Learn Multi platform 6502 Assembly Programming... For Monsters!

Platform Specific Lessons

Lesson P31 - Hardware Sprites on the Atari 800 / 5200 The Atari 5200 and 800 have some limited hardware sprite support... capable of 8 pixel wide sprites - but that are the entire height of the screen! Lets learn about them!

SpriteTest.asm

Compared to other systems, the 'Hardware Sprites' of the atari are pretty limited, and may not be very useful as they are just 8 pixels wide and one color That said, they may be useful in some cases, you could combine them together to make a 32x32 player sprite - or use them for parallax effects or something!

Atari 800 / 5200 Sprites
The Atari's hardware sprites are very weird!

Basically each sprite is 8 pixels wide and just 2 colors (1+transparent)... there are 4 'normal' ones that are 8 pixels wide.... and 4 missile sprites that are just 2(!) pixels wide... but we can position them together to give us 5 sprites.

Despite being 8 pixels wide... each sprite is up to 128  pixels tall (or 256 in hires mode) - the entire height of the screen!... if you can't guess this is because the systems is changing the data each rasterline.

The data used to draw the sprite is taken from a single pointer at $D407... if this pointer is set to $18 then all the sprites will use the $1800-$1FFF range - the exact address differs depending on whether the Resolution bit of $D400 is set to 0 or 1... in Res1 Sprites will be at $1800+$400 - $1C00 ... or in Res0 $1800+$200 = $1A00

On an Atari 800 where the GTIA is at $D000 this would give the following addresses for the sprite settings  GTIA is at $C000 on the 5200)

Atari 800 / 5200 Sprite Registers

Coding a Player sprite (sprite 0-3)

The procedure for setting Player sprites 0-4 are all basically the same, we need a 1 byte wide sprite (1 bit per pixel) file, and to set our 'Y position' we'll need to load it into the correct memory address. First of all we need to set up the sprite settings, we need to turn on sprites, set them to appear in front of the background, and set the memory address of our sprites - we're using 'High Resolution mode, and our sprite base is at $1800... so Player 0's sprite data starts at $1C00 We need to enable the DMA - this is what copies the sprite data to the screen register each screen line to change the sprite vertically. We're also enabling 'Player 4' - this combines the missile sprites into one 'fifth' sprite - we'll learn how to use it in a moment!
OK, we're ready to define our sprite! First we set the Xscale with $D008 - but because the GTIA is in a different place on the Atari 5200 - we'll refer to it with GTIA+$08 ... the setting can be 0-3... there is no Yscale - we need to alter our bitmap data to make the sprite taller!   Next We'll set the Xpos with $D000... There is no Ypos - the sprite covers the entire height of the screen - we need to alter the bitmap data according to where we want it to be. Finally We set a color with $D012
We need to set the sprite data, we do a memory copy from the 'Sprite' label in our code, and write to the $1C00 - adding an offset to change the Ypos ($80 in this case) The same procedure can be used for sprite 1-3 - just change the memory addresses used.

Coding the Missile sprite (sprite 4)

The 4th 'Player' sprite is made up of the 4x two pixel missiles... Because of this, we need to set the width in 4 different bit pairs... We also need to align the Xpos of all 4 parts to make the single sprite. Depending on our color settings, we can set each part separately, but it's more simple to set them with a shared color, and set them together - we do this with bit 4 of GTIA+$1B
We need to load the sprite data into the the ram for Sprite 4 (Missile) At $1B00 - again we need to add the Ypos offset. ($40 in this case)
In this example we've used the two sprites to draw 'targets' onscreen... The Player 0 sprite (Yellow) has been scaled super wide!

The weird hardware of the Atari probably goes back to the early days of pong!... the 4 player sprites would be the characters - and the 4 two pixel missiles would be the balls or bullets for those players. Unfortunately it's not really very impressive by even the standards of the 80s!

