When we want to calculate the memory address our formula is: Address= $1E00 + (Ypos * 22) + Xpos As multiplying by 22 isn't so easy (and our screen is pretty short) we'll use a loop and addition to effect the multiply

Joystick Reading

On the Vic 20, we ned to read in from ports $9120 and $911F to get UDLR and Fire... We'll need to ensure that port B is set to READ by writing to $9122

Sprite Data, Palette and Screen Init sesttings

We have 4 different files of sprites 16x4 for the 4 banks of sprites
We define a 1 byte palette for each sprite (0-15)
We have 16 bytes of screen init data, these are transferred to the screen hardware during startup

We're going to define a function called GetVDPScreenPos to select an X,Y Tilemap position in Vram memory The tilemap is 32 tiles (bytes wide).. and the tilemap starts from $2000, so the formula is... Address=$2000 + (Ypos *32) + X We multiply Y by 32 by bitshifts, and select the calculated address... We don't actually write into the Tilemap... we write to the buffer 'VDPBUFFER' First We write the HL address in vram we want to write to, then we write the byte to change ... writing the byte to change occurs in the sprite routine.
GetVdpBufferCT calculates the next free entry in the buffer... the buffer has a limit of 32 bytes to change (during vblank)... so if it's reached 32x3 then we wait for the next vblank (when it clears down) We write a Zero to VDP_CT during processing - in case the VBLANK runs while we're writing more data.
When we want to define tiles we do this directly to VRAM (not via the buffer)... we use PrepareVram to select a destination VRAM address We write z_bc bytes of data from z_hl to the VRAM via port $2007
When we want to define tiles, we can turn off the screen, this means we don't need to wait for VBLANK before writing. We use $2001 to set the PPUMASK which turns off the tilemap layer We use $2000 to turn off the NMI interrupt handler
PrepareVram will select a destination VRAM address for writing to, we write the address (from z_de) to $2006 , High byte then Low byte
Waitframe will wait for VBLANK... we check this by writing a 0 to zero page entry 'Vblanked' to change... this will occur when our NMI runs.

Joystick Reading

We need to read in a sequence of 8 bits from port $4016 to get each direction key... we also need to strobe the port by writing 1 then 0 to the same port... The 8 reads from the port will return the directions: Read  1 - A Read  2 - B Read  3 - Select Read  4 - Start Read  5 - Up Read  6 - Down Read  7 - Left Read  8 - Right
We also have a 'Wait for fire' function... this randomizes the seed, and waits for fire to be released, then pressed. It's used for menus and between levels.

Sprite Data and First bank header

We have 5 different files of sprites 96 for the font 16x4 for the 4 banks of sprites
We now have our palette in native format
At the end of our cartridge we have the 'footer'... it has a link to the Start of the program and the NMI interrupt handler

Lesson YQuest10 - SNES Specific code It's time for the SNES version... like the NES we need a buffer of the tilemap data... unlike the NES version we can use a DMA to copy a whole tilemap during vblank.

See YQuest folder folder

SNES Header

So we can support multiple platforms with different screen sizes we have platform specific screen size definitions Each system needs an area of ram for game variables, know as 'UserRam' We use CollisionMasks - these will skip some bits of the internal object positions, this is to ensure we don't detect a collision that is not visible due to the low resolution of screen co-ordinates. We also need to define the memory address of the Direct page, and set up some symbols for the common code. We also need a 'ScreenBuffer' in RAM - this will contain the tilemap, and will be transferred fom RAM to VRAM
We need to turn on the Tile layer and set up the palette
We need to set the scroll position of the tilemap, We clear the RAM buffer (Tilemap copy, transferred to VRAM during Vblank) We transfer our tile patterns to vram with 'DefineTiles', Finally we turn on the screen. We then initialize the 'ChibiSound' Sound driver - which copies the program code to the SPC700 sound chip
We zero the game's ram data. using CLDIR0 - which fills an area with zeros

 

Sound on the SNES is painfully complex, the SPC700 is separate processor with separate ram, and Is NOT a 6502 based chip... for more details see here

ShowTitle

When The title screen starts, we first reset the game settings for a new game to start, Then we clear the screen.
We want to draw the tilescreen... it's held as a 1 byte per tile data block in our code at 'TitlePic' We use our ShowSprite Routine to draw it to the screen... GetSpriteAddr calculates the pattern number for the sprite.
We need to show a few text items to the screen A 'Press Fire' Message The 'LearnASM.Net' URL (Very Important!) The Highscore.

LevelStart

When the game or a new level starts, we first wait for fire to be pressed. Next we clear the screen, Reset the player position Initialize the level enemies with LevelInit

Level Loop

