Register | Login | |||||
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
| |
1 user currently in Rom Hacking: |
Acmlm's Board - I2 Archive - Rom Hacking - Geiger's Snes9x Debugger Mark 9 | | | |
Pages: 1 2 3 4 5 6 7 8 9 10 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
User | Post | ||
Imzogelmo Blue Octorok Level: 11 Posts: 24/41 EXP: 5292 For next: 693 Since: 09-22-04 From: (Longview) Starkville, MS, USA Since last post: 15 days Last activity: 1 day |
| ||
I'd vote for C. | |||
Sokarhacd Ball and Chain Trooper Resistance is Futile You Will Be Assimilated Hab SoSlI' Quch Level: 61 Posts: 1041/1757 EXP: 1799888 For next: 76708 Since: 03-15-04 Since last post: 6 days Last activity: 4 hours |
| ||
Yah, I vote for C also, it seems like it would work best. | |||
Geiger Buster Beetle Level: 34 Posts: 301/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
when dragging the scroll bar to get to the bottom of ROM on the hex editor, you get an error about 1/4 of the way down, only happens when your viewing the ROM though. I think I know what the problem is. And it looks like the LoROM issue just got a lot more complicated. I am looking at the mapping in Snes9x again. A bank looks like this: 0000 - 1FFF . RAM 2000 - 3FFF . PPU Special Registers 4000 - 5FFF . CPU Special Registers 6000 - 7FFF . I have no freakin' clue 8000 - FFFF . ROM I had always been under the impression that the low and high banks were mirrored, but it looks like that is incorrect. (edit) Ah, okay. I was correct about mirroring, just incorrect about a LoROM's address range. Apparently, it uses the same range as a HiROM (C00000 to FFFFFF). So I have two problems to fix, the default LoROM range and how the data is displayed. The main problem I have with option C is that the data displayed will not match how it looks in the ROM itself. ---T.Geiger (edited by Geiger on 02-17-05 10:50 AM) |
|||
Sokarhacd Ball and Chain Trooper Resistance is Futile You Will Be Assimilated Hab SoSlI' Quch Level: 61 Posts: 1042/1757 EXP: 1799888 For next: 76708 Since: 03-15-04 Since last post: 6 days Last activity: 4 hours |
| ||
ok, then just go with B, only showing the LoRom, that will be less confusing. | |||
Imzogelmo Blue Octorok Level: 11 Posts: 26/41 EXP: 5292 For next: 693 Since: 09-22-04 From: (Longview) Starkville, MS, USA Since last post: 15 days Last activity: 1 day |
| ||
I agree. I was under the impression that the banks were mirrored to the high ones, and that changing either would effectively change both. Since it appears that this is not the case, option B would be preferable, so as to limit any misinterpretation. | |||
Geiger Buster Beetle Level: 34 Posts: 302/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
Bah, I am an idiot. Is it obvious yet that I have not spent more than about 10 minutes looking at LoROM stuff? Banks C0 to FF are primarily for expanded LoROMs. Banks 80 to BF are indeed normal LoROM, so I guess option C is right out. So here is how the question now stands. How would you people like me to fix this? A) Just leave it be B) Display high bank addresses only (8000 to FFFF) ---T.Geiger |
|||
Imzogelmo Blue Octorok Level: 11 Posts: 27/41 EXP: 5292 For next: 693 Since: 09-22-04 From: (Longview) Starkville, MS, USA Since last post: 15 days Last activity: 1 day |
| ||
Heh. You are most definitely not an idiot. I'd say B but with one caveat: Display something in the high banks just as a placeholder... like XX or --. That way, no thinking person will try to edit the "uneditable." By the way, have you got support for the JumboHiROM format? |
|||
Sokarhacd Ball and Chain Trooper Resistance is Futile You Will Be Assimilated Hab SoSlI' Quch Level: 61 Posts: 1043/1757 EXP: 1799888 For next: 76708 Since: 03-15-04 Since last post: 6 days Last activity: 4 hours |
| ||
Yeah, I agree with imzogelmo, I think that will be the best option. | |||
Geiger Buster Beetle Level: 34 Posts: 303/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
By the way, have you got support for the JumboHiROM format? The display works from the memory map Snes9x constructs. So, in theory, yes it should be supported. I have not actually tested this though, and you will need to put in your own address range for it (400000 to 7DFFFF). (edit) BTW, I think you are misunderstanding what I mean by option B. It would look something like this: 808000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 808010 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ... 80FFE0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 80FFF0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 818000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 818010 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ---T.Geiger (edited by Geiger on 02-17-05 11:54 AM) (edited by Geiger on 02-17-05 11:55 AM) |
|||
Imzogelmo Blue Octorok Level: 11 Posts: 28/41 EXP: 5292 For next: 693 Since: 09-22-04 From: (Longview) Starkville, MS, USA Since last post: 15 days Last activity: 1 day |
| ||
No, I'm not misunderstanding. I just don't like discontinuities. What I'm suggesting is something like this: ... 80FFF0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 810000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ... 817FF0 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 818000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ... IOW, the low banks would be explicitly "locked out" from edition. EDIT: Maybe someone who's more interested in LoROMs should give an opinion? I'm mainly a HiROM guy myself. (edited by Imzogelmo on 02-17-05 12:10 PM) (edited by Imzogelmo on 02-17-05 12:12 PM) |
|||
Parasyte Bullet Bill Level: 35 Posts: 301/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
There is no need to display inaccessible memory. Especially "just to have something there". I suggest you stay as close to the hardware as you possibly can. Do not mirror data if the hardware does not do so, etc. | |||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 3335/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
Originally posted by Imzogelmo I'd go with either that or just skipping the addresses entirely. Maybe make it an option. |
|||
Geiger Buster Beetle Level: 34 Posts: 306/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
I have a question about how you guys think GSD should work. I have plugged the hole in read / write breaks concerning special register $2180 (fill ram). However, there is nothing indicating why the emulator has stopped. For example, breaking on a write to 7EAC8D in Final Fantasy VI produces the following line in the debugger: $C3/18B7 8D 80 21 STA $2180 [$00:2180] A:0000 X:0000 Y:AC8D P:envMxdIZc The AC8D in the Y register is just a lucky coincidence; such will not always be true. So how do you think I should remedy this issue? ---T.Geiger |
|||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 3352/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
What exactly does that register do, activate some sort of memory-fill feature? If so, it shouldn't be too difficult to figure out why it's stopped (though you'd want to document it). You might consider making a different type of breakpoint for that, even. | |||
Parasyte Bullet Bill Level: 35 Posts: 303/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
I hate to say this, HyperHacker; look it up, lazy bones. The WRAM register is used as a linear read/write buffer. You write the [RAM] buffer address to *three bytes at $2181-$2183, then after every read or write to the byte at $2180, the data is read or written to that buffer address, and the address is incremented by one. In my opinion, there are two ways to go about handling this: 1) The method I would perfer is including the work address in the disassembly. Rather than seeing this: $C3/18B7 8D 80 21 STA $2180 [$00:2180] A:0000 X:0000 Y:AC8D P:envMxdIZc You would see this: $C3/18B7 8D 80 21 STA $2180 [$7E:AC8D] A:0000 X:0000 Y:AC8D P:envMxdIZc 2) Include an edit box somewhere within the debugger window that contains the "WRAM address". Similar to FCEUXD's method of displaying current scanline, PPU address, etc. * The upper byte appears to be masked. The upper seven bits of the address are 'locked' to 0111111b (0x7E) meaning the WRAM register can only access RAM at $7E:0000 - $7F:FFFF. |
|||
Geiger Buster Beetle Level: 34 Posts: 308/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
I may have misstated the problem slightly. The issue here is that with the way it currently prints, the user has no means of knowing which breakpoint caused the stop. This is a problem of identification. So far, I think Parasyte's first suggestion sounds the best, but I would like to hear any other ideas anyone has. ---T.Geiger |
|||
jman2050 Red Koopa Level: 19 Posts: 79/123 EXP: 33172 For next: 2605 Since: 03-21-04 Since last post: 10 days Last activity: 103 days |
| ||
I think a simple solution would be to display the actual breakpoints somewhere in the window, in a listbox perhaps, and when a breakpoint occurs just higlight the breakpoint in the list that triggered it. If it's a problem of identification, that seems like the optimal solution to me. | |||
Parasyte Bullet Bill Level: 35 Posts: 305/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
Why is identification an issue? It's really just a matter of connecting the dots; if you see a write to $7E:AC8D, it would be painfully obvious which breakpoint [of five] caused the break. (edited by Parasyte on 02-19-05 01:48 PM) |
|||
MathOnNapkins Math n' Hacks Level: 67 Posts: 1420/2189 EXP: 2495887 For next: 96985 Since: 03-18-04 From: Base Tourian Since last post: 1 hour Last activity: 32 min. |
| ||
Well I guess then it's a convenience issue? Or am I wrong | |||
Geiger Buster Beetle Level: 34 Posts: 309/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
Why is identification an issue? It's really just a matter of connecting the dots; if you see a write to $7E:AC8D, it would be painfully obvious which breakpoint [of five] caused the break. A write to $2180 is an identifcation issue, at present, to the user. I was just trying to restate the original problem, which was not totally clear from what I had said. DMA and HDMA related registers will also be an issue (though I will have to figure out which ones actually do indirect reading and writing first). ---T.Geiger |
Pages: 1 2 3 4 5 6 7 8 9 10 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
Acmlm's Board - I2 Archive - Rom Hacking - Geiger's Snes9x Debugger Mark 9 | | | |