Lesson P32 - Hardware sprites on the Atari Lynx Sprites on the Lynx are not hardware sprites in the same sense as other systems, rather than a layer, the 'Suzy' Chip will quickly scale and render the sprite into our bitmap memory. Lets Learn how!

SpriteTest.asm

Hardware Sprites
Unlike other systems, Lynx hardware sprites are not an extra layer! the 'Suzy' graphics chip draws the sprite into the Vram area of the 6502's addressable range

This may leave you wondering why not just do our sprites in software with the 6502... but the Suzy chip is VERY fast... it's a 16mhz 16 bit chip... and can even do dynamic scaling of sprites!

Sprites for the Suzy chip have to be held in RAM, and need a 'Sprite control block' to define the drawing of a sprite... this pointer is passed to the Suzy chip to get it to draw a sprite

My Akusprite Editor can Export Literal and RLE bitmaps... but lets take a look at the theory

Don't worry about all the work of creating bitmap data, just use AkuSprite Editor (or similar) to export valid bitmaps for the Lynx... It's worth knowing the theory, but it's unlikely you'd really want to do things yourself.

The Source code

efore we can use sprites, we need to set up the screen hardware, defining the Ram area the sprites will be drawn to (in this case the same as the visible screen)... We also need to set any offset for sprite clipping - we're setting the first visible pixel at (8,8) We also need to send some bytes to the sprite hardware to initialize it - these are pretty fixed bytes and don't really need changing
Our next stage is going to involve setting up a 'Sprite Control Block' (SCB)... we've got a template we're going to patch our settings into. The first byte defines the sprite type, in this example we're using a 16 color (4bpp) RLE sprite Note: Our example won't use scaling, but you can do if you want, just change the WID and HEI bytes - $200 would make the sprite 2x larger
We're going to define a function called 'SetHardwareSprite'... This will use zeropage entries z_hl to point to the sprite bitmap data. z_ixl is the X position and z_iyl is the Y position of the sprite The function handles the job of setting up the SCB, and calling the Suzy chip to draw the sprite to screen.
We need to load the address of the sprite into the SCB We also set the X and Y position of the sprite We also Initialize the start address of the SCB to $FC10/1 We're now ready to get Suzy to draw the sprite.
We're ready to draw the sprite, we need to tell the Suzy chip to draw the sprite, and the allow Suzy to take over the ram bus... We put the CPU to sleep with $FD91 while the sprite is drawing. For *SOME REASON* the first byte of the SCB is getting altered in the process - I don't know why!
In this example we've drawn the Cross-hair sprite to two positions onscreen.

Usually hardware sprites are always onscreen even if the screen/tilemap is cleared... but the Lynx is different. We'll need to draw all the sprites again for the next frame - which is a pain, but unlike other systems, there is no limit to the number of sprites we have onscreen!

Lesson P33 - Hardware Sprites on the PC Engine (TurboGrafx-16) The PC Engine is capable of 64 hardware sprites, each of which is 16 color, and is 16x16 in size. This gives the PCE some pretty impressive graphical capabilities - lets learn how to make some sprites!

SpriteTest.asm

The Sprite table allows for up to 64 sprites... each one has 4 words of data - making 256 words in total... it's held in VRAM between $7F00 and $7FFF

Sprite Definitions

You don't need to worry about working out the sprite data for the PC-Engine format, you can export valid 16x16 sprites using my free Open Source AkuSprite Editor! It's included in the sources.7z file!

