
for somereason SNAPSHOT (versados) locks up on 4.6 (stuck in task is terminating state)... others, NOT 4.6, can break out but snapshot does not print the screen.. it is stuck, but will terminate... probably something to do with background activation blocks from screen driver, not getting done due to no DOEVENTS occuring while in loop. Dont really know... 

actually quite a few things dont work right in 4.6..the graphics server can not break out 

for some unknown reason, executing SNAPSHOT as first command after boot as user 0 , causes VDOS to crash...All versions

maybe the break handling in the term driver needs something that i did not emulate.

-----------

the line 

    MOVE.W   #$100,FHSBLK+34-BASE(A5)

in the download programs, caused the assembler to abort with bus error/bad pointer Don't know why.
Lost the source, so can not test, but maybe the bad EOR instruction was to blame. (or maybe the z option was too small)

-

SOMETIMES, The screen keyboard refuses to relinquish focus by simply clicking another window in the emulator. you have to use the task bar... or click on a window outside the emulator, first ????. closing and then restarting the emulator fixes it. (until the next time)

-

TENBUG issues a Keyboard Time Out when first started. the timeout seems not to matter. May fix it someday, but not a priority. Need Source for Tenbug. Tried adding a return of Buffer empty... the OS drivers still worked but tenbug did not wait for Cntrl-C

I have imaged Tenbug 2.1 and Tenbug 2.2 from my real VME10s... Both are provided, along with the other good Tenbug 2.2 NOTE that the names of the two new tenbugs are .mx, not .s19, so, might need to change defaults if upgrading. i have removed the bad tenbug 2.1

NOTE - Tenbug appears to be based on MACSBUG as is TUTOR. Tenbug uses the same temp address (0x30) for error msg as does TUTOR. 

The garbage spewn onto the screen during Tenbug startup, is due to the implementation of the screen. The screen does NOT work exactly as the real one. (see memory.txt) Tenbug tests the graphics ram and the character display ram and the character genrator ram and the character attributes ram, during start up. This is where the garbage spewn onto the screen comes from... a real vme10 does not attempt to display anything until the hardware is initialized, but the emulator displays characters even before the character hardware is initialized. .

DO NOT enable TENBUG self-TESTs...

-

The programs that are with the versados 4.6 hard disk image were written on an old machine with supervisor only access to certain hardware. On the emulator all hardware is accessible in both user and supervisor mode. so, the use of a user defined directive to access the 6845 is NOT required, and the program that changes the screen to 25x80 or 50x80 should be re-written. Back in 1990, during the install of 4.6 from verbatim floppies, there was errors, so i did not install everything. Now those disks are unreadable.

-

the CPM 1.3 hard disk that uses the fake hardware, was written to be booted with the BSOD rom. It appears to work with Tenbug, but might have trouble detecting the boot drive. 

-

if the Versados KILL bug is encountered, the file is not killed; but is overwritten. The file is not truncated so, smaller files will have the old garbage at the end. Think i have fixed. 

-

the graphics server is slow, as is, all uses of the screen

occassionally, the screen turns white while configuring the control registers... can not find the reason, but not significant enough to warrant fixing..

sometimes the graphics freeze until the mouse is clicked... DEMO Clock..think it might be due to windows pre-processing the F10 key...but really don't know

-

The Versados realtime clock is NOT reliable. Versados keeps real time by tallying the number of milliseconds that have passed since midnight. Each periodic interrupt(from the 14HC6818) causes the OS to add 125.625 ms to the count. The emuulator can not interrupt at 15.625 ms. The runtime for the emulator can only interrupt in multiples of 55ms (18.2 HZ  54.9450549450549450549450549450549 MS). Use HOT patch to attempt alleviation (not fix)

Reading the 14hc6818 is reliable. But, Versados does not use what it reads. (some do, but not 4.3)

