Thanks for this reply Shiru.

Could you possibly explain to me in a conceptual way, how the "many text files with the code" are grouped together? ... Is it eventually all organized in ONE sequential list of commands ("the program")? ... Or is it that there is one core program with occasional instructions to "leave" and go to another, or to "retrieve" information from one of the other "text files"? Or are most of these extra files deposited by the cartridge in memory on the console while the program is running?

Or perhaps it is silly to ask these questions at the outset?

Those are great questions, not silly at all. The answers to them will become more clear over time, but a general answer follows:

It is optional whether a game program is contained all within one text file or multiple text files before assembled into a final binary ROM that the NES or an emulator reads. Neither an emulator nor the NES can know how many text files created it. The only reason multiple text files are ever used is to help the programmer split up their code into logical chunks. You might have a text file that deals with the camera,  a text file that deals with updating all enemies on screen, another to decode the map and perform scrolling, another for generic PPU operations, etc.  It's all about organization.  That leaves a ton of details out, but hopefully helps a little.


It took a bit for another part of your question to sink in. The NES can *potentially* see up to 64kb of ROM or RAM at any given time. However, the way the cartridge pins and memory pins are wired up to the NES, it can usually only see 2kb of RAM (8kb with wram), and up to 32kb of ROM at any given time. That 32KB of ROM is basically where your text files appear, in binary form. It is typically made up of two 16 kb chunks, and depending on the mapper they can be swapped out, like "windows" into the code that originally appeared in your text files.   2kb of ram is on the NES itself, any additional RAM has to be on the cartridge. All of your program code just stays right on the cartridge---and is read directly by the CPU with the help of the mapper on the cartridge, for letting the cpu dig into various 16kb chunks at a time. Again...I probably glossed over a lot of details, but trying to keep my answers as simple as I can.

Basically, you have to create a subroutine that is activated when something happens.  i.e. your score reaches a level, you die, you win, etc. 

Just have it set a flag that allows your subroutine to run.  This routine will switch the game state, load the status screen, clear the variables in the level RAM, and then sit there and wait for you to push Start or something.

Then you push start and it loads the next level, changes the game state, and dumps the player into the next level. 

It is challenging, but you just have to think:  Okay, what did I do to get the first screen to load?  Sprites, background, initilize all the RAM required to run the room, etc.  Do this every friggin' time you load a room or different level, set, death, and stuff. 

It would probably be easier with an example, but I really don't have time to whip up another tutorial right now.  Hope that helps though. 

This game structure is semi comprehensible to me. ...

