Building a Classic Mac Hardware Clone
What would it take to build a working clone of an early 80’s Macintosh computer? I’ve been kicking around the idea of a 68000-based project for a while– a custom computer something like BMOW 1, but using a 68000 CPU instead of a homebrew CPU design. More than two years ago I purchased a 68000 and a 68008 (68000 variant with an 8-bit bus) in anticipation of such a project, but never did anything with them. Recently, however, my thoughts returned to the 68000 idea in the form of a Mac 128K or Mac 512K clone. I’m imagining something like the Replica 1 Apple I clone, but for the classic Mac series: a custom hardware project using all new components (zero Apple hardware) which is able to directly run classic Mac software. In order to meet the zero Apple hardware requirement, a standard PS/2 or USB mouse and keyboard would be used, and some kind of floppy disk substitute like an SD card. The floppy disk would likely be the most challenging piece of the project by far, but I’ll return to that in a minute.
The original Mac 128K (expandable to 512K) contained only four LSI chips: the Motorola 68000 CPU, Zilog 8530 serial port controller, MOS 6522 VIA containing ports and timers, and Apple’s own IWM floppy controller. Everything else was just RAM, ROM, some PALs for glue logic, and a bunch of simple TTL chips. You can even find a mostly-legible schematic of the motherboard if you search online. So what exactly would be involved in constructing a working clone?
Logic Core
The easiest piece would be the logic core, consisting of the 68000 itself, RAM, and ROM. Finding appropriate components new would not be difficult. SRAM could be used in place of the original system’s DRAM, eliminating the need to worry about DRAM refresh. ROM could be programmed with an authentic Mac ROM image obtained online, or even physically copied from a vintage Mac. The required memory map is simple: RAM begins at address 0, and ROM begins at $400000. There’s some voodoo at startup where the address decoding is temporarily altered to place ROM at 0 and RAM and $600000, but that wouldn’t pose too large a problem. All that’s really needed is a 68000, RAM, ROM with appropriate image, and address decoding logic to create a classic Mac clone that would successfully “boot” to the the point where it first attempted to communicate with any peripherals.
Video
The original Mac maintained a 512 x 342 1-bit frame buffer in main memory at $01A700. Some kind of memory controller logic held the CPU in a wait state if it attempted to access that area of memory while the video circuitry was using it. I need to research that further, but it doesn’t sound too complex to replicate. BMOW 1’s video circuitry worked similarly, so I’m fairly condfident I could design a circuit to generate a 640 x 480 VGA signal with a 512 x 342 image centered in it, using the memory at $01A700 as a 1-bit frame buffer. Maybe I’m naive, but while it certainly wouldn’t be a simple project I don’t envision any particularly difficult challenges.
Sound
I would be prepared to ignore sound altogether and make a silent clone, but replicating the sound hardware may not be overly difficult. I haven’t looked into it in detail, but it appears the original Mac had a 740 byte sound buffer at a fixed address, which worked conceptually similarly to the frame buffer and actually shared some of the same hardware. At the end of each horizontal scan line, the next byte was fetched from the sound buffer, and used to control a PWM output, which was filtered by analog hardware to create an analog audio voltage. Since the horizontal refresh rate was 22 kHz, this yielding 8-bit 22 kHz digital audio. While I haven’t confirmed this, I assume the 740 byte sound bank operated as a ring buffer, updated as needed by the system software to ensure the audio hardware was never starved for sample data.
Mouse
The classic Mac mouse consisted of four optical encoders (two per axis) plus the mouse button. Some of these were connected to the 6522 VIA and some to the 8530 serial controller in an unconventional way, but I believe all of them generated a CPU interrupt when their state changed. Assuming the exact details of the connections are documented somewhere, it should be possible to use a small microcontroller to get position data from a PS/2 mouse and synthesize the corresponding optical encoder state changes. If no adequate documentation exists, though, it may be necessary to disassemble portions of the Mac ROM to learn exactly what signals are expected on what ports, or to follow the traces on a real Mac 128K motherboard.
Keyboard
Creating a working keyboard would be more challenging, and would probably require reverse engineering some of the Mac ROM to understand its operation, or studying the signals from a real Mac keyboard during operation. From what I’ve read, the classic Mac keyboard was an “intelligent peripheral” and communicated using a serial interface, although it was actually connected to the 6522 VIA rather than the 8530 serial controller. The Mac initiated all communication, and the keyboard only sent keypress data when specifically requested, rather than generating an interrupt when a key was pressed. Assuming the keyboard communication protocol and list of key codes are documented somewhere, this might not be too difficult to simulate, and reverse engineering could be avoided. A small microcontroller connected to a PS/2 keyboard could buffer key data, and send it to the Mac clone in the appropriate format when requested.
Timers and Interrupts
I’m not too concerned about these, as they are fairly well documented. I believe there was both a 60 Hz and 1 Hz interrupt, which I could replicate easily enough. The VIA also had some built-in timer functionality, that I could probably emulate if I can find the datasheet for it. Maybe I could even use a real 6522 VIA, if they can still be found.
Floppy Disk
The floppy disk is where things begin to look pretty grim. The original Mac interfaced with the floppy disk drive at an amazingly low level: it directly controlled the disk rotation speed and track-to-track head movement, and read data one bit at a time as the head passed over a track. In fact, I’m betting it didn’t even read logical 0’s and 1’s from the track, but instead had to parse magnetic flux transitions into 0’s and 1’s in software, just like the card reader in my Mozart’s Credit Card project. In theory I could build something using a microcontroller or FPGA that reads an SD memory card, and simulates a floppy drive at this low level, but it sounds terrible. It would have to keep track of virtual head movement, and do on-the-fly recoding of data into fake flux transitions. And to make matters worse, I have no idea how raw data was stored on each track on those 400K/800K floppies, and that’s exactly the sort of information that’s not likely to be well-documented now. How was the beginning of a track marked? What sort of structure did the track data have? Who knows, and I don’t really want to find out.
Unfortunately, all the Mac ROM routines will expect to control the floppy drive at this level of detail, by tickling memory-mapped registers in the IWM to adjust drive speed and read flux transitions and so forth. If I don’t want to simulate a floppy at that level of detail, then I can’t use those ROM routines.
The only alternative I can see is to patch the Mac ROM and replace the floppy-related routines with new routines of my own creation, which read/write to an SD card using memory mapped I/O. That seems nearly as bad as the first option, and raises many more questions. Does all floppy disk access go through a well-defined floppy API in ROM, or do some low-level routines (perhaps at startup) access the floppy hardware directly? How can I find all the routines requiring patching, short of reverse engineering the whole ROM? I also dislike the idea of having to modify the original Mac ROM. It seems like the start of a slippery slope towards building a Mac emulator instead of a true Mac hardware clone.
One possible source of help for indentifying the areas needing attention is classic Mac emulators, and in particular Mini vMac. I haven’t looked at its source code, but Mini vMac claims to emulate classic Macs like the 128K by directly emulating all Mac hardware except the floppy drive. I assume that means it patches or intercepts the floppy-related routines in Mac ROM. By studying the Mini vMac source code to see which portions of the ROM it patches, that should give me an idea which portions I’d need to patch for a classic Mac hardware clone.
Conclusions
The classic Mac hardware clone seems almost doable, except for the floppy drive. Without a working floppy drive (or equivalent), the Mac clone would do nothing but boot up to the screen showing a disk with a question mark (remember that one?), or the “sad Mac” screen. If there’s no floppy, then there’s no Mac clone, end of story. But there’s also no simple way I can see to build and test a Mac clone floppy subsystem in isolation, without all the rest of the pieces present first. It appears that the only realistic path is to build everything at once, and hope the floppy problem can be solved, otherwise the rest of it will be useless. That’s not very appealing.
If any readers are familiar with the classic Mac’s floppy driver or floppy disk API, I’d appreciate hearing from you. Likewise I’d be thrilled to hear from anyone who can think of another clever way to build a working classic Mac clone without a floppy interface.
Read 16 comments and join the conversation16 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
This sounds like a great project! Now, I don’t know if this is technically accurate, but I was told (many years ago when MacOS still ran on a 68000) that Mac never switched from supervisor mode into user mode when running apps. So, potentially any app could access the IWM hardware directly, just like on 8-bit machines. I was told that Apple was in too much of a hurry to implement a proper user/supervisor mode switch in the OS! If that’s right, then you’d run into compatibility problems if you decide to modify the ROM routines, at least for some app software.
Yet another awesome project!
I don’t know if you are aware of this, but Western Design Center makes a plug in replacement for the 6522 VIA: http://www.westerndesigncenter.com/wdc/w65c22-chip.cfm
Didn’t the Mac 512K have a hard disk available? I think I remember that it plugged into a SCSI interface on the back, though it’s possible that the SCSI port was added with the Mac Plus. In any case, a HD might be easier to emulate. I wonder if a Mac would boot with no floppy (or no IWM!) and a hard disk?
@John – I think you’re right about always running in supervisor mode. But either way, what kind of compatibility problems would you imagine seeing? Any modified ROM routines I created would run in the same mode as the original floppy interface routines, subject to the same restrictions.
@Josh – That’s amazing the 6522 is still for sale! I don’t think I’d use one though, since I wouldn’t be connecting to real vintage peripherals, I wouldn’t need to use the actual VIA from the Mac. Instead, I’d likely use a microcontroller or FPGA that responds to memory accesses at the VIA’s address, and responds to the CPU the way the VIA did, while doing something completely different underneath (talking to a PS/2 keyboard/mouse for example).
@Stephen – I believe the HD20 was introduced with the Mac Plus, which was the first to have a SCSI port. I could attempt to clone a Plus instead of a 128K, since they’re very similar: I think the only difference was the ROM and the SCSI hardware. Simulating a SCSI connection likely wouldn’t be easy, but might be better than simulating a floppy disk. I’d still rather clone the 128K (or 512K) if I can though, instead of the Plus. Since the 128K was the first, it would earn more retro geek points!
The 512k didn’t have a SCSI interface, however, there was a HD available for it, the HD20 ( http://en.wikipedia.org/wiki/Hard_Disk_20 ). It connected through the external floppy connector.
Steve, have you considered just using a real mac floppy drive? Or, alternatively, you could move up a step and make a plus? Ancient slow SCSI might be a lot easier to fake than weird manually controlled single-sided floppy drive emulation.
@Toren – You’re right! I didn’t realize the HD20 was not a SCSI disk. From the Wikipedia article, the Mac 128K and 512K could not boot directly from the HD20, but instead required booting from a floppy first. The 512Ke was the first to have the necessary code in ROM, enabling it to boot directly from the HD20 without a floppy. So assuming the interface to the HD20 is documented somewhere, it might be possible to build a 512Ke clone with a simulated HD20, and skip the floppy disk. It might be simpler to aim for the Plus and a standard SCSI disk, however.
Didn’t the ADB (Apple Desktop Bus) come into existence slightly later, i.e. didn’t the early Macs use a different keyboard/mouse bus?
How about putting an 8051 (SiLabs has some very nice ones) or a small FPGA into the system to emulate the floppy hardware? You might even be able to get away with halting the rest of the system temporarily while the 8051/FPGA calculates. Or you can prepare a RAM buffer with faked transitions that can be read out at normal speed and which can be prepared one sector at a time, which you can hide in the seek latency. You can probably also prepare a set of handy samples for what track seeks look like, sector seeks, read errors, etc.
The Mac is a nice design and Burrell Smith is one of my heros because of it. I believe the sound buffer /is/ part of the frame buffer: it is simply the last/first byte of every scan line. And I believe the scanout does double duty as DRAM refresh, just as in the Apple II. That’s how I remember it, anyhow.
When I read up on the Mac a couple of years ago there was also web sites about South American clones which you may find useful.
For 512×342 you’d be better simulating a 1024×768 image and just double the horizontal and vertical resolution; then you don’t have to worry about blanking out the various horizontal sections.
Wow, I don’t know how I overlooked the fact that 512×342 is half of 1024×768!
Yes, using some kind of microcontroller or FPGA to emulate the floppy hardware is the first path I considered. Maybe I’m overestimating how difficult that would be, but I’m guessing it would be very difficult. I assume I would have to reverse-engineer the both the physical and logical layout of an 800K disk in order to accurately reproduce those flux transitions. If anyone has pointers on how to take a disk image from the web, and use it to generate fake track-by-track floppy read head data, I’d be very interested to hear. But since none of the Mac emulators I’m aware of actually emulate the floppy drive hardware, I’m assuming it’s a very challenging task.
You could look at an Apple 2 emulator. I’m pretty sure that the floppy controller is very similar between the two, and there are plenty of Apple 2 emulators that emulate the floppy drive given just a disk image.
I was going to suggest picking up a copy of “Guide to the Macintosh Family Hardware”, but it seems to have gotten rather pricey. It does document the pre-ADB keyboard interface & protocol.
As to the floppy interface, my understanding is that the software converts between 3 logical data bytes and 4 GCR bytes, and the IWM has a shift register to (de)serialize with the drive the GCR data a byte at time (although the IWM documentation confusingly refers to this as an “8 bit nibble”).
The source of the 1 Hz interrupt is a custom RTC chip that also holds a 4 byte seconds counter and 20 bytes of nonvolatile configuration data. It uses a synchronous serial interface to the VIA; I don’t have any info on the protocol used.
Looking forward to watching another exciting project!
I think the tough part will be that any deviation in your clone compared to the original hardware might confuse the ROM I/O routines. Theoretically, you could rewrite the I/O routines so that they talk to your modified hardware, but most versions of Mac OS will replace the ROM routines – undoing your fixes. But I think it would be really time-consuming to reverse-engineer the ROM and rewrite those I/O routines. The code itself would not be too hard to write, but deciphering the system so you know where to fit in the new code would be the big challenge
Woah, what’s this about IWM documentation now?? That would be superb. The only references I’ve found are from Inside Macintosh Vol 3, and while they discuss how to read and write IWM registers, they don’t really explain how to read/write data to the disk. Two of the IWM registers are described as “instantaneous data from the disk head”, but that’s all.
The major questions I have:
– Does the system software read data from the disk one bit at a time, or one byte at a time? And how? An example would be great.
– Is the data that’s read the actual disk data (what you’d find in a disk image), or some kind of flux encoding?
– Since the drive can only be instructed which track to read, how does the software read from a specific sector in that track?
– How are the tag and data bytes in each sector organized?
The alternative approach of replacing the ROM’s floppy routines instead of emulating the floppy hardware might be easier. After reading Inside Macintosh Vol 2 about the Disk Driver and device drivers in general, the interface looks like it might not be too bad to implement for some more modern storage device. However, it would require me to write a device driver for a 25 year-old OS in an assembly language I’m not very familiar with, using tools I don’t have. It also might create compatibility problems if newer versions of the Mac OS contain updated drivers that patch or replace the ROM ones. Emulating the floppy hardware would definitely be the preferred path, if I can pull it off.
Edit: Brian raised virtually the same concern while I was typing this.
From the Mini vMac documentation: “Mini vMac does not emulate the floppy drive hardware but instead patches the ROM with a replacement disk driver”
The fact that this works implies that the system software does not patch the floppy driver that’s in ROM. Hmmm…
Here’s a good online source. Among other things, it has information on the communications with the keyboard and the RTC as well as using the IWM to do mundane things with the drive (i.e. eject a disk, step the head in/out, check the write-protect tab):
http://www.mac.linux-m68k.org/devel/plushw.php
Lots of documentation on the IWM here:
http://brutaldeluxe.fr/documentation/iwm.html
When writing data to the disk, the CPU writes an 8-bit value to the IWM, but only 69 of the 256 possible values are allowed. Of the 69, 64 are used to encode data and the others are either used as special sync markers or left unused. So the software takes a sector’s worth of data, chops it up into a sequence of 6 bit “nibbles”, and sends the 8-bit code associated with each 6-bit value (via a table look-up). Reading data is the reverse process, looking up 8-bit codes from the IWM to get 6 bits of logical data that is concatenated until you have a whole sector read.
Although it’s for the IWM’s predecessor hardware in the Apple II, a good explanation of how this goes together can be found in chapter 3 of “Beneath Apple Dos”: http://www.scribd.com/doc/200679/Beneath-Apple-DOS-By-Don-Worth-and-Pieter-Lechner
“Wow, I don’t know how I overlooked the fact that 512×342 is half of 1024×768!”
Oops, it isn’t. 342 * 2 = 684, so a pixel-doubled Mac screen on a 1024×768 display would still have black bands at the top and bottom.
There are going to be some problems with the horizontal scan rate. Even with pixel doubling or letter-boxing, the video hardware is going to need pixel data faster than the original Mac did. And since the pixel clock and CPU clock are closely related, that may cause problems.