Tuesday, 4 June 2019

Cruiser X-79 - Migrating to another base

2nd-3rd June 2019

Sunday, I came home and was wondering what I should do. I decided on doing some more work on Cruiser-X 79. I decided to carefully look at the code, and copy/paste it it from CBMPRGStudio to Endurion's C64Studio. I created a new C64Studio project and called it CruiserX79_2019 and copied and pasted the necessary files. Then afterwards, the hard work was to be done. I had to rename commands to match the ACME syntax. This took about an hour of my time. Then there was the correcting of syntax errors. The labels were mixed case. So I had to relabel those. The errors were then fixed. I compiled, compressed (with Exomizer) and then run the program. The game title screen was running perfectly, but when it come to starting the game. It crashed. I investigated the problem. The culprit was - an incorrect music file was copied. So I corrected this by copying the correct in-game music file and placed it into the bin folder. The game now worked.

While I was testing the migrated build of Cruiser-X 79. I had come across a nasty bug, which I came across a long while ago. The bug was pretty much unknown to me at the time. The issue was where after the player had lost a life. When the shield had run out, the player exploded straight away, without even hitting an enemy, bullet or deadly background. I investigating further into this bug and I found the main culprit that caused it. That was the player death and shield code. After the player was killed by an enemy a pointer PlayerIsDead is set as 1, indicating that the player explodes. All I needed to do was initialize the PlayerIsDead to zero. So that every time the player's shield is activated, the player should not be dead. That is of course until an alien or deadly background hits the player.

I'm happy very happy to present you with the result and show you a video of the game in action, with a vertical scrolling test map, with all collision working in place. I deliberately set the game into cheat mode, so that you can see that I have indeed fixed the nasty bug. Although there are still one or two minor bugs inside the game preview. Nothing too serious though. Enjoy!

Sunday, 20 January 2019

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.

Saturday, 21 April 2018

C64 Mini Weekend dev challenge #1

20th-21st April 2018

A couple of weeks ago, I bought myself a theC64 mini console, and I loved it. The built in games were cool. However I needed to purchase a USB keyboard, so this week I did exactly that. Set up a multi-USB adapter with the C64Mini (An old one) and everything was working. I was able to play multiple games from a .D64 (D82 image renamed to .d64). Now I realized. Wouldn't it be cool if I set myself a Dev challenge. Announced on theC64 Mini Users Group. I decided to set myself an assembly programming challenge.


20th April 2018

I set myself a challenge, which was to create and develop my very own oldschool cracktro style intro using theC64 Mini. I was able to select some of the classic public domain utilities, that were released by the C64 demoscene back in the good old C64 scene days, and get those on to a D82 image (via dir master). Then I renamed the .D82 to 'theC64-drive8.d64' using my 1541Ultimate 2. Now it was time for me to get to work.

The Logo:

In order for me to design the logo. I went for a very classic utility from the 1980's called Centauri Logo Editor (Pictured below). I wanted to draw my own logo for this challenge. I went for an oldschool design idea. The idea was simply to draw a logo that was embossed inside a plaque. I got a bit carried away with the logo design, and pixed inside the words TND some stars and basic shading. Of course the logo was limited to 3 colours. After finishing the logo, I converted the Hires/Multicolour bitmap into a Font+Screen matrix format and the saved the font+screen files separately.

The Charset:

I wanted to create two character sets for the intro. They were 1x1 hires and 2x2 multicolour. I loaded in Shape's Font Editor V3.0. There was no joystick function for designing the font, so I used the USB keyboard to pixel the correct colours into the correct position in the grid. I was very happy with the 2x2 charset, the same for the 1x1 charset. Not a bad result.

The Music:

Now that I was 100% happy with the graphics. I got started on composing some music. For this I used Graffity's DMC V4.0 (Pictured below). I found it quite awkward to work out the key-mapping on the USB keyboard at first, but managed to get around it afterwards. The tune was to sound oldschool in a sort of Future Composer kind of way. I decided not to use FC, due to the possibility of the program crashing should DUR/SND be in the wrong place. I would not have been able to get back to the music editor if it did crash. I created some oldschool instruments using DMC's sound and filter editor. A little further experimenting came out before coming out with a final piece of music, called Laser Light. I was very pleased with the result.

The Sprites: I originally chose Shape's Sprite Editor V1.7, but after creating some star sprites for the intro. I realised it was just impossible for me to save the sprites. There was no save option implemented. So I decided to use  Graphic Editor, also by Shape. I created a series of sprite frames for the animated stars. Then saved everything


