Plus Too: a DIY Mac clone project (128k -> Plus)

[Bunsen]

Conceptual stage right now, but he seems to know what he's about - and he has form for getting crazy stuff built and working.

Plus Too

Inspired by projects like the Replica 1, Minimig, and C-One, the goal is to build a functionally identical copy of the original Mac, but using modern hardware parts. Such a system would be a true hardware clone rather than an emulator.

Of particular note:

A side note: There seems to be significant interest in the vintage Mac community in an external floppy drive replica that can work with a real Mac. While this project won’t address that need, it may provide some knowledge and expertise that could be used to help reach that goal.

[jongleur]

This one is definitely worth following and supporting. As much as I love playing with my 512, I would much prefer to muck around on a PlusToo day to day. Emulators are OK, but a PlusToo in the case of a dearly departed would be ideal.

[dougg3]

I remember when this same guy made his own CPU + computer from scratch using a ton of wires and chips (the "crazy stuff" Bunsen linked to). That was incredible! I can't wait to see what he ends up with on this new project!

[techknight]

i could see him succeeding.

But you need to emulate all those PAL/GAL ICs. thats the trick. not hard, just time consuming. I am more interested in the floppy emulation than anything, I dont understand enough about what data goes in and out of a drive to be able to write something up that works. I know how the drive works, but i never monitored what data goes in and out of a drive?

I know the IWM/Drive work hand-in-hand to produce valid bytes from requested sectors on the bus. So if you could study the mac driver on what data goes in and out of the IWM, you could use a logic analyzer to read the data going in and out of the IWM from a particular disk. Then read the raw sectors of the disk from a binary disk image, so you could compare this with your results you got on the logic analyser, and figuring out the IWM protocol on the head-end wouldnt be too difficult. I just never had the initiative to drive toward that, and i dont have a logic analyzer. lol.

In other words, you could study how the driver talks to the IWM, selecting heads, reading/writing sectors, etc... Then you could just patch the driver for a drive "2" So drive 0, and drive 1 would still work, but drive "2" is trapped by your custom hardware so it thinks its talking to drive 2 on a real IWM, but its not. its only emulating the IWM commandset/protocol, while the real IWM works with drive 0 or 1.

or you could just replace the IWM completely and do away with the floppy drives totally and emulate protocols for drive 0 and 1.

Or, patch the driver, rebuild the ROM and use your own protocol system, but thats the hostile approach. Or you could replace the IWM with a SWIM in a mac plus, and patch the ROM with the new SWIM driver. (borrowed from an SE) and bring a superdrive to a mac plus.

[bigmessowires]

Hi!

> or you could just replace the IWM completely and do away with the floppy drives totally and emulate protocols for drive 0 and 1.

Yup, that's my plan. The Plus Too hardware should act like an IWM with a pair of floppy drives connected to it, so reading/writing from memory-mapped IWM registers should produce the same results as on a real Mac. But behind the scenes, instead of the IWM and floppy drives there will be some combination of an FPGA, microcontroller, and SD card.

Replicating the IWM's behavior shouldn't be too difficult, I hope. The hardware can keep track of which floppy track is currently selected, by watching for track step commands sent to the IWM. The bigger challenge will be replicating the byte-by-byte data stream that the IWM returns when reading a track on the floppy.

I believe the data is a circular buffer consisting of all the sectors in that track. A read might start anywhere in that buffer. The IWM will keep returning bytes from that buffer, looping back to its beginning if necessary, as long as the CPU continues to poll the IWM read register.

The buffer will contain about 10 sectors (exact number depends on which track due to the changing drive RPM). Sectors in the buffer are separated by a large but indeterminate number of FF bytes. A special 3-byte signature D5AA96 marks the start of a sector. The format of the sector contents is documented in the MESS source code file ap_dsk35.c, and also in the book Beneath Apple DOS. The sector data is encoded using GCR, where every six bits of "real data" is encoded into an eight bit byte on the disk. The hardware will need to do on-the-fly GCR encoding of a portion of a DiskCopy 4.2 image, then the Mac OS will decode it normally just like a real floppy disk read.

It hopefully won't be necessary to disassemble the floppy driver code or use a logic analyzer, since the necessary details are already documented. But as a last resort, the answers could certainly be found that way.

It sounds doable in principle, but I'm sure the devil is in the details! If anyone's attempted something like this before or is familiar with the low-level 400K/800K floppy format, I'd love to hear from you. I'm just kind of faking this as I go along, making educated guesses about implementation details based on the incomplete information that's available.

