• Please review our updated Terms and Rules here

MCL68+ A Motorola 68000 drop-in emulator

MicroCoreLabs

MicroCoreLabs

Experienced Member
Joined
Feb 12, 2016
Messages
292
I would like to share my latest project, a Motorola 68000 drop-in emulator called the MCL68+. The CPU emulation is written in C and runs on a Teensy 4.1 micro controller board. I made a small PCB which contains a number of buffers and registers to break out and de-multiplex the Teensy's limited pins to the 68000's 64 pins.

I thought now would be a good time to share my progress in case I never get any further along! 🙂

 
Thanks for pointing this development out here. Don't have time right now, but will be watching this soon.

Do you think that that you would be able to emulate the later processors in the line, 68020, 68030, etc. with this also?

That would allow simple upgrades and repair to a lot of Macs, Amigas, and such.

How different is this from your MCL86+ being used to "replace" the IBM PC's 8088 experiment?
 
It was a challenge to bit-bang the 68000's local bus at 8 Mhz, so I think emulating an even faster processor is probably not possible. That said, I thought running at 4.77 Mhz was the most speed I could squeeze out of the Teensy so you never know...

It would be a "simple" upgrade if the 68000 was socketed, which it is not on the Macintosh or the Sega! :) I am curious if the MCL68+ will run noticeably faster than a 68000 when cycle accuracy is disabled and code is run from internal memory. Hopefully I can debug it to a point where I can find out!

The MCL68+ is basically the same as the MCL86+ in that it uses a Teensy 4.1 to emulate both the CPU and to bit-bang the local bus interface. The Motorola 68000 has a de-multiplexed address and data bus, so I use shift registers and buffers to break out the Teensy's limited IO's to the 64 pins of the 68K. The MCL68+ is significantly more complicated due to this plus it is running 2X faster than the 4.77 Mhz MCL86+...

I believe the local bus is working correctly so the next challenge is to debug why I am getting this OS crash. I believe it is an address alignment error so hopefully I will be able to trace back to the instruction that caused it... (Sometimes debugging CPU's is like looking for a needle in a haystack)
 
acgs said:
Do you think that that you would be able to emulate the later processors in the line, 68020, 68030, etc. with this also?
Click to expand...

Someone over on TinkerDifferent got a PiStorm, which is an Amiga upgrade, *mostly* working in a Mac SE. A big caveat is SCSI doesn't work for some reason.
tinkerdifferent.com

PiStorm on the Macintosh SE

Starting a thread to track my experiments on using the PiStorm on the Macintosh SE. Just today I tried a new configuration and got much better numbers on SpeedoMeter... I removed the original CPU and put in a socket so I can run both the original CPU and the PiStorm. It could be installed...
tinkerdifferent.com tinkerdifferent.com

68000, 68010 and 68EC020 are possible, because they all have a 24 bit address bus. A full 68020/68030 isn't possible without a lot of glue logic due to the 32 bit buses. There was a reason those 68020/030 upgrades for compact macs were so expensive, it took a lot of engineering time and parts to interface a 32 bit CPU onto a 16 bit data bus, 24 bit address bus and deal with the bus speed timings. The CPU had to slow down to the 68000 bus speed of ~8 MHz to do anything on the host motherboard. The memory map on a compact mac is also a mess with devices sprinkled all over the upper memory map, limiting the maximum amount of memory available without tricks using a MMU.

I'm sure it'd be possible to cram an entire upgrade board into a modern FPGA, but the cost isn't going to change from back then. It'd be a better use of time to just engineer a new logic board for the compact mac. Several Mac logic boards have already been cloned because of battery bombs, so it's not much of a stretch to make a custom logic board based on another mac.
 
Is there a repository of 400K disk images for games/applications which are compatible with DART?
 
MicroCoreLabs said:
Is there a repository of 400K disk images for games/applications which are compatible with DART?
Click to expand...
You don't want to use DART
DART was quickly replaced by Disk Copy 4.2 which is the preferred imaging tool for non copy-protected floppies.
Apple's disk imaging tools are pretty useless for copying copy-protected disks.
It's only been the last couple of years with people having access to Applesauce floppy readers that accurate
runnable copy-protected disk images have been made available.
 
Last edited:
GiGaBiTe said:
I'm sure it'd be possible to cram an entire upgrade board into a modern FPGA
Click to expand...

The problem you will have is recreating the timing and side-effects the earlier machines depend on.
I was at Apple. I know how the sausage was made. It was well into the PowerPC era before some of
the really gross aspects of the I/O system were fixed. Only MAME has been crazy enough to actually
emulate parts of the system other emulators just patch out.

The original versions of the compact Mac firmware is not pretty, and people inside and outside wrote
really gross timing-dependent code for it.
 
One of the ironies of how the Macintosh was designed is *if* you're just talking about hitting the firmware ROM APIs the OS, even in its earliest form, has *amazing* hardware independence; if you patch out the device drivers and replace them with your own stubs, going all the way back to the original 64/128K ROMs, you can run System and *most* Mac user software on just about anything with a 68000 CPU, the hardware doesn't matter hardly at all. (Witness the Macintosh emulators that ran on Atari STs and Amigas; the hard part was reading Macintosh floppy disks, the "hardware" for the actual emulation was just a carrier to shove a set of Mac ROM chips into.)

But underneath that amazing software layer the hardware in 68K Macs was usually pretty hacky. Building a computer to run an *unmodified* Mac ROM means replicating a bunch of arcane hardware shortcuts and completely messed up memory maps, it's only been fairly recently that the FPGA computer folks have managed to get fully functional Mac Plus simulation working. Replicating a newer Mac well enough to use its ROM directly is probably going to be even harder, because later machines mostly replaced their few standard parts like the VIAs with fully custom circuits that Apple never documented completely.

Anyway, yeah, this is why emulators that hack the ROM, like BasiliskII/Sheepshaver, are "easy" and have been mostly working forever, but MAME's Mac support had an extremely difficult history.
 
Wow.. interesting. I am just emulating the 68000 so the motherboard components are all the same, including the original ROM. I keep getting stuck at the same place which is a JSR to a misaligned address. Tracing backwards is proving difficult... :)
 
