Finally we found a better name for the snesram and renamed it to ‘QuickDev16 USB’. Final PCB layouts are ready and will be send to china soon. So in about 2 weeks we will have our first PCBs.

Confirmed Features:

  • 16 MBit Sram for Rom storage
  • ATmega644 MCU for housekeeping
  • USB connection for ROM upload
  • ucon64 software compatibel
  • PAL/NTSC CICs are supported
  • Lo/Hirom support
  • Reset trigger from cartridge possible
  • AVR USB Bootloader for quick firmware uploads
  • Snes bootloader intro
  • Snes powered, no power source needed

Stay tuned for more features, especially debugging helpers



Had a big breakthrough yesterday with our Super Nintendo Snesram project. Got for the first time a commercial game running. This was quite a hard one.

Spend a great amount of time debugging the memory uploads routines. I had to add CRC checks to both sides of the hardware. An AVR hosted CRC memory check and SNES hosted CRC check, showed us that our addressing was done correctly. But we found out that no commercial game ran on our hardware. Why that ??? More testing showed that we got a lot of memory corruption while starting a game. First we thought that the bus driver switching ( which was quite lazy implemented) caused the memory corruptions. Fixing that help a little, we could boot Super Mario World. But that would crash right after the start. Finally we found out that we shouldn’t map the WR line of the cartridge to our sram. We always thought the snes uses an unique address space for the rom and save game ram mapping. This might be true for the cpu address space but not for the cartridge address space. So the games constantly wrote to save game ram and destroyed the actual rom content….Fixing that worked out perfectly.

Right now we support up to 4mbit games. But We don’t have any save gave support at all. Also HI ROM support isn’t tested yet. The good thing is, now that we have our poc working we can move on to build an actual pcb. Our main focus will be on homebrew stuff, so running all kinds of commercial game is not our first target. This implies some hardware design decision. We want to go for software usb for the bulk rom upload, and another ftdi based usb for the cpu debugging or even for an control and user interface. Like a little remote login shell to upload roms, peek and poke memory…name it. If we have the board running with usb i see a lot of features coming up. I am not sure if we go for an sd card slot, which in my views is only interesting for gamers.

Also i have to admit that our approach, using an cpu and a static memory addressing mode is limited. The way how Scott is doing this gives him a lot more options to handle the black magic snes rom layouts. Also he will have the option to synthesize DSP and FX chips onto his fpga. So we might see him playing super mario kart on his board 🙂 But i also see an advantage in our design i guess if we make pcb kits they will be suitable to be build by an average hobbyist geek.