Foreword
In the previous post we managed to display the Intro screen for our game Dan Dare within our C64 FPGA implementation.As with many other C64 games, to actually start the game you need to press fire on a joystick. Since our emulator doesn't feature any joystick at the moment, the purpose of this post will be to add functionality to emulate a joystick.
For the joystick we will just use the Numeric Keypad on the USB keyboard attached to the Zybo Board.
We will also just be focusing on implementing joystick port #2 of the C64, since this is the port the game Dan Dare uses.
How Joystick port#2 is wired to the C64
A good start for this post would be to see how Joystick port#2 is connected on a real C64.The following snippet of a schematic from http://www.zimmers.net:
As you can see, joystick port#2 share wires on Port A of CIA#1 with the keyboard.
This setup of shared wires between joystick and keyboard immediately reminds us of a anomaly of joystick port#1, where moving the joystick also type characters on the screen.
One might tend to wonder why Joystick port#2 doesn't have the same effect. The answer is because we read the keyboard from port B on the CIA, which is connected to the row pins of the keyboard connector.
With no key been pressed on the keyboard, all pins would just remain high on port B of CIA#1. This is obviously by passed by Joystick #1 which is also connected to port B of CIA#1, which can pull down selected lines to zero, which the C64 will read as key presses.
Pulling down selected lines via Joystick port#2, will not have the same effect. With no keys been pressed on the keyboard, these pulled down lines would simply not propagate to port B of CIA#1.
Implementing Joystick port#2 in our C64 module
In the previous section we mentioned the concept of pulling low a line on either port A or port B on CIA#1. Thus, the keyboard and Joysticks on the C64 follows the philosophy of active when low.Another feature of port A and port B of CIA#1 is that each pin of those ports is bidirectional.
This leaves us with the question: How do you implement a bidirectional pin in an FPGA?
One might think: Sure, instead of declaring a port pin on a module as either input or output, you can just declare the bidirectional port as inout.
You can indeed create a Verilog module with inout ports. However, as soon as you may be try to connect these ports to other Verilog modules in your design, you might end up running in circles.
This is because inout pins is really only meant for pins going to the outside world, for instance if you want to implement a I2C port on your FPGA.
The FPGA synthesis tools doesn't like it at all if you try to utilise inout ports for internal use.
So in our CIA module we would need to split our bidirectional ports into two separate ports each:
module cia(
output [7:0] port_a_out,
input [7:0] port_a_in,
output [7:0] port_b_out,
input [7:0] port_b_in,
...
);
...
Next, we need to make a small adjustment when we read from Port A or B:
...
always @(posedge clk)
if(!we)
case (addr)
0: data_out <= ~((~slave_reg_0 & slave_reg_2) |
~port_a_in);
1: data_out <= ~((~slave_reg_1 & slave_reg_3) |
~port_b_in);
...
Let us try and understand what is going on here.
When we read from either port A or B, a low value can either be caused by the input port, or via the corresponding output port (e.g. slave_reg_0 or slave_reg_1).
Also, the corresponding output port is enabled by either slave_reg_2 or slave_reg_3.
The combined effect of a input and output port resembles that of an OR operation, with the inputs inverted. For this reason we are doing all the negations.
Next, let us hook up port A and port B of our CIA instances:
...
cia cia_1(
.port_a_out(keyboard_control),
.port_a_in({3'b111, joybits}),
.port_b_in(keyboard_result),
...
);
...
cia cia_2(
.port_a_out(cia_2_port_a),
.port_a_in(8'b11111111),
...
);
...
First, we hook up the five bits of our joystick to port a of CIA#1.
We also connect port A of CIA#2 to eight ones. We use the lower two bits of this port for the VIC-II banking bits. It is therefore crucial that we keep the relevant input bits high, so that the contents of the VIC-II bits doesn't get lost during bitwise operations.
Serving the joystick bits from AXI slave
Currently our AXI Slave block have two slave registers indicating which keys were pressed. Each bit position in these two registers represent the actual C64 key scan code of the key pressed.
In a similar fashion we can add a third register where each bit position represent the current posistion of the joystick, as well as whether the fire button is pressed.
Currently slave register 2 (e. g. address 0x43c0_0008), only have about three bits utilised for tape operation. So, we can just use some unused bits in this register for our joystick bits.
We will use bits 4 to 8 of this register for the joystick bits. This falls on a nybble boundary, making it convenient to see the joystick bits when you are debugging and you see the register contents in hexadecimal format.
To wire up the joystick bits from the AXI slave to our C64 module, we would follow the same approach as we previously performed to enable keyboard access for our C64 module. I will therefore not be going into detail on this.
Redirecting Numeric Pad as Joystick bits
As mentioned earlier, we will be using the numeric pad of the USB keyboard as a joystick.
You might remember from a previous post that in order to interface a USB keyboard to our C64 module, we basically catch the USB scan codes, convert it to C64 key scan codes, and setting the relevant bit (or bits if more than one pressed simultaneously) at either address 0x43c0_0000 or 0x43c0_0004.
The C64 keyboard can produce key scan codes in the range 0 to 63. We can reuse our USB scan code -> C64 scan code routine by basically using scan codes 64 upwards for our joystick bits:
u32 mapUsbToC64(int usbCode) {
if (usbCode == 0x4) { //A
return 0xa;
} else if (usbCode == 0x5) { //B
return 0x1c;
} else if (usbCode == 0x6) { //C
return 0x14;
}
...
} else if (usbCode == 0x28) { //enter
return 0x1;
} else if (usbCode == 0x2c) { //space
return 0x3c;
} else if (usbCode == 0x36) { //comma
return 0x2f;
} else if (usbCode == 53) { //play key `~
return 100;
} else if(usbCode == 96) { //up joystick
return 64;
} else if(usbCode == 90) { //down joystick
return 65;
} else if(usbCode == 92) { //left joystick
return 66;
} else if(usbCode == 94) { //right joystick
return 67;
} else if(usbCode == 98) { //fire joystick
return 68;
}
}
We invoke this method as follows:
void getC64Words(u32 usbWord0, u32 usbWord1, u32 *c64Word0, u32 *c64Word1, u32 *c64Word2) {
*c64Word0 = 0;
*c64Word1 = 0;
*c64Word2 = 0;
if (usbWord0 & 2) {
*c64Word0 = 0x8000;
}
usbWord0 = usbWord0 >> 16;
for (int i = 0; i < 2; i++) {
int current = usbWord0 & 0xff;
if (current != 0) {
int scanCode = mapUsbToC64(current);
if (scanCode == 100) {
Xil_Out32(0x43C00008, 0);
} else if (scanCode < 32) {
*c64Word0 = *c64Word0 | (1 << scanCode);
} else if (scanCode < 64) {
*c64Word1 = *c64Word1 | (1 << (scanCode - 32));
} else {
*c64Word2 = *c64Word2 | (1 << (scanCode - 64));
}
}
usbWord0 = usbWord0 >> 8;
}
for (int i = 0; i < 4; i++) {
int current = usbWord1 & 0xff;
if (current != 0) {
int scanCode = mapUsbToC64(current);
if (scanCode == 100) {
Xil_Out32(0x43C00008, 0);
} else if (scanCode < 32) {
*c64Word0 = *c64Word0 | (1 << scanCode);
} else if(scanCode < 64) {
*c64Word1 = *c64Word1 | (1 << (scanCode - 32));
} else {
*c64Word2 = *c64Word2 | (1 << (scanCode - 64));
}
}
usbWord1 = usbWord1 >> 8;
}
}
We have introduced a third word c64Word2. This will be the word we will use to populate the joystick bits at address 0x43c0_0008.
Next, we need to update our old state_machine() method (our mini USB stack method) as shown by the following snippet:
void state_machine() {
...
u32 toggle = Xil_In32(qTDAddressCheck+8) & 0x80000000;
if (!(Xil_In32(qTDAddressCheck + 8) & 0x80)) {
u32 word0 = Xil_In32(0x305000);
u32 word1 = Xil_In32(0x305004);
if (word0 == 0) {
Xil_Out32(0x43c00000, 0);
Xil_Out32(0x43c00004, 0);
u32 joy = Xil_In32(0x43c00008) | 0x1f0;
Xil_Out32(0x43c00008, joy);
} else {
//u32 bit = mapUsbToC64((word0 >> 16) & 0xff);
//bit = 1 << bit;
u32 c64Word0 = 0;
u32 c64Word1 = 0;
u32 c64Word2 = 0;
getC64Words(word0, word1, &c64Word0, &c64Word1, &c64Word2);
c64Word2 = ~c64Word2 & 0x1f;
c64Word2 = c64Word2 << 4;
/*if (bit < 32) {
c64Word0 = 1 << bit;
} else {
c64Word1 = 1 << (bit - 32);
}*/
Xil_Out32(0x43c00000, c64Word0);
Xil_Out32(0x43c00004, c64Word1);
u32 tempJoy = (Xil_In32(0x43c00008) & 0xf) | c64Word2;
Xil_Out32(0x43c00008, tempJoy);
//Xil_In32(0x305004);
}
...
}
Basically we start with word0 and word1, which show the usb scan codes of the gets that is currently been pressed.
If no key is pressed (e.g. word0 == 0), we just set bit 4 to 8 of address 0x43c0_0008 to ones.
The End Results
The following video shows what happens when we press the fire button when we are at the intro screen of the game Dan Dare:It faintly resembles the game as I remember, though garbled and frozen!
What we are missing here is implementing Raster interrupts for everything to render correctly, which we will cover in the next post.
In Summary
In this post we managed to implement a joystick in C64 module by utilising the numpad on the USB keyboard.With our Joystick we managed to transition from the Intro screen to the actual, although our emulator froze at the this point.
In the next post we will be implementing Raster interrupts so that the game screen can render properly.
Till next time!
No comments:
Post a Comment