How do you guys debug on SNES?

Just curious if I should be doing something more sophisticated.

When I have to debug code that is not working correctly I feel kind of at a loss. I'm left with: take out the code that isn't work, make the background change to color X to see if it got to this specific nugget of code. The most sophisticated thing I have done is to look at actual values in RAM via SNES9X's debugging version.

That's about what I've done, and in the same manner using the exact same tools. You won't find as good debugging-based emulators for the SNES as you would the NES, for whatever reason. You're kinda stuck with the tools that are available.

But hey, all that's more than we had back during the 90s snesdev days -- that consisted of literally changing some assembly code, reassembly, copying to floppy, putting floppy in copier, resetting copier, waiting for ROM to load off floppy, then seeing results, rinse lather repeat. :-)

These threads might also help you in some way:

http://www.romhacking.net/forum/index.php?topic=9249.0
viewtopic.php?t=5786

The debugger in some older version of bsnes seemed fairly usable to me back when I tinkered with some SNES development.

My methodology for debugging is that first, I try to analyze RAM (as well as have the actual code up in both the hex editor and a text file: the hex editor allows me to analyze the compiled code, while the text file allows me to match it up with the compiled ASM). If I have to resort to a step-by-step method of analyzing what went wrong in the assembly, then I transfer the ROM file to my Windows laptop and use no$sns and laevateinn for a step-by-step code analysis. no$sns is more complete, but has the usual inaccuracies for me to worry about. laevateinn is based on I believe higan v08x, and thus has more accurate step-by-step code, but it has incomplete implementation (I have no gripes about this, as it's good enough for me). Both debuggers have both 65C816 and SPC700 available, so I'll need those especially when I finally get to programming my own sound driver for the SPC700.

On the Genesis, sometimes I set the PSG channel frequency with a value I'm testing so I can hear if it's changing at all and in what direction. I would imagine doing something like that for the SPC700 would be more complicated, but it still may be a possibility to check in a "is that even doing anything at all?" circumstance.

The version you're referring to is still maintained as a fork called "bsnes classic". I myself use NO$SNS, which runs at full speed in Wine on an Atom laptop.

I mostly use no$sns for debugging, it's very easy to use for most homebrew debugging tasks, doesn't work too well on linux sadly.
However no$sns lacks watchpoints, which forces me to use other emulators for that, such as bsnes.
I use this version. There are some other bsnes debuggers around if you go digging but they're all a bit unwieldy and unintuitive compared to no$sns in my opinion.
Then there's mess which is even slower than bsnes-accuracy and not as accurate, and there's no vram viewer. But it has a pretty good interface, so if your computer is fast enough it might be useful. It's also the only emulator that currently seems to support proper coprocessor debugging beyond the spc700.

What problem did you have getting it to work in Wine? I initially had trouble getting it to load a ROM on the command line, but I resolved that through email discussion with nocash. It turns out you have to specify the absolute path of the ROM with Windows conventions (drive letter and backslashes). It was nothing that a little sed in the makefile of my LoROM project template can't handle.

That was how started writing my NES sound emulator, in 2001 or so. Because my main PC was down when I started the project, and it was probably for the best that I didn't rely on ZSNES to get anything working. What I still find amusing though, after the ROM grew to be over 8mbit, I started writing it to CD-RW to test (I have a Bung Gamestation). Probably the only time I ever did anything useful with a CD-RW.

If I was going to do some SNES stuff today, what I would do is build an SNES controller port to USB adapter. Then send whatever data you want in ASCII format. Sending is easy, but you can't easily receive on SNES this way, because it would have to continually poll the port. Actually there are some challenges with doing this too, because I tried it in the past (done it on NES, failed on SNES). Cycle-timing code on SNES can be tricky. It's better documented today, so AFAIK it should be doable. Would be better if there was a flashcart that provides a USB port, I haven't looked at any of them really so I don't know (NES Everdrive appears to have one, at least).

I'd imagine it would be easier on the Super NES because a horizontal IRQ handler can poll at roughly 16 kHz. Or the adapter can include a FIFO to queue about 20 ms worth of bytes for the system to read next frame.

Yeah I was thinking "the old way", in terms of using MAX232/FT232 to bit-bang. For async stuff in that case, polling with an IRQ might not be fast enough for bit-banging since it needs to detect the edge of the start bit, that could work at lower baud rates though. That reminds me too, one chip that looks like it may be simple to use is the FT121, USB to SPI. I haven't investigated the SNES controller port enough, but I know on NES it would be great, except that I can't think of a way to control the chip enable (without adding an MCU). Maybe it could be left enabled all the time, I don't know. Using an MCU is still more interesting, to me (would cost the same probably).

edit: on second thought, 16khz start detection sounds like it would be good for some decent baudrates.

I've seen "use a lowpass filter on $4016.0" suggested before. It sounds like that should work...

The last time I was looking for a USB-to-SPI bridge the ones I found required that the bridge serve as the SPI master, which wouldn't play nicely with the SNES or NES's controller port.

(tangent: If I had a famicom, it'd be fun to attach a huge SPI EEPROM to the expansion port. No extra hardware needed!)

Has anyone here used the UART interface on SD2SNES for hardware debugging? There's solder points on the PCB and at least hooks to use it in the SD2SNES firmware.

Yes I saw your shell fix in another thread, that works great. The problem I've had is that a lot of the keybinds don't work, including but not limited to: pretty much anything with a modifier (ctrl+s, ctrl+g, ctrl+t), typing in the debug interface to get a prompt to enter instructions etc. I forget since it's been a while, but basically I have to go through the menus to use those features, which is a bit tedious. I brought it up to martin and it seems to be a wine issue.

> Yeah I was thinking "the old way", in terms of using MAX232/FT232 to bit-bang

You can get up to 57600 baud (2-3KiB/s), but any higher and DRAM refresh gets in your way.

Infinitely smarter to use synchronous UART instead. No need for bit-banging and you get up to 20-40KiB/s. A Teensy works fine for this.

I still wish we could find a USB2 chip that'd let us stream at 2.68MB/s over the expansion port B-bus via DMA, though.

The annoying part is you still need a boot-loader cartridge (flash cart is fine), and you are limited to 128KiB RAM for both your program and data. So this method won't let you test a full-fledged game. It's really only useful for reverse engineering the hardware and dumping SA-1/MMC games.

Cypress EZ-USB. e.g. CY7C68013A . 3.3V but 5V tolerant. Has a native FSM that lets the other end negotiate when to present data. Should even be able to be used bidirectionally.

It's been used in the various cheap digital logic analyzers, such as Saleae and is supported by the Sigrok project.

Which is a crapload more than a lot of NES games had available to them. Depending on the game design, you could make a compile-time option to include only a single level's data, and then testing becomes as easy as reset on the Control Deck and then Ctrl+R on your computer. This "romless" concept worked for "multiboot" games on the GBA, and it could work for entries to a collaborative Super NES multicart. INL could sell a "coder's cable" bundle with a bootloader cart and a USB cable. Heck, if the Cypress is fast enough, a game could essentially mount the cartridge as a block device and DMA things to RAM that way, using the computer on the other end as a makeshift SSD.

That's a really open-ended question. But...

One thing I do is when I know I can get to a certain section code I'll add a label right there if one doesn't exist... I use WLA to export a symbol file which gives me the ROM address, then in BSNES debugger I set a breakpoint at that ROM address.. then I step thru the code and do my thing...

but there's different approaches for all different types of problems.. BSNES debugger also lets me set breakpoints on a read/write of memory.. even lets me break on when certain values are read/write IIRC...

Sometimes I might do a trace from one point to another and analyze the code in between the trace points.

I dunno what else to say to you cause there's loads of possible situations, calling for all different approaches