Transfering Sprite Data Transfering Data to VRAM is the same as with tiles, we specify a source in ram, destination in VRAM, and use DefineTiles to transfer the data to the VRAM See this tutorial for details of how DefineTiles works
We're going to create a function called 'SetHardwareSprite' to do the heavy lifting for us... We'll use zero page entries to define the settings for our sprite A is the hardware sprite number z_IXH/L will define the X position z_IYH/L will define the Y position z_H will set the size & flipping options z_L will select the layer and palette z_DE is the top 11 bits of the address of the sprite data in VRAM (Bits XXXXXXXX XXX-----) - we get them by bitshifting the address with >>5
Setting a hardware sprite We're going to need to use the memory mapped hardware graphics ports at $0100/2/3 - and the equivalent ST0/1/2 commands when we're writing fixed values First the function needs to select the VRAM address of the sprite settings - to do this we multiply the sprite number by 4, and select the address (Starting at $7Fxx) by writing to Register $00 (with ST0)
We need to select Register $02 (with ST0) as we now want to write bytes to the $7Fxx range we selected before... We write our Ypos, Xpos, Sprite address and Attributes to vram - as the address autoincs, we don't need to do anything else!
OK, the data is in VRAM, but that's not enough to change the visible sprites, we need to initiate a copy of the VRAM to the STAB sprite table... We do this by writing the VRAM address of our sprites ($7F00) to reg $13
The sprites will now be visible on screen!

In this example we've only looked at a 16x16 sprite, but the PC engine can combine tiles to make sprites up to 32x64, we just need to set more patterns and set the bits to make the sprite bigger.

Lesson P34 - Hardware Sprites on the NES / Famicom The NES and Famicom use a graphics system called the PPU - they are also Tile / Sprite based systems, with a grid of 8x8 tiles in the background. Lets learn to use the sprites to draw a 16x16 graphic!

BmpTest.asm

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)

PPU Graphics ports

To directly alter the sprites, we'll use use ports $2003 and $2004... $2003 selects the OAM address... then we write the 4 bytes to $2004... this can only be done during VBLANK - so it's better to use a buffer, and transfer it to VRAM during Vblank.

Pattern Definitions for sprites and tiles

If you want to create NES sprites, my AkuSprite editor can export valid format data. It's included in the Sources.7z - and is free and open source.

We can set up sprites in two ways, directly by writing to the OAM, or by making a buffer, and using the DMA to copy it... The DMA way is better... but first we'll look at the 'simpler' direct way.

Simple Sprite Example

Sprite data in VRAM is the same as tile data, so we can just use our DefineTiles function to transfer it. We covered DefineTiles in a previous lesson...
We're going to create a function called 'SetHardwareSprite' to do the job of talking to the hardware. A is the hardware sprite number z_IXL will define the X position z_IYL will define the Y position z_L will select the flipping option and palette z_E is the tile number First we need to wait for VBLANK - we use the WaitFrame function we wrote before for this... Then we multiply A by 4 - as there are 4 bytes per sprite... we write A into $2003 - selecting the address in the OAM for the sprite we'll change... We write all 4 bytes to $2004 - it automatically increments the destination address in the OAM, so these 4 writes set the sprite data... Writing to the OAM messes up the scroll position, so we have to reset it with our ResetScroll function
We're going to show a 16x16 sprite... but sprites on the NES are 8x8 - so we're going to need 4 of them to show our image The top corner of the sprite will be at position ($40,$40) - and we're using Palette 0 for the sprite... We're going to use zero page entries z_IXL,z_IYL and z_L to define settings for our 'SetHardwareSprite' function - but we'll use X and Y as temporary registers too - as we build up the 4 sprites.
We're going to use Hardware sprite 0 for the first part - so we set A to 0... and we loaded our tile patterns into Tile 192... so we set z_e to 192 We now call our function to set the sprite.
We need to do the same for the other 3 hardware sprites... We use the X,Y registers we set up before, and add 8 to offset them for the new locations, we also INC z_E to alter the tile number, we set A each time for the hardware sprite numbers A z_E z_IXL z_IYL Pos Hardware Sprite  Pattern Xpos Ypos Top Left 0 192 $40 $40 Top Right 1 193 $40+8 $40 Bottom Left 2 194 $40 $40+8 Bototm Right 3 195 $40+8 $40+8

The Code above works... but waiting for the VBLANK all the time is not a realistic way of doing things... instead we can allocate 256 bytes of ram, write changes to the OAM there, then send them all in one go using a DMA! Lets learn how!

Using a buffer, and copying during Vblank

