Author
|
Topic: Think I found a good tool for NES hackers. (Read 739 times)
|
I.S.T.
Guest
|
 |
« on: December 19, 2007, 05:01:38 am » |
|
http://nocash.emubase.de/nes.htm Turns out there's a No$nes. It's available for free, no less. Of note is the insanely detailed everynes.htm file linked underneath the emulator. It's not included in the download as the page states, however.
|
|
|
|
|
Disch
Guest
|
|
« Reply #1 on: December 19, 2007, 11:09:02 am » |
|
I'm pretty certain FCEUXD's debugger outperforms No$'s in pretty much every way.
Everynes is more of like a collection of existing docs, not so much a doc in itself. It's like he cruised nesdev and slapped all the files into a single html file (it's also worth noting that it contains several errors -- specifically in the mapper department).
EDIT
Just tried No$ for myself to see firsthand how it stacked up. Turns out the emulator itself is pretty "blech".
Not to be a total downer -- but you're really better off with FCEUXD
|
|
|
|
« Last Edit: December 19, 2007, 11:18:07 am by Disch »
|
|
|
|
Kagemusha
Guest
|
|
« Reply #2 on: December 19, 2007, 01:48:30 pm » |
|
Out of curiosity, is anything actually better than FCEUXD? I personally love that emulator and all its cool features.
|
|
|
|
|
Disch
Guest
|
|
« Reply #3 on: December 19, 2007, 03:51:51 pm » |
|
In terms of debugging: No -- FCEU's family of debuggers pretty much dominate.
In terms of emulation accuracy, compatibility, and features: NEStopia blows pretty much everything else out of the water. Nintendulator is very accurate as well (moreso than NEStopia in some ways, less so in other ways) but is much more awkward to use, is a lot slower, and doesn't have near the feature or compatibility list.
Of course... if I ever actually finish the emu I'm working on (haw), it could be a contender for both of those categories....
|
|
|
|
|
DaMarsMan
Guest
|
|
« Reply #4 on: December 19, 2007, 04:22:32 pm » |
|
We need bnes and bgen byuu...
|
|
|
|
|
Disch
Guest
|
|
« Reply #5 on: December 19, 2007, 05:50:51 pm » |
|
We need bnes
Not really  Unless I'm mistaken, Nintendulator functions similarly to bSNES (runs each subsystem in parallel, emulates every fetch that goes on the bus, etc, etc -- which is why it's so bloody slow). So you could say it already is the 'bnes' Though, really, such an approach isn't really necessary for NES emulation because there's only 1 CPU, and all other subsystem's behavior can be predicted... so a "catch up" style approach is much faster and works equally well. NEStopia employs this which is why it can be significantly faster without really being less accurate. In fact NEStopia passes a lot of blargg's test ROMs which test funky special case oddball behavior that Nintendulator fails -- so you could say it's even more accurate in some ways. But whatever. My point is there's no shortage of accurate NES emulators. |
|
|
|
|
MathOnNapkins
Guest
|
|
« Reply #6 on: December 19, 2007, 06:41:28 pm » |
|
BSNES is not the end-all be-all of SNES emulation to me b/c if you slap a debugger in it, it runs extremely slow. I'd honestly rather put debugging procedures into my actual rom and run them on the hardware than use BSNES with a debugger. Now for testing.... yeah it's a great thing to use if I don't feel like writing data to my copier.
|
|
|
|
|
Shadowsithe
Guest
|
|
« Reply #7 on: December 19, 2007, 07:40:30 pm » |
|
The alternative you just suggested doesn't exactly involve emulation, now does it?
|
|
|
|
|
MathOnNapkins
Guest
|
|
« Reply #8 on: December 19, 2007, 10:43:45 pm » |
|
If you took my post at face value, I'd say you're right. But in practice I use Geiger's Debugger rather than BSNES or a real SNES to test. It's just so much quicker that any gains made by using BSNES pretty much go out the window. Anything odd I notice in BSNES or the console is noted as a potential bug (in the case of BSNES there have been false positive) and I attempt to rectify it.
edit: my point was that it's difficult to have an emulator that is good at everything, speed, debugging, accuracy, etc. There's no way in hell I'm going to put anything but the most basic of debugging information into my rom for testing on an actual console.
|
|
|
|
« Last Edit: December 19, 2007, 10:49:00 pm by MathOnNapkins »
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #9 on: December 20, 2007, 09:01:55 am » |
|
We need bnes
Not really Unless I'm mistaken, Nintendulator functions similarly to bSNES (runs each subsystem in parallel, emulates every fetch that goes on the bus, etc, etc -- which is why it's so bloody slow). So you could say it already is the 'bnes' Though, really, such an approach isn't really necessary for NES emulation because there's only 1 CPU, and all other subsystem's behavior can be predicted... so a "catch up" style approach is much faster and works equally well. NEStopia employs this which is why it can be significantly faster without really being less accurate. In fact NEStopia passes a lot of blargg's test ROMs which test funky special case oddball behavior that Nintendulator fails -- so you could say it's even more accurate in some ways. But whatever. My point is there's no shortage of accurate NES emulators. The last version of Nintendulator was from January 2006 according to sourceforge. That's nearly 2 years ago... Dead emulators shouldn't count. If 'bnes' existed, it would still be active, thus Nintendulator can't possibly be 'bnes'. |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #10 on: December 20, 2007, 09:17:09 am » |
|
BSNES is not the end-all be-all of SNES emulation to me b/c if you slap a debugger in it, it runs extremely slow. I'd honestly rather put debugging procedures into my actual rom and run them on the hardware than use BSNES with a debugger. Now for testing.... yeah it's a great thing to use if I don't feel like writing data to my copier.
And just how are you going to put debugging procedures into your ROM without using a debugger to determine where to put any of your hack code to begin with? You must use math on napkins in ways unfamiliar to me to hack a routine without a debugger unless you're deciphering opcodes in a hex editor to pick your spot! Geiger's Debugger is turning into a poor choice to use because it's really outdated as far as accuracy goes. It's not even up to par for SNES9x (several versions old now), let alone bsnes. I've already run into several issues using Geiger's debugger where a hack wouldn't run correctly on the real SNES, but looked fine in Geiger's. Your own debugging routines on the real hardware are only going to catch so much before they become extremely frustrating to code. If you get into certain kinds of DMA, HDMA, sprite manipulation. writing to certain registers etc.., it's going to be extremely difficult to write debug code that executes in game to track down things like that. Times that by 10 if you've got any SPC700 code! That's a real pain to write debugging code for on the real hardware because you've constantly got to be communicating with the main processor and then have that info relayed to the screen. That's going to be extremely difficult if not impossible if you're hacking an existing game's sound engine. Geiger's is still being used by default since no other up to date, full emulator even has a debugger. The best debugger ultimately goes hand in hand with the most accurate emulator. What good is a debugger if it's not accurate? And who needs speed for debugging? What purpose does it serve? |
|
|
|
|
MathOnNapkins
Guest
|
|
« Reply #11 on: December 20, 2007, 09:22:14 pm » |
|
Woah.... slow down there. I'm not going crazy with debugging on a rom. But if a crash occurs, I'd like to have at least some sense of where it occurred. Hence, I plan on putting in a stack dump via the BRK and COP instruction (which IS the first sign of a crash on most games I hack.) This would involve stopping the whole shebang and just displaying a stack dump on the screen. Fully reliable all the time? Probably not. If a crash occurs on the real thing and neither BSNES and Snes9x are of any help, at least I'd have that in addition.
Now for games that actually uses those instructions, I guess you're out of luck. In the event of a STP instruction, you're also out of luck (I think.)
I think you overstate the outdatedness of Geiger's by far. I'm not saying it's the greatest thing ever. But I'll take it over BSNES's debugger b/c I actually want to be able to debug things in a sensible timeframe. If that means sacrificing a little accuracy sometimes, so be it. And, as I have noted, BSNES has also given me false positives for bugs that don't exist on the actual hardware. Yes, I have run into problems that Geiger's won't detect, that's why I also test in BSNES whenever I write code that seems potentially accuracy sensitive. (especially NMI code!).
edit: "You must use math on napkins in ways unfamiliar to me to hack a routine without a debugger unless you're deciphering opcodes in a hex editor to pick your spot!"
What do you think I did before we had debuggers?
|
|
|
|
« Last Edit: December 20, 2007, 10:59:35 pm by MathOnNapkins »
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #12 on: December 21, 2007, 08:57:38 am » |
|
If nothing else, by both of our posts, I think we've established that there are currently no single SNES debugging solutions that are good enough to get the job done at present.  Emu authors, are you listening? |
|
|
|
|
|
RHDN Forum Archive
