NES Programming Tutorial : Init Code

Output :




Explanation :

* SEI stands for SEt the Interrupt-disable bit, we use it to disable IRQ interrupt.

* CLD stands for CLear Decimal, NES cpu doesn't have Decimal mode at all but we use CLD to make sure it is disabled!

* $ is a prefix for address in hexadecimal system starting from $0000 to $FFFF

* #$ is a prefix for immediate value in hexadecimal system starting from #$00 to #$FF

* #% is a prefix for immediate value in binary system starting from #%00000000 to #$11111111

* The rightmost bit is called bit 0 or lsb (least significant bit)

* The leftmost bit is called bit 7 or msb (most significant bit)

* So the name of the bits are like this : bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0

* LDA stands for LoaD Accumulator. Accumulator is a register of CPU, it is like a variable. It can hold max 8bit values starting from #$00 to #$FF

* STA stands for STore Accumulator. We can write value of Accumulator into an address

* PPU stands for Picture Processing Unit

* Some special addresses are called Port. CPU use Ports to control other parts like PPU, Joypads, etc

* Most of the Ports are bit wise. It means making their bit 1 or 0 have a special effect and meaning.

* $2000 and $2001 are PPU ports.



* With this code we Load the value #%00000000 ( = #$00) into A and then we write A to $2000. Setting the 7th bit to 0 stops NMI Interrupt from happening.



* We set the 3rd and 4th bits to 0 to hid the graphics. At start up there is nothing to show, right?

* $2002 is another PPU port. We can only read its value. It gives report about PPU. If 7th bit is 1 then it shows that vBlank is happening. Reading this port clears 7th bit and will stay 0 until the start of a new vBlank

* To find out the meaning of other bits of $2000, $2001, $2002 read this : PPU registers

* There are different kinds of Flags : Carry, Zero, Interrupt, Decimal, Overflow, Sign

* Executing an opcodes can set or clear these flags

* These flags together are called Processor Status

* Need more info about flags? then read this : CPU status flag behavior

* After each operation there is a result value. The 7th bit of the result is copied to SIGN FLAG. 0 shows positive result and 1 shows negative result

* BIT checks the 7th bit of $2002. If it is 0 vBlank is not happening. If it is 1 then vBlank is happening. SIGN FLAG gets the value

* BPL stands for Branch on PLus (positive sign). If SIGN FLAG is set to 0 then a jump will happen to its following label. It will jump until the SIGN FLAG is set to 1.

* ;PPU warm up : This loop runs until a new vBlank starts. We have to wait at least 2 vBlanks before using PPU. It needs time to become stabilized.

* LDX is similar to LDA. X is another register like A

* STA $0000, X : it is similar to this : A --> ($0000 + X). For example if the value of X is #$44, then the value of A will go into $0044.

* INX stands for INcrement X. For example if the value of X is #$44 then it will be #$45

* X can hold up to 8bit values, let's say X is #$FF, after INX it becomes #$00

* CPX stands for ComPare X register. It compares the value of X with its following value

* BNE stands for Branch on Not Equal. If compared values are not equal to each other then it will jump to its following label

* From $0000 to $07FF is 2KB RAM. We can store values like score, life, etc here to use later. At start up we have to clear the whole RAM



* With this code we set the 7th bit of $2001 to 1, and by doing so the whole screen becomes blue!

* Here is a more correct and optimized init code

/////////////////////////////////////////////////////////////////////////////////////////////////

How to use Debugger :

* Sometimes the game doesn't work as we expect, maybe because of a logical mistake in the source code.

* So how to find it? We need to use a tool called Debugger. We can run the game step by step and check the codes to find the error.

* In the above code the RESET label is under $8000, it means the game will run from that address. So let's use debugger from that address and find out what is going on!

* Run the game with FCEUX emulator

* Go to Debug > Debugger

* Click Add

* Type 8000 in the address box, click on Execute option, click ok

* This is called a breakpoint and it means when CPU want to read or write or execute a special address then stop the game and use debugger to run the game step by step.

* Go to NES > Reset

* Game stops running and debugger windows comes up

* On the first line it shows the instruction which is going to be executed



* Click on step into to run the instructions one by one



/////////////////////////////////////////////////////////////////////////////////////////////////

How to disassemble :

* An assembler (ASM6) converts the source code of assembly language to object code of machine language : Game.asm --> Game.nes

* A dissembler does the opposite : Game.nes --> Game.asm

* Disassembling is not accurate all the times because of some difficulties, for example it is not easy to distinguish between opcodes and data.

* The best disassembler that I found so far is : NESrevPlus

* It is easy to use : load your game.nes into it then save game.asm :



* Compare the original source code with disassembled one.

* Wow today was awesome, wasn't it?

/////////////////////////////////////////////////////////////////////////////////////////////////

Exercise :

Change the background color to Red.

/////////////////////////////////////////////////////////////////////////////////////////////////

Files :
asm6.exe
Assembler.bat
Game.asm

/////////////////////////////////////////////////////////////////////////////////////////////////

Former Level : NES Programming Tutorial : Interrupts
Next Level : NES Programming Tutorial : Background

I am usually setting 2001 to $1e to enable normal rendering. $80 would set the blue emphasis bit, but leave rendering off.

