So we can support multiple platforms with different screen sizes we have platform specific screen size definitions
We need to set up all the screen registers for a 256x256 @ 16 color bitmap screen. We set up our palette of 16 colors... we do this by writing to $E82000+
We zero the game's ram data. using function CLDIR0 - which fills an area with zeros

 

We're only using bitmap 'soft sprites' on the x68000 - of course the X68000 has hardware sprites, but they're more than what we need for such a simple game, so we won't use them here.

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... however we need to calculate the sprite address of the desired tile, so we use GetSpriteAddr to do so
We need to show a few text items to the screen A 'Press Fire' Message The 'LearnASM.Net' URL (Very Important!) The Highscore.

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

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 D1 for a loop counter - and D2 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

To clear the screen (CLS), we need to wipe the bitmap area at address $C00000 - we use the CLDIR0 command to do this We set the number of bytes to clear with D1... although our screen is 256 pixels wide, the memory layout means we have to clear 1024 bytes of width
PrintChar will show a character to the screen, using a bitmap font the same as the sprites... We need to calculate the position in the font data of the character Each Character is 32 bytes, and there are no characters below 32 (space) We also need to multiply up the X,Y pos into an 8x8 grid position. Once we've shown a character, we increment the X position for the next character

Lesson YQuest3 - Sinclair QL Specific code The Sinclair QL also uses a bitmap screen - with 8 color graphics.... let take a look at the QL version

See YQuest folder

We have a couple of ShowSprite routines... BlankSprite will draw the empty sprite (Space in the font), using the object A4 - to clear the old position of the object
GetSpriteAddr will calculate the address in ram of the sprite data we want to show to the screen... each sprite is 32 bytes We also handle the sprite frame... there are 4 frames of animation for each sprite - each bank is 512 bytes (16 sprites)
DoGetSpriteObj will show object A4 to the screen, getting Sprite, and XY pos from A4 ShowSprite will draw Sprite D0 onscreen (at XY position D1,D4)

Get Screen Pos

The Get ScreenPos function will take an XY pos in D1 and D4... it will return a screen memory address in A2 Our screen address starts at $20000.. Each pixel is stored in a separate word... so we multiply the Xpos by 2 Each line is 128 bytes - so we multiply the Ypos by 128

Joystick Reading

Reading in from the keyboard has to be done with Trap 1 - command 9 We have to send a sequence of command bytes - with byte 6 as the row number - the trap will return a byte in D1 - with a bit high when the button is down. We're going to use Trap #1 to read in from the keyboard, we need to pass the command we just defined to the trap in A3 The function will return the bits of the line in D1 We're going to use the bits in D1 to build up the result in D0 We're going to move each of the controls in one by one, We'll use D2 as a temporary copy of the the register, and shift the required key bit into D0 We'll use Escape as a start button and Space,Enter and \ as Fire 1-3, shifting them into D0 Finally we'll shift in all the bits of UDLR into D0 The Cursor Keys are also used by an external Joystick if one is connected

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

We have 5 different files of sprites 96 for the font 16x4 for the 4 banks of sprites

So we can support multiple platforms with different screen sizes we have platform specific screen size definitions We're using the tilemap - which is limiting movement to 8x8 blocks We also need to define the 'user ram' area which is used for the game vars.
We need a cartridge header for our game.
We need to Disable the TMSS chip (copy protection) We also set up our screen, by transferring the VDP registers to the screen hardware
We need to define our color palette. We also need to define the pattern data for the tiles. Finally we turn on the screen.
We zero the game's ram data. using function CLDIR0 - which fills an area with zeros

We're only going to use the tilemap for graphics in todays version - this will make the movement 'blocky.... Later we'll upgrade the game with hardware sprites, which will make it better.

