sd2snes

[Patrick FR]

My first message here..

I did build a flash cartridge in 2004 (flash, SRAM and an ispGAL) based on Chnowack work. It is like the tototek board, programmed with a parallel port board.

I'am looking on the internet for documentation in order to build my own "yet another SD card cartridge". Ir differs from your board, I will use flash memory again because it is not expensive and I do not need to reload a game at each boot. I plan to use a cpld because his program is static. And like you an atmega to read the sd card (but i will try to use the SD parallel interface wile wiring the port with SPI in case of a problem).
The concept would be: the snes cpu reads NOPS, MOV, and JUMPS instructions coming from the cpld thus loading a "boot" program in SRAM. Once the program is in SRAM, the snes cpu jumps to the boot program and the cpld becomes configured in HiRom address space, giving only a tiny interface to acces the atmega in order to read the SD card.
The snes checks for an input, if say R buton is pressed it starts the FAT16/Menu/programming routines, else it looks for a lorom header in the flash memory and configures the cpld for lorom/hirom and removes the SD interface. Then the snes cpus clears his sram memory and jumps to the start of the ROM.
I do not know if the snes can execute program from his own sram? Anyone?
Thus no super FX on this, no nothing except maybe a fun DSP-1 simulation. Guess how.

I have indeed questions concerning your design. The fpga needs a "long" time at start to load his configuration. How do you manage the snes cpu read operations during this time? I assmume that the microcontroler controls the level shifter buffers between your board and the console?
Or maybe the micro controller holds reset signal enabled?
Why do you need to access your rom memory between 2 read operations of the snes cpu?

Why did you transfer the data from the avr to the fpga using SPI? You could have used a 8bit port, rd/wr signals and an interrupt pin from the atmega. It could have been faster.
If I understand, the super FX has on one side the snes bus and on the other side the ROM "bus" and therefore can cut the access to the snes?
Thus if this is correct your fpga cuts also the bus and you could send NOPS and JUMPS on the snes bus while loading the SRAM on the ROM side.
However I begin to understand and I find it simpler to load the "ROM" using the snes cpu throug a temporary custom atmega buffered interface at say $30 | $3000. Maybe it is slow?
How do you load your boot program?
Now with the built in SPI interface, do you need the avr?

How much time did you spend on this project? Because It took me a year and half to complete my flash cartridge. And the biggest problem with electronic is when you are stuck with an unexpected problem for month.
In my case it was parallel port glitches and time outs, the other problem is to get 1mm thick boards instead of the standart 1,6mm.

Nice project (but really big because of the SA, fx chip and co).

PS: design fever today....

[ikari_01]

what type of money would I be looking to spend to make it actually happen if you have any ideas? Where would I have to order from and what potential difficulties would I run into? Just curious, it'd be great to have something like this for myself even if you won't be handling the production yourself.

I can only tell you what I paid in Euros, you might get things cheaper in the US. (If you are in the US )
The most expensive part is the PCB when you order just one or two of them. I paid around €120 for my latest prototype PCB (sans parts). Had I ordered 4 it would only have cost me €20 more. Maybe you can organize your own omnibus order (is that the correct term?) when it's ready.
I ordered the PCBs at pcbcart.com.

Parts amounted to about €95 (SRAM €60, FPGA €15, AVR €5, SD card slot €4, level shifters €3, voltage regulators €3, plus small change).
I ordered the parts at reichelt.de and rsonline.de, but they are German distributors. digikey.com might be a good choice.

[ikari_01]

I'am looking on the internet for documentation in order to build my own "yet another SD card cartridge".

They spring like mushrooms these days.

I do not know if the snes can execute program from his own sram? Anyone?

It's DRAM but yes it can.

Thus no super FX on this, no nothing except maybe a fun DSP-1 simulation. Guess how.

Software emulation using the AVR, triggered by IRQ?

I structured your questions to make reading the reply easier without using tons of quote boxes:

