l33t debugging.

[blargg]

I'd really like to see the feature worked on, but we should try to keep our notes organized, concise, and easy to find.

You must be new here. People don't care much about that, so it's wasted effort worrying about it. Use the wiki if you want something organized.

[B00daW]

Totally would, blargg... totally would. The Wiki is what I prefer to use whenever I do extensive research. There are a lot of holes in it though that could be filled. I do not yet consider myself qualified to write articles on the Wiki because even though I have been lurking and around in the whole NESdev area for quite some time now. I'm just beginning now to take the time to understand the workings aside from the audio portion.

In summary: The Wiki needs more articles. I'm a moron; but an assertive moron, so I'll push others to include the information that it needs.

Also if this is an environment that needs to be disheveled to be conducive to learning, then so be it. I relate being an artist -- or a struggling artist in the least.

[tepples]

Modularity is one possible solution to these problems. The first thing to do is segregate the low-level debug primitives (functions and whatnot) from the user interface; make the interface modular, interchangeable with any interface. Then you define how the debug primitives interact with the interface via a communications link; make the communications link modular, able to establish communication using any number of interchangeable modules for TCP/IP sockets, operating system pipes, RS232, USB, etc. Next, you define the protocol; make the protocol modular, a 'universal language' that describes generic debug primitives, and allow it to be extensible as necessary. Finally, you define those debug primitives and provide a base implementation that can be expanded if required. However, a well-defined set of primitives is unlikely to need expansion for anything but the most exotic architecture configurations.

Could we start with the GDB protocol? Or would that work only for the 32-bit machines that the GNU operating system targets?

[Parasyte]

The GDB protocol is established, which is nice, but there is a slight problem with it: The protocol does not allow binary data to be sent. In interfaces which might want to update a PPU viewer in real-time, you will have to encode the PPU data to ASCII characters (0x94 becomes "94", for example) which has the side effect of doubling the bandwidth requirements.

Its use of a specific start/end sequence and a checksum indicates that it is really designed for a raw communications link which does not provide synchronization or cyclic redundancy checking. So it is great for very simple serial communication, but poor for TCP/IP or pipes/sockets.

Another problem is that it does not provide access to multiple memory maps. So you would have to establish a standard of some sort for accessing CPU, PPU, PRG, Sprite memory, etc. using the GDB commands for reading/writing memory (m/M respectively). [Not to mention related problems dealing with a lack of a well-defined command to describe the target architecture.]

And it would be very cool to use GDB with an NES target. Unfortunately, GDB hasn't had 65816 support since 2001, and has never supported 6502. So if you can't use GDB, why constrict yourself to the GDB protocol?


There's also DBGp which uses XML+TCP/IP, but obviously adds a LOT of overhead. And the Ladebug Remote Debugger Protocol, using simple UDP/IP packets with a 16-byte header. Finally, RFC-909 - Loader Debugger Protocol, which looks a bit closer to what I had in mind.

[teaguecl]

Parasyte, I'm on board. Years ago I implemented GDB debugging over TCP/IP into my emulator. I ran into all the issues you mentioned (specifically having 2 address spaces), and modified the protocol to suit my needs. That meant no more using gdb/ddd, so I started writing my own debugger interface. I modeled off of the best debugger I've ever used, SoftIce.
I was never really happy with any of it, though I love the approach. If we can decide on a good protocol, get some buy in from a few emulator authors to support it, then I'd love to write a new debugger. Maybe someone would want to do it as a plugin to Eclipse?

[tepples]

Would it be possible to pretend to have a 24-bit address space, where the upper 4 bits select which chip we're looking at?

• $000000-$00FFFF: CPU address space
• $600000-$602FFF: PPU address space
• $603F00-$603F1F: Palette
• $700000-$7000FF: OAM
• $800000-$BFFFFF: All PRG ROM banks
• $C00000-$DFFFFF: All CHR ROM or CHR RAM banks
• $E00000-$FFFFFF: All PRG RAM banks

[Parasyte]

teaguecl: That's about what I would expect. Thanks for confirming. Did you look over LDP (RFC 909) yet? I think it might be a very good starting point, since it's already designed to support multiple architectures and has a lot of room for extension. It's also well suited for TCP/IP. I'm thinking that's the one to build from, or at least barrow [a lot of] inspiration from.

The last time I tried Eclipse, it was too bloated for my tastes so I wouldn't be the one to write a plugin for it. But I imagine it could be done without much trouble.

tepples: Yes and no. It's certainly possible to define a generic 24-bit address space for NES, but what happens when you want to add support for SNES? Do you shift it to 32-bit address space? And when you want to add DS support later? 40-bit address space? What about 64-bit architectures like ia64/x64? Virtualizing the address space would compromise the idea of using an architecture-independent protocol.

LDP's proposed solution to this problem is fairly simple:

Code: Select all

4.3.1  Long Address Format

          The long address format is five words long and consists of a
     three-word  address  descriptor and a two-word offset (see Figure
     9). The descriptor specifies an address space to which the offset
     is applied.  The descriptor is subdivided into several fields, as
     described below.  The structuring of the descriptor  is  designed
     to  support  complex  addressing  modes.  For example, on targets
     with  multiple  processes,  descriptors  may  reference   virtual
     addresses,  registers,  and  other  entities  within a particular
     process.

Address spaces would be accessed using the "ID" field in the descriptor, which separates it from the address. Seems like an elegant way to handle it.

[tepples]

And when you want to add DS support later? 40-bit address space?

The DS has working gdb.

[Parasyte]

And GDB still has negligible support for multiple address spaces, let alone multiple CPUs.

[mic_]

I like the disassembler in FCEUXD, but it lacks in PPU debugging features (think no$gba-style viewers for nametables, attribute tables, palettes, sprites etc).