Next Page

N64 debuggering by Parasyte at 8:34 PM EST on January 7, 2010
Greetings, on this fine new year of 20XX!

First, allow me to introduce myself, since this is going to be a bit of a mysterious thread, anyway. I go by "Parasyte" online, particularly in certain video game hacking communities. I've authored some important tools that make video game hacking more accessible, or just plain better. Some examples of these tools are listed below:

* GCNrd; GameCube Remote Debugger, a set of programs that allow low-level debugging of commercial GCN games using the broadband adapter.

* FCEUd; A fork of the FCEU emulator which adds a low-level debugger and simplified cheat console. It has been superseded by many following forks of the FCEU code base; most recently, FCEUX.

* GCNcrypt/MAXcrypt; two separate programs which can encrypt and decrypt Action Replay codes for GameCube and PS2, respectively.

I have also done a handful of [decidedly pretty bad] USF rips. I believe Mario Kart 64 is my most famous rip. Now, back when I was doing these USF rips, I was stuck with the same basic tools that everyone else was using. And for some reason, I get the feeling that the situation hasn't changed much even now, a little over 5 years after initially ripping that USF.

One project I started working on around the same time (and not listed above, for reasons which will be made obvious shortly) was adding a debugger to Mupen64. Mupen64 already had a debugger at that time, available in the GTK+ UI build. But it didn't have any of the features that I needed; things like breakpoints/watchpoints, a memory editor... The features that I associate with low-level debuggers.

The "Mupen64d" project never really got beyond the state that breakpoints were working; there was no usable UI for it. I halted work on the project to focus on a related project which would help alleviate some of the problems I was running into. My biggest concern was being forced to write Yet Another debugger UI. I already did that once with FCEUd. Wouldn't it be nice to write a UI once, and then use it everywhere? Sure, you might have to change a few things between different video game consoles, but the basics of the UI would always remain the same.

This all eventually led to an idea I'm calling the "Scalable Remote Debugger Protocol" SRDP. Its focus is on making debugger interfaces which are disconnected from the emulator or game console that you would be hacking. In effect, you will always be debugging remotely; outside of the emulated/real console.

SRDP is actually a fairly large topic of discussion, and I cannot squeeze all of the information into a single post. But I do have some resources available, if you are interested in some further reading:

* The post that started it all
* About the debugger UI I intend to create using SRDP
* About the protocol

TL;DR: I want to make the best N64 debugger ever. Would you like to have one too? I am looking for help, and I can explain exactly how you can be of assistance if interested. Please read the references above (yes, they are incredibly long) and respond here to voice your interest!

Thanks, and I hope we can all collaborate to accomplish something great. :)

edited 8:35 PM EST January 7, 2010
by J-Lead at 8:58 PM EST on January 7, 2010
These are just two few places that are definitely worth telling/asking. They have a lot of good hackers.
by J-Lead at 9:07 PM EST on January 7, 2010
Yeah, those two places are like the cornerstone to video-game hacking and I cannot for the life of me think of anywhere else. Sorry but I cannot help in any other way since I have no knowledge of anything about computers let alone any sort of hacking.
by Mouser X at 9:31 PM EST on January 7, 2010
Actually, ugetab seems to have figured out some "reasonably easy" (comparatively speaking) methods for ripping USFs. One of the biggest problems he runs into now are limitations of the emulator/Winamp plugin. My suggestion would be to get in touch with ugetab, since this sounds like the stuff that's right up his alley.

As for me, I really have nothing useful to offer. Hopefully ugetab sees this and responds. He might find it useful. Mouser X over and out.
by Parasyte at 9:54 PM EST on January 7, 2010
GSCentral; No interest. I am the founder of a website which is in nearly direct competition with them:
GSHI; I have a close relationship with many of their staff and hackers. This includes ugetab.

Thanks for the suggestions, however.
by JILost at 10:09 PM EST on January 7, 2010
What about
by Parasyte at 10:36 PM EST on January 7, 2010,8271.msg128975.html#msg128975

