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.