CS 150 CHECKPOINT 3 Video Interface Jeffery Tsai

CS 150 CHECKPOINT 3 Video Interface Jeffery Tsai Sammy Sy And pretty much everything else too….

The Project so far Controller Interface n Audio Interface n Video Interface n Game Engine n UART Memory Module Video Encoder FSM Controller Interpreter Controller Block Audio Module

Checkpoint 3 Overview UART n Serial Connection n Learn Sammy’s GUI n Memory Module (16 x 8 RAM) n Simplified Game Engine n Integration with previous checkpoints n

Overall State Machine Poll the controller like normal and update the game state. n Update the video 4 times each second. n start initialize idle process controller data video output process events (play sounds) update game state

Serial Cable Protocol Regular Serial Cable n Only need 2 pins since we only care about sending data to the computer. n • Pin 2 is to transmit (to the computer) P 5 – T 1 • Pin 5 is ground (on MAX 233) • Pin 3 is there, but NOT USED 1 2 3 out 6 7 GND 4 8 5 9

RS 232 Waveforms 8 bits of data, 1 start bit, 1 stop bit n Wire is normally high, and this time, you MUST keep it high. n Transmission rate = 57600 bps n start of tranmission start bit end of tranmission MSB LSB 17. 36 ms stop bit Time

57, 600 bps? !? ! You can’t get a 57. 6 k. Hz clock with a conventional clock divider. (16, 000/57, 600 278) n Use the 16 MHz clock, and pulse the output every 278 cycles. n By the way…. . remember to use BUFG’s for ALL your clocks! n

UART Universal Asynchronous Receiver Transmitter. n Since we don’t receive messages from the computer, only the transmitter is needed. n Need a READY signal since it is critical that you try to send at the maximum rate. n P 37 serial out UART Transmitter transmit data 8

Maxim Transceiver n n Actual serial connection is inverted and is 12 V. Maxim transceiver takes care of everything. BUT BE CAREFUL!!! DO NOT PLUG THE 12 VOLT END TO YOUR XILINX CHIP! P 37 n GND VCC GND

Video Interpreter mana[13: 0] score[13: 0] console 16 x 8 array of blocks[6: 0] This “Dream. Katz” program draws the game screen on the computer monitor. n <demonstration> n

Protocol (1) n Types of messages (all 1 byte wide) n SYNC • Game start (GS) • Game over (GO) • Game play (GP) n DATA • Data byte (D)

Protocol (2) n n n Only 3 legal sequences, all preceded by a SYNC byte. Each sequence can be followed by another valid sequence. n Display game start screen • GS n Display game over screen with final score • GO, D, D n Display a new frame (grids + mana + score) • GP, D 0, D 1, D 2, … D 127, D, D Reminder: n GS = game start n GO = game over n GP = game play n D = data byte

Protocol (3) n Physical representation in bits Game start = 1000 0001 n Game over = 1000 0000 n Game play = 1000 0010 n Data = 0 XXX XXXX n n note: n 0 <= Data <= 127 n 1 XXX XX 11 is always illegal

Protocol (4) n Display game start screen n n easy… just send GS byte Display game over screen and final score 1. 2. 3. GO: 1000 0000 D: 0, score[13: 7] D: 0, score[6: 0]

Protocol (5) n Display a frame 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. GP: 1000 0010 D 0: 0, block 0[6: 0] D 1: 0, block 1[6: 0] … DN: 0, block. N[6: 0] … D 127: 0, block 127[6: 0] D: 0, mana[13: 7] D: 0, mana[6: 0] D: 0, score[13: 7] D: 0, score[6: 0] block. N[6: 0] represents the type of image to display in the Nth block.

Protocol Example n Let’s display a frame with all white blocks (white=000 0001), mana=7, score=128 GP: D 0: D 1: … D 127: D: D: 1000 0010 0001 0000 0001 (game play) (block 0 = white) (block 1 = white) 0000 0000 (block 127 = white) (mana. Hi = 0000) (mana. Lo = 000 0111) (score. Hi = 0001) (score. Lo = 0000) 0001 0000 0111 0000

Killer checkpoint => Hints n n n The master FSM is complicated, but fortunately runs sequentially. Make sure you design it with Control and Datapath in mind. You might find pseudocode helpful for laying out the FSM’s and thus the control signals for the datapath. If pseudocode is good, datapath falls out naturally from it.

Pseudocode (1) Memory. Module Game. State; // 16 x 8 RAM /* Rotate all bits of Game. State to left/right once */ Handle. Left. Right(bool left, bool right) { 8 bit. Register tmp; for (I = 0; I < 16; I++) { tmp = Game. State[I]; tmp = Universal. Shift. Register(tmp, left, right); Game. State[I] = tmp; } } /* Move all bits of Game. State down once */ Handle. Down() { 8 bit. Register tmp; for (I = 15; I >= 1; I--) { // process backwards! tmp = Game. State[I-1]; Game. State[I] = tmp; } Game. State[0] = 0000; }

Pseudocode (2) /* encode Game. State into frame update message sequence */ Handle. Encode() { 8 bit. Shift. Register tmp; UART_Send(1000 0010); // sync game play byte for (I = 0; I < 16; I++) { tmp = Game. State[I]; for (J = 0; J < 8; J++) { UART_SEND(0000 000, tmp[0]); // either white or black tmp = tmp >> 1; } } UART_SEND(0, MANA[13: 7]); UART_SEND(0, MANA[6: 0]); UART_SEND(0, SCORE[13: 7]); UART_SEND(0, SCORE[6: 0]); }

Pseudocode (3) /* Main loop * ENCODE_LIMIT = period of video refresh * FALL_LIMIT = period of blocks falling */ Handle. Main(bool left, bool right) { count = 0; while (1) { Handle. Left. Right(left, right); // process left/right if (0 == (count % FALL_LIMIT)) { Handle. Down(); } // process gravity if (0 == (count % ENCODE_LIMIT)) { Handle. Encode(); } // process video count ++; } }

I don’t understand this pseudocode thing. . . Each subroutine is a mini-FSM that has idle and active states. n Calling a subroutine can be done by sending a start pulse. n When the subroutine returns, it outputs a done pulse. n start IDLE done ACTIVE

In Conclusion… Checkpoint 3 is really long. n BUT…don’t forget your midterm next week. n Good luck. Now Jeff and Sammy can go sleep… n