Previous Week - 6502 ASM Sprites

Edited: Dain fixed formatting below!

Not sure why... I just re-saved and it fixed it. I'll take a look at the Apply-generated goulash.

Seeing that palette again...  Is there any way of knowing if $1D is black or a very dark grey?  The whole XD range of the palette actually isn't clear.

That palette isn't very accurate, it will be better to look at emulators like Nintendulator. PAL and NTSC will also be slightly different. Having 2 colors next to each other can blur them together or create new colors. And of course RF vs composite will be different too. Basically you have to test on a real NES and TV to see what it really looks like

I gave up on the last Nerdy Nights... I just don't have the know how for this kinda stuff. If you teach once person though Brian it is worth it to have just 1 new game.
~~NGD

Could someone explain the need for loading $2002 before the accessing $2006? Is it because vblank flag needs to be reset manually? Also, during the memory clear, is there any reason putting sprites outside the visible area? Or could the loop simply set everything to 0?

You can use a loop to set the sprites offscreen, or clear them. It's actually done that way in the reset code. Took me a long time till I noticed that myself.

$2006 is a 16 bit address. You write to it twice, once for the high byte of the address and once for the low byte. But at reset or when your code is running you may not know if the PPU is expecting the high or the low byte. If you write low but the PPU is expecting high then the address will be wrong. So reading $2002 resets the PPU to expect the high byte first.

Ah, so the 8 sprites per scanline even counts sprites that are turned off.

So, is it necessary to read $2002 as a precaution every time you are writing addresses to the PPU registers? Or are there only specific times?

Is it best (or is it necessary) to turn off sprites & background (using $2001) during all palette, sprite, and background updates?

Thanks!

I'd say yes yes and yes.

The 8 sprites per scanline does count offscreen, but it doesn't really matter since you'll never see them. You can set them all offscreen.

You don't have to read $2002 if you know for a fact that $2006 is already expecting a high byte.  If you don't know, or are unsure, it's best to read it as a precaution.  An example of when you would know might be a case like this:

lda $2002 ;reset hi/lo latch
lda #$20
sta $2006
lda #$00
sta $2006
sta $2007

lda #$23   ;look, we didn't need to read $2002 here
sta $2006
lda #$C0
sta $2006
lda #$00
sta $2007

We don't need to read $2002 here because we know $2006 is expecting a high byte since we wrote to $2006 exactly two times since we read $2002.

As for turning off sprites/bg, you definitely don't want to do it everytime you update something or your screen will black out every update (turning off BG blacks out the screen).

You do want to make sure all your graphics updates are done during vblank (in your NMI routine) though.  This includes writing palettes, updating nametables and performing sprite DMA.

The only time you'd need to turn sprites/bg off would be if you need to draw an entire screen all in one go, like redrawing the title screen after the game is over, or drawing the first screen at the beginning of a new level or something like that.  In these cases you need more drawing time than vblank allows, and a black transition screen is usually desirable.

edit: This is based on this tutorial number 4. You can try it with the next one (that is 5) too, but be sure to understand what i did. It will help you to understand ASM. It is very simple though.)
If someone wants multiple sprites (max 8) but has problems you can try this code:

  LDA #$80
  STA $0200        ; put sprite 0 in center ($80) of screen vert
  STA $0203        ; put sprite 0 in center ($80) of screen horiz
  LDA #$00
  STA $0201        ; tile number = 0
  STA $0202        ; color = 0, no flipping

  LDA #$80
  STA $0204
  LDA #$88
  STA $0207
  LDA #$01
  STA $0205
  LDA #$00
  STA $0206

  LDA #$88
  STA $0208
  LDA #$80
  STA $020B
  LDA #$02
  STA $0209
  LDA #$00
  STA $020A

  LDA #$88
  STA $020C
  LDA #$88
  STA $020F
  LDA #$03
  STA $020D
  LDA #$00
  STA $020E

  LDA #$90
  STA $0210
  LDA #$80
  STA $0213
  LDA #$04
  STA $0211
  LDA #$00
  STA $0212

  LDA #$90
  STA $0214
  LDA #$88
  STA $0217
  LDA #$05
  STA $0215
  LDA #$00
  STA $0216

  LDA #$98
  STA $0218
  LDA #$80
  STA $021B
  LDA #$06
  STA $0219
  LDA #$00
  STA $021A

  LDA #$98
  STA $021C
  LDA #$88
  STA $021F
  LDA #$07
  STA $021D
  LDA #$00
  STA $021E

  LDA #%10000000   ; enable NMI, sprites from Pattern Table 0
  STA $2000

  LDA #%00010000   ; enable sprites
  STA $2001

Replace it with the original code and you'll get a full Mario who is prepared to jump
Oh by the way a question. How did they include the enemies and other sprites? With a mapper or did they use tiles?