Our 'SetHardwareSprite' code is almost the same, just this time we're storing into the buffer, We'll transfer the data into the actual OAM during our interrupt handler
Address $FFFA of our rom is the interrupt handler We can create an interrupt handler of our own, and put it's address at $FFFA
To copy our buffer of the sprites into the OAM, we just write the top byte of the buffer address to $4014... So if our buffer is at $0300, we write $03

Lesson P35 - Hardware Sprites on the SNES / Super Famicom Of course the SNES has some pretty powerful hardware sprites - but unfortunately they're not the most simple! Lets learn how we can easily create some 8x8 sprites and get them to the screen!

BmpTest.asm

Sprite Definitions - Overview
Sprites use as special bank of 512 bytes of 'OAM' memory for their definitions... they also use standard VRAM for the pattern data.
In theory the Pattern data can be relocated... but in practice it's best to just assume it's at $4000 (address in 16 bit words)
Sprites can be various sizes - a 'default size' is set for all sprites... and certain selected sprites can be double size...
this is, however a bit tricky... lets say you have the default size as 8x8... and one double size 16,16 sprite
If we point this sprite 'double size' 16x16 sprite to pattern  'Tile 0',  the 4 8x8 chunks will be made up of tile numbers:

Lets look at this example of a 16x16 sprite in AkuSprite Editor... Akusprite editor is designed for 8x8 sprites, but we can export a 16x16 one in the following way If we want to export this quickly, so we can use it as a single doublesize sprite, one option is to tick the 'FixedSize' tickbox, and set the size to 128,16 This will export the sprite correctly - of course there will be a lot of unused space in the exported file... so we would want to combine all our 16x16 together into a single image

16x16 tiles are rather a pain... so even though our sprite today is 16x16 - we'll actually make it up out of 8x8 tiles anyway!

Sprite Definitions - Ports Used

Programming a Sprite Example!

We're going to define a 16x16 sprite... but we'll do it with 4 smaller 8x8 sprites... First we need to define some bitmap data... we used AkuSprite editor to export the sprites, then we need to send the data to VRAM
We'll use a 'SetHardwareSprite' function to do the work... we'll look at it in a moment! We need to set the X position in zero page entries z_IXH&L (a 16 bit pair) We need to set the X position in zero page entries z_IYH&L (a 16 bit pair) The Pattern number for the first part one of the sprite is 1... we store it in z_h We need to define the priority of the sprite... we store it in z_l We can also set the palette... NOTE Sprites use palette 128+ Finally we set A to the hardware sprite number... our first part will be sprite 0 (Top Left)
Now we need to do the 2nd part... We add 8 to the X position, increase our tile number, and set our hardware sprite to 1. We draw the second part (Top Right)
We're going to do the 3rd part... we move the Xpos left 8, and the Ypos down 8 We increase our tile number again, set our hardware sprite to 2 We draw the third part (Bottom Left)
Last part! We increas the Xpos by 8, Increase the Tilenum again... and set the hardware sprite to 3 We now draw the last part (Bottom Right)
The result can be seen here.

Setting a hardware sprite

Ok, Lets look at that SetHardwareSprite function... but first we need to set up sprites to work! We need to turn on the sprite layer, and also define the default memory... in these tutorials we have our sprite ram defined as memory address $4000
OK, we're ready to start setting up our sprite... We need to write 4 bytes into the first part of the OAM... the VRAM addresses are 16 bit, so each is 2 bytes...  This means we need to double the sprite number to calculate the OAM address for the hardware sprite. We then write the 4  main parameters to the OAM
OK, the next bit is a real pain... The last bit of the Xpos, and the 'Doublesize' parameter for each sprite is combined into a single byte with 4 other sprites!... GRR! We need to work out which address to work with, so we divide the sprite number by 4, and read in from the $01xx range to get the current state of the address (as it holds 3 other sprites info!)
OK, We need to work out the position of the bits we need to change, and move the two bits of our passed z_ixh into that position... To do this we define a 'Mask' - we then shift both the Mask and our data into the correct position depending on the 2 low bits of our sprite number (0-3)... this is because 4 sprites are combined into the same byte
Now we've got our mask, we use it to clear the 2 bits of the old value... Now we OR in the new value, and write the result to VRAM... We've finished the sprite!

