Project Final Report. Z8 Arcade! 4/25/2006 James Bromwell,

Transcription

1 Project Final Report Z8 Arcade! 4/25/2006 James Bromwell, Project Abstract Z8 Arcade! is an extension of the presentation on adding a composite video output line to the Z8 project board, implementing an arcade-style block-breaking video game using an external analog controller. The video signal is generated purely in software and output using a resistor network Digital to Analog Converter (DAC). The game itself uses delay-looping to time output, and each on-screen object is drawn individually. Status While the final product looks more or less as originally intended, several major speed bumps were encountered on the path to what is pictured below. First and foremost, the original memory-mapped idea was scrapped because (at the time) it seemed impossible to get more than 20 or 30 pixels per scanline, which would have made horizontal movement appear very, very choppy. So, the code was updated to use simple delay looping draw black, wait until the paddle should be drawn, switch to white, wait, switch to black, etc. This allowed for finer-pitch control. There was a problem where the logic to decide which line was being drawn (is there a block? a ball? the paddle?) took so long the left inch or two of screen was forced to stay blank. This was solved by drawing only every other line of each field, using the odd fields to calculate what would be done in the even ones. And finally, the two original controller ideas (serial mouse and PC gameport joystick) both did not work. The serial mouse requires 7-bit serial communications, and the Z8 UART uses 8-bit. The project couldn t afford to spare enough CPU cycles to use a GPIO port as a software-controlled UART, so the mouse was abandoned. The PC gameport joystick would probably have worked out, had I found one old enough both of the ones I could find were actually USB devices that could be connected to a gameport with special drivers. Since all I was going to use on the joystick was one analog axis and a button, I went out and got a simple 300 potentiometer, and used a button on the Z8 development board instead.

2 Video Signal Before we get to know the project, we need to know a little something about black and white NTSC composite video, the kind of signal put out by the project. The below review will be brief since the report on the presentation which preceded this work has already been submitted. Overview The NTSC black and white signal is composed of 525 lines per frame, each made up of two interlaced line fields at 30 frames per sec = 60 fields per second. The definition of the NTSC signal uses Institute of Radio Engineers measurements ( IRE units ), which are defined as -40 to 100 IRE over a 1.0v scale. Thus, 1 IRE equals 1/140 volt. Four discrete voltage levels are used in the basic specification: Sync: -40 IRE = 0v Blank: 0 IRE = 0.286v Black: 10 IRE = 0.357v (NTSC-J uses BLANK) White: 100 IRE = 1.00v Each frame is structured as three lines of Pre-equalization pulses, each of which is made up of a 4.7 µsec SYNC followed by a µsec BLANK; then three lines of VSYNC, the inverse of the above (long SYNC followed by short BLANK); then three (or 3½) lines of Post-equalization pulses ; then 253 (252½) lines of (mostly) visible output The first nine lines of a field define the vertical hold time, and are shown below:

3 Scanlines Each visible line is composed of 4 parts: a Front Porch, which is1.5 µsec BLANK; a horizontal synchronization pulse (HSYNC), which is 4.7 µsec SYNC; a Back Porch, which is 4.7 µsec BLANK, and line data, which lasts the remaining 52.6 µsec and can be any voltage between BLACK and WHITE. The signal is illustrated below: Data The visible data comprises 52.6 µsec of each scanline. It is assumed to be between 10 and 100 IRE (0.357v and 1.00v), though many displays will automatically adjust gain so that the signal presented covers the entire black-to-white range. The first 21 or so lines of each frame are not drawn, as the beam drawing the image on the CRT needs time to return to the home position. Frequently, this time is used to transmit auxiliary data, like closed captioning or special color synchronization information.

4 Hardware The hardware consists of three principal components: the main control board, the digital-to-analog converter, and the game controller. Controller (Potentiometer) Main Board Z8F6403 Digital to Analog Converter (DAC) Main Board The main development board for the project is the Zilog Z8F6403. The board is based on the Zilog ez8 running at MHz. Notable features used were: 4KB register RAM 12-channel 10-bit A/D converter (controller input) Four 16-bit timers with PWMs and capture and compare (video timing control) 60 general-purpose I/Os (video signal output) 24 vectored interrupts (video timing control) On-chip debug with break and trap capability Early implementations depended on the 4KB of RAM to hold a large amount of on-screen data; this implementation was deemed too slow for reasonable use. The onchip debugger was used extensively in testing the software during development. And of course, an NTSC television is required to view the resulting signal. The only other hardware components are the resistor-based digital-to-analog converter (DAC), and the potentiometer used as a game controller.

