How Repetition 64 was formed

 28th April 2025

During the winter of 2025, I had some time spare in the evenings to participate in the "Simon Basic" game jam run by Phaze101 and Retro Programmers Inside. The idea of the game was to create and develop a game suited for a retro computer or console which resembles the old classic type-in game "Simon Says". We know there were popular toys in the 1980s and 1990s called "Simon Says" or "Einstein". Let me explain more about the theory of the game.

"Simon Says" is a simple game, where you watch a sequence of lights (and listen to the sounds) played by the computer. After listening to the sound, your task is to repeat the sequence of the lights/sounds in the correct order. If you successfully completed the sequence you move on to the next round, where an extra light/sound is played. The game keeps playing on until you select a wrong note/light.

Well, being that I did not make anything for a very long time for the game Jam, due to either 1. the production idea was too difficult, 2. I didn't have enough time available and was very busy on another project. I decided to create my own entry for the game jam. There was a rule though. "The game must use any form of BASIC". I was allowed to use machine code, as long as I keep it minimal. The game that came to light was "Repetition 64".

A rough start

When I started working on "Repetition 64". The first thing I wanted to do was work on the basics of the game. I needed to have some sprites to prepare the buttons. I booted up CBMPRGStudio V4.5.0 to create sprites for the game project using the sprite editor. It was simply a square. Then afterwards, I exported the square sprite as pBASIC data. (pBASIC is an BASIC interpreter that uses labels rather than numbers, then after compiling, generates the listing using numbers. I hated working with line numbers, because I easily got myself lost. pBASIC on the other hand made life much easier).  Since a whole sprite consists of 64 sprites ($00-$3f) I needed to work out where to POKE the sprite data. So I POKE the data to $2000-$203f. (8192-8255). This was only for the first part of the project.

A touch of randomness

The next thing I had to do was think "how am I able to make the computer be able to play the notes at random?". This idea was fun, but I got round to a simple solution. It was to generate a for/next loop which generated a random set of numbers between 1 and 4 (using dice simulation RND functions) and then POKE the random number table TO $c000-$c0ff (49152 to 49407) inside the loop as 256 bytes in memory. 

Getting the computer to play the notes

The first thing I did was used CBMPRGStudio's built in SID editor to prepare the chords for each of the notes for the game. After I was happy with those, I exported them as GOSUB labels ready for the game to be able to play them. Of course I also had to create a loop that completely initialised the sounds.

The easy part was preparing the random numbers into memory (49152), the hardest part was getting the computer to play the random sequences. Apparently not, it wasn't that hard to be honest. All I had to do was create another for/next loop and PEEK each number from the random number sequence table. Then afterwards I checked if a marked variable matches the number of the random number, and then jump to a subroutine in the listing to play the correct colour and note. 

Getting the player to play the notes

A similar trick to computer playing the notes was made to get the player to play the notes and light up the correct squares. However, there was one trick I had to do to solve this trick and that was of course check if a wrong note was being played. If the variable stored from the player was played incorrectly then the program jumps to a subroutine that process a fail sound and then deducts one life from the player. Then loop to the computer playing the same sequence again. If the player got the sequence correct, then the level variable increments by one, and adds one extra sequence to the sequence play/read loop. The program can play a maximum of 255 sequences, but I highly doubt the player can do that.

Scoring and bonus

I made this game allow add 150 to the score variable for a correct note played, and if a whole sequence was completed, I added 1,000 points to the score variable. Also after eight levels were completed, I added an extra life to the lives variable.

Adding skill levels.

Having one skill level during game play was pretty much boring. I already had one slow speed set for an easy game. So, I created a variable set as a skill level, which was set if F1, F3, F5 or F7 was pressed. F1 set up the easy skill level, F3 set up normal, F5 set up hard and F7 set up the totally difficult setting. The skill levels were based on the speed of the playing time for each of the notes. After play testing through these in the main BASIC program, I was very pleased with what I did, I decided to work on presentation.

Presentation and music

I wanted to make Repetition 64 more presentable. This was so that the game focused more on the quality design, than being just a standard basic game with a plain black screen and 4 sprites with four colours. While designing the graphics, the custom made character sets and screens were designed first using Charpad V2.7.6 free edition. Then afterwards I started a new character set project in CBMPRGStudio and imported the graphics font and other data into memory. The reason being was because Charpad only allows limited attributes. I wanted to use both colour and screen RAM based on custom colour data, rather than character sets. After importing the character set and re-colouring the character screen for both the title screen and game screen. I exported both screen data and colour RAM as PETSCII graphics and exported the character set as BASIC into the project. After generating the whole BASIC program, I came across a snag, where the screen and colour data did not display in the correct row, and also the sprite data overlapped the BASIC listing also. 

I needed to solve this problem, quick and fast before running out of time. The solution was to keep the BASIC listing, but instead of using DATA statements and PETSCII screen layout listings, I decided to rely on creating some limited machine code. This had to be done for the sprites and the screen display. Also I wanted to add an interrupt to the title screen so that it can scroll text across the screen and also play some music I made in Goat Tracker Ultra V1.5.5. So I created some small routines to create an IRQ raster interrupt with scroll text and play music. To finish off, I tested the IRQs, screen display routines, etc (outside the BASIC listing) and used a M/C monitor on the Action Replay to convert the hexadecimal addresses to decimal SYS addresses. Then afterwards, I put the SYS addresses into the BASIC listing.

Making the Music

I had an old tune which was already released on the title screen. Since there was still a little bit of time, I decided to make some music exclusively for this game. This was made using Goat Tracker Ultra V1.5.5. The music had some 80s space disco sort of feeling, also featured echo lead sounds to definitely give out a space kind of effect. I feel that this could be one of my best tunes by far this year - but could I beat that in my next game C64 project later on this year? We will have to wait and see.

Putting the game together

So, then you may wonder how did this game get put together? Well, the rule for the competition was that the game MUST have a BASIC dialect and should also be runnable from BASIC. I followed that rule. However, putting the game together required two different builds. The first part was compiling the pBASIC listing into C64 BASIC (using CBMPRGStudio). Then afterwards, add an import binary command of the actual BASIC listing along with the machine code program, charset, sprites, the two screens and music (with a safety offset of two). This resulted to 116 blocks file size.

The finished release

