Infrared Instant Messenger Introductory Digital Systems Laboratory Final Project

Transcription

1 Infrared Instant Messenger Introductory Digital Systems Laboratory Final Project Abstract: The Infrared Instant Messenger system allows two users to communicate text messages to one another across a large room. Each user controls a communications module and uses a keyboard to input, monitor to display, and IR transmitter and receiver to communicate textual data to the partner s module that is located across the room. The user types text using a keyboard and transmits it in real-time using IR. The user sees two text display windows on a TV monitor, the lower window displaying text that he is typing and the upper window displaying text that he is receiving from his partner via IR. This dual-window text display system emulates popular computer instant messenger software such as AOL Instant Messenger and ICQ. The Infrared Instant Messenger system allows for real-time, two-way simultaneous data transmission so that both users can type text at the same time and receive messages from one another. The system is divided up into two subsystems. Ji Zhang worked on the Keyboard/IR Input/Output Subsystem and Philip Guo worked on the Video Subsystem. Philip and Ji worked together to design a data interface protocol to connect their two subsystems and to integrate and debug the entire system in order to make it fullyfuncti onal. The Infrared Instant Messenger system worked properly and successfully exhibited all functionality that we originally intended for it to perform. Philip Guo Ji Zhang T.A. Frank Honore Professor Don Troxel December 10 th, 2003

2 Table of Contents 1 Infrared Instant Messenger Overview 2 Keyboard & Infrared I/O Subsystem (Ji Zhang) Overview Keyboard Hardware Configuration Keyboard Serial Transmission Keyboard Scan-Code Translation Infrared Emitter Infrared Receiver Testing & Debugging Video Subsystem Overview (Philip Guo) Top-Level Functional Specifications External Circuitry Components Keyboard and IR Data Interpreters Video RAM Address Counters RAM Interface Video Controller FSM Testing & Debugging Video Subsystem Conclusion 56 4 Conclusion 57 5 Appendix VHDL Source Files 58

3 List of Figures and Tables Figure 1.1 Photograph of Infrared Instant Messenger Communications Module 1 Figure 1.2 Infrared Instant Messenger Top-Level Block Diagram 2 Figure 1.3 Two Communications Modules in the Lab 3 Figure The block diagram of the keyboard and IR system 5 Figure Common DIN connection routes for PS2 keyboards. 6 Figure Synchronous serial transmission of keyboard for one byte cycle. 6 Figure State transition of the keyboard scan-code capture shift register. 7 Table PS2 & ATX Scan Code Set 2. 8 Figure Simulation of keyboard capturer. 9 Table ASCII byte-code table for key strokes. 10 Figure State transition chart for keyboard scan-byte to ASCII translator. 11 Figure Simulation of the keyboard module. 12 Figure Logic analyzer output of keystroke sequence A-B-C-ENTER 12 Figure IR Emitter module; taken from the main block diagram. 13 Figure IR Send Controller s state transition diagram. 13 Figure Simulation of the Frequency Sender. 14 Figure Simulation of the IR Emitter unit. 15 Figure Radiant intensity of TSAL6100 versus emission angle. 15 Figure IR Receiver s block diagram 16 Figure Gain stage with tone decoder. 17 Figure Translation of 38KHz into digital 0s. 17 Figure I/O timing diagram of the TSOP3800 IR receiver. 18 Figure Block diagram and application diagram of Vishay s TSOP3800 IR receiver 18 Figure IR serial transmission signal lines. 19 Figure State transition diagram of the IR capturer. 19 Figure Simulation of the IR Capturer. 20 Figure The keyboard & IR subsystem. 22 Figure TSOP3800 s relative signal degradation 23 Figure The IR Messenger setup. 24 Figure Frequency versus signal degradation of TSOP Figure Simulation of the keyboard and IR subsystem. 25 Figure Photograph of monitor attached to the video subsystem 26 Figure Video Subsystem Top-Level Block Diagram 29 Figure Video Subsystem Lab Kit Physical Layout 30 Figure Video Subsystem Wiring Diagram 31 Figure Data Interpreter Block Diagram 33 Figure Data Interpreter Timing Diagram with Backspace and Enter 34 Figure Data Interpreter Timing Diagram with Regular Characters 35 Figure Description of Video RAM Address Counters 36 Figure Video RAM Address Counter Timing Diagram 37 Figure RAM Interface Block Diagram 38 Figure Reset Counter Timing Diagram 40 Figure Video Controller FSM Block Diagram 41 Table Video Controller FSM Inputs and Outputs 42 Figure Video Controller FSM State Transition Diagram 1 of 2 43 Figure Video Controller FSM State Transition Diagram 2 of 2 44 Figure Video Controller FSM executing Display New Character subroutine 49 Figure Video Controller FSM executing New Line and Backspace subroutines 50 Figure Video Controller FSM executing several IR subroutines 51 Figure Video Controller FSM executing Reset & Scroll Text subroutine 52

4 1 1. Infrared Instant Messenger System Overview Figure 1.1 Photograph of Infrared Instant Messenger Communications Module Inspired by the popularity of computer instant messenger software such as AOL Instant Messenger and ICQ, Philip Guo and Ji Zhang have developed a hardware-based instant messenger system that uses infrared signals to send text messages. Our system consists of two identical communications modules located across the room from one another, each containing a keyboard, monitor, two lab kits, and an infrared (IR) transmitter and receiver. Figure 1.1 shows a complete communications module in the lab. The monitor display is designed to emulate a typical dual-window instant messenger graphical user interface. The user types text messages with the keyboard and sees his input displayed in the lower text window just like he is using computer instant messenger software. At the same time, the system transmits the user s text message via IR to the second communications module that is located on the other side of the room. The user on the other end receives the text and displays it in the upper window of her monitor in real-time. Both users can type on the keyboard at the same time and send messages to one another without interference. This two-way real-time IR communication allows for truly simultaneous and uninterrupted instant messaging between two users. The system transmits and receives the text data through the IR transmitter and receiver with nearly 100% accuracy, and moreover supports the use of the Backspace key to erase characters in case of typos or other inadvertent errors.

5 2 Figure 1.2 Infrared Instant Messenger Top-Level Block Diagram Figure 1.2 shows the top-level block diagram for the Infrared Instant Messenger system. There are two identical communications modules, each controlled by two lab kits. Ji Zhang worked on the Keyboard/IR Input/Output Subsystem kit, which manages the signals from the IR transmitter, receiver, and keyboard. Philip Guo worked on the Video Subsystem kit, which takes ASCII input from Ji s kit and generates video output to display the dual-window instant messenger graphical user interface. Philip and Ji first worked on constructing, debugging, and integrating one pair of kits, and after making sure that these worked properly, they both constructed identical kits to form the second communications module since two complete modules are required to demonstrate instant messenger functionality. This project required a total of four lab kits, two

6 3 keyboards, two monitors, and two sets of IR transmitters and receivers. Ji and Philip developed a one-way, 18-bit interface that connected the two subsystems. Ji s kit sends two sets of 8-bit ASCII values to Philip s kit along with 2 data ready bits. Philip s kit interprets this ASCII text data and displays it to the monitor in the appropriate format. Figure 1.3 Two Communications Modules in the Lab Figure 1.3 shows the setup of the two communications modules in the lab. At this distance, we were able to achieve nearly 100% accuracy in data transmission even while both users typed at full speed (approximately 90 words per minute). When moving kits to a new location, care must be taken to point the IR transmitters and receivers directly at one another and make sure that nothing obstructs the transmission path. For our demonstration, Philip stood at one table while Ji stood at the opposite table. We both started typing as fast as we could, and our monitors showed the text that we were typing in the lower window as well as the text that the other person was typing and sending across the room via IR in the upper window. We consistently achieved almost 100% accuracy, with many more errors due to typing mistakes (typos) than actual infrared transmission errors. The system supports the use of the Backspace key to erase characters in case someone made typing or transmission errors. The system will be described in much greater detail in the sections that follow. Our system fulfills all of our original intentions and expectations in terms of functionality, reliability, and ease-of-use. Ji Zhang will begin this report by discussing his Keyboard/IR Input/Output Subsystem. Philip Guo will continue with his discussion of the Video Subsystem. We will conclude with an assessment of our project results and lessons that we have learned from this experience.

7 4 2. Keyboard & Infrared I/O Subsystem (Ji Zhang) 2.1 Overview The keyboard and IR interface was an independent system that occupied one FLEX10K FPGA per messenger send-and-receive station. Since both the keyboard components and the IR components dealt with similar serial transmission protocols, the two were combined into one large component. The system operated independently of the monitor-- except for IR signals from other IR Messenger stations, the keyboard and infrared unit received no other signals and only outputted keyboard character and IR character signals to the monitor. The purpose of the keyboard module was to record and send keystrokes to the IRtransmitter and the monitor. It needed to process serial data from a keyboard into an 8- bit ASCII literal at a rate that kept up with typing speed and was compatible with other systems. Two standard PS2 keyboards were used as the text-input devices for the Infrared Messenger. Most modern Windows keyboards share the same transmission protocol; hence, even though the two keyboards we used were of different brands, the serial data from the keyboards were of the same encryption. Figure 1.1 is the block diagram of the keyboard-infrared interface, dividing the system into its key components. The keyboards sent synchronous serial data, which was received, stored into a buffer, and processed by the KEY-CAPTURE component. The KEY-TRANSLATOR translated the keyboard serial data, which represented keystrokes, into its corresponding 8-bit ASCII value. The KEY-TRANSLATOR also notified the monitor and the IR emitter blocks of when a new key has actually been pressed. The infrared module was divided into an emitter and a receiver. The IR emitter received keystrokes and sends out a frequency-modulated signal. The IR receiver pieced this frequency-modulated asynchronous serial signal into ASCII bytes and sent the ASCII bytes to the monitor. Since the IR Messenger was designed to communicate at variable distances, variations in amplitude of the transmission signal must not interfere with transmission accuracy. The infrared module operated on frequency modulation in order to boost transmission distance. The receiver amplified the IR signal through gain stages, detected signal zero-crossings to translate the frequency modulated IR signal into digital values, and sent ASCII-valued keystrokes to the monitor.

