NES hardware debugging board

[Bananmos]

I recently purchased a cheap USB logic analyser (which I have yet to try out) for getting a bit more of a debugging tool for Everdrive/Powerpak experiments. But I quickly realised that trying to connect the probes to the NES cartridge edge would not be a fun task.

So with the kind guidance of Paul@infiniteneslives, I've spent some late evenings of my vacation designing a simple pass-through PCB that would allow easy-and-obvious access to all the signals on the cartridge edge.

The idea is that after soldering on a 72-pin connector and some break away IDC pins and putting on a bunch of jumpers on those, the board can be used in these ways:
1) Pass-through mode for debugging signals. Plug in any cartridge, and you can easily put on a debugging probe on any signal, by connecting it to either the top of the jumper, or to the pin (would slightly depend on which way you've chosen to have your jumpers, they could be either on the top or the bottom of the PCB)

2) Cartridge prototyping mode. Get two IDC34 ribbon cables and attach the board to a (wired or soldered) prototyping board. Would allow creating a new prototype board design from scratch without designing a new PCB for it.

3) Pimp an existing mapper design. If you have a new mapper in mind that is a slight variation on an existing one, then rather than designing it from scratch it *might* be possible (depending on what modifications you intend to do) to prototype this by plugging an existing cartridge into this debug board, and selectively removing jumpers from the IDC-pins, connecting them to a smaller prototyping board.

I plan to have the board manufactured by "itead studio", as recommended by Paul. The minimal order should give me at least 10pcs of them, which gives me one or two for personal use and a few to pass around. If a lot of people are interested then I might do multiple orders - but only after I've confirmed the first one works without problems. Although if a lot of people in the US want one, then we might save on customs if someone just clones my order and orders PCBs/components to distribute to others.

For the first run I'll go with 1.2mm board thickness, as that plays nicely with toploaders (even though I don't have one myself) and is still usable on a front-loader if you have a Game Genie at hand. But I am also considering ordering a 1.6mm version to make the Game Genie redundant.

The Designspark PCB file, a slightly modified version of Paul's NES component library (just adds a 72-pin IDC connector) and the Gerber files can be found here if you want to have a closer look around.

The design is close to done but not 100% final yet. So any feedback/suggestions for improvments is welcome. And also do let me know if you're really keen on having one to play with soon, and you might be able to have one from the first order...

[Bananmos]

So looks like there was zero interest. Oh well - it's made my own experiments easier at least.

But if anyone might be interested in the future, here's the final version:

And here's how an assembled board looks attached to an Everdrive N8 and fitted with probes from a cheap logic analyser:

Designspark files (based on InfiniteNESLives template) are here

And Gerber files - useful to clone the order I made at ITEAD Studio are here

Besides that, there's still a few spare boards around at mine that could use a new home. Not the quickest thing to solder together, but saves frustration in the long run when doing hardware debugging.

[lidnariq]

I really like the variant of those logic analyzers that also supports 12MHz / 16 channel. (e.g.)

Unfortunately, I find myself really wanting more than 16 channels when I'm working with these old systems. I'd probably have to pick up one of the HP logic analyzers to really benefit.

[infiniteneslives]

Congrats on completing your project! I'm looking forward to tinkering around with the one you sent my way.

Unfortunately, I find myself really wanting more than 16 channels when I'm working with these old systems.

For my basic needs to date I get by pretty well with my 4 channel ikalogic, my more advanced logic analyzer needs are typically for serial anyway. But I've been thinking about doing some more advanced parallel bus analysis for things like advanced mapper/coprocessor reverse engineering and such, 4 channels just wont cut it. I've got a 16 channel LA on my scope but that thing is such a pain to interface with and 16 channels will still not be enough to capture the whole bus, and the interface is a PITA. Has me thinking of taking on a project similar to Bananmos' pass through board with a bus analyzer integrated into it.

Something along the lines of putting all signals on level shifters fed to a CPLD with ~100io. Then some fast parallel SRAM or few for a capture buffer that the CPLD would route the desired signals to for capture. That would make a trade off between number of captured channels and capture rate/length. But might be easier to simply pony up for a massive FPGA that could keep a sizable internal buffer. The tool development time would be pretty high though, it can often be best to throw hardware at the problem when developing tools.. Perhaps it would be worthwhile in the end especially as the time consuming parts would be system independent allowing it to be migrated to other systems fairly easily.

I'm still not even sure what I would specifically want to look at. Just when I think capturing the entire CPU or PPU bus alone would be enough, there would be some case I would want to see both at the same time at least for a brief period. The other problem with the level shifter -> CPLD -> SRAM idea is the delays introduced. If you want some more accurate timing analysis especially between channels it may make a mess of things to the point where you can't even trust your data.