I did two versions of the game. The first was the game jam version (The 116 blocks release), where everything remained uncrunched and was runnable from BASIC. The other version (featured on TND's itch.io page) features exactly the same game, but instead, the game was crunched the good old Public Domain tool, Time Cruncher V5.0 from 1988. I used the BASIC run (JMP $A659) command and $37 as $01 to set the BASIC listing to run the program after decrunching from memory. Finally I put the TND presentation linker on to the game, crunched again with Exomizer and everything was running nicely. The reason for why Exomizer's Exo BASIC wasn't used was because it wasn't compatible with the tape loader I used for the TAP version and crunched with TC V5, worked fine for me.

So how did the project turn out.

Development of Repetition 64 lasted a while, during the cold awful winter and the project went really well. If there were improvements made to this game, I probably would have added scrolling character graphics, like I did with a few of my games, add a custom option where you could play in cross mode as well as square. I probably would have moved the sprites around to increase more craziness for the player who plays it, but that could be "Rotor Repeat" later on this year, in order to mark the 25th anniversary since my first ever C64 release in September 1995 (Update: 11/01/2026 - Unfortunately Rotor Repeat did not happen, but I can confirm that the game idea is not cancelled.). However, I was developing towards a deadline, and decided to keep it pure and simple, but presentable at the end.

Where to get the game

The game was created specially for Retro Programmers Inside and Phaze101, but I have not supplied the whole project code publicly yet, in respect to the game jam rules. However, after the game jam has finished broadcasting, I have now uploaded the entire project onto my github page publiclyso that you can load it into CBMPRGStudio. You can find the code here:

https://github.com/RichardTND/Repetition64

You can download the Repetition 64 from my itch.io page which is via this link below:

https://richard-tnd.itch.io/repetition64

 

2022 Reflections

It is that time, and for the very first time I thought it would be nice to reflect about the game-related releases of 2022, which I made. Warning – this is a very long post, but hopefully you should enjoy it and you may get some laughs out of it.

No SEUCK Compo in 2022

First of all, unlike previous years I did not launch the traditional Official C64 SEUCK Competition, this is because I decided to retire as host from the competition. A new organizer was found, and there was going to be one at the fall of 2022 but due to busy schedules and other reasons, the competition has been postponed to 2023. Merman is a good C64 enthusiast and a writer for Scene World and also runs the SEUCK Vault. He has been appointed as future host for the SEUCK Game development competition. When that will be we don't know, but if anything does happen then I'll post news about it on my TND web site.

SEUCK Enhancements

Looking back in 2022, I started the new year with a utility called the “SEUCK Title Screen Maker”. It was a fun utility that allowed you to create brand new title screens for standalone games that were constructed with the Shoot Em Up Construction Kit. Those who were bored with the old front ends were able to construct a game with an animated title screen full of colour, optional hi score table and also plenty of music. No code was needed to make a new front end, just access to a freezer cartridge like the Action Replay MK VI cartridge or VICE.



The easy part was developing the utility. The hardest part was writing the manual. I am usually not good at explaining things technical, etc. There was good feedback and improvement suggestions about the production, some of which got implemented (Multi tunes). I was really pleased with how the SEUCK Title Screen Maker turned out. A few people have actually used it. I know Vox Video Game used it for Diamond, and Mac of TUGCS used it to make his SEUCK creation, The SEUCK Camp.

The other SEUCK enhancement I did was a special tutorial of SEUCK School. A tutorial where you could make a new score panel for your SEUCK game, using 8 sprites in Rayfish. This was to be split into two parts, but unfortunately part 2 had to be postponed due to raster time issues and needing more investigation. Perhaps in the new year this will be solved.

That said, regarding enhancements. There was one unreleased game which was made for the delayed Reset 64, which I enhanced with a new front end and music. All will be revealed in issue 15 of Reset when it comes out.

... Now what about the games I have developed throughout 2022? Well, let's check them out!

Lane Crazy

The very first C64 game creation I wrote in 2022 (although I started it Christmas 2021) was a really fun creation. It is quite a memorable production. I know I had loads fun coding it in C64Studio, and for the game to appear on the Zzap! 64 Micro Action covermount was a real bonus.

I teamed up with Blazon and Friends to develop a really fun hi score survival challenge called Lane Crazy. The concept was quite original and turned out well amongst the crowd. You had four balls rolling down a vertical scrolling lane while holes appeared at random. You had to use either a joystick or keyboard to shift the balls left or right. If one ball fell through the hole, the game was over. There were 8 levels in which the player had to survive, where after two levels the game got much faster.



While developing this game, I was using some of the usual graphics tools, such as Charpad V2.7.6 free and Spritepad V2.0 BETA. Usually my graphics looked really rushed out. However the result of making the in game graphics turned out nice and smooth. There were separate void tiles specially made for each level. When I was programming the game, I made the code copy charsets that formed the void and placed it into the actual charset that formed the scrolling void. The rest of the scroll was a wrap-around scroll, apart from the holes that appeared on screen at random. The concept really worked. The hardest part was to get the smooth scroller working on NTSC, but at the end I managed it.

When I was composing music for this game, I decided to go oldschool and use DMC V4.0 on my Ultimate 64. The music for the game blended in quite nicely.

Lane Crazy was really great fun, and it was nice of Firelord, Logiker and Baracuda to have teamed up to help me bring out a quality production, which saw the light of day. A huge thank you to you all for helping me out with such a successful project. Maybe we can do another new game in the future.



Tasered in the Crotch

The next game (Ironically) I wrote was a little joke game. It was called Tasered in the Crotch. Despite the silly name, and it being inspired by Commodore Format Archive’s Twitter poll (Dick Tracey, Cisco Heat, Tasered in the Crotch). The majority of people voted to be Tasered in the Crotch. This gave me a funny idea for a game coded in C64Studio. It was a fun little shooting gallery style game.

You had police officers lined up on a high balcony (or maybe a scissor lift). They are armed with their new state of the art tasers. Your task was to command each officer to fire a taser at the bank robbers that were walking/running past. Some were armed with smoke bombs, and you had to defend your officers from being hit by a bomb. Also, you had to watch out for innocent civilians who were passing A bomb or tasering civilians resulted in a loss of a life. If the number of criminals escaped exceeded the quota set for each level, the game was lost.



The game design was yet again made in Charpad and Sprite Pad (Same version as before). I wanted to make a few different landscapes, but with the limited number of characters, I had to improvise. After importing into the game project in C64Studio. The code was in place, and the result looked really good.

It was great fun making this game, and the music (made in Goat Tracker V2.76), which was featured on the title screen sort of had an Ocean Loader inspired tune to it just after the introduction might sound quite familiar.

A game which was intended to be a joke turned out to be something much more playable and successful, compared to Dick Tracey and Cisco Heat - It also appeared on the Zzap! 64 Micro Action covermount and was quite popular amongst one particular video reviewer :)


Little Nippers and Little Nippers DX

Reset had launched a 4K game development competition. I wrote a fun little single button game in which later on become a full game production. Little Nippers was the game. It was a fun co-op production which I made in C64Studio. This was a single screen game, where naughty kids were running across the beach. There were buckets lined up and it was up to you to fire a crab out of the buckets in sequence, by using either the spacebar key or the fire button. The crabs then moved in a straight line and if you nipped a pesky kid, points would have been scored according to distance from the sea. If the crab entered the deep end of the water, it gets lost.




