To: Michael J. Mahon Michael J. Mahon wrote:
Actually, I'd abandon the "Slinky" interface entirely and use a RAMWorks interface. The bank-switched model is more useful, since it can be directly addressed instead of read through a register. You can run code from an AUX bank, for example. Once you have access to the address bus, you can easily implement the RAMWorks interface, without any impact on slot addresses at all.
Okay I guess thats something to think about.At this point I am guessing that the earlier memory interfaces for the //c were based on that RAMWorks style interface? I will review some of the docs on the earlier ramworks style memory cards. Any thoughts on why Apple moved away from that type of interface when they designed the memory expandable //c?.
This would also mean anyone who had their system setup to expect a //c memory expansion option would have to change everything. Hopefully most software that used extra memory in a //c had drivers to support both memory models.
It's hard to imagine my "laundry list" not fitting easily on a board that could hold a megabyte of 256K DRAMs, and that didn't get in the way of the internal drive. I count an FPGA, a small flash RAM, an SRAM, an SD card socket, a phantom clock "socket", plus a 3.3v regulator and a few level-shifter packages. ;-)
True but my comment about removing the drive was to give an easily accessible place to insert and remove a cf cards without a case mod, not for use as extra circuit space.
Glenn