Al Kossow said:
The problem you will have is recreating the timing and side-effects the earlier machines depend on.
I was at Apple. I know how the sausage was made. It was well into the PowerPC era before some of
the really gross aspects of the I/O system were fixed. Only MAME has been crazy enough to actually
emulate parts of the system other emulators just patch out.

The original versions of the compact Mac firmware is not pretty, and people inside and outside wrote
really gross timing-dependent code for it.
Click to expand...

There wasn't a single 68k or PPC Mac that didn't have some gross aspect. CPUs with crippled half buses (LC, LC II and the 2349823 different models based on them), CPUs crippled with 68k bus emulators to recycle old chips (Performa 52xx, 62xx), CPUs bolted on to old motherboards they had no business on (IIvx -> Performa 600.)

And pretty much every mac had zero hardware acceleration, everything was done in software on the CPU, which crippled performance. I think the Mac SE was the first to have some form of pedestrian video acceleration for the refresh circuitry, so the CPU wasn't having to bit bang the display and chase the raster.

The only reason that Apple survived the 90s is because of the community and 3rd party vendors fixing their broken crap. By the time OS9 came out, more of the OS had been written by third parties than Apple itself, most of the technology was bought from outside.
 
GiGaBiTe said:
I think the Mac SE was the first to have some form of pedestrian video acceleration for the refresh circuitry, so the CPU wasn't having to bit bang the display and chase the raster.
Click to expand...

The CPU doesn’t “chase the raster” or “bit-bang” the display in the Mac Plus, nor does the SE have any “video acceleration“, both are just dumb framebuffers sharing the same RAM between the CPU and video refresh. The minor speed improvement in the SE is due to slightly smarter memory contention logic that does a better job preventing the CPU from having to wait when the raster is in the active area. (I don’t recall the exact details, I think it indulges in a little clock cycle stretching while the Plus is stuck with hardcoded video/RAM access windows. Unfortunately for Apple the 68000 doesn’t have the neat predictable 50/50 duty cycle synchronous bus of the 6502, some wait states are inevitable, but smart design can minimize them. Similar differences are why a Tandy 1000 running from shared RAM is faster than a PCjr even though they both run their CPUs at 4.77mhz.)
 
Oh yeah I remember the Power Macintosh 5200...same front-end ASIC as the Quadra 630 and even the ROM was very similar to the one on the Power Macintosh card used in the 630- even the same startup chime.
 
You must log in or register to reply here.
Back
Top