The SNES is capable of a large number of 16 color sprites, but it's a little difficult in some ways, the 16x16 tiles are harder to use than it feels they should be, and the layout of the OAM makes setting the sprites a little tricky. Still, the fact we can use 128 hardware sprites onscreen easily is certainly a bonus!

Lesson P36 - Hardware Sprites on the C64 The Commodore 64 is capable of 8 hardware sprites on screen at the same time - and they can be 2 or 4 color just like the bitmap screen, but they don't need to be the same color depth as the screen, or even as each other... lets learn more!

SpriteTest.asm

Technical Details of Hardware Sprites

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!

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

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.

We're going to map the screen to the $4000-$8000 range - out the way of our program (which starts at $0800) and the rottern character rom (which appears at $1000-$2000 and $9000-$A000) This means we've changed our Font routines, and GetScrPos routine for any bitmap sprite functions as well!

Coding to support Hardware Sprites

We need to store our sprites in the 16k bank with our Screen Ram... but this will cause us a problem The Stack and Zeropage are $0000-$0200, the screen is at $0400-$0800, our program is at $800+, the Screen Bitmap is at $2000-$4000 - We've not got much memory left! This wouldn't be too bad if $1000-$2000 was free, but it isn't! In the VIC-20 terms this area is used by the Character Rom!... We're going to move the screen to the $4000-$8000 range - out of the way of the program, and the Character rom (it uses $1000-$2000 AND $9000-$A000) We move the screen to $4000-$7FFF by changing bits 0 and 1 of $DD00 to %0000010 We'll need to change our font code to write to the same area, or we won't see our text.
We're going to need to alter particular bits of the registers depending on the sprite number, To facilitate this, we're going to use a lookup table of bits and bitmasks to clear and set the values by sprite number.
Ok, we're going to define our SetHardwareSprite function to do the job of drawing a sprite... First we need to set the correct bit in $D015 - we do this by moving the sprite number to Y, and ORing in the bit from
We're going to use bit 4 from z_L - and set the 4 color mode accordingly in $D01C To do this we'll use 'C64SpriteConvertToMask'... it will return a mask for the sprite bit in A... and 1 or 0 depending on the bit of z_L anded with A
C64SpriteConvertToMask ANDS in z_L If the result is zero, we set z_as to zero, and load in the mask to keep the bits other than bit Y if the result is one, we set z_as so bit Y is 1, and load in the mask to keep the bits other than bit Y This gives us the function we need!
We now want to do the same for $D017 (DoubleHeight) and $D016 (DoubleWidth) using different bits of z_L
We're now going to load the 1 byte pointer (Address in VRAM /64) and save it to $07F8+SpriteNum Next  we store the color (in the bottom nibble of z_L) and store it into $D027+SpriteNum
We need to store 9 bits of the X position, and we treat the 9th bit in the same way as the other functions , where all these 9th xbits are held in $D010... We use our C64SpriteConvertToMask to do the job, but this time we AND with z_xh
Ok, we need to write the X and Y position - but these are next to each other in memory... To write them to the correct addresses, we double the sprite number in Y, and write the Low X byte to $D000+Y and the high byte to $D001+Y Phew! We're finally done!

Using our function for a test

First we need to copy our sprite data into the correct location in vram... In our test our Screen base is $4000 - so we'll load the sprites to $5000 we use the LDIR command to copy z_BC bytes from z_HL to z_DE
Ok lets set one of the sprites! We set z_IXH/L to the Xpos... We set z_IYH/L to the Ypos we need to calculate the Position in z_h... we take the OFFSET of our sprite (Sprite-Vase= $5000 -$4000=$1000) - and divide this value by 64... Remember, each sprite is 64 bytes in size! All the other settings are in z_L... Sprite Color, XY scaling, and 4 color mode bit. We set A to a number 0-7 to select the hardware sprite we want to change.
Here we've drawn two hardware sprites, a streched 4 color one, and 2 color one
If you want to create valid bitmap data for sprites, you can use my AkuSprite Editor... it's what I used to create the test sprites for this tutorial!