Although Little Nippers started as a 2022 4K game competition entry. However, with summer on its way, and the competition submission deadline had finished. I decided to team up with Hugues Poisseroux to make a full version specially for Zzap! Micro Action’s 9th covermount, before taking a break from it and focussing on finishing off one of my main game projects.

The new version of Little Nippers gave the player five different beach/seaside locations. Before you were able to complete each location, you had to complete eight levels. There were 40 levels in total. Also there was a fun incentive which was added to the game. You had a time limit to launch your crabs out of the buckets before they have enough and jump out. There was also an incentive where you could fling a jellyfish for more points. Little Nippers DX was a good highlight and it really turned out to be a fun and pretty much addictive game creation.

 

Hugues' loading bitmap really highlights how fun the game was to be, It highlights some of the elements that were featured in the game. A snappy crab, a jellyfish and also a bikini (or two). All of which blended into the all new version of TapeTool turbo loader.




TheC64 Coding Challenge - Poing Ultra

I joined the group, Retro Programmers Inside. It was a group of retro computing enthusiasts, who were learning to program games and other fun stuff. The group was run by Prince/Phaze101, and Retro Programmers Inside. They did weekly video casts which mainly involved coding tutorials and also run game jams. The challenge I participated in was the PONG challenge. The game was called Poing Ultra.

My challenge was to make a new retro game, which suited the PONG challenge. It was to mark 50 years of the classic arcade bat and ball game, PONG. I thought it would be fun to make my very own game using RGL’s theC64 full size computer. The game was constructed using various Public Domain utilities I owned back in the 1990s and also the previously commercial Multi-Screen Construction Kit, and Action Replay cartridge MKVI (plugin). Music was made in DMC V4.0, The music was mainly techno, trance style and it worked out pretty well in the music editor. The programming was done bare bones in Turbo Assembler / Turbo Macro Pro most of the time.




There were a few pitfalls I encountered while developing this game. Although the main game was fully complete and working well in the assembler. I should have programmed the title screen as a separate file. Instead, I used the same assembly file and run out of memory. It wasn’t a complete failure developing this game. I ported the code to 64TASS and finished off the production using the cross-development tool. The game graphics were then drawn in Face's FacePainter, and the result turned out quite nicely in the overall productions. Mastering was finished with Martin Piper's TapeTool V1.0.0.7




The game got submitted to Prince/Phaze101, who then later broadcasted the game live on his Twitch channel along with some other entries. He was very impressed with the game overall, especially the graphics and presentation. While I was watching the broadcast, I was very pleased with the overall result.

Slug VS Lettuce

I developed a new little game, as part of the Scene World feature “Let’s Make a C64 Game”. This time it was a 10 minutes survival challenge called Slug vs Lettuce. It was a little game in which was to teach the basics of making a single screen platform game using KickAssembler. You played a slug that has to jump from platform to platform, gobbling up the lettuce. The slug had to avoid getting washed out by the falling salt droplets.

The game graphics were designed using the usual cross-development platform tools. The music was made in Goat Tracker. The rest of the project was being made in VS Code, and KickAssembler via plugins. Although I liked KickAssembler, the one thing I least liked, during the development of this project were the nuisances that VS Code developed. Popup-tooltip, etc. Of course compiling the code was easy enough, a basic push of F6 on the compile target file, and then F5 to run it, but there were no possibilities of crunching it with Exomizer (or the brand new TS Crunch). Instead I had to just make a batch script file and execute that.

This game did not turn out too bad, and it was really fun to make in Kick Assembler. However, the hardest part was to get the jump and charset collision mechanics accurate. The good thing about it though, was that the game worked out really well.



My biggest C64 project - Cruiser-X 79 – finally finished and released

The majority of 2022 was spent on my main game project, Cruiser-X 79. I had waited too long for additional graphics and level maps. Unfortunately, I received nothing due to many busy periods which Saul had to go through. – That was until I thought about an alternative plan. I did promise to get Cruiser-X 79 finished in 2022 and I really wanted to do that. However, I wanted to try and make the job easier for Saul. So, I created some rough game graphics (which you saw in previous blog entries) and maps. Then I sent them over to Saul to improve. 

I also worked exceptionally hard on making level music in GoatTracker Ultra V1.2 and getting everything to work. Also, I was working to a deadline to get this game ready in time for the Christmas issue of Zzap! 64 Micro Action (Issue 11) and its covermount.



I did come across one major pitfall in getting the mighty big shoot ‘em up finished. That was handling the Covertbitops loader system and Exomizer level unpacking system. It took me quite a lot of attempts to finally get each level to unpack and run on the disk version of the game, and I managed it.  

I also wanted to do a multi-load tape version of the game. Martin Piper’s TapeTool was one option, but I chose Paul Hugues' Freeload at the end because it used less zero pages. Also, it did not affect the game code either. The overall result for both digital disk and tape version of Cruiser-X 79 turned out excellent. It felt like a full price commercial quality game production as you would have expected back in the late 1980s or early 1990s. It was also the very first time I ever made a huge multiload production - especially on tape as well as disk. I am really pleased with how Cruiser-X 79 turned out. The feedback was also good.




Snake VS Bomb

Now coming to the end of this year, I decided to end C64 development for 2022 with a bang. There was a competition that was run on CSDB called the “Snake Fun Compo”. The idea of the competition was to create and develop a demo, game or whatever was related to snake. Considering there have been many Snake clones launched (I specially did one as a theC64 challenge back in 2020 called the Forever Extending Hungry Snake). I wanted to make something completely different.



Hugues and I joined forces again to bring out a quality game production for the competition called Snake vs Bomb. Developed in CBMPRGStudio V4.0 with KickAssembler (and with less nuisances compared to VS Code), Snake vs Bomb was a vertical scrolling dodge and collect hi score challenge.

You played a snake that was slithering through a tunnel. Fruit and bombs appeared at random inside the tunnel. The snake had to eat the fruit but avoid the bombs – otherwise the game ends. As the game progressed, the speed of the game scroll increased levelling up in difficulty. The result turned out really nice, and no matter how simple the game was, it turned out great. The graphics and the loading screen artwork really polished the game. It was also my very last game for 2022.



… and that rounds up my productions I made in 2022. 2023 will be a tougher year, but I insist that new games will be made by me. There should be another theC64 programming challenge sometime (Where I make a production fully on RGL’s theC64), my SEUCK enhancements/tutorials and my editorial task of building Scene World will continue. Also, I aim to return to Unity and convert one of my year 2022 C64 games to the platform. Before I do that, I some books to go through. I look forward to seeing what can be achieved in 2023. Also 2022 is the year I finally realize how proud I am about myself, and my creativity - and may it continue throughout 2023.