[techknight]

how would the byte-by-byte be difficult? Just a question because maybe im seeing something differently or wrong. lol.

All you need is to put the sector information into RAM. Not sure what the sector sizes are on a floppy diskette, but standard HDD its 512bytes? So you could just buffer the 512byte request from the SD card into RAM inside an array. and your IWM emu subroutine will pull the bytes out of the array when requested. problem solved Just need to keep track of an index register, and the index register is calculated upon depending on the data stored in the IWM emulated registers. I will say that i know zip about an FPGA, so i cant speak for how to do it in there. But thats how i would do that in an MCU.

As far as a circular buffer, it could be. I havent studied the IWM. But maybe its not? maybe the IWM has its own RAM? but yes when the head does an advance it starts wherever in the track, but its the job of the IWM to be able to look at the start/stop markers and stuff (GCR) stored on the diskette, to streighten out the data and buffer it into the IWM, so it looks like a real datablock, kind of like what you would get from an SD card or logical HDD. to be fetched by the driver? I could be all wrong about this. but thats my guess. I doubt the IWM has RAM, so im sure the driver has to pick apart the sector formatting, but as i said, i have not studied it extensively.

I breifed over the IWM documentation, its a state-machine device, so all you need to do is emulate the state machine...
or practice with the real IWM or real drive and see what data comes out, compare against a valid diskimage. Easy way to learn the state machine.

problem is, its the "back-end" the IWM docs dont talk about. (the floppy drive to IWM)

[Bunsen]

Greetings, bigmessowires! I'm glad to see you noticed the pingback and dropped in to say hello. Here's hoping the good folks of the MLA can be of assistance

[trag]

I don't know if it is any help, but Outbound (the Macintosh Laptop clone company from the 80s/90s, managed to implement the SWIM functionality using a WD37C65, a WD92C32, a 28C64 EEPROM, and a Xicor 9103 digital potentiometer. I think there were a couple of discrete logic chips, like 244s and maybe a few transistors on there too. One of these days, I must trace out a schematic.

Anyway, all that stuff interfaced with a standard old Citizen brand 1.44MB floppy drive (such as a W1D) and provided a Macintosh compatible drive which could read and write 400K and 800K disks as well as the easier 1.44K disks.

The laptop that used this controller board had Plus ROMs inside.

Gah! I almost forgot. There's a GAL on the board. Little 20 pin 16V8 jobber. I would have cloned the floppy controller by now, except I don't know what's in that GAL.

[bigmessowires]

To make a Mac clone with an SD card floppy replacement, I don't think it's necessary to clone the floppy controller perfectly. That should only be necessary if you're trying to make a drop-in IWM or SWIM replacement that works with a real Apple floppy drive. All that's really needed in my case is to clone the controller's CPU-side interface, which is documented in Inside Macintosh Volume 3, as well as the byte-by-byte floppy track data format, which can be inferred from the source code of Mac emulators or a 68K Mac Unix distro. In other words, by cloning the IWM + floppy as a single block, you gain the freedom to change the IWM <-> floppy interface into anything else you'd like.

[techknight]

Ya, you could. And for us with the real macs, you could swap out the SWIM chip with your own little board, and use the original floppy port that hooks to the swim, to interface to an external CF/SD/USB Mass Storage setup.

[Bunsen]

Just out of curiosity, do those Macs that are capable of mounting two floppies contain two SWIMs?

[techknight]

no, not that I have seen.

[bigmessowires]

Working with a Spartan 3A FPGA board right now, and I've finally got some visible progress. I've never been so happy to see a Sad Mac!

A boot failure may not seem exciting, but I'm thrilled that it's actually doing something recognizably Macintosh-like. That means I'm actually running 68000 code from the Mac ROM, which is drawing stuff to the screen buffer, which is getting displayed to the screen. From here it will be a long, slow road of implementing replacements for the VIA, SCC, IWM, and other components.

[trag]

Wow. That's fantastic progress.

What is your setup? Not in detail. But just the components. Is it just a 68000, a Spartan 3A and a set of Mac ROMs?

[bigmessowires]

Right now I'm using the Spartan 3A FPGA starter kit from Xilinx. All the other "hardware" is actually synthesized inside the FPGA: a 68000 soft-CPU (TG68 core from opencores.org), 32K RAM, and 8K ROM. The synthetic RAM/ROM sizes are much too small, but are all that would fit inside the FPGA. They're enough to create a screen buffer and run the initial boot code from ROM, anyway.

