Figure 1 : pong
Objective 1 complete, we have implemented a real world processing task on the simpleCPU, processed an image (Link). Now its time for a more significant problem. The unspoken truth about computers is that they were invented so that we can play video games :). Its true, if you go back to 1950's and were to use EDSAC, one of the first stored program computers you could play noughts and crosses against the computer(Link). To keep things simple we are going to implement on the simpleCPU the first video game I ever played: Pong, as shown in figure 1. Pong is the original table tennis game in which two players hit a ball back and forth, if your opponent misses you score a point, first to 10 wins.
The ISE project files for this system can be downloaded here: (Link), basically the same structure, but with a few tweaks and a serial port. An updated python based assembler is also available here: (Link).
What display can we use?
To controller or not to controller?
The game
Cheap FPGA board
The first problem to overcome is: what kind of display can be attached to the FPGA board? Some of these FGPA boards do have HDMI interfaces, but these must be accessed through the onboard ARM core, rather than from the general purpose FPGA resources. Therefore, HDMI is impractical for this application. The next alternative considered was an VGA display (Link). This may sound complex, but the interface circuit is relatively simple to implement in an FPGA (Link), as shown in figure 2. Pins 1(R), 2(G) and 3(B) controls each pixel's colour, represented as an analogue voltage: 0v (no colour) to 1.0V (full colour). Pixel selection is controlled via the horizontal (pin 13) and vertical (pin 14) synchronisation control signals i.e. given a fixed scan rate these signals (pulses) define the start of a row and frame updates. The analogue voltages used to define the RGB value is generated by a simple resistor based digital to analogue converter (DAC) (Link) i.e. the 510, 1K, 2K and 4K resistors shown in figure 2. These are combined with a 75 ohm termination resistor within the monitor to form a potential divider circuit, as shown in figure 3. Therefore, by setting the associated digital outputs on the FPGA to a logic 0 (0V) or logic 1 (3.3V) we can generate the output voltages shown in figure 4.
Note, this analogue circuit was simulated using LTSpice (Link).
Figure 2 : VGA interface
Figure 3 : DAC simulation
Figure 4 : DAC output voltage
I will probably build this display interface for a later model of the Pong game, but for lab usage it wasn't practical to have a second VGA monitor, as since the move to digital interfaces: display port, HDMI, DVI etc, analogue ones such as VGA are starting to become less common.
Figure 5 : LCD
The next display considered was a liquid crystal displays (LCD) panel, such as those shown in figure 5. These have either a parallel port or an I2C (Link) interface, which are again relatively simple to implement on the FPGA i.e. i have existing hardware / software for these from other projects. These displays could connect to the existing I2C interface or general purpose input/output ports (GPIO) on the FPGA board. Again, would be nice to implement this display for the "hand held" version of Pong, but decided against these from a cost view point i.e. everything starts to get expensive when you have to start kitting out a full lab :).
Figure 6 : RS232 connector
Figure 7 : RS232 wiring
This left plan B, the existing serial port shown in figure 6, and using the host PC's display. In previous versions of the simpleCPU we have used an RS232 (Link) serial port to print "Hello World" to a serial terminal running on the PC. However, in addition to sending alphanumeric characters we can also send command sequences to move the position of the cursor, print graphical symbols, or change the foreground / background colours. Typically these command sequences start with an ESC character (0x1B) followed by a "[" character (0x5B), allowing the terminal to identify that the characters that follow are a terminal command and should not be displayed. These command codes were adopted as an ANSI standard in 1981 and are therefore typical referred to as ANSI escape sequences, more information on these commands can be found here: (Link). To illustrate these commands consider the python code below:
Note, receiving a serial character across the RS232 interface, or printing a character to a terminal using a python program is basically the same thing so we can use this to our advantage when prototyping this system i.e. quicker to debug test out ideas using a high level language etc.
RED = chr(27)+"[41m"
BLACK = chr(27)+"[40m"
GOTO = chr(27)+"["
def main():
print( RED + GOTO +"12;40H " +
GOTO +"13;39H " +
GOTO +"14;40H " + BLACK )
if __name__=='__main__':
main()
By constructing the correct ASCII text string we can now move the cursor to the desired position in the terminal windows i.e. in this example initially row 12, column 40. Then to change the background colour to RED and print spaces. These will form our low resolution "pixels", allowing use to drawing a red cross in the middle of the screen, as shown in figure 8.
Figure 8 : cross.py output
Now that we have the ability to set a "pixel's" colour and to move the cursor we can start to think about how we could implement the various graphical elements within the game. My first computer was a Commodore 64, so in tribute of this machine this game's graphics will be based on Sprites (Link). A Sprite is a simple way of organising your graphical elements within a display. Each element on screen is made from one or more sprites e.g. consider the score graphics shown in figure 9. These numbers are represented as an 3 x 5 array of pixels i.e. a sprite, that is stored in memory. An active (illuminated) pixels is represented by a logic 1, an inactive pixel as a logic 0. Therefore, the data array 7, 1, 7, 4, 7 represents the symbol "2".
Figure 9 : number sprites
In early computers the main software optimisation goal was to minimise memory usage, as typically these machines only had 16KB to 64KB of main memory. By reusing these graphical elements, plotting them at different positions you could give the illusion of movement, consider the iconic 11 x 8 space invader sprites shown in figure 10.
Figure 10 : space invader sprites
In the assembly program sprites are used to represent the score, bat, net and ball. To simplify coding these are stored at the end of the program using the sprite macro as shown below. In this example the values 2 and 3 are defined. The sprite macro converts this 3-bit data into a 3-bit integer i.e. each address will only hold three pixel values. This is not very efficient as the complete sprite could be stored in a single memory location. However, this approach was taken to simplify their representation within the program. Will refine in version 2 :)
# macro
define( sprite,`.data eval(($1 * 4) + ($2 * 2) + $3)' )
# number sprites
num_2:
sprite( 1,1,1 )
sprite( 0,0,1 )
sprite( 1,1,1 )
sprite( 1,0,0 )
sprite( 1,1,1 )
num_3:
sprite( 1,1,1 )
sprite( 0,0,1 )
sprite( 1,1,1 )
sprite( 0,0,1 )
sprite( 1,1,1 )
Note another advantage of using sprite base graphics is that you can reuse the same code to draw each graphical element, greatly simplifying code development / size.
Figure 11 : variable resistor
The original Atari version of this game used two controllers based on rotational sensors, rotating anti-clockwise moves the bat up, clockwise down. These controllers used variable resistors to produce an analogue voltage to represent each bat's position. You can implement a simple analogue to digital convertors (ADC) (Link) using the resistor / capacitor circuit (Link), shown in figure 11. Converting these analogue signals into a digital representation the FPGA can use. In this circuit the FPGA board pulses the base of the transistor, discharging the capacitor. It then starts a timer on the FPGA (binary counter) and times how long it takes for the voltage on the capacitor to cross the logic 1 threshold. This delay being proportional the resistance of the variable resistor, as shown in figure 11. The plot on the left shows the delay for a small value of R and the plot on the right a larger value of R. From this delay we can therefore calculate the bat's position. This would be a workable solution, as we don't need a high resolution ADC (only 30-ish positions need to be represented), however, this would require some modifications to the FPGA boards in the lab, which would take some time to complete :(.
Figure 12 : push buttons
A simpler and cheap alternative is to use push buttons, as shown in figure 12 i.e. holding down the up or down button would move the bat in the desired direction at a constant speed. You would also need a button to trigger the ball's server function. One problem with these types of push buttons is that they suffer from contact bounce (Link) i.e. can generate false signals when pressed. To overcome this problem the RC debounce / filter circuit shown in figure 12 can be used. Again, did not take this approach for the lab owing to its labour costs, but i would use these for the hand held version of the game, as they offer a nice clean interface.
To simplify the simpleCPU implementation used in the lab i decided to use the PC's keyboard and send ASCII characters to the FPGA board via the terminal program. Also the the right hand player will be controlled using a simple AI, removing the need for two controllers, the left hand player keyboard controls are:
The final Pong system contains the simpleCPU_v1d, 4K x 16bit memory and a universal asynchronous receiver transmitter unit (UART). The UART (serial port) can operates in a full duplex mode i.e. receive and transmit serial data packets at the same time. This project can be downloaded from the link at the top of this page.
Figure 13 : memory map
Figure 14 : ISE project
Figure 15 : pong graphics
The default terminal screen size is 80 columns x 30 rows i.e. characters, an initial (approximate) game view is shown in figure 15. Within the display:
The bat stops if it reaches the top (5 pixel) or bottom (24 pixel) display limits. If the ball hits the top or bottom display limits it will bounce off this edge and continue towards the other player. When the ball reaches the left or right display limits (position 10 and 70), if any part of the that player's bat is in 'contact' with the ball the ball will bounce off the bat and travel back to the other player. If ball does not make contact with that player's bat, it will continue through and off the screen. At this point the other player's score is increased by one and service returns to the player that missed. Serves are triggered for both the AI and human player by pressing the "d" key. Each player's score is displayed at the top of the screen, as shown in figure 13. The first player to score ten is the winner. The complete python program can be downloaded here:
To run this program at the command prompt enter: python pong.py.
Note, to simplify testing the "pygame" library was used to implement an OS independent, non-blocking keyboard read i.e. if we used the standard input() function the display will stop updating until a key was pressed. The downside is that you need select the small “graphics” window to enter key presses. Also make sure the command prompt is at least 80 x 30 characters, otherwise word-wrap will cause the screen to update incorrectly.
If all is well you should now be able to play the HD, high FPS, fast action packed game shown in figure 14 :). Remember, you need to select/click-on the small pygame window to enter the key presses.
Figure 16 : pong graphics
Now that we have a prototype working in a high level language the next step is to take these ideas a port them to the simpleCPU. The main assembly code loop is shown below:
################
# THE BUG GAME #
################
# MEMORY MAP
# 0xFFF - WR - UART tx
# 0xFFF - RD - UART rx
# 0xFFE - WR - UART tx
# 0xFFE - RD - UART status
# UART REGISTERS
# TX : B7 - B0 data
# RX : B7 - B0 data
# STATUS REGISTER
# B7 : NU
# B6 : NU
# B5 : NU
# B4 : NU
# B3 : NU
# B2 : TX Idle
# B1 : RX Idle
# B0 : RX Valid
# Main
# ----
start:
call init # initialise system
call clear # clear screen
call net # draw net
call scores # draw scores
call ball # draw ball
call bat1 # draw user bat
call bat2 # draw ai bat
loop:
load RA mode # serve or play
and RA 0xFF
jumpnz play
serve:
call move_player # move player
jump loop
play:
call move_player # move player
call move_ai # move ai
call move_ball # move ball
call check # check edges
call delay # wait
jump loop # repeat
stop:
jump stop # trap code for testing
The game's main functions are broken down into a series of subroutines. At the heart of these is a common sprite based draw subroutine. To illustrate this consider the ball drawing subroutine below:
# Draw Ball
# ---------
ball:
load RA ball_x # set position
store RA column
load RA ball_y
store RA row
movea( RA, b_green ) # set colour
store RA colour
movea( RA, ball_1 ) # set graphics
store RA graphics
call draw # draw sprite
ret
ball_1:
sprite( 0,0,0 )
sprite( 0,0,0 )
sprite( 0,1,0 )
sprite( 0,0,0 )
sprite( 0,0,0 )
To generate the text string required to draw each sprite the following arguments are passed to the draw subroutine:
# Draw sprite
# -----------
draw:
move RA 0
store RA lineCnt # set sprite line to first
store RA pixelCnt # set sprite pixel to first
store RA colActive # set colour active to false
movea( RA, string_buf )
store RA bufIndex # set buffer index to start
movea( RA, b_black ) # get colour string address
store RA srcAddr # call strcpy
load RA bufIndex
store RA destAddr
call strcpy
move RA RC
store RA bufIndex
draw_next:
load RA bufIndex
move RB RA
move RA 0x1B # ESC
store RA (RB)
add RB 1
move RA 0x5B # [
store RA (RB)
add RB 1
move RA RB
store RA bufIndex
load RA row #
store RA decValue
call convDecBuf
load RA bufIndex
move RB RA
move RA 0x3B # ;
store RA (RB)
add RB 1
move RA RB
store RA bufIndex
load RA column #
store RA decValue
call convDecBuf
load RA bufIndex
move RB RA
move RA 0x48 # H
store RA (RB)
add RB 1
move RA RB
store RA bufIndex
load RA graphics # load sprite address
addm RA lineCnt
move RB RA
load RA (RB) # load pixel data
store RA line # buffer line
draw_loop:
load RA line
and RA 0x04 # test bit position
jumpz draw_black
draw_colour:
load RA colActive # is colour active
and RA 0xFF
jumpnz draw_colourSet
move RA 1 # set colour is active flag
store RA colActive
load RA colour # get colour string address
store RA srcAddr # call strcpy
load RA bufIndex
store RA destAddr
call strcpy
move RA RC
store RA bufIndex
draw_colourSet:
load RA bufIndex # draw block (space)
move RB RA
move RA 0x20
store RA (RB)
add RB 1
move RA RB
store RA bufIndex
jump draw_nextPixel
draw_black:
load RA colActive
and RA 0xFF
jumpz draw_blackSet
move RA 0 # set colour is not active flag
store RA colActive
movea( RA, b_black ) # get colour string address
store RA srcAddr # call strcpy
load RA bufIndex
store RA destAddr
call strcpy
move RA RC
store RA bufIndex
draw_blackSet:
load RA bufIndex # draw block (space)
move RB RA
move RA 0x20
store RA (RB)
add RB 1
move RA RB
store RA bufIndex
draw_nextPixel:
load RA line # move to next pixel
asl RA
store RA line
load RA pixelCnt # inc pixel count
add RA 1
store RA pixelCnt
sub RA 3
jumpnz draw_loop
move RA 0 # zero pixel count
store RA pixelCnt
load RA row # move to next row
add RA 1
store RA row
load RA lineCnt # inc line count
add RA 1
store RA lineCnt
sub RA 5 # have all 5 rows been processed?
jumpnz draw_next
load RA bufIndex # yes, insert NULL
move RB RA
move RA 0x0
store RA (RB)
call txString # display string
ret
The draw subroutine constructs the required text string in the array string_buf in memory to draw the request sprite. When complete this buffer is then transmitted to the host PC across the serial link via the UART. As part of this process the row and column values at which the sprite is drawn need to be converted into decimal characters as defined by the ANSI Set Graphic Rendition (SGR) command codes. To convert the simpleCPU's binary values into decimal characters the convDefBuf subroutine is used:
# Convert variable DECVALUE into decimal characters
# -------------------------------------------------
# Used in cursor movement commands RANGE limited to 99 - 0
convDecBuf:
load RA bufIndex
move RD RA
load RA decValue
move RB 0
convDecBuf_H:
sub RA 10 # sub 10
move RC RA # copy for compare
and RC 0x80 # neg?
jumpnz convDecBuf_HTx # yes, exit
add RB 1 # inc count
jump convDecBuf_H # repeat
convDecBuf_HTx:
add RA 10 # undo last sub
move RC RA # buffer for units
and RB 0xFF # skip if 10s count 0
jumpz convDecBuf_LTx
move RA RB # copy count
add RA 0x30 # convert to ASCII
store RA (RD)
add RD 1
convDecBuf_LTx:
move RA RC # copy count
add RA 0x30 # convert to ASCII
store RA (RD)
add RD 1
move RA RD
store RA bufIndex
ret
A significant amount of the processing time involved in generating the required text string is copying the selected escape sequences into the string_buf buffer. This is done using the strcpy subroutine:
# Copy string (must terminate with a \0)
# --------------------------------------
# Source / destination addresses passed in SRCADDR / DESTADDR
strcpy:
load RA srcAddr # get source address
move RB RA
load RA destAddr # get destination address
move RC RA
strcpy_loop:
load RA (RB) # load char
and RA 0xFF
jumpz strcpy_exit # exit if 0
store RA (RC) # copy
add RB 1
add RC 1
jump strcpy_loop # repeat
strcpy_exit:
ret
When the TX buffer string_buf contains the final escape sequences these are transmitted to the host PC using the txstring subroutine:
# TX String (must terminate with a \0)
# ------------------------------------
# Base address passed in variable STRING
txString:
movea( RB, string_buf ) # get string address
tx_loop:
load RA (RB) # load char
and RA 0xFF
jumpz tx_exit # exit if 0
store RA TXCHAR # tx
waitTX:
load RA STATUS # test TX status wait till 1
and RA 0x04
jumpz waitTX
add RB 1 # inc address
jump tx_loop # repeat
tx_exit:
ret
)
With a few slight variations on this theme and a basic state machine to control the different phases of the game we can implement a simpleCPU version of Pong. To display the escape sequences on the PC, open a terminal window, resize to at least 80 x 30 to avoid word wrap, then enter:
screen /dev/ttyUSB0 19200
Screen shots of the game running are shown in figure 17. A short video of the game in action is available here (Link).
Note, to exit screen press CTL+a, then k, then answer yes. Confess its a little slow on the screen update, but this was due to the RS232 to USB serial port adapter's max speed being limited to 19200 bps. Could of easily got a x8 increase in screen fps if i had bought the more expensive 115200 bps version :(.
Figure 17 : Xilinx pong game
The lab FGPA boards are Xilinx based, good functionality, but the downside is that they are a little on the expensive side. However, i found a cheap Altera FPGA board online: Altera FPGA Cyclone ll EP2C5T144 Development Board. This board (£15), plus its USB programming cable (£8), came to approximately £21, shown in figure 18. Therefore, i decided to port the simpleCPU pong game to this new board.
Figure 18 : Altera Cyclone ll FPGA EP2C5T144 development board (left), USB Blaster JTAG Download Cable Debugger (right)
This minimal developed board only has GPIO pins, so to implement the RS232 interface i used the USB to TTL Serial Debug Cable shown in figure 19, costing approximately £4. This cable has four pins: Red +5V, Black GND, Green TXD, White RXD. The USB adapter is a PL2303, it doesn't seem to work / has "issues" under windows, but is fine in Linux. I did have a Google around, there seems to be some discussion about using an older driver, but as it worked under Linux i didn't want to mess up my windows box.
Figure 19 : USB to TTL Serial Debug Cable
To program this FPGA use Quartus II 13.0sp1 Web Edition (Link). Note, there are newer versions of Quartus, but these do not support the Cyclone II chipset. This software is similar to the Xilnx ISE environment allowing schematic and HDL design entry, but as you would expect you can't import the Xilinx schematics :(. Therefore, i decided to manually convert the schematic into a VHDL representation to simplify the transition to this new FPGA i.e. define the processor and its peripherals using generic VHDL models. As always the one exception to this plan is the memory. As with Xilinx designs these need to be mapped to the FPGA specific memory cores. For Xilinx these are RAMB16_S4 block rams (Link) and for Altera M4K memory blocks (Link). To generate the Altera's memory i used the Mega Wizard plug-in manager as shown in figure 20.
Figure 20 : M4K memory block
Unfortunately these memory devices are slightly different from the original ones used in the Xilinx FPGAs :(. Both FPGAs use synchronous memory devices, but the Altera's FPGA memory has an additional output buffer stage (registered) i.e. memory timings are different, the Altera memory blocks taking an additional clock cycle. Note, this problem is due to how the simpleCPU operates, the Altera FPGA memory is just as fast as the Xilinx FPGA, but its intended for pipeline operations, unfortunately the simpleCPU was not designed to operate in this way. Therefore, this timing problem messes up the fetch and execute phases on the simpleCPU. We could overcome these issues by modifying the simpleCPU's architecture i.e. the number of clock cycles needed for instructions that access operands from memory (LOAD, STORE, ADDM and SUBM). That would be a pain and i don't want to start modifying the simpleCPU's internals for different FPGA's. Therefore, bodge :). To get the same functionality i used a phase lock loop (PLL) on the Altera FPGA to generate two different clocks, the standard 10MHz system clock and a 20MHz clock, with a 90 degree phases shift, as shown in figure 21.
Figure 21 : PLL 20MHz clock parameters
The CPU is runs at 10MHz and the memory now runs at 20MHz, it still takes an extra clock cycle to get the data from the memory, but as its running twice as fast, from the CPU's point of view it's all good. Yes i know a bodge, but it works :), a final compiled top_level design is shown in figure 22.
Figure 22 : top_level Quartus II project
Screen shots of the game running are shown in figure 23. A short video of the game in action is available here (Link).
Figure 23 : Altera pong game
Both FPGA boards use a 3.3V IO standard, therefore, the +5V signal from the USB to TTL serial debug cable to the FPGA board need to be shifted down to this level. Signals from the FPGA to the USB to TTL serial debug cable are ok as 3.3V signals will still be interpreted as a logic 1. You can buy specific level shifter ICs to implement these functions, however, for this system a simple resistor circuit will suffice, as shown in figures 24 and 25.
Figure 24 : Altera FPGA board
This circuit is a simple potential divider, halving the TX signal from the USB to TTL serial cable.
Figure 25 : Level shifter
Work done for the present. As previously discussed the next version will be a hand held implementation.
WORK IN PROGRESS
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Contact email: mike@simplecpudesign.com