We have a couple of ShowSprite routines... BlankSprite will draw the blank tile, using the object A4 - to clear the old position of the object
GetSpriteAddr will calculate the address in the pattern data... the first 96 tiles are the font We also handle the sprite frame... there are 4 frames of animation for each of the 16 sprites
DoGetSpriteObj will show object A4 to the screen, getting Sprite, and XY pos from A4 ShowSprite will draw Sprite D0 onscreen (at XY position D1,D4) We need to calculate the vram address of the tile we want to change, we then write the bytes of that tile with the new tile number.

Joystick Reading

There are two ports which are read and written for the joypad... Joypad 1 is at address $A10005 Joypad 2 is at address $A10003 First, however, we need to set one of the bits of these ports to WRITE... we do this with 2 ports... Joypad 1 is at address $A1000B Joypad 2 is at address $A10009
The Joypad needs a sequence of writes to select the 'sections' of the joypad... this is achieved by writes with bit 6 as a 1 The first batch rerturns Up, Down, Left, Right... button C and Button B The second batch returns Button A and Start The final batch are Button X, Button Y and Button Z... as well as Mode. Note: some of the buttons are duplicated... eg Up is returned in the first and second batch.
Finally, we shift around the bits, so we have all the buttons in a neat order in a single register.
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 Palette

We have 5 different files of sprites 96 for the font 16x4 for the 4 banks of sprites
WE have the palette words... on per color - these are in native Genesis format.
Finally, we have our screen Init settings

Lesson YQuest7 - Atari ST Specific code Lets Port to the Atari ST... The ST can't do hardware sprites, and unfortunately it's screen layout is a bit of a pain.

See YQuest folder

We have a couple of ShowSprite routines... BlankSprite will draw the empty sprite (Space in the font), using the object A4 - to clear the old position of the object
GetSpriteAddr will calculate the address in ram of the sprite data we want to show to the screen... each sprite is 32 bytes We also handle the sprite frame... there are 4 frames of animation for each sprite - each bank is 512 bytes (16 sprites)
DoGetSpriteObj will show object A4 to the screen, getting Sprite, and XY pos from A4 ShowSprite will draw Sprite D0 onscreen (at XY position D1,D4) We transfer the bytes of the sprite to the 4 bitplanes of the graphics screen (in 4 consecutive words of vram) ****

Get Screen Pos

The Get ScreenPos function will take an XY pos in D1 and D4... it will return a screen memory address in A2 Each line is 160 bytes , 4 bitplanes are next to each other as words, eg $0000 $1111 $2222 $3333

Joystick Reading

To operate the joysticks we need to add a handler to the Atari OS. We need to get the 'IKBD' vector table, then put our 'Joystick Handler' into it This makes 'Joystick Handler' run every time a button is pressed - we then store the data from the joysticks in two bytes of 'Joystick Data' for later. The format of the read in byte is %F---RLDU
We convert this into the format %---FRLDU
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, Palette and screen ram

We have 5 different files of sprites 96 for the font 16x4 for the 4 banks of sprites
We need to define a palette (in Atari ST format)
We need to define enough space for the screen ram, the screen is 32000 bytes in size, but we need it to be aligned on a byte boundary, so we allocate 32256 bytes We need to define $800 bytes of ram for game variables

The graphics routine here is based on the old ones The horizontal movement is pretty jerky here... we'll need to make a better sprite routine to fix that, but we'll look at that next time!

Hardware Sprites

On the NeoGeo Sprites are 16 pixels wide, and are made up of tiles 16 pixels tall... they are 16 colors (4 bitplanes) so each tile is 128 bytes... The NeoGeo is capable of up to 380 sprites total. A sprite can be made up of up to 32 tiles to make the sprite taller... there is also a 'Chain' bit - this will connect a sprite to the previous sprite (Sharing its position) to make a sprite wider! Hardware sprite Tiles are not in the same format as the FIX layer - they are 16x16 pixels in size and use bitplanes, but the layout is odd, and they are split onto two rom files (C1/C2 or C3/C4 etc) The sprite is split into 2x 8 pixel wide 'columns' the rightmost one is stored first - each pair of bitplanes 0 & 1 are stored together in ROM C1 - and 2 & 3 are stores in ROM C2 - all 16 lines of the right half are stored first - then the 16 lines of the left side are stored - making a total of 128 bytes (64 in each file)

