Worst case, the driver would be called from an interrupt handler, but I'm not seeing anything particularly problematic.
Yeah--if we needed to call the driver from an interrupt handler, I suppose we could just disable interrupts during any writes to the SIMM to force it to be atomic. Maybe there's a better solution too with the help of the FPGA...I'm not sure.
I'm up for a driver.
Great! Now we just need to find people who are up for PCB design and FPGA programming
It's beyond my current knowledge level. I want to learn (and I have some FPGA dev boards), but I have a lot to learn about it before I'm anywhere near proficient for sure.
But, the tradeoff there is making the access pattern application specific vs. generic and modular.For both size constraints and modularity, would it be reasonable to put the FPGA on the SIMM, and have a connector and separate board for the components the FPGA exposed (microSD/CF/whatever)?
I agree completely and I think it's feasible. The SIMM has to fit within an SE/30 which doesn't have much clearance above the existing SIMM, and it'll be hard to fit extra connectors. It's probably going to be hard enough fitting an FPGA on it. It would be wonderful to make it some kind of generic card that could be reused for tons of different purposes. I agree that the FPGA would have to stay on the SIMM (otherwise there are over 50 wires that would have to go through a cable to the FPGA, not counting ground wires...probably not going to happen, but I'd love to be proven wrong).
On the hardware size limitations/design front, it looks to me like it's time to
just add a microprocessor to your ROM SIMM, DQ. :
Yep -- although I'm not sure a microprocessor is the right choice -- an FPGA is probably the way to go. I suppose a microcontroller could set up an interrupt to occur whenever the output enable/chip select lines toggle to determine when to read/write to the address bus (and when to set the data lines as inputs rather than outputs), but I think an FPGA is more suited for the task. For parts of it that do need a microcontroller, possibly an FPGA paired with a microcontroller or a softcore inside the FPGA could do the trick.
We also have to keep in mind that it's going to be hard to find 5V FPGAs. I think it will require level shifting (and a voltage regulator to generate 3.3V from the 5V), which is definitely possible, but annoying. Also, do we know how much current the power pins in the SIMM socket can supply? Same with all of the data/address pins...we'd have to make sure we're not trying to draw too much from any of them. Considering it was really only designed to power four flash chips, I always have to wonder. Some of these questions make me wonder if one of the other sockets *is* a better idea.
Direct access has the highest potential and can be made to work with ALL Macs, but considering the bottlenecks involved with the cheap massive flash memory we have available, We should at least think about NuBus.
Very true, although we will need to hack the ROM anyway to get it to boot off of such a NuBus card (or does the Mac ROM have a mechanism in place to boot from a NuBus card?)
I really like the idea of a community project as Dennis Nedry pointed out. I don't want to be the only one designing the hardware on this project (and now that we're moving toward more complicated things, I will need help). I'd recommend if we do it this way to use something like KiCad so that everyone has easy access to the PCB files. Like bbraun said, Eagle's usefulness starts to break down as soon as you need bigger boards. I'm not the biggest fan of KiCad, but maybe it's just because I don't fully understand it yet. I remember feeling similar things about Eagle initially too.
In conclusion, I have no idea where to go next
But I think the consensus is that there is definitely a next step to bring high-speed modern storage, among other things, to these Macs. If we can somehow bypass the slow secondary storage mechanisms of the computers of this era (slow SCSI drives) by hooking modern secondary storage mechanisms (CF, SD, SSD, whatever) into a faster primary storage interface, we can really do some cool things, as evidenced by bbraun's ROM disk driver.