8 Figure The block diagram of the keyboard and IR system: the keyboard module mainly consists of a serial data capture unit and a scan code to ASCII translator; the IR module consists of a signal emitter and a receiver. 5

9 6 2.2 Keyboard Hardware Configuration The PS2 keyboards transmitted synchronous serial data to the keyboard module via a keyboard clock line and a data line. The PS2 keyboards had more than four pins (see Figure 2.2.1), but only four of them were actually connected. Figure Common DIN connection routes for PS2 keyboards. Not shown in the Figure is the Earth-ground connection inside a PS2 connector. Earth-ground could have been connected to the keyboard module s ground to shield noise from the transmission. For some keyboards, it was necessary to connect either a pull-up or a pull-down resistor on the keyboard-clock and data lines. 2.3 Keyboard Serial Transmission The keyboards sent two signals to the keyboard capture module-- the keyboardgenerated clock and the actual data line. The data packet that the keyboard sent consisted of a start bit, eight scan bits, and one parity bit. Shown in Figure 2.3.1, during idle times, the keyboard data line and clock lines remained high. Figure Synchronous serial transmission of keyboard for one byte cycle.

10 7 The keyboard clock and data lines technically were bidirectional lines. Signals could have been transmitted to the keyboard to control keyboard settings such as key repeat rate and keyboard LED control, but for simplicity, the keyboard controller of the IR Messenger focused only on receiving keystroke data from the keyboard. The keyboard clock started to oscillate as soon as a key has been pressed. The keyboard s Make code is the byte or bytes representation of the key that has been pressed. For example, according to Table 2.3.1, when the letter A is being pressed, the keyboard serially sends out 0x1C on its data line. After the data line asserted the start bit, the scan code was sent out least-significant-bit first. The parity bit was received by the keyboard receiving system, but since there was no keyboard error in any of the tests and no keyboard scan correction system was implemented, the parity bit was essentially never used. The keyboard capture unit was essentially a loadable and registered shift register that triggered on low transitions of the keyboard clock (see Figure 2.3.2). Each data bit on different keyboards was asserted from 50us to 100us, and the negative edges of the keyboard clock ensured that the data bit was valid. The propagation delay and RAMwriting time of the FPGA was on the order of hundreds of nanoseconds at most, and did not prevent the system from accurately sampling each data bit from the keyboard. Figure State transition of the keyboard scan-code capture shift register. That the keyboard scan code capture unit recorded and latched keyboard serial data only at low edges of the keyboard clock prevented violations of the static discipline, but it offered no remedy for catastrophic instances in which a clock event is missed or a data bit skewed. In the case that the keyboard capture system somehow became misaligned (for example, if it were stuck in the Start Read state when it should have been in the Idle state), the keyboard capture system would never correctly capture data unless if it somehow became re-aligned. Since each state only transitioned on ticks of the keyboard clock, and since ticks of the keyboard clock only occurred on valid key presses, misalignment mistakes were unfixable.

11 8 KE MAK MAK BREAK KEY MAKE BREAK KEY Y E E BREAK A 1C F0,1C 9 46 F0,46 [ 54 FO,54 B 32 F0,32 0E F0,0E INSERT E0,70 E0,F0,70 C 21 F0,21-4E F0,4E HOME E0,6C E0,F0,6C D 23 F0,23 = 55 FO,55 PG UP E0,7D E0,F0,7D E 24 F0,24 5D F0,5D DELETE E0,71 E0,F0,71 F 2B F0,2B BKSP 66 F0,66 END E0,69 E0,F0,69 G 34 F0,34 SPACE 29 F0,29 PG DN E0,7A E0,F0,7A H 33 F0,33 TAB 0D F0,0D U ARROW E0,75 E0,F0,75 I 43 F0,43 CAPS 58 F0,58 L ARROW E0,6B E0,F0,6B J 3B F0,3B L SHFT 12 FO,12 D ARROW E0,72 E0,F0,72 K 42 F0,42 L CTRL 14 FO,14 R ARROW E0,74 E0,F0,74 L 4B F0,4B L GUI E0,1F E0,F0,1F NUM 77 F0,77 M 3A F0,3A L ALT 11 F0,11 KP / E0,4A E0,F0,4A N 31 F0,31 R SHFT 59 F0,59 KP * 7C F0,7C O 44 F0,44 R CTRL E0,14 E0,F0,14 KP - 7B F0,7B P 4D F0,4D R GUI E0,27 E0,F0,27 KP + 79 F0,79 Q 15 F0,15 R ALT E0,11 E0,F0,11 KP EN E0,5A E0,F0,5A R 2D F0,2D APPS E0,2F E0,F0,2F KP. 71 F0,71 S 1B F0,1B ENTER 5A F0,5A KP 0 70 F0,70 T 2C F0,2C ESC 76 F0,76 KP 1 69 F0,69 U 3C F0,3C F1 05 F0,05 KP 2 72 F0,72 V 2A F0,2A F2 06 F0,06 KP 3 7A F0,7A W 1D F0,1D F3 04 F0,04 KP 4 6B F0,6B X 22 F0,22 F4 0C F0,0C KP 5 73 F0,73 Y 35 F0,35 F5 03 F0,03 KP 6 74 F0,74 Z 1A F0,1A F6 0B F0,0B KP 7 6C F0,6C 0 45 F0,45 F7 83 F0,83 KP 8 75 F0, F0,16 F8 0A F0,0A KP 9 7D F0,7D 2 1E F0,1E F9 01 F0,01 ] 5B F0,5B 3 26 F0,26 F10 09 F0,09 ; 4C F0,4C 4 25 F0,25 F11 78 F0,78 52 F0,52 5 2E F0,2E F12 07 F0,07, 41 F0, F0,36 E0,F0, PRNT E0,12, 7C,E0, SCRN E0,7C F0, F0,49 7 3D F0,3D SCROLL 7E F0,7E / 4A F0,4A 8 3E F0,3E PAUSE E1,14,77, E1,F0,14, F0,77 -NONE- Table PS2 & ATX Scan Code Set 2.

12 The method to self-correct shift-register misalignment mistakes was to introduce a watchdog timer in each of the Read states. If each Read state lasted more than a few hundreds microseconds, then it can be certain that it the FSM should not have been in that Read state and the FSM would be automatically reset into the Idle state. At the end of a read cycle, after the scan-code capturer recorded the last scan-code byte that the keyboard sent, the capturer sends out an END BYTE pulse (see block diagram in Figure and Figure s NEW BYTE ) and also the complete scan-code byte to the scan-code translator unit via parallel data lines. This END BYTE led the translator to latch onto the scan-code byte and also started a translation cycle. After the translator has latched onto the scan-code byte, the capturer became free to initiate another scan cycle if another key has been pressed. 9 Figure The key capturer accumulated serial keyboard data and sent the completed byte to the translator. The duration of idle time between each cycle, of course, depended on the typing speed of the user. Since keys could only be typed so fast, and that the keyboard s internal key-detection system could only process keys so fast, it was safe to assume that the translator, which needed less than 10 microseconds for each translation, was able to finish translating before the capturer fed it another data byte. 2.4 Keyboard Scan-Code Translation The Make code on Table represented key presses and the Break code on Table represented key releases. For example, typing would generate scan code sequence 0x36F036, 0x49F049, 0x16F016, 0x16F016, 0x16F016. The keyboard s internal settings allowed a continuous key press to generate alternating Make and Break codes, effectively indicating that the key has been repeatedly pressed.

