Description
If you implemented your driver correctly, compiling and running the program will draw the following image.
2. Reading keyboard input
For the purpose of this lab, here’s a high level descrip on of the PS/2 keyboard protocol. For a more comprehensive resource, see Sec on 4.5 (pp. 45-46) of the DE1-SoC Computer Manual.
/
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 is summarized by the table below. (Originally taken from Baruch Zoltan Francisc’s page on PS/2 scan codes.)
KEY
MAKE
BREAK
KEY
MAKE
BREAK
KEY
A
1C
F0,1C
9
46
F0,46
[
B
32
F0,32
\`
0E
F0,0E
INSERT
C
21
F0,21
–
4E
F0,4E
HOME
D
23
F0,23
=
55
FO,55
PG UP
E
24
F0,24
\
5D
F0,5D
DELETE
F
2B
F0,2B
BKSP
66
F0,66
END
G
34
F0,34
SPACE
29
F0,29
PG DN
H
33
F0,33
TAB
0D
F0,0D
U ARROW
I
43
F0,43
CAPS
58
F0,58
L ARROW
J
3B
F0,3B
L SHFT
12
FO,12
D ARROW
K
42
F0,42
L CTRL
14
FO,14
R ARROW
L
4B
F0,4B
L GUI
E0,1F
E0,F0,1F
NUM
M
3A
F0,3A
L ALT
11
F0,11
KP /
N
31
F0,31
R SHFT
59
F0,59
KP *
O
44
F0,44
R CTRL
E0,14
E0,F0,14
KP –
P
4D
F0,4D
R GUI
E0,27
E0,F0,27
KP +
Q
15
F0,15
R ALT
E0,11
E0,F0,11
KP EN
R
2D
F0,2D
APPS
E0,2F
E0,F0,2F
KP .
S
1B
F0,1B
ENTER
5A
F0,5A
KP 0
T
2C
F0,2C
ESC
76
F0,76
KP 1
U
3C
F0,3C
F1
05
F0,05
KP 2
V
2A
F0,2A
F2
06
F0,06
KP 3
W
1D
F0,1D
F3
04
F0,04
KP 4
X
22
F0,22
F4
0C
F0,0C
KP 5
/
Y
35
F0,35
F5
03
F0,03
KP 6
Z
1A
F0,1A
F6
0B
F0,0B
KP 7
0
45
F0,45
F7
83
F0,83
KP 8
1
16
F0,16
F8
0A
F0,0A
KP 9
2
1E
F0,1E
F9
01
F0,01
]
3
26
F0,26
F10
09
F0,09
;
4
25
F0,25
F11
78
F0,78
‘
5
2E
F0,2E
F12
07
F0,07
,
E0,F0,
PRNT
E0,12,
6
36
F0,36
7C,E0,
.
SCRN
E0,7C
F0,12
7
3D
F0,3D
SCROLL
7E
F0,7E
/
E1,14,77,
8
3E
F0,3E
PAUSE
E1,F0,14,
F0,77
Two other parameters involved are the typema c delay and the typema c 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 a er an ini al delay. The ini al delay ensures that briefly pressing a key will not register as more than one keystroke. The make code will stop being sent only if the key is released or another key is pressed. The ini al delay between the first and second make code is called the typema c delay, and the rate at which the make code is sent a er this is called the typema c rate. The typema c delay can range from 0.25 seconds to 1.00 second and the typema c rate can range from 2.0 cps (characters per second) to 30.0 cps, with default values of 500 ms and 10.9 cps respec vely.
Task: Create a PS/2 driver
The DE1-SoC receieves keyboard input from a memory-mapped PS/2 data register at address 0xff200100 . Said register has an RVALID bit that states whether or not the current contents of the register represent a new value from the keyboard. The RVALID bit can be accessed by shi ing the data register 15 bits to the right and extrac ng the lowest bit, i.e.,
RVALID = ((*(volatile int *)0xff200100) >> 15) & 0x1 . When RVALID is true, the low eight
bits of the PS/2 data register correspond to a byte of keyboard data.
The hardware knows when you read a value from the memory-mapped PS/2 data register and will automa cally present the next code when you read the data register again.
For more details, see Sec on 4.5 (pp. 45-46) of the DE1-SoC Computer Manual.
/
Download ps2.s. This assembly file implements a program that reads keystrokes from the keyboard and writes the PS/2 codes to the VGA screen using the character buffer. Copy your VGA driver into ps2.s . Then implement a func on that adheres to the following specifica ons:
Name:
read_PS2_data_ASM
Input argument (r0): A memory address in which the data that is read from the PS/2 keyboard will be stored (pointer argument).
Output argument (r0): Integer that denotes whether the data read is valid or not.
Descrip on: The subrou ne 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 pointer argument, and the subrou ne should return 1 to denote valid data. If the RVALID bit is not set, then the subrou ne should simply return 0.
read_PS2_data_ASM
’s C declara on is as follows:
int read_PS2_data_ASM(char *data);
Testing the PS/2 driver
To verify that the PS/2 driver is working correctly, you can type into the simulator’s PS/2 keyboard device and verify that the bytes showing up on the screen correspond to the codes you might expect from the table in this sec on’s introduc on.
If you implemented your PS/2 and VGA drivers correctly, then the program will print make and break codes whenever you type in the simulator’s keyboard input device. Make sure to use the keyboard device that says ff200100 .
Note: If you did not manage to implement a working VGA driver, then you can s ll get credit
for the PS/2 driver by replacing
with the implementa on below. It will write
write_byte
PS/2 codes to memory address
. Delete all calls to VGA driver func ons and delete
0xfff0
the write_hex_digit func on to ensure that your code s ll compiles.
/
write_byte:
push
{r3, r4, lr}
ldr
r4, =0xfff0
and
r3, r3, #0xff
str
r3, [r4]
pop
{r3, r4, pc}
3. Putting everything together: Vexillology
We will now create an applica on that paints a gallery of flags. The user can use keyboard keys to navigate through flags. Pressing the D key will prompt the applica on to show the next flag. Similarly, pressing the A key will prompt the applica on to show the previous flag. Pressing A when at the first flag or D when at the last flag cycles to the last or first flag, respec vely.
Download flags.s. This file implements an input loop that reads keystrokes from the keyboard, tests if they are A or D key presses, and cycles flags accordingly. It also implements a func on that draws the flag of Texas.
Your task is twofold:
1. Include your VGA and PS/2 driver func ons.
2. Implement flag pain ng logic for two other flags by rewri ng draw_real_life_flag and
. One flag must be a real-life flag and another flag can be a flag you
Hint: The starter code includes the draw_rectangle and draw_star func ons. You can use these func ons to draw any flag that consists of rectangles and stars. This encompasses many flags, from the flags of the US to France and even China.
draw_rectangle draws a rectangle. It takes five arguments. The first four arguments are stored in registers r0 through r3. The fi h argument is stored on the stack at address
[sp]
. draw_rectangle ’s signature is:
/**
• Draws a rectangle.
• @param x The x coordinate of the top left corner of the rectangle.
• @param y The y coordinate of the top left corner of the rectangle.
• @param width The width of the rectangle.
• @param height The height of the rectangle.
• @param c The color with which to fill the rectangle.
*/
void draw_rectangle(int x, int y, int width, int height, int c);
draw_star draws a star. It takes four arguments, stored in registers r0 through r3. Its signature is:
/
/**
• Draws a star.
• @param x_center The x coordinate at which the star is centered.
• @param y_center The y coordinate at which the star is centered.
• @param radius The star’s radius.
• @param c The star’s color.
*/
void draw_star(int x_center, int y_center, int radius, int c);
Hint: The flag of Texas as drawn by the starter code should look like the image below. If it doesn’t, then your VGA driver might be faulty.
Grading and Report
Your grade will be evaluated through the deliverables of your work during the demo (70%) (basically showing us the working programs), your answers to the ques ons raised by the TA’s during the demo (10%), and your lab report (20%).
Grade distribu on of the demo:
Part 1: VGA driver (30%).
Part 2: PS/2 driver (20%).
Part 3: Flag gallery applica on (20%).
/
Write up a short report (max 5 pages in total) that should include the following informa on.
A brief descrip on of each part completed (do not include the en re code in the body of the report).
The approach taken (e.g., using subrou nes, stack, etc.).
The challenges faced, if any, and your solu ons.
Possible improvement to the programs.
Your final submission should be submi ed on myCourses. The deadline for the submission and the report is Friday, 4 December 2020. A single compressed folder should be submi ed in the .zip format, that contains the following files:
Your lab report in pdf format: StudentID_FullName_Lab3_report.pdf
The assembly program for Part 1: vga.s
The assembly program for Part 2: ps2.s
The assembly program for Part 3: flags.s
A screenshot of your real-life flag and a screenshot of your imaginary flag: real-life-flag.png and imaginary-flag.png. Make sure to take screenshots that include the simulator UI, so we can verify that your pictures were created by the simulator.
Important
Note that we will check every submission (code and report) for possible plagiarism. All suspected cases will be reported to the faculty. Please make sure to familiarize yourself with the course policies regarding Academic Integrity and remember that all the labs are to be done individually.
The demo will take place via Zoom between 24 Nov – 30 Nov 2020 on the day of you assigned lab session day. We will provide a registra on system for the demo the week before. You will need to answer live ques ons during the demo with your screen shared to onstrate the working program.
/