We have to pause a while during the game loop, so we read in from the joystick during this time, and if the user presses a key we'll store it for later. we use Y and z_b for a loop counter to slow down the game - and X for any pressed button. we use function call Player_ReadControlsDual - which will read in the joystick and fire button
First we draw the UI (Score etc) Next we clear the player sprite.
To slow down the acceleration, we have a 'timeout'... if a key was pressed, for a short time we'll ignore any other keys.
We're going to process the input, We process each direction, and alter the acceleration of the player if a direction is pressed... We have a 'Bullet fire' routine (in the common code) for Fire 1 Fire 2 will immediately stop the player If any button is pressed, the key timeout is set
Finally we run the multiplatform 'Draw and Move' routine, this draws the player, and handles movement and drawing of enemies and bullets The system is still too fast... so we slow things down a little more.

Clear Screen and Print Char

To clear the screen (CLS), we need to set all the tiles to 0 (Space in the font)
Printchar will show a character to the screen... the first 96 patterns of the tilemap are the font... the first character is space (Char 32)

Sprite routines

We have a couple of ShowSprite routines... BlankSprite will draw the empty sprite (Space in the font), using the object z_IX - to clear the old position of the object
GetSpriteAddr will calculate the pattern we want to show to the screen. The first 96 are our font. We also handle the sprite frame... there are 4 frames of animation for each sprite - each bank is 16 tiles
DoGetSpriteObj will show object IX to the screen, getting Sprite, and XY pos from z_IX ShowSprite will draw Sprite A onscreen (at XY position BC).... It doesn't do this directly however, GetVdpScreenPos calculates a position in the tilemap buffer in z_hl... We then transfer the two bytes that define the tiles in to ram. It will be shown onscreen next vblank

Get VDPScreenPos, PrepareVram, DefineTiles and More

We're going to define a function called GetVDPScreenPos to select an X,Y Tilemap position in Vram memory We need to calculate an address in the ScreenBuffer for the tile. Each tile is 2 bytes, and the tilemap is 32 tiles wide... so the formula is: Address= SnesScreenBuffer + (Ypos * 32 * 2) + (Xpos * 2)
When we want to define tiles we do this directly to VRAM (not via the buffer)... we use PrepareVram to select a destination VRAM address We wait for Vblank before writing any data. We write z_bc bytes of data from z_hl to the VRAM via ports $2119 and $2118... We have to write in this order, as we've set Autoinc to occur on $2118
To Check if we're currently in Vblank, we test the top bit of $4212 - while this is Zero we're not currently in vbank
PrepareVram will select a destination VRAM address for writing to, we write the address (from z_de)... low byte to  to $2116 , High byte to $2117
We've defined a Custom NMI handler... this will run during VBlank.... we're going to use a DMA to quickly transfer the SnesScreenBuffer from ram to VRAM We have to select a destination Vram address with $2116/7. We define the autoinc mode to update on the write to $2119 - we d this with port $2115 Next and select the destination port with $4301 - we select $2118 - as we'll write in word pairs. We specify the source (as a 24 bit number) using $4302/3/4... and the number of bytes to transfer with $4305/6/7 We disable the H-DMA (it's a special function we don't want) with $420C Finally we start the DMA transfer with bit 0 of $420B. Once we've finished, we set the AutoInc with port $2115 back to update on $2118

Joystick Reading

We need to read in a sequence of 8 bits from port $4016 to get each direction key... we also need to strobe the port by writing 1 then 0 to the same port... The 8 reads from the port will return the directions: Read  1 - A Read  2 - B Read  3 - Select Read  4 - Start Read  5 - Up Read  6 - Down Read  7 - Left Read  8 - Right
We also have a 'Wait for fire' function... this randomizes the seed, and waits for fire to be released, then pressed. It's used for menus and between levels.

Sprite Data and First bank header

We have 5 different files of sprites 96 for the font 16x4 for the 4 banks of sprites
We now have our palette in native format
At the end of our cartridge we have the 'footer'... it has a link to the Start of the program (Reset Vector) and the NMI interrupt handler We need an 8 and 16 bit set of Vectors

Lesson YQuest11 - Hardware Sprites on the PC Engine / Turbografix Our Yquest program currently only uses the Tilemap... Lets extend it to use Hardware sprites!. This will give the game nice smooth movement... lets learn how to use PCE hardware sprites!

See YQuest folder folder

Multiplatform Sprite code

We had an unused byte in the object definitions before... We're going to use it now! This will be the 'Hardware sprite number'... A Zero will be the same as before - a tile will be used 1+ will be a numbered hardware sprite - relating to one of the hardware sprites the system is capable of. This flexibility to use tiles or hardware sprites helps with systems with small numbers of hardware sprites
We'll need to set banks of objects to consecutive sprite numbers (EG bullets)... We use SetHardwareSprites to do this.
We need to alter the DrawAndMove function and check the 'hardware sprite number' Values 1-128 are hardware sprites... other values (0 / 255 etc) are soft sprites

