BMOW title
floppy emu banner
Border

Happy Mac

Things are starting to warm up now. I’ve successfully booted Plus Too as far as the Happy Mac startup icon! It’s not booting all the way into the Finder yet, but most of the tricky business with the IWM, floppy, and disk encoding schemes has been proven to work. Hooray!

If you can tolerate some shakey-cam video, here’s a movie that demonstrates Plus Too’s current capabilities. It shows booting to the question-mark disk screen, moving the mouse, inserting a blank disk, ejecting a disk, inserting a fragment of a System 3.3 startup disk, and the Happy Mac.

I’ve divided all of Plus Too’s disk-related functions into three parts: IWM, drive, and disk. The IWM is the floppy disk controller chip in the classic Macintosh, and my model of the IWM is finished and working. The Plus Too drive model replicates the brains of a 3.5 inch Sony floppy drive, which has sixteen 1-bit status and control registers. The drive model is mostly done, but there are still a few functions related to disk swapping and disk writing that are incomplete. The disk model replicates the GCR encoded data format of a 3.5 inch Macintosh disk, and is where more work is needed in order to boot to the Finder.

Plus Too is intended to load 400K/800K disk images from an SD card, perform on-the-fly GCR encoding for each sector, and pass the result to the drive model and IWM. That part isn’t working yet, so I took some shortcuts in the test shown in the video. The GCR encoding was done offline with a Windows PC, using a custom program I wrote. Then five sectors of the encoded data were stored in a block ROM inside the FPGA itself. Five sectors isn’t much, but it’s all I had space for, and it’s enough for the Mac to recognize a boot disk and show the Happy Mac icon. Testing the boot sequence this way enabled me to confirm that the GCR encoding algorithm is correct, and that the IWM and drive models are working, even before the SD card interface and on-the-fly encoding module is ready.

Next Steps

The next logical step is to implement an SD card reader interface, so I can load encoded data from the card instead of from the limited FPGA memory. Once that’s done, I should be able to boot all the way to a working Finder. For a read-only system I technically don’t need to do any more than that, but doing the encoding on the fly instead of with an offline tool would be much nicer. To support disk writes, on-the-fly encoding (and decoding) will be a necessity. The encoding and decoding algorithm is somewhat complex, and I’m unsure whether to attempt to design a Verilog state machine to do it, or incorporate a simple microcontroller core (maybe even Tiny CPU) and do it with a conventional program instead.

Other Concerns

There are all kinds of timing problems and glitches hiding just beneath the surface, and I’m worried. Every now and then I’ll make a change that causes Plus Too to exhibit broken behavior or fail to boot, even some innocuous change that definitely doesn’t affect the logic. Just today I made a change that caused an unexplained boot failure, and in the latest version I get random mouse droppings when the mouse is in a certain area of the screen.

Usually if I rearrange some modules or make some other superficial change, the problem will disappear, but that’s a very scary situation. There’s no doubt I need to master the Altera timing constraints editor to sort it all out, but my earlier attempts to make sense of it were dismal failures. Unfortunately, it doesn’t seem to be possible to translate a statement like “external signals D15-D0 must be valid no more than 50ns after the clock edge” into a simple constraint that I can enter somewhere. The whole system seems geared toward me writing custom Tcl scripts, which so far I’ve refused to do. Reading through the documentation, my eyes quickly glaze over and I wonder again why this all has to be so complicated.

A few concerns remain in the drive subsystem as well. With my current test setup, I always return the same five sectors of data, regardless of what track or side is actually being accessed. It’s possible there’s some hidden complexity there that I’ll need to address, or that I’ll incorrectly map disk image data to the wrong sectors, or that the method I’m using to determine what track and sector is being accessed isn’t even valid. This is a fairly small detail, though, and I’m optimistic I’ll be able to extend the current model to support all tracks and sides without major problems.

Read 7 comments and join the conversation 

7 Comments so far

  1. Brad October 4th, 2011 2:19 pm

    This project is looking great so far!

    Is this capable of simulating Mac Classic hardware? Something you could try is that the Mac Classic ROM has Mac OS 6 on it. That would be neat to try out.

  2. Steve October 4th, 2011 9:41 pm

    No, the Mac Classic is a newer machine than the Plus, Mac 512K/e, and Mac 128K. It uses ADB, and a 1.4MB superdrive, and a few other additions. There’s no reason in principle that Plus Too couldn’t be made to replicate that hardware too, but I’m focusing on the simplest Macs for now.

  3. Peter Lund October 6th, 2011 4:50 am

    “There are all kinds of timing problems and glitches hiding just beneath the surface, and I’m worried.”

    Are you sure it’s timing problems in the sense of not being able to switch fast enough or forward signals fast enough? Might it not be due to races and clock domain crossings without proper synchronization?

  4. Dave October 6th, 2011 8:34 am

    Keep up the good work, Steve. It’s fun to watch your progress. Thanks for taking the time to write it up.

    A while ago you talked about using a ps2 mouse and directly writing mac mouse data to memory at the driver level instead of translating ps2 data back to quadrature and implementing the SCC and VIA. Is this how you ended up doing it?

  5. Steve October 6th, 2011 8:37 am

    I don’t know for certain. I doubt its a clock domain problem though– there are only two clocks used in the design, and one is just a divide-by-4 of the other. When the problem once appeared as an almost-working system, I was able to debug it far enough to see that a ROM read from a specific location was returning the wrong value in a single bit.

    I think what’s happening is that ROM access is right on the edge of failing timing constraints. I have a 123ns clock period, with 70ns access time ROM. I don’t know what the clock-to-q delay is for my external address lines and ROM control lines, but if it’s more than 53ns then it clearly won’t work. In practice it would need to be even faster than that in order to also meet the setup time requirements of the registers in the FPGA that will store the data coming back from ROM.

  6. Steve October 6th, 2011 11:35 am

    Thanks Dave. The mouse was implemented at the hardware (VIA and SCC) level, not with the mouse data to memory method I was considering earlier. The mouse logic was taken almost verbatim from Ben Herrenschmidt’s MiniMig-Mac project that I mentioned earlier. Great stuff there.

  7. Joe October 20th, 2011 10:06 pm

    Most people implementing emulated (read: reimplementing) hardware will worry more about the software side than the logic side. Their goal is to make a working system, not an exactly-the-same-working system. Your goal of reimplementing in detail the logic of the original system is kind of neat, though. You can for example, do hardware debugging that the other (hypothetical) reimplementations can’t! A software-compatible system would use the ‘fake I/O’ trick mentioned and just make sure that existing software accepted the data in a good enough manner. This is more stable but sadly, less accurate. There could be some software that can actually fail due to faking the timing of an I/O port.

Leave a reply. Comments may take a few minutes to appear.