Lab 4: High level I/O - VGA, PS/2 Keyboard, and Audio Solution

Introduction




In this lab will use the high level I/O capabilities of the DE1-SoC computer. In particular, the tasks will:




Use the VGA controller to display pixels and characters. Use the PS/2 port to accept input from a keyboard




Use the audio controller to play generated tones





















1 VGA




For this part, it is necessary to refer to section 4.2 (pp 40-43) of the De1-SoC Computer Manual.




Brief overview of the De1-SoC computer VGA interface




The VGA controller hardware has already been introduced in the ECSE 222 labs. The De1-SoC computer has a built in VGA controller, and the data displayed to the screen is acquired from two sections in the FPGA on-chip memory - the pixel buffer and the character buffer - which are described in sufficient detail in section 4.2.1 and 4.2.3 of the De1-SoC Computer Manual. For this lab, it is not required to make use of the double buffering feature described in the manual.







VGA driver




Create two files VGA.s and VGA.h and place them in the correct folders. The code for the header file is shown in Figure 1.

















































Figure 1: Code for the VGA.h file




The subroutines VGA clear charbuff ASM and VGA clear pixelbuff ASM should clear (set to 0) all the valid memory locations in the character buffer and pixel buffer respectively.







VGA write char ASM should write the ASCII code passed in the third argument to the screen at the (x,y) coordinates given in the first two arguments. Essentially, the subroutine will store the value of the third argument at the address calculated with the first two arguments The subroutine should check that the coordinates supplied are valid (i.e. x = [0,79] and y = [0,59]).







VGA write byte ASM should write the hexadecimal representation of the value passed in the third argument to the screen. This means that this subroutine will print two characters to the screen! (For example, passing a value of 0xFF in byte should result in the characters ’FF’ being displayed on the screen starting at the x,y coordinates passed in the first two arguments) Again, check that the x and y coordinates are valid, taking into account that two characters will be displayed.







Both the above subroutines should only access the character buffer memory.




Finally, the VGA draw point ASM subroutine will draw a point on the screen with the colour as indicated in the third argument, by accessing only the pixel buffer memory. This subroutine is very similar to the VGA write char ASM subroutine





NOTE: Use suffixes ‘B’ and ‘H’ with the assembly memory access instructions in order to read/modify bytes/half-words







Simple VGA application




Build a C based application to test the functionality of the VGA driver. Write three functions as shown in Figure 2


















































































Figure 2: C functions used to test the VGA driver




Use the pushbuttons and slider switches as follows:




PB0 is pressed: if any of the slider switches is on, call the test byte() function, otherwise, call the test char() function.






PB1 is pressed: PB3 is pressed: PB4 is pressed:




call the test pixel() function.







clear the character buffer.




clear the pixel buffer.








2 Keyboard




For this part, it is necessary to refer to section 4.5 (pp 45-46) in the De1-SoC Computer Manual.




Brief overview of the PS/2 Keyboard Protocol




For the purpose of this lab, a very high level description of the PS/2 keyboard protocol is given. A more detailed description can be found at this link.




The PS/2 bus provides data about keystroke events by sending hexadecimal numbers called scan codes, which for this lab will vary from 1-3 bytes in length. When a key on the PS/2 keyboard is pressed, a unique scan code called the make code is sent, and when the key is released, another scan code called the break code is sent. The scan code set used in this lab can be found here.




Two other important parameters involved are the typematic delay and the typematic rate. When a key is pressed, the corresponding make code is sent, and if the key is held down, the same make code is repeatedly sent at a constant rate after an initial delay. The make code will stop being sent only if the key is released or another key is pressed. The initial delay between the first and second make code is called the typematic delay, and the rate at which the make code is sent after this is called the typematic rate. The typematic delay can range from 0.25 seconds to 1.00 second and the typematic rate can range from 2.0 cps (characters per second) to 30.0 cps, with default values of 500 ms and 10.9 cps respectively.

















































(a) Key ’a’ is pressed and released

















































(b) Key “a” is pressed, held down, and then released




Figure 3: Example of data received on the PS/2 bus

PS/2 keyboard driver




Create two files ps2 keyboard.s and ps2 keyboard.h and place them in the correct folders.







For this lab, simply implement a subroutine with the following specifications:




Name: read PS2 data ASM




Argument: A char pointer variable data, in which the data that is read will be stored




Return type: Integer that denotes whether the data read is valid or not




Description: The subroutine will check the RVALID bit in the PS/2 Data register. If it is valid, then the data from the same register should be stored at the address in the char pointer argument, and the subroutine should return 1 to denote valid data. If the RVALID bit is not set, then the subroutine should simply return 0.







Simple keyboard application




Create a simple application that uses the PS/2 keyboard and VGA monitor. The application should read raw data from the keyboard and display it to the screen if it is valid. Only the VGA write byte ASM subroutine is needed from the VGA driver, and the input byte is simply the data read from the key-board.







Note: In the program, keep track of the x,y coordinates where the byte is being written. For example, write the first byte at (0,0) and the second byte at (3,0) and so on until the first line on the screen is full, and then start writing bytes at (0,1), (3,1), (5,1) etc. A gap of 3 x co-ordinates is given since each byte will display two characters, and one more for a space between each byte.




3 Audio




For this part, it is necessary to refer to section 4.1 (pp 39-40) of the De1-SoC Computer Manual




Write a driver for the audio port following the same procedure introduced so far. The driver should only have one subroutine. The subroutine should take one integer argument and write it to both the left and the write FIFO only if there is space in both the FIFOs (Hint: Use the value of WSLC and WSRC in the subroutine). The subroutine should return an integer value of 1 if the data was written to the FIFOs, and return 0 otherwise.




Use the driver in an application that plays a 100 Hz square wave on the audio out port. The frequency can be achieved by knowing the sampling rate of of the audio DAC. For example, if the sampling rate is 100 samples per second and a 2 Hz square wave is to be played, that means there are two complete cycles of the wave contained in 100 samples, so for 25 samples a ‘1’ should be written to the FIFOs, and for 25 samples a ‘0’ should be written to the FIFOs.




For this lab, find the sampling rate from the manual and calculate the number of samples for each half cycle of the square wave. Finally, write 0x00FFFFFF and 0x00000000 to the FIFO instead of ‘1’ and ‘0’.
























5
4 Grading




The TA will ask to see the following deliverables during the demo (the corresponding portion of the grade for each is indicated in brackets):




VGA (30%)




P/2 Keyboard (20%) Audio (20%)




Full marks are awarded for a deliverable only if the program functions correctly and the TA’s ques-tions are answered satisfactorily.




A portion of the grade is reserved for answering questions about the code, which is awarded in-dividually to group members. All members of your group should be able to answer any questions the TA has about any part of the deliverables, whether or not you wrote the particular part of the code the TA asks about. Full marks are awarded for a deliverable only if the program functions correctly and the TA’s questions are answered satisfactorily.




Finally, the remaining 20% of the grade for this Lab will go towards a report. Write up a short (2-3) page report that gives a brief description of each part completed, the approach taken, and the challenges faced, if any. Please don’t include the entire code in the body of the report. Save the space for elaborating on possible improvements you made or could have made to the program.




Your final submission should be a single compressed folder that contains your report and all the code files, correctly organized (.c, .h and .s).




This Lab will run for two weeks, from March 12th to March 23rd. Demos for Lab 4 will begin in the week of March 19th to March 23rd, and demos will also be accepted in the week of March 26th to March 30th, within your assigned lab section. The report for Lab 4 is due by 11:59 pm, March 30th.
























































































6