§ 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:
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.
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.
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.
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.
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.
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 emulation of the 6522 VIA
is only complete to the degree required for the graphics and interrupt emulations to function.
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.
Tip: In the following tables, "n/u" means "not used." You are advised to write zeros in these bit positions. "x", on the other hand, means "dont' care", and it doesn't matter what you write in a bit position with this label. Generally, this is because a bit in another position has disabled the functionality that would otherwise be provided by the "x" bit.
The data port is a single byte with bits organized as follows:
|Command ||b7 ||b6 ||b5 ||b4 ||b3 ||b2 ||b1 ||b0 ||Format |
|Clear ||n/u ||n/u ||n/u ||n/u ||n/u ||C2 ||C1 ||C0 ||Color |
|Write Y ||b7 ||b6 ||b5 ||b4 ||b3 ||b2 ||b1 ||b0 ||8-bit Position |
|Write X ||b7 ||b6 ||b5 ||b4 ||b3 ||b2 ||b1 ||b0 ||8-bit Position |
|Write Vectoid ||Y.D/u ||X.L/r ||Y ||X ||n/u ||C2 ||C1 ||C0 ||Vectoid |
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:
|Clear||00000011||Write the Clear command to the command port. Then write a byte with the desired color choice in C2,C1,C0 to the data port. At the time the data byte is written, the entire display will be cleared to the chosen color. The vector bits are ignored for this command.|
|Write Y||00000010||Write the Write Y command to the command port. Then write a byte that is the Y adddress of the desired position on the display. The display position is changed; no pixels are modified.|
|Write X||00000001||Write the Write X command to the command port. Then write a byte that is the X address of the desired position on the display. The display position is changed; no pixels are modified.|
|Write Vectoid||00000000||Write the Write Vectoid command to the command port. Then write a byte to the data port that contains the vectoid data. When the vectoid data is written, the X and Y positions are modifed according to the settings of the highest order four bits of the vectoid data byte, then the resulting pixel address is set to the color in the C2,C1,C0 bits. The four control bits allow X:Y pixel adjustment in any of the eight vertical, horizontal and diagonal directions.|
|The table at the right describes the exact behaviour of a vectoid write. All displacement occurs prior to the pixel modification. For instance, if the current X:Y address is 128:128 (the center of the display), the command is Write Vectoid, and you write 11110101 to the data port, the pixel address is first changed to 127:129, then the pixel at 127:129 is changed to purple.||Up||0||x||1||0|
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
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
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
, Previous Page
. Next Page
This manual was generated with wtfm
wtfm uses aa_macro and SqLite
aa_macro uses python 2.7