It is currently Sun May 26, 2019 3:02 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Sun Dec 30, 2018 10:48 pm 
Offline

Joined: Tue Dec 04, 2018 2:28 pm
Posts: 44
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)


Top
 Profile  
 
PostPosted: Sun Dec 30, 2018 11:05 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3681
Location: Indianapolis
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.


Top
 Profile  
 
PostPosted: Sun Dec 30, 2018 11:11 pm 
Offline

Joined: Tue Dec 04, 2018 2:28 pm
Posts: 44
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.


Top
 Profile  
 
PostPosted: Sun Dec 30, 2018 11:32 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3681
Location: Indianapolis
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.


Top
 Profile  
 
PostPosted: Mon Dec 31, 2018 3:05 am 
Offline

Joined: Tue Dec 04, 2018 2:28 pm
Posts: 44
padding area?
how do you tell if something is padding or not?

Did you mean $0000 & $00FF as well?


Top
 Profile  
 
PostPosted: Mon Dec 31, 2018 4:00 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3681
Location: Indianapolis
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.


Top
 Profile  
 
PostPosted: Mon Dec 31, 2018 4:24 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11357
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Mon Dec 31, 2018 11:56 am 
Offline

Joined: Tue Dec 04, 2018 2:28 pm
Posts: 44
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.


Top
 Profile  
 
PostPosted: Mon Dec 31, 2018 3:49 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3681
Location: Indianapolis
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group