In 2014, i decided to finally write a VME10 emulator. I started it in C, and intended to run it on both Linux and Windows. However, i found that i was writting more test code than actual code for the emulator. I had the MMU, and the Display, mostly working. I had the CPU doing simple Bus Error and Address Error processing and the RTE instruction working. But when i saw what had to be done to every instruction to allow return and continue, i gave up. 

Three years passed, i got an idea. I would first write in Visual basic and then port to C. This idea was not a good one. After i began writting in Visual Basic, i decided to do the whole thing in VB6. This is also a bad idea, since VB6 is no longer supported for Windows. This means that to run this emulator, you must use an older windows that does support running VB6 runtime and programs. I find that running a Virtual machine on linux and then installing W2000 with guest additions is a very good platform to run  the emulator. I personally still use a W98 system to do the actual development. It would be nice to run W98 on the VM but i dont think they have guest additions for it, so the graphics is too slow. 

TO run on Newer Windows. you must set compatibilty flags (found in the registry) I do not know what flags are needed. If you upgade a windows to a newer windows while the emulator is correctly installed, the migration program will automagically set the correct compatability flags. But if you install the emulator after installing a new windows, the flags are NOT set. 

I wrote the entire VME10 emulator using VB6 enterprise edition, and compiled it to native code. This produces a fairly good product. 

The MC68010 CPU for the VME10 emulator is implemented with a microcode engine, however, it is NOT the same MCE as the real MC68010. This was done to facilitate the RTE instruction's ability to return and continue after an access fault. And to facilitate modifying the MC while running. (change CPU type)

I have figured out a way to increase the speed. Make two MCEs, one for normal execution and one for executing an instruction after an RTE instruction... Lots-0-work, so wait..plus looks like minimal increase, if both are microcoded.  And Logic is absurd if one is brute force and only the RTE one is microcode.

The MC68451 is implemented only for a single chip. Implementing the interchip communication would have slowed the emulator much more than the benefit of having more descriptors. The MMU also contains a non-standard AST CACHE.

As i wrote, i knew that it would be a major task to write all the VME10 hardware implementation and debug it all at the same time. So, i wrote some FAKE hardware, based on the emulated hardware in the Z80 emulator for Windows. This fake hardware allowed a quick path to getting the emulator running "real" code. 

CPM68K comes from DRI with a pre-built S-rec system that the user only has to add a bios, but is configured for a MC68000. I added a bios for the FAKE hardware, and tested the CPU and other features. To do this, required that the VME10 emulator run as a MC68000, instead of a MC68010, so i added an option to make the VME10 emulator run as a MC68000. Then, just for fun, i added the ability to run as a CPU32 (not completely finished with it) .

Early on, while running CPM68K, i ran into a terrible problem. The C compiler was getting stuck in an infinite loop, until the stack overflowed. This led me to believe that there was a bug in the CPU. I spent weeks looking for a bug. I found many, but fixing them did not fix the C compiler. 

Finally, i reached out for help. I contacted David Schultz, who wrote the CPMSIM emulator based on the MUSASHI MC68k emulator, by k. Stenerud. I downloaded the CPMSIM and moved the same software that i was running to the CPMSIM. I did this by copying the CPMSIM's 16MB image. Then, leaving the existing stuff to boot, i replaced everything else on the image with the same code i was running. It turns out that the bug was in a the C compiler. David Schultz pointed out that my syntax for describing a pointer to a structure was wrong. The C compiler, instead of issueing a warning or error, got stuck. 

As a result, i found that i like the CPMSIM. It is fast and very stable. I also like the software that David Schultz placed on his disk image, so i made, the BIOS for CPM68k for my emulator's fake hardware, also be able to access his 16mb disk image, and added a few options to make the VME10 have memory where his CPMSIM also has memory, thus allowing his CPMSIM 16mb disk image to be used on the VME10 emulator. It can be made bootable by replacing his boot stuff with my Boot stuff with BIOS that uses the fake hardware.

My BIOS for the fake hardware ignores the VME10's RWIN's requirements for what is a floppy and what is a HD. Any type of supported disk image can be placed in any drive for the Fake BIOS. The RWIN requires HDs in HD00 and HD01 and floppies in FD02 and FD03. The fake BIOS uses the Fake hardware Disk Controller(not the RWIN) and any disk can go anywhere. 

