The initial version was an experiment with Rowan’s BASIC game, which I attempted to enhance by compiling it using PetSpeed and RTL-Basic. Unfortunately, both approaches failed; the compilers either crashed or produced non-functional output.
During this process, I discovered an intriguing issue: it appears that none of the PetSpeed versions for the PET function properly in emulated environments. Each compiler I tested resulted in a disk error when I attempted to write the compiled file. Further investigation revealed that nearly all PetSpeed compilers on Zimmers.net still enforce dongle protection at memory address $14AD.
Amidst these challenges, I also began working on a different project: a PET adaptation of Berzerk. I successfully created a maze generator that utilized a seed value, allowing for consistent yet random mazes upon revisiting. However, as I contemplated programming the movement and firing logic of the enemies, the scope of the project became daunting.
At that point, I decided to take the easier and more enjoyable route: I would create a PET version of Qix from scratch—entirely in machine language.
As with all my projects, I started by drawing a border around the screen and setting up the display. From there, I added the enemy sparks that would move along the border in opposing patterns.
Flood Fill
The next major challenge was developing the flood-fill routine. Initially, I struggled to determine how to identify the inside of the polygon for filling. After a few days of confusion, I learned that most versions of this game filled the opposite area of the screen, but I wanted to avoid using temporary characters during this process. My solution was to fill the outer area of the lines with a shifted-space, making it invisible. This allowed me to then flood-fill the actual spaces (character #32).
My first attempts at flood-filling were partially successful, but I encountered an issue where creating L-shaped lines would cause the fill to stop at the right of the line. The problem stemmed from utilizing a stack with values exceeding 255. Given that each screen location required both X and Y values, the stack would overflow after 128 characters.
Eventually, I adjusted the stack to utilize zero page, permitting a 16-bit stack, which resolved the issue perfectly.
Trailblazing
Next up was the most intricate challenge, paradoxically one of the simplest coding tasks. I needed to move the player through the borders effortlessly, while initiating drawing upon entering the inner screen area. To manage this, I had to track the last movement direction; a 90-degree turn from the north differed from a turn from the south. I spent several hours utilizing ChatGPT to overcome the hurdles.
The trail functioned well if I used the same character repeatedly (which was dull). However, attempting to implement the full PETSCII set resulted in the character being drawn one position too late. ChatGPT understood my dilemma and generated a table of values for each of the four directions. Nonetheless, my code faced multiple failures.
I decided to take a break, returning fresh the next day. I wiped my current code and began the drawing routine anew. Surprisingly, it took me about six hours to get the line drawing right; one might expect the flood fill would have been more time-consuming, but that wasn’t the case.
After some trial and error, I finally got the trail functioning correctly. I was thrilled to have conquered this challenging task.
The Qix
The Qix itself proved to be the most complex aspect of the game. I searched for any available 8-bit versions that might aid my efforts but found none. The C64 iterations of the Taito game were particularly hard to decipher. I spent time with ChatGPT (which might be seen as cheating) for coding assistance, but it often led to frustration. Ultimately, I returned to my usual approach—writing it from scratch.
It was then that I discovered Claude AI, which proved invaluable in identifying bugs in my code. My initial Qix was represented by a single character.
I requested Claude to implement a trail for the Qix, and it provided a line drawing routine. I envisioned the Qix tracing actual lines in the 80×50 mode but struggled with how to manipulate the other end of the line to replicate the movement from the original game. Although I could have used a sinus maker, that would create a predictable pattern.
After a night’s work, I successfully got the Qix functioning. Claude AI assisted me in emulating the arcade game’s dynamics, including sudden accelerations and area navigation. Remarkably, it achieved this flawlessly on the first attempt within C64Studio. However, this was a one-off occurrence; Claude AI often exceeded 127 bytes with relative branches and repetitively reused labels, which C64 Studio does not tolerate.
You may question whether using AI constitutes genuine programming. Without this assistance, completing the game—or at least making it challenging—would have been far more difficult. However, the rest of the game’s content is entirely my creation.
Sadly, the game’s difficulty might not be adequately challenging, as the sparks only move along the border. I spent four days and countless hours trying to allow the sparks to enter the playfield and traverse the lines. Despite receiving tips from ChatGPT, Claude, and Google Gemini, I ultimately decided to abandon the attempt. While the game may present enough challenge for younger players, it may fall short for more experienced gamers.
I am currently halfway through adapting it for the 80-column PET, which will provide a gameplay experience closer to the original. The 40-column screen is insufficient for a PETSCII version. Should anyone possess expertise in A* pathfinding to allow the sparks to chase the player, I’m happy to share the source code. The player and sparks are defined by their X and Y coordinates.
The project includes a C64 prototype, as the game was initially developed for the C64 before being ported.
Until the next update…
Download
https://milasoft64.itch.io/qixie
Original article by www.commodore.ca