Before I was able to do some programming. I needed to work out where I should place data and code. In order for me to complete my task. First however, I needed to use a M/C monitor, for loading/saving data during the coding process. I loaded up Black/Angel's improved version of Omicron's Turbo Assembler from the filebrowser menu then added a JMP $FCE2. This forced the C64 to do a soft reset. I was then able to load in the Code Suck Monitor into $5000 (Since my intro was intended to be only use data+code from $0c00-$4500 - where $4500 is where linked programs will go). I set CSM to load the following data to the following addresses in memory:

- Music: $1000-$1fff
- Logo Charset: $2000-$2800
- Logo Matrix: $0C00-$0e00
- 1x1 Charset: $2800-$2a00 ($2a00-$2c00 reserved for the star field source)
- Sprite anim frames: $2c00-$2fff
- 2x2 Charset: $3000-$3800

I went back to the turbo assembler by calling J 9000 in CSM. Then I programmed my own text routine, for writing the intro text, and also the scroll text. The intro text was placed at $3c00, and the scroll text was placed at $3800. Now it was time to code the main intro.

So then what was done in the main intro code. Well, for a start off, I needed to program an IRQ interrupt to ensure that music was okay and in working order. Then, I started to add more and pieces of code, and placing those together with the assembler. Basically, create a subroutine that displayed the text, logo and scroller charset using the default PETSCII. After I was happy with the result. Some more raster splits were added inside the code. One of which was to display the logo charset+screen, the presentation lines charset, and the 2x2 scroll text - and get everything smooth running. A good result.

Although everything displayed nicely. I felt that the intro looked too plan. So I decided to code a few raster colour bars. They got displayed, but the rasters needed timing out. Although I always had difficulties with raster timing, when coding intros/demos - I had no problem with this one. All 3 rasters were nicely timed out on PAL machines. It was getting late, so I decided to create a save state of the intro (as well as save the intro data + code done so far).

21st April 2018

More coding:

Last night I was very happy with the result of the intro, so far made on my theC64 Mini. Now it was time for me to add a bit of code to the intro. I felt that the presentation lines were just too plain. There needed to be something behind the text. So I decided to create an additional table which produced 6 characters for a flying star field. I put the star field into place. Added a little more code that could flash the text, and avoid the starfield from also flashing. Then I added the flying sprites and code. A final result. Finally the main code has finished. It was time to code a relocator subroutine then put everything together using the save option in CSM. (s "introfinal",8,0c00,4500)


The intro (pictured) was complete, but there was one more thing I needed to do. Compile and compress the final intro, so that it was runnable from BASIC. Since I wanted to do things sort of late 1980's/Early 1990's style. I loaded up Compactor/Linker V4S by E.C.A Industries, a very old packer/linker, which did its job fine on my intro. Then to finish it off. S&T's 2mhz Time Crunch V5.0. The final intro was made and it all worked out quite nicely.

My weekend challenge of programming on theC64 Mini was very successful. :) I was very pleases with my result.

Want to see the intro? Download it from here, and place on to a USB Stick on your theC64 Mini and enjoy. I have also provided the Public Domain utilities that helped support me producing this production so you can see how the intro was made and put together. This intro can also be run on WinVice, and CCS64. Enjoy :)

Monday, 25 December 2017

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:


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!


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:


other presents (new releases) can be found at:


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!

Saturday, 7 October 2017

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. :)

Thursday, 5 October 2017

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.

Saturday, 19 August 2017

Cruiser X-79 - Update #10

19th August 2017

More action has been taking place today. First of all, Saul suggested that I should reduce the animation speed for the aliens and also the explosion. Basically double the delay of the animation. Also I had a go at setting up level pointers, where after each level advances, the game sets up the next level settings. For example, pick out the chosen alien type, formation, level colour scheme, etc. I tried compressing a test level map, using Exomizer, then imported it into the source code 16 times, to set each level. Sadly this trick didn't work and caused a memory overflow.

In order to solve this issue. I have decided to make this game multi-load based. This means that after 1 level is complete, the disk or tape image should load the next game file.There is just not enough memory for me to place even 8 level compressed versions of test maps that exceed $0300 bytes (Compressed). I will make sure disk loading will also be SDIEC compatible as well. Tape version is intended to be mastered using Freeload or the Thunderload Multi-Load companion tool.

You will notice a slight difference in the game during this test video of cheat mode below.  :)