Sprite Attributes
Each sprite is defined by 1-32 tile definitions, A palette/flip byte, a Scale byte, a Ypos/Height byte and an Xpos... lets see what all these bits do in detail!
Note, it's possible to scale a sprite DOWN, but it's not possible to scale them up...

Address of

Bit

Function

Sprite 1

F

E

D

C

B

A

9

8

7

6

5

4

3

2

1

0

Purpose

Sample

TileAddr 1,2..32

$0040,$0042�$007E

N

N

N

N

N

N

N

N

N

N

N

N

N

N

N

N

N=Tile Number L

$2000

TilePal 1,2..32

$0041,$0043...$007F

P

P

P

P

P

P

P

P

N

N

N

N

A

A

V

H

P=Pallete, N=tile Number H, A=Animate (4/8) V=Vflip H=Hflip

$0100

Shrink

$8001

-

-

-

-

H

H

H

H

V

V

V

V

V

V

V

V

H=H shrink (F=off), V=V shrink (FF=off)

$0FFF

Ypos

$8201

Y

Y

Y

Y

Y

Y

Y

Y

Y

C

T

T

T

T

T

T

Y=Y pos (from bottom, so 248-Y) C=Chain another sprite on right, T=Tile count vertically

$E002

Xpos

$8401

X

X

X

X

X

X

X

X

X

-

-

-

-

-

-

-

X=X pos (from left)

$0800

Valid Tile Counts (T) are 1-12 , 32 and 33 (13-31 are invalid)
A special Tile Height of 33 makes the sprite the Full height of screen - use for building a 'tilemap'

Sprite Attribute Addresses
We need to set various addresses in the Sprite Attribute data... to do this we use two 68000 addresses...

First we write the Address of the Sprite Attribute we want to change to $3C0000, then we write the new word value for the address to $3C0002

Sprite Num	TileAddr (1st)	TilePal (1st)	TileAddr (32nd)	TilePal (32nd)	Shrink	Ypos	Xpos
0	$0000	$0001	$003E	$003F	$8000	$8200	$8400
1	$0040	$0041	$007E	$007F	$8001	$8201	$8401
2	$0080	$0081	$00BE	$00BF	$8002	$8202	$8402
3	$00C0	$00C1	$00FE	$00FF	$8003	$8203	$8403
�	�	�	�	�	�	�	�
379	$5EC0	$5EC1	$5EC0	$5EC1	$817B	$837B	$857B

Hardware sprites are defined in ROM - we need to set up our XML file so MAME knows where the files are, and where to map them in VRAM
Because each hardware sprite can only appear on the screen once, We need to allocate hardware sprites to each object... we use the 'SetHardwareSprites' function to do this
We have a new DoGetHspriteObj function - this will do the same as the old DoGetSpriteObj, however it uses the new hardware sprite code, rather than software sprites. We get the X,Y pos of the sprite from the object... The Ypos on the NeoGeo is reversed (from the bottom)  so we subtract our Ypos from 288+207 We use SetSprite to actually set the hardware sprite
SetSprite will set a hardware sprite of a single Tile (16x16) We pass the Hardware sprite number in D0... the XY pos in D1,D2... the pattern in D3 and the palette in D4
Because hardware sprites are a separate 'layer' - we need to alter our Clear Screen Routine. We need to go through each hardware sprite, and remove it from the screen.
To remove a sprite we can just change it's XY co-ordinate to 0,0 - this is completely offscreen, so the sprite won't be drawn.
The sprites on the neo-geo are 16x16, but our graphics are 8x8... We can covert our 8x8 tiles into 16x16 ones using the 'SpriteSpace' function of AkuSprite Editor