10-12nsec 5v 256kbit x8 SRAM that I typically use for CHR-RAM is pretty cheap stuff though. Wouldn't be the craziest idea to drop ~8 of those SRAMs onto a pass through board with the data pins wired directly to all signals. That would get 64 channels with no trade offs between capture width/length. Could get by with just a counter for the address incrementing. But then there's the challenge if pulling the SRAM off the bus to read the captured data back out again. Plus you want to have advanced triggering on specific address accesses and such. While there are 5v tolerant CPLDs that could dump the capture after removing the device from the console or holding reset perhaps it would be annoying. Probably makes sense to put the level shifters back on. But now the data isn't going through the CPLD/FPGA as in my original idea. The capture SRAMs just have a level shifter buffering immediately in front of them. The 3v CPLD could now 'sit from behind' while watching all signals and control the capture sequence. Throwing all the SRAM at the problem has me thinking it wouldn't take much design time to create something like this in comparison to what I was previously thinking. This setup is also much simpler in terms of the data path and would have me more confident that the captured data was accurate and not corrupted by a bug in the data path.

Then it would only really need a relatively small mcu with USB to configure the CPLD for the desired trigger and dump the capture data to host PC for analysis. Making all this hardware sounds like fun, but writing a massive GUI to display all that data intelligibly doesn't... Should suffice to convert to a text file as a simple log of the bus transactions. The other use case I had in mind was comparison testing between original chips and replicas, in that case you would really only need to compare file outputs to see where they differ.

Anyway, sorry for rambling too long on that side tangent. Just got me thinking and one thing led to a somewhat related other...

[lidnariq]

10-12nsec 5v 256kbit x8 SRAM that I typically use for CHR-RAM is pretty cheap stuff though. Wouldn't be the craziest idea to drop ~8 of those SRAMs onto a pass through board with the data pins wired directly to all signals. That would get 64 channels with no trade offs between capture width/length.

There is this glorious hack using SDRAM... writeup #1 and #2

Plus you want to have advanced triggering on specific address accesses and such.

I think borrowing from the various FX2-based options might be the right idea. With Sigrok, these support 24MB/sec captures, natively either 24MS/s at 8bit or 12MS/s at 16bit. The NES runs at 5.3MHz (more or less), so it should be possible to stuff 35 bits at 5.5MHz. Not quite enough to get all 54 signals from both buses, and it would lose information about microstep-by-microstep phase effects...

But then there's the (newer, more expensive, USB3-only) FX3 that was recently programmed into being a logic analyzer—cnlohr got it to reliably supporting 64MS/s at 32bit. Much more total bandwidth than we need here.

Then it would only really need a relatively small mcu with USB to configure the CPLD for the desired trigger and dump the capture data to host PC for analysis.

The FX2/3 have said MCU inside the USB PHY.

Making all this hardware sounds like fun, but writing a massive GUI to display all that data intelligibly doesn't... Should suffice to convert to a text file as a simple log of the bus transactions.

definitely take a closer look at Sigrok. It's basically what you're describing.

[infiniteneslives]

There is this glorious hack using SDRAM

Yeah I thought about DRAM but SRAM is so much easier to work with in terms of control, commands, refresh etc. If using an FPGA to capture the data SDRAM is the obvious solution for expanding it's RAM.

There's definitely merit to the FX2/3 based solution and free running data over USB to let the host deal with storing. Not sure if I'll ever be so motivated to tackle a project like this, I guess it depends on how long I can get by without it. Thanks for the tip on sigrok, definitely looks like the best way to go for signal/data analysis.

[lidnariq]

There is this glorious hack using SDRAM

Yeah I thought about DRAM but SRAM is so much easier to work with in terms of control, commands, refresh etc. If using an FPGA to capture the data SDRAM is the obvious solution for expanding it's RAM.

No, no, it's better than that. It's not just DRAM; it's specifically using SDRAM and setting up a feedback loop so that it the data in it is treated as commands to it, and starts a write cycle. Hence "hack"

[Rahsennor]

There is this glorious hack using SDRAM... writeup #1 and #2

I think my brain just melted.

[infiniteneslives]

No, no, it's better than that. It's not just DRAM; it's specifically using SDRAM and setting up a feedback loop so that it the data in it is treated as commands to it, and starts a write cycle. Hence "hack"

No I got that and picked up on what he was doing in the overly drawn out video too. I wasn't commenting on the hack as much as synchronous DRAM in general.