Epyx 1987-1990


The Apple-II computer had pretty much out lived its usefulness for me. Except now, I was being hired for my forté, debugging other’s code. Epyx hired me as a consultant to work on the Amiga/Lynx project for Atari. I was a little apprehensive from my past dealings with Atari, but I took the job anyway. I never got paid and the Lynx handheld vanished into the sunset.

I was then changed over to working on Sporting News Baseball. Of any program I debugged, this was the worst. Every year, Sporting News, imported new baseball stats for all of the players in the league. That was cool, but what the programmer did was call for too many random numbers sequentially in the execution of the game. This reduced the “stats” to white noise. None of the stats matched the players. For example, the player that lead the league in triples, never hit a single one. What I had to do is find all of these calls and rewrite the code to use just ONE call per game loop. Example: If a player had a 40% chance of getting a hit, then I had the other 60% to use for another calculation like what kind of hit, single, double, triple or Home Run based on his stats. I rewrote the code to allow the stats to have a higher weighting and the games between teams now matched real life outcomes. Another example of too much of a good thing can be bad for the program.

Another task was to debug Epyx’s Sprite Engine that they used for all of their Apple-II games. “Its not working correctly.” This was about 16K of very tight and complex code. I finally tracked it down to a processor flag that was not being handled properly. There is one thing that I have only done on rare occasions, print a listing of the code. I regularly have at least 3,000 lines of code in any game I create or debug. To save paper, I use a notepad to write down key status flags at given points. That is how I found the Sprite Engine bug.

I had done a lot of sound work on the Apple-II one-bit speaker. They had a 3 voice sound driver that sounded okay using two voices. Three voices came out of tune and sour. What is more fun than tracking down a processor flag? Counting cycles, of course. For music to sound good the cycle times must be exact! More debugging, they had not counted the cycles correctly. Cycle timing changes if an instruction crosses a page boundary, they missed several of those. Soon I had a working, in tune, 3 voice sound, but I wanted more. I used the Sequencing Software concepts, I had learned from working for Passport Designs, and added a 4th voice for drums or rhythm. The Drums became the filler for rests or other openings in playing the 3 voices. MusicPlus was born!


Epyx asked me if I would be interested in doing some Atari 2600 work. Here we go again. But this time I _did_ get paid. I worked on Winter, Summer and California Games for the 2600. Wow. Now we are talking strange programming. The 2600 draws to the TV screen a line at a time with each line taking exactly 76 cycles. If you crossed into 77 cycles the screen would tear and stretch out past the bottom. I found out that you could use code for data. Halfpipe took advantage of that, but its the ONLY known code that did NOT tear the screen using 77 cycles for a frame or two. Why? No answer, it just works. I coded Halfpipe, Speed skating, Rowing, Biathlon Shooting, the wave for Surfing, and the sound generator used for the series.

I had made my own sprite generator on the Apple-II for 2600 objects. This allowed me to easily make animation sequences I needed for the Halfpipe and other objects. It still amazes me how a 87 byte sound generator could have so many functions. Thanks to my work at Passport Designs, I was the man for the job. I did the sound effects and music for the Epyx Game series. But, alas, Atari was already on the downhill slope and picking up speed. I needed something new to do.

Next Chapter > Decision Development Corporation 1990-1993 Top