The code that Propeddle uses to download data into the SRAM chip "behind the 6502's back" as described in the project description, was written over two years ago but never tested. I'm pleased to report that with a few minor bug fixes and improvements, it works now. The latest version of the software that's in Github downloads the test program or Krusader ROM image into the SRAM, and then resets the 65C02 without mapping the ROM areas to the Propeller hub memory (as it did before).
Mapping Hub memory into 6502 memory space using the Hub Cog module was an easy way to get the system up and running, but the ability to download data to the SRAM chip instead is extremely important: With working download code (which is part of the Control Cog), it's no longer necessary to run a Hub Cog, and it's no longer necessary to keep the ROM image in memory while the system is running.
One feature I want to add is the possibility or downloading the SRAM from EEPROM (particularly the part of the EEPROM that isn't used by the Propeller). I kinda prepared for that possibility, but it's not implemented yet.
Another feature I'm planning to implement is reading data from SRAM and storing it into hub RAM or into the EEPROM. This will be trivial to do, and will be essential to emulate external storage devices such as floppy disks.
Storing ROM data into the SRAM chip is enough to make it work, but really there should be a way to keep the 6502 from accidentally overwriting any memory that should be read-only. That's where the RAM Cog module comes in: it starts a cog that monitors the address bus of the 6502 and may block read or write access (or both) to the SRAM chip by making the RAMOE and/or RAMWR lines high.
But I think the next thing that I'll do is finish (or rewrite) the Theory of Operation page on the website, so it explains how this magic download software thingy works.