They will probably be easy to
find. Maybe not easy to modify. In programming, the "low level" things are defined and can't change. They can't change because they are based on what the hardware needs to properly give output and the hardware can't change once shipped.
The 6502 CPU is used by many things. It runs Asteroids and NES. Asteroids and the NES have very different graphical and sound capabilities. This is what makes Asteroids... well. Asteroids. And it's what makes the NES. Well. The NES. But since the same CPU is running them, how does it give different output? The answer is a defined list of locations, that when read from or written to, cause the hardware specific things to happen.
When I am looking at a game in the FCEUX debugger I know what those locations are and what they do having read about them previously. If you don't have the knowledge, it's not a helpful way to learn. You have to get that knowledge
first. And the way to do that is reading documents and tutorial code.
To find any scrolling code, you'd look for $2005. https://github.com/captainsouthbird/smb3/search?utf8=%E2%9C%93&q=2005&type=
You'd look for $2005 because that's the defined way to make the NES scroll: https://wiki.nesdev.com/w/index.php/PPU_registers#Scroll_.28.242005.29_.3E.3E_write_x2
There's just one result in that SMB3 disassembly because the author labeled it to something else (PPU_SCROLL). Okay, fine. So we search for that: https://github.com/captainsouthbird/smb3/search?utf8=%E2%9C%93&q=PPU_SCROLL&type=
And there are a few results. One is this:
Code:
LDA <Horz_Scroll
STA PPU_SCROLL ; Horizontal Scroll set
LDA <Vert_Scroll
ADD Vert_Scroll_Off ; Apply vertical offset (used for??)
STA PPU_SCROLL ; Vertical scroll set
The game writes a value from locations in RAM called Horz_Scroll and Vert_Scroll. So those two variables are what control scrolling, but now we are at the point where things can be done in a unique way because how Horz_Scroll and Vert_Scroll are set up could be any way. The only thing the hardware cares about is the final store to $2005. But still, let's go deeper. Let's search for that RAM.
https://github.com/captainsouthbird/smb3/search?utf8=%E2%9C%93&q=Horz_Scroll&type=
This is where the results get dense. One of the results is this, however.
Code:
.org $F4
Scroll_OddEven: .ds 1 ; 0 or 1, depending on what part of 8 pixels has crossed (need better description)
Controller1Press: .ds 1 ; Player 1's controller "pressed this frame only" (see Controller1 for values)
Controller2Press: .ds 1 ; Player 2's controller "pressed this frame only" (see Controller2 for values)
Controller1: .ds 1 ; Player 1's controller inputs -- R01 L02 D04 U08 S10 E20 B40 A80
Controller2: .ds 1 ; Player 2's controller inputs -- R01 L02 D04 U08 S10 E20 B40 A80
.ds 1 ; $F9 unused
.ds 1 ; $FA unused
.ds 1 ; $FB unused
Vert_Scroll: .ds 1 ; Vertical scroll of name table; typically at $EF (239, basically showing the bottom half)
Horz_Scroll: .ds 1 ; Horizontal scroll of name table
.ds 1 ; $FE unused
PPU_CTL1_Copy: .ds 1 ; Holds PPU_CTL1 register data
This reserves locations in RAM for variables. We start at $F4 (the .org) Scroll_OddEven gets assigned to $F4, Controller1Press gets assigned to $F5 etc.
Horz_Scroll ends up at $FD in RAM. And Controller1 ends up at $F7 in RAM. Let's verify if what we've learned is correct.
Marked in blue is $F7 (Player One's controller). Marked in red is $FD (The horizontal scroll position). Note that when buttons are pressed, the blue value changes. Note that when the game scrolls right, $FD increases in value.
That's more or less the process for figuring out code you didn't write. But if you don't have the base knowledge of the hardware, the process breaks down. I have never read anything about how to hack games. I just realized after programming for a while that I knew how to.
But I started WAY smaller than scrolling. Even one direction scrolling on NES is not that simple. To make the camera move, it's true that all you have to do is write different X and Y values to $2005. (Well... you have to write to $2000 sometimes as well, but I'll skip that for now.) But that's just the camera. You also have to write the new data to the map itself, and that's a little hairier.
Anyway, start learning (from
Nerdy Nights or
easy6502) right now! Time spent learning now will only increase the likelihood the knowledge you have will be sufficient to modify NES Maker by the time you get access to it! And who knows, you may even end up having a game before NES Maker gets out of beta!
And you can totally ask questions! In this forum, or on
NESdev. (NESdev's the better bet. I'm good, but I'm just one guy. NESdev is
filled with knowledgeable people.)
edit:
A human isn't going in and giving names to every single thing.
That's not quite true. What NES Maker seems to do is put together a bunch of individual .asm files which were TOTALLY written by humans and would TOTALLY have comments and names.
The part that's generated would be data (like the screen data or palette sets.) But even then, I'd bet they'd still have names like:
Code:
palette_set_00:
.db $00, $01, $05;... each palette index
screen_54:
.db $E1, $52, $03;... more data for the screen
And each byte wouldn't have a name, but each byte wouldn't have a name even if it was written by a human either, usually.
Like in my tool
I-CHR, I totally have readable source for the actual code. The I-CHR exe just hacks the different data into the I-CHR ROM. Similar sort of thing. (Except I didn't choose to release the source for my I-CHR ROM. I've gotten the impression NES Maker will have the source to its scripts.)
The image I posted earlier was some of the I-CHR's ROM code, though.
Edit 2: As an example, here is some autogenerated content from a tool I wrote:
Code:
met16sets_bank00:
.db $03;Offset to access 16 set $00
.db $14;Offset to access 16 set $01
.db $25;Offset to access 16 set $02
.dw bank00_meta16_00_00
.dw bank00_meta16_00_01
.dw bank00_meta16_00_02
.dw bank00_meta16_00_03
.dw bank00_meta16_00_04
.dw bank00_meta16_00_05
.db $00;Frame Delay << 3 | Frame Count
.db $00+bgchrstart;CHR Set 00 for frame 1
.db $00+bgchrstart;CHR Set 01 for frame 1
.db $01+bgchrstart;CHR Set 02 for frame 1
.db $02+bgchrstart;CHR Set 03 for frame 1
.dw bank00_meta16_01_00
.dw bank00_meta16_01_01
.dw bank00_meta16_01_02
.dw bank00_meta16_01_03
.dw bank00_meta16_01_04
.dw bank00_meta16_01_05
.db $00;Frame Delay << 3 | Frame Count
.db $03+bgchrstart;CHR Set 00 for frame 1
.db $04+bgchrstart;CHR Set 01 for frame 1
.db $05+bgchrstart;CHR Set 02 for frame 1
.db $06+bgchrstart;CHR Set 03 for frame 1
.dw bank00_meta16_02_00
.dw bank00_meta16_02_01
.dw bank00_meta16_02_02
.dw bank00_meta16_02_03
.dw bank00_meta16_02_04
.dw bank00_meta16_02_05
.db $83;Frame Delay << 3 | Frame Count
.db $07+bgchrstart;CHR Set 00 for frame 1
.db $08+bgchrstart;CHR Set 01 for frame 1
.db $09+bgchrstart;CHR Set 02 for frame 1
.db $0A+bgchrstart;CHR Set 03 for frame 1
.db $07+bgchrstart;CHR Set 00 for frame 2
.db $08+bgchrstart;CHR Set 01 for frame 2
.db $09+bgchrstart;CHR Set 02 for frame 2
.db $0B+bgchrstart;CHR Set 03 for frame 2
.db $07+bgchrstart;CHR Set 00 for frame 3
.db $08+bgchrstart;CHR Set 01 for frame 3
.db $09+bgchrstart;CHR Set 02 for frame 3
.db $0C+bgchrstart;CHR Set 03 for frame 3
.db $07+bgchrstart;CHR Set 00 for frame 4
.db $08+bgchrstart;CHR Set 01 for frame 4
.db $09+bgchrstart;CHR Set 02 for frame 4
.db $0D+bgchrstart;CHR Set 03 for frame 4
It even auto generates comments describing the data!