§ 13 - Graphics Capabilities

§ 13.1 - General Information

ReFLEX offers a 256x256 graphics environment that is an emulation of a custom graphics system for a commercial video game machine I designed around 1980. At the time, my goals were simple: Keep the CPU memory space occupied by the graphics design to a minimum; make the design as flexible as possible; make it fast, and keep it inexpensive.

The actual implementation uses two bytes of memory space; is quite flexible and capable, allowing fast line drawing, pixel writing, erase and easily handled "pseudo-sprites"; can write pixels as fast as the CPU can store bytes, and used less than five dollars worth of TTL (not counting the display RAM). Looking at the design today, it's still far better than a straight frame buffer, though (of course) it can't compare with dedicated graphics engines. But if I'd had a multi-million transistor design budget, who knows what this might have turned into...

The display appears in its own window. If you do not open the window using the appropriate menu item (Modes/Graphics), it will open automatically when the first graphics command is executed by running 6809 software. I've provided a few graphics programs for you to play with:

• KINART.CMD
  • This is kinetic string art, a program I wrote back in 1980 or so. There are no commands. Pressing ESC with the main emulator window active will terminate the program.
• RB.CMD
  • Once you start the program, click in the graphics window. There are four controls: Rotate left, rotate right, thrust and fire. These are the A, S, K, and L keys. You can exit the program by clicking back in the main emulation window, and pressing the ESC key. It may take more than one press.
    • RB.CMD uses the DIP switches to set bonus levels, ships/credit, run/stop, and credits. Switches 0, 1 and 2 are credits. 111 or 000 is test mode, 2 credits at all times. You need this setting. Switches 3,4 are ships/credit, 3, 4, 5 or 6. Switch 5 is run/stop. Switches 6,7 are bonus levels; 00=5000, 01=10000, 10=15000 and 11=20000.
• IT.CMD
  • Once you start the program, click in the graphics window. There are four controls: move up, move down, flip direction and fire. These are the A, S, K, and L keys. You can exit the program by clicking back in the main emulation window, and pressing the ESC key. It may take more than one press.
• CARDS.CMD
  • Once you start the program click in the graphics window. There are four controls, which vary in function according to the menu on the bottom of the display. The four keys are, from left to right: A, S, K, and L. You can exit the program by clicking back in the main emulation window, and pressing the ESC key. It may take more than one press.
• STORM.BAS
  • This is a hurricane tracking program written by Pete Gerardi. To use it, type BASIC. At the BASIC prompt, type LOAD "STORM", then RUN. Once it starts, it prompts you for what it needs. There are a number of associated files, which are: STORMS.DAT, EMILLY.DAT, DENNIS.DAT, FLOYD.DAT, GERT.DAT, BASPGEN.BIN and BLINE.BIN. These should all be on the working drive.
• CHESS.CMD
  • This command is a "translated" 6809 version of SARGON, a very early chess-playing program. SARGON's source code was published in a paperback book, and I believe it was Brian Bailey who began the translation of the code from 8080 to the 6809. When I got the source code, the program wasn't completely translated and most assuredly did not work. I spent many hours checking the translation against the paperback, and finally got it all going. I even had the moves and warnings coming out of my speech synthesizer! Once you start playing, the only way out is by pressing NMI or RESET, then using the monitor's "W" command to restart FLEX. I must have really thought no one ever quits a chess game... The moves are entered at the FLEX console prompt in column-row / alpha-numeric format. It's easy to use, but doesn't play a very strong game of chess, and the graphics are decidedly minimal.

If you would like to work with the graphics EM-ware, a fairly complete discussion follows. If you simply prefer to play with the supplied graphics programs, then you don't need to read any further on this page.

You can only "zoom in" using the Host computer's screen zoom capabilities. There is no magnification provided in the emulation itself.

§ 13.2 - The Nuts And Bolts

§ 13.2.1 - Technical Overview

The graphics system uses one 6522 VIA, or 16 bytes of memory space. Control of the graphics capabilities requires accessing only two bytes of memory, the VIA's two data ports.

The graphics hardware has two ports, or addresses, it is accessed through. The first port (at $E030) is the command port. The second port (at $E031) is the data port. The command port accepts four commands, and the data port accepts three data formats, depending on which command has most recently been issued. These are color, pixel addresses, and a vectoid, which is a single pixel with the vector characteristic of displacement.

The data port is a single byte with bits organized as follows:

Pixel colors are defined as follows:

The command port is a single byte of which two bits are used to select one of four possible commands:

Graphics are created using four "Commands" to the graphics hardware:

Because the command port is mapped to the VIA's B data port, which is at the base address of the VIA ($E030), and the data port is mapped to the VIA's A data port which is at the base address plus one ($E031), you can use any 16-bit store operation to very quickly (one fast instruction) write the command, then the data. A table of 8, 16-bit values can provide you with all of the clear commands, for instance.

Since once a command is written to the command port, it remains set, you can also write multiple vectoids to the data port one after another. Envision writing a stream of bytes from a table somewhere to the data port. As a program task, things just don't get much more trivial.

