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

And some pictures of the OR gate hack:

Now its time to work on the software side. Stay tuned.

So we investigated this. We went thru all logic step involving setting up our hardware. Double checked all IO Ports and Input/Output behaviour. Re-wrote all our setup routines and switching functions, like Lo/Hi rom switching and bus driver switching. Did memory pattern checking from the AVR and the SNES side. Added extra delays to critical area and double checked all IO line on the board. And guess what. Still the same problem. Nearly everything crashes.

So here are the news, we figured out as soon as a rom start music its crashes. So all homebrew stuff without SPC stuff works fine. But can’t get any homebrew or commerical stuff running thats uses sound. I don’t have any deep knowledge about the sound sub system of the SNES. I only know its co-processor called SPC, it gets his IPL from the SNES and it has to be setup with code/music via a dedicated 8bit data port. So i assume there is no direct rom access from the SPC to the cartridge. So why is his a problem on our prototype board. We never had this kind of problem with the proof of concept board.

Last options we are thinking are: We either have a problem with the SRAM timings, since we use faster SRAM on the prototype board. The proof of concept board used 70ns SRAMs, now we are running 50ns. Or the capacitors on the SRAMs are to small. I would appreciate if anybody reading this have experienced same problems or knows what causing this problem could leave me a comment or contact me on #snesdev.

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.

On the bottom side you have a socket for the cic-lockout chip and the rest of the bus transceivers to connect or disconnect the snes. In the lower half you have shift registers to preset a certain adress to the adress counters. These counters are connected to the ram via bus transceivers, so you can access large memory with only a few io-pins on the mcu side. The red block is a demultiplexer to distribute the 22bit adresses to the 19 bit adresses of the ram ics.

I think the PCB looks really good and iam looking forward to power it up soon…

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.

After testing Mario Kart i got pissed off the Wii Controllers. You are supposed to use them in the same manner as in Wii Mario Kart. Steer with Up and Down button and accel with the [1] Button. But no R and L buttons. Without them Mario Kart is no fun. After a quick internet research i found a project to connect and orginal Super Nintendo controller via the Gamecube connectors to the Wii. Its a little more complicated than a simple piggy tail, since the protocol used by the Gamecube and Super Nintendo are totally different.The Gamecube uses a more complex protocol so that you need a microcontroller to do the conversion. Yesterday was DIY sunday, soa friend and me threw this thing together. And it works really good. My friend got so hooked, so he is planing to make some more of the controllers and put them on ebay.