Making a debugging cart

Hi folks.

I am in the process of creating a debugger cartridge for the SNES. Essentially, what it is is similar to a game genie, in that it's a cartridge that also has a slot on the top.
I have already made the first prototype, a pinout cartridge with rows of pins allowing you to easily hook up a logic analyzer.

Next prototype will be targeted at slotting in an fpga, a large array of level shifters, and a usb 3.0 interface. It's slightly driving me insane, so many damn pins .
Goal is to record the entire bus at sysclock speed with a computer, to have an easier time understanding timing problems for TAS.

That said, there is also some man in the middle stuff possible because there was enough pins available to try it.

Would this be interesting to anyone else? Also, is there anyone else out there to bounce stupid questions at / review schematics/boards?
I am not an electronics guy, i have a background as a programmer, just got nerdsniped into this. It's going reasonably well so far, with the tried and tested method of copying samples into a glorious godawfull mess, but my brain is slowly starting to get turned into a mush from reading a truly absurd amount of datasheets.

Hi! (Weird to be actually posting here, i'm usually lurking)

I'd be super interested in this project. I'm currently in the process of making a SNES flash cart with a non-standard co-processor (ARM-cortex based, 120mhz) and i'd love to hear more about this and maybe share some issues i am facing. One main difficulty is that i want bidirectional level shifting on both A and B Bus to allow the co-processor more control over the system, but i've yet to find bidirectional shifters that fit my (very strict) budget. Another difficulty is that i'd like to use RAM for storage instead of flash, for easy on-the-fly ROM patching, but all reasonably priced PSRAM options are BGA only (i'm not gonna solder that by hand ) and DRAM requires complex circuitry for refresh and address multiplexing. I'm thinking of using a FPGA or CPLD for RAM glue logic, so i'd love to hear if you had any trouble reading the bus with an FPGA behind a level shifter.

Hi!

Yeah, that sounds like an interesting discussion!

I am going to be using the cypress fx3, which actually includes an 200mhz arm9 core: https://www.digikey.se/en/product-highl ... controller

Yeah, using an FPGA is an absolute must. There is *one* native 5v fpga, from microchip. Its about 20$, but the development tools actually only run on windows xp and crashes like crazy. It's such a pity.
I am going to be using an array of 74ALVC164245DGG 's, https://www.digikey.com/product-detail/ ... ND/2209909
I think it's the ones used by the SD2SNES boards.
I was warned that actually driving the address bus from the cart could potentially fry the processor, by some people on discord. Something about, uh.. that the cpu will try to source/drain enough current to pull the address bus high or low? So in my case, I am driving all of the level shifting in the expected direction. There are *very* few pins that are actually bidirectional on the snes, mostly the data bus and some of the signals like IRQ.

Poke me on discord, tuxie#8691 ?

Have you looked at the 74LVC8T245? Still kinda expensive though.. like 40 cents even if you buy 1000. Even so, may be the cheapest dual-supply option that I'm aware of.

tuxie: for ALVC parts, take care to keep the traces short. Not sure if it will matter in this application, but usually the Axx parts have very fast transition times. That can cause reflections in the signal. Normally I would say to avoid the Axx parts if possible. Maybe OK when switched at these lower speeds though, I'm really not sure.

I, uh ... just to be clear, you know that both address buses are always outputs from the SNES and can never go high impedance, right?

(Want to point out that, before we go all choir with serene voices singing 'Dude you should not drive the address bus' like it's the stupidest thing ever, I spent like.. two weeks searching for a way to do it because I figured it would be a good way to be able to debug some shit inside the SNES. Being able to poke any memory address would be pretty useful, or just.. pause the snes.
So, uh, we be fellows in this one <3. Shitsucks).

Oh damn, that's a bummer. It's honestly the first time I've read, that driving the bus from the cart is a bad idea and I've done tons of research (admittedly, more on the software side). Writing and reading WRAM at any time would've been such a blessing, e.g. through the port at 2180h. I guess i gotta hijack the PC somehow and sneak in a little uploader routine.

So how does bidirectional communication with the cart work? Does the CPU just write to the bus to give the co-processor stuff to do, and when it's done the co-processor pulses the IRQ line so that the CPU breaks out of whatever it's doing and reads the results? How does the SuperFX transfer its data to the PPU? Does it just signal the CPU to fire off a DMA?

Argh, this makes everything a lot harder and a lot easier (and cheaper) at the same time. I guess i gotta scrap my whole concept and PCB design. Welp.


For unidirectional shifting i was gonna use the 74LVC245, which is a 3.3v transceiver with 5v tolerant inputs. (Basically the same part you suggested but unidirectional). It has been cloned by pretty much every manufacturer under the sun and is really cheap (~10 cents pp. even at low volume). You can switch direction (and drive the bus at 3.3v) by connecting the direction pin to the co-processor, but yea... not really an electrically sound idea. For the data bus i was gonna use a TXS0108EPWR, since it needs to be bidirectional for stuff like external RAM. Not sure if it's a good idea to use two different level shifters, since i'd expect them to have slightly different timing.

Krzsiobal did something fantastic on a NES, injecting code ending in a jump to rewind back to where injection started: viewtopic.php?p=225801#p225801

Yeah, pretty much. Things like the SA-1 provide some primitive multiplexing, where the S-CPU has precedence, and if it's not accessing ROM, the SA-1's internal CPU can read ROM instead. The SFX and CX4 instead handle this multiplexing at the software level, letting the software to decide when to deny the S-CPU permission to read the ROM and feed it something else instead.


If it makes you feel any better(???), if you had successfully overpowered the SNES's address bus and control signal drivers, because of how the S-CPU's constructed, you still wouldn't have been able to write to any S-CPU internal registers; only the parts on the B/PA bus.

The tricky thing about the SNES, I think, is that it uses 5VCMOS voltage thresholds instead of 5VTTL, so 3V logic really requires up-translation for the S-CPU to receive things correctly. But down-translation can sometimes make use of a voltage clamp (may or may not be cheaper, YMMV) like the GTL2000.

The SNES is slow enough that I'd be surprised if needed to worry about that. Nothing happens faster than 3÷21.5MHz≈140ns, and most things are slower. Total PCB area and ease of routing is more likely the reason you would want a single part instead of multiple.