The software is coming down smoothly. Ported the usb uploader code to ucon64. Also Hirom support ist working now with ucon64 autodedection. So the Snesram board is becoming quite handy for daily dev work.
This hardware revision has 2 bugs which doesn’t make it possible to print pcbs now. There is additional OR gate needed to drive the CS line properly and an AVR reset switch is missing too. I guess when Max is back from his holiday he wants to fix this in the pcb layout. I think
it would be smart to only use 4 sram chips and to have 2mb and not 4mb. Just to reduce the cost and get some more space on the pcb. If there is an interest from the community to support this hardware revision we gonna print some pcbs and sell them. Otherwise we gonna start working on a enhanced version soon.
A video showing the hardware with ucon64 in action…
Yeah, its working. Have been playing Super Mario Word last night. Did a few tests with different roms. Mainly Lorom, type 0 without save game ram. Was able to run games up to 16bmit. Couldn’t find any 32mbit type 0 games to test the complete ram area. Anyways its working finally. What de did? Resolder the cart connector and cleaned the contacts 🙂
And some pictures of the OR gate hack:
Now its time to work on the software side. Stay tuned.
I did some more debugging over the weekend. The thing to investigate was why roms crash or hang when music starts. That was the last suspicion we had on thursday.
So mukunda from #snesdev helped me and made a few test roms to investigate the problem with the SPC. First we started with a simple test to find out that during the SPC boot the system stalls.
So it was verified, that music triggers the problem.
I learned that the system needs to read back $2140 and $2141 to get the SPC status. So where software will wait for $AABB in that registers. I suggested to mukunda to add verbose debug printing on the display to see the register status. Also he added color flashing of the background so see if the snes crashes or just idles on the register poll.
So it came out that the register always reads $2121, which is an openbus. Made a video from that tests:
So i suspected that there is something wrong with the CART/CS line, because it looks like the rom doesn’t
Background to this is that MMIO access of the register $2140/2141 make the address appear on the A bus. RD will go low and CS will go high for deselecting the rom. This should activate the SPC on the A bus.
So i made a little logic analyzer session with the prototype board to verify this. The outcome looked quite ok.
Next day Max joined me debugging and i explained him that we have a conflict on the A bus during MMIO. Going thru the schematics we figured out that the only weak spot could be the busdriver which forwards the CART IO line and switches the ram address and data bus to the SNES A bus.
So Max added another OR gate to get better control over the CS line. What we needed was this:
CS: Cart ( low active )
EN: SNES enable from avr
G: Busdriver enable
CS EN G
1 1 1
0 1 1
1 0 1
0 0 0
Since i didn’t had anything better than an 74LS00 at home, we did it with 3 AND gates.
And this did the trick. Now we were able to boot roms which used the SPC. So we think the problem was that the budsriver was soaking up too much voltage, when the SNES was pulling CS hi the SPC didn’t got triggered.
After running a few games, we found that that now he have random crashes somewhere else 🙁
Have to investigate this right now…
Last night i had a long debug session with Max and we tried to track down the problem with the prototype board.The problem is that some homebrew roms are runinng fine, but most commerical games don’t even start. I can start up the game “Mr. Do”, but it hangs directly at the first intro screen.
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.
The last 2 nights i spend some time debugging the firmware of the prototype board. I added CRC checks for the sram areas and each uploaded bank. Hence i can push roms to the sram and verify it at runtime on both sides. So i can see if there are any transfer errors. Iam not using any CRC checks on USB layer, because the VUSB lib only supports this for 18MHz driven mcpus and we use 20MHz. This why i have to do it by ‘hand’ later after a block/bank is upoaded.
Also i switched the SRAM addressing mode to the faster counter based version. This boosted the upload speed by a great magnitude. I guess there is more room for optimization, but right now its quite fast to upload a rom. Like 2 seconds for a 32kb LOROM bank. So just a few seconds for a 4mbit game.
I know that USB could do much faster, but there are limits to the USB lib we are using. The client side allows only transfer up to 254 for each call. Minus the protocol overhead. Also the host side runs in user mode and can’t be compared to a kernel module performance. USB Transfer is realized thru callback in the firmware. Right now an 128 Bytes data transfer is splitted into 16 times 8 bytes payload callbacks. So i got a huge accumulated function overhead with this. Either i have to optimize this callback behavior or do it in ASM to squeeze out some cycles.
There a little downside right now. I can’t get commerical roms working. Iam able to upload and run homebrew stuff, but games doesn’t seem to boot. Sometime i have weird crashes in homebrew stuff.
I can assume that our attached CRC chip is working, because i made it into the start screen of Mr.Do, but Super Mario World doesn’t even show up the Nintendo start logo.
I guess there is something wrong with the our HI/LOROM or WR Enable switching logic. Have to investigate this….
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.
These two pictures show the different functional blocks of the prototype design. On the top side you have the MCU and next to it the connector for In-System-Programming and the MMC/SD daughter board. The yellow block marks the usb hardware for emulated software-usb on the mcu, the green block is the ram section. The orange block on top, right under the cart edge connector marks the bus transceivers to connect or disconnect the snes to the ram interface. The blue block overlays the transceiver for data access to the ram from the mcu side. The logic gates are for lo-/hiram switching and to disable write access to the ram section from the snes side.
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.
Finally assembled and the pcb powers up. So iam posting a few more details photos.
The boards powers up and the FTDI can be accessed via usb. So tomorrow i gonna meet with max and we will port the old firmware from the mega16 to the mega644. Tomorrow we might have simple usb based uploader working.
This monday morning the long awaited first prototype PCB arrived from pcb-pool. We had a little UPS problem on friday, so we had to wait till monday to get the PCB. Max just started to solder all the chips, looking forward to get a working usb uploader firmware running till the next weekend.
I think the PCB looks really good and iam looking forward to power it up soon…