The C64 is capable of 8 sprites at one time, but if we're very clever, and switch the sprite data while the screen is drawing, we can up this to 8 sprites per line? Lets say there's 8 sprites on the top line of the screen... if we move those sprites to the bottom of the screen when the middle is being drawn - we'll double our sprites - we'd have to move them back before the start of the screen is drawn again! It's complex - and beyond the scope of this tutorial, but it's what the best C64 games do to make the most of the hardware!

Lesson P37 - Screen settings with the CRTC on the BBC Micro! The BBC Screen uses the same CRTC chip as the Amstrad CPC - and allows for reshaping and reconfiguration of the screen - lets take a look, and see what the settings do to the visible screen

BBC_CRTC_Test.asm

The CRTC Registers

The CRTC 6845 handles the display, it will size and position, and define the memory used by the screen...

In theory there are 17 registers, but in practice ones such as the Lightpen and Cursor registers may not be any use to us... the most interesting registers are marked in Yellow

The Various registers will define the width, height and starting position of the screen. Each screen mode will have a set of recommended registers settings (shown in the chart above), but we can resize the screen in some cases to make a smaller screen - and we may wish to do this to save memory if we don't need a 'full size' screen. By altering Reg12 we can effect hardware page flipping with Double Buffering - by allocating one memory area for a visible buffer, and a second for the drawing area, we can make sure the viewer won't see the screen redraw. In addition, we can alter Reg12+13 to effect a Horizontal or Vertical Hardware scroll - but this will expose other areas of Ram, which weren't used by the screen before.

Beware! While BeebEM recrates some of the registers - it seems it does not 'accurately' emulate a real monitor... some of the settings which may work fine on the emulator, may not work correctly on a real BBC (or may risk damage to the display in the worst situations.)

Using and Testing the registers!

We're going to define a function called SetCRTC - it will use A as the new value for CRTC register z_C We select a register using $FE00 - then set the new value for that register with $FE01
We're not going to look at the program code - it's long and not particularly related to the CRTC - what it does is let us see the changes to each register onscreen! To use it, compile 'BBC_CRTC_Test.asm'
On the left are two letters - these are keys you can press to change the register - for example J and K will change the address of the start of the screen! Try the keys - you'll see the settings in VAL (decimal) and &VL (hex) and the effect onscreen!
Because our text drawing code hasn't changed, Altering AddrH will make the screen look weird - we'd need to reprogram our drawing code to accommodate our new settings to make it all work seamlessly..
It's very easy to use some setting that are impossible to view, and now we can't see the settings any more! The tool has a Safe Mode to get around this... Press Space... this will turn on safe mode! In Safe Mode, the settings you choose will be applied for an instant, and then it will flip back to the defaults - so you can see the effect of the settings you chose, and still see all the options on a normal screen

This program just allows you to test what each register does - and find suitable settings for the screen size and position you need... Once you've done that, you'll need to reprogram your sprite, font and other drawing routines to work with the new screen position and orientation.

Lesson P38 - Character Block Graphics on the PET The PET does not have bitmap graphics, what it does have is the full combination of possibilities of a 2x2 'block' pixels defined as characters. We can use these for simple graphics.

PET_Bitmap.asm PET_Bitmap2.asm

Character Map

The PET has a character map of 128 characters... when the top bit (bit 7) is 1, these characters will be inverted - we'll need to use a combination of both for the block graphics.

The early PET had a single upper case character map... later systems had a second character map with lower case... The block characters used in this lesson exist in both.

We can switch between the two by writing to register $E84C...

VRAM Addresses