• The fpga needs a "long" time at start to load his configuration. How do you manage the snes cpu read operations during this time?
• I assmume that the microcontroler controls the level shifter buffers between your board and the console?
• Why do you need to access your rom memory between 2 read operations of the snes cpu?
• Why did you transfer the data from the avr to the fpga using SPI?
• If I understand, the super FX has on one side the snes bus and on the other side the ROM "bus" and therefore can cut the access to the snes?
  Thus if this is correct your fpga cuts also the bus and you could send NOPS and JUMPS on the snes bus while loading the SRAM on the ROM side.
• How do you load your boot program?
• Now with the built in SPI interface, do you need the avr?
• How much time did you spend on this project?

• Indeed, by holding the /RESET line on the cartridge slot.
• partly. It can control the direction of the block containing the SNES /RESET pin. Thus, it can reset the console and it can also detect when the user presses the Reset button on the console. SNES Databus /OE and direction, and SNES /IRQ direction are handled by the FPGA.
• To access the SaveRAM area which resides in one of the SRAM chips. I do it to monitor the SaveRAM contents and save to SD card when a change is detected. I need to time multiplex it because I only have one memory bus.
• Because I ran out of I/Os on the FPGA and was too lazy to switch to a larger package. Also, it makes for a flexible configuration/command interface.
• Not exactly. The SNES CPU has to cut access to the ROM itself (by granting the SuperFX access to it).
• I load it like a normal ROM during the initial reset phase.
• I keep it for flexibility. It configures the FPGA in serial slave mode, loading the bitfile from SD card. It will be preprogrammed with a bootloader so it can flash upgrade itself. So it's really easy to deploy upgrades. It gives me a nice debug console via UART. And there already exist great SD card access code written by the author of sd2iec, and FAT access libraries.
• I started in April 2009. I do it besides my normal job so real productivity mostly occurs when I'm on a leave.

[Patrick FR]

Software emulation using the AVR, triggered by IRQ? Smile

Right, and the avr being slower than the DSP1 in terms of clock cycles per multiply I am curious about the result. Some latches are needed in the cpld in order to handle the accesses. The PIC32MX could be better here: many times faster, multiply and divide and a slave parallel port of 4 addressable bytes. But this may be a shameful overkill (72Mhz Mips).

Indeed, by holding the /RESET line on the cartridge slot.

Simple and efficient, I feared to use this before checking that it has a pull resistor up but indeed.

To access the SaveRAM area which resides in one of the SRAM chips. I do it to monitor the SaveRAM contents and save to SD card when a change is detected. I need to time multiplex it because I only have one memory bus.

Tremendous, by the way the SD card would not tolerate million writes. Do you use a brown out detector to trigger the write to the SD? A timer?

I keep it for flexibility. It configures the FPGA in serial slave mode, loading the bitfile from SD card.

I did not know that it was possible with a xilinx to lad the configuraiton trough SPI. Loading from the SD is a very good idea because it simplifies development, allows updates, and avoids the cost of an SPI memory.

Thank you for all these explanations. Your design is what would be the ultimate snes cartridge because of the fpga.
When thinking the design I feared to use an fpga because of this load step and configuration memory size. You solved the problem in an elegant way.

But yes it is a lot of work, I do not know if I will develop my SD cartridge yet because of the work required but it is interesting because it allows to learn things fast.

PS: Chnowak multi console copier that I used to start (it simplified a lot my work):
http://chn.bplaced.net/index.php?doc=mcc/mcc.html

[Patrick FR]

Patrick FR: However I begin to understand and I find it simpler to load the "ROM" using the snes cpu throug a temporary custom atmega buffered interface at say $30 | $3000. Maybe it is slow?

I was wrong then, I thought of a complex system loading the ROM in parallel of the snes execution.
With the cpld I will be obliged to use a trick at boot time with the snes cpu to load the boot code because the cpld has not enough pins to address the Rom and Sram. And maybe not enough complexity even if it had enough pins.
Maybe it wont fit at all, I must begin with the cpld.

