I'm looking to build an SNES cart reader powered by a Teensy++ 2.0 board, and I'm trying to figure out which of the cart pins are actually necessary/useful for this purpose, as I don't have enough I/O pins for every cart pin. For instance, since I just want to read/write to the cart directly, I don't think I have any need for the IRQ signal (pin 18). Or the stereo audio output pins, I have no use for those. The SNES cart has 58 I/O signals , and the Teensy++ has a maximum of 47 I/O pins, though it would be nice if I didn't have to use them all, since some of them are wired up for specific purposes. So I'm trying to figure out which signals I don't need to connect if I'm just concerned with reading/writing to the cart (maybe the expansion bus as well). If nothing else, I can always break out the full 62 pins to a standard IDC header so I can tap into any additional lines later. Anyway, this is the list of what I *think* I can omit, feel free to comment if I actually need these or if there are others I could leave off as well.
Pin 1 - 21.477MHz Clock
Pin 18 - /IRQ
Pin 24 - CIC Data Out (p1)
Pin 25 - CIC Data In (p7)
Pin 31 - Left Audio
Pin 55 - CIC Data Out (p2)
Pin 56 - CIC Clock (p6)
Pin 57 - CPU Clock
Pin 62 - Right Audio
That leaves me with 49 I/O's. I could maybe add in a pair of 8-bit latches for, say the upper 8 bits of the address bus and the 8-bit expansion address bus, which would get me down to 42, which is totally doable. Any thoughts?
A Super NES Game Pak can have a a 62-pin connector with extra sets of pins at the sides (1-4, 28-35, 59-62) or a 46-pin connector with only the long row of pins in the middle. The majority of Game Paks have either no coprocessor or an ordinary DSP, and these use the 46-pin connector. Are you intending to include compatibility with the coprocessors used in Super Game Boy, Super FX, and SA-1 games? If not, you can leave the side pins off. Leave the power, ground, and CIC pins out, and you're down to 40 or fewer.
I'll be using a connector off an old broken SNES, so I'll have access to the expansion pins, I figured I might as well connect them to something. Do I need the /WRAM signal (pin 32)? IIRC, WRAM is on the console, not the cart, right? From the documentation I've read, the /WRAM signal just indicates that a WRAM access is using the A bus, so my setup won't ever need that signal, right?
I'm not sure what the /WRAM signal means in the Super NES, and wiki.superfamicom.org appears unspecific:
"/CART and /WRAM are the two auxiliary lines." But at least on the NES, the name "WRAM" was used for "work RAM" in a Game Pak mapped at $6000-7FFF (more commonly called PRG RAM nowadays). Actual work RAM is far less needed on the Super NES than it was on the NES because internal RAM is 64 times as big as it was on the NES. But Super NES Game Paks often have battery-backed RAM at $xx6000-$xx7FFF or at $700000-$7DFFFF for saved games, and boards with the expansion pins may use /WRAM to decode addresses like those.
Nocash says that /WRAM and /CART are
nocash wrote:
/WRAMSEL - Work RAM select (00-3F,80-BF:0000-1FFF, 7E-7F:0000-FFFF)
/ROMSEL - Cart ROM select (00-3F,80-BF:8000-FFFF, 40-7D,C0-FF:0000-FFFF)
So /WRAMSEL lets coprocessors snoop on CPU writes to the console's internal RAM; you can probably just pull this up to +5V. /ROMSEL aka /CART, on the other hand, is essential to the ROM decoder on the PCB.
I think you can get away with A0-A23, D0-D7, /RD, /WR, /CART for virtually all carts. That comes to 35. Reset could be an RC if you don't have an I/O pin.
Do I actually need to connect /CART to an I/O or can I just pull it low, since I will always be addressing the cart? Also, if I do hook up the expansion pins, are PA0-PA7, /PARD, /PAWR, EXPAND, and REFRESH(??) sufficient? That's another 11 or 12 pins, depending on whether or not I need REFRESH, but if I use latches for A16-23/PA0-7, I'm still within my pinout limitation...
/CART should be low if and only if the entire address (A23-A0) is valid, or at least if A23-A15 is valid.
Things that use the expansion pins probably rely on the 21.5 MHz clock signal. How is the Teensy++ itself clocked?
If I need the 21MHz clock signal, I can put an oscillator on the board I'm making, that's not an issue. I'm just working out the cart<->Teensy connections.
qwertymodo wrote:
Do I actually need to connect /CART to an I/O or can I just pull it low, since I will always be addressing the cart?
What's your goal? Are you looking to dump carts and saves? If you want to dump battery ram on HiROM carts you'll need to set /ROMSEL high to access battery ram (what I assume you're calling /CART).
It's really pretty clean to put some 74HC374 flipflops on there for expansion on the upper address bit lines. If you're dumping in sequential byte access (not random access) it really won't even slow you down. It's kind of a waste to suck up all those pins for upper address lines if you think you might be able to make use of those pins in the future. I'd say have A7-0 directly connected, and A15-8, A23-16, behind 8x flipflops. It's actually less PCB routing as well.
N64 and GBA cart bus protocols put most of the address bus behind binary counters.
infiniteneslives wrote:
What's your goal? Are you looking to dump carts and saves? If you want to dump battery ram on HiROM carts you'll need to set /ROMSEL high to access battery ram (what I assume you're calling /CART).
It's really pretty clean to put some 74HC374 flipflops on there for expansion on the upper address bit lines. If you're dumping in sequential byte access (not random access) it really won't even slow you down. It's kind of a waste to suck up all those pins for upper address lines if you think you might be able to make use of those pins in the future. I'd say have A7-0 directly connected, and A15-8, A23-16, behind 8x flipflops. It's actually less PCB routing as well.
Mostly, yeah I'm wanting to dump carts and read/write saves. Eventually, I'm hoping to finish up my from-scratch dev cart PCB (not a "real" flashcart, just a 1A3M/1J3M clone with a flash ROM onboard instead of donor carts), and I'd like to use this for flashing ROMs to it. Correct me if I'm wrong, but I believe I should be able to connect the flash ROM /WE line to the cart /WR line without issue, because flash ROMs require specific commands before they actually begin writing anything.
I'm using this pinout for my signal names:
http://www.caitsith2.net/snes/flashcart ... nouts.htmlUsing FF's/latches for A23-16/A15-8 sounds good. How does the expansion bus work, is it just an 8-bit address, or is it combined with the normal address bus? I don't really care are about leaving spare pins, I just want to avoid using the pins that are intended for specific purposes (like the secondary clock inputs, or the bootloader enable pin) if possible, and it would also be nice to avoid the port that's broken out to a 2x4 header in the middle of the board, instead of the DIP rows on the edge of the board (PORTA). However, the Teensy++ has a crapload of I/O pins, so I may as well use them, no need to be stingy.
EDIT: Do
these look like they'd work in place of the HC374? From the datasheet, it supports 5V Vcc, the output voltages look compatible with CMOS logic levels (Voh 4.0V min, Vol 0.25V max), and on one of the other 74*574 parts (though not on this one, not sure why, I'd think it would be true across all of the '574 lines), the descriptions said that the 74*374 and the 74*574 are functionally identical, with different pinouts.
Not only does the flash require a specific command sequence, but it also requires /CE low and /OE high. The game shouldn't really be trying to write to ROM anyways. So you've got several means of write protection, you should be fine to connect it directly.
Yeah any D-flipflop should work. The pinout of the '574 is a little nicer to deal with for PCB routing purposes. I'd be surprised to see any issues with Voh/Vol. The Voh/Vol for most parts will satisfy the Vih/Vil of the part it's driving, there may be an exception but I've yet to find it...
How's this look? I have every pin on the cart edge connected except /IRQ (18), REFRESH (33), CPUCLK(57) and the CIC lines. I have all of the pins broken out to a 2x31x0.1" header, just in case I ever need to tap into the pins for something. I have footprints for a 741GX04 clock generator and a crystal, to generate the 21.47727MHz signal, and a 3.5mm headphone jack connected to the L/R audio pins. I also added a Pickit header for programming SuperCICs on-board (Vpp on the PIC doesn't connect to a cart pin, so I left a pad for it and I can use a jumper wire for that 1 pin.
If that schematic is good, I've managed to route the whole thing... this one was all kinds of fun to do (especially those latches...)
Any chance you could post a link to the 741gx04dbv datasheet? I'm curious.
Otherwise, I don't see anything obviously wrong. I love hiding components under other socketed components, but it might make assembly a little obnoxious.
Looks pretty good to me.
lidnariq wrote:
I love hiding components under other socketed components, but it might make assembly a little obnoxious.
No biggie assuming you solder the under components before the socket
lidnariq wrote:
Any chance you could post a link to the 741gx04dbv datasheet? I'm curious.
TI SN74LVC1GX04infiniteneslives wrote:
Looks pretty good to me.
lidnariq wrote:
I love hiding components under other socketed components, but it might make assembly a little obnoxious.
No biggie assuming you solder the under components before the socket
Yeah, and also that you check for any solder bridges on the SMD parts before soldering on the socket... cleaning them up after would be nigh upon impossible. Thankfully, my Teensy++ has square-post pins, so I'm able to use
these rather than a chip socket, which makes it way easier to fit components underneath.
qwertymodo wrote:
Thankfully, my Teensy++ has square-post pins, so I'm able to use
these rather than a chip socket, which makes it way easier to fit components underneath.
If you're ever looking to do similarly with a chip when you can't use a breakout board
these (ebay search IC female header) work nicely
Moved some of the parts around, made for a little cleaner board, and managed to fit the third flip-flop under the socket along with the other two. Also, I think I'll run the PIC high-voltage Vpp signal (for the SuperCIC) to the unused /IRQ line. I'll have no other use for it, and when I get around to making carts from scratch, I can just put a solder jumper on the board between the Vpp pin on the PIC and /IRQ, so I can disconnect it when I'm done programming (the SuperCIC uses that pin for it's pairing mode detection, so I wouldn't want to leave it connected after programming...)
qwertymodo wrote:
Also, I think I'll run the PIC high-voltage Vpp signal (for the SuperCIC) to the unused /IRQ line.
This makes me uncomfortable, but I can't articulate a reason that I can't argue myself out of.
lidnariq wrote:
qwertymodo wrote:
Also, I think I'll run the PIC high-voltage Vpp signal (for the SuperCIC) to the unused /IRQ line.
This makes me uncomfortable, but I can't articulate a reason that I can't argue myself out of.
There is no actual voltage to that line unless you actually connect a PICkit, which you would only be doing for the sole purpose of reprogramming a SuperCIC... maybe I could add a jumper to disconnect it on the board side, but there is no reason I should have a PICkit hooked up to a retail cart, and for now, I can't see myself making any carts that actually use the /IRQ line.
I just bought myself a SOIC socket, so I don't really have a need for a SuperCIC programming header on this board... so I thought about what I might do with those pins instead and came to the realization that I should put a CIC lock on-board, so I can talk to SA-1 games. Can anybody confirm these connections for the SuperCIC lock? I'm not sure what to do with the extra pins (esp. the REG_TIMEOUT pin, it isn't very well documented in the SuperCIC code what that actually does...). As for the 50/60Hz and D4 pins, I don't need those since this isn't a console mod, right? Also, the host reset out, not really sure what that does...
qwertymodo,
Could you provide the values you used for the 741GX04DBV Resistors and Capacitors? Also, did the use of the SuperCIC work out? Were you able to dump SA1 games?
@waterbury -
I added an snesCIC/SuperCIC to the Arduino based cart reader to enable reading/writing of SA-1 carts. In conjunction with the snesCIC/SuperCIC, I use an Adafruit Clock Generator module to supply all of the necessary clock signals for the reader. CLK0 is 21.477272MHz, CLK1 is 3.57954500MHz, and CLK2 is 3.072MHz. CLK1 is disabled until needed for SA-1 SRAM writes.
From my early testing, the snesCIC-resync version seemed to produce the best results.
The snesCIC is connected to Cart Pins 24, 25, 55, 56. CIC Pin 2 and Cart Pin 56 are both connected to CLK2 outputting 3.072MHz. CIC Pin 3 (Host Reset) and CIC Pin 4 (CIC Lock Reset) are connected to pins on the Arduino to control the snesCIC. CIC Host Reset doesn't really do anything on the reader but it is connected.
I start the Arduino with the CIC Lock Reset HIGH then allow the rest of the reader to initialize. Once all of the reader hardware is initialized, I set CIC Lock Reset LOW releasing the snesCIC to do its magic. You can then proceed to read the data off the cart. It works for all carts.
Good Luck!
> From my early testing, the snesCIC-resync version seemed to produce the best results.
That was indeed a lifesaver. It was thanks to ikari installing one of these in my US console that I was able to dump all of my US SA-1/S-DD1 games.
skaman wrote:
@waterbury -
I use an Adafruit Clock Generator module to supply all of the necessary clock signals for the reader. CLK0 is 21.477272MHz, CLK1 is 3.57954500MHz, and CLK2 is 3.072MHz.
Did you have to use any level shifting to generate a 5V signal, or did you just hook up the 3v3 output clock to the cart? Also, which version of the SuperCIC are you using? The 16F630?
waterbury wrote:
skaman wrote:
@waterbury -
I use an Adafruit Clock Generator module to supply all of the necessary clock signals for the reader. CLK0 is 21.477272MHz, CLK1 is 3.57954500MHz, and CLK2 is 3.072MHz.
Did you have to use any level shifting to generate a 5V signal, or did you just hook up the 3v3 output clock to the cart? Also, which version of the SuperCIC are you using? The 16F630?
No level shifting. Direct connection from the Adafruit Clock Generator to the appropriate pins on the cart connector (and CIC). When I started experimenting, I built small interchangeable boards with the snesCIC-resync using the 12F629 and the SuperCIC using the 16F630.
Here's the post on the Arduino forum with pics of my original setup:
http://forum.arduino.cc/index.php?topic ... msg2358446Like I mentioned previously, the snesCIC-resync seems to be the version that works best and it is the version adopted in all subsequent cart reader builds.
More details in the Arduino forum.
Good Luck!
How long does your Arduino reader take to dump a cart?
waterbury wrote:
How long does your Arduino reader take to dump a cart?
I run a modified code based on an old version of the Arduino code. My code is slower than the current standard code used by the PCB readers designed by sanni but I've added support for all of the Enhanced carts, SF Memory Cassettes, Sufami Turbo carts, and BS Satellaview carts and Memory paks.
Ran some quick tests with a couple carts that were in front of me. My code does a complete dump of all cart contents so the ROM dump times listed are approximate.
Yoshi's Island ROM dumps in about 1 minute. A complete cart dump with a text file, ROM dump (including checksum verification), RAM dump, and CRC32 calculation takes ~1:20.
Super Mario RPG ROM dumps in slightly less than 2 minutes (~1:50). A complete cart dump with a text file, ROM dump (including checksum verification), RAM dump, and CRC32 calculation takes a total of ~2:30.
Keep in mind that this is with the older, slower code. sanni's current code uses direct port manipulation of the Arduino which speeds up the results. My code uses a mix of direct and indirect code because I found that fully converting to the direct port manipulation broke some of the timings used for the Enhanced carts. I never got around to reworking the code as it is fast enough for me.
Ok, reran the tests with sanni's code.
Yoshi's Island ROM dumps in 23-24 seconds and then completes the checksum verification in a total of 30 seconds.
Super Mario RPG ROM dumps in 44-45 seconds and then completes the checksum verification in a total of 56 seconds.
sanni has some videos of the cart reader in action on YouTube:
https://www.youtube.com/channel/UC6QtRt ... q-32e5Edbg
One of these days, I'll get around to rebuilding my reader, especially now that I have a proper 2.50mm cart slot to use instead of the 2.54mm one on my original prototype. I'll definitely have to give the CIC and clock generator a try.
SuperUFO on AliExpress sells some nice replacement SNES cart connectors:
https://www.aliexpress.com/item/Replace ... 79303.htmlA little pricey compared to the cheap plastic connectors but they're the closest thing to the original thru hole connectors. Cart insertion and extraction is smooth. The plastic connectors can have a death grip on different carts.