technology

MCL68+ MOTOROLA 68000 EMULATOR – UPDATE

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

MCL68+ MOTOROLA 68000 EMULATOR – UPDATE

8088 CPU Emulator for the IBM PCjr – MCL86jr+

MicroCore Labs, , , , , , , , , , , ,

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.

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

8088 CPU Emulator for the IBM PCjr – MCL86jr+

MCLV20_Max – A Software-defined NEC V20 CPU And More

MicroCore Labs, , , ,

The MCLV20_Max is a Teensy 4.1-based software-defined drop-in CPU replacement for the Intel 8088 used in vintage IBM XT’s. It has enhancements built upon the MCL86+ project and uses the same PCB.

It emulates the full Intel 8088 instruction set as well as the additional 80188 and V20 opcodes. It also mimics the behavior of the V20 with its treatment of flags, shift-counts, and the ability to restart multiple prefixes upon exit of an interrupt. Below is the Anonymous BIOS which recognizes the MCLV20_Max as a V20 CPU.

In addition to the CPU emulation, some of the features of the XTMax project are integrated into the MCLV20_Max which include 4 MB of Expanded RAM and MicroSD hard drive support. Below are the drivers being loaded that configure the 4 MB of Expanded RAM and enumerate the MicroSD as drive D:

Two acceleration modes are provided. Acceleration mode 1 simply removes opcode clock cycle accuracy so that one opcode is executed for each clock. This can provide for as much as 100% speed improvement over the stock 4.77 Mhz 8088.

Acceleration mode 2 provides the maximum acceleration which can be from 5 to 10X faster than the 8088. It does this by first copying all 640 KB of the motherboard RAM plus the ROM into the Teensy’s internal memory which runs at 800 Mhz+. From then on all CPU accesses to instruction and data are handled using this fast mirror RAM with only CPU accesses to motherboard peripherals and video RAM using the CPU’s local bus. The resulting speed is faster than a 10 Mhz 80286 and approaching that of a 80386.

The MCLV20_Max also has enough internal memory to host any BIOS or diagnostic ROM.

Using a modified LoTech EMM 3.2 driver, MCLV20_Max can provide 4 MB of Expanded RAM which can be used as a fast RAMDISK and like the XTMax project, the MCLV20_Max can also provide access to a MicroSD card which is formatted as FAT16 and can be freely used by any other computer including Windows, Mac, Linux, and Chromebook.

I made a few video demonstrations of the MCLV20_Max and posted to YouTube:

All of the source code and PCB files are open source and posted on GitHub:

https://github.com/MicroCoreLabs/Projects/tree/master/MCLV20_Max

MCLV20_Max – A Software-defined NEC V20 CPU And More

XTMax – 8-bit Software-Defined ISA card using Teensy 4.1

MicroCore Labs, , , , , , , , ,

XTMax is a software-defined 8-bit ISA card which uses a Teesny 4.1 microcontroller board that provides the functionality of THREE vintage ISA cards. It can expand “conventional” motherboard RAM up to 640 KB, adds up to 16 MB of Expanded RAM, supports 320 KB of UMB RAM, and provides bootable hard-drive access using a MicroSD card. A small PCB is used to allow nearly all of the ISA bus signals to attach to the Teensy 4.1.

A similar project to this is the PicoMem which is also a software-defined ISA expansion card, however the Teensy 4.1 used on the XTMax is nearly 3X faster than the Raspberry Pi Pico so does not share some of its limitations.

The first feature of XTMax is that it can expand the motherboard’s conventional (motherboard) ram up to 640 KB without limitation and with zero wait states. XTMax also has no limitation on the ability to support DMA to and from the computer’s floppy or spinning hard disks as PicoMem does.

XTMax can currently support 16 MB of Expanded RAM and 320 KB of UMB using a updated drivers.

XTmax also allows a MicroSD card to be accessed as a hard drive which is similar to the functionality of an XT-IDE card. By default it will be the boot device if there is no hard drive present.

All design files are open souce and posted to GitHub:

https://github.com/MicroCoreLabs/Projects/tree/master/XTMax

Here is the PCB developed using KiCAD:

And here is the actual board with a Teensy 4.1 attached:

Here is XTMax installed in a very early IBM 5150 rev-A which has 64 KB installed on the motherboard.

It shows that 4 MB of Expanded RAM was added and that the MicroSD card is accessible as the C: drive. The older IBM PC’s did not display the total amount of conventional memory, but in this application below the memory is expanded to the maximum of 640 KB.

It is worth noting that the first BIOS version of the IBM PC did not support extension ROMs and therefore do not support hard disks, so XTMax is currently the only way to have a hard disk equivalent on these machines!

Here is the total memory on this early PC as reported by Norton Utilities:

Here is a screen capture of the XTMax providing 16 MB of Expanded RAM and loads the UMB driver plus configures a 15 MB RAMDISK!

I posted a video on YouTube of the XTMax in action:

XTMax – 8-bit Software-Defined ISA card using Teensy 4.1