With the question of emulation/console disparity I am coming from an experience with Vectrex, in which (someone else's homebrew game) looks PERFECT in an emulator, but VERY DISTORTED on the actual Vectrex. ... It appears to me that this is far less of an issue on NES (and other consoles), and that the NES is working with a much more straightforward paradigm of graphics display and organization. "Tiles" and "scrolling" are kind of a built functionality of this machine. Correct???? I know that Vectrex is a very strange point of reference, but in comparison there seems to be much more of a language and a modular structure to "drawing" the graphics on NES.

You say that "video timing is critical" though, and that time must be allowed for rendering, (if I understand correctly this "time" is tiny fractions of a second, in between other equally brief commands which are constantly being executed and re-executed in a cycle).  ... Is it common that major compromises need to be made to the (NES) game program in order to get it to LOOK the way you want it to?

Awesome succinct answer. Thank you.

LoadNametable:
  LDA $2002                         ;normal loading routine
  LDA #$20
  STA $2006
  LDA #$00
  STA $2006
SetNametable:
  LDA BG_ptr                        ;BG_ptr is a variable in your zero page which tells the game
  ASL A                                  ;which level you're on.  Everytime you beat a level, increment this.
  TAY
  LDA bkgd_pointer_table, y                 ;pointer table which takes the BG_ptr variable and
  STA AddrLow                                        ;tells it which level data to load.
  LDA bkgd_pointer_table+1, y
  STA AddrHigh

  LDX #$04
  LDY #$00
LoadBackgroundsLoop:
  LDA [AddrLow], y               ;load nametable
  STA $2007                      ;draw tile
  INY                            ;X is 0, so move on to get new counter number
  BNE LoadBackgroundsLoop
;;Outer Loop
  INC AddrHigh
  DEX
  BNE LoadBackgroundsLoop
  RTS

bkgd_pointer_table:  ;;table of addresses for backgrounds.  if BG_ptr is #$00, it will
                                      ;;load the first one.  #$01, the second.  etc
  .dw gamebkgd0   ;;level 0 background
  .dw gamebkgd1   ;;level 1 background
  .dw gamebkgd2   ;;level 2 background
  .dw gamebkgd3   ;;level 3 background
  .dw gamebkgd4   ;;level 4 background
  .dw gamebkgd5   ;;level 5 background
  .dw gamebkgd6   ;;level 6 background
  .dw gamebkgd7   ;;level 7 background
  .dw gamebkgd8   ;;level 8 background
  .dw gamebkgd9   ;;level 9 background
  .dw gamebkgd10  ;;level 10 background
  .dw gamebkgd11  ;;level 11 background
  .dw gamebkgd12  ;;level 12 background
  .dw gamebkgd13  ;;level 13 background
  .dw gamebkgd14  ;;level 14 background
  .dw gamebkgd15  ;;level 15 background

gamebkgd0:  ;a full table of tile numbers that fill up the screen.  you'll need one of these for
                         ;every ".dw" in the pointer table.
    .db $05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05, etc, etc

Khan and MRN, thank you very much for this.

KHAN - The script will be very helpful, I'm sure. I can't wait to implement it. What does dw stand for? I've only ever seen .db before.

MRN - Thank you as well. I think that was what was screwing me up...I kept trying to just re-load images, as opposed to initialize the ram, and doing everything over from the start.

As .db is a byte-sized chunk, .dw is a word sized chunk. 

.db $12 ; 8-bit number

.dw $1234 ; 16-bit number

MOST of the time, as in Kevin's example, it is an address in ROM. Some assemblers have different ways you can have a word-sized numeral for better readability, such as .addr (address):

.addr gamebkgd0   ;;level 0 background
.addr gamebkgd1   ;;level 1 background
.addr gamebkgd2   ;;level 2 background
; etc etc etc

That just depends on the assembler that you end up choosing though.

What are some classes one could take at say a Community College to get a better idea about programming.

I'm sure that varies school to school.  You'd just have to check their curriculum.  I doubt there would be anything directly assembly language related though.

  So .dw means Data Word, and .db means Data Byte?

Sounds about right!

Don't clear out all the RAM, just the stuff applicable to the rooms.

You can also use:
  .byte
  .word

I am taking a slightly different approach to learning 6502 than jumping right into the Nerdy Nights. I have read the first 4 tutorials but before I move on, I am trying to learn 6502 from scratch. Every book I have skimmed always begins with hex-dec-bin and doing math with these. The next thing covered is explanations of the 7 flags and operand formats, such as indexed direct and immediate. My question is for some of the veterans to tell us what stuff is key and most important to know in 6502. Just so we have an idea what things we need to have a good understanding of. I feel like ASCII code is not useful for NES game making, so I have not spent as much time on it as I have with HEX math. I am hoping for a response that might give us a very skeletal overview of what stuff is integral. Clearly, the 6502 books don't cover sprites, sound, controller input, or anything to make games - it's just about learning the actual language and its concepts.

Also, I am having a hard time with LDA/STA and remembering which does which. Sure, it might be easy for some, but I keep confusing the two. How do you guys go about this? Load the Accumulator and Store the Accumulator. Sound the same but do two completely different things. I hate having to look in my notes every single time. I need "hints" and "tricks" to memorizing key stuff.

Do you guys take notes? Do you write things down in a notebook or do everything using the computer?

Mostly general questions about approaches you take. Not necessarily specifics to a program I am working on. But that's because I haven't started my program yet. Your answers will help me move forward though!!

I mostly remember "Load" and "Store" as in you have to "Load" something to change it, and when you're done, you "Store" it when you're done. Like when you go grocery shopping. You store everything away in the cabinets and walk away. I don't really know how else to explain it. Just give it some time.

I think a lot of people that are learning to program are getting hung up on math. I have no idea what %01010101 is in decimal. I have no idea what $E4 is in decimal. When I need to know these things, I open up the Windows calculator, turn it to Hex or Bin, type in the value, then change it to Dec and it converts it for me.

The main thing you're going to have to understand is the various values of addresses on the Nintendo, because you're going to be manipulating them over and over and over.

The nametable you're going to be using 95% of the time is $2000. The sprites you're using will be starting at $0200 (or $0300 depending on where you put them.) The palette is at $3F00. All of these addresses are just things you're going to have to ingrain in your memory, because that's the stuff you're going to be changing.

Other than that, the main thing you're going to have to learn is how certain things are changed and when you can change them. Moving a sprite across the screen can be done at anytime. Changing a tile of the background can only be done in a very short time called Vblank, which sounds complicated, but there's a specific location in your assembly document where all this stuff goes. Eventually if you try to do too much there, it will run out of time and things start blowing up, so you have to be very careful.

I generally don't take notes, but I do have to open up some of the Nerdy Nights tutorials every now and then to remind myself on how to do certain things.

I build my entire games with only these commands haha.

LDA
STA
CMP
BEQ
BNE
BCC
BCS
LDX
CPX
TAX
TXA
LDY
TAY
TYA
CPY
ADC
SBC
JSR
JMP

Well, I guess that's more commands than I thought.  Still seems simple!

If you really need to, write it down on a sticky note (either a virtual one or a real one): "LDA: Load from memory to A, STA: Store from A to memory". You will without a doubt learn it by heart after using it for a a couple of weeks.

As for hexadecimal and other numbering systems, I agree with KHAN. The most important thing is to understand that all of the numbering systems are just different representations for the same number. It's also useful to understand some relations between them, for example the fact that a hexadecimal digit (0 through F) corresponds to 4 binary digits (bits) (e.g. $F = %1111). But don't get hung up with conversions.

Really? I thought you updated the sprite RAM and then used DMA in the VBLANK.
Can you use writes to $2003/4 outside NMI?

All you'd be doing is changing the value of $0300/$0303 (or whatever sprite you're moving), so yes, that can be done anytime.

