It is currently Sun May 26, 2019 2:13 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Fri Dec 28, 2018 4:42 am 
Offline

Joined: Tue Dec 04, 2018 2:28 pm
Posts: 44
I understand a bit more, and managed to create a simple new gamegenie code for highspeed pinball.
I been experimenting with different games, but one thing I'm confused about is

"read breakpoints", "write break points", and "execute breakpoints"
Sometimes I debug an address, and not sure which to use.. and sometimes none of these do anything once I found the address.
Any clue which one to use and when?

There's also some options I never used before.
"forbid", "CPU mem" "PPU mem" , "sprite mem"

Lastly there's "break on bad OPcodes"


can anyone explain these to me? At this point, it's a guessing game. I read some definitions on these.. but maybe someone can explain it better or give examples.


Top
 Profile  
 
PostPosted: Fri Dec 28, 2018 5:20 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2510
Location: DIGDUG
Maybe some examples would help your understanding?

Let's say I wanted to find the music code, and I know the APU registers are at 4000. So I would set a breakpoint for writes to 4000-400f. That's a CPU address.

If I wanted to find the palette update code, I would set a write for 3f00 in the PPU. If you look at the code, when it breaks, it's probably STA $2007. The 2006 2007 registers are how it accesses the PPU, but if we had just set a break on CPU 2007, it could be anywhere. Tiles. Tilemap. So to isolate just writes to the palette... writes to 3f00-3f1f in the PPU.

I wouldn't set a break for OAM (Sprite memory), lets skip that.

Now, let's say after investigating, you decid that RAM address 23 is # of lives, and you want to find code for when it is set to 5 at the start, so you set a break for writes to CPU address 23.

Now, let's go back to music. After finding the general area for music with breaks on APU registers, you want to break at the start of the music code each frame. So you scroll up, and locate the start of the subroutine... maybe the first line of code after an RTS. See the address of that code, set a break for execution at that address. I think double clicking the line or something brings up the option.

Many games have multiple banks. So you might want to set a conditional break, bank = #. I think that's something like K == #1, where 1 is the bank number.


You shouldn't have to worry about "break on bad opcodes" if you're working with commercial games. The 6502 didn't assign an opcode to every number, so some values will freeze the CPU requiring a reset (on real hardware).

If you're curious, here's all the bad opcodes. Search for "CRASH"

http://visual6502.org/wiki/index.php?ti ... 56_Opcodes

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Fri Dec 28, 2018 12:06 pm 
Offline

Joined: Tue Dec 04, 2018 2:28 pm
Posts: 44
oh, it deals with crashing you say.
that might come in handy for "Bucky O Hare Nes". there's a level that hard crashes.. not sure if it's a bad rom or what (I got past it back then with disabling random addresses).


good examples. but are you supposed to use "execute" & "read".. I get confused when write fails. Does it mean, it won't work for the address, and I should try the ones above/below.. or certain things will never break, and I can only look at the hex editor and guess.


Top
 Profile  
 
PostPosted: Fri Dec 28, 2018 12:50 pm 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
If you want to know when an address is read by some code, use a read breakpoint. If you want to know when it's written to by some code, set a write breakpoint. If you want to know when it's executed as code by the CPU, set an execute breakpoint.

If you really don't know, then use all 3; they're not mutually exclusive.


Top
 Profile  
 
PostPosted: Fri Dec 28, 2018 6:12 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4077
Location: A world gone mad
Re: possibility of the ROM being bad: there are valid/proper dumps of Bucky O'Hare for NTSC and PAL. Below are the checksum details. If yours differs, then it very well could be a bad dump. You didn't specify what locale ROM you're working on, so: U means USA/North America (NTSC), E means Europe (PAL).

Code:
File: Bucky O'Hare (U) [!].nes
CRC32: 3C9622D3
MD5: 3C218418BC5B044BF0954CFBC1992C52
SHA-1: 1E8F1FCB0B77A6AC0B038FFD85B3CEC680BBFB57

File: Bucky O'Hare (E) [!].nes
CRC32: BA2860E3
MD5: F7F4F40DF3AE9FE4E9FC979E35A42956
SHA-1: 978BF462F24A96523F232B504FBCE2361B2EACCD


Top
 Profile  
 
PostPosted: Sat Dec 29, 2018 7:10 pm 
Offline

Joined: Tue Dec 04, 2018 2:28 pm
Posts: 44
Probably a bad dump.. and maybe there's many bad dumps of this game out there.

It's been a while since I touched this game, so not sure why I forced cheated through this game to get past the crashed levels.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 13 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