If you would like to check out my releases (as mentioned in this lengthy blog) you can find these at:
https://richard-tnd.itch.io

I would like to wish you all a Merry Christmas and a Happy New Year

Cruiser-X 79 vs Spore

 Well then, another week nearly over, and the rough graphics designs and maps I have been making are close to completion. Today I focused the mid morning - afternoon developing level 13 for Cruiser-X 79. The idea this time is based inside another base, which contains spore. The spore will not be deadly for the player ship, but there are to be quite a lot of obstacles for the player to watch out for, such as the usual high walls.

There isn't really much I can talk about, where it comes to this level. Except for that things look a bit messy at the moment. However S.C should hopefully be able to tidy things up with my rough level map design.

More music has been done for this game, and yet again another up tempo soundtrack, but this time more moody, but still trance like. 

Cruiser-X 79 - Ultra Violet

 Wow, there has been quite a delay since I last did my last level design on Cruiser-X 79. Well, it was due to working between other game projects. I had the PONG jam, also Alf Yngve's Captain Ishtar project (Which is nearing to completion). Finally a secret game project I was working on for an upcoming covermount for Zzap! 64. Unfortunately the game project has been very problematic so close to the deadline. 

Anyway, moving on forward to Cruiser-X 79. This time it is level 12. It is also the return of the vegetation zone, but this time, I called it "Ultra Violet". This is because the game uses an ultra violet blue scheme instead of green. The idea sounds quite weird but the colour scheme has actually turned out quite good. Also yet again, the music for the game is trance music, similar to the style of level 5. I have added less walls for this level, as the enemies for this stage are getting quite harder and faster.

Cruiser-X 79: Let's Rock !!!

Wow, am I really on to level 9 already? You betcha :). After completing level 8 last week. I worked on with designing level 9 on Thursday. I thought that for level 9, it would be nice to add a some new theme to the game. So an idea had come into my mind. The first half of the levels have been quite simple and involved shooting aliens and flying through bases, and hoping to avoid the enemy bases highest points.

Well, level 9's idea is similar to the first few levels, but I came up with an idea to implement even more deadly background. So that the player can easily crash into deadly terrain like rocks or similar - unless the player is carrying a protective shield (simply by hovering over the 'S' tiles). I started the level where there power ups are in place at the start of the game. Then I designed some of the background to make it look a bit like rocky terrain. It sort of uses some of the base's background character sets, and the deadly high building. I painted the blocks a little to make the deadly terrain look a bit like rocks. 

Although the graphics data that was being used for level 9 was based on level 4's Bubble World. This time round, I didn't want the bases to be bubbles based. I also didn't want the space background to become bubbles either. Instead, I chose to edit those character sets and turn those into steel saw disks. The colour scheme for the level are red, grey and light grey. The shoot-able blocks and other bits got transformed into different charset objects. After finishing the map and the design layout of level 9. I packed up everything ready for the next day.

The next day came, but sadly nothing happened that Friday. I was going to do some more work on the project on Friday, which was to work on some game music for the project. Sadly I felt unwell to be productive. Maybe tomorrow.

Saturday came by, I loaded up GoatTracker Ultra V1.2.0 to first work on some more in game music for Alf Yngve's Captain Ishtar project. Then I worked on level 9's music. It is sort of a dark, moody and industrial tune, which I felt would suit Level 9 of Cruiser-X 79. The tune is not trance this time (unlike levels 5, 7 and 8). I edited my instruments to make it sound right, then I exported the tune as SID and tested the tune. 

Once I was happy with the music, I exported it to PRG format into the game project's source code. Then I loaded up Charpad, and exported my Level 9 graphics and crunched them with Exomizer. I loaded up the source code, edited the settings and then compiled and built the project and tested the game in cheat mode. It looks pretty good. However, after Saul's magic touch to the graphics, it will look even better.

I am now going to take a short break on the level development of Cruiser-X 79. It is set to continue in about 2-3 week's time, unless theC64 challenge for Retro Programmers Inside's PONG challenge is finished and submitted to the compo. Stay tuned!!

To find out more about my progress with theC64 challenge #7 PONG 50th Anniversary game, please check out the link below:

https://tnd64.blogspot.com/2022/05/thec64-challenge-7-celebrating-50th.html

Cruiser-X 79: Lava hard work

 Last weekend I have been working on level 8, which is yet again based in space. However, I wanted to give the game a sort of a hot feeling. That's right. Level 8 is a lava base. I loaded up Charpad. I loaded up the graphics from Level 2. Then I cleared the whole screen and re-drawn the space background. Afterwards I placed in the tiles that formed the enemy base.

The next thing for me to do was to make sure that the level did not look too much like Level 2. So I edited the charset graphics and replaced some of those as new charsets. I tried experimenting with different looks for the enemy base. I decided to try and give it some hot look. I turned a few of the unused chars into plain chars, so that I could create a checkerboard effect. Also I altered the two scrolling charsets to represent the lava, which should parallax scroll with the game scene. A floor mosaic of an invader (with two high pillars) were implemented for the eyes. 

After completing my base, I worked on some music. This time, using the GoatTracker Ultra V1.2.0. Like with level 5, I thought it would be good to do an atmospheric fast thumping trance style tune for that level. I went for a traditional exotic mood inside the sound track. 

After finishing the music I exported all of the graphics data, and also imported the music into the game project source. I loaded up C64Studio and edited the level table and set the colour to match the level. The D64 building batch file got edited Then I compiled the project once more and run it to only load that level (I says level 1 on the status panel, but this is only test mode). The level loaded nicely, and the map turned out quite well.

Like with level 7, I have passed the graphics file to Saul to alter to make it look even more improved. I am very pleased with how things have turned out so far, and there is another level of Cruiser-X 79 (Level 9) I have in mind. It will be slightly easier on the game front, but there are harder aliens to come.

Cruiser-X 79: Fear the Freeze

 First of all, a quick note to let you know that during may, this project will be paused for a short period of time to make way for my 4K game for the Craptastic 2022 game development competition. It is unknown how long it will take me to write my 4K game. I'm hoping about 2 or 3 weeks or so.

Secondly some fantastic news about my levels. Saul has been working on updating my level designs, and they have been turning out pretty well. I am really pleased with the overall result from levels 2-5 (As level 1 needed nothing updated). Out of all of the levels so far, "Level 5" is my personal favourite.

On Thursday and Friday, I started with designing Level 6 and yesterday I did some more updates to the level and finished making the map. Level 6 is a freezing cold stage in which contains plenty of ice. I used Level 3's graphics data, as there was a nice cube in the space background, which looks pretty good for this level. The colour scheme uses cyan, light blue and white. However, Saul might decide on some different colours. The player ship is cyan, but it still can be seen (thankfully). I wanted to make level 6 harder than level 5, so more deadly background was added.