5 Digital to Analog Converter (DAC) A digital-to-analog converter is required to output the NTSC composite video signal. As stated above, four voltage levels are needed: 0 VDC, VDC, VDC, and 1 VDC. To build this out of resistors requires 3 GPIO pins, such that with one active at a time, the three non-zero voltage levels can be generated. Two pins are not sufficient because one of the resistors in the network the impedance of the television is not under our control. The DAC looks like this: The three pins on J1 were used as PF[0:2] on the Z8. J2 represents an RCA jack, which was used as a convenient way of hooking the project up to the output device (television). R1 through R3 represent the three resistors that make up the DAC, and R4 represents the internal impedance of the television, nominally 75 ohms. Calculating the values of the three resistors is not a trivial task, so a Microsoft Excel spreadsheet was used to determine the formulas for each target condition: pin 1 on = 0.286v, pin 2 on = 0.357v, pin 3 on = 1.00v, and all pins off. The spreadsheet is attached, and described later in this document under the Attachments section. An assortment of metal film resistors (2% tolerance) were used to approximate the nominal values shown on the spreadsheet. Game Controller The arcade game software needed a controller to act as a user interface. Originally, a serial mouse was proposed, but this proved impossible to implement since the serial mouse uses a 7-bit serial connection, and the Z8 UART is only capable of 8-bit communications. A software RS-232 interface could have been constructed but would have had to be interrupt-based, and would have seriously disrupted the delicate video output software. The second choice was a PC gameport joystick, but this too failed to pan out. Two test joysticks were obtained, but both turned out to be USB devices in disguise, with special drivers (for Windows PCs only, of course) that allowed them to be physically connected to a PC gameport, then polled with a special serial protocol whose specification does not seem to be available, and again would have required an impractical software emulation. Since the only components of the PC joystick that would have been used were an internal potentiometer (the axis of the joystick) and a switch (the joystick button), those two components were obtained in discrete form and used instead.

6 The potentiometer chosen is a 10k ohm model with 300 rotation. Since it covers the entire 0-10k ohm range, some discrete resistors were needed to control the voltage output at the device s wiper. As described below in the Software section, the Z8 ADC input reads relative to 2.00 VDC, so resistor values were chosen such that only zero to about 1.7 volts were dropped across the potentiometer, for reasons that will be explained later. The game controller circuit appears below: After some experimental testing, two 4.7k ohm resistors were wired in series with the potentiometer. VDD in the picture (and VDD on the Z8F6403 board) is 3.3 VDC.

7 Software The project is controlled by software that is divided up, at the highest level, into video control and game control. The video control software is interrupt-driven, with one interrupt generated to start a field (half a frame), and another generated repeatedly during the data portion of each field to start a scanline. The game control software runs continuously and is executed any time the video control software is not using the CPU it is the idle task. Video Control: Interrupt Controller Hz Initialize Video

8 Game Control: There are some important points to be made about the implementation of the software. First and foremost, the video signal has some tricky timing. To best approximate the ideal signal, interrupts were use for large-scale correctness, and delaywaiting was used for finer control. Ideally, the video signal might be generated entirely from interrupts, since (for small values) the interrupt controller can be made precise to within one clock cycle 1 / = e-8 seconds, or about 54 nanoseconds. The original video output attempt used this model, but hit a roadblock. First, the C compiler does a terrible job with switch statements! There does not seem to be an efficient way to branch through multiple code paths based on an integer value and one of the goals of the project was to use assembly only when absolutely necessary. Second, the vector tables used for interrupt lookups are in code-space, which means that they cannot effectively be updated at runtime. The combined effect of these two problems is that for multiple code branches (like drawing the different parts of a video output signal), the further down the branch is, the later it will get executed. For example:

9 switch(i){ case 1: foo(); ++i; break; case 2: bar(); ++i; break; case 3: default: baz(); break; } If the function containing the above code is called three times successively, there might be X clock cycles between calling the function and the call to foo(), but X + Y between calling the function and the call to bar(). The call to baz() would come after X + 2Y, where Y is probably about 3 (depending on the type of i and several other factors). This problem is why delay-looping is used to control the precise timing of the video signal. Another important point is that there are only a few microseconds (or a few dozen clock cycles, or a handful of useful opcodes) between the end of the Back Porch and the beginning of the visible beam trace. This means that calculating what will be drawn on a line during the actual line trace will create a single-colored bar on the left side of the screen, of a length that varies depending on control flow. Needless to say, this is unacceptable. Instead, the project as implemented uses odd-numbered lines to calculate the contents of the next (even-numbered) line of the field. As a result, the output has a striped effect that can be quite pronounced on a big screen. Also of note, the implementation of the video output logic is completely different from that used for the NTSC presentation. The difference is that the program used in the presentation was memory-mapped, and the project display computes each line as it is drawn. The memory-mapped model used part of the RAM to store the value of each onscreen pixel here defined as the smallest *horizontal* line that can be drawn. The problem with this was that it does not seem to be possible to load a value from memory and change the value put out over a GPIO pin in a short enough time to make pixels reasonably small. With computed output, the pixels don t really get smaller, but since each object is drawn individually, the space between objects can be controlled with a finer pitch. It is possible that further hand optimization of the memory-mapped code could make it as efficient as computed output, but such optimization would have to take place at an assembly-code level.

10 Results

11 The video output is fairly stable (better on some displays than others) and animation is nice and smooth. Unfortunately, the ball cannot be drawn closer than about 1 ball-width to another object, including both the paddle and the blocks. As a result, the ball actually bounces off a space about one ball-width in front of the paddle, and disappears when it comes within a ball-width of (the front of) a block. The former is mostly noticeable at the beginning before the ball is launched, and the second is most visible in the distortion the ball creates when it bounces off the backplane. This could be remedied by removing the visible backplane, which would probably look OK.

12 Retrospective There were no major hardware design decisions, except those driven by failure failure to use the serial mouse, and failure to interface with the PC gameport joystick. The impact of these failures was to fall back on the humble potentiometer as a controller. This should have been done from the first place for games that use only one analog axis, it just makes sense, and is easier to deal with than a multi-pin header on a gameport connector intended for another purpose. The serial mouse, though technically impressive, was definitely overkill. As mentioned above in the Software Design section, there were several previous incarnations of the software architecture that differed radically from the one used in the end. The design decision to use interrupts for all timing control stemmed from a desire to make timing as precise as possible some displays will show sloppy NTSC, but some will choke and only output static. Fear of this problem led to the (poor) design decision to pop in and out of interrupts over and over again, with no real visible benefit. The design decision to use memory-mapping was quite well-intentioned: a memory-mapped display lends the ultimate in versatility, and is the model used in all modern graphic controllers. An implementation in assembly might have worked reasonably well, but one done in C was simply doomed from the start. In the end, the decision to use delay looping made for a smooth animation of both ball and paddle movement, though it complicated some of the rendering code considerably, and made it impossible to effectively draw the ball when it goes behind a block. As a result, the game rules were changed such that gravity pulls blocks to the right of the screen a block taken out of the third row will make any blocks in the first or second rows fall to the right. This is not in the spirit of the original Breakout game. If I had more time, I d do the project over again with hand-assembled memory mapping and compare the results.

13 Description of Attachments Attachments include: 339Project.zuml: All UML state charts displayed above, Poseidon UML CE project.epc: schematic of the resistor network (pictured above), PCB123 Breakout (folder): The source of the project as shown in class controller.sch: schematic of potentiometer connection, ExpressSCH DrawData.png: Statechart of the data drawing software module GameControl.png: Statechart of the game control software module Project Brochure.doc: The glossy brochure circulated in class, Word 2002 Resistor calculations.xls: spreadsheet to pick DAC resistors, Microsoft Excel 2002 VideoOut (folder): original implementation of video output VideoOut.png: Video output code state chart VideoOut2 (folder): Updated video output code (used in presentation) Z8 Video Output.ppt: Presentation given in class, Microsoft PowerPoint 2002