Quote:
I do not know if the snes can execute program from his own sram? Anyone?

It's DRAM but yes it can.

Very useful then.

Today I read from http://sneshack.blogspot.com/ that it would be nice to pause the snes using only jumps to a specified addresse and indeed NOPs are not usefull.

By the way, many people are "working" on the nearly same thing.

[ikari_01]

Yes, SaveRAM access is not directly passed through to the SD card.
The AVR permanently generates a checksum of the memory area. When a change is detected, the SaveRAM will not be saved to SD card until it has remained unchanged again for about 1 second.
Of course there are some games which use the cartridge RAM as work memory, i.e. update it constantly. In this case there's a fallback that will save every ~30 seconds even when contents keep changing.
And there's a manually triggered save when resetting to the menu by pressing Reset on the SNES for more than 1 second.

[tomaitheous]

Sorry, kinda zonked out when I got home.

kyuusaku is correct, re: Fast/SlowROM times. "Normal speed" (e.g. "SlowROM") has to be 200ns or faster. "High speed" (e.g. "FastROM") has to be 120ns or faster.

This is defined in the manual, section "Super NES Software Submission Requirements", chapter 1. Revision C, dated 1992/11/02.

I'm a bit confused. Why is it requiring speeds at that rate?? Master clock /6 = 280ns per memory cycle and /8 is 372ns per memory cycle. Why would you need anything faster than that? All the SFX docs I've read stated VDMA doesn't move data from the bus any faster than master clock/8 per byte, so that can't be it. Unless this speed rating is for one of the addon processors or DSPs...

[tepples]

As I understand it, you need the ROM to respond within about half a memory cycle. /OE goes low on a read, and the data lines need to stabilize before it goes back high.

[tomaitheous]

As I understand it, you need the ROM to respond within about half a memory cycle. /OE goes low on a read, and the data lines need to stabilize before it goes back high.

The SNES needs a rom to respond the rom to respond and have the data on the bus at half a memory cycle!? Why? That doesn't make any sense. I don't know of any other 65x related processor setup that requires that. It also defeats the whole purpose of a slower clock speed (slower memory speed means slower roms, means cheaper roms). I've always used roms slightly faster than the memory bus speed (for 65x), but never twice as fast. The state from off to enabled for /OE is tiny in comparison to the rated chip speed for roms. The propagation delay is really small. There's something that's missing here.

[ikari_01]

This was made a while ago for a different purpose, but anyway:

/OE ("/SNES_RD") stays high on hw register access (where /PARD should go low).
The large pause is the refresh cycle that occurs in the middle of each raster line.
To the right we see a single SlowROM cycle. (probably WRAM access)

