Lesson P11 - Joystick Reading on the Genesis The original Genesis controller had 3 fire buttons, and one select... but later on, to compete with the SNES an extra 3 buttons were added, We need to use a control port to select the keys to read in, then read the actulal keystates from a second port, Lets take a look!

BitmapTest.asm

Common Data format for Joypad controls used by these tutorials

On the Z80 We used to read in the buttons and fires into a single byte... on the 68000 systems we're going to keep the same format for ULDR Fire1+2 and start... but we'll also extend into a second byte for any extra fire buttons we have... for each bit, a 1 means the button is up (unpressed) a 0 means the button is down (pressed) We'll load player 1's joystick data into D0... and player 2's into D1

Bit F E D C B A 9 8 7 6 5 4 3 2 1 0 Meaning - - - F8 F7 F6 F5 F4 Start F3 F2 F1 Rgt Lft Dn Up

Our test program is very simple, all it does is read in the two controllers, and show the value of the registers to the screen.

Genesis Joystick Ports
Each joystick has two ports - on for Reading or Writing  of Data... and one Control port, to set the direction (Read or Write) of each bit of the data port (0=Read, 1=Write)
We will need to set bit 6 to Write to read all the Genesis Buttons

End address	Description
$A10003	Controller 1 data
$A10005	Controller 2 data
$A10009	Controller 1 control
$A1000B	Controller 2 control

The Genesis Joystick ports are backwards compatible with the Mastersystem, therefore we have to send a sequence of 1's and 0's to the 'TH' bit (Bit 6) to select the different buttons available
Note: Some of the buttons are duplicated in multiple read configurations.

TH Bit Write	7	6	5	4	3	2	1	0	Notes
1	0	(TH)	C	B	Right	Left	Down	Up
0	0	(TH)	Start	A	0	0	Down	Up
1,0,1,0,1*,0	0	(TH)	C	B	X	Y	Z	Mode	* should perform a write of 0 to TH afterwards to reset sequence (1,0,1,0,1,0)

If you only want to use the basic 3 fires, you can ignore the 3rd option... also note that not all 6 button joysticks have a 'Mode' button.

Getting Data from the Joysticks

We're going to process Joystick 2, then Joystick 1, using a common function to do the reading and bitshifting work (Player_ReadOne) Whichever Joystick we want to read from, we need to first set all the bits to Read EXCEPT bit 6 - which we need to set to Write ,0We then move the data port to use into A0 (as it's different for each joystick) before calling Player_ReadOne
We need to send commands to the data port, alternating bit 6 between 1,0,1,0,1,0... we do to NOP commands to effect a short delay to allow the joystick hardware to respond to the change. After the 1st,3rd and 5th flip, we need to store a byte, we back these up intoo D1,D2 and D3... we'll use these in a moment.
The bits in D1, D2 and D3 are in the wrong order, so we're going to do a series of bit shifts and masks to get the buttons into our 'standard format' We need to get the bit for A and Start into the CBRLDU bits,  and M and XYZ are in the wrong order - we want M as the last button

Lesson P12 - Joystick Reading on the Amiga The Amiga uses the classic 'Atari style' 4 direction 1 fire 9 pin joystick... Despite being such a classic digital joystick, it's actually connected to a 'Mouse Port' and the data is encoded in a way we've not seen in these tutorials before... lets take a look!

BitmapTest.asm

Mouse Joystick position ports
joysticks on the Amiga connect to the Mouse ports... the data is 'encoded' in the bits of the Horizontal Data

NAME	ADDR	FUNCTION
JOY0DAT	$DFF00A	Joystick-mouse 0 data (vert,horiz)
JOY1DAT	$DFF00C	Joystick-mouse 1 data (vert,horiz)

To covert data from these ports into a traditional digital joystick direction, we need to do some logical operations.

Direction	Represented by   Bits in $DFF0A/C
Right	1
Left	9
Down	1 XOR 0
UP	9 XOR 8

We also need to get the joystick fire buttons from a different port:

Address	Purpose
$BFE001	FIR1 / FIR0 / RDY / TK0 / WPRO / CHNG / LED / OVL
$BFE201	Direction for bits of port A ($BFE001)... 1=Out / 0=In

The Amiga uses the same ports for Mice and Joysticks... we'll assume Port 0 has a Mouse, and Port 1 has a Joystick... While our code will support 2 joysticks, Port 1's joystick will be Joystick 1, and Port 0's will be Joystick 2.

Common Data format for Joypad controls used by these tutorials

On the Z80 We used to read in the buttons and fires into a single byte... on the 68000 systems we're going to keep the same format for ULDR Fire1+2 and start... but we'll also extend into a second byte for any extra fire buttons we have... for each bit, a 1 means the button is up (unpressed) a 0 means the button is down (pressed) We'll load player 1's joystick data into D0... and player 2's into D1

Bit F E D C B A 9 8 7 6 5 4 3 2 1 0 Meaning - - - F8 F7 F6 F5 F4 Start F3 F2 F1 Rgt Lft Dn Up

Our test program is very simple, all it does is read in the two controllers, and show the value of the registers to the screen.

Reading the Joysticks

We're going to need to set the top two bits of Port A ($BFE001) to READ so we can get the joystick buttons, Next we'll read joystick 2's XY data from $DFF00A, (we're treating Mouse Port 0 as Joystick 2)... we'll load this into D2. We're also going to load Joystick 2's fire button from $BFE001 into D5... it's in Bit 6, but we need it in bit 7 We're going to call Player_ReadControlsOne to covert the input into the correct format in D0... Once we've done Joystick 2, we push the result onto the stack, and do the same for Joystick 1
First we're going to get the 4 bits we need from the Mouse position word into 4 registers (0,1,8 and 9) We'll need these to calculate the U D L R position of the joystick in a moment.
We use the bits we extracted in the last stage to calculate the state of the Up and Down directions, and we shift all the bits into our destination register D0
Finally we want to shift in the Fire bit into Bit 4, we then need to flip all the bits of UDLR, and set all the unused bits to 1.

