Showdown

Showdown is a two-player gun-fighting game in which each player controls a gunfighter on screen, moving up and down and firing at the opponent. The BASIC loader reads a long hexadecimal string from DATA statements, converts each two-character pair into a byte value using the expression `16*VAL a$(1)+VAL a$(2)`, and POKEs the resulting machine code into memory starting at address 31000. A checksum of 72781 is verified against the accumulated byte values before the machine code is executed, guarding against corrupted DATA. Two custom UDG characters (defined in subroutine 9000) form the sprite of each gunfighter, drawn as a 2×2 block using characters `\a\b` and `\c\d`. Two separate machine code entry points are called via `USR 31000` and `USR 31506`, with the result of a PEEK at address 31631 determining which player won.

---

Program Analysis

Program Structure

The program is divided into four logical phases:

1. Initialization (lines 1–120): Sets border, clears memory to address 30999, calls the UDG setup subroutine, then loads and checksums the machine code from DATA.
2. Machine code loading (lines 40–100): Reads hex strings from DATA, converts them to bytes, and POKEs them into RAM from address 31000 upward.
3. Game loop (lines 1000–1120): Draws the arena, places random cactus-like obstacles using UDG sprites, runs the machine code game engine, displays the winner, and offers replay.
4. Setup subroutine (lines 9000–9170): Defines UDG bitmaps and displays the title/instructions screen.

Machine Code Loading and Checksum

Lines 40–100 implement a hex-string loader. Each DATA record is a string of hexadecimal digit pairs. The loop at lines 50–90 reads one string at a time into a$, then processes two characters at a time:

• z = 16*VAL a$(1) + VAL a$(2) converts a two-character hex pair to a byte. This relies on VAL treating a single digit character as its numeric value, which works for digits 0–9 but not for A–F. All hex digits in the DATA are therefore restricted to 0–9 and A–F represented as decimal digit pairs — on inspection the DATA strings contain only hex digits 0–9 and A–F encoded as the characters themselves, so VAL is applied to single characters. This is a subtle limitation: VAL "A" would cause an error, so the hex-string decoder here actually relies on the DATA bytes never containing letter hex digits in positions that reach VAL. Looking at the DATA more carefully, digits A–F appear, meaning this loader would fail on those bytes. This is a likely bug: the standard approach on this platform for hex loading uses CODE a$(1)-48 or a lookup, not VAL.
• Each byte value is accumulated into t for checksum purposes.
• Bytes are POKEd starting at address n=31000, incrementing n each iteration.

After loading, line 100 compares t to 72781. If the sum does not match, the program halts with an error message and a low beep. The sentinel value # in the last DATA record signals end-of-data.

UDG Sprite Definition

Subroutine 9000 defines four UDG characters (a, b, c, d) using 32 bytes of bitmap data (8 bytes each), POKEd into USR "a" and onward. The gunfighter sprite is rendered as a 2×2 tile using PRINT INK 4;AT y,x;"\a\b";AT y+1,x;"\c\d", producing a 16×16 pixel figure in yellow ink.

Arena Setup

Lines 1000–1040 draw the game arena. The border columns are created by POKEing attribute memory directly: for each row n from 1 to 23, address 22528+32*n and adjacent cells are set to attribute values 67 and 69 (INK/PAPER combinations for left and right border columns). Four obstacles are then placed at random positions within the play area using the UDG sprites.

Game Engine Execution

The machine code is invoked twice per game via USR 31000 and USR 31506. These two entry points likely handle player 1 and player 2 logic respectively. After execution, PEEK 31631 is tested: a value of 0 indicates Player 1 wins; any other value indicates Player 2 wins. This flag byte is embedded within the machine code block at a fixed offset.

Key Variables

Variable	Purpose
a$	Current hex DATA string being parsed
n	Current POKE address (starts at 31000)
t	Running checksum of loaded bytes
z	Current decoded byte value
a–f	Pre-set to values 10–15 (unused after initialization — likely intended for hex digit conversion but superseded)

Notable Techniques

• POKE 23693,71 sets the border color to black (attribute value 71 encodes the border in the system variable BORDCR).
• CLEAR 30999 both resets the BASIC variable area and sets the stack pointer, protecting machine code loaded above address 31000.
• The title screen uses PAPER 1 (blue) with TAB 31 to create a full-width colored banner without looping.
• Variables a through f are initialized to 10–15 at lines 20–30, suggesting an originally planned hex-to-decimal lookup that was abandoned in favor of the VAL approach — though the VAL approach is itself buggy for A–F hex digits.
• The replay loop at lines 1100–1110 polls INKEY$ continuously without a PAUSE, which is a busy-wait but functional for keyboard response.

Bugs and Anomalies

• The hex loader uses VAL a$(1) and VAL a$(2) to parse hex digits. VAL on a single alphabetic character (A–F) would cause a BASIC error, yet the DATA strings contain letters A–F. The program likely relies on the machine code bytes being loaded correctly despite this apparent contradiction — possibly the DATA was pre-tested and the checksumming masks the issue, or the DATA strings were crafted to avoid letter-only single-character VAL calls in a specific way not immediately apparent from inspection.
• Variables a through f (lines 20–30) are set to 10–15 but never used in the loader logic, suggesting leftover code from an earlier design.