The Apple-1 and OSI Superboard / Challenger emulators don't need a lot of RAM and ROM memory. For those projects, the Memory cog module (see the project details) does its task just fine to map a ROM image into the 6502's address space, and let the 6502 (effectively) read and write the Propeller hub memory as if it's real RAM.

But the Propeller only has 32KB of hub memory, and for some (future) projects, that simply might not be enough, and it will be necessary to put some real memory in the system.

I designed the L-Star Plus as a kit that includes an SRAM chip to take care of this problem. The chip is a 128KB Alliance Memory AS6C1008-55PCN. Why 128KB you might ask, if the 6502 only has 64KB of address space? Well, as it turns out, there is no 64KB SRAM chip, at least not one in a DIP package, with 16 address lines and 8 data lines, and 3.3V compatibility. So I had to use a 128KB chip instead. First world problems!

The lowest 16 address lines of the SRAM are connected to the 6502 address bus, and the data lines are connected to the data bus. The highest address bus pin (A16) was grounded in the Rev.1 PCB design, but is available on the jumper block on the L-Star Plus in the Rev.2 design.

That means that the Propeller can be connected to the SRAM chip's Chip-Enable-Not pin (~CE) to put the chip on the data bus when needed. All that's needed is a new software module that I wrote last week, called SRAMctrl. This module builds a literal bitmap of which addresses in the 6502 address bus should be mapped into the SRAM chip. Then, on each 6502 clock cycle, it checks the bit in cog memory that represents the address that the 6502 requests, and, if necessary, activates the SRAM chip's Chip Enable line.

The bitmap actually consists of two tables that seamlessly work together. The R/~W line of the 6502 address bus is used as an extra address line when an index into the table is calculated (it's not a coincidence that the R/~W line is connected to the P24 pin of the Propeller, adjacent to P23 where address bus line A15 is connected). That way, reads and writes can be controlled separately and it's possible to create read-only memory areas in the SRAM chip. For some future large projects, this may make it possible to let the Propeller initialize the RAM with a ROM image file, and then let the 6502 boot from the SRAM. See if you can do that in an ordinary 6502 system (tip: you can't).

It would be nice if each address on the 6502 address bus were represented by one bit in the table, but this would be difficult. The table wouldn't fit in a cog, so I would have to e.g. let two or more cogs work together or retrieve data from the hub. Using two or more cogs just to turn an SRAM chip on or off is not very efficient, and putting the data in the hub is a non-starter because it takes quite a few Assembly instructions to generate the index into the table, shift the bit out from the long-word entry. If I would have to add a hub access instruction to that, there just wouldn't be enough time in a 6502 clock cycle to get everything done.

So the compromise is that (for now), each bit in the table represents 16 bytes in 6502 address space: the first bit represents addresses $0000 to $000F, the second bit represents $0010 to $001F etc. For most uses, this should be more than adequate. A future version of the SRAM control cog could be made to support a one-in-8 resolution instead of the current one-in-16 resolution, by eliminating the separate handling of reads and writes.

Another compromise is that if you want to use the SRAM chip in your Software Defined Computer, you'll have to either give up the monochrome 1-pin video output, or you'll have to switch from the full PS/2 keyboard driver to the 1-pin keyboard driver (by Ray Rodrick a.k.a. Cluso99 on the Parallax forums) which doesn't need the keyboard clock input. For now, that also means that you'll have to ask the user to push the space bar on the PS/2 keyboard to measure the keyboard-specific clock speed. But I'm thinking it should be possible to do away with that, with some smart programming.

The SRAM control cog is in a module called SRAMctrl.spin in the new Apple1SRAM project. The code in that project activates the SRAM for the entire low 32K memory area which is also present in Vince Briel's Replica 1. It doesn't use the memory cog to emulate any RAM, only ROM. The 32K of available RAM is nice, because now there's no need to patch the Krusader program in the emulated ROM (it's kinda hard coded to expect that the system has 32K). It's trivial to make the amount of SRAM even larger, but instead of mapping more SRAM into memory, I wonder if maybe I could emulate the CFFA1, or the Apple 1 cassette interface using the Propeller. That would make L-Star into a Replica 1 Replica! :-)