Chapter 22 - May 27th, 2015

House keeping duties

This instalment of the PopStar Pilot blog takes a break from program development to devote some time to some house keeping duties. And I don’t mean vacuum the floors and dust the shelves!

After an intense period of development, code can get a little untidy and in need for some re-organization. Sections may need to be properly commented, blocks of code may need to be spaced out to make them clearer and documentation may need revision and updating.

Failure to keep these tasks in check can lead to confusion and make the task of coding more difficult as we progress deeper into the game. It’s a busy and necessary process that needs to be done religiously in order to stay on track.

I have been maintaining documentation of memory maps , compression data and graphic design since the start as well as keeping this blog up to date. This blog is an important step towards my goal of documenting the development process.


The recurring question

Over the time, people have asked me for more technical details of code and algorithyms and just recently this message was posted asking for more information. I have included a short edited transcript below.


One thing I was wondering - while you do at times go into some brief specifics on the techniques and algorithms used in your development efforts, you don't delve into them too deeply. Were you planning on elaborating on these at a future date, after you finished development of the game?


One of the things that has frustrated me (mostly in the past) is the dearth of coding techniques, algorithms, and code for the CoCo 3 - especially when it comes to the more advanced topics (scrolling, sprites, music generation using interrupts, etc). There's always hints, but few and far between has there been full explanations, which could help others. It seems like everyone re-invents the wheel instead.



Good point but I have no plans to go into more technical detail than what I have.


This blog is about documenting the game design aspects of PopStar Pilot. It’s not meant to teach the workings of the CoCo3’s GIME chip or go into detail about coding techniques although I do cover minor aspects of them every so often.


It’s important to understand the design, obstacles and creative philosophy behind such a venture. I look back at when I was creating my first assembly language game back in the early 80’s on my then TRS-80 Model 1.  Back then, I didn’t have any information on code techniques or access to such resources. I found the best way was to jump in and start building a game from the ground up, working it out as I went.


But I didn’t start with assembly language. I began writing games in BASIC and with this experience, I gained an understanding of what the basic elements of a game were and got a feel for the capabilities of the system.


Then, as my skills improved, I found that BASIC was too slow for the type of arcade games I wanted to create and so began learning Z-80 assembly language.


Assembly Language was like someone disengaging the handbrake and unleashing the 1.77 Mhz beast within!


Of course, I didn’t get it right the first time and my first project reached a point where I had learned better (or proper!) ways to do the same things. The first failure led to the second failure but in reality, each failure was actually a win because each time I learned so much more until I finally released a complete game. Cosmic Bomber for the TRS-80 Model 1 was my first completed assembly language game but I was to find that there was much more for me to learn.



My first completed assembly language game for the TRS-80 Model 1,  Cosmic Bomber - 1982.

It proved to be a valuable lesson in data backup and data integrity.


Cosmic Bomber is the only game I created where I have lost all the code and even the final binaries. Even today I don’t understand how I managed to lose the files but it taught me a good lesson on the value of staying organised, documenting everything and maintaining working backups.


So to get back to the question asked..


I never found it necessary to have all the answers provided to me on a plate, preferring to work it out based on my knowledge of the computer's architecture. Engineering the product myself also gave me a better understanding of how games are built and how to create solutions and workarounds for many of the obstacles I encountered.


I recommend reading the manuals and documentation and then formulate a solution or algorithym to suit your particular requirement. I don’t have a set piece of code to do a specific function such as double buffering, creating software sprites or generating sound. Each project has a unique set of requirements and I create customised code optimised for that specific requirement. Each project had it's own set of unique challenges.


For example, the double buffering routines in PopStar Pilot are different to those I used in PacMan Tribute which are different again to those I created for Rupert Rythym. Likewise, my sound routines have evolved with every project. I first started using interrupts in Space Intruders to control the laser base and then realised that interrupts were useful for sound generation and implemented interrupt driven sound in Rupert Rythym. In Cosmic Ambush, I learned how to improve those routines to generate two channels of interrupt driven audio. In PopStar Pilot, I have taken it a step further again to include split screen scrolling and Amiga’like raster bar effects in the same routine.


How do I explain this evolution of ideas to someone who is starting out? It would take a well written book to explain it properly and completely.


Where to start


BASIC is good but it can only go so far. As far as arcade game goes, you may need to add some additional support using assembly language subroutines. Better still, for maximum speed and no barriers, why not go full hog and get into assembly language. Then again, that's my opinion. Depending on your expectations, OS-9 may provide other languages and options.


My advice to anyone starting out with assembly language is to firstly learn and understand the language. On the CoCo, this means reading up on the 6809 CPU, understand how it talks and how to instruct it to do what you want. It's just like learning BASIC except much simpler. Yes simpler! Assembly Language instructions do so much less than a BASIC command but that’s why it’s more tedious to learn. Perseverance is mandatory else you won’t get anywhere.


Second, learn the system I/O (input/output), read the memory maps, understand what each register does because it’s this I/O that opens the CPU to the outside world. If the CPU is the brain, the I/O is it's arms and legs. Learn how they operate and you're ready to tackle almost anything using your ingenuity, creativity and some logical thinking to realise whatever ideas you devise.


The biggest problem you will have is finding enough free time.   :(


But wait, there's more!


For those who would like to read more CoCo development blogs, I highly recommend the ever informative blogs by the creator of Fahrfall, John Linville. Check out the links below and happy reading!



                                  Next Chapter

Copyright 2013 by Nickolas Marentes