13 The keyboard scan-code was raw data that was undesirable to manipulate and pass between components of the IR Messenger system since keys Make codes were of variable byte-length and since bytes were not unique to unique keys. Instead, each keystroke was converted to its ASCII value. The keyboard translator unit was responsible for outputting the corresponding ASCII code whenever a key had been pressed and also for appropriately handling key-releases. 10 Char Dec Oct Hex Char Dec Oct Hex Char Dec Oct Hex Char Dec Oct Hex (nul) x00 (sp) x40 ` x60 (soh) x01! x21 A x41 a x61 (stx) x02 " x22 B x42 b x62 (etx) x03 # x23 C x43 c x63 (eot) x04 $ x24 D x44 d x64 (enq) x05 % x25 E x45 e x65 (ack) x06 & x26 F x46 f x66 (bel) x07 ' x27 G x47 g x67 (bs) x08 ( x28 H x48 h x68 (ht) x09 ) x29 I x49 i x69 (nl) x0a * x2a J x4a j x6a (vt) x0b x2b K x4b k x6b (np) x0c, x2c L x4c l x6c (cr) x0d x2d M x4d m x6d (so) x0e x2e N x4e n x6e (si) x0f / x2f O x4f o x6f (dle) x x30 P x50 p x70 (dc1) x x31 Q x51 q x71 (dc2) x x32 R x52 r x72 (dc3) x x33 S x53 s x73 (dc4) x x34 T x54 t x74 (nak) x x35 U x55 u x75 (syn) x x36 V x56 v x76 (etb) x x37 W x57 w x77 (can) x x38 X x58 x x78 (em) x x39 Y x59 y x79 (sub) x1a : x3a Z x5a z x7a (esc) x1b ; x3b [ x5b { x7b (fs) x1c < x3c \ x5c x7c (gs) x1d = x3d ] x5d } x7d (rs) x1e > x3e ^ x5e ~ x7e (us) x1f? x3f _ x5f (del) x7f ASCII Name Description C Escape Sequence nul Null byte \0 bel Bell character \a bs backspace \b ht horizontal tab \t np Formfeed \f nl newline \n cr Carriage return \r vt Vertical tab esc escape sp space Table ASCII byte-code table for key strokes. Source: michael/c/ascii-table.html.

14 The Break code system allowed simultaneous keystrokes since the system that received the keyboard would be able to keep track of when keys were actually pressed and released. The IR Messenger system, however, did not need to track key releases. Since a lower-case font package had not been written for the monitor, and since there were no application-specific key combinations (for example, Ctrl+Alt+Del), there was no reason to keep track of key releases. The translator s role, then, was to filter out Break codes and only acknowledge Make codes. The Key ROMs were pre-instantiated memories whose cell addresses corresponded with Scan-code bytes and whose stored values corresponded with the ASCII translation for the Scan-code. Key ROM1 directly translated a keystroke s first scan-byte, and the subsequent ROMs translated additional scan-bytes of a keystroke if needed. As indicated on the scan-code table, only certain punctuation marks and special characters had scancodes longer than one byte. Only if the first Key ROM s output and input were a F0 or E0 would the translator proceed to use the next scan-byte that it receives in the next Key Rom (see Figure 2.4.1). The ROMs outputted a F0 or E0 whenever it received those values, indicating that further lookup is required. Since all multiple byte scan-codes begin with F0 or E0, those values were the scan-bytes that triggered the translator to read multiple levels of ROM. 11 Figure State transition chart for keyboard scan-byte to ASCII translator. While the first ROM gave direct ASCII conversions for one-byte scan-code keystrokes, the second ROM and third ROM only gave ASCII values for two-byte and three-byte Make codes and outputted 0 otherwise. Consequently, the second and third ROMs outputted 0 s for Break codes. Upon completion of a valid translation, the translator sent a NEW KEY DATA pulse and the translated 8-bit wide ASCII to the IR system and the monitor. If the translated ASCII code were a 0, indicating that the scancode was a Break code, then the NEW KEY DATA would not be asserted. This way, the translator successfully sifted out all Break codes and translated all Make codes into corresponding ASCII values. Figure gives a simulation of a single keystroke. At roughly 1.0us, a user pushed a key on the keyboard. Following the user action, between 1.0us and 6.5us, the keyboard sent its synchronous serial data via the KEY DATA and KEY CLK lines. At the end of the keyboard s transmission cycle and the keyboard raw data capturer has completed its capture shift cycle, the keyboard s serial data was sent to the translator. The translator uses the data that it just received to browse lookup ROMs and outputs the ASCII (0x43) value that corresponded with the keystroke. At roughly 6us,

15 KMOUT STATE indicated that the translator FSM was transitioning between states and that the entire translation process was significantly faster than a keyboard capturer cycle. At roughly 6.5us, the translator finished its translation cycle and outputted a NEW KEY pulse, indicating that the ASCII data was ready to be used. 12 Figure Simulation of the keyboard module. A scan-code of 0x21 from Figure was translated into an ASCII value of 0x43. Figure is the actual keyboard module output for the keystroke sequence A-B- C-ENTER. Each ASCII value was asserted for roughly a hundred milliseconds and then the ASCII data line is reset to 0. It was the monitor and the IR module s job to be able to capture the ASCII data when the NEW KEY signal is pressed. The logic analyzer could not display the NEW KEY signal since its duration was only a few hundreds nanoseconds. Even at extremely fast typing speeds, the translator would still be fast enough since the data transmission is limited by keyboard s serial output. Figure Logic analyzer output of keystroke sequence A-B-C-ENTER, which corresponds with ASCII hexadecimal values of D.

16 Infrared Emitter The IR Emitter transmits keyboard ASCII values serially to IR receiver modules. After each keystroke, the Emitter latches onto the keyboard s ASCII value when the new key signal is asserted and then sends out the data. The Emitter module has a Frequency Sender unit that always oscillates at 38KHz, which is the frequency that the receiver unit will translate into a digital 0 (see Figure 2.5.1). Figure IR Emitter module; taken from the main block diagram. The Frequency Sender is essentially always oscillating, and the IR Send Controller acts like a MUX that selects whether the Frequency Sender outputs a 38KHz signal or outputs a pure low signal. We can compare the IR Sender Controller to a gate-- it either was closed and forced a digital 0 out or was open and let out a high frequency signal. Illustrated in Figure 2.5.2, after a key has been pressed, the IR Send Controller first sent a high start bit and then sent the ASCII value of the keystroke with least significant bit first. Note that a low IR send-bit corresponded to a digital low, and a high IR send-bit corresponded with a 38KHz oscillation output. Figure IR Send Controller s state transition diagram. The Sender Controller s timing was crucial in that it complemented the timing of the IR receiver unit. Since we wanted an oscillation frequency of 38KHz and a Sender

17 FSM that operated on a very fast clock so that the Key Detection State can be quickly reached, the Sender FSM operated on a MHz clock and a 4KHz countdown timer. The Frequency Sender unit also operated on a MHz clock so that it can switch between on and off very quickly. The oscillating signal that the Frequency Sender outputted was literally a signal that was switched high and low at twice the oscillation frequency (see Figure 2.5.3). 14 Figure Simulation of the Frequency Sender. The output became a 38KHz oscillation when the system was turned on. In the next section detailed timing requirements of the IR receiver is given, but for now let us just take for granted that the fastest IR transmission rate is 4Kbits per second. A point to note here is that there was also a minimum IR transmission rate limit due to constraints timing requirements of the receiver. As will be explained later, the receiver needed at least 6 oscillation periods before it could reliably translate that to a digital 0. In addition, the receiver could not receive more than 72 continuous oscillation periods. If the Sender s transmission rate were too slow, then each high serial bit would take more than 72 continuous oscillation cycles and actually cause the receiver to switch output at the end of the 72 cycles. A design shortcut was used in the IR serial transmission. Technically, in order to accommodate the maximum 72 oscillation cycle requirement of the IR receiver, a serial oscillation bit should either be preceded or followed by a period of non-oscillation. In this case, the receiving end of the IR system would have to sample the data in a phase-locked loop and never sample the streaming IR data at rest periods of the receiver. Looking at the ASCII data that we the IR Messenger must transmit, however, notice that the maximum number of consecutive digital high bits that must be transmitted is eight. If the start bit were a high, and if a DEL key (ASCII value of 0x7F transmitted LSB first), then the IR Sender would need to transmit 8 consecutive digital highs. The Sender was designed such that at roughly 4KHz, each high serial bit used roughly 7 to 8 oscillation cycles. This way, the most number of continuous oscillation cycles that the IR system

18 would ever send was 64, and each serial oscillation cycle would definitely be detected by the receiver (see Figure 2.5.4). The End Bit was intentionally chosen to be a digital low, which corresponded to a period of no oscillation, to ensure that there was a period of nonoscillation between consecutive serial transmission bytes. 15 Figure Simulation of the IR Emitter unit. At t=0, the system received instruction that it needs to send 0x11. At 200us, the start bit (high frequency) is sent out. Afterwards, the LSB (1) is sent, followed by three 0s, another 1, and three mre 0s. At 2ms, the low frequency end bit is sent. At 2.5ms, the system has completed sending the ASCII byte 0x11. Another point to watch is the hardware configuration of the IR-LED used for IR transmission. Vishay s TSAL6100 high-efficiency 950nm IR-LED was chosen for the IR Messenger to be able to transmit over longer distances. The narrow emission angle (see Figure 2.5.5) allowed the emitting LED of one kit to be angled away from its own receiver module such that each IR Messenger station did not receive its own IR output. The TSAL6100 boasted a radiant intensity of over 130mW/sR, more than the most powerful Fairchild IR LED QED123 and any other IR LED that was found on the market. Signals from the TSAL6100 were able to be received at a distance of almost 30 meters. Figure Radiant intensity of TSAL6100 versus emission angle. Source: Online datasheet from Vishay.

19 16 Of course the TSAL6100 IR-LED could not handle a 5V power source. The resistor in series with it (see Figure 2.5.1) regulated the amount of power that flowed through the LED. The IR-LED technically was able to operate safely with a series resistor down to 10 Ohms, but there was no need to overpower the IR Emitter since we only needed to accurately transmit over a few meters. In the end a 160 Ohm series resistor was chosen such that the IR Messenger transmitted over 3 meters with 100% accuracy. 2.6 Infrared Receiver The IR receiver was comprised mainly of a tone decoder and a serial transmission capture unit (see Figure 2.6.1). The IR receiver was different from the keyboard serialcapturer because there was no sender-generated clock pulse; the capturer had to find the best times to capture serial data and remain in a phase-locked cycle. Theoretically, the IR capture unit should capture at the same transmission rate that the IR Emitter was sending data. Through many experiments, however, it seemed that slightly faster IR capture rate sometimes improved capture accuracy. This occurred because it was difficult to determine the best time within each serial-bit to capture that serial-bit due to serialtransmission inaccuracies. A slight skew between the IR Emitter clock and the receiver clock sometimes forced the receiver s sampling clock to line up with better spots to sample. A variety of culprits, ranging from manufacturing inaccuracies of the tone decoder to degradation of the IR signal, cause the length of each serial-pulse to slightly fluctuate. Figure IR Receiver s block diagram-- taken from the main IR Messenger block diagram.

20 Even though the IR Emitter used an extremely powerful IR-LED, the amplitude of the IR signal significantly degraded over a few meters. The decoder stage included a gain stage that amplified peaks of the IR signal (see Figure 2.6.2) and a tone decoder that used the IR signal s zero-crossings to recognize oscillation. 17 Figure Gain stage with tone decoder. With the help of a pull-up resistor, the decoder translated 38KHz oscillations into a digital low and static signals into digital highs. Originally we planned to use a LM567 tone decoder along with two LP353 low-bias current Opamps, an AC-coupling capacitor, and a 950nm phototransistor as the gain stage. Fortunately, much easier and much more reliable to use was the TSOP3800 IR receiver module. Although Vishay s TSOP3800 was slightly more expensive than assembling an IR receiver and had various usage constraints, it was ultimately used as the final IR receiver module. Figure The tone decoder translated 38KHz oscillations into a digital 0 and a static pulse into digital 1s.

21 The TSOP3800 receiver had propagation delay of over a few hundred microseconds (see figure 2.6.4) between its detecting the first zero-crossing of an oscillation and changing its output, but since the IR serial transmission was asynchronous, this propagation delay was of no consequence (see Figure 2.6.5). The TSOP3800 also was designed to filter out noise vibrating at 38KHz; if a signal continued to oscillate at 38KHz for more than 72 cycles, then the TSOP3800 would begin to ignore that signal until it received a static pulse of at least 72 cycles. 18 Figure I/O timing diagram of the TSOP3800 IR receiver. Figure Block diagram and application diagram of Vishay s TSOP3800 IR receiver taken from Vishay s online datasheet. As mentioned in the last section, the IR Emitter was designed not to breach the 72 continuous oscillation cycle maximum. The TSOP3800 also required a general rest cycle that lasts as long as the oscillation cycle preceding it; hence, the static End Bit of the IR Emitter ensured that TSOP3800s timing requirements were never violated. The many filters of the TSOP3800 were designed to filter out most common sources of light noise, including sunlight and fluorescent light bulbs flickering. Large stabilization capacitors were essential around the power supplies of the TSOP3800 in order to prevent voltage spikes. Figure illustrates the IR sampling timing diagram.

22 19 Figure IR serial transmission signal lines. The IR serial capturer ideally sampled each serial transmission bit right in the middle of its period. Ideally, transmission packets could last infinitely long as long as there were no errors and no error-detection system. Unfortunately, not only were there transmission errors, the emitted IR bit pulses also varied in length. This meant that it was absolutely necessary to sample IR data in the best estimate for the middle of the pulse since sampling anywhere close to an edge will eventually result in sampling the wrong data as the length of bits fluctuate. Figure State transition diagram of the IR capturer. Figure illustrates the IR capturer s state transition diagram. Like the IR sender, the capturer operated on a fast MHz clock in order to quickly detect the Start Bit and quickly transition from the Idle state to Capture states. The first state of the Capture cycle was a half transmission cycle delay state that aligned the sampling clock in the middle of the first IR serial bit-- the Start Bit. This delay amount was changed around during testing phases in order to find the optimum place to sample. The final delay time turned out to be slightly less than half a 4KHz transmission cycle in order to account for the delay between IR transmission start and Start Bit detection. At the end of the delay state and each capture state, a 4KHz timer was reset (see Figure 2.6.8). In each subsequent capture state, the next more significant bit of the ASCII transmission was concatenated into IR RECEIVED buffer. By the time all 8 bits of the ASCII byte and the End Bit were stored, the IR CAPTURE FSM sent out a 1- period NEW BYTE signal at the last state transition.

23 20 Figure Simulation of the IR Capturer. 2.7 Testing & Debugging The problem keyboard and IR modules were designed to be an independent system-- that is, a monitor did not have to be connected to the keyboard and the IR receiver to test the functionality of the keyboard and IR components. Since the keyboard capturer was a loadable shift-register that operated on ticks of the keyboard-generated clock, simulations of keyboard signals should be very close in functionality to actual signals. It did not matter what the transmission rate of input signals in simulation were as long as the input signals were orders of magnitude slower than the fast MHz clock. A small problem with obtaining compatible keyboards was that all keyboards had different and misleading color-coded connector wires. For example, the Toshiba keyboard that was used had a yellow line for clock, red line for data, black line for ground, and brown line for power. The generic Dell keyboard that was used for the second IR Messenger station used a red line for clock, brown line for data, black line for ground, and gray line for power. After a keyboard had been stripped open, we had to connect each line to power, ground, and look at outputs of the other lines on the logic analyzer. Unfortunately, this probably could have burned out a few of the older keyboards that we first tried to use. To make matters worse, some of the keyboards had output lines that required either pull-up or pull-down resistors. We had no idea what pull-up or pull-down resistor values were needed, only that an unnecessary pull-up or pull-down would shut down a valid output line and an undersupplied pull-up or pull-down would also shut down a valid output line. Given the trial and error testing of pull-down and pull-ups, and the guessing of which color-coded line connected to what for every keyboard, connecting and soldering the first few keyboards cost an entire day.

24 Another problem that cost us an entire day was the use of incompatible keyboards. Dell Quietkey and other generic brand keyboards that were first used did not share the modern ATX2/PS2 protocol. Unfortunately, the other protocols that those keyboards outputted were very similar to ATX2. When the outputs of incompatible keyboards were recorded, they looked almost identical to the PS2 protocol for most keystrokes. A lesson learned here was to always use relatively new keyboards with 6-pin DIN PS2 connectors. Since the keyboard serial transmission rate was relatively slow, its output signals could be seen with LEDs. When figuring out which pins were the clock, data, power, and ground lines, we plugged LEDs into the lines. When the LEDs flashed after a keystroke, it indicated that the line with the LED was probably the clock or power signal. Of course, since some keyboard lines asserted varied output voltage ranges, connecting an LED in reverse (positive end of LED to power, negative end to keyboard output) sometimes allowed for more visible output line flashing after a keystroke. The problem with testing the keyboard with LEDs was that sometimes connecting power to the data line would supply enough power to the keyboard such that the clock line would be responsive to keystroke presses, adding to the confusion. Since after each keystroke, the keyboard module sent out an 8-bit ASCII value corresponding to the keystroke, LEDs were plugged into the keyboard ASCII output lines (see Figure 2.7.1). After each keystroke, its ASCII output would flash briefly on the keyboard LEDs. If a key is held down, however, the keyboards automatically assumed that the key has been struck repeatedly. As long as the keystroke repeat-rate was fast enough, the keystroke LEDs corresponding each key always seemed to stay on to the naked eye. For example, when A was held down, the corresponding hexadecimal ASCII value (0x41) would be continuously displayed on the 8 LEDs connected on the outputs of the keyboard ASCII. Of course displaying the keyboard ASCII output with a LED array was a fast but a crude way of gauging output. When the keyboard module was first connected to the monitor, it turned out that many key strokes would either repeat or sometimes not trigger. The LED display gave the impression that the keyboard module was working perfectly, but in actuality it was unable to catch minor flaws in the keyboard module. Many of the keyboard problems turned out to be caused by broken pins on the lab kits. On one of the lab kits, pin L3-8 was somehow disconnected. On the other lab kit, a bunch of pins on the AD bus were disconnected. In order to detect the broken pins, we loaded a short program that outputted a clock signal into every single FPGA pin and identified the pins to avoid. In the end, every single lab kit of the IR Messenger had slightly different pin assignments. 21

25 22 Figure The keyboard & IR subsystem. It was important that none of the connection wires were dragged out to be too long since that could have resulted in significant propagation delay as well as glitches. As mentioned earlier, the keyboard capture system had no real way of catching a serialtransmission misalignment error except to wait until its watchdog timer expired. This meant that the keyboard signal must be as clean as possible, and that glitches could easily misalign the transmission. A large 47uF capacitor was connected between the power and ground rails of the keyboard to filter out noise. Of course, the system clock must be glitch-free. Without a 33pF capacitor at its output, the system clock outputted a positive glitch almost every five oscillation cycles despite that the wire connect itself to the FPGA s clock input was only two inches long. The IR send and receive lines, like the keyboard, was also kept glitch free with large capacitors. Since glitches in IR transmission could easily trigger the TSOP3800, it was best that both the aired IR signal as well as the received IR signal remained as glitch-free as possible. In fact, in a worst-case test, when a PIC microcontroller was used to generate one-cycle oscillating IR signals, that IR signal sporadically triggered an active response in the TSOP3800.

26 Like the keyboard module, the IR module was also connected to an array of 8 LEDs (see Figure 2.7.1). Again, when the IR receiver finished catching a serial byte, the ASCII value that it received was latched and displayed on the LEDs. This way, we were able to connect the keyboard to the IR and crudely test the IR transmission. Figuring out the optimal IR output strength was a challenge since the IR system exhibited different behaviors when transmitting in different environments. Illustrated in Figure 2.7.2, the TSOP3800 receiver was able to receive at decent strength at almost 80 degrees along both the horizontal and the vertical axes. At first this seemed like an unexpected bonus, but the strong sensitivity of the TSOP3800 became a problem when one IR Messenger station transmitted and received its own transmission. Each IR Messenger was meant to only receive signals from other IR Messenger stations. 23 Figure TSOP3800 s relative signal degradation for horizontal spread (left) and vertical spread (right). Testing showed that the emitted IR signal was so strong and that the TSOP3800 was so sensitive that we were able to reflect the IR signal off windows that were roughly 3 meters away and accurately receive the signal that was emitted. Placing one station s IR- LED behind the station s TSOP3800 did not prevent self-transmission due to uncontrollable signal deflection. In the end, the IR-LED and TSOP3800 of each IR Messenger station were placed roughly a foot apart horizontally. When two IR Messengers faced each other, the symmetry of the IR-LED and TSOP3800 allowed the IR-LED of one IR Messenger to directly face the TSOP3800 of the other. An insulating black electrical tape cover was placed around the TSOP3800s so that the TSOP3800 did not pick up signals from the IR- LED that was positioned a foot away from it. The TSAL6100 IR-LED did not need a roll of electrical tape to narrow the emission beam since the TSAL6100 emitted signals at less than 10 degrees from center. Nevertheless, if a person stood in front of the IR emitter and forced the IR signal to deflect off his or her body, the IR receiver would pick up the signal from the IR emitter. It was essential that no object obstructed the IR transmission path (see Figure 2.7.3)

27 24 Figure The IR Messenger setup. There was a variety of noises that fortunately did not interfere with the transmission. The TSOP3800 also captured electromagnetic wave frequencies far from 950nm, the TSAL6100 s emission frequency (see Figure 2.7.4). During testing, it was found that IR emissions from external sources could have triggered wrong data in the receiver module. Even a weak 880nm IR-LED in place of the high-powered TSAL6100 IR-LED worked in accurately transmitting data. This further emphasized the need for insulating the TSOP3800 such that it could only receive a beam of IR data that was pointed directly at it. As shown in Figure 2.7.3, flickering of the fluorescent lights, light reflection off the ground, walls, and ceilings, and incoming sunlight all triggered the IR receiver when the TSOP3800 was not properly covered. The effect of light noise was not always apparent by looking at the LEDs that were connected to the IR receiver. When the monitor was plugged into the IR receiver, any noise that had a significant impact on the system was immediately shown as an undesired character on the screen. For example, one short delta of noise would have triggered the IR receiver to start receiving a series of 0s and then sending the character corresponding to an ASCII 0x00 to the monitor. This would not have shown up on the LED array.

28 25 Figure Frequency versus signal degradation of TSOP3800. In the end the series resistor for the TSAL6100 was changed to a 160 Ohm resistor in order to limit the power of the IR-LED. Lower resistance caused the IR signal to be so strong that the IR receiver captured self-transmission signals that bounced off walls over 10 meters away. Except for the keyboard s output timing, the keyboard and IR subsystem behaved exactly as the simulation did in Figure Figure Simulation of the keyboard and IR subsystem. At t=0 a keyboard transmission triggered the keyboard module such that 0x4D was outputted shortly afterwards. When KB NEW ASCII was asserted high, the IR sender was triggered to send a frequency-modulated serial signal. IR SERIAL DATA was set to low for high frequencies. At 1.7ms, the IR receiver received the keyboard s keyboard s ASCII output.

29 Video Subsystem Overview (Philip Guo) Figure Photograph of monitor attached to the video subsystem Philip Guo designed and implemented the video subsystem and wrote Section 3 of this document. The video subsystem of the Infrared Instant Messenger system is responsible for displaying text on a TV monitor. Figure shows a TV monitor attached to the video subsystem. The graphical user interface that the video subsystem provides attempts to emulate traditional instant messenger software (such as AOL Instant Messenger and ICQ). It consists of two text windows, one above the other, separated by grayscale borders. The lower window, which contains a blinking cursor, displays text that the user types in via the keyboard. The upper window displays text that the system receives from the other user via IR. The video subsystem supports simultaneous, realtime display of both keyboard and IR data so that two users can type and receive messages from one another concurrently. This emulates the real-time ICQ chat system rather than the AOL Instant Messenger system where users must press Enter to send an entire buffer of text at a time. Like a traditional software text editor, the video subsystem accurately handles text wrapping at the end of lines, deletes characters when the user presses the Backspace key, jumps to a new line when the user presses the Enter key, and scrolls the text upwards by two lines when the user fills up an entire text buffer. The video subsystem consists of several main components on the lab kit that are all connected to a common Mhz clock: The Video Controller FSM, data interpreters, address counters, RAM interface, MC6847 video display generator, and external output circuitry. I will begin by discussing the top-level functional specifications of the system, then describe each component in detail, and conclude with testing and debugging information as well as lessons that I have learned from working on this final project.

30 Top-Level Functional Specifications My partner Ji and I purposely designed our two subsystems so that they could be constructed, tested, and run as independently as possible. When we started designing our project, we decided that having a narrow and clearly-defined interface between our two kits would greatly improve modularity and ease of debugging. Thus, we came up with an 18-bit one-way data bus that feeds data from Ji s kit into my kit. Since my kit acts as a video display controller, it does not need to feed any data back into Ji s kit. My video subsystem connects to Ji s input/output subsystem through a 50-pin ribbon cable that connects our lab kits together. We utilize 18 pins to perform one-way parallel data transfer from Ji s kit to my kit. 8 bits are used for ASCII data from the keyboard, 8 bits for ASCII data from the IR, 1 bit for keyboard data ready, and 1 bit for IR data ready. The top-level specifications for the video subsystem are fairly straightforward. When the user asserts a pulse on the keyboard data ready bit, the video subsystem reads in the 8 bits of ASCII data from the keyboard and performs the appropriate action such as displaying a new character on the screen in the appropriate place, deleting a character if the Backspace key is pressed, or jumping to a new line if the Enter key is pressed. All keyboard inputs affect the lower text window. The same thing happens when the user asserts a pulse on the IR data ready bit, except that ASCII data from the IR is read and the upper text window is affected. The length of the keyboard or IR data ready pulse must be a minimum of one clock period (1 / Mhz = ns) but can be asserted for an arbitrary length of time since they are fed through level to pulse components before reaching the data interpreters. The level to pulse converts a pulse of arbitrary length into a pulse that lasts for exactly one clock period. We have decided not to support the shift key in our system. As a consequence, all characters are displayed in one case (uppercase). Although the system supports a limited subset of the standard 8-bit ASCII code, it supports enough characters to allow users to communicate effectively. All 26 letters and 10 numerical digits are supported. The all-essential Spacebar, Enter, and Backspace keys are also available. All punctuation keys that do not require a shift key press to access are also available. These include the single quote ( ), backquote ( ), brackets( [ ] ), slashes ( / \ ), semicolon ( ; ), dash ( - ), equal sign ( = ), comma (, ), and period (. ). These are most of the keys that are used during standard instant messenger conversations.

31 Due to the modularity of our project design, the video subsystem does not have to be attached to Ji s kit in order to function. It functions as a dual-window text editor that supports text wrapping, new lines, backspaces, and scrolling when the text buffer overflows. All a user needs to do to interface with the video subsystem is to attach 18 bits of data to the appropriate pins on my kit and transmit data according to the following protocol: If the user wants to display something on the upper text window, he must provide 8 bits of valid ASCII data on the IR ASCII data lines and assert the IR data ready signal for at least one clock cycle (279.4 ns). If the user wants to display something on the lower text window, he must do the same thing except with the respective keyboard data lines. At the most fundamental level of abstraction, the video subsystem receives signals from 18 data lines and displays the appropriate text or formatting on a monitor. Figure shows the top-level block diagram of the entire video subsystem. 28

32

33 External Circuitry Components As shown in Figure 3.2.1, the majority of the logic for the video subsystem is implemented within an Altera 10K10 FPGA. The external circuitry components that form the link between the FPGA logic and the display monitor include the MC6847 Video Display Generator chip, Mhz clock circuit, vertical sync generator circuit, and analog video output generator circuit. The monitor connects to the video subsystem through an 8-pin monitor interface cable. These components are shown in the photograph of my lab kit in Figure 3.3.1: Figure Video Subsystem Lab Kit Physical Layout The analog output circuitry was constructed by directly following the schematic on the handout entitled Using the MC6847 Video Controller that I found in the lab. The purpose of the analog output circuitry is to convert the output data from the MC6847 VDG chip into a format that is compatible with the monitors in the lab. I have made slight adjustments to various resistor and capacitor values, but the design was copied almost directly from the schematic. Figure on the next page shows the wiring diagram that corresponds to the lab kit shown in Figure I will briefly describe each of these external components in the following few pages.

34 31 Figure Video Subsystem Wiring Diagram MC6847 Video Display Generator Chip The Motorola MC6847 generates NTSC video signals by reading data out of a Video RAM. It provides the crucial link between the digital logic and analog video output. It provides address and data bits into the Video RAM within the FPGA as well as various status bits for the Video Controller FSM. The field sync (nfs) signal feeds into the FPGA and tells it when the MC6847 is done drawing the entire screen and the CRT tube is in the process of repositioning itself. When nfs goes low, the system is free to update the Video RAM without causing the screen to flicker since the CRT tube is repositioning instead of drawing. The FPGA can assert the memory select (nms) signal low in order to tell the MC6847 that it is trying to access the Video RAM. In the current configuration, the MC6847 provides 9 address bits (for a total of 512 addresses) and expects 8 bits of data from the FPGA at each address. Depending on the operation mode, the MC6847 then renders either a character (text mode) or a chunk of graphics

35 (semigraphic-4 mode) based on the 8-bit data. This chip takes care of generating sync signals and asserting the analog voltages to display text and graphics on an NTSCcompatible monitor. 32 The two most significant bits of the data from the Video RAM are connected to certain select pins in the MC6847. This allows for custom rendering on a character-bycharacter basis based on the contents of those bits. Notice that pins 34 and 40 are connected. This means that the MSB of the data (Data[7]) is connected to the text/semigraphic (na/s) select bit. If a certain piece of data contains a 1 in the MSB, then the MC6847 renders that data in semigraphic-4 mode. This is used to draw the borders. If a certain piece of data contains a 0 in the MSB, then the MC6847 renders that data in text mode. This is used to render the text in the windows. Similarly, pins 2 and 32 are connected. This means that the second MSB of the data (Data[6]) is connected to the invert (INV) select bit. If a certain piece of data contains a 1 in the second MSB, then that is rendered with inverse brightness. This is how the blinking cursor can be rendered as an alternately dark and light spot. This will be further described in a later section. Clock Circuit The MC6847 requires a precise Mhz clock in order to properly function. A clock is built using a Mhz crystal oscillator coupled with a few resistors and inverters. This circuit provides the clock for both the MC6847 and all components within the FPGA. The entire video subsystem is synchronized to this common clock. Vertical Sync Generator Circuit The MC6847 does not directly provide a vertical sync output. Rather, it provides a field sync (nfs) output that must be converted into a vertical sync using the circuit shown in Figure The two 100K potentiometers in this circuit can be tweaked in order to obtain a properly-synced image. If the image flickers or appears to constantly be scrolling up and down, then tweaking the values of these two potentiometers should fix the problem. Analog Video Output Generator Circuit This circuit takes the Y output of the MC6847 and converts it into an analog output voltage that is fed into the monitor. The 5K potentiometer can be tweaked to adjust the brightness of the image on the screen. 8-pin Monitor Interface Cable The monitors in the lab are equipped with an 8-pin monitor interface cable. This system operates in monochrome, so the analog video output voltage should be connected to the Red, Green, and Blue inputs in order to generate a monochrome image. The horizontal sync signal comes directly from the MC6847 while the vertical sync signal comes from the vertical sync generator circuit. Notice that the pin 1 is not connected and that pins 5 and 6 are grounded.

36 Keyboard and IR Data Interpreters Figure Data Interpreter Block Diagram The keyboard and IR data interpreter components form the interface between the video subsystem and Ji s input/output subsystem. The two data interpreters are identical components that are implemented in DataInterpreter.vhd. In the top-level VHDL file, VideoTopLevel.vhd, the keyboard and IR data interpreters are two instances of the same DataInterpreter component. The only difference between the two is what gets connected to the ports. The Keyboard Data Interpreter receives its inputs from the 9 keyboard bits of the data bus and the IR Data Interpreter receives its inputs from the 9 IR bits of the data bus. The purpose of the data interpreters is to translate the 8 bits of ASCII input (ASCII In[7:0]) into 6 bits of video data output (Video Data Out[5:0]) that the MC6847 can understand. The keyboard and IR data ready inputs are first fed through level to pulse components which make sure that the signal is only asserted for exactly one clock cycle. The output data from the keyboard and IR data interpreters are sent to the KB/IR data multiplexer where they wait for a selector signal to allow one of them through into the Video RAM. As soon as the system receives an Incoming signal, it latches the ASCII In[7:0] data, translates it into MC6847-compatible data in Video Data Out[5:0] and asserts DataReady to tell the Video Controller FSM that the data is translated and ready to be stored into the Video RAM. The DataReady signal remains high until the Video Controller FSM resets it back to low by asserting the LatchReset signal to tell the data interpreter that it is done using the current data.

37 34 How does the data get translated from 8-bit ASCII to 6-bit MC6847-compatible data? Page 20 of the MC6847 data sheet shows that in text mode, the MC6847 uses the 6 least significant bits of the 8-bit data it receives to render one character. This allows the MC6847 to render 2ˆ6 = 64 different characters. After a bit of observation, I found that the MC6847 character codes are arranged in almost the same order as standard ASCII codes. The data translator only needs to make a few slight adjustments in order to translate ASCII into MC6847-format character codes. Thus, no complex lookup tables or ROMs are required. That is why the data interpreter can work so quickly. Here is how the incoming ASCII data is interpreted: 1. As soon as the Incoming signal asserts high, the data interpreter reads 8 bits of data from the ASCII In[7:0]. 2. If the value of ASCII In is between 64 and 95 (0x40 to 0x5F), set the 5 least significant bits of Video Data Out to the 5 least significant bits of ASCII In (Video Data Out[4:0] = ASCII In[4:0]) and set the MSB of Video Data Out to 0 (Video Data Out[5] = 0). 3. If the value of ASCII In is between 32 and 63 (0x20 to 0x3F), set Video Data Out to the 6 least significant bits of ASCII In (Video Data Out[5:0] = ASCII In[5:0]). 4. If the value of ASCII In is 13, then an Enter key has been pressed so the Enter signal should assert high. 5. If the value of ASCII In is 8, then the Backspace key has been pressed so the Backspace signal should assert high. 6. If any one of steps 2 through 5 have been executed, then the ASCII code was valid so assert DataReady high to inform the Video Controller FSM that Video Data Out is ready. 7. However, if the ASCII code is unsupported, then set Video Data Out to 0 and do not assert DataReady. This way, invalid keystrokes and noise signals do not get displayed. Figure Data Interpreter Timing Diagram with Backspace and Enter Figure shows the data interpreter at work on the Backspace and Enter signals. Notice that Backspace and DataRdy assert high when ASCII In equals 8 (the ASCII code for backspace) and Enter and DataRdy assert high when ASCII In equals 13 (the ASCII code for enter). Notice that DataRdy remains high until it is reset back to low by LatchReset. Also notice that DataRdy does not assert high when ASCII In equals values that cannot be properly handled by the video subsystem.

38 35 Figure Data Interpreter Timing Diagram with Regular Characters Figure shows the data interpreter at work with regular characters (between ASCII code 32 and 95). Notice how Video Data Out translates ASCII In using step 3 on the previous page by simply copying the value of Video Data Out whenever Incoming asserts high since these ASCII codes are between 32 and 63. Once data from Ji s lab kit has passed through the data interpreters, it is correctly formatted for the MC6847 to display, but it is up to the Video Controller FSM and other components to determine how and where this data gets displayed. 3.5 Video RAM Address Counters The Video RAM is a 512x8-bit RAM that is implemented within the FPGA. In text and semigraphic-4 modes, the MC6847 uses 9 of its address bits to scan through all 512 locations in RAM and renders a frame of video data from the data within the 512 locations. The 512 locations are divided up into 16 rows by 32 columns on the screen. Each location corresponds to a group of pixels on the screen that can be controlled by the 8 bits of data in that location. In text mode, the 6 least significant bits determine the character to be rendered (see Section 3.4 Keyboard and IR Data Interpreters for more details), and the two most significant bits are extra bits that can be connected to other pins on the MC6847. Remember that in Section 3.3, I mentioned that Data[7] is connected to na/s (text / semigraphic selector) and that Data[6] is connected to INV (invert). In semigraphic-4 mode, the 6 least significant bits are used to determine the shape of the block to be rendered. The system updates the monitor display by refreshing the Video RAM with new data so that the next time the MC6847 sweeps across the RAM with its address pins, it can receive new data to render to the screen. Thus, the challenge of creating a text editor for the video subsystem is all about writing the correct data to the correct locations in the Video RAM. The Upper and Lower-Half Video RAM Address Counters provide abstractions for referencing RAM addresses that correspond to the upper and lower text windows. There are two sets of borders around the windows, so the counters cannot simply count up. They must skip over the borders so text does not override them. Additionally, they must reset when they are out of bounds of their respective windows so text does not overflow into different parts of the screen.

39 36

40 37 Figure on the previous page shows a detailed description of the Video RAM Address Counter functionality. The counter supports incrementing (regular character printing), decrementing (Backspace), and incrementing rows (Enter). The counter makes sure that only the Video RAM addresses that are within the bounds of either the upper or lower text window can be accessed. It provides a safety net that prevents text from overriding borders or overflowing into a text window that it does not belong to. The addresses from the two counters are sent to the Upper/Lower Address Multiplexer where a selector signal from the Video Controller FSM decides which address should access the Video RAM at a particular time. Figure Video RAM Address Counter Timing Diagram My realization to split the 9-bit address into separate row and column addresses allows for fairly straightforward VHDL implementation of the two address counters in UpperAddrCntr.vhd and LowerAddrCntr.vhd. The pseudo-code follows naturally and intuitively when the address is split into rows and columns. The only difference between the upper and lower address counters are the values of the generic constants for FIRST ROW and LAST ROW. The use of generic constants allowed me to reuse almost 100% of the code when coding the two counters. Figure shows the timing diagram for the Upper-Half Address Counter. Notice that the first row and column corresponds to address 33. When IncRow is asserted, the column remains at 1 while the row increments. Right after 1.0us, the LastRow warning signal asserts telling the user that the counter is on the last row. A further assertion of IncRow wraps the row back to 1. This diagram also shows the handling of the Inc and Reset commands. The LastRow signal asserts high when the counter is on the last row and the LastChar signal asserts high when the counter is on the last row and last column. These provide useful feedback to the Video Controller FSM, telling it when the text window is about to overflow. Now that we have examined the multiple sources of addresses and data that feed into the Video RAM, let us examine the actual RAM interface to see how the data is coordinated to allow the RAM to function as the internal representation of a fully-functional dual-window text editor.

41 RAM Interface Figure RAM Interface Block Diagram As described in previous sections, the 512x8-bit Video RAM is a direct representation of the video data that is displayed on the monitor. In order to display one complete frame, the address bits of the MC6847 increment through all 512 addresses and translate the 8-bit data at each address into either a character (text mode) or border image (semigraphics-4 mode). In order to change what is displayed on the screen, the video subsystem must change the contents of the Video RAM to the appropriate data at the appropriate times. The RAM interface is responsible for making sure that the Video RAM gets updated appropriately at the appropriate times. This section describes the components that work together to manage the Video RAM data. Address Multiplexers There are two address multiplexers that determine what 9-bit address gets sent into the Video RAM Addr[8:0] port. The Upper/Lower Address MUX determines whether the address from the Upper or Lower Address Counter gets passed through depending on the RAM KB nir signal from the Video Controller FSM. When RAM KB nir = 1, that means that keyboard data needs to be written to the RAM so the lower address gets used since the lower window corresponds to keyboard data. The opposite is true when RAM KB nir = 0 and IR data needs to be written to RAM. The Address Selector MUX, controlled by the nms signal, determines whether the internal address generated by the counters or the external address provided by the MC6847 reaches the Video RAM. During normal operation, nms = 1 and the MC6847 addresses the RAM, but when data needs to be written to the RAM, nms = 0 and the address counters address the RAM.

42 39 Data Multiplexers There are three data multiplexers cascaded in series that determine what 8-bit data gets sent into the Video RAM Data In[7:0] port. The first, KB/IR Data MUX, determines whether the 6-bit keyboard or IR data from the respective data interpreters is allowed to pass through into the next multiplexer. Just like the Upper/Lower Address MUX, the KB/IR Data MUX is controlled by the RAM KB nir signal. The next in the chain is the RAM Clear Data MUX that selects between received data and , which is the MC6847 character code for the empty space character. When RAM Clear = 1, this multiplexer selects , which feeds an empty space character into the RAM. Erasing characters is accomplished by overriding them with this space character. After passing through the first two data multiplexers, the 6-bit data is augmented into 8 bits by setting the MSB to 0 and the second MSB to equal the INVERT output from the Video Controller FSM. Remember that on the MC6847, the MSB (DD7) is connected to the na/s text/semigraphics mode selection pin. Since we are only adding new characters in text mode, this bit should always be 0. That is why the MSB should equal 0. Also, recall that on the MC6847, the second MSB (DD6) is connected to the INV pin. Connecting this data bit to the INVERT output allows the Video Controller FSM to achieve a blinking cursor effect. The final data multiplexer, the Data Selector MUX, determines whether the data that has gone through the previous two multiplexers or the data from the Reset RAM should feed into the Video RAM Data In[7:0] port. The control signal ResetRAM ndatabus is normally kept at 0 to let the normal data through, but when the text is scrolling after the text overflows the window, ResetRAM ndatabus turns to 1 to let the Reset RAM data feed into the Video RAM. The scrolling feature will be described in a later section. Video RAM The Video RAM is a 512x8-bit RAM that is programmed into the 10K10 FPGA. It is initialized with the contents from video-ram-init.ntl, a binary file created using the dat2ntl program on Athena. The initialization file is designed to provide the data for the borders of both the upper and lower text windows. The borders are rendered in the MC6847 semigraphic-4 mode. When the user turns on the video subsystem kit, two blank windows should appear on the monitor. The initialization of the RAM allows for these borders to be drawn without adding extra initialization states to the FSM in order to write that data into the RAM. Having an initialization file also makes it easier to change the style and shapes of the borders. The address and data input ports of the Video RAM are connected to the myriad of multiplexers described above. The write enable (WE) port is directly connected to the Video Controller FSM. The data output pins (Data Out[7:0]) are connected to the data input pins of the MC6847 in order to feed it with data to render on the screen. The data output is also connected to the data input of the Reset RAM in order to perform screen scrolling when the text overflows the window.

43 40 Reset RAM The Reset RAM is a 120x8-bit RAM that is programmed into the 10K10 FPGA. The sole purpose of the Reset RAM is to buffer text when the lines of text scroll upwards. Each text window displays 6 rows of text, each consisting of 30 characters. When the text fills up all the space in the window, the initial design of the system was to clear the entire window and start all over from the first row and first character. I thought that it would look more aesthetically-pleasing and be more useful if not all of the previous text was erased when the text window overflowed. The current implementation scrolls the text two lines upwards, thus leaving four lines of text and two new blank lines for new text to appear. This simulates the text scrolling of software text editors, but of course without the mouse or scrollbars. The Reset RAM needs to store four rows of text data so that they can be scrolled upwards and re-written into the Video RAM. 4 rows times 30 characters per row equals 120, and that is why the Reset RAM has 120 addresses. The write enable (WE) port is directly controlled by the Video Controller FSM. The data input comes directly from the Video RAM since the Reset RAM s job is to buffer data from the Video RAM. The data output goes into the Data Selector Multiplexer, and at the appropriate time, when ResetRAM ndatabus asserts high, that data gets written back into the Video RAM (in different locations, of course) in order to achieve the text scrolling effect. The Reset RAM address is controlled by the Reset Counter described below. Reset Counter Figure Reset Counter Timing Diagram The Reset Counter (counter120.vhd) is a simple synchronous counter that counts from 0 to 119 (and wraps around) when the inc signal is asserted. It can be reset using the reset signal, and it asserts the overflow status signal when the count equals 119. The count[6:0] output drives the address port of the Reset RAM. Figure shows the timing diagram for the reset counter. It behaves like an ordinary up-counter that asserts an overflow signal when the maximum value has been reached and then resets back to 0. The overflow signal that is sent to the Video Controller FSM is crucial in performing text scrolling. The mechanics of the text scrolling feature will be covered in-depth in the Video Controller FSM section. We have now examined all parts of the video subsystem except for the Video Controller FSM, the brains that control all of the parts to make the system function as a whole. This will be the emphasis of the next section.

44 Video Controller FSM Figure Video Controller FSM Block Diagram The Video Controller FSM is the brain that controls the entire video subsystem. It is a synchronous Mealy finite state machine that is programmed into the Altera 10K10 FPGA (VideoController.vhd) and clocked with the Mhz crystal oscillator clock that drives all components in the video subsystem. This FSM is responsible for providing functionality that allows the system to act as a robust dual-window text editor. The FSM has subroutines for printing new characters, erasing characters, jumping to new lines, and scrolling the text when it overflows a window. The FSM can control both upper and lower windows concurrently so that users can see both their keyboard data and received IR data appear on the screen at the same time. There are many input and output signals for this FSM, but many signals come in pairs. Since the functionality of the upper and lower text windows are virtually identical (with the exception of the blinking cursor which only shows up in the lower window), most signals come in homologous pairs. Signals that start with a L (lower) or KB (keyboard) correspond to the lower text window. Signals that start with a U (upper) or IR (infrared) correspond to the upper text window. Table describes all of the inputs and outputs of the Video Controller FSM, while Figures and show the complete FSM state transition diagram.

45 42 Inputs: clk Mhz crystal oscillator clock U LastRow, L LastRow Asserts high when the upper or lower address counter is currently on the last row. If the FSM receives an Enter signal in the appropriate window, the buffer will overflow and cause text scrolling. U LastChar, L LastChar Asserts high when the upper or lower address counter is currently on the last character. The next letter that the system receives for that window will overflow the buffer and cause text scrolling. KB in, IR in Asserts high when there is newlyreceived keyboard or IR data that is ready to be stored into the Video RAM. KB bksp, IR bksp Asserts high when a Backspace character has been received from the keyboard or IR. The system must move the cursor back and delete a character. KB enter, IR enter Asserts high when a Enter character has been received. The system must shift the cursor down into a new line. nfs Input from MC6847 that asserts low (negative true) when the MC6847 is done drawing a frame on the screen and the CRT gun is in the process of resetting its position. It is only safe for the system to write to the RAM when nfs is low. ResetCntrOverflow This signal assert high when the Reset Counter reaches its maximum value of 119. This signal is crucial when performing text scrolling. blink This signal from the Blinking Timer asserts high for a clock cycle once every 0.5 seconds to signal that the cursor on the lower text window should blink (change from light to dark and vice versa). Table Video Controller FSM Inputs and Outputs Outputs: U Inc, L Inc Signal to tell the upper or lowerhalf address counter to increment by one character. U IncRow, L IncRow Signal to tell the upper or lower-half address counter to increment by one row, thus bringing the cursor down to the next line. This is asserted as a response to an Enter character input. U Dec, L Dec Signal to tell the upper or lowerhalf address counter to decrement by one character, thus bringing the cursor back one place. This is asserted as a response to a Backspace character input. U Reset, L Reset Signal to tell the upper or lower-half address counter to reset back to the starting value and bring the cursor back to the first row and first character. KB rst, IR rst Signal to tell the keyboard or IR data interpreter that the FSM has already utilized the data that it provided so the KB in or IR in latch should be reset back to 0. INVERT Signal to the RAM interface that makes a particular 8-bit word of character data inverted. This is used for the blinking cursor. RAM KB nir Signal to the Upper/Lower Address MUX and KB/IR Data MUX that tells the RAM interface which addresses and data to use. When RAM KB nir = 1, then the lower address and KB data should be active. Otherwise, when RAM KB nir = 0, the upper address and IR data should be active. RAM Clear Signal to the RAM Clear Data MUX to tell the RAM to store an empty space character ( ) instead of regular data. This is used for deleting characters. ResetRAM ndatabus Signal to the Data Selector MUX to tell the RAM whether to store data from the data bus (ResetRAM ndatabus = 0) or from the Reset RAM (ResetRAM ndatabus = 1) RAM WE, ResetRAM WE Write enables for the RAM and Reset RAM, respectively. nms Signal to tell the Address Selector MUX that the internal RAM interface should address the RAM (nms = 0) or the MC6847 should address the RAM (nms = 1) ResetCntrInc Increments reset counter by 1 ResetCntrReset Resets the reset counter to 0

46 43

47 44

48 The following sections will discuss the functionality of the Video Controller FSM at a higher level of abstraction than the state transition diagrams show. I will split the Video Controller FSM functionality into subroutines and provide sequential pseudo-code which will be easier and more intuitive to interpret than reading the complex state transition diagrams. The FSM starts in the IDLE state and waits for an event to occur by listening for several key signals to assert: nfs coupled with KB in, IR in, or blink. As soon as the key signals assert, the FSM jumps into one of the following subroutines: Cursor Blinking, New Line, Backspace, Display New Character, or Reset & Scroll Text. Cursor Blinking Subroutine The Blinking Timer component is a clock divider that divides the Mhz clock into a 0.5 Hz divided clock that asserts the blink signal for one clock period every 0.5 seconds. When the FSM receives a blink signal, it toggles the INVERT signal and asserts the cursorwritelatch. The toggling of the INVERT signal occurs every 0.5 seconds so every half of a second, the cursor should turn from light to dark or light to dark. This is how the blinking cursor effect is achieved. Notice that only the lower text window has a blinking cursor since that is the window that displays text that the user types from the keyboard. A cursor is a basic graphical interface feature in any text editor since the user needs to know the current position as he is typing. It makes no sense to have a blinking cursor on the upper text window since that is a reception window for incoming IR text messages and the user does not have direct control over that cursor s position. As soon as nfs goes low, it is safe for the video subsystem to write to the RAM. If no keyboard or IR data is incoming and the cursorwritelatch is high (which means that the state of the cursor has recently changed and needs to be written on the screen), the system enters the LOWER CURSOR WRITE 1 and LOWER CURSOR WRITE 2 states. In these states, the FSM asserts RAM Clear and writes to the current lower-half address location to write an empty space in that block. If INVERT = 1, then the empty space will be dark, otherwise it will be light. In this way, the cursor will appear to alternate between dark and light every 0.5 seconds when the FSM writes to the RAM and the MC6847 subsequently reads from it. Incoming Keyboard or IR Data When nfs is low and KB in (or IR in) is high, then the system enters the KB START (or IR START) state, and it is ready to take one chunk of data from the keyboard (or IR), interpret it, and display it to the screen in an appropriate manner. The FSM delegates to one of the following subroutines depending on the state of the upper (or lower) text window and the nature of the incoming keyboard (or IR) data. Due to symmetry between the keyboard and IR subroutines, the states in Figures and Figure are almost identical. There are fewer IR states since the upper text window does not have to worry about a blinking cursor. 45

49 1. If the user pressed the Enter key and the cursor is not in the last row, then call the New Line subroutine. 2. If the user pressed the Backspace key, then call the Backspace subroutine. 3. If the user pressed a regular character (not Enter or Backspace) and the cursor is not at the last character, then call the Display New Character subroutine. 4. If the user pressed Enter and the cursor is in the last row or the user pressed a regular character and the cursor is at the last character, then call the Reset & Scroll Text subroutine. This means that the text buffer has overflowed and needs to be scrolled. New Line Subroutine This subroutine is called to bring the cursor down to a new line once the Enter key has been pressed and the cursor is not currently located at the last line. The only difference in the keyboard and IR subroutine is that the keyboard version needs to make sure that the blinking cursor is set to clear (NOT inverted) before moving the cursor down to a new line. Failure to do so may result in a dark block being left behind as the cursor moves into its new location. This is because the blinking cursor results from repeated alternate writings of a dark (inverted) block and a clear (not inverted) block in the current cursor position (see Cursor Blinking above). Here is the subroutine: 1. (Keyboard only) Enter the two LOWER CLEAR PRE-WRITE states, set INVERT = 0, RAM Clear = 1, and write to the current location in RAM to clear out any residual dark spots formed by the blinking cursor. 2. Assert the respective increment row signal (U IncRow or L IncRow) and finish by resetting the data ready latch (KB rst or IR rst) and returning to IDLE. Backspace Subroutine This subroutine is called to erase one character to the left of the cursor and to decrement the cursor s position back by one. This should behave like the backspace on an ordinary text editor. Once again, the only difference in the keyboard and IR subroutine is the need to clear the blinking cursor in order to not leave behind a dark block residue. Here is the subroutine: 1. (Keyboard only) Enter the two LOWER CLEAR PRE-WRITE states, set INVERT = 0, RAM Clear = 1, and write to the current location in RAM to clear out any residual dark spots formed by the blinking cursor. 2. Assert the respective decrement signal (U Dec or L Dec) to bring the cursor backwards one position. 3. Assert RAM Clear and write an empty space into the RAM in order to clear any text that occupied that position. The cursor has now moved one position back and the text in that position has been cleared. 4. Finish by resetting the data latch (KB rst or IR rst) and returning to IDLE. 46

50 47 Display New Character Subroutine This subroutine is called the majority of the time that there is keyboard or IR input. This displays a new character to the appropriate text window and moves the cursor forward just like a regular text editor. The address counters handle the cases when characters overflow a particular line. The characters will automatically wrap around to the next line. This subroutine is called directly by the FSM when the system receives a new character and the cursor is currently not at the last character position. If the cursor is at the last cursor position and the system receives a new character, then the text buffer overflows and the text must scroll up by two lines before this subroutine is called to display that character. Here is the subroutine that is identical for both the IR and the keyboard: 1. Write the current data into RAM. 2. Assert the appropriate increment signal (U Inc or L Inc) to increment the respective cursor forward by one character. 3. Finish by resetting the data latch (KB rst or IR rst) and returning to IDLE. Reset & Scroll Text Subroutine This subroutine is called when the user overflows the buffer and the text needs to be scrolled upwards to make room for new text to be displayed. This is called when the system receives an Enter key and the cursor is on the last row or when the system receives a normal (not Enter or Backspace) key and the cursor is at the last character. The concept is to emulate a text editor s ability to scroll text upwards so that old text can be seen as well as new text. The original implementation simply cleared the entire screen. This was not very aesthetically pleasing or useful since users would lose previous textual information as soon as they overflow the text buffer. Since there are 6 rows of text that can be displayed at one time, the current implementation takes the 4 lowermost rows (the most-recently displayed text) and shifts them upwards by 2 rows each so that row 3 is now row 1, row 4 is row 2, row 5 is row 3, and row 6 is row 4. The 2 uppermost rows are scrolled away and deleted, thus leaving the bottom two rows empty for new text to be displayed. This allows users to both see what has already been typed on the screen and allows for more room for users to view new incoming text. This is the most complicated subroutine to implement because of the fact that the text needs to be buffered in the Reset RAM before being transferred back into the Video RAM in different locations to make it appear as though it has scrolled upwards by two lines. There are subtle differences between the keyboard and IR versions due to the blinking cursor. Here is the subroutine: 1. (Keyboard only) Enter the two LOWER RESET CLEAR CURSOR states, set INVERT = 0, RAM Clear = 1, and write to the current location in RAM to clear out any residual dark spots formed by the blinking cursor. 2. Enter the RESET CLEAR CURSOR STALL, RESET INC ROW 1, and RESET INC ROW 2 states to reset the appropriate address counter and make two calls to increment row. This places the cursor at the beginning of the third row.

51 Remember that all data from rows 3, 4, 5, and 6 must be saved and transferred back up to rows 1, 2, 3, and Enter the three RESET BUFFER states and loop for 120 iterations until ResetCntrOverflow asserts high. During each iteration, copy the current data from the Video RAM into the Reset RAM and increment the address of both RAMs by one. There needs to be 120 iterations since there are 4 rows of 30 characters each that need to be saved in the Reset RAM. Once these 120 iterations are complete, the Reset RAM will have all of the data contained in the lowermost 4 rows of the Video RAM. Remember that the definition of lowermost 4 rows depends on whether we are in the keyboard or IR state. The keyboard uses the lower text window while the IR uses the upper text window. 4. Now that the Reset RAM has a copy of the lowermost 4 rows of character data from the Video RAM, the system enters the two RESET WRITE states and erases all data in the appropriate text window. It is safe to erase all of the data since the relevant data is already saved within the Reset RAM. 5. Now that the text window is all cleared, the system resets the appropriate counter so that the cursor is positioned at the first character in the first row. The system then enters the three RESET DATA WRITE states and feeds all of the data from the Reset RAM back into the Video RAM. During every one of the 120 iterations, the data from the Reset RAM is written into the Video RAM and the addresses of both RAMs increment. After these 120 iterations are completed, then the Video RAM will contain the data from the lowermost 4 rows, except that everything is moved up by two rows. This is exactly the desired behavior to achieve the text scrolling effect. 6. If an Enter key caused this subroutine to be called, then increment the row to start a new line and finish by resetting the appropriate latch (KB rst or IR rst) and return to IDLE. 7. Otherwise, if a regular character key caused this subroutine to be called, then call the Display New Character subroutine in order to display the new character after the text has scrolled up by two lines. The state transition diagrams for the Video Controller FSM may look complicated, but there are only a few subroutine calls that the FSM needs to perform. Those are the ones that I have described in this section. The complex set of states and state transitions are necessary to get the precise timing of signals and RAM data correct in order to implement these subroutines in the Altera 10K10 FPGA. The next four pages show the timing diagrams for the Video Controller FSM as it executes the various subroutines. 48

52 49 Figure Video Controller FSM executing Display New Character subroutine In Figure 3.7.5, the FSM first receives input from the keyboard (KB in), executes the Display New Character subroutine to display a new character to the lower text window, and then receives input from the IR (IR in) and displays a new character to the upper text window. This is the typical FSM behavior when a user types a key and then receives a text via IR at the same time. Notice that both the keyboard and IR text get written to the Video RAM while the nfs is low. This means that when the MC6847 renders the next frame (when nfs goes high again), two brand new characters will appear on the screen, one in the upper text window and one in the lower text window. It appears as though both the keyboard and IR data has been handled concurrently, which is exactly the desired behavior.

53 50 Figure Video Controller FSM executing New Line and Backspace subroutines Figure shows the system s response to a user pressing the Enter key followed immediately by the Backspace key. The system first executes the New Line subroutine as a response to KB in and KB enter, and then executes the Backspace subroutine as a response to KB in and KB bksp.

54 51 Figure Video Controller FSM executing several IR subroutines Figure shows the FSM executing various subroutines in response to IR data inputs, thus manipulating the upper text window. The first key that is received via IR is the Enter key so the system executes the New Line subroutine. Then the Backspace key is received and the system executes the Backspace subroutine. Finally, a regular character key is received and the system executes the Display New Character subroutine. The purpose of this screenshot is to show that there are two sets of almost-identical subroutines for the keyboard and IR.

55 52 Figure Video Controller FSM executing Reset & Scroll Text subroutine Figure shows the FSM executing the Reset & Scroll Text subroutine. Notice how the state transitions are much more complicated than the previous three timing diagrams due to the complex interactions between the Video RAM and Reset RAM that must occur in order to accomplish text scrolling. This concludes the discussion of the Infrared Instant Messenger video subsystem functionality. The Video Controller FSM provides the control signals for the system while the Video RAM provides the actual data that is interpreted by the MC6847. The analog output circuitry takes the MC6847 outputs and converts them into a format that can be displayed on the television monitors in the lab. The modularity of the video subsystem design allows it to function as a robust dual-window text editor using an 18-bit data bus interface, 9 pins for the upper text window and 9 pins for the lower text window. The video subsystem is hooked up to Ji s keyboard/ir input/output subsystem, and our two kits work together to form the complete Infrared Instant Messenger system.