VYSLYOET (B157 val: 7B cmp: E8)
ZASUAPLA (B158 val: 86 cmp: 03)
LENATXNY (867B val: 03 cmp: 3F)
Trying to get the marble to go turbo speed once it moves fast enough... still working on that.
What I managed to do though is change the LDA $03E8 (or E8 03 in the hex editor) to load 867B (7B 86).
I wanted to change the value of the LDA, so I searched the debugger for a undefined line, and then changed it's value to 03.
(The marble moves 3x fast when moving /.. which is correct, but only wanting it to do this once the normal speed is high enough)
In the future, if I want to change the value of a LDA, is this how you do it? Or did I make the code longer then it needed to be?
(I mean besides finding an undefined line with a partial matching hexadecimal.. like if E87B was undefined for example)
It may be possible to shorten the code, it depends on what else is in memory. There's a decent chance that there is an '03' byte in the somewhere in $8000-$FFFF that you can re-use. That would reduce it to 2 codes (address only). And since the original address is $03E8, there is a slimmer chance you can find an '03' byte at an address like $80E8, $81E8, through $FFE8. If one exists there, you don't need to patch the low byte of the address anymore, and it would be just one code (high byte of address).
edit: btw, searching $8000-$FFFF should be safe, since Marble Madness uses mapper with 32kB page size. With other mapper you might have to be more aware of the PRG page size and state.
Basically, you're saying I did it correct for "testing purposes".. there's no way to change the value without loading another address.. I mean for testing.
Would probably speed things up.
Yeah, for LDA $03E8 (lda absolute) that's one way to do it. Though I'd be a little concerned about changing an "undefined" byte unless you're absolute sure it's never accessed. If there is some kind of $00 or $FF padding area of memory, I would go for that first.
padding area?
how do you tell if something is padding or not?
Did you mean $0000 & $00FF as well?
If there's any obvious padding you'll usually find it near the end of a 16kB or 32kB bank boundary, so look around $BF00-$BFFF and $FF00-$FFFF. Some games like SMB1 probably don't have any free memory anywhere, but I doubt that's very common. If padding isn't found the obvious place, you could also look near the end of 256 byte page boundaries, like $xxF0-$xxFF. There is some incentive for developers to align their data (for indexing) on 256-byte page boundaries like that, because there is a performance penalty from an index crosses a page boundary.
Not sure about the $0000 $00FF question. I mean just look for long runs of $00 or $FF in the ROM.
It's worth mentioning that some games just fill unused parts of ROM with garbage from their dev system's memory. Which leads to some interesting finds sometimes. I'm not sure how common that is overall, though.
Do note that not all long runs of $00 or $FF are guaranteed to be unused... For example, look-up tables of 16-bit values may be split into two, one containing the low bytes and the other containing the high bytes, so it's not unusual for the table of high bytes to contain long series of $00 and $FF. To be sure you'll have to either do some code/data logging, or setup read breakpoints for the range you think is unused. If you can play the game for a long time without the breakpoints triggering or without the bytes in question being marked as data, then they're probably unused.
I'm thinking a simple "ctrl + F" in the hex editor would work in this case to find out if an address is ever called.
That works when you're looking for calls to a subroutine. Data in a table will be indexed, so that particular address will appear in ROM only as the first entry in the table (and for indirect indexed, may be in separate tables for high and low byte). The safest way to be sure is to use code and data logger (specific to FCEUX, or do other emulators do that also?) and play through the game.
Would be neat if there was a database of code/data logs for NES games. The logging capability is there, seems like there are a lot of controller input recordings for gameplay. Just a lot of work to automate it and compile the data.