I have an Altera DE1 board on the way, which has real external SRAM and Flash ROM that I can use. (The Spartan 3A board has DDR RAM that I could never figure out, and ROM that can only be programmed through a serial port.) I haven't yet decided whether to add a real 68000 to the DE1 on an expansion card, but given how easy it was to get the TG68 soft-CPU working, I'll probably stick with that.

Eventually I'll need to construct an expansion card containing a microcontroller and some other things, but I should be able to get pretty far with just the Altera DE1 board. The DE1 is an "educational" board with all kinds of miscellaneous gizmos. My long-term goal is to make an all-custom Plus Too board that contains only the parts actually needed.

[Gorgonops]

Impressive work.

If I could say *anything* critical, and mind you, it isn't a real criticism, I was sort of vaguely hoping the project might go the other direction (from using an FPGA) and use more old-fashioned through-hole discrete components (IE, a real 68000, a pair of 6522s, etc, etc.) There'd be the problem of duplicating the PALs, of course, and possibly some related issues with component scarcity. (Perhaps the PALs could either be rolled into a CPLD or two, or unrolled into discrete components, although the latter might make for an unwieldy PCB board.)

Using the FPGA is undoubtedly the "right" choice, there's just a certain ring to the idea of making a machine that duplicates the original a little more closely in all its glorious hardware-shortcut-y obscureness in a way that's visible to the naked eye.

[techknight]

well with the JIT soft-core running on the FPGA, you could theoretically clock the hell out of it and make it much faster than the original hardware?

[bigmessowires]

there's just a certain ring to the idea of making a machine that duplicates the original a little more closely in all its glorious hardware-shortcut-y obscureness in a way that's visible to the naked eye.

I have the same feelings, and have gone around in circles in my head a few times on this. But from a practical standpoint, the 68000 is the only part that can be readily sourced today. The IWM, VIA, SCC, PALs, and other goodness need their behaviors reimplemented in an FPGA (or maybe a large CPLD). I suppose you could put each one in a separate FPGA so you could label them, but I'm not that masochistic. It would be cool to use a real 68000, but I've worked through the details and it would increase the necessary FPGA pin count to where I'd likely need two FPGAs, or a whole bunch of extra muxes and bus drivers, so it complicates things. The soft-CPU also makes it a lot easier to debug during initial development.

I'm going to continue with the soft-CPU for now, since it's already there, but may switch back to a real 68000 later once everything is more or less working. There's still lots of room for Mac-specific hardware goodies when I get to building a custom board too. Maybe add connectors for vintage keyboard, mouse, serial, and even floppy if I can find a source for DB-19's!

well with the JIT soft-core running on the FPGA

It's actually not a JITter, but a full-fledged 68000 realized from the "sea of gates" of the FPGA. So there's no emulation or dynamic recompliation involved. It's basically exactly the same as having a real 68000, just internal to the FPGA.

[techknight]

Eh, i guess i just dont quite understand FPGAs yet.

[Gorgonops]

Just to note, the VIAs are still fairly readily available. (And still being made. I have two brand new ones acquired as spares for Commodores.) I was sort of picturing a hybrid approach where parts like the IWM would be replaced by bit-banging microcontrollers but the core of the system is "real".

Again, using an FPGA is more practical for a system of this scale, but it does sort of raise the question of why you need to build hardware at all, instead of "just" writing an alternative core for one of the pre-existing Amiga or Atari ST-in-an-FPGA boards.

[olePigeon]

I'd like to make a recommendation for a followup project: Freescale ColdFire upgrade.

[trag]

Right now I'm using the Spartan 3A FPGA starter kit from Xilinx. All the other "hardware" is actually synthesized inside the FPGA: a 68000 soft-CPU (TG68 core from opencores.org), 32K RAM, and 8K ROM. The synthetic RAM/ROM sizes are much too small, but are all that would fit inside the FPGA.

Heh. If you had the Spartan 3AN Starter Kit, you'd have something like 700K of ROM available on board the FPGA.

Those block RAMs really don't add up to all that much RAM, do they?

If you want to use the DDR2, I would start with the demo that Xilinx has available. I don't know how hard that is to get up and running, but it seems like the logical starting point. Programming your own DDR2 controller would be a ridiculous amount of work.