Today I worked on adding the music and putting the test level together. The music which I have chosen for level 6 is a rendition of one of my trance tracks, Ice Dream, which I originally did for Scene World about 2 years ago. I did a PC remix of the same tune (See: Nucleo448 - Trance Remix) and also in Nucleo 448 as in game music. I liked this composition a lot, so I decided to do another version for Cruiser-X 79. 

The level data got exported as character set, tiles, map and music data. Then crunched through the Exomizer V3.1.1 (in V2 mode). The level table got modified once more. I compiled and run the game into VICE, and played all the way to level 6. Argh, I think I have made the level too difficult with all those big walls, which the player has to avoid. However, I will give those a tweak next time I go back into the game project, and of course before I work on level 7 (unless of cource Saul has done it already). However, I do like the ice-blue theme in that level and the wonderful in game music. 

That's it for now with Cruiser-X 79. The project is now paused for a short term until after my 4K Craptastic Compo 2022 entry is finished and submitted. Then I'll be back onto it.

Cruiser-X 79 - April Update #1

14th April 2021  

Previous update was deleted along with the Para Lander DX blog entry. This entry from 3rd April  is what has been remembered from that day.

3rd April 2021

Last time I was dealing with alien patterns. The next task was to put these into levels. I also was setting up the colour settings for each level table. Of course, last time all aliens were put into order of sequence and were being tested.

That week (for this part in the development) I mainly focused on the level alien attack patterns. Instead of all aliens being in sequence 0-40. I setup alien selection tables for each level. The idea was to ensure that each table has a specific level of difficulty. There are 40 different alien tables (some of which are duplicated enemies doing different things). The idea is that the harder faster enemies get used after a few levels. There are 16 levels in total.

Now that all the alien patterns are in place for each level. There is not really much I can do to the game right now. Although I will need to work on doing different tunes for each level of the game. 16 different tunes might be too many to compose, so maybe I do a few tunes and then create a table to load specific music files. Still, that will do for now :)

 

 

theC64 Challenge: #6 Para Lander DX - Part 1 / 3

1st April - 13th April 2021 

First of all, you may noticed that I deleted the previous dev-blog entry based on this project. Sorry about that, but I wanted to try and squeeze things down more and give you slightly less to read.

You may remember back in December 2020 I wrote a couple of games for the Cassette 50 Charity competition and I submitted them into the competition. The two games were Rocket Away (source code now lost) and Para Lander Mini (Created on theC64 in Turbo Assembler). 

During the Easter holidays, I felt like setting myself a challenge in creating an enhanced version of Para Lander Mini and write Para Lander DX. I was quite font with the development of Para Lander Mini. I also felt that this game could have looked and felt much better if I enhanced it. Since the source code was still on my USB I decided to set myself a new theC64 game development challenge to make it happen.

I chose to develop the game fully on theC64 using the following C64 applications:

* Faces Sprite Editor V1.3 (Sprites)
* Jon Well's Multi Screen Construction Kit (Charset graphics and game design)
* Face Painter V1.0 (Title screen logo)
* DMC V4.0 (Music composing)
* I-Relocator (Music relocating)
* Starion Text Editor (Scroll Text Writing)
* Action Replay MK VI cartridge plugin (Freezer and M/C monitor usage)
* Style's Turbo Macro Pro V1.2  (Programming) 
* ECA Compactor/Linker V4S (Packing/Linking)
* Cross' Cruel Cruncher V2.5+ (Crunching)
* Loader Game Tape Master Kit V3 (On the Ultimate 64)

The cross development applications used:

* Notepad ++ (Writing code and batch files)
* 64Tass cross assembler (Compiling code)
* Style's Dir Master (Disk Mastering)
* Exomizer V3.1.0 (Packing/Linking/Crunching)

The majority of the game was developed using those applications above. However there have been cases where I had to move source to the PC and use Notepad and 64TASS, more about that later as we get along through this feature.

Preparation

In order to prepare myself for this project, I needed to use Style's DIR master utility to create blank work disks (Since that cannot be done on theC64 itself). Then I imported all of the applications to the utilities .D64 image. I also made a .CJM file to disable the accuratedisk function, and allow fullheight mode. This is because by default I set theC64's root directory to use those functions. Once ready, I ejected the USB stick and placed it into my theC64. Then I attached the Action Replay MK VI artridge plugin to theC64 via the media manager. (I also own the original physical cartridge).

The graphics

The first stage was to prepare the game graphics. I started by using the Faces Sprite Editor V1.2 to draw the game sprites. The main sprites were the helicopter, the player, splash frames, platforms, Game Over and Well Done messages. The Game Over and Well Done messages consists of the game sprites.

The second stage was preparing the main game background and game scene graphics. I chose to use Jon Well's Multi-Screen Construction Kit for this task. As there were not many screen editors that allowed me to design screens and background objects the easy way MSCK did. I designed the text character sets and screen background objects then saved to disk as charset, object and screen data and also colour data. (Note: The pic below was an earlier layout of the game's graphics. The final result is a bit different).

Next on the graphics part, I pressed the Power + Right Shift Key on my theC64 to activate the Action Replay Freeze mode. Then it was time to enter the machine monitor and type in a small routine that will grab the colour and screen data and paste it into memory. I executed it and saved the colour and screen data onto a disk. 

Making music

