# CLASSIC COCO PROGRAMMER INTERVIEW: Chet Simpson # --------------------------------------------------------------------------- Chet Simpson, currently aged 28 and living in Los Angeles, California, is the creator of "Digger II - Return of the Saint". This game is based on the original Apple II game by Broderbund titled "Lode Runner". Digger II takes the original Lode Runner from a single screen per level format and enlarges the play area to extend beyond the boundaries of the screen. Utilizing the CoCo3's hardware scrolling abilities, Digger II is stunningly fast and has contributed to many late nights for me playing the game and admiring Chet's programming. In this interview, Chet talks about the development of Digger II as well as many of his other projects. # INTERVIEW Q: How and when did you become interested in computers? A: This is actually kind of a toss up. I originally got interested in computers sometime in 1983. It's still a little foggy of exactly what caught my eye, but it was somewhere between playing with them at Radio Shack and seeing the movie WarGames. Ever since then, I've been pretty much hooked. I finally got my CoCo on October 23rd of that year and I've had one ever since. Q: What computers have you owned and currently own? A: I started with the original white cased 64k CoCo1. There were only a few of them made and they looked almost identical to the original grey cased CoCo's with the exception of the keyboard. From there I went to the Intel architecture to pursue my programming and work related stuff. I currently have two CoCo3's (one is used for parts and is beyond hope) and a CoCo1. Interestingly enough, the CoCo3 I used for development (the only one I have working) is Rick Adams' old CoCo. Back when I was in Iowa working for Microware, Rick put out a message giving away his CoCo. Eric Crichlow drove up and picked up all the stuff he was letting go and I ended up with the CoCo3, 1/2mb card, 20mb hard drive and a few other goodies. I also have a CDi development system which has a hard drive and ethernet networking capabilities. In the very near future I plan on adding a Motorola MBX system which has a 40mhz PPC860 processor, PCI and ISA slots and runs OS- 9000 and DAVID/MAUI. Q: What was your favourite computer and why? A: By far, my favorite computer is still the CoCo, if only because of how easy it is to programming. Regardless if you program under OS-9 or RS-DOS, you don't have to remember the 1000+ system calls that 'newer' operating systems have. Most people are so used to having everything handed to them they simply cannot fathom what it takes to understand writing your own API or library calls. Spending all night (yes 3am!) banging your head against the perverbial wall because you know you've missed something in that 10000+ lines of assembler code is extremely enjoyable! Q: What programs have you developed? A: RoadRacer (1983) - This was my very first game. You were this little dot on the screen (your race car) and you had to go through 26 levels (all I could fit on a disk) within a certain amount of time in order to win. All of the graphics were drawn with BASIC draw, line and paint commands and saved to disk. I think about 20 people where I lived got a copy of it and most of them enjoyed it. Gold Runner Editor (1986) - This was an editor that I wrote so people could create their own levels in the Gold Runner game by Diecom (written by Dave Dies). This was never released to very many people though. Waterfall Demo (1986) - This was the original waterfall demo that was eventually 'ported' to OS-9 (by Kevin Darling I believe). The actual animation was done through palette cycling and was made possible by the original artist who drew the picture on the AtariST. If I remember correctly, the picture of the waterfall ended up on a cover of Rainbow magazine (one of the graphics issues I believe). SpinDemo (1986) - This was a really neat demo. The artwork was actually raytraced on the AtariST (for the original demo) and then converted over to the CoCo. I actually did updated versions of this and the Waterfall demos to add sound and other effects (fading, night, etc) but never got around to releasing them. GDEdit (year unknown) - This was a small assembler program I wrote to edit the players and saved games in Gates of Delerium which was an Ultima clone. MacPlay (1986) - After seeing that OS-9 users could play Macintosh sound files, I felt the need to write one so that RS-DOS users could also play them. It had a simple menu for loading and changing the playback times, but it ran pretty well. This was the first program I actually sold (and made an even $100 on it). Image Master (1986-1993) - This went through SEVERAL revisions and is currently at v4.1. It was designed to allow people to create game graphics such as backgrounds and sprites and from what I've been told it was actually used for a couple of commercial projects. The unique thing about it was that you could edit a smaller image (say 32 by 32 pixels) instead of doing it in CoCoMax3 or ColorMax Deluxe and having to convert it from a 320x200 screen down to the size you needed. One interesting thing about Image Master is that it uses an enhanced version of the HI-RES adapter routine that is in ColorMax Deluxe. I had been having trouble getting information on one and Greg Miller was gracious enough to let me use the original code until I could write my own. This stayed in until version 2.5 and had to be changed because I needed a more optimized routine to allow 64 colors to be displayed without any flicker on the screen. TuBBS (1987) - I worked on a few portions of the BBS software TuBBS written by Brian Stretch. Most notably, some of the later security features which rendered it useless to break into BASIC. If a ROM was burned this would actually reboot the CoCo and restart the BBS. Studio-29 (1988) - Probably the first full screen animation studio that was ever released for the CoCo. It was actually meant as a companion program for Image Master to allow non-programmers a crack at using it. With it you could create animation sequences up to 400 frames (approx. 20 seconds worth) with each frame made up of 1 of 3 user selectable backgrounds and up to 20 sprites. GBE (1988) - My first game board editor which was another companion for ImageMaster. With this you could create game boards such as those in Digger, Digger II, Super Pitfall, Crystal Cities and other games which had very large play areas. It used a technique called 'Macro Blocking' which can take the same small square image and reproduce it all over the place with only a fraction of the storage space required. You could actually create an image that would normally require 16 megabytes of storage and save it in exactly 128k. Blox (1991?) - This was (I believe) the first game that I actually released to the public. Like most of my programs, it was released as shareware/begware. This was a Tetris clone that I wrote just to see how long it would take me to do on the CoCo. It included the same options and gameplay as the original Ninetendo release (it just didn't look as good). Total time to write and debug it was 5 days. Digger (1991) - This was my first commercial game. One of my all time favorite games is "Load Runner" by Broderbund. There were 4 games on the CoCo I/II that were clones of Load Runner (Gold Runner, Gold Runner 2, Dragon Slayer, and one other I can't remember). I was very disappointed that nobody had ever written this for the CoCo3 to take advantage of the enhanced graphics. After a while, I just got tired of waiting and wrote my own. Originally I was only going to include 40 levels but finally decided upon 80. I also included additional graphics and a few other 'hidden' items which to this day, I don't think anyone has ever found. This one ran full screen on a 128k CoCo3. The only thing I regret doing is not putting in any sound. Maybe I'll disassemble a copy (the original source disk was destroyed) and add it in. 6309Sim (1996) - The only released version of this (which included source) lacks some features but is overall a good simulator to testing 6809 assembler code fragments. BCC/6809 - Port and enhancement of Bruce Evans K&R C Compiler. Adds several fixes and a few features to a great C compiler. Used primarily for rapid prototyping of applications, utilities and assorted routines for CoCo game development. TC/PC (1997) - Utility to decompress TC (The Compressor by John Lauro) compressed archives on the PC. Digger II (1997) - This was my follow up to the original Digger. By taking advantage of a full 512k and other features of the CoCo, I was able to get full screen multi-directional scrolling (something I don't thing ANY CoCo game ever did). Digger II - Return of the Saint In addition to that I have a 1mb 'test' version which also plays 3 voice digital music in the background. Unfortunately, not very many people have 1mb and the one I have blew up (literally) so I wasn't able to finish it. CASM (1997) - In order to allow for quicker development of Digger II, I preferred to do my programming on my PC. This required me to write CASM which is a 6809/6309 cross assembler. I added more features (such as OS-9 support, advanced macros, branch optimization detection) as I went along. Originally this was based on the 6809 assembler released by Motorola but over time all of their code has been replaced and a complete rewrite has been done. Doom - Yes, I said Doom. I've just recently finished porting Doom to OS-9 (PPC, 68k and Intel) with the exception of sound. Right now for 68k, it requires a 68020 or better with a 68040 recommended. I hope to have at least SOMETHING running on an MM/1 or AT306 sometime in the future (probably January). But if I can't get it running fast enough it is doubtful that I will release it. LCC-6809 (ongoing) - While not actually anywhere close to being finished, I felt it should be noted. Over the past year, I've been spending my free time creating a back end (assembly code generator) for LCC which is an ANSI-C compiler. I've got a decent amount done with the code generation and simple optimizations but unfortunately the amount of time I have to work on such projects is limited. Q: Can you tell us a bit about the sound routines that you used in some of your programs? A: The sound routines that I've written range from the very simple (as used in MacPlay) to ones that are a real pain to get working properly. Most notably, the best sound routines that I've written to date allow for up to 6 simultaneous digital instruments to be played at once with very little sound distortion. Unfortunately, because of the CoCo's DAC, it's sometimes very hard to determine just what instrument IS being played. But when moved to something like the Orch- 90 pack it sounds beautiful! With the exception of MacPlay, all of my sound routines are hooked into the 6809's FIRQ line. This means a much better response time when trying to mix items together. I've used two different methods when doing this though. The first one actually does the mixing while in the interrupt, primarily so that it can be done completely in the background and independent of whatever else might be going on (like a game). The other actually just has the FIRQ handler spitting out 'unprocessed' data. When doing this, I have a program that is constantly running that is mixing sound data and filling a continuous buffer. This is what allows for the 6 instruments to be played since I never have to worry about saving and restoring the state of the music player each time a single byte is processed. Q: Tell us about the development of Digger II. A: During the development of Digger II, I had an idea to use 'compiled' sprites. For a while, a lot of PC and Mac games used 'compressed' sprites. These are sprites which are run length encoded so that the transparent parts of the sprite are skipped. This saves a lot of time because you don't have to check each pixel to see if it should be drawn or not (painters algorithm). On the CoCo, we have to deal with packed bytes, ie a single byte contains 2 pixels (upper 4 bits and lower 4 bits), so we usually use a 'mask' byte which tells which parts of the destination we keep to mix with the sprite. I took the approach that if I can skip those areas (usually inside of edges of the sprite) which NEVER get masked, I could save a LOT of CPU time and be able to "blit" more sprites onto the screen. I wrote a small 'compiler' to handle the conversion from 'pixels' to opcodes. It worked pretty well, but it just didn't have the speed I was expecting (it was still fast though). So I went back to the compiler and added a lot of optimizations. Things such as repetitive bytes, working with words (16bits) of data in areas where it was applicable and a few others. One optimization was dealing with the index registers. The Y register was avoided at ALL costs (except for a couple of extreme circumstances that saves 2 cycles!). I even went as far as implementing a primitive form of register/pixel tracking which allowed me to load commonly used data into a register throughout a certain span within the code. This saved a LOT of time and I ended up with some extreme "blit" factor of 3600 to 4000 sprites per second (16x16 and 16x24 mixed in testing). Which averages down to about 120 sprites per frame if you run your game at 30fps. Of course when you add in actual CPU time required to update the display, process input, sound, AI and other misc game stuff, you can still end up with something like 20 or 25 16x16 pixel sprites per frame in the end. The downside to this is that it requires a bit of memory which can range from 1.5 to 4 times the original size of the sprite data. But all in all I still think that the extra memory requirements are definitely worth it. What's even nicer is that the code the compiler generates is position independent so it can be loaded on the fly (one compiled) or used in OS-9. I think the only FIXED variable taken into consideration is the physical width of the display. Q: You used the CoCo3's ability of "hardware scrolling" for the movement of the screen. How did you place the scoring so that it doesn't scroll with the rest of the display? A: Actually, that's an easy one. It's actually just copied onto the screen! After getting all of the graphics routines done and playing it for a while, I found that I had quite a bit of CPU time left (imagine what features could be added to a 6309 ONLY version!) so I played around with a few things. I decided to use it for the score bar instead of the 2 channel digital music, I figured I would save that for a later project when I get it perfected/enhanced. Q: The full title is "Digger II - Return of the Saint". What's the story behind the "Saint"? A: This all came about during a discussion about Orphanware. Eric Crichlow, Terry Simons, myself and several others got into a very heated debate about the distribution and rights of older programs. Eventually, Terry started referring to me as "Chet [The Saint] Simpson". I kind of liked the name and I always liked the old B&W television series so I kind of went along with it. Since Digger II was my first CoCo program in almost 5 years, I figured it was kind of a suitable name. Q: Tell me more about the "challenge" that Eric put before you to prove that Digger could be done better on the CoCo3 than on the MM/1? A: Eric and I have had somewhat of a brotherly rival between us ever since I can remember. One day, for some unknown reason, we got into a debate (as always) about the capabilities of the CoCo. Somehow, Gold Runner 2000 (written for the MM/1) came into the conversation and I had to open my big mouth (ready to put my foot in it again) and state that it could be written on the CoCo3 AND be better. Well, a challenge was laid out (in October or November of 1996) to have it done by the Chicago Fest and of course, me being me, took it with great enthusiasm. I spent probably the next week or so trying to figure out how I was going to approach it, keep it within 512k AND make it run on a standard 6809 CoCo. Other requirements were that it needed to use the original data assets (graphics, sprites, levels, music and sound effects) as the original Gold Runner. This presented somewhat of a problem due to the fact that all of these took up several megs on the MM/1 - so they needed to be compressed. The biggest part was getting the background music to an acceptable size. Each one had to eventually fit into 96k and couldn't take up too much disk space. So using the advantages of having a newer computer, I cleaned them up, resampled them to 8 khz and compressed them. All in all, I got everything down to less than 1mb, including sound. Although the original graphics data was required, I did get Eric to concede to a point that if the same amount of graphics are being moved around the screen, I could use my own graphics. Although the pixels being moved are a little bit less than the MM/1 version, he thought it was acceptable. Unfortunately, that was the easy part and didn't take very much time, but because I no longer had a native editor/assembler on my CoCo, I was unable to do any on it because nobody had one. So I moved all of my development efforts to the PC. I got a hold of some source code to an assembler (the Motorola assembler), made some enhancements for macros, multiple include files and a few bug fixes and was on my way. Creating the rest of the development tools probably took up the majority of the time. This included creating a native 6809 OS for development (the same OS kernel/core is actually a part of the game), graphics converted to take GIF and PCX files and make them into a usable format for the CoCo along with sound compressors and other misc utilities to transfer data to the CoCo. While some might disagree with using a PC to develop CoCo programs, I personally feel that anything that allows you to develop and debug code faster is a worthwhile thing. If I hadn't done it on a PC, it would have taken a LOT longer than it did. My assemble times went from over 5 minutes on the CoCo to less than 5 seconds on the PC - and when you talk about debugging assembler, those small little bugs that require a recompile of the code can take up a tremendous amount of time! While the development process went on, there were a lot of things needed to be written. Loading scenes, startup code, sound code, graphics engine, game engine, and a countless number of other little annoying things that every developer runs into. Even right now there are things which I want to change in it (mostly in the start up code). Anyway, as the deadline approached, I found myself a new job. By this time, Gold Runner 2000/CoCo was actually done, even with a score bar at the bottom of the screen (which Eric complained about needing to be there). Unfortunately, there just wasn't enough time for me to finish it up on a distribution disk and give it to Eric, so technically, I 'lost' the challenge, but I KNOW that I not only met it but created a 'port' of a game from the MM/1 to the CoCo which ran faster and (IMHO) better than the original. It even has cheat codes! Q: What companies did you work for? A: Actually, I've only been working professionally in the computer industry for 4 years. I started my work with a company called ACS and was contracted out to Procter and Gamble in 1994 doing system and network troubleshooting. After a while, I switched contracts (still at ACS) and worked for SquareD writing and maintaining their systems distribution software. After my stint with ACS, I moved on to the infamous Microware in Des Moines, Iowa working in the Testing and then MPEG group of their NewMedia division. I primarily worked on drivers and support modules for various settop boxes for NVOD (near video on demand) settop boxes. After only a year at Microware, I was lured away by Americast here in Los Angeles to work on their settop box software. I handled all of the graphics, animation and electronic programming guide (an interactive version of something like PreVue) 'stuff'. Unfortunately, there were some power struggles between the partners at Americast and almost the entire company was let go (yup, including me) and am now considered unemployed. Currently, I do some contracting to various companies involved in OS-9 and Digital Video (DAVID/MAUI platforms). Q: Can you tell us any interesting "stories" of your past development days? A: There are a few that stick out in my mind, but one single one more than anything... Early in my programming days, somewhere around 1985/86, I was visiting with Bill Vergona (then owner of Cer-Comp in Las Vegas). I had been asking him questions about various programming techniques and he was being a little stiff on giving answers to everything I asked him. Then all of a sudden, he pops out with "nothing you write will ever be as good as my software" or at least something to that effect. What was even more interesting was that in almost the same breath he also said that "nobody will ever be able to crack the protection scheme I use." Well, I never quite forgot about that. So a little while after he had made those comments, I had a friend of mine back east mail me his disks of programs that Bill had written (CBasic, EDT/ASM 64) and pulled my stuff I had bought from him. I sat down for a few hours and after a while had removed the protection from every single one of his programs. So, being the obnoxious kid I was, I just had to call him up and tell him about it. Needless to say, he was fuming. What was more interesting was that a few months later, a letter from him appeared in Rainbow talking about pirated copies of his software, much of which was blown out of proportion. NOTE: The software was legally obtained and were purchased from Cer-Comp. They were returned to the original owner at a later date. No copies of the cracked software were ever distributed. Those copies which were 'cracked' by 'RamMan' were not obtained from me nor anyone else in this story]. I've also got another story... In 1991, All 3 members of Hyper-Tech (Eric Crichlow, Mike Haaland and myself) were able to all attend the same Rainbowfest (April 1991 in Chicaco). This was either the second or third fest I attended in Chicago. Unfortunately, Eric was flying out of Pheonix (where he was attending college) and Mike, myself and a good friend of mine Tina were flying out of Vegas. When we arrived in Chicago, we met Curtis Boyle and a couple of his friends. The rest of the day was the normal Fest going stuff. Booths, visits, meeting people I hadn't seen in a while and some I had never met before. After the normal festivities, we all ventured across the street to a nice little eating joint and talked. All in all, we had a pretty good time and both Tina and Curtis kept in touch and eventually got married a couple of years later. She moved up to Canada with him and they're as happy as can be. So you can attribute at least one marriage happening because of a RainbowFest. Q: Are you still developing for the CoCo and why? A: Unfortunately, not actively. This probably doesn't come as a surprise to anyone, but it's for very different reasons that most people think. Simply, I just don't have very much free time on my hands anymore. Although I do revisit certain ongoing projects from time to time, I'm just too busy with work related things to have a chance to get anything worthwhile done. Q: Whatever happened to that Mario-like game you had announced after completing Digger II? A: I still have the initial work, but unfortunately, due to time constraints, it's on the shelf. Interestingly, it was originally going to be based on the Digger II/Gold Runner 2000 engine, but I scrapped the idea when I decided I wanted to have more capabilities available. The engine specs required an entire reworking of SCOS (Small Computer OS - used by Digger/GR2k) and a new approach to the interface of the engine. I still intend on finishing it someday, and I will when I have a little more time on my hands. Q: What are some of your favourite CoCo products of all time? A: That's a hard one. One of them is the Rascan digitizer. I always liked the thought of being able to digitize color pictures on my CoCo. Unfortunately, I never bought one because I could never get any information on programming it so I could write my own interface software for it. Some of my all time favorite games are actually some of the early ones like Buzzard Bait, Donkey King, Sailor Man, Time Bandit, Galaga, Lunar Rover Patrol and especially Cashman. A lot of time was spent making these games as close as possible to the arcade versions and a lot of time was done to get the graphics just right. But my all time favorite is actually a tie: CashMan and Shock Trooper (by Rob Shaw). Q: What is your opinion on Software Piracy? A: You're just looking to open up a can of worms aren't you?! I think it's wrong. I have no problems with making an attempt to preserve and save software with multiple working copies so we ensure they are never lost. Personally I'd like to see the CoCo Preservation Society take on this task. People, including myself will rant and rave to the end of time about it, but it's not so much as the act of making copies of software that is the real kicker, it's more of the attitude of SOME people who have an attitude about it. If it wasn't for that I probably wouldn't have much of a problem with it. Q: What is your opinion of the CoCo2 and CoCo3 hardware platform? A: For tinkering and the hobbiest, it's a great thing to have since you can interface it to just about anything! But...I'd like to see it expanded - drastically, It's nice that now we have an IDE controller because that gives us access to CD-ROM's, easily available and BIG hard drives and removable media. But I don't think it's enough. Personally, I'd like to see some type of backplane or expansion bus similar to the MultiPak which allows you to plug in 16bit ISA cards such as IDE controllers, SCSI cards and especially graphics and sound cards. It would be a real hoot to be able to play sound effects with FM synthesized music and hardware accelerated graphics going on. One thing that I've always considered would have been a great benefit to the CoCo would have been a special graphics chip to handle tiled displays with sprites - perfect for games. I've been thinking about picking up a few old Ninetendo systems and plucking the graphics chips out of them and attaching them to my CoCo. Q: When the CoCo3 was released, how did you feel once you learned of it's extra features? A: I had a lot of mixed feelings about it. On one hand, I thought they were a great upgrade to the CoCo2. Especially having an 80 column display and 16 color graphics. But I also felt that it was too little too late since even the closest '8bit' rival (Apple 2gs) was much better. Q: Do you feel the CoCo3 software market to have been "stagnant" compared to the CoCo1/2 era? A: Yes. Back in 1983/84/85, I always looked forward to a new issue of Rainbow because there were always new things coming out. But between 1986 and 1990, that simply wasn't the case. You could go 3 or 4 months sometimes (even in 1986 and 1987) without having a new CoCo3 program out. And as time went on and support for the CoCo2 dwindled, the CoCo3 market was starting to lose it's steam and just never quite caught up to the potential it could have. This was probably due to the fact that programming things on the CoCo3 and taking advantage of it's new features requires a lot of new tricks to come into use. While information was widely available, people just weren't trying/wanting to learn new tricks to write software. Most figured that if they're going to learn something new, they might as well go to another computer with a newer processor (such as the AtariST or Amiga). If you look at the market and the ads, 1990 seemed like a cut-off point. Those games and products that WERE coming at the time took full advantage of the CoCo3. Games like Crystal City, Contras, and other Sundog games all required 512k and did an amazing job at using the 'virtual screens' for hardware scrolling. Unfortunatly, it was too late and we had lost too many good people to the 'other side' as some like to call it. Q: If you were asked by "Mr.Tandy" to create a CoCo4, what would you include? A: Dual processors - and not just the 6809. I'd like to see a "CoCo 4" with a much updated architecture. The AT306 was a great effort, but the CPU just isn't up to snuff. Something like a PPC system with a PCI 6809 add in board (with it's own memory and slot for the GIME) would be exceptional. 3 areas that are deep to be changed is the processor speed (not specifically the processor), graphics and sound. If you can change all of these, you add a LOT more potential to the types of software that can be written. This is one of the reasons why I'm getting the Motorola MBX board. It's got a 40mhz PPC in it with 1 PCI and 1 ISA slot along with ethernet, serial, parallel, EIDE, floppy, mouse port, keyboard port, Infrared port handles up to 128mb of RAM and has 2 or 4mb of flash (depends on the version). Starting at $750 (depends on options). There are 4 OS's supporting it, including OS-9 and this is one of the boards targeted by LinuxPPC. To me this is the CoCo 4. Q: Have you any "words of wisdom" to pass on to any budding CoCo programmers? A: Don't plan on ever sleeping again, it just won't happen. The best advice I can give is to just try the little things first - you'll be amazed at what you can do a lot sooner if you don't just jump into something. If you're just starting to learn assembler or want to learn it, get a good book (I recommend the one by William Barder Jr.) and follow it from start to finish. Planning and design make a wonderful combination, especially with the CoCo. Knowing ahead of time what limitations you have to overcome can make things a lot easier to deal with. If you're writing a game or any graphics applications (RS-DOS or OS-9) plan your memory usage ahead of time. Knowing where you're going to place certain key components and how much space they take will save you a lot of headaches. This is one of the primary reasons I was able to get Digger II done in such a short time - I didn't have to change the design once I started writing code. # --------------------------------------------------------------------------- Interview copyright by Nickolas Marentes - October 17, 1998.