 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| 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:  hukka |
| 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 | ||
Parasyte Bullet Bill Level: 35  Posts: 356/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
| Why do the MVN/MVP instructions cause read breaks when writing, and write breaks when reading? Any particular reason for this behavior? (The instructions properly break on read and write, but also suffer from the aforementioned problem.) An example: $80/9104 54 80 80 MVN 80 80 A:0017 X:197A Y:0203 P:envmxdizCThis instruction properly causes a break when a read breakpoint is set on $80/197A. But it also [improperly] causes a break when a read breakpoint is set on $80/0203. Proper behavior would be breaking on: 1) Read on $80/197A. 2) Write on $80/0203. I would have to call this a bug report. ;\ |
|||
Geiger Buster Beetle Level: 34  Posts: 332/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
| Why do the MVN/MVP instructions cause read breaks when writing, and write breaks when reading? Because of the way I detect read / write. I knew about this one when I put the first release out, I just hoped no one would find it.  ;In a nutshell, I have each command classified as read, write, both, or neither. When a command goes to be executed, I see if it qualifies as the correct type of each breakpoint and then see if either of the operands match up. The MV commands are classified as both, and of course one of the operands matches up, so it signals the breakpoint. Fixing it would not be extremely difficult, but it would put a lot of conditional testing in that would get checked every time for commands that make up less than 1% of the total set. I was not real keen on adding that overhead (though I do not know how noticeable it would be). If it is a significant problem, I suppose I can go ahead and fix it. BTW, I am still looking into Aero. It is just taking a really long time. Due to all the extra looping Mark 8 did compared to Mark 9, I have to synchronize the files up by removing all the extra looping. It can take 10 to 30 minutes per file to do this. I think I finished file 29 Friday. Mark 9 has 98 log files. ---T.Geiger |
|||
|
Parasyte Bullet Bill Level: 35 Posts: 358/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
| Well... All you would really need to do is check the breakpoint type, and compare the address with the source (X reg) for reads, or the destination (Y reg) for writes. You could also go further and check the address against either if both read and write are enabled on the breakpoint. That only adds [a maximum of] two additional if-statements, considering you already need one statement to do the checking currently. That certainly won't add a whole lot of overhead. Anyway, I say it's imperative to fix regardless of any speed decrease. |
|||
|
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: 3690/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
So where exactly do I get this hexedit.dll it's complaining about? And why do people insist on using such arbitrary formats to save a measly 100K?  |
|||
|
Parasyte Bullet Bill Level: 35 Posts: 363/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
| Download the full release: http://www.geigercount.net/crypt/Snes9X1.43.ep9r6.7z | |||
MathOnNapkins Math n' Hacks Level: 67  Posts: 1576/2189 EXP: 2495887 For next: 96985 Since: 03-18-04 From: Base Tourian Since last post: 1 hour Last activity: 32 min. |
| ||
Originally posted by HyperHacker The phrase "Beggars can't be choosers" comes to mind regarding the 7zip format. Geiger has said that it is to reduce bandwidth on his server. So either he's compulsive or is on a tight bandwidth budget. (edited by MathOnNapkins on 03-14-05 03:26 PM) |
|||
|
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: 3709/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| Well the key word is 'arbitrary' here... Also, joypad support seems to be completely broken. I got it all set up nicely, then clicked Cancel because it's right where OK should have been.  Now it just kinda assigns the button I press to something completely random. It's also very quiet... Being able to set breakpoints for a range of addresses would be nice too, and disabling one then clicking the game window should actually disable the breakpoint. Maybe the 'next op' button actually going to the next instruction instead of the same one over and over...(edited by HyperHacker on 03-14-05 09:11 PM) (edited by HyperHacker on 03-14-05 10:55 PM) |
|||
|
Geiger Buster Beetle Level: 34 Posts: 333/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
| Geiger has said that it is to reduce bandwidth on his server. So either he's compulsive or is on a tight bandwidth budget. Actually, it is a bit of a murky grey area as to whether I am supposed to have a server on this network at all. So the less bandwidth it uses, the less likely it is to get noticed. joypad support seems to be completely broken. I just tested the control setup with my PS2 controller and a USB converter. While it seems to be a bit quirky, I was able to get it to setup properly. I went ahead and tested the official version and it displayed the same quirks. Its their bad code. I already presumed it was since I have never touched that section. ---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: 3721/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
Even so, it'd be nice to have it fixed... I know it's not really your problem, but it does affect people who are using your program in such unpleasant ways as forcing them to use the keyboard to play.  And you could always host it on Geocities... |
|||
|
MathOnNapkins Math n' Hacks Level: 67 Posts: 1592/2189 EXP: 2495887 For next: 96985 Since: 03-18-04 From: Base Tourian Since last post: 1 hour Last activity: 32 min. |
| ||
Originally posted by HyperHacker That's what 'step into' is for :p edit: deletered b/c Parasyte answered it. edit2: I've also been getting sketchy results when dealing with savestates and breakpoints. Often if I go to a savestate it forgets my breakpoints until I click on the breakpoint button and "refresh" it. edit3: regarding trace using the keyboard: when I turn on trace, then turn it off, and then turn it back on again, sooner or later (2 - 4 tries) I lose the ability to turn trace off. This results in me having to force quit the emulator and something like 1500 empty logs files are created in a matter of a few seconds. O_o. I've tinkered with the trace settings, and narrowed it down to one thing that might cause it. In the trace from dialog, if "to:" is set to 0, trace toggling will crash the emu as above.  since this is the default setting, you are setting people up for a high % of unintentional user error. I think it would be best to have those values as the minimum address of the rom and the "to:" as the maximum. btw, those are SNES addresses, right? Not file addresses I would think.(edited by MathOnNapkins on 03-16-05 05:06 AM) (edited by MathOnNapkins on 03-16-05 05:42 AM) (edited by MathOnNapkins on 03-17-05 06:12 AM) (edited by MathOnNapkins on 03-17-05 04:44 PM) |
|||
|
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: 3768/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| Yeah, I found that. What's the point of 'next op' anyway? |
|||
|
MathOnNapkins Math n' Hacks Level: 67 Posts: 1594/2189 EXP: 2495887 For next: 96985 Since: 03-18-04 From: Base Tourian Since last post: 1 hour Last activity: 32 min. |
| ||
| by telling you what is up ahead (the next operation) you can decide whether to execute it or not. Since you can skip instructions too. | |||
FloBo Koopa Level: 17  Posts: 27/101 EXP: 20723 For next: 4020 Since: 09-11-04 Since last post: 3 days Last activity: 13 hours |
| ||
| Sorry for posting dumb questions, but I just don't know how to handle this. I want to run my game until a certain breakpoint in the rom (when a particular offset is read). So I open the rom, add the correct breakpoint and click on run. But the Program just executes the next command and prints it out to the text-output. And if I want to go forward in program code, I have to push Step into again and again. If I push the reset button and the the Run-button, my rom is running at full speed but the breakpoint I inserted doesn't make it stop anymore. So can anyone tell me: how do I run my game at normal emulation-speed up to the breakpoint I inserted? Cause I just don't know what I did wrong to make this little thing work... |
|||
|
Parasyte Bullet Bill Level: 35 Posts: 365/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
Originally posted by MathOnNapkins You must be using Windows 98? The 'output box' is a standard multi-line edit box, which has a maximum size of 65,535 bytes on Win98. (Each character is 1 byte, and each 'new line' consists of 2 bytes.) If you had large chunks of diassembly, that would explain the problem you experienced. (Try it, disassemble a few thousand lines, and press "Next Op" to see if it's pronted or not. It shouldn't be too difficult to overflow the text buffer on Win98.) FloBo: After setting the breakpoint, press the Run button. If it breaks at the wrong address, press Run again. Just continue pressing Run until it breaks where you want it to. If you reset the game at any time, the breakpoints you have set will be DISABLED, and must be re-enabled manually. (This is an issue that was brought up earlier) Step Into is used to step through code one instruction at a time. Use Run, instead. (edited by Parasyte on 03-17-05 09:01 AM) |
|||
|
MathOnNapkins Math n' Hacks Level: 67 Posts: 1597/2189 EXP: 2495887 For next: 96985 Since: 03-18-04 From: Base Tourian Since last post: 1 hour Last activity: 32 min. |
| ||
| Parasyte: yep. <3 | |||
|
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: 3779/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| Hmm, this thing sure likes to crash when closing the cheat menu, and occasionally corrupts the ROM when doing so. Also, editing register values and breaking when a register has a certain value could be infinitely useful... |
|||
|
MathOnNapkins Math n' Hacks Level: 67 Posts: 1601/2189 EXP: 2495887 For next: 96985 Since: 03-18-04 From: Base Tourian Since last post: 1 hour Last activity: 32 min. |
| ||
Originally posted by HyperHacker cheaters never prosper... but the thing about register breakpoints is good. If you've ever used Sneqr you'd know that the emu sucks, but has a damn good debugger (obviously not as full featured as this). But out of all the debuggers before this, I'd say it's the best. And it has the ability to wait for an opcode prototype. ex: w lda would wait for a lda command to pop up. w lda #$40 would wait for that specific instance of lda (with #$40) to pop up. |
|||
|
Geiger Buster Beetle Level: 34 Posts: 334/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
| this thing sure likes to crash when closing the cheat menu Yes, that is a long-time bug that I know of well. Not sure if its their code or mine causing the problem (I would guess it is their code, since I have not really mucked around with that particular window). The real issue is that I can not reproduce the crash consistantly, and never when I am in debug mode. If someone can give me a step-by-step that reproduces the problem every time, I would be very grateful. ---T.Geiger |
|||
|
MathOnNapkins Math n' Hacks Level: 67 Posts: 1603/2189 EXP: 2495887 For next: 96985 Since: 03-18-04 From: Base Tourian Since last post: 1 hour Last activity: 32 min. |
| ||
| Since it's more than a few posts back I'll just note that there are some bugs I found in that post (the one with many edits). I didn't know if you read them given you only mentioned hyperhacker's post. The trace problem is by far the worse of the two. edit (4, technically, since it's a continuing bug report): eugh, the water gets more muddy. I confirmed beyond any doubt that the GSD tracing code screws with the 3D triforce scene in Zelda 3 (my baby). I had thought it had disappeared in this release (was present in mark 5 - 8 at least), but that was only b/c trace handling code doesn't seem to be active by default. Once activated, the triforce sprites do not come together in their normal way (rotating). They come in as fixed triangles each on its own linear path. You'll have to watch the whole animation to understand what I mean. My guess is that the code interferes with vblank or some type of DMA where the rotations of that sprite would get written to VRAM. I'm obviously no expert on the subject. As far as how I determined the above, I clicked "CPU" in the logging section. Resetting several times to see the consistency, you'll notice that logging is turned off on reset. But that alone doesn't disable the tracing code. But, clicking it on again, and then turning it off will. And the results show once you reset - it will be normal again. All this came about while I was trying to figure out how to use the tracing features of this version. I'm sorry but I find them utterly incomprehensible. in order to get an actual trace file to appear, I have to run through a lot of steps. I will mention before going into detail that the task I was trying to perform was to create a compilation of as much assembly from the game as possible, i.e. a quasi disassembly from playing through all or most of the game. That would require being able to trace from the very first instruction executed. 1. First, I have to make sure" trace to" is not 0. (due to the aforementioned problem of crash + thousand or more log files) for some reason "trace to" = 1 seems to work just fine.  . oh well. 2. Then I have to click reset. 3. Then I select "CPU" under the tracing options checkboxes. Steps 1 and 2 are actually interchangeable. But step 3 must come last b/c resetting the game turns the "CPU" check box to empty. (However, as noted above, the tracing code is still active, just nothing is being traced.) In addition, step 2 is required b/c if I load the game, do step 1, and then do step 3, without using reset, tracing somehow never activates. The emulator thinks it is tracing but it in fact not. Hitting the / button will give the message "Tracing End", but no log file will appear upon exit. This is in agreement with the all knowing triforce animation. It's actually rather fortunate about that triforce animation bug, or else I would not have been able to deduce what triggered these tracing bugs very quickly. So.... *takes a breather* sorry about the long posts but I'm not a terse guy I guess.  in conclusion, the tracing code is borked at the moment. Actually, the actual log files (when created) are perfect, no qualms there. This has to do with getting them to appear and not crash the emu. As Parasyte pointed out, I am indeed on Windows 98 SE, but I'm sure there are others. I don't have any access to other computers until a day or two from now, so if someone else wants to test out this stuff on a winxp or win2k platform go right ahead.Again, thanks Geiger for the debugger but lately I've been mostly cursing at it. FloBo: no idea. That sounds really borked too. would help if you posted the game, the offset, the type of breakpoint, and some example output. We can't read minds. (edited by MathOnNapkins on 03-18-05 06:09 AM) |
|||
|
FloBo Koopa Level: 17 Posts: 28/101 EXP: 20723 For next: 4020 Since: 09-11-04 Since last post: 3 days Last activity: 13 hours |
| ||
| @Parasyte: No. That still doesn't work. I also think you got me wrong on this. When I add a breakpoint at x80000 for example, the emulation brakes at EVERY command thats being executed when I press run. Means I'd have to press run a thousand times to finally get to the position where my REAL breakpoint is set. Any idea why this happens?! |
| 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 |
| | |