Because there will often be a Mouse plugged into Port 0, Joystick 2 may give unpredictable results, so you should either ignore it, or keep it disabled by default.

Lesson P13 - Palette definitions on the X68000 The x68000 has a great palette, using 15 bits per color!... We just need to write to the correct memory address... In these tutorials we use a common format on all platforms, which is one nibble per channel, we just need to covert to the format needed by the x68

Palette Definitions on the x68000

The Palette on the x68000 use 2 bytes per entry... it uses 5 bits per channel. In our tutorials we use a common palette format,	F E B C D A 9 8 7 6 5 4 3 2 1 0 Tutorial Format - - - - G G G G R R R R B B B B X68000 Format G G G G G R R R R R B B B B B -
We use Memory addresses $E82000-$E82220 to define the palettes of the x68000, Each entry uses 2 bytes, and we have different definitions for the Graphics layers, Text layers, and Sprites	Address   Entries   Purpose $e82000 256.w Graphics palette $e82200 16.w Text palette (Palette block 0) $e82220 240.w Sprite palette ('' 1-15)

Setting the palette

We define our palette with two bytes per entry Our code will convert this for every system (Except the QL which has a fixed 8 color palette)
We're going to use these definitions with our 'SetPalette' function that will set each color for us... We just need to loop around all the colors we need. We'll look at SetPalette next...
We need to split up each of our 3 channels, and move them around. Although in the correct GRB order, our definitions are 4 bits per pixel, and the x68000's are 5 bits, we need to shift them around. We also need to calculate the address of the palette we want to change, The palette entries for the background start from $E82000, the sprite palettes start from $E82220

Note that we do not use the 'Text layer' for our text in these tutorials, we draw directly to the bitmap layer, so we don't set the text palette here. We WILL be looking at sprites in a later tutorial!

Lesson P14 - Palette definitions on the Atari ST While later versions may have had better color, the basic Atari uses 3 bits per channel,  Lets learn how to set the colors with our palette

Palette Definitions on the Atari ST

The Palette on the Atari ST use 2 bytes per entry... it uses 3 bits per channel. In our tutorials we use a common palette format which uses one nibble per channel We use Memory addresses $FF8240-$FF825F to define the palettes of the Atari ST, Each entry uses 2 bytes

F E B C D A 9 8 7 6 5 4 3 2 1 0 Tutorial Format - - - - G G G G R R R R B B B B Atari ST Format - - - - - R R R - G G G - B B B

Setting the palette

We define our palette with two bytes per entry Our code will convert this for every system (Except the QL which has a fixed 8 color palette)
We're going to use these definitions with our 'SetPalette' function that will set each color for us... We just need to loop around all the colors we need. We'll look at SetPalette next...
We need to split up each of our 3 channels, and move them around. Although in the correct GRB order, our definitions are 4 bits per pixel, and the Atari's are 3 bits, we also need to shift them around. We AND with $E (%1110 ) to keep the 3 bits we want and use ROL to shift those bits in the correct position We also need to calculate the address of the palette we want to change, The palette entries start from $ff8240, and each uses 2 bytes, so we do a ROL to double the palette number to get the byte offset

The Atari ST has no Hardware sprites or other layers, so these 16 palette entries are all that the basic Atari ST has... The Falcon had more colors, but it's outside of the scope of these tutorials.

Color definitions
Palette data is stored between $400000-$401FFF
Each color is 2 bytes in size, there are 16 colors in each palette, and 256 palettes.

The first color in the first palette is special ($400000), it must be $8000... this is called the "Reference color"
The last color in the last palette is special ($401FFE), it is the "Background" color that shows through, when all other layers are transparent
By default, the 'offscreen' border areas of the tilemap are filled with Color $400004

The 16 bits of Color data are in the following format:

The Color format is quite odd!
Each color is defined by 5 bits.. .but the lowest bits for each channel is separate from the rest... this means each color can be quickly defined by a single nibble - or all 5 can be used together...
There is also a "Dark" bit... which is effectively the least significant bit for all 3 color channels.

Setting the palette

Color Ram addresses
Setting colors on the Genesis is the same as writing to memory... we set the VDP Write address to C0xx0000 - where xx is the byte of the color entry.

Colors are defined by 16 bits in the following format

Setting the palette

The Color Changing Code

It's the Copperlist that actually effectively sets the colors on the Amiga, so the code that actually sets the colors is in the v1_BitmapMemory.asm... We store the address of the first palette change code in 'PalettePointer'
We define our palette with two bytes per entry Our code will convert this for every system (Except the QL which has a fixed 8 color palette)
We're going to use these definitions with our 'SetPalette' function that will set each color for us... We just need to loop around all the colors we need. We'll look at SetPalette next...
When we want to set the palette, first we check we're being asked to change a color less than 31, As our Copperlist entry uses 4 byte entries we rotate our palette number left 2 times to multiply it by 4, We then add 2 - as the left two bytes are the Address (The right 2 are the -RGB palette definition) We now split out each channel from the $-GRB source definition into the $-RGB definition the Amiga needs, Once we've done this we write it to the copperlist address in a0 The color will change during the next screen redraw!

FM Sound on the x68000 with the YM2151 Chip

The YM2151 is controlled by 255 registers, that are summarized below: