This line contains initial write-up information, COMPUTE! Magazine scans, and original program from 1988.
"Tiles" is a program which appeared in COMPUTE! Magazine, Volume 10, Number 2, Issue 93, February 1988, Pages 30-46. The program was originally written by Rick Harrison, with versions for the Commodore 64, Apple ][, Atari 8-bit, IBM PCjr, Amiga, and Atari ST. The Texas Instruments conversion is based upon the game description in the article. The graphics are based upon the Atari ST version, with the screen layout matched as closely to the original versions as possible.
After COMPUTE! dropped the TI-99/4A, I obtained permission from ABC Publications and COMPUTE! Magazine to produce and distribute my TI-99 conversions of programs which appeared in the magazine. "Tiles" is one of these conversions.
As a budding programmer, I wrote this conversion back in 1988, and last year I was able to decode the original RadioShack T-10 cassette which holds the "final" version of the program.
It is atrocious. I mean, it works, but, Dear God, the code is horrendous.
So, starting in October 2010, I have been reprogramming the game. I have re-used a ton of the original elements, re-worked the screen layout, added a few things, and completely scrapped the main game loop.
I am not ready to present any work just yet, and I shudder at the prospect of showing the original code before I have the final product ready for comparison. I would, however, like some thoughts on a chunk of code over which I am currently agonizing.
The routine is to return a value of J based upon the directional keys within a split keyboard scan, fire button (or associated key,) joystick position, as well as a few other keys:
The problem is the sharing of certain keys by the two different key-scan modes which will be used. For instance, while FCTN keys are not returned, the non-FCTN part of the key is detected. I try to account for that in my code. Fortunately, there are no value overlaps between what I want from each key scan. For instance, AID is 1 in unit 3 but 1 in units 1 and 2 is unused, E/X/S/D from units 1 and 2 are 0, 2, 3, and 5 (not respectively) which do not overlap with REDO and BACK, etc.
I attempt to overcome key scan disparities while retaining performance and catch the key before the user releases it by jumping from one CALL KEY to the next as quickly as possible.
Below is the code, followed by pseudo-code narrative. I also left line 1450 in place in a REM just to show some of the numerical technique I have attempted to use. Unfortunately, this formula also returned phantom values for A and W in unit 1 and H and U in unit 2. It also had other shortcomings which I resolved by using a simple POS() comparison.
I would appreciate any thoughts on what I have here.
(Quick note, I never used the original listings to write my conversions. I just read the program descriptions and starting banging out code of my own. I felt that reading others' work would somehow "corrupt" my creative process. hehehe)