Sorry, I was just nitpicking.
I meant, the sprites aren't actually changed when you change the sprite RAM.
But it is easy as changing it anytime you want, since you can just DMA one RAM page to the sprite OAM.

Or am I wrong here?

Oh, I see what you're saying.  Yes, if you're being nitpicky about it you are correct.  I'm just trying to explain things to people who have no idea what you're talking about (most people reading this thread).

That's correct. (Calling it "sprite RAM" is misleading though, better call it something like "shadow OAM" or "shadow sprite RAM" instead because "sprite RAM" is usually used to refer to the 256 byte sprite RAM that's inside the PPU).

Sorry.

I have a question. Is it common to interpret a value as a 2's complement signed number,
and use the negative values for left movement and positive values for right movement?
Could you then get away with just adding a value to the sprite's X value every time you move?
You know, instead of having to branch and subtract if you want to move left?
If this is a good idea, some example code would be appreciated.

An example or explanation of sub-pixel movement would also be nice.

I hope I'm making sense, thanks!

Ok, I will remember that, kiitos!

Yes.

Yes. Basically your signed number would be the X velocity here.

To get sub-pixel movement you would make the velocity a fixed point number, for example 8.8 fixed point (8 bits for the whole part, 8 bits for the fractional part, 16 bits total). The position also needs a fractional part, so you would make that a fixed point number as well.

Then just add the velocity to the object position on every frame, and modify the velocity depending on which direction you want the object to move. If you add a constant value to velocity on every frame, you get acceleration/deceleration.

The more code you write, it'll become more clear. Maybe try to come up with metaphors for yourself. I probably take it for granted, but I think of the accumulator as like, your workspace. LDA puts a number on your workspace. STA, "stores" something that had been on your workspace (but leaves a copy there) when you're done with what you had been working on. Not sure if that helps.

When I first did NES code, I had had some x86 background but had to look things up quite a bit to get a hang of 6502. New assembly languages will have a different feel but will use the same concepts, if that makes sense. Once you know binary, hex, bitwise operations, branches, addressing modes, 2's complement....etc. you can pick up any assembly language. Basically just keep at it.

It's hard to gain so much fluency in assembly language that you don't have to sketch something out "in pseudo code" first. I'm starting to get almost that comfortable with 6502, after one game and now working on another, but usually I have my devlog up while working, and I think "out loud" into my text document for quite a while before coding something. I usually break it down into lots of tiny chunks and work on them one at a time. I definitely wouldn't fit the stereotypical thought of "guy staying up late hammering out code at a million miles an hour" heck, sometimes I sit and think and write in my devlog and just sit there..for a long time, before actually coding anything. Even now, it is a slow process. I have no idea if this is normal or not, or if there are some folks out there who can do it way more efficiently, but....I'm able to do it and I'm happy I'm doing it.  I guess that's why I feel so compelled to get others into it or help out somehow. I know I'm not a genius, I just realllly want to do this stuff, even if I'm slow as moles' asses in january at it.