I cheated a little where it came to writing music for Para Lander DX. I did use DMC V4.0 (As by far it is one of my all time favourite C64 based music editors and I used it since the mid-late 1990's). You may noticed that I imported all the utilities into the D64, but what I did not mention was that I imported my Happy Blocks music into one of the work disks. After loading Happy Blocks. I cleared the old music and written all the title and game music. The result turned out great. It made me feel great also.

The Game Code

The easy stuff was all done and dusted, so now it was time to get into the hard stuff. The game code. I did a zero memory fill of the C64, using a hard reset. Then I went into the Action Replay fast load option and I loaded the desired files into memory:

* Game graphics charset = $0800
* Game music = $1000
* Game sprites = $2000
* Game screen and colour data capture = $2800

Next I loaded up Turbo Macro Pro and got programming the game from source I did when I made Para Lander Mini in December. The first part was to remove a lot of the old subroutines from the game. I used the linefeed delete option. Next I produced a routine that would display the new graphics onto the screen. This was called by reading the game screen and colour data capture from $2800-$2be8 and colour data capture $2c00-$2fe8 and place it into the screen and colour RAM ($0400-$07e8, $D800-$DBE8). Then I run the source.

Setting up the new game graphics data

Having the graphics data to display worked more or less. However while the zeppelins were being dragged across the screen (using the old source interrupt code) the colour did not move. I got back to the code and I decided to cheat a little by creating a routine that writes the character colour of the zeppelin to the whole row of the C64's colour RAM. I repeated it with the other zeppelins. Everything was working great. I saved the code again.

Scroll them like you should

The colour layout was sorted out, but the zeppelins were still dragging across the screen in a rough fashion. Just like the Cassette 50 Charity Competition entry. Something needed to be done about this. I edited IRQ code to give it some multiple interrupts. There were five in total. Then in three of the interrupts raster splits, I set the target speed stored from the hard scroll routine and stored it to the horizontal scroll position ($D016). After running the source code, the zeppelins were moving at a much smoother pace. I was very happy with the result.

Animation

The next step was to deal with the sprite animation. The helicopter, the player and the happy landing sprites all consist of 4 sprites. For the sprite animation the pointers needed to be set and so had the tables for each sprite frame. A subroutine was required to be added to make the animation happen inside a loop. Then of course the animation should be stored to the actual sprite number that was being used in the game. After a few simple routines, I got the sprite animation to how I wanted it.

The other routine that was missing was the character animation. The water was still and the reeds in the background were still. I created a subroutine that could animate the characters. The reeds had to scroll up, and the water had to scroll left. There is something I did not mention about, regarding the IRQ. The botttom IRQ background colour was set to blue to blend in with the water.

Splash down

My next task was to generate a scene that breaks a looping code, and creates a new loop that causes the player to fall to its death and splash into the water. This event takes place every time the player hits a zeppelin. Also the water splash was another scene for itself.

Yippee

There was another part in the game code where the player lands onto the launch pads, the player disappears. I wanted to do something more fun, so I created a little routine which made the player jump for joy then disappear. However I did not want the pads to disappear. Instead I wanted them to go into the water. With a little tweak of code that was done.

Great the main game play was dealt with, but what about scoring? I moved the score panel to the bottom of the screen. Just as I was about to generate a score routine. Turbo Macro Pro got messed up at the bottom. I ended up with garbage. I estimated it as running out of memory for game code. So I decided to move the code to 64TASS and use Notepad ++ to update and fix the game code. Then after adding the time routine and scoring routine. I exported the assembler file back to thec64 and re-assembled with Turbo Macro Pro. Awesome, I have a working score and clock and lives counter.

Status

Although I had a working clock, there were a couple of things mission. The Game Over and Well Done routines. I got the player to lose all lives but no GAME OVER. I got the player to complete all six pads, but no WELL DONE. Just a flashing inc $d020 jmp *-3. I created a couple of routines that awarded bonus points to the player. Then I placed two sprites Well Done on level complete and Game Over. I got those to flash and then saved everything. I was very happy with the game. It was time to save all of the code and move on to the next step. The front end.

Designing the front end

Not much had to be done here regarding front end design. I did have something missing. A logo. I loaded up Face Painter V1.0 and I got working on a logo for the game project. Like with Spider Maze and a couple of my other game projects. I created a basic logo for the title screen. I filled each character with one colour. Then I painted the characters with a few colours. The Commodore 64's multi colour bitmap mode can only allow 3 different colours and the main background colour in each cell. The result looked pretty good for someone who is not really an artist :) After finishing, I saved it as a Vidcom image (Using Action Replay's Screen Grabber).

Writing a scroll text

I loaded up Starion Text Editor and wrote down my scroll text for the title screen. Basically it was all about the credits, game instructions and also the usual scrolling messages.

Making a title screen

Having a logo may have been easy enough, however something needed to be done to it. The game was missing a front end. I loaded all the game data (as before) and then I loaded up Turbo Macro Pro V1.2 again and I started programming the front end. I wanted to make a front end which contains a scroll text and some credits. However I wanted to also include the game background graphics, and a bit of flashing text. Well, eventually that did happen. Here is the result below:

Hi Scores