If you need to run CPM, i recommend using the CPMSIM, because it is very fast. The VME10 emulator with its MMU and microcoded CPU is very slow, but, if you need to run VersaDOS, the VME10 emulator can run the Motorola distributions of VersaDOS as-is. It can also run the DRI distribution of the CPM68k for the VME10 as-is. It also runs Unix SYSV68k r1v2.8 as-is.

The default VersaDOS has one MVME400 and one MVME410. The vme10 emulator can have two MVME400s so that up to 5 users can be login at the same time. 

The MVME410 supports the Versados SPL (spooler task) by implementing all the interrupts needed.

For several weeks i searched for another problem. The MVME400 cards refused to work with Versados, until i found that i had reversed the polarity of the DSR signal. 

For months, i was stumped by the fact that TENBUG 2.1 ROM image would not run on the VME10..Disaasembled and debugged for weeks. Finally, one day while diassembling, i noticed a MOVEM.L reglist,-(a3) .. this was wrong. Should have been MOVEM.L reglist,-(a7). The Image file for Tenbug 2.1 had an error in it... at offset 6650 the word 48E3 should have been 48E7. After fixing tenbug 2.1 worked. Al Kossov sent me a TENBUG 2.2, which is better. I added Tenbug 2.1 and 2.2 from my real VME10s, replacing the defective tenbug 2.1. 

I do not regret having a tenbug that was bad... while looking for why it did not work, i found several bugs in the emulator, which i probably would not have found elsewise. 

While writting the VME10 emulator, three real VME10s sat in a corner.  I finally got around to setting them up and imaged the hard disks on two of them (two had Unix SYSV/68 r2v1.0 and the other has Versados 4.6) I imaged the two unix systems and imaged the Tenbug ROMs. One had Tenbug 2.1 and the other Tenbug 2.2.

To image the HDs, i set up a W95 PC with Hyperterm, configured to connect to a MVME400 Port. I turned on the VME10, then typed Cntrl-C to make Tenbug talk to the 400 port, instead of the keyboard/screen. (all of my monitors for the VME10 no longer work...would be nice to connect a VGA , but don't know how to build a converter..should be simple, but i have no lab equipment.. if you know tell me, via snail-mail) Then, since Unix is loaded on disks that have been formatted using alternate sectors, i simply read blocks of the HD into memory (1MB at a time), then dumped (using TEnbug DU command) that memory to the 400 port, as s-recs, and captured it to a file on the PC. Each 1MB of memory( disk ) took about 50 minutes to transfer at 9600 baud. After acquiring about 40 s-rec files (each about 3MB in size, 120mb total) i then loaded them onto the VME10 emulator, by using the emulator's LOAD memory, then used the emulator's Get/put Boot to write to a disk image.. the disk images worked fine as-is with the emulator. Since the last 72 tracks were reserved for alternate sectors, i did not need them. The data in the alternate sectors was returned when the defective sector was read. and the emulator always thinks that the disk is perfect.

I want to thank Al Kossov, David Schultz, bkrosin and Larry Greene for listening to my rambling about the problems i have. And, of course, Gaby Chaudry for distributing it.

i am currently writting a VME147 emulator. I have almost nothing to run on it. I only have the MVME147BUG which was sent to me by bkrosin. 

apparently, someone has been watching the internet connection to the JUNO, client v4 server.  They have stolen my e-mail and now check it and respond to people who contacted me for help. They claim that the emulator is a trojan horse which locks their computer and that the victim must send them money to a bitcoin wallet. Their claims are false. I do development on a machine which has NEVER been conected to the internet. I have a separate machine to search for stuff and another that ran my web server. i have two LANs inn my house. one can access the internet, the other can not. 

about 4 years ago, all SSL stopped working for my systems(w98)... i did not care because i only used e-mail and ran my own server.. i have never liked the internet, and have never used any social media. 
 
to distribute the emulators, i would send an e-mail to mrs chaudry, then she would download it from my server (fixed IP with NO DNS, but using Apache virtual webs). This required that anyone who wanted to access it must add a name record to their HOSTS file. the default VWWW had access denied to enverone, so only someone with that hosts record could access it. "IP only" would use the default server and by default was denied) 


i have now terminated my internet access. don't need it anymore. this means that i no longer can provide free support. now use snail-mail only...