/OE appears to be derived from the "CPU clock". It is low for about t_cycle-140ns. So in FastROM operation, it is low for ~140ns, in SlowROM operation it is low for ~230ns.
About 20-30ns after it goes high, the new address is put on address bus A (haven't looked at the B bus so far). Nothing else seems to happen on the memory bus during that period. There seems to be no bus sharing within the same cycle.

EDIT. This should clear things up. In the original 65C816 design, there are only 16 address lines - BA0-BA7 (A16-A23) are multiplexed on the D0-D7 lines.
see http://www.westerndesigncenter.com/wdc/ ... 5c816s.pdf p. 13 and p.26.

[tomaitheous]

Oh thanks for the capture pic. I see, it's because they multiplexed the upper address lines on the data bus lines. That makes perfect sense. I totally forgot the original '816 was supposed to be pin compatible with the 65x. That's the only way to extend the address lines while still maintaining the original pin count. Although, that's really stupid on Nintendo's part. If anything, that explains why the CPU speed is so slow. Because of requiring double the speed memory. Man, Nintendo really screwed up on that one :/ They definitely should have went with a custom core processor like Hudson did. And I can't believe WDC still uses mechanism. Just another crippling mechanism added to the mistakes of the '816 IMO.

[ikari_01]

Small(?) update:
I am going to switch to PSRAM after all
A 128Mbit chip is only 1/5 the cost of my current 64Mbits of SRAM and we managed to get the small BGA package soldered with an, uhm, super special custom reflow pizza oven!

There will also be a second bus with 4Mbits of SRAM to facilitate parallel access for custom chips without getting into timing trouble.

The uC will be upgraded from AVR to an ARM based architecture, which gives much more bang for the buck and should further improve loading speed and provides a hardware USB interface, too.

I am also looking into adding an audio DAC to the board, maybe to provide compatibility for byuu's 21fx spec, or just to be able to emulate other sound chips, who knows

I hope to connect all PA lines, but I still need to recalculate the available I/Os on the new FPGA (will have to upgrade to a 208-pin package anyway for the 2nd memory bus).

[danntor]

Soldering SMDs actually work using toaster ovens? Can you please describe how you did it (I have seen it discussed on forums before but never explained).

[ikari_01]

Well, I usually hand-solder SMDs where the pins stick out. But with BGAs that was not an option

It is possible but you need to closely observe the temperature in the oven. Chip manufacturers usually recommend a temperature profile that looks a little bit like a backward ADSR envelope. e.g.: http://www.actel.com/documents/Solder_R ... adFree.pdf
Basically there's a preheating phase to preheat the components and activate the flux, a solder phase where the temperature stays above the melting point of the solder used (but below the allowed peak temperature), and a cooldown phase. For leadfree solder balls used in RoHS parts, the melting point is usually 217°C.

I simply used the thermometer function of my multimeter and put the sensor in the oven along with an empty board. On the board I placed a small amount of leaded solder (melting point=183°C) and a small amount of leadfree solder (melting point=227°C). Yes, this is a different melting point from the number I gave above because I saved a few Euros and purchased silver free solder which has a 10°C higher melting point.

I then used Manual PWM™ to slowly ramp up the temperature in the oven and noted down the multimeter readouts where the leaded and lead free solder melted, respectively. The MM actually read some degrees less than what the actual temperatures should have been according to the given solder specs.

Using this I was able to extrapolate the "MM temperature" that I needed to reach. My goal was to stay between 230° and 240° for at least one minute, so that was about 224°-234° on the MM.

I then put the board with flux and the BGA chip on it (align carefully!) into the oven. Heated it slowly, stayed below ~180° for 2-3 minutes, then ramped up to 230° and tried to stay there for a minute. Afterwards I switched the oven off and let it cool with the oven door shut. Et Voila!
And it even worked. Here's a pic of the test board wired to an existing sd2snes prototype. The four fat SRAMs that still reside on the board are disabled and now obsolete. Note the difference in space requirement, i found it pretty cool.

Note that this is quite a taxing task, because having to turn the oven switch while observing the MM readout and trying not to move the (light, cheap) oven too much is not so easy and definitely not recommended for more than experimenting
I'm going to build an automatic temperature control according to http://thomaspfeifer.net/backofen_smd_reflow.htm (sorry, it's in German) to have an uC do this hopefully much more accurately.

[ikari_01]

Small update for the record.

BGA reflow soldering proved feasible. So there will be 128Mbits of 16-bit PSRAM + 4Mbits of 8-bit SRAM on the secondary bus.
A DAC for the SNES's analog line in will be included. (Testing the DAC is the last todo before a prototype PCB is ordered)
The B address bus is fully connected, who knows what it may be good for.
There's a replaceable backup battery for RTC support and SRAM data retention (I'm sure there is some good use for that)
And of course, a SuperCIC key enabling operation on any unmodded SNES/SFC, but also adding the option to switch 50/60Hz via software on SuperCIC modded consoles.
MSU-1 support may or may not be possible depending on the data rate I can get from the SD Card.
Two of the LDOs have been replaced by a dual switching regulator, slightly improving power consumption. This will be more important once the FPGA core becomes more active due to custom chip emulation.