by arbingordon at 11:42 PM EST on January 7, 2010
you actually run kodewerx? didn't know that. nice job on the site (and obligatory "fuck rune" :)

I'll try and help if there's anything tedious... Other than that I don't really have much to offer.
by ugetab at 12:23 AM EST on January 8, 2010
The 'comparatively easy' method I use:
It relies on a combination of a hacked NEmu64(uncompressing save states) and Project64(with uncompressed save states).

Basically, I use the debugger in NEmu to setup the code, and sometimes the entire main RAM area, then use a hacked Project64 to get the PC in the save state the same as the one in the NEmu state, and either copy over the bit of code edited, or the entire RAM area if Project64 doesn't play well with the game. Then I tend to end up with either a working Save State for ripping with, or find out the USF ripper dies horribly when exposed to the Save State, and post my work in this thread.

I doubt this is helpful for your debugger development, but I figured I'd give you a run-down of what I might use it for. For a different project, I intend to eventually figure out why Zelda64 doesn't run at the right speed. If I can't, it'll just get in the way of other N64 projects for the rest of my time ripping them. If you have any idea where I could find someone to grill for hints about where to look, I'd appreciate the info.

I hadn't seriously considered the idea of using your portable debugger to hook into a compatible emulator. As it was discussed before, it had some hefty options that would play quite nicely with hardware. Having a version that hooks into compatible software just to get the UI out of the way(and to build up a MAME debugger style fan-base) could very well be more useful than even I can comprehend.
by Parasyte at 12:28 AM EST on January 8, 2010
Hi arbingordon,

Yes, that's me. That Parasyte.

Right now I'm throwing some ideas around in IRC. You're welcome to just idle there and listen for any chatter (even if it's rare): #srdp

I've started some coding work, even without a fully specified protocol. I think having an implementation will help iron out some of the remaining details.

As we all know, the state of N64 emulation has been ... disappointing, for lack of a better term. And of course, it has been that way for over a decade(!) In my opinion, Mupen 64 and 1964 are the only usable open source emulators. It does not appear that they will support games with custom uCode any time soon though (Battle for Naboo, Indiana Jones, etc).

MooglyGuy has been showing some nice progress on low-level emulation of N64 hardware over the past few years. This is a huge step in the right direction; "HLE" is the opposite of emulation accuracy. And emulation accuracy is important for debugging accuracy. Anyway, until his work is in a state where MESS's N64 compatibility matches Mupen 64 and 1964, I can't see this being an honest candidate for hosting a useful debugger.

Finally, we still have real N64 hardware in the year 20XX! It might be worthwhile to invest time and research into building a low-level debugger for use on the old GameShark Pro hardware (with the built-in LPT interface). But, modern computers do not contain LPT ports, and buying a real LPT port (NOT those "usb printer adapters" you see for $15) for laptops is not exactly accessible, since they cost $150 (more info) ... and it's still a dog-slow interface.

So I'm thinking, as kind of a supplement for debugging on emulators, a hardware-based debugger would be perfect. Probably not through GSPro, but we can certainly design and build hardware that can become the missing communications link to your N64. One idea I have is using an Arduino with an Ethernet shield; hook it up to an address decoder, and you get full network support through the N64's cartridge port interface. Then it is just a matter of writing a low-level debugger along the same lines as GCNrd... only it will speak SRDP, which should hopefully be established by then (with SRDP clients in use with emulators).

As an extension to this simple hardware idea, turn the Arduino into a full-fledged "flash cart" ... It can be based on PVBackup, or go with a more modern approach using SD or CompactFlash, formatted with a FAT file system. The Arduino should be capable of doing all the complex FAT read access in hardware, passing the raw data on to N64 for DMA operations and such.

Granted, this is all speculation. But it sounds like a good idea, no? ;)

Anyway, meet us on #srdp to get involved!

Next Page
Go to Page 0 1

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=]Link[/url]


HCS Forum Index
Halley's Comet Software
forum source
Generated in 0.005s;