You should do an extra BIT $2002 before vBlank_wait1. The system can be reset in the middle of vblank with the vblank flag already set, which would make the first wait return immediately, and you really do need to wait the full 2 frames for the PPU to warm up before you can start using it. Writes to it may fail to have any effect until that point. Nerdy Nights' tutorial fails to do this, and even SMB fails to do it (but luckily the rest of its startup before it uses the PPU takes just long enough for the PPU to warm.)

So, an extra throw-away BIT $2002 before you start the wait loop will clear the bit just in case it's already inside a vblank period. (It's like a 10% chance that any reset is inside vblank, I think?) the vblank flag was spuriously left on at power on by the PPU (see wiki).

Also you can put the RAM clear in between the two vblank waits just to speed things up if you like. (Not too important, just a common practice.)

Edit: accidentally wrote $2000 instead of $2002.
Edit: clarified the real need for extra $2002 clear at init.

Typo: bit $2002, as reading $2000 instead returns the content of the PPU's I/O data latch and has no side effects. Fixed

Probability of reset in vblank is 20 in 262 on NTSC, 20 in 312 on Dendy, and 70 in 312 on PAL NES.

Also before the PPU warm up I think you may need to write $40 to $4017 (disables APU frame IRQ) and clear $4010 (disables DMC IRQ) in addition to clearing $2000 and $2001 that you already do.

In what way it is better?

@ rainwarrior
Thanks for the suggestion. I used LDA $2002, is that ok?



I used SEI which disables IRQ interrupt, do I really need to mess up with $4010 and $4017 really?
I do not want to confuse beginners with unnecessary codes, they can learn about them later, right?



I (and probably most of other beginners) prefer to use explicit style of coding and easy to read, even if it eats a lot of space!

LDA is fine, I just tend to use BIT out of habit because of its strong association with $2002.

SEI masks interrupts, but writing to $4010 and $4017 will disable and acknowledge any pending interrupts from those devices. I think it's good practice to write to them at init. If you ever CLI to start using interrupts you don't want to have an unacknowledged signal there that's been hanging around since reset, because it would immediately trigger the IRQ.

Also, you forgot to initialize the stack pointer! (LDX #$FF, TXS) An uninitialized stack doesn't matter in some naive cases, but there are lots of reasons why it does matter (e.g. debugging, or trying to reclaim some extra memory from the unused stack area.)

I don't really understand the "show screen" part of the code. There's no reason to write 0 to $2000 again, and you haven't initialized the screen with any data. You're using $2001 to show a tint on the screen, but you haven't initialized the palette, so on a real machine the colour might be more or less random anyway. Normally we would write at least the palettes and a blank nametable (and the scroll registers) before showing anything. Perhaps at least setting the "greyscale" bit in $2001 as well would insure that the uninitialized palette would be a non-black grey?

I didn't forget them, I omit them on propose because I want to make the tutorial as simple as possible and step by step.
If I write those code then I have to teach about them, while for this level I didn't use APU and Stack, right?
In each level I try to make the code easy to understand, I don't want to make a perfect and optimized code!

It's not better. It's what YOU are doing.

Storing $1e to $2001 is better, in the sense that it matches your comment...

Thank you

I, for one, am enjoying this discussion. My own example code, and major projects only do 2 V-blank checks before writing to PPU.

would a back to back check work? I seem to remember that checking 2002 clears the flag, so it seems like it would wait twice, if I...

You have to wait at least one full frame period.

If the player pressed the Reset button during vblank, the first loop will exit immediately because nothing has cleared the vblank flag. (Only the start of the pre-render line and reading $2002 clear it.) Then the second loop will exit at the start of the first vblank, but the PPU will still be unresponsive to writes until after the first vblank.

Sorry, I mean, these 2 v-blank checks, then another one I didn't mention, a little later.

Would this example count as 2? Assuming you weren't already in v-blank.

If you have these two loops and then burn at least enough cycles to finish vblank (2387 on NTSC and Dendy, 7566 on PAL NES) before writing to the PPU, it'll work. If you have these two loops and then a third loop later on before writing to the PPU, it'll work.

I think I may have muddied the waters slightly with this comment, so just to clarify...

I'm used to adding an extra BIT $2002 out of habit before I enter a BIT $2002 / BPL wait loop, because often that code can get entered mid-vblank, so it's necessary in any generic wait for vblank.

At reset, though, you still should have it but I think the reasoning is different. The PPU will power/reset consistently at the start of a frame, but the vblank bit of $2002 is random/unreliable (according to the wiki). So, the problem isn't that it might start in vblank, it's that $2002 might misreport a non-existent vblank before the first true vblank occurs, causing you to skip the first frame of wait if you don't clear it once before you start your loop.

On the Famicom or top-loader, a CPU reset might occur at any time during the frame but the PPU does not reset, so technically the reset could start you in the middle of vblank, but in this case the PPU is already warm so it's not an issue.


...or maybe this is just a semantics thing, because the "unreliable" vblank flag is probably caused by resetting during vblank?

Exactly. It's neither set nor cleared by externally applying the /RESET signal.

The wiki seems to suggest that it's set (or unreliable?) at power on as well.

NES users are used to having to reset a few times to get their game to work anyway, though. Sometimes it might be the software's fault.