Acmlm's Board - I2 Archive - Rom Hacking - FCEUXD W00t.
| User | Post |
dan
Posts: 288/782 |
Oh! You mean the infamous "Debug My Hack For Me" feature? It doesn't have that.  bbit should add that to FCEUxd.  |
Gavin
Posts: 355/799 |
Originally posted by dan
Seems comparable to FCEUxd to me:
* disassembler
* assembler (change code and ability to save modified rom)
* breakpoints
* break on access
* conditional breakpoints
* singlestepping/tracing/animating/step out/step over
* vram viewer: BG map, tiles, OAM, palette
* IO registers viewer
* break on exceptions (accessing inaccessible VRAM, read unitialized WRAM and HRAM, echo ram access, access locked external ram, disable video outside vblank)
The feature sets for both FCEUxd and BGB seem very similar to me. There's even conditional breakpoints in BGB. BGB has probably the best debugger available in any emulator for any system. 
Dan i don't think you heard him, he said a lot of power.
Like, so it can do everything for you! |
dan
Posts: 284/782 |
Seems comparable to FCEUxd to me:
* disassembler
* assembler (change code and ability to save modified rom)
* breakpoints
* break on access
* conditional breakpoints
* singlestepping/tracing/animating/step out/step over
* vram viewer: BG map, tiles, OAM, palette
* IO registers viewer
* break on exceptions (accessing inaccessible VRAM, read unitialized WRAM and HRAM, echo ram access, access locked external ram, disable video outside vblank)
The feature sets for both FCEUxd and BGB seem very similar to me. There's even conditional breakpoints in BGB. BGB has probably the best debugger available in any emulator for any system. |
HyperLamer
Posts: 2534/8210 |
NO$ = very buggy, not powerful enough.
BGB = crappy interface, still not powerful enough. (I'm talking a LOT of power here. ) |
dan
Posts: 283/782 |
What about BGB? It's got a debugger now. |
windwaker
Posts: 693/1797 |
No$GMB, is kinda both  . I've found it to be buggy on occasions, especially when dealing with a lot of sprites on the screen. |
AJ 187
Posts: 10/15 |
HH: Have you tried No$GMB yet? (Or would that fall under "buggy"?) |
HyperLamer
Posts: 2517/8210 |
Originally posted by dan
I do hope that turn it into a GB/GBC emulator was a joke, though. 
Hell no. I long for a truly powerful, non-buggy GB debugger. It would be a big project but essentially all you'd have to do is change the opcode handlers and such.
GBA, on the other hand... Could be done but not by me. |
Parasyte
Posts: 167/514 |
Originally posted by AWJ
One useful feature would be to see the current state of the mapper--which PRG and CHR banks are loaded at which addresses, which nametable mirroring mode is currently in use (for mappers like MMC1 and MMC3 that can change the mirroring with a register write), et cetera. Right now seeing which banks are currently loaded requires looking at the CPU address space in the debugger and comparing it with a copy of the ROM loaded in a hex editor. And the only way to find out what mirroring a game is using is to trap writes to the mapper register that controls it.
It's not too difficult to find out which PRG bank is swapped into memory at any given moment. All you have to do is scroll to any ROM address in the disassembler and hover your mouse over the vertical "inline assembler" box. Below the disassembly output, it will tell you the memory address, as well as the file address of the hover. This screenshot shows the feature in action. (NOTE: This screenshot is from an older build. The most recent debugger window looks just a bit different.)
Having a seperate window to list current hardware states would be pretty ugly. You would need a seperate handler for each mapper.
On the other hand, name table mirroring shouldn't be difficult to add at all. |
bbitmaster
Posts: 39/103 |
Someguy; I still do very much plan on making a disassembler that allows that feature, but it won't be done in time for christmas because it's turned out to be a much larger project than what I'd planned for. |
Someguy
Posts: 134/397 |
That joke is possible because he'd just have to mod VBA, looking at the features and functions of FCEUXD, and VBA has several debugging tools allready, I wish more emulators were like it. The thing I'd love to see the most is that feature that makes a source code out of the rom by playing all the way through it and having it read the stuff and all that. |
Jaspile
Posts: 78/133 |
at least, wouldn't it be not *that* hard to convert it into a Snes debugger as the processors are kind of similar ?
I'm talking with almost none knowledge about all of this, so this is a simple question... |
dan
Posts: 280/782 |
Well, the original FCE Ultra is released under the GPL, so yes, it's safe to assume that the source code will be released. I do hope that turn it into a GB/GBC emulator was a joke, though. |
HyperLamer
Posts: 2491/8210 |
Alright, I'm convinced. Assuming it's not chock full of bugs (which I somehow doubt ) this is gonna be the best debugger ever.
What are the chances I could get a copy of the final source code and try to turn it into a GB/GBC emulator?  FCEUDXD4GBC, got a nice ring to it. |
AWJ
Posts: 2/3 |
One useful feature would be to see the current state of the mapper--which PRG and CHR banks are loaded at which addresses, which nametable mirroring mode is currently in use (for mappers like MMC1 and MMC3 that can change the mirroring with a register write), et cetera. Right now seeing which banks are currently loaded requires looking at the CPU address space in the debugger and comparing it with a copy of the ROM loaded in a hex editor. And the only way to find out what mirroring a game is using is to trap writes to the mapper register that controls it.
The debugger in SNES9x has a "view hardware features used this frame" command which tells you at a glance what screen mode is being used, the locations in VRAM of the pattern tables and name/attribute tables for each layer, the scroll position of each layer, what each of the HDMA channels is doing, and such. Here's an example of its output:
> w
V-line: 0, H-Pos: 8
Screen mode: 1, (BG#2 Priority)Brightness: 15
V-blank NMI enabled
H-DMA 0 [4] 0x7F8A00->0x2126 inc repeat 0x7F8380 indirect addressing
H-DMA 1 [3] 0x7F8A18->0x2111 inc repeat 0x7F10F8 indirect addressing
DMA 6 0 0x7FF220->0x2104 Num: 0 inc
VRAM write address: 0x5633(Byte), Full Graphic: 0, Address inc: 1
BG0: VOffset:12, HOffset:12, W:32, H:32, TS:16, BA:0x5000, TA:0x0000
BG1: VOffset:12, HOffset:12, W:32, H:32, TS:16, BA:0x5400, TA:0x0000
BG2: VOffset:0, HOffset:0, W:32, H:32, TS:16, BA:0x5800, TA:0x3000
BG3: VOffset:0, HOffset:0, W:32, H:32, TS:8, BA:0x3000, TA:0x0000
Main screen (always on): BG0,BG1,BG2,OBJ,
Sub-screen (always on): BG0,BG1,BG2,OBJ,
Window 1 (255, 0, 17, 17): BG0(I-XNOR),BG1(I-XNOR),BG2(O-OR),OBJ(I-XNOR),COL(I-XNOR)
Window 2 (255, 0): BG0(O),BG1(O),OBJ(O),COL(O)
Fixed colour: 000000 |
ev0
Posts: 3/27 |
w00t
congratulations xD |
Someguy
Posts: 130/397 |
I would of thought that GBA would be easiest to do it for because it seems so much is known about it and I think VBA is open source allready and many things about it are easy, even things like pointers which normally require adding 5040 and dividing by pi were made simple. However you probably won't do that but I don't care this will be great |
bbitmaster
Posts: 38/103 |
Originally posted by jman2050
I've said it before and I'll say it again...
Do this for the SNES... I don't care how long it takes or how much time you actually spend on this, but do this for the SNES. Nevertheless, this'll come in handy when I start my next hacking project (a Megaman hack...)
I have considered doing a snes debugger like this, and after looking over the source, I know it's certainly possible. I just haven't decided if I want to put forth the effort. There are just too many other things I'd like to do after I finish with this.
|
jman2050
Posts: 31/123 |
I've said it before and I'll say it again...
Do this for the SNES... I don't care how long it takes or how much time you actually spend on this, but do this for the SNES. Nevertheless, this'll come in handy when I start my next hacking project (a Megaman hack...) |
Gavin
Posts: 339/799 |
Originally posted by Emptyeye
I wonder, can this possibly be used for non-traditional hacking purposes? What I mean is stomping out potential crippling bugs in games (I'm thinking specifically of the "Scuzz never falls down" glitch in Level 10 of Battletoads...looking at the code, figuring out what it is that causes him to not fall down, and editing it)...in all, if someone decided to go that route, this could be a very useful tool indeed beyond the more traditional hacking applications.
Granting, you can do this anyway, but something like this seems like it would make it a whole lot easier.
actually it certainly can. And FCEUXD has a special option that would be extremely helpful finding something like this, along with the normal breakpoint settings for the debugger, there is a very useful option to "Break on Bad Opcode". Now, normally a game should pretty much never be reading a Bad Opcode, it means that something bad happened to the game and the PC was thrown into oblivion, or a bank wasn't swapped at the correct time, or any other number of oddities that can make a game crash.
i just recently used the bad opcode breakpoint in conjunction with the trace logger to find the code executed directly before the game crash. it's really amazing what this thing can do  |
| This is a long thread. Click here to view it. |
|
hukka
