Just tossing this out there too:
There is a really skanky technique available that would allow you to map a peripheral into a ROM socket that doesn't "see" write attempts. The idea is that you decode an address that when read, usually multiple times in order to act as a key so a "normal" read cycle doesn't trigger the peripheral inadvertently, unlocks a port for reading or writing. (The old Dallas "No Slot Clock" chips did this, allowing them to reside under a computer's BIOS chip.) Reading happens the usual way, over the data lines at a selected address. (You of course need circuitry to disable the ROM chip which shares the mapping's output.) To *write* a value, one technique I've seen (on a TRS-80 graphics board, I believe...) is to define a range of 256 contiguous addresses and use the location of a *read* inside that range to write the byte.
(The contents of a latch connected to the bottom 8 address lines would be used as the data value. Psuedocode write to such a device would look roughly like this:
WriteByte(WriteVal) {
BaseAddr=0x500100; # arbitrary start address of the block
PrepWrite(); # Call a routine which tells the hardware to expect a byte
WriteAddr=BaseAddr+WriteVal;
return Peek(WriteAddr) ; The return value is unimportant, although in theory you could design the hardware to return a status code.
} # End writebyte
If you want to write 16 bit words then obviously you'll need 64k's worth of contiguous address space for your address/data latch, which might get a little unwieldy.)
Thus, in theory, if you have the ability to churn out custom ROM SIMMs you might with a little work be able to embed the hardware to talk to an SD card or other storage device onto a *very* custom ROM SIMM. If said ROM SIMMs do indeed allow for a whole 8MB addressing range then you could dispense with the need to overlay this hardware over an active portion of the ROM, since no 68k Mac needs more than 1MB. (Well, okay, some of the Powerbooks have more.) Granted I haven't looked at what speed constraints we're looking at here, it may be even less forgiving than the PDS slots.
There is a really skanky technique available that would allow you to map a peripheral into a ROM socket that doesn't "see" write attempts. The idea is that you decode an address that when read, usually multiple times in order to act as a key so a "normal" read cycle doesn't trigger the peripheral inadvertently, unlocks a port for reading or writing. (The old Dallas "No Slot Clock" chips did this, allowing them to reside under a computer's BIOS chip.) Reading happens the usual way, over the data lines at a selected address. (You of course need circuitry to disable the ROM chip which shares the mapping's output.) To *write* a value, one technique I've seen (on a TRS-80 graphics board, I believe...) is to define a range of 256 contiguous addresses and use the location of a *read* inside that range to write the byte.
(The contents of a latch connected to the bottom 8 address lines would be used as the data value. Psuedocode write to such a device would look roughly like this:
WriteByte(WriteVal) {
BaseAddr=0x500100; # arbitrary start address of the block
PrepWrite(); # Call a routine which tells the hardware to expect a byte
WriteAddr=BaseAddr+WriteVal;
return Peek(WriteAddr) ; The return value is unimportant, although in theory you could design the hardware to return a status code.
} # End writebyte
If you want to write 16 bit words then obviously you'll need 64k's worth of contiguous address space for your address/data latch, which might get a little unwieldy.)
Thus, in theory, if you have the ability to churn out custom ROM SIMMs you might with a little work be able to embed the hardware to talk to an SD card or other storage device onto a *very* custom ROM SIMM. If said ROM SIMMs do indeed allow for a whole 8MB addressing range then you could dispense with the need to overlay this hardware over an active portion of the ROM, since no 68k Mac needs more than 1MB. (Well, okay, some of the Powerbooks have more.) Granted I haven't looked at what speed constraints we're looking at here, it may be even less forgiving than the PDS slots.