P.S.: Replace the first 4 numbers of your sprite palette with $0F,$16,$27,$18 and you'll get a Mario that is as close as possible to the original (they do have a small color difference. Maybe because of PAL and NTSC. I don't know)

That's a lot of hard coding right there.  I'd do something like this:

data:
  .db $80,$00,$00,$80,$80,$01,$00,$88, etc.

load_sprite_data:

  LDX #$00

.loop:
  LDA data,x
  STA $0200,x
  INX
  CPX #$??
  BNE .loop

RTS

Cleaner and easier to read.

I know its in the next tutorial. But i wanted to try it with doing it again and again by my self to understand it better. Because this is what the loop does.
Btw i didn't read the scanline thing so the question with the enemies is solved....

how can I expand the memory space for sprites? I need 356 (#$164 bytes of space.

You don't, it is a fixed space inside the PPU.

Damn! So there is no way to display more than 63 tiles at once?

Nope, 64 sprites is the limit. Other than that you're going to have to do tricks with backgrounds.

I can't imagine needing more than 64 sprites at a time though.

Yikes! This is gonna make my head explode! Which address(es) indicates the position of the sprite? How do I do that?

  LDA #$00
  STA $2003  ; set the low byte (00) of the RAM address
  LDA #$02
  STA $4014  ; set the high byte (02) of the RAM address, start the transfer

That piece of code tells the PPU's internal sprite RAM to point to the first sprite RAM spot (#$00) to start uploading sprites. $02 tells it to put the sprites from $200-$2FF inside the NES to that memory. (Called sprite DMA. Uploads faster then a LDA STA loop which is why we use the special pointer. Can also point to $300, $400, and so on. Uploading bytes $X00-$XFF to the sprite RAM, but $200 is used consistently for sprite data, so that's why it's used. Pretty much a "standard" spot.)

So locations $200-$2FF of the RAM inside the NES holds 64 sprites. 256/64=4, so every 4 bytes is a new sprite. The 4 bytes used for the sprite data are called the attributes.

Byte $200 (1st sprite, 1st attribute)

Y position on screen. Moves the sprite up/down. 0=top, Higher number, more down is goes.

Byte $201 (1st sprite, 2nd attribute)

Tile number. whatever bank is switched on, the tile number from that bank will be put on the screen. In most programs, the 2nd 4K "page" of CHR-ROM are the sprites.

Byte $202 (1st sprite, 3rd attribute)

Other misc. attributes. Each bit does this function in this byte:

  76543210
  |||   ||
  |||   ++- Color Palette of sprite.  Choose which set of 4 from the 16 colors to use
  |||
  ||+------ Priority (0: in front of background; 1: behind background)
  |+------- Flip sprite horizontally
  +-------- Flip sprite vertically

Byte $203 (1st sprite, 4th attribute)
X position on the screen. Moves player character left/right. 0=far left. Higher the number, more right it goes.

Bytes $204-$207, $208-$20B, $20C-$20F, $210-$213 of Sprite RAM are different sprites, but each follows the same attributes. For unused sprites, just write #$FF to the Y locaion and they will be put off the screen. If you write #$FF to the X, It may cause sprite overflow on some scanlines and cause sprites not to show up. (There can only be 8 sprites per scanline. Any sprite after the first 8 will be left out. The ones that come first in RAM will be shown on top/in priority to other sprites if there's overflow/overlap.)

Hope this helps you understand, I simplified it a lot for the sake of making it easier to understand, but if you get this, understanding the technicalities behind it isn't so hard. Any questions, just PM me.

Here's what I did, I don't know if this is correct or not.

The original code:

LDA #$80
STA $0200 ; put sprite 0 in center ($80) of screen vert
STA $0203 ; put sprite 0 in center ($80) of screen horiz
LDA #$00
STA $0201 ; tile number = 2
STA $0202 ; color = 2, no flipping

Newer code:

LDA #$C0
STA $0200 ; put sprite 0 in center ($80) of screen vert
STA $0203 ; put sprite 0 in center ($80) of screen horiz
LDA #$00
STA $0201 ; tile number = 2
STA $0202 ; color = 2, no flipping

I only changed the value of #$80, because when I messed with $#00 and $#80, the sprite was translated to a different part of the screen, but it changed. By changing only $#80, the sprite moved, but it retained its original form.

Not sure what the question is.

Yes, changing the value you are storing to $0200 and $0203 will change the horizontal and vertical positioning.

I'm not sure what color = 2 means. You're writing 0 to the color, so it would take the first palette. And also, the tile number you're writing is 0, and not 2.

Oops! I completely forgot that I changed 0 to 2 in the comments area thinking it would do something (silly me ). My concern was how I can change the position of the sprite with out altering sprite 0.

Speaking of color, what address do I need to go to to change the color or palette of the sprite?