Last night we spend atleast 3 hours to track down a little bug in the cpu fuse settings. After running first tests on the hardware we got debug uart and some basic sreg addressing working.
Then we started to implement a sram read/write round trip. We found out that we read for all sram cells the same value as the last value which was written. So we stepped through the schematics and traced all IO lines and logic involved in the sram addressing process. First we analysed the sreg setup and the address counters. Then we checked the busdriver and the sram multiplexer. But this looked all out. Finally we found the problm that the WR line from the AVR to the sram is not pulled high when set in software.
So we looked for shortcircuits but didn’t find anything. Last guess was the mcu is broken, but finally we found out that we had a false fuse setting. So our IO pin was configured to passthru the clock signal on that pin. Fixed that and so basic sram read/write is working.
Tonite we gonna test bulk transfer. Hopefully this time we don’t have so nasty bugs.
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](http://sneshack.blogspot.com) 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.