Although I was nearly here, in exactly the same code I prepared a high score table. The high score table data was made by using a normal basic screen, an Action Replay freeze, and in the text editor I set up the table and noted down the values for each name and list. The high score name detection had to be changed a few times, due to a lot of problems I have been having with the zeropages. I even tried the longer method, but it left too many bugs. I decided to re-write the Shock Raid hi-score name entry routine but I used different zeropage values. It worked nicely. Next I manually linked the hi-score name entry to the game code. The name entry routine was keyboard based. This was actually the most easiest part in the name entry. Especially when the whole game project was using Kernal routines and IRQs ($01 = #$37).

Hi Score Disk Access

The final part of this task was to create a high score saver/loader routine. This part of the role had to be done in 64tass. This is because I wouldn't have known if theC64 was writing / reading the high score table. This is because theC64's accuratedisk mode has problems. So I had to rely on 64tass. I did many versions of the hi-score loading/saving code but it just didn't go very well. There were a lot of crashing going on. This had to be investigated, but I realised I used routines and zeropages I should not have used in the game, that caused it to crash. Finally this got fixed.

Compiling - Oldschool Style

Well, finally I get to compile, pack and crunch the project. All of this which I decided to do on my Ultimate 64, due to the features it has. I loaded up the ECA Compactor/Linker and packed the whole chunk of game data with this program. (And also endured the noise while doing the job). Then I set the jump address of the disk loader ($5780) and saved the packed file.

Next I loaded up the Cross Cruel Cruncher V2.5+. I typed in a 1-liner de-crunch text and set my Ultimate 64 into 48MHz mode for high speed crunching. - I set the jump address to $0810 (The jump address of the ECA Linker's de-packing routine) and then crunched the program. It only took a few seconds, whereas if it was at 1mhz mode, it would have took about 15 minutes. I saved the game to disk. I tested it and run the game. Result. I have a full working game. 

Is the game ready to release? ...   Not yet, you'll find out in the second part of this blog. The game will be released. You will just have to wait and see.

Cruiser-X 79 Update

1st May - 26th May 2016

While things have looked very quiet on this project. It doesn't mean that we are not continuing with the game project. In fact, the hardest part of the game code is practically out of the way. There are 16 alien formation tables set up so far, but there's still more to go. For the time being I have decided to leave the additional alien group property tables for the time being and focus on trying to get the main game engine repaired.

The aliens were unable to shoot at the time, and I tried to re-install the alien firing. However because I had deleted a lot of the old code (as I assumed it wasn't necessary) C64Studio processed loads of errors. I looked through the code, and tried to work a way round fixing the error result. Good news is that I managed to find the result. I re-created the enemy firing routine, selected the aliens to fire at random (via a pointer and value selector). If the alien was alive, the pointer and the bullet was out of the screen.

After fixing the alien firing I decided to fiddle about with the front end a little more. I added a flashing effect to the game's title screen. Also a page flip routine was added in order to flip between the front end credits and also the high score table. The result turned out pretty good.

Next the main game. The aliens were originally spawning in sequence. However, I didn't want the alien groups to spawn in order of the values 1 -17, so I setup the level pointers and some custom sequence tables to get the aliens spawning in a chosen value for that particular level. The video below shows you how the feature results during game play.

Update 11/09/2020: I just want to let you know that this game has NOT been cancelled. At the moment, I am stuck in a loop where on the coding side, I cannot really continue until the new set of level graphics come in. This project is therefore currently frozen until further notice.

Cruising for a Bruising

20th January 2019 

Well, 2018 sure has been a bit of a roller coaster of a ride, where C64 productivity and time was concerned. I mainly have been busy on SEUCK projects, but finally I have got time to do what I want. I will be on an Assemble It tutorial game project later on this week, but today I decided to concentrate a bit more on Cruiser-X 79. 

So then, what has been done today?. Before launching the playable preview, I have been doing a little more design to the test game map, which Saul originally did. This was mainly because the map looked pretty much plain space after about a quarter of the game map was drawn. So I decided to add some more tiles into the game's map and I tried to make it look as cool as I could. As soon as I finished with the map, it was time for me to export it to the game project.

Next was to load up the CBM PRG Studio and tweak some of the game code. There were some bugs inside the game, where sprites could be visible in the black lines between the game screen and the score panel. I simply fixed this issue by moving a subroutine which masked blank sprites into that particular screen area. After re-compiling the game, I could see my trick was working.

The next trick to was deal with the main game engine. I found that while playing this game, the player ship was just moving way too fast. The player was able to crash into the aliens or the deadly background too quickly. So I reduced the X, and Y speed of the player, so that it was moving at the slowest X speed and the Y speed is near enough to the correct X speed of the player.

Following that, I wanted to tweak the power ups slightly. There are 3 different tiles, marked B, M and S. The B tile is the smart bomb, M is the missile upgrade, and S is the shield. I wanted to make some alterations to the smart bomb and the missile. I started with the missile. The player's missile did work, but shouldn't the player have to pay the penalty for a cost of a life?. I altered the life lost code, so that then the player's missile was set to default - every time the player dies and fires the next bullet when spawned again.

The Smart Bomb feature was the next for me to enhance. Last time (originally) the smart bomb had a bug in the code, in which while a batch of aliens were being destroyed. Half a batch visible may have destroyed, but other alien sprites of the same group appeared. This just didn't look good for me. So I decided to do something about it. I added a trick which was to explode all of the aliens in one go. This was done simply by setting the code to enable all aliens, and make them dead straight away.

While still working on the Smart Bomb feature. I felt that the smart bomb code should be changed. So I altered the feature by adding some flashing background, to indicate the explosion. Also the feature was better off not being automatic, but manual. So I added a new subroutine and pointer where the player checks for the bomb carried. If carried, the Space Bar key activates the smart bomb feature, which destroys all or spawning aliens and awards the player 500 points.

The player has a penalty feature. If the smart bomb is carried, and the player loses a life, it loses the smart bomb power up, as well as the bullet power up.

I was going to launch a playable preview of this game on to the TND web site today, but I have decided to postpone it, due to a weird collision bug that is in place in the main game's code. The sprite/sprite collision code needs to be re-written from scratch, and some of the code needs to be inside macros. Once this has been dealt with, a playable demo of the game will be launched on to TND. Watch this space.

It's Christmas ... Time to Follow that Starfysh

25th December 2017
 
First of all, Merry Christmas (Happy Birthday to me ;o)) and a Happy New Year. This will be my final Blog for 2017, and I have decided to talk about the production of my LATEST game release Starfysh. This is basically a horizontal scrolling shoot 'em up - which is not a SEUCK game, although I have released some enhanced SEUCK titles as well today.

Starfysh is a simple 4-level scrolling game, in which Earth has been severly damaged by an alien battle. Humans and dogs have been transported on to rescue stations. The stations are now being attacked by aliens. You are a commander of the Starfysh Elite. Your mission is simply to battle through 4 different zones, fighting the aliens. After you reach the end of one stage, you'll move on to the next. This game has no particular power ups, but it was inspired a little on some classic games like Hewson's Subterranea, and Mastertronic's Star Slayer. The player can be controlled using a joystick plugged into port 2. That's the fun part. Now for the production notes:

Programming

The game was programmed using C64Studio, while I had a lot of free time spare between October - November in the evenings, and weekends (Excluding Sundays). The game consists of only 4 different maps which are quite large and caused me to play around with moving data to different areas of memory. 256 tiles in fact. All levels were transformed from bitmap format to charpad, using the map importing option. At first there were some technical problems. There were too many tiles and chars. I wanted a limit of 256 tiles/chars. The tile + charset compression option was a very good help.

Graphics and Design
 
I managed to fit 3 levels in, but adding the fourth stage was really challenging.  Each level was squeezed down using the Exomizer level/memory compression mode (exomizer.exe -l mem $xxxx source.prg -o dest.prg. The example decompression source was used to extract the compressed graphics source. (Charset, tile set and map).

Before I had the game sprites by Shaun, I created some test sprites of my own (Which were created in Sprite Pad, and then imported into the C64Studio source code). The sprites later got imported into my little weekend SEUCK project 'Space Crumpets' (Along with test sprites for Cruiser X-79, which I also drew ages ago). Creating the sprites wasn't much of a problem, but moving them was quite a challenge. I could have used the Alien Formation maker, which I wrote about a year ago, but I didn't want to make this another X-Force type of game. Instead, I worked hard on programming sprite movement patterns, based on timing and sense of direction. Some aliens will just move across the screen, but some aliens will move in a different formation. Also, unlike X-Force, I added alien firing. I also wanted to do something different to the game. The player should have a shield at the start of the game, or every time a life is lost. Shaun came up with an idea, which was to create a damage count before the penultimate death for the player.

Shaun did some new sprites for the game. The sprites were designed and created using the Shoot Em Up Construction Kit. Shaun used this editor for sense of a purpose (Not for creating a SEUCK game this time). The sprites were imported inside sprite pad. Sprite animation had separate subroutines to animate at different speed. Shaun's sprite example in SEUCK had to be followed. This was so that I could match the actual speed of the alien sprites.

Designing the front end with logo and scroll text was pretty much straight forward. Shaun sent me some bitmap mockups, and I was able to port them to C64 charset and screen format, using CharPad. This helped me a lot, however the title screen data had to be split into two separate charsets. The reason being was that manually creating the HUD design was a really difficult and painful task. I had to find a way to cheat and save time doing this. So I captured first the text charset snapshot, which included the HUD design. Then I capatured the main title screen presentation mockup. I imported all of the graphics assets into the source code, and programmed a new front end, and a working score panel, which uses the HUD. EXCELLENT!

Music

Sound and Music was done using GoatTracker V2.7. The in game music style was slightly inspired by some tunes from the demo scene in the very late 1980's - early 1990's (The Dutch USA Music Assembler/Voicetracker era). This time round I didn't want to make any techno/trance music. I wanted to try a different style. The title music was a slight remix of one of my older tracks, I originally composed in the 2000 year. (Space Techno I think it may have been called). I made the remixed title tune sound more disco style, rather than techno. For the up scroll ending music, I went for an epic space ending theme.  Sound effects were also created using Goat Tracker.


Mastering (Tape+Disk)

The final mastering of the production. Before I could do that I asked Shaun if he was able to make a loading picture. He suggested that I contacted JonEgg. I spoken to JonEgg and asked if he was interested to draw the loading pic, JonEgg was. However Shaun drew me a temporary loading picture for the mastering - also just in case there was no loading picture at all.

I decided to do the first master, using my pre-built C64 tool 'Tape Master Pro V3.0'. Before I could do that I imported the assets 'Loading music', 'Shaun's picture' and game, and used a black screen with thin dark blue loading stripes scheme. This was Shaun's suggestion. A good result. However, when I was on the 1541Ultimate 2 page, I discovered that someone else used Tape Master Pro V3.0, on a C64 game, but the loader caused a few problems. I contacted Martin Piper to find out, and he introduced me to a new version of TapeToolBuild.

I had to recreate the tape loader using the TapeToolBuild source in scrollermusicloader.a as the source code had no ability to display a loading picture or use any additional code I would have wanted it. So I re-programmed some of the features from the Tape Master Pro V3.0 tape loader (The flashing text, scroll text, picture display and PRESS SPACE option). I also created my own source files to import/relocate the game and picture data through a PC. Also a custom loading stripes scheme. The result turned out how I wanted it.

The disk loader was pretty much straightforward. I used the exact same loader as I did for Let's Invade (A Space Invaders game, which I wrote last year). I placed a loading picture and music for Starfysh into the game. Bolted a TND intro before the loader. I chosen the latest intro I created earlier on this year (Rippled Dreams), and added a brand new tune to the intro. I imported the main game and used Excess' Dir Master V7.1 in VICE to change the load address of the main game to $2000.

Eventually I received an email from JonEgg, which he attached a new loading picture for the game. I loved it. :). This replaced Shaun's loading picture, but I felt that Shaun's pic should still be used. So I made a timed splash screen which quickly display's Shaun's pic and run i through the Exomizer.  Not a bad result.

I showed the Disk + Tape version of the game. He suggested that the disk version should have loading stripes. He wanted dark blue loading stripes. I tried implementing this feature into the .D64 version of the game. Sadly adding the function to the IRQ loading code LDA #$06 : STA $D020 : LDA #$00 : STA $D020 caused the Exomizer decruncher to crash instead of decrunch. Instead I replaced the border flash with INC $D020 and DEC $D020. That made a huge difference and the program worked absolutely fine. :)


Starfysh can be found and downloaded on to your C64 1541Ultimate2, Turbo Chameleon, CCS64, VICE or whatever at:

THE NEW DIMENSION - GAMES PAGE - STARFYSH

other presents (new releases) can be found at:

 THE NEW DIMENSION




Also, to support SDIEC users, the game has a kernal loading option (With stripes), but you still will be able to listen to the loading music after loading has finished.

MERRY CHRISTMAS, Enjoy the presents, see you in 2018 and have a HAPPY NEW YEAR!

Cruiser X-79 Update #12

7th October 2017

This is a just a quick update. You may remember a couple of days ago, I mentioned about having trouble getting the tape loader to work using multi-load, and  the game crashed. I finally managed to get my way around this problem, simply by not triggering RTS after the loader had finished loading a file. Of course, I had to edit the game code, where RTS was originally called for setting up new levels. This was replaced with a jump start to the main game code. I also implemented the same code with the disk multi loader.

The tape turbo code also needed a slight altering, so that it could switch off the tape motor, call Exomizer to level-decrunch the program file loaded, then call a subroutine to check whether or not all files have loaded. If so, then jump to the main game code, otherwise keep on loading the level graphics data (Charset, tile set, map) until all 3 files have loaded in and run through Exomizer's decruncher. Thankfully, it all worked.

Now Cruiser X-79 can have digital disk and tape versions. :)

Cruiser X-79 [UPDATE 11] - Not much ... Or is it?

5th October 2017

I really should have back dated this Friday+Saturday last week, as nothing had been done today. I've been running late. Anyway, last week, I was doing some brain storming, and slight of hand updating of the game code.

Originally Cruiser X-79 used a 3xIRQ interrupt, but since that was just UNECESSARY, I decided to reduce it to a 2xinterrupt instead. Reason being fixing the smooth scrolling, so that it could scroll smoothly.

Other implementations which had taken place last week was related to access to levels. The size of the game map 320 blocks in height. That is way too much for one file - even compressed. Now imaging having to pack 16 levels and try to cram that into a single file? Not really possible, due to the memory restrictions.

In order to solve this problem, I decided to implement a disk load subroutine, along with the Exomizer level decruncher. Each file to decrunch has to be a game character set, tile set and also a map. To make the level packing more simpler, I decided to create a project in Endurion's excellent C64Studio suite, and call Exomizer to compress each level file, and then import the files on to a .D64.Then I set up the file names, low + hi-byte of the END address of the program for Exomizer to decrunch. At first I had crashes, probably due to some silly mistakes I made into the code. After several attempts the code worked, and a working game / preview was in place. Brilliant.

This may sound as if the game is turning out to be disk only? Well, not necessary. I had a bash at making a 2-sided tape version of the game with TapeToolBuildV2, and my modified  version of Martin's source. Where after loading the game with picture and music. The front end comes on, then a message on screen should prompt the user to flip tape to side 2 and rewind (Or in .tap form, simply eject side 1 or the tap file, and then start side 2  - Since I use 1541Ultimate more than a tape - in order to reduce loading programs and finding load errors :D ).

Although this felt like a great idea. I had to disect Martin Piper's turbo loader system, through his source. So I created a second source, which made two loads for each file. Basically, the idea is to load a test pilot $0200-$0240, then load in the selected charset/tile/map file. After each file has loaded, the loader should point the end low/byte address to the decrunch address. Then call the loader again, another two times, then after the last decrunch. Run the game. Sadly this didn't work for me. The turbo did load the data to the correct end address, and the low/hi byte of the end address, did get stored to the correct self-mod decrunch from address of Exomizer. However, instead of actually running the decruncher, after loading (Where I added an RTS at the end of the loader (The loader is mean't to be a subroutine), the program crashed completely with a CPU JAM. I will need to investigate further into this issue. The test disk version loads fine. I'll let you know how I progress through making a .tap version of my game.