And on the Starter Kit it's 16 bits wide, so the width is just what it should be. Gonna be a lot of wasted transactions, with the DDR2 insisting on doing 4 word bursts for every transaction though...

Maybe add connectors for vintage keyboard, mouse, serial, and even floppy if I can find a source for DB-19's!

I posted a source in a new thread on this forum.

well with the JIT soft-core running on the FPGA

It's actually not a JITter, but a full-fledged 68000 realized from the "sea of gates" of the FPGA. So there's no emulation or dynamic recompliation involved. It's basically exactly the same as having a real 68000, just internal to the FPGA.

What is "JIT soft-core " and how does it differ from what you implemented.

Did someone run off with the designs from Motorola, or is the FPGA 68000 design reverse engineered from the 68000's behaviour?

[Gorgonops]

What is "JIT soft-core " and how does it differ from what you implemented.

JIT = Just In Time (compilation). It's a method of speeding execution of interpreted languages (and emulators, since one CPU running code for another is broadly the same thing as running an interpreted language) by compiling snippets of code into native equivalents in psuedo-real (just in) time and caching the compiled version for later use when appropriate.

In the context of emulator software the word "core" could refer to the software component that emulates *any* part of the emulated system (like a chipset) but without modifiers usually means the CPU emulator. And many emulators allow the user to choose between several. Modern builds of BasiliskII on x86, for instance, generally have a "JIT core", which itself has several performance-enhancing options that can be turned on and off, alongside a much slower interpretive core which persists as an fallback in case one encounters a bug with the JIT core. (JIT cores are "hard", and tricks like self-modifying code can break them.)

"JIT Soft-Core" is thus meaningless in the context of an FPGA because an FPGA isn't a "CPU" with a native instruction set. It's basically a huge pile of electronic tinkertoys that can be interconnected according to a "meta-code", VHDL or Verilog, that has nothing to do with the normal operation of the chip once it's programmed. (Once the FPGA is programmed it's not "emulating" the chips it's coded for, it in essence *is* the chips.) An FPGA "core" is a collection of code that describes to the FPGA how to connect its tinkertoys to make a working copy of another chip, and for a given CPU or other IC there may be multiple "cores" floating around which incorporate different trade-offs. For instance, one core might uses less gates than another, thus leaving more space on the FPGA for other things, but the tradeoff may be that it can't be clocked as high. Another case may be that for a given CPU there exists a commercially licensed version which is "guaranteed" to perfectly replicate the real thing, unlike a free reverse-engineered open-source version.

[Gorgonops]

Just as a random note, I don't know if it would "help" at all, but apparently you can get a preassembled "MiniMig" board with 2MB of RAM for about $180 US. (4MB is another $30.) That actually looks cheaper than a suitable starter kit and might be a good platform to develop on.

[bigmessowires]

Writing an alternative Mac Plus core for a pre-existing Amiga or Atari ST-in-an-FPGA board would be one way to go, but seems less fun, since I like to build stuff with my hands. Nevertheless I'm starting with this Spartan 3A board (and soon an Altera DE1 board) that's not too different from those Amiga boards, because it's the easiest way to get started. Once things are mostly working there, I plan to create a custom board that eliminates any uneeded parts, adds vintage keyboard/mouse/floppy connectors, and incorporates any daughterboards I made for a microcontroller or other stuff. At that point it would also be possible to extract the 68000 and maybe VIA out of the FPGA, and add them back as real chips for extra style points.

It's basically a huge pile of electronic tinkertoys that can be interconnected according to a "meta-code", VHDL or Verilog, that has nothing to do with the normal operation of the chip once it's programmed. (Once the FPGA is programmed it's not "emulating" the chips it's coded for, it in essence *is* the chips.)

That's a good way of putting it. The Verilog code determines the configuration of 40-bazillion internal interconnections between 20-bazillion primitive logic gates on the FPGA. The configuration data is like a tremendous number of switches, or like the plugboard configuration panel on early computers like Univac. Each switch can either connect two specific wires inside the FPGA, or leave them unconnected. After that, it's the same as if you'd soldered up all those primitive logic gates by hand, and it really *is* the chip described in the Verilog code. This stuff is fascinating, and if you're into digitial electronics, it's like sex on a stick. And to trag's question, I'm pretty certain the TG68 68000 core I got from opencores.org is reverse-engineered from the known behavior of the real 68000.