SATB - Sprite attribute table buffer

Sprites are stored in regular vram... the sprite definitions are stored in special ram which we CANNOT ACCESS...however we can allocate a bank of 256 addresses (each containing one word) called SATB, and then get the hardware to copy that ram to the special ram... it's suggested you use $7F00 for that purpose.

To start the copy we just write the address to control reg $13

The PC Engine Sprite table allows for up to 64 sprites... each one has 4 words of data - making 256 words in total... the format is as follows

Byte	F	E	D	C	B	A	9	8		7	6	5	4	3	2	1	0	Notes
1	-	-	-	-	-	-	Y	Y		Y	Y	Y	Y	Y	Y	Y	Y	Y=Ypos (64 is first visible line)
2	-	-	-	-	-	-	X	X		X	X	X	X	X	X	X	X	X=Xpos (32 is first visible line)
3	-	-	-	-	-	A	A	A		A	A	A	A	A	A	A	A	A=Address (Top 10 bits $trueaddress>>5 )
4	YF	-	YS	YS	XF	-	-	XS		F	-	-	-	P	P	P	P	YF=Yflip XF=Xflip YS=Ysize XS=Xsize F=Foreground (infront of tilemap) P=Palette

PC Engine Sprite code

the PC-Engine hardware sprites use palette entries 256+... We're going to set them to the same colors as our tiles.
The Hardware sprites are in a different format to the regular patterns - They are 16x16... in 4 bitplanes We can export the sprite data in the right format using AkuSprite Editor... We also need to 'space out' the sprites from 8x8 to 16x16
We load the sprites in VRAM address $2000
DoGetHSpriteObj will draw a hardware sprite to the screen from object z_IX... like before, the XY pos will be read from object z_IX, the sprite frame will also be calculated We need to calculate the pattern number for the current sprite, and the XY pos...
We need to set the hardware sprite in the SATB (Sprite attribute table buffer) - but we can't write it directly, so we write to VRAM $7F00-7FFF - then execute a transfer to copy these to the video hardware (Showing the sprite)
The Clear Screen Routine needs to turn off all the hardware sprites, we do this by moving the sprites off the visible screen
Until we set the 'Hardware Sprite Numbers' of the objects they will still use the old tile code... We do this in the 'StartLevel' routine... setting the player object to Hsprite 1... the player bullets to 2-9... and so on...

As with most things on the PC-Engine, the hardware sprites are pretty poweful - and easy! Each sprite is 16x16, and we have 64 - far more than Yquest needs!

Lesson YQuest12 - adding Hardware Sprites on the NES Lets add hardware sprites to the NES... unfortunately, like the Tilemap, we can't alter hardware sprites outside of VBlank - so once again we'll use a buffer, and transfer it during VBlank

See YQuest folder folder

Multiplatform Sprite code

We had an unused byte in the object definitions before... We're going to use it now! This will be the 'Hardware sprite number'... A Zero will be the same as before - a tile will be used 1+ will be a numbered hardware sprite - relating to one of the hardware sprites the system is capable of. This flexibility to use tiles or hardware sprites helps with systems with small numbers of hardware sprites
We'll need to set banks of objects to consecutive sprite numbers (EG bullets)... We use SetHardwareSprites to do this.
We need to alter the DrawAndMove function and check the 'hardware sprite number' Values 1-128 are hardware sprites... other values (0 / 255 etc) are soft sprites

NES Sprites

Sprites on the NES are defined by 256 bytes of OAM memory- 4 bytes per sprite
The byte is selected by setting the OAM-address with memory location $2003 - effectively with 4x the sprite number...  then by writing the 4 bytes to $2004 (the OAM address autoincs)

Byte	Purpose	Bits	Meaning
1	Ypos	YYYYYYYY
2	Tilenum	TTTTTTTT
3	Attribs	VHB---PP	Vflip  Hflip  Background priority  Palette
4	Xpos	XXXXXXXX

NES Sprite code 

We need to copy our sprite buffer to the 'OAM' duirng our NMI Vblank handler... we do this by writing the top byte of the address to port $4014... this will transfer 256 bytes of data to the video hardware
In this case the sprites use the same patterns, but separate palettes - the first 4 palettes are for the tilemap... the second 4 palettes are for the sprites.
We need to turn on the hardware sprites with port $2001, and zero the sprite buffer
DoGetHSpriteObj will draw a hardware sprite to the screen from object z_IX... like before, the XY pos will be read from object z_IX, the sprite frame will also be calculated We need to calculate the pattern number for the current sprite, and the XY pos... We've defined which of the 4 palettes to use for each of our defined sprites, we store this in z_l For sprites, The top left corner of the screen is 16 pixels down, so we add 16 to z_iy
We need to set the hardware sprite in the SATB (Sprite attribute table buffer) - but we can't write it directly, so we write to VRAM $7F00-7FFF - then execute a transfer to copy these to the video hardware (Showing the sprite)
The Clear Screen Routine needs to turn off all the hardware sprites, we do this by zeroing the sprite buffer
Until we set the 'Hardware Sprite Numbers' of the objects they will still use the old tile code... We do this in the 'StartLevel' routine... setting the player object to Hsprite 1... the player bullets to 2-9... and so on...