The screen is 40x25 characters... or 80x25 on later models. Putting a character onscreen is easy!... we just write a character to memory address $8000 onwards. Our formula for an address on the 40 char wide screen is Vram Address = $8000+(Ypos*40)+Xpos Our formula for an address on the 80 char wide screen is Vram Address = $8000+(Ypos*80)+Xpos
When we want to move down a line, we just add 40 or 80 to our memory address.

The character blocks

if we imagine the character block as 4 pixels in a 2x2 grid, there are 16 possible combinations. Here are the 16 - Shown separated by 'Club' symbols.
Here is the bytes that produce this pattern. The character numbers for these are a bit erratic... the ones >$80 are inverted - we have to invert half the characters to make the patterns we need. Note, the 'club' character here is ASCII 'X'

Showing our 'bitmap'

Here is the routine we'll use to show a bitmap. It's pretty simple, it copies lines of bytes from the source to screen ram, moving down a line after each line.
When we want to show a bitmap, we first calculate the destination address in Vram with GetVDPScreenPos, We then specify the source data into zero page pair z_hl, and specify our bitmap size before using ShowBitmap.
Here is the result!
If you want to create a 'bitmap' for the PET, you can do it with my Akusprite editor. It will take a bitmap, and covert it to bytes that represent the correct characters - it's what was used for this tutorial!.

The PET doesn't have any graphics modes that can do bitmaps, and unlike its successor the VIC-20, it also cannot have 'redefined' character codes. We'll have to make do with these characters in the charset for any 'game graphics'... but that's kind of the charm of these old systems!

Lesson P39 - Key reading on the PET In this episode we'll learn how to read in from the keyboard, We'll read in keys, and use them to simulate the Up,Down,Left,Right and Fire of a controller - we'll use this for games later!

PET_V1_ReadJoystick.asm

The PET Keyboard

The Keyboard of the pet is split into 10 'Blocks' (0-9)... we select one of these by writing to memory mapped port $E810, We then read from $E812 - this will return the state of each of the keys in that block ('Row' of the key matrix) - each key will be represented by one bit... a value of 1 means that key is not pressed... a value of 0 means the key is pressed! For example... Suppose we want test the Return key... this is in group 6, so we write #6 to port $E810... we then read back from $E812 - among the other keys, Bit 5 (PB5) will represent the state of Return... this row also includes Z,C,B,M,Full stop, Num1 and Num3 !

The keys matrix layout is shown below:

Simulating a joystick

We're going to read in the numpad, and use 8,2,4 and 6 as directions so we can port Y-quest and Grime to the PET We're going to create a function called "TestCursorBit" - this will test a bitmask in X of row A , and shift a bit into zero page entry z_H
We'll use this function to read in the 4 directions, and space and enter as fire buttons!

The PET didn't come with a joystick port, however it is possible make a converter and connect one via the parallel port. However, for simplicity, we'll stick to the built in keyboard for our game-controller needs!

Lesson P40 - Sound on the PET While the PET didn't come with a speaker, it's possible to add one to the external IO port. We can then use it to make simple beeps... Lets learn how!

PET_V1_ChibiSound.asm

PET Sound!

The PET is capable of up to 4 octaves... one of 3 possible pairs can be selected with $E84A.

Address $E84B will turn the sound on or off... we write #16 to turn it on, #0 to turn it off.
Address $E84A can be used to select the Octave with value 15/51/85
Address $E848 can be used to select the note, a value of 64-255 should be passed.

It is not possible to set the volume, or play multiple tones at the same time.

(Sound info taken from the PetFaq)

Sfx with Chibisound!

We turn the sound on or off with $E84B. We select our tone with $E848... Chibisound only uses one octive, setting $E848=15

Now we've got graphics, sound and input routines we can port Yquest and Grime to the PET! We'll have to use graphics characters for our game graphics!

We have to use Ascii characters for all the graphics of Yquest and Grime.
Rather than sprite bitmap data, these games use a 'list' of graphics characters to use for each object and frame of animation.