Now, since each vectoid may contain a displacement, they can modify the X:Y position as they are stored. For instance, if you wanted to write a 4x4 blue square, you would first write the X and Y commands with the X and Y position (of the upper left corner for this table), then the write vector command, then store the contents of the following table to the data port:

 FCB $11  1     Initial X:Y address  -->  C 1 2 3
 FCB $11  2                               B     4
 FCB $11  3                               A     5
 FCB $A1  4                               9 8 7 6
 FCB $A1  5
 FCB $A1  6
 FCB $51  7
 FCB $51  8
 FCB $51  9
 FCB $21  A
 FCB $21  B
 FCB $21  C

§ 13.2.2 - Pseudo-Sprites

This is the basis for simple, but extremely useful pseudo-sprite creation. A solid object is just as easy to create, and involves the same series of store operations after and X:Y address set. Further, if the object (pseudo-sprite) is created with a one pixel outer border that is the same color as the backdrop color, and the sprite is moved no further than one pixel per redraw, it will erase itself as it is moved and no erase code is required.

§ 13.2.3 - Line Drawing

One of the best-known methods of line drawing is Bresenham's Algorithm. This is also referred to as a DDA. The DDA method involves calculating the slope of the line prior to drawing it, then "costs" one addition per pixel. It generates pixels that are either increased by X, by both X and Y, or just by Y in each case. It turns out that since my hardware design allows you to implicitly encode those specific motions into a pixel (a vectoid), you can pre-calculate any vector and use it anywhere with the same speed as a pseudo-sprite; that is, the vector is a list of vectoids. You write the X:Y position of the line start, then a stream of vectoids. No calculations, not even an addition. Of course, you can "live" generate lines as well, then the speed is as fast as any DDA, except with a normal display, you'd be calculating pixel addresses for each generated output - vectoids do the calculations for you, and hence even a "straight" DDA is faster here.

You can, of course, use the hardware by writing X, writing Y, then writing a vectoid with no motion - that's three 16-bit stores per pixel and is 6x slower than the hardware's maximum display speed (one 8-bit store per pixel), but it's still mighty quick. It's a lot easier to figure out, too. However, if you want to use the hardware the way I described above, the following set of equates will make it much easier.

To use these equates, just "or" in the color to the direction and store (repeatedly, as many times as you like) to $E031 after writing $00 to $E030, once. The equates to use are EAST, WEST and so on. They are built "from" the preceding equates.

*
* BIT POSITION VALUES
*
B7      EQU    128
B6      EQU    64
B5      EQU    32
B4      EQU    16

*
* VECTOR DIRECTION EQUATES
*
VUXY    EQU    B5+B4       VECTOR UP X & Y
VUYX    EQU    VUXY
VUX     EQU    B4          VECTOR UP X
VUY     EQU    B5          VECTOR UP Y
VDXY    EQU    B7+B6+B5+B4 VECTOR DOWN X & Y
VDYX    EQU    VDXY
VDX     EQU    B6+B4       VECTOR DOWN X
VDY     EQU    B7+B5       VECTOR DOWN Y
VDXUY   EQU    B6+B5+B4    VECTOR DOWN X & UP Y
VUYDX   EQU    VDXUY
VUXDY   EQU    B7+B5+B4    VECTOR DOWN Y & UP X
VDYUX   EQU    VUXDY

*
* THE FOLLOWING PAIRS OF EQUATES ALLOW YOU TO
* CHOOSE ORIENTATION... IN A VIDEO GAME, IT
* IS VERY USEFUL TO SWITCH ORIENTATION QUICKLY.
* FOR INSTANCE, IN A COCKTAIL TABLE GAME, THE
* DISPLAY MUST BE FLIPPED VERTICALLY FOR EACH PLAYER,
* AND A SET OF VALUES CAN BE HARD-CODED FOR THAT,
* OR CHOSEN AT RUN TIME. THE TWO SETS HERE ALLOW
* YOU TO DRIVE THE MONITOR SIDEWAYS OR VERTICALLY.
* NICE AND FLEXIBLE. AS SHOWN HERE, THE ORIENTATION
* IS DECIDED AT ASSEMBLY TIME. BUT YOU COULD EASILY
* MAKE THESE VARIABLES INSTEAD OF EQUATES, AND THEN
* STORE THE CONTENTS OF THE VARIABLES TO THE
* GRAPHICS HARDWARE. YOU COULD HAVE ANY OF FOUR
* ORIENTATIONS (THOUGH ONLY TWO ARE SHOWN HERE) SET
* UNDER PROGRAM CONTROL. WHEN YOU'RE CODING VIDEO
* GAMES FOR THE VARIOUS STYLES OF ARCADE CABINETS,
* THIS IS INVALUABLE.
*
HORIZ   EQU    1

        IF HORIZ=1
*
*HORIZONTAL ORIENTATION
*
WV      EQU    0
WY      EQU    1
WX      EQU    2
WC      EQU    3

EAST    EQU    VUX
WEST    EQU    VDX
SOUTH   EQU    VUY
NORTH   EQU    VDY
NW      EQU    VDXY
SW      EQU    VDXUY
SE      EQU    VUXY
NE      EQU    VUXDY

        ELSE

*
*VERTICAL ORIENTATION
*
WV      EQU    0
WX      EQU    2
WY      EQU    1
WC      EQU    3

EAST    EQU    VUY
WEST    EQU    VDY
SOUTH   EQU    VUX
NORTH   EQU    VDX
NW      EQU    VDXY
SW      EQU    VUXDY
SE      EQU    VUXY
NE      EQU    VDXUY

        ENDIF