The UNIX periodic interrupt is severely OFF. Unix thinks it is being interrupted every 10ms, but it is really being interrupted every 55 ms.. so, wait times are longer than you think...be patient, or figure out how to change it.

- 

The mvme400 cards dont seem to work perfectly with unix. You must open any ports and associate them with a TTY, CRT or NET emulated device, before booting, for unix to use them. Versados uses a transition on DSR to tell when a device is up or down. Unix ???.

The 400 cards are jerky in unix. 

Unix never seems to read the 1468hc18.. it sets the internal clock to the time of the last shutdown.

---

after creating and running the graphics kerel for unix (r1v2.8), the KILLALL aborts with memory fault. Not sure if bug in unix (can not imagine releasing with such a thing) or if there's a bug in the emulator.. if emulator bug, most likely in MMU.

--

sometimes it is best to move the emulator's executable to a path with NO spaces. Avoid spaces in all pathes used with the emulator. Not sure why, in some places , spaces work, and others they do NOT.

----

running on windows 7, 8, 10 is problematic. This is due to compatibility problems. Normally, windows has a set of compatability flags, to make older programs work properly.. i don't know what they are supposed to be for Visual Basic 6 programs... BUT... if someone installs the emulator on an older system and then upgrades to a newer windows, the migration feature will set the compatibility flags correctly for VB6 (the emulator's EXE). But if you install fresh on a new windows, no compatibility flags will be set. So, if you have problems go on-line and find someone who upgraded windows while the emulator was installed... their system will have the compatability flag settings that you need.


--

There might be a problem with the RWIN's calculation of offsets into a disk image. The Unix documentation says that Partition 0 starts at block 112, which is 57344, but the actual disk has partition 0 starting at 57856, which is block 113.  ????? everything else works..Versados, CPM and unix, so ?????

the versados values work out to match where they are on the disk. So, might be bug in unix or its documentation.

--

Many of the tests in the power-up self-test for tenbug fail. Need source for tenbug to figure it out.
Many of the tests in the Disk Resident Diagnostic bootable programs fail. Need source for Diagnostic tests to figure out why.

--

selecting memory to exist between 60000 and 17ffff, and memory to be at 180000 and UP causes the SCM.SY on-board memory test to fail. They seem to only support memory to 0x100000. The routine accidentally checks 0xF00000 instead of 0x100000


--

for unknown reason, screen colors for diagnostics changed to blue ( with inverse yellow on white) seems what the program intended, but sure is hard to read. Might be intended for Mono screen only, so added support for mono screen (green or white phosphors)

--

need more than default memory to run some of the graphics demos
if you apply timer patch to versados and run the graphics demo, the demo has a tendency to stall. suspect loss of periodic events to ASR

when running the graphics demo on vdos 4.6, the break key refuses to terminate the randomlines demo..don't know why...

----

versados 4.3 barely fits in the 384k of memory. Default sysgen, does NOT look for memory outside the default 0-5ffff...So, add memory boards and do a sysgen to see memory above 180000. If you do a sysgen and add anything, you must also add memory in the sysgen files, else next sysgen fails.

When i added a second HD and a second FD to Versados 4.3, the system could not do a sysgen, because not enough memory. So, add memory when you do a sysgen. 

--

When running UNIX it looks like the emulator is running VERY slow... this happens when the OS has nothing to do, and executes a STOP #srdata instruction, such as when there's no programs running and the system is waiting for interrupts from the IO. The STOP instruction releases control to the OS on EVERY execution of it. It also loops in microcode, so counted as only one instruction. So, basically, the STOP instruction DOES execute slow, but when the OS has stuff to do, it will show that it is running faster, due to the fact that it is no longer looping on the STOP instruction. During looping on the STOP instruction, the system will be servicing periodic interrupts only, so the total instructions executed will be the STOP loop plus the instructions in the periodic interrupt service routine, which is executed 18.2 times a second. (not 60 times a second as Unix thinks.)

---

