ai – MicroCore Labs

I would like to share an update for the MicroCore Labs MCL68+ project first introduced here: https://microcorelabs.com/2023/10/26/mcl68-motorola-68000-emulator-2/

I am happy to say that it is now able to completely boot and run the Macintosh 512K!

As a winter project I thought I would pick this project back up after a two year break and see if I could make some progress. When I left off the MCL68+ was able to almost boot to the MacOS desktop but would get a fatal error.

The breakthrough was to run the MCL68+ against Tom Harte’s 68000 opcode test suite which found a number of subtle errors which were resulting in the Mac experiencing the fatal error.

The reason I did not use Tom’s test suite two years ago was because they are all written in JSON format and I lacked the skills to translate it into vectors that my code could use. I STILL lack these skills but I was able to generate the conversion code using ChatGPT. I was impressed that between my prompt and the maturity of ChatGPT it was able to generate the correct code on the first pass!

Once I had the stream of opcode before and after results I was able to plug them into the MCL68+ and see where they diverged. The errors on the MCL68+ were mainly due to incorrect effective address handling when the address for the opcode source and destination was the same register. There were a few instances of incorrect flag calculations and stack ordering as well.

I believe there were over a million tests, so I am fairly confident at this point that the MCL68+ 68000 emulation code is now mostly correct – and cycle accurate to a large degree.

The Macintosh runs the CPU at almost 8 MHz and was a real challenge to get the Teensy 4.1 to bit-bang the local bus at that speed. I believe there are still signal integrity issues at the local bus interface so I chose to emulate the Mac’s 512K of RAM and the BIOS ROM inside of the Teensy to guarantee error-free operation. You may be able to see random dots around the screen which I believe are due to stray bus cycles writing to the video memory. These are harmless.

The updated source code is uploaded to GitHub: https://github.com/MicroCoreLabs/Projects/tree/master/MCL68%2B/code

Here is a short video demo of the MCL68+ running in a vintage Apple Macintosh 512K

You can reach me at: mailto:eastwood90@hush.com

I got the MCL86+ running on the IBM PCjr by adding 8088 minimum mode support plus a few modifications to the PCB.

Project on GitHub: https://github.com/MicroCoreLabs/Projects/tree/master/MCL86%2B

Cycle accurate mode appears to work fine so I next added some acceleration by removing clock counting and mirroring all 640 KB inside of the Teensy. According to MIPS.COM, this IBM PCjr is as fast as a 80386.

The only issue I am running into is the inability to write to the floppy drive. Reads work fine but writes are inconsistent. I’m fairly sure I know why…

Early in the development of the MCL86jr+ I found that the PCjr BIOS is very (overly) reliant on 8088 instruction and bus timing.

Here is what I found:

In the BIOS POST CRT Attachment Test the MCL86jr+ would fail with ERROR 0908 and halting. Once I compared the sequence on a logic analyzer with a genuine 8088 I could see that the MCL86+ was performing opcode prefetches at the end of opcodes while the real 8088 interspersed them throughout the opcode execution. This resulted in the MCL86jr+ opcode execution being “tighter” and ready to accept interrupts earlier than the genuine 8088 could.

Shortly after the OUT opcode at address 0xF0452 which enables the vertical retrace interrupt was executed, the MCL86jr+ would accept and process the interrupt which disabled the source even before the main loop at address 0xF0459 had started. This code is not well written and is dependent on specific bus timing and recognition of the interrupt.

Also, I am certain that interrupts were already enabled before address 0x0F458, so the STI opcode should not have been necessary. I wonder if they added it as an attempt to guarantee that interrupts would not be accepted until at least the end of the TEST opcode. (They knew that interrupts are not accepted at the end on the STI opcode). Seems like a sloppy solution.

My guess is that there is another timing-dependent piece of code somewhere in the floppy write routine which is not tolerant of big differences in the MCL86jr+’s approach to opcode and bus timing.