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:
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Plus Too: a DIY Mac clone project (128k -> Plus)
- Thread starter Bunsen
- Start date
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.
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.
no, not that I have seen.
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.
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?
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.
Eh, i guess i just dont quite understand FPGAs yet.
