Thread
Plus Too: a DIY Mac clone project (128k -> Plus)
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
Plus Too
Of particular note:
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.
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.
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.
> 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.
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)
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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...
I posted a source in a new thread on this forum.
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?
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.
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.
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.
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.
Somehow I don't think it would be a good idea to do a Google image search for "sex on a stick". ;^)
FPGAs are incredibly fascinating to me, but I'll freely admit I'm far too stupid to work with one. My eyes are starting to glaze over a little bit just trying to draw a decent schematic for an idea for a clip-on MMU/memory expansion add-on for a Commodore PET, and that would only require about eight chips.
Random link:
Don't know if it'd be useful since it sounds like you're using Verilog instead of FHDL, but... here's a source for a 6522 core:
http://www.fpgaarcade.com/vic20_main.htm
Don't know if it'd be useful since it sounds like you're using Verilog instead of FHDL, but... here's a source for a 6522 core:
http://www.fpgaarcade.com/vic20_main.htm
Some more progress-- it's now booting up to the question-mark disk screen, with the mouse cursor in the corner of the screen.
http://www.bigmessowires.com/2011/09/18/question-mark-disk/ if you're interested in more details.
http://www.bigmessowires.com/2011/09/18/question-mark-disk/ if you're interested in more details.
Very cool! 
I was wondering why you're worried about about finding DB-19s and other ancient connectors? :?:
How about using whatever is available currently, whether it's the right pin count or not?
I like the notion of using an ASCII Keyboard interface for one.
I've used a CrapShack M<->F DB-25 jumper unit cut down to DB-15 as a Portrait Converter for a TPD cable, the same ought to be possible if you ever really NEED to hook up a real Mac FDD.
I was wondering why you're worried about about finding DB-19s and other ancient connectors? :?:
How about using whatever is available currently, whether it's the right pin count or not?
I like the notion of using an ASCII Keyboard interface for one.
I've used a CrapShack M<->F DB-25 jumper unit cut down to DB-15 as a Portrait Converter for a TPD cable, the same ought to be possible if you ever really NEED to hook up a real Mac FDD.
you could implement an ADB driver, and use an ADB keyboard/mouse, or use PS/2 keyboard/mouse, but of course either of these solutions requires a translator of some sort, if you implement the keyboard/mouse hardware exactly as laid out originally, unless of course you emulate the side the ROM/CPU wants to see, and the other side use the PS2/ADB protocol.
Fortunately the Mac Plus doesn't use ADB, so the mouse is pretty simple. My plan is to start by simulating mouse interrupts with buttons on the board, just to make sure it's behaving as expected. Then I'll make a PS/2 mouse module in the FPGA that receives mouse data and creates fake mouse interrupts. When I make a custom board later, I'll put a DB-9 on it so you can also connect a real M0100 mouse.
That's awesome bigmessowires. 
And what a coincidence, my classic II is showing that screen again. (It does that occasionally, I think the 230MB Drive is dying.)
Watching your progress on the Plus Too is so inspiring. Makes me think about the kind of things I could try when I learn enough. (As if there's such a thing!)
I'm very excited about college this quarter because I'm taking my first programming course, "Programming Fundamentals." This will be the course's textbook. The only thing I've done with programming so far is read some programming books and maybe compile their examples. But I've never really gotten further than that because for me I need an actual project with a personal goal. (The way I taught myself HTML, JavaScript and currently PHP.) And I haven't come up with any ideas that can work with just the console. (Eg, an APNG editor.)
That's also why I'm eager to teach myself programming on the Classic Macs. You learn to program the interface instantly. No "learn the console, then find a GUI library you like and learn that." I still kinda need to find myself a goal to get started, but I'm researching one idea that looks promising. (Making a basic Stunnel clone, kind of like this.)
Anyway, I'll probably stick to software as my career. But I definitely want to dabble with hardware in the future, like some of the stuff you do.
Keep up the awesome work!
And what a coincidence, my classic II is showing that screen again. (It does that occasionally, I think the 230MB Drive is dying.)Watching your progress on the Plus Too is so inspiring. Makes me think about the kind of things I could try when I learn enough. (As if there's such a thing!)
I'm very excited about college this quarter because I'm taking my first programming course, "Programming Fundamentals." This will be the course's textbook. The only thing I've done with programming so far is read some programming books and maybe compile their examples. But I've never really gotten further than that because for me I need an actual project with a personal goal. (The way I taught myself HTML, JavaScript and currently PHP.) And I haven't come up with any ideas that can work with just the console. (Eg, an APNG editor.)
That's also why I'm eager to teach myself programming on the Classic Macs. You learn to program the interface instantly. No "learn the console, then find a GUI library you like and learn that." I still kinda need to find myself a goal to get started, but I'm researching one idea that looks promising. (Making a basic Stunnel clone, kind of like this.)
Anyway, I'll probably stick to software as my career. But I definitely want to dabble with hardware in the future, like some of the stuff you do.
Keep up the awesome work!
Just as an aside, I've been looking at those projects very seriously because of an idea I've had for a homebrew 6502-based computer, and unfortunately the conclusion I've come to is that while the Propeller works as a glue/peripheral chip like that it's non-trivial to achieve "cycle-accuracy" with it. (A link to add to yours would be the "Propeddle", which is essentially an enhanced version of the 6502 laptop design targeting Commodore PET emulation:
http://www.savagecircuits.com/forums/showthread.php?677-Propeddle-Software-Defined-6502-Computer
) Anyway, if you dig into the "pPropQL" design theory you'll see that, for instance, interfacing the Prop to a 68000 as "memory" requires the insertion of a substantial amount of wait states. The Macintosh OS as written is so timing dependent I don't know if you could really get away with it. (At least if you're attempting to do things like use "real" floppy drives or the serial controller. If you're emulating those devices then dealing with the "clock skew" would probably be doable.)
On the subject of emulating the IWM I'd probably suggest it's sort of pointless to include a 19 pin floppy connector, if only because the original drives are getting so rare. (And troublesome in their old age.) Is the ultimate target of the design to produce a board that's physically compatible with the original PCB, with all the same ports in the same places and allowing the use of all the original parts and peripherals? (Of course, that would either require the ports be carried on a daughterboard or that multiple versions be produced to fit either the 128k/512k and Plus cases, respectively.) I'd worry about the ultimate cost of something like that, as when I last checked the commercial version of the Atari-ST-in-an-FPGA board that includes legacy ports was nearly $600.
:O That's astounding. Congratulations!
A little tidbit of information that may be of interest to you: the Mac Classic (essentially a re-release of the Plus) came with a bootable copy of System 6 in ROM.
That's a good point about the Classic's built-in OS. I actually have a Classic here, but I never tried it. I wonder how it's implemented, and at what level? Like, does the phantom disk appear as a floppy, or a SCSI device? Does it prevent a real floppy/SCSI drive from being used at that address or drive? Does it install a new device driver?
Another interesting discovery: Benjamin Herrenschmidt has already created a mostly-working Mac Plus core for the Amiga Minimig, which is pretty similar to what I'm doing. He invited me to borrow whatever might be useful. Code is at http://git.ozlabs.org/?p=minimigmac.git I’ve been looking at several of his modules to make sure his interpretation of the docs matches mine. I want to avoid outright copying of his design modules though, since then I wouldn’t learn anything, and puzzling things out for myself is most of the fun.
Another interesting discovery: Benjamin Herrenschmidt has already created a mostly-working Mac Plus core for the Amiga Minimig, which is pretty similar to what I'm doing. He invited me to borrow whatever might be useful. Code is at http://git.ozlabs.org/?p=minimigmac.git I’ve been looking at several of his modules to make sure his interpretation of the docs matches mine. I want to avoid outright copying of his design modules though, since then I wouldn’t learn anything, and puzzling things out for myself is most of the fun.
Almost there now! I've conquered most of the IWM and disk encoding puzzles, GCR encoded a few sectors from a startup disk using an offline tool, and stored the encoded sector data in the FPGA's internal memory. Plus Too now boots as far as the Happy Mac icon.
That's as far as it gets, though. After a few seconds, it returns to the question-mark disk screen, because it can't find the System file, because it's not part of the sectors I encoded. The FPGA internal memory is pretty small, and that's all I could fit.
The next step is to build an interface to load data from the SD card, instead of from FPGA memory. Once that's done, I should hopefully be able to boot all the way into the Finder and run programs.
I made a video demo if you want to see it all in action:
That's as far as it gets, though. After a few seconds, it returns to the question-mark disk screen, because it can't find the System file, because it's not part of the sectors I encoded. The FPGA internal memory is pretty small, and that's all I could fit.
The next step is to build an interface to load data from the SD card, instead of from FPGA memory. Once that's done, I should hopefully be able to boot all the way into the Finder and run programs.
I made a video demo if you want to see it all in action:
I love how technology is getting cheap enough that we get to rediscover vintage computing hardware. Between this and the ROM hack, I'm on vintage Mac cloud 9 right now. 
I can't wait to see this project boot a full disk image.
Out of curiosity, how much does the board cost, and would you be willing to sell kits once they're completed?
I can't wait to see this project boot a full disk image.
Out of curiosity, how much does the board cost, and would you be willing to sell kits once they're completed?
Thanks for the kind words. It's getting to the exciting part!
It occurs to me now that I should probably contact Paul Pratt to share what I've learned, or find some other way of preserving and sharing it. Unfortunately I can't publish my commented ROM disassembly for the same reason you can't publish the ROM contents. But I've put a lot of work into reverse-engineering a documenting the purpose of many of the routines in ROM, and it might eventually be of interest or use to someone else, so maybe there's a way I can share it.
The Altera DE1 board that I'm using is $150. It's a great place to start, but isn't perfect for this project. It has only 512K of SRAM, and no way to hook up a mouse and keyboard at the same time. It also has some other components I don't need that just raise the cost. Eventually I hope to create a custom Plus Too board with Mac-specific parts. If there's enough interest, I guess I could sell additional boards or kits, kind of like dougg3's doing with the IIci ROM design. I'm not sure how much they might cost... maybe about the same as the DE1 board.
I used a tool that's part of Mini vMac to disassmble the ROM, which provides a dump of all the CPU instructions in the ROM routines. The tool also adds trap names, some constant names, routine names, and a few comments, all of which I believe were derived by Paul Pratt from his analysis. So for example, most references to the VIA appear using the constant "VIA" instead of the literal address $EFE1FE, and several key routines have meaningful names like P_mBootBeep. That's been a tremendous help, but it still left many huge blocks of hundreds or thousands of instructions whose purpose was totally unknown to me. Most of what I've been doing during the past few weeks is digging slowly through those, trying to reverse engineer the pieces that look relevant to the boot process. As their purpose becomes clearer, I've been adding lots more comments and assigning names to previously unnamed entry points, like P_ShowHappyMac.
It occurs to me now that I should probably contact Paul Pratt to share what I've learned, or find some other way of preserving and sharing it. Unfortunately I can't publish my commented ROM disassembly for the same reason you can't publish the ROM contents. But I've put a lot of work into reverse-engineering a documenting the purpose of many of the routines in ROM, and it might eventually be of interest or use to someone else, so maybe there's a way I can share it.
Nifty! I'm actually a backer of this project on Kickstarter, which is supposed to be for Arduino stuff but it also seems like it would be useful as a cool Xilinx FPGA dev board with VGA and two PS/2 ports. It's also limited to 512K of SRAM, so it's probably not the best choice either, and it's too late to back the project now, but I just thought I'd point it out (I'm sure he's going to be selling more)!
If you ever decide to make a board/kit, count me down as interested in one! I have a Plus, but haven't tried booting it in a long time. I'm almost afraid to try...haha
Oh wow! I did some of that by hand by copying a list of traps from Inside Macintosh and doing a find/replace thing--I think it was in Perl. FDisasm seems like it's a very useful tool, much more powerful than what I was doing! I wish he had versions for some of the later Macs like the later II series...
I don't know if this is useful at all (maybe FDisasm already handles it all), but MPW comes with some Mac ROM maps. The Plus's ROM is one of them. It has a bunch of labels for routines and their addresses. MPW is long gone from Apple's site, but there is a mirror of their old FTP site here.
Oh definitely -- that has to be very tedious to comment all that! I thought commenting the sound code was tedious enough, but you're doing the entire boot process! Yikes! Haha. You're probably right about not being able to share the commented disassembly. That's too bad because it would be a useful thing for people to have, but at the same time, it definitely makes sense that you can't share it since it's Apple's copyrighted code.
It was kind of a pain, but not too bad. The GCR stuff is almost the same as on the Apple II, which is documented in books like Beneath Apple DOS. You can find out the Mac-specific differences by looking at the MESS emulator source code, or just disassembling and reversing portions of the Sony driver from ROM. Info about the sixteen 1-bit registers in the drive is partly covered by inside Macintosh, and the rest again comes from emulators and ROM analysis. The IWM itself is not that complicated, and is pretty-well documented.
Also I think it was easier to create a replacement for the IWM and floppy than it would be to create a replacement floppy that works with a real IWM, because replacing them both means you're mostly freed from worrying about disk read/write timing concerns.
I'm happy to share what I've learned with anyone who's interested, but it's really nothing new, more just a compilation of info from a bunch of scattered sources. And as of today, my function names and comments for the Sony driver in the Mac Plus ROM have been integrated into Paul Pratt's FDisasm fdplus-0.4.0.zip, if you want to check them out.
Anyway, no one should get too excited until I can actually boot this thing into the Finder!
Also I think it was easier to create a replacement for the IWM and floppy than it would be to create a replacement floppy that works with a real IWM, because replacing them both means you're mostly freed from worrying about disk read/write timing concerns.
I'm happy to share what I've learned with anyone who's interested, but it's really nothing new, more just a compilation of info from a bunch of scattered sources. And as of today, my function names and comments for the Sony driver in the Mac Plus ROM have been integrated into Paul Pratt's FDisasm fdplus-0.4.0.zip, if you want to check them out.
Anyway, no one should get too excited until I can actually boot this thing into the Finder!
Breaking news hot off the internet: Plus Too works!!!
I didn't want to tackle SD card loading yet, so the GCR-pre-encoded 800K disk image resides in ROM, just above the Macintosh ROM image. The floppy drive module uses the video module's memory access time slot during hblank periods to load disk data, transparently to the CPU.
Plus Too ran for about five minutes while I took these photos, then it locked up. Not bad for the first boot.
Now, to celebrate with a cold beer!
I didn't want to tackle SD card loading yet, so the GCR-pre-encoded 800K disk image resides in ROM, just above the Macintosh ROM image. The floppy drive module uses the video module's memory access time slot during hblank periods to load disk data, transparently to the CPU.
Plus Too ran for about five minutes while I took these photos, then it locked up. Not bad for the first boot.
Now, to celebrate with a cold beer!
It runs at 8.125 MHz, which was chosen because it's 1/8th of the 65 MHz pixel clock necessary for 1024 x 768 @ 60 Hz VGA video. The real Plus runs at 7.83 MHz, so everything is a little bit too fast.
One strange thing is that loading data from the virtual "floppy disk" is unexpectedly slow. I haven't timed it, but it seems slower than even a real Mac Plus, which is odd because there are no delays here for track-to-track head movements. Or maybe it's the general execution speed of the computer in general that feels slow, I can't be sure. When it's working better, I'll run Speedometer or something on it.
One strange thing is that loading data from the virtual "floppy disk" is unexpectedly slow. I haven't timed it, but it seems slower than even a real Mac Plus, which is odd because there are no delays here for track-to-track head movements. Or maybe it's the general execution speed of the computer in general that feels slow, I can't be sure. When it's working better, I'll run Speedometer or something on it.
I can't imagine why they would be. So far as I'm aware the Plus runs at exactly the same speed as the 128k/512k.
(The SE ran at the same clock speed but changed the video timing to free up more RAM bandwidth, so it's slightly faster. But it didn't debut for another year-and-change.)