Getting NES sprites to work is a bit of a pain, but once we have the buffer code set up, it's all pretty easy! The Nes has 64 sprites, and each can use one of the 4 color palettes - giving our game some nice color too!... especially considering palettes are set for the tilemap only for every 4 tiles (2x2 blocks)

Lesson YQuest13 - SNES Hardware sprites. Like the tilemap, we can't write to the sprites out of Vblank, so once again we'll use a buffer for the sprites, and use the DMA to transfer the sprite data to vram

See YQuest folder folder

Multiplatform Sprite code

We had an unused byte in the object definitions before... We're going to use it now! This will be the 'Hardware sprite number'... A Zero will be the same as before - a tile will be used 1+ will be a numbered hardware sprite - relating to one of the hardware sprites the system is capable of. This flexibility to use tiles or hardware sprites helps with systems with small numbers of hardware sprites
We'll need to set banks of objects to consecutive sprite numbers (EG bullets)... We use SetHardwareSprites to do this.
We need to alter the DrawAndMove function and check the 'hardware sprite number' Values 1-128 are hardware sprites... other values (0 / 255 etc) are soft sprites

We're going to use the same kind of DMA as we did to transfer the tiles, however unlike tile data, we don't write pairs of bytes to two different addresses, we write all the data to a single address.

SNES Sprite code

We need to copy our sprite buffer to the 'OAM' duirng our NMI Vblank handler... we use the DMA to do this The sprite buffer uses a total of $220 bytes - we need to write these bytes to $2104 To select an 'address' in the OAM to write to we use ports $2102/3 - we write a zero to these to select the start of the OAM. We want the bytes of data to all write to $2104... first we select 'single address' with $4300.... we select port $2104 with port $4301 We select the source address (our SnesSpriteBuffer) with port $4302/3/4 We select the number of bytes $220 with ports $4305/6/7 we start the transfer with bit 0 of port $420B
The sprites use palette entries from 128 onwards... we define them in the same way as our regular tile palette
We define the Sprite patterns at address $4000 - and transfer the sprite patterns to the VRAM... they don't use the same pattern definitions as the tilemap
Finally, we clear the buffer, and turn on the Tilemap+Sprites with port $212C
DoGetHSpriteObj will draw a hardware sprite to the screen from object z_IX... like before, the XY pos will be read from object z_IX, the sprite frame will also be calculated We select the pattern with z_h - the first sprite is blank (So we can hide the sprites) so we add 1 to skip the blank sprite We need to calculate the pattern number for the current sprite, and the XY pos... We define the palette, and how the sprites overlay the tiles with z_l To line up the sprites with our Tilemap, we add 16 to z_iy
We need to set the two bytes in the buffer... In the first part, there are 4 bytes per sprite - Xpos, Ypos, Tile number and attribs
in the second part, there are 2 bits per sprite in a byte - so 4 sprites per byte... these are the 8th bit of the Xpos, and the scaling option We have to bit shift these into the correct position and OR them into the current value at that memory position!... what a pain!
The Clear Screen Routine needs to turn off all the hardware sprites, we do this by zeroing the sprite buffer
Until we set the 'Hardware Sprite Numbers' of the objects they will still use the old tile code... We do this in the 'StartLevel' routine... setting the player object to Hsprite 1... the player bullets to 2-9... and so on...

Lesson YQuest14 - C64 Hardware Sprites We were using bitmap graphics before for our game - making the objects move in 4x8 blocks The C64 has 8 hardware sprites - we'll use one to draw the player, which will allow for smooth movement.

See YQuest folder folder

The Sprite pointers for the bitmap data are a single byte... multiplying the sprite pointer by 64 will give the address of the sprite *within the 16k bank of Vram* (so must be in the range $0000-$3FFF)...
$1000-$2000 and $9000-$A000 are seen by the VIC as character ROM, so sprites cannot be in this area!
We can move our screen base to something more convenient... so for example with a screen base of $4000 (Screen ram at $6000)- our sprites can be at $5000

Sprites are 21 vertical lines and 63 bytes each...
In 1bpp (2 color) mode this makes sprites 24x63...
In 2bpp (4 color) mode they are 12x63...

In both modes, Color 0 is Transparent
In 2bpp mode color 1,2 are read from $D025/6... and color 3 is the sprite color.