Hi everyone. I’ve got another nearly finished project here. This one almost done! I have boards in hand and they have been working in the lab for almost 6 months. I need some testers who have a variety of Apple II family machines to test the cards out on.
For those who don't know, "Slinky" or "RamFactor" RAM is a large memory expansion card standard for the Apple II family that presents itself by default as a RAM disk. This card can provide up to 8 MB (actually 16 but there is a bit of a caveat) of Slinky/RamFactor RAM. We call it the GR8RAM ("great RAM"), in reference to the 8 MB of RAM, a rather capacious amount on an Apple II. (The name came about as one of many in a series of puns about product names and RAM capacity but it stuck...)
Anyone interested in testing? Slinky RAM is particularly applicable to the //e but I’m looking for users who have at least one of all three generations of the Apple II: ][+, //e, and IIgs. Unlike the Mac Classic RAM card I posted about, these are all assembled so no need to put it together. I’m hoping the testers for this card can sort of put it through its paces in multiple machines running multiple apps, particularly in AppleWorks (maybe the most demanding client of Slinky RAM) but also as a RAM disk. Also to test you’ll need a PC capable of running Windows XP through 10 (not sure about 11) in order to run the programmer software required to update the controller CPLD on the card if necessary.
Board photo (not a rendering!):
Source is available on the Garrett’s Workshop GitHub under the usual dual commercial/noncommercial license. Card will be for sale once I'm done with testing. Price will be $45 including shipping to anywhere in the United States.
How it works
There are basically two parts to a Slinky/RamFactor-type RAM. First there is the driver ROM that makes the card look like a ProDOS RAM disk. Second and most importantly is the RAM interface itself, accessible through the 4-register address low/med/high/data interface. You write addresses into the three address registers (totaling 24 bits, i.e. 16 MB) and then you can read or write the data register to perform a read/write access to that address. After any access to the data register, the address register is automatically incremented by the RAM card.
The driver ROM is implemented with a “ROM-in-RAM” architecture. We have 32MB of RAM onboard for just an 8 MB (16 MB experimental mode) RAM card. Some of the extra RAM is reserved for storing the ROM. The ROM is stored in an SPI flash memory. At boot, the contents of ROM are copied into RAM and accessed from there. Of course, the “ROM RAM” is effectively read-only so there’s no functional difference between the ROM-in-RAM architecture and a regular Slinky/RamFactor card with a real parallel ROM.
The RAM controller doesn’t run at 7.159 MHz Apple II bus speed; too slow to get the SDRAM access completed in time to return data to the 6502. Instead we have a 25 MHz crystal oscillator on the board which provides the SDRAM clock. The card synchronizes the start/end of PHI0 cycles to the SDRAM clock. Once a PHI0 cycle has started, the controller checks the /DEVSEL, /IOSEL, and /IOSTRB lines to see if a ROM (in RAM) or RAM access is being requested. If so, the correct sequence of ACT, RD/WR, NOP, PC commands are issued to the SDRAM. Write data is sent from the Apple II data bus asynchronously to the SDRAM data bus. On the other hand, read data from the RAM is registered into the CPLD for transmission back to the Apple so that the SDRAM banks can be precharged and the SDRAM placed into clock disable to save power, rather than the SDRAM holding the output data for the slow Apple by inhibiting the clock before precharge.
There’s plenty of extra space in the ROM-in-RAM flash so what would be amazing is if the contents in RAM could be pre-loaded from flash on power-up. (Could add another DIP switch for this.) Unfortunately the CPLD is completely full and there’s no room to implement this feature. I think more than 230 of the 240 logic elements in the CPLD are used and I have not had success so far paring down the design. Slinky RAM requires a large 24-bit address counter that gets incremented after every RAM access and this takes a bunch of logic elements. It would be awesome to be able to load a disk image into RAM right at boot so I will continue to ponder ideas about how to reduce the logic footprint of the design.
Why is 16 MB considered experimental? Not for hardware reasons; the hardware is stable in my machines and there’s nothing profound about the 16 MB mode. It’s just that software was never really written for RamFactor cards so large. I have seen some programs use the high bit of a 24-bit address to store some information so they tend not to work right with more than 8 MB of RAMFactor/Slinky RAM.
For those who don't know, "Slinky" or "RamFactor" RAM is a large memory expansion card standard for the Apple II family that presents itself by default as a RAM disk. This card can provide up to 8 MB (actually 16 but there is a bit of a caveat) of Slinky/RamFactor RAM. We call it the GR8RAM ("great RAM"), in reference to the 8 MB of RAM, a rather capacious amount on an Apple II. (The name came about as one of many in a series of puns about product names and RAM capacity but it stuck...)
Anyone interested in testing? Slinky RAM is particularly applicable to the //e but I’m looking for users who have at least one of all three generations of the Apple II: ][+, //e, and IIgs. Unlike the Mac Classic RAM card I posted about, these are all assembled so no need to put it together. I’m hoping the testers for this card can sort of put it through its paces in multiple machines running multiple apps, particularly in AppleWorks (maybe the most demanding client of Slinky RAM) but also as a RAM disk. Also to test you’ll need a PC capable of running Windows XP through 10 (not sure about 11) in order to run the programmer software required to update the controller CPLD on the card if necessary.
Board photo (not a rendering!):
Source is available on the Garrett’s Workshop GitHub under the usual dual commercial/noncommercial license. Card will be for sale once I'm done with testing. Price will be $45 including shipping to anywhere in the United States.
How it works
There are basically two parts to a Slinky/RamFactor-type RAM. First there is the driver ROM that makes the card look like a ProDOS RAM disk. Second and most importantly is the RAM interface itself, accessible through the 4-register address low/med/high/data interface. You write addresses into the three address registers (totaling 24 bits, i.e. 16 MB) and then you can read or write the data register to perform a read/write access to that address. After any access to the data register, the address register is automatically incremented by the RAM card.
The driver ROM is implemented with a “ROM-in-RAM” architecture. We have 32MB of RAM onboard for just an 8 MB (16 MB experimental mode) RAM card. Some of the extra RAM is reserved for storing the ROM. The ROM is stored in an SPI flash memory. At boot, the contents of ROM are copied into RAM and accessed from there. Of course, the “ROM RAM” is effectively read-only so there’s no functional difference between the ROM-in-RAM architecture and a regular Slinky/RamFactor card with a real parallel ROM.
The RAM controller doesn’t run at 7.159 MHz Apple II bus speed; too slow to get the SDRAM access completed in time to return data to the 6502. Instead we have a 25 MHz crystal oscillator on the board which provides the SDRAM clock. The card synchronizes the start/end of PHI0 cycles to the SDRAM clock. Once a PHI0 cycle has started, the controller checks the /DEVSEL, /IOSEL, and /IOSTRB lines to see if a ROM (in RAM) or RAM access is being requested. If so, the correct sequence of ACT, RD/WR, NOP, PC commands are issued to the SDRAM. Write data is sent from the Apple II data bus asynchronously to the SDRAM data bus. On the other hand, read data from the RAM is registered into the CPLD for transmission back to the Apple so that the SDRAM banks can be precharged and the SDRAM placed into clock disable to save power, rather than the SDRAM holding the output data for the slow Apple by inhibiting the clock before precharge.
There’s plenty of extra space in the ROM-in-RAM flash so what would be amazing is if the contents in RAM could be pre-loaded from flash on power-up. (Could add another DIP switch for this.) Unfortunately the CPLD is completely full and there’s no room to implement this feature. I think more than 230 of the 240 logic elements in the CPLD are used and I have not had success so far paring down the design. Slinky RAM requires a large 24-bit address counter that gets incremented after every RAM access and this takes a bunch of logic elements. It would be awesome to be able to load a disk image into RAM right at boot so I will continue to ponder ideas about how to reduce the logic footprint of the design.
Why is 16 MB considered experimental? Not for hardware reasons; the hardware is stable in my machines and there’s nothing profound about the 16 MB mode. It’s just that software was never really written for RamFactor cards so large. I have seen some programs use the high bit of a 24-bit address to store some information so they tend not to work right with more than 8 MB of RAMFactor/Slinky RAM.
Last edited:
