theC64 Challenge #3 - The CF Power Pack challenge resurrected

The Commodore Format theC64 Challenge #3 diary updates will be added throughout this project. Watch this space 

17th September 2020

The previous code challenges I did on theC64 were quite a success and had me in a sort of comfort zone with a machine code monitor and Turbo Assembler, although I did come across some pitfalls - but I managed to get out of those quite easy enough.

A demo/intro was made in 2018 on theC64 Mini (See: C64 mini weekend dev challenge #1). A couple of games were made this year, using Turbo Assembler and a few PD utilities (Storm Chase, and The Forever Extending Hungry Snake) . I have decided to do just one last theC64 full size challenge for this year. This time, this challenge will be taking me outside of my comfort zone.

Killer Saucers is going to be an 8-level, 3 lives high score attack retro-style single screen shoot 'em up tailor made as what you would imagine a reader's game for a magazine cover tape would have looked like back in those days. Of course this game is not going to be an actual Power Pack tape. Just a standalone game which you will be able to download for free from my web site. The reason for why all of the levels are going to be single screen is due to the limitations of the assembler that was featured on the Power Pack tape.  ;)

"Planet Earth is under attack by incoming flying saucers. Your mission is to guide your grounded vehicle and fire missiles at them. Beware though. the saucers can also fire missiles back towards you. You will have 1 minute to shoot as many Killer Saucers and 8 levels before they can kill you. For each level complete. The game will eventually get harder to play. After 2 levels, newer flying saucers will appear on screen. Although 8 levels. This is a high score attack challenge"

 Back to the challenge:

The purpose of this challenge is also my part of celebrating the 30th anniversary of Commodore Format magazine. The magazine started in September 1990, and ended in September 1995. The memories about this magazine lives on. The main attraction for CF were the Power Pack cover tapes. Each month, at least 1 or more full games, and a few playable demos were added to the cover tapes. Occasionally, some exclusive non-commercial/commercial or Public Domain utilities were featured on the cover tape. So, for this final theC64 challenge. I have decided to work on a new C64 game using only the utilities that featured on the cover tapes - also pick out two or 3 useful utilities for other tasks such as compression, memory code movement and music.

The following programs I have chosen for theC64 challenge are as follows:

• FROST (Format's Really Original Sprite Thingy) - Power Pack 32 & 56 (Sprites)
  
• Font Editor V3 - Power Pack 38 (Character Set)
  
• 6510+ Assembler - Power Pack 45 (Programming and compiling)
  
• Code Suck Monitor (Preparation / moving / saving of sprites)
• A chosen music editor (Excluding Soundtracker 64 from Power Pack 57 - It is tough to handle) . My choice is likely to be DMC or Voicetracker/Music Mixer.
• A couple of compression tools (Most likely to be XTC V1.0 and Fast Cruel Cruncher again).

DAY 1:

1. Frozen by FROST

I loaded up FROST on to my theC64 full size computer. This was from the original tape. I still had to wait for the clock to count down during loading. Brings back memories eh?. It started with a nice intro presentation with some Future Composer Music. Pressing Space goes directly to the editor.

I made a start with drawing the sprites with the editor. I drew a single frame for the player, for Killer Saucerz. Drawn up next was the player's bullet. I drew it like a missile with a flame at the bottom. The animation consists of 4 frames for that one. Thirdly I drew an explosion, which consists of 6 frames. Then came 4 different enemies using 4 frames. Finally was the enemy bullets. Although at the moment I class 4 aliens to be enough for such a small hi-score challenge game. There may be a chance of more alien saucer frames. This of course depends on memory free after compiling a complete game.The last 4 frames set are the saucers missiles (Basically a reversed version of the player's bullet).

 I completed all of the sprites I needed so far. I went to the save menu to save to disk. Oops, I forgot to save the files to disk and utility was trying to save to tape. theC64 has no tape save function yet, so I pressed RUN/STOP and then tried saving the sprites to disk again. (After changing the device). Also, as a just in-case scenario I selected MAKE DATA to generate a BASIC listing for all of the sprites that I made. 

The DATA MAKER went in to BASIC and generated a big list of DATA lines. I saved all of those lines to disk. Then I loaded and listed the directory. It turned out that the utility only saved a 1 block file to disk, even after selecting the start and end sprite. That could possibly a small fault with the firmware maybe? I had this sort of problem before with theC64 when accuratedisk function was enabled. I had no trouble with this on the Ultimate 64. The BASIC listing successfully saved completely. Looks as if FROST had a bug. I think the version I used might have been from CF32.

I just tested the same save method on my Ultimate 64, to see if I get the same problem as I did on theC64 (test saving a range of sprites to disk). There were no issues. Therefore FROST is not bugged.

2. Do the SPRITE thing

Because I reached a problem with saving the complete set of sprites. I needed to find an alternative solution to this problem. Scenario: I have hundreds of DATA lines in BASIC, I need to make it into a machine code generated DATA. How do I get to put the data to $2000, and how do I save it from the start to the end without an Action Replay Cartridge? A problem always has a solution. I had Code Suck Monitor installed on one of my disks. So I loaded that up. New the listing. Loaded up the sprite data lines and then created a BASIC listing to convert the data list into machine code data at $2000 - until the C64 ran out of DATA. 

A simple solution was:

1 FOR X=8192 TO 12288:READ Y:POKE X,Y:NEXT X

Of course the ?OUT OF DATA error did spit out, but I only wanted the sprite data to convert to machine code until it reached the end of data. 

I enter the Code Suck Monitor, examined the data using the M prompt until empty memory was found. The I saved the sprite data from $2000-$2500 (start of clean memory after running the BASIC listing)

3. Now Which Font?

Since I was very happy with my sprites. I decided to work on the character set for the game. I chose FONT EDITOR V3 for designing and creating the game graphics font. This is because the size of the font is pretty short, especially for 1x1 fonts. I only needed something basic for designing and creating the game's prototype background.

A few characters were drawn to form a road and also some buildings, as well as the text and numbers. Once I was happy, I saved the font ready for the next session.

 

4. Where's the Editor?

Because this is to be a theC64 challenge, and theC64 does have no Action Replay support for the reset/freezing. I didn't want to cheat by using other text/screen editors for the main graphics for this project. Instead, I am relying on coding. I loaded up the 6510+ assembler and I had to program my very own screen+colour capture routine. It first clears the screen and then runs on a BASIC input using JSR $A560. After the tap of the RETURN/ENTER key, the program stores the complete screen and colour data to $4000-$47e8. Where $4000-$43e8 is for colour data and $4400-$47e8 is for the screen data. The game and title screen hasn't been designed yet. There just wasn't enough time tonight. I decided to call it a day.

19th September 2020

DAY 2

1. The Designer's Pencil

The second day of this project. Last time on Thursday, I created my own little editor, and assembled it. I loaded up 6510+. Loaded up the character set and then I loaded up the SCRED.SRC assembly source. The file then was assembled and SYS49152 started the program. I was ready for the painstaking screen design. I have decided not to design the title screen at the moment since I will be leaving it until last. I moved the cursor around the screen, and prodded a few keys to design the game screen and colour data. Things were working out quite nicely with the screen game design. I drew the hi-res char city and street and score panel. Then I pushed Return to store the screen and colour of the game pic. I enter the machine code monitor in 6510+ and saved the game colour and screen RAM data to my virtual workdisk.

2. I like to Move It 

I am not quite ready to code yet. I need to move some things around, like sprites. Add a test music, and a few other bits. I reset theC64 full size, into CBM Basic. Then I loaded up the CodeSuckMonitor. The problem is that 6510+ Assembler's M/C monitor didn't allow me to load my data to a specific load address. I loaded in the sprite memory to $2000-$3000, game screen data to $3000-$3800 and the game character set to $3800. Then I grabbed one of my old music pieces, Plasmatic from the DMC collection and added that to $1000. I then used the Code S Monitor to save all of the game data. Reason for this is because I will need use all of the game data for the main coding.

3. Know the Code

6510+ had to be loaded again. I loaded up the assembler, and started programming the main game code. The first thing I had to do was prepare the game screen. Then after that I setup the IRQ interrupts for the game, including a synchronized timer. During each coding session I had to play around a little with the routines. Since each command was being written on a basic numbered line (Like how it used to be back in the 1980's). I saved the source and assembled it. Once assembly was successful I loaded in the game data and then typed in SYS 16384 to run the program. The game screen displayed successfully, and it also played my old piece of music Plasmatic in the background.

4. Ready Player One

Since I was doing the code a bit at a time. The next stage was to setup and test the game sprites and their animation. I created a series of pointers to give each enemy its own animation. The player ship only has a single frame, but the saucers and other sprites all use 4 or more frames. I programmed a routine that would display all 8 sprites. I placed the player at the bottom of the screen. I saved the source code and loaded in the game data and tested the animation. It was working quite smoothly. I was pretty happy with the animation. 

Now was the time to get the player setup for the project. The player was positioned at the bottom of the game screen but it could not move. That is because there was no particular code added to the player ship. So I worked on adding the code. The player should only move left or right. However it should also stop on the left and right parts of the screen. I added code that did exactly that, via a push of a joystick in port 2 (Since most games used that joystick port anyhow). I saved the code, assembled it, loaded the game data and then run it. The player moved quite smoothly.

5. Ready, Aim Fire

The player was moving pretty much well, but it could not fire at the moment. I loaded back in the code and then created a couple of routines. The first one was to check whether or not the player had already fired a bullet. The second one was whether or not the bullet was out of the screen. If the bullet was
out of the screen. The player was able to fire the bullet again. Also a routine was programmed to moved the bullet upwards. Then after the bullet leaves the screen it is positioned inside the border at the very left. If the bullet is at the very left of the screen, the player can fire the next bullet. Otherwise it has to wait for the next one. I saved the source, assembled it, loaded the game data and had a working bullet.

6. UFO sighting

After the player bullet was one more session before I called it a day. The Saucers need to be moving on screen. I programmed a subroutine that allowed to move one saucer. I got the saucer to move around the screen. I watched it move. I wasn't too happy with the saucer bouncing around the screen. I have another great idea for it, which I will be continuing with on day 3 of the project. I'll mention about it in the next day update. I saved all of the data and code that was made for the project so far, and made a backup of the project from USB to PC. It would be a shame to lose the project if a USB gets corrupt and a file becomes unrecoverable.

 DAY 3 - I like to Move it Move It

 23rd September 2020

TV was unsurprisingly rubbish and filled with soap operas as usual. So what better thing to do if you hate soaps than do a bit more coding on theC64. I made this session a slightly shorter session. This time it involved programming the enemy movements from scratch. I deleted the old movement routine for just one saucer and created a loop which reads speed X and speed Y of the enemies. This was because I had a better idea planned for this game. I wanted to use a similar mode as my loader game Mootilation originally did. The saucers can move across the screen, but if they spot the player's position, they can swoop down and try to capture the player. There is still not enough action yet, as the player cannot blast the aliens yet. Also the aliens cannot target the player yet either. More code on this on Saturday. ... stay tuned!

 DAY 4 - Fire at will

26th September 2020

Yet another short session today. I've been a little bit clumsy, but the second session should hopefully take place sometime tomorrow morning. Today I loaded up theC64 full size and 6510+ assembler and loaded and assembled what I did last time. I noticed a small fault in the game data. The enemy bullet animation was just plain garbage. It seems that I didn't manage to recover the enemy bombs during generating of the data in day 1. I decided to load up the Faces Sprite Editor V1.3 to fix this issue (As the version of FROST I used had a bug in the save sprites function. After fixing the sprite data and saving. I reset theC64 and then use Code Suck Monitor to load in the game data, update the sprite data and save the game data again 

The re-save of the game data was done. I loaded up the 6510+ assembler and loaded up the game source code. I assembled it, loaded up the game data and then SYS16384. The program did run, but there was still a glitch in the enemy bullet sprite animation. This time it was because the sprite animation table was one byte ahead. I corrected the issue, saved the code again and reassembled the source and loaded the game data and ran the program. It looked much better now. On to the next phase.

So I had the enemy saucers animate correctly, the player shooting but the enemies could not shoot. I decided to work on a subroutine that could do exactly that. Before I could do that though, I needed to check that the enemy bullet could only fire if it was out of the screen. Also I needed to pick which enemy could fire out the bullet. In order to do this I created some pointers that allowed the bullet to move down screen and once it reaches the bottom, it should go offset. A second pointer was used as the random selector. A subroutine was created in order to select the enemy that should fire the bullet. Then the enemy bullet was then positioned

on to the enemy object. Of course the bullet had to be checked to be offset first. I saved the code assembled it, loaded up the game data and then ran the program. Nice, enemies are dropping bombs.

The next stage had to be postponed because although I was doing the routine, I accidentally typed in NEW forgetting to save the source code, loaded up the game data and then run the program. The routine was a random enemy Y position for every time it reaches a certain outside position on the game screen. I will be working on this trick tomorrow. ... Stay tuned!

 Day 5

27th September 2020

CRASH!

Yesterday I successfully had enemies firing. Today I worked on the collision read routine, and setting up the level tables. Each level tables was based on the enemy type, speed and number of shots to kill it. I also added a test collision routine for the player vs enemy. I saved all of the code like normal, and assembled the program. The assembled code was going to overwrite the source code. Looks as if memory is low here. I assembled the source and overwritten the listing. Typed in NEW I loaded in the game data and then typed in SYS16384. The assembler froze. The program didn't run. it was a complete FAIL. 

So is it the end of the challenge resulting to a fail? No, because all I had to do was move the code to a different part in memory where it could not overwrite the listing and corrupt the project. I moved the assembled game code to $6000. It has not reached $7000 so that's quite good. I still have enough memory to finish the main game code. The title screen will be coded separately.

DAY 5 

4th October 2020

BOOM!

First off, I was running a bit low in memory, but I noticed I created too many data tables for levels, etc. I don't really need those at the moment. So I deleted them to make more space for some more code. 6510+ assembler is memory restricted. I continued with the sprite/sprite collision routines this time. Last week the sprite/sprite collision routines only flashed the border if the player was hit by an enemy bullet, or if the player bullet hit an enemy. The collision felt very raw.

I added some more routines that could animate the explosion frame on to the player, and also bullet objects. This should only take effect if the object hits an enemy or bullet. The enemy bullet is indestructible by the player's bullet. So in a more common sense kind of way, the bullet sprite should explode before it leaves the screen after shooting an enemy. The player should also explode, before losing a life. I also added routines that zero-positioned enemy vertical position as soon as they have been shot by the players bullet. 

I saved the source code, assembled and loaded the game data and then type in SYS $6000 to test the new source code. It seems to be working quite nicely, but I have noticed a bug in the code. The enemies were shooting their bullets, like they should have done. However when zero positioned. You could see bullets firing from the enemies that were killed. This is not how the game is supposed to work. I loaded back the code and then edited the listing so that if the enemy vertical position is 0, no bullet can be fired. I saved the source, assembled and executed the game code and then loaded in the game data. I then run the code, and it was working much better.

So now I have a fully working game engine, with full sprite animation, working collision detection and enemy bullet firing. Great.... but the project is not quite finished yet. The next stage (which will be in the next update to this blog/diary) will be something hectic and crazy. I aim to give the passing enemies some kind of crazy behaviour, when they spot the player in their sight.

Day 6

6th October 2020

Kamikaze

As mentioned on Sunday. This evening I wanted to code a feature which allows the saucers to kamikaze towards the player when detected.  Before I did that, I fixed the player's re-spawn after death animation. The last frame of the player explosion was stuck. So I needed to sort that issue out. Next I worked on the kamikaze saucers routine. This was where flying saucers charge for the player, if the saucers are in range of the player ship. The routine worked for all of the enemy flying saucers, however there was still an issue. The enemy saucers charge towards the player constantly. The routine needed a timer. I created a timer, and I had the enemies charging towards the player on position - only if the timer has elapsed and reset. This made the kamikaze saucer routine much fairer, but there are still bugs in the routine. I tried to prevent the saucers from charging towards the player when offset. Hopefully on day 7 of this little project I should be able to sort this out.

11th October 2020

Just a load of random stuff

Today's session on this project has been pretty much a very long session. The first part was basically fixing the kamikaze aliens routine. The routine required being timed before an enemy could try and detect the place and then charge for it. 

After fixing the kamikaze routine. I did a fix-up of the enemy firing routine. First of all, the enemy firing was too rapid. Not only that. There was a case where aliens could fire when at zero position. So I decided to add some code which allowed the enemy to only shoot after a wait duration timer has reached a certain point, also check whether or not the alien was on screen or not. Then the enemy should fire a bullet.

Once that was fixed it was time to spawn random enemy types, colour and speed. The random position for each sprite was also read. I had to create some more pointers and expand the table of bytes. This was so that every time an enemy leaves the screen, or is shot, or kills the player. A new enemy comes out of the screen with a new colour, frame and starting position. Once I was happy with the result it was time to update the enemy to bullet collision.

The enemy to bullet collision originally cycled the border colour to indiicate an enemy has been shot down. That was not really how the game should operate. The enemy short should add a number of points to the score. So I generated a few pointers. This is because scoring points should vary on the enemy type. There are 4 different enemy types. The scoring system should work like this:

Enemy type 1 = 100 points
Enemy type 2 = 200 points
Enemy type 3 = 300 points
Enemy type 4 = 500 points

The low byte of the enemy's animation got stored into a new pointer called scorezone and then when calling the score routine, the scorezone code checked for the enemy type low byte value and then jumps to one of the scoring subroutines that added up the correct scoring amount.

I saved the updated source code, assembled the source code, I loaded in the game data and then started the game code. The game is starting to look quite promising, despite the ugly game background graphics, and a few minor bugs. Those will be fixed in the next session. Then hopefully once those bugs have been fixed. It is time for setting up the concept, game level tables, etc. This is shaping up quite nicely.

20th October 2020

Day 7 - Sounds like another unlucky evening.

Well not too unlucky. The project has been developing slowly, but there seems to be a few issues in the game. Aliens were still doing a Kamikaze for an incorrect period of time. I managed to fix this by setting the screen range for where the aliens are. If they reach inside the border, then they cannot charge for the player when the timer is set. I also forgot to disable the Y position speed of the alien. Every time it charged for the player it carried on doing so after leaving the screen. How wrong :). 

Now the annoying bug was fixed, and the alien appearances are more accurate. I thought it would be cool to create some in game sound effects for this game using Achim's SFX Editor V3.2. It made quirky sounds which I felt would suit the game. However, after setting up the SFX and getting them imported into the game's source. A fault occurred. For some strange reason, the sound effects wouldn't play but crashed the project. The SFX had a built in player and I was sure that I did the right thing.To be sure of this, I rebooted theC64 into BASIC mode, loaded up Code Sucker Monitor and created a test routine. I loaded in the sound effects (with built in player) and it all seemed to have worked fine. I went back into 6510+ assembler and tried again. This time the SFX did not play, and crashed. It turns out 6510 assembler has routines that caused the crash.

Day 8: 30th October 2020

I checked the same code and data files on the Ultimate 64 and I had a go at assembling and running. The code and game data was working with success. I went back to theC64 to see if I did something wrong. I loaded up the game data and also the source code, and sound effects. As with day 7 I did have the same problem as before. There was an issue with theC64 and the disk version of the 6510+ assembler. I tried loading the version from Power Pack 45. I loaded in the source code, game data and sound effects. It all worked without a problem. So the project can use the sound effects after all. More on this project tomorrow or Sunday

Day 9: 4th November 2020

Some bad news I'm afraid. While trying to tweak the code to fix the enemy bullet firing sound effects. While typing in 4707 ; I received an error statement, ?Out Of Memory. Unfortunately it looks as if there wasn't enough memory space for my game project. If this is the case, then this project may have to be cancelled and this will have been my first failure of theC64 challenge. I'll check this through to see if the same problem persists on my Ultimate 64. If it does, then this project has failed.

Confirmed ... The challenge has unfortunately failed. This does not mean that the game project is finished for good. I will be working around solving this issue, and continue on theC64 challenge using Turbo / Macro Assembler, if converting of the source code over this weekend goes to plan.

Day 10: 7th November 2020

The CF Power Pack game challenge sadly has failed, but this does not mean that I have decided to give up on this project. In fact, I have managed to salvage the source code and I have changed software applications in an attempt to finish this project off in time for the festive period. So that there are 2 new small TND games, instead of one. This really depends on time.

On the plus side, I have managed to salvage my source code on the PC with Style's DIR master, and place it into CBMPRGSTUDIO. The game project will now be enhanced and developed with this using PC based application. This will give me the opportunity to improve the looks and features for this project. 

I gave up on developing this project on theC64, due to the issues I had with the 6510+ assembler and the limitations of the other C64 applications. Yesterday I converted the 6510+ assembler source into a usable source for use in CBMPRGStudio. I also imported all of the graphics and sound files into the game's source code and assembled everything and test run. The code was working. I added some more code to the project, so that there was a Level Complete, and Game Over scene. Also the saucers needed to be fixed a little. The SFX of the missiles being dropped from the aliens were constantly playing. On Wednesday evening, I tried to fix this issue, but I ended up with the ?Out Of Memory issue in 6510+.  A check routine was needed to check for the position of the killer saucers before the bomb drop SFX was able to play. This

Day 11: 8th November 2020
 

I spent most of my time with this project today. I have jazzed up the graphics using Charpad, to make them look much nicer. I still have some work to do in the main game. Levels have not been set up yet, but the game is starting to shape up quite nicely. There is still a weird Kamikaze bug in the game where after an alien is shot during the Kamikaze it constantly goes down towards the player from outside of the screen. You will also notice that at the bottom, I have added a counter. This is going to be used to give the player limited bullets during play. The idea is that the number of bullets the player has left results to the bonus points added to the player's score. 

Now was the time to go back to the game code. There was a problem with the enemy position detection routine. For some strange reason, after the saucers were killed or attacked the player by kamikaze, the random counter failed to reposition the enemies. I located the sprite movement check and created a new set of pointers. Aliens refused to continue moving their last direction. So I had to make a backup routine. What it does is backup the stored horizontal directional speed of the alien after read through. I did an on screen test check routine where characters showed whether or not the aliens were moving outside of the screen. This test helped me fix a few things.

As soon as I got the saucers repositioning at a random vertical position and enter the screen. I worked on some new sound effects using Achim/Mayday's SFX Editor V3.2. This time instead of having 6 sound effects. I ended up creating 10 retro-blasting sound effects. I tried mixing some of the wave forms to give some kind of effect. I exported the sound effects into the project folder and I carried on programming. This time I set the sound effects to play at the right time. 

After completing the sound effects. A routine was needed to count down the number of missiles the player has during play. At the start of the game, the player ends up with 99 missiles. However, I wanted to detect the amount of missiles = 00. If the missile count = 00 then engage the self-destruction mode to the player and re-store the missile count to 99. There was a minor bug in the routine where the player didn't die straight away, but that soon got fixed.

Next I worked on rewarding the player bonus points during the game. Every time a level is complete. The player should have an additional 50 points awarded for every missile that has not been shot. I created a subroutine that did a count down  of the missiles that were left and I also played sound effects during the count down. Afterwards I set the level counter to increment then jump to the game refresh code for the next level (which has not been implemented yet, but it might do later on). 

My final task for today was to do something about the static screen in the game. The stars and the laser beams were just still. Something had to be done to make this worthwhile. I updated the in game interrupt to call one subroutine that animated the star field (so that each character scrolls a pixel of each star across 4 whole characters). I also added a routine that scrolled the laser beam two ways. This was to make it look as if two of the buildings was firing a laser beam or something like that. The game is supposed to be based in the future. ;)

It has been a long day, but quite an achievement compared to Wednesday's flop on the 6510+ assembler. Ha, ha, ha, ha! :)

The next task later on this week will be to create the actual levels of this game. Then later develop a front end/title screen and then make some music for the title screen. Then the final crunching and testing of the game.

Days 12 - 15

 
You may remember that on day 11 I had trouble with 6510+ assembler, and moved the game to CBMPRGStudio by salvaging it from the 6510+ work disk. I focused on fixing the bugs that were left in the game. Then I created and generated some levels. Although each level uses the same screen and sprites. There's some kind of difficulty implemented into the game. Each level was based on table of pointers. However after sucessfully nearly finishing the main game. 

Disaster had struck. I encountered a strange bug where a large portion of the code got deleted after saving. Luckily there was a backup file, which I restored. So thankfully the code was still there. However I did fill a whole lot of listings into a whole page. So I tried splitting the project into separate source files. I tried assembling the source. Unfortunately I ended up with too many errors in the compiler window. Due to the sheer frustration with the problems I had. I decided to convert all of the source files into C64 Studio/ACME format.

I worked on doing a title screen using CharPad V2.3 and imported the screen data to the project source. Then I programmed the main title screen. The idea of the title screen was to make it look pretty basic and quite oldschool. I set the title screen to use some raster splits over the logo. Also I added some scrolling colours inside the credits and flashed the scrolling text silver. The only thing that was missing here was a title music. I loaded up Goat Tracker V2.75 and composed a disco-style tune that would suit the title screen, using my usual SID disco style. I was pleased with the result and I decided to keep it.

The final part of the game coding was to add an end screen. I didn't want to make the game end completely as it was supposed to be a hi-score attack challenge game. That meant that after level 8, the game should start back to level 1 instead of ending. I created a congratulations message with a colour washing routine. Then after pressing fire, it takes the player to the very first level. I had a final play test of the whole game and it was seems to be working okay. I compressed with Exomizer.

I wasn't done with this project yet. The game was supposed to have been a C64 Power Pack Challenge. I decided to use the Ultimate 64 for the last two parts of this challenge (As theC64 even with the latest firmware did not support tape recording). I loaded up Idea's Saracen Paint (CF Power Pack 25) and I drew a loading picture to suit the game's theme. It was basically space themed with a logo in the middle, with my signature underneath the logo. After the picture was done, a .tap was created, where the picture filename was stored for later use. Then using the built in Action Replay. I saved the bitmap image to disk in Koala Paint format (For the picture linker code). The picture got linked to the game in C64. Then everything was ready for the final mastering stage.

Doing the disk mastering was pretty much straightforward. Basically I use Style's DIR MASTER to import the game project into a digital disk image. Then I jazzed up the directory with the usual TND magic. As for preparing the digital tape version. I loaded the tape version of Killer Saucers from D64 on my Ultimate 64. Then saved the game to tape using the standard Kernal save. It took about 6-7 minutes to save to tape. I loaded up Loader Maker by Jason Finch from Power Pack 37. I selected the Saracen Paint picture digital paint file. Loaded it up. Then I mastered a digital tape image of the game with the new loader and picture. What a great result.

The game was finally finished and sent off to my regular beta testers and (hopefully) you will get to play it this Christmas Day when I upload the finished piece on to the TND web site and my itch.io page. The CF Power Pack Challenge did get completed, but sadly it did not result how I hoped it would. Next time I write something on theC64 I will perhaps stick to Turbo Assembler / Turbo Macro Pro and the new Action Replay functions but of course I will have to avoid using accuratedisk, _AD functions) :)

Sadly this will be my LAST C64 production for 2020. My other game project is also finished, and will also be released on Christmas Day at http://tnd64.unikat.sk. I shall now take a well earned rest until 2021 :).

Hope you look forward to the two games I release Christmas time.

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.

theC64 Challenge 3 - The Forever Extending Snake

18th-22nd May 2020

I like theC64 full size. It gives me some great fun and challenges playing C64 games. But what if I wanted to actually MAKE a game on the full size computer? Well, first of all I am used to the cross-assembly/cross-compiling method in making a game. For many years, I written games using C64Studio, or ACME cross assembler. Sometimes on the Ultimate 64 I like to make little things like intros or demos. Some of my entries for the Intro Creation Compo 2019 were made on the Ultimate 64.

However, making a new C64 game on theC64 proved to me to be pretty much challenging. For a start, although I legally own an Action Replay cartridge. theC64 doesn't support freeze frame yet. So an alternative solution had taken place. I had fun writing Storm Chase during the winter of 2020 on the full size theC64. I fancied a challenge in making something slightly more advanced and different. I was going to do another of those typical pew, pew space shoot 'em ups, but at the end of the day. I decided to do something I had not attempted to do before. A Snake game, but with a twist.

On my PC I generated some blank D64's using Style's DIR master. Then I dug out a set of public domain utilities to compile on to an empty tool disk. The programs were as follows:

SPRITE EDITOR V1.2 by Faces
FONT EDITOR V1.3 by Faces
SCREEN EDITOR V2.0 by Small Change Software
STARTEXTER V2.0 by Starion
DEMO MUSIC CREATOR V2.0 (and separately, the music relocator) by Graffity (Although the file and intro mistakenly indicates it as V1.2)
CODE SUCKER MONITOR by Padua
TURBO ASSEMBLER by Omikron
XTC Packer V1.0 by Rockstar
FAST CRUEL V2.5 (From the Cruel Packet) by Galleon/Oneway

All of the tools above can be found at CSDB. 

During each session, I did save states of some of the development, in order to reduce the risk of losing my recently made files. After each session of creating graphics, music, etc. I save the files and eject the disk, and move on to something else. I had to do some of the same things a few times because for some strange reason, although I saved the files from the program in True Drive mode (which was automatically set by a default CJM file). I ended up with the unreadable *PRG splat files. It could perhaps be something to do with my USB - or perhaps I'm not using the computer right. I'm not sure, but I'm still on to the challenge.

Update: 23/05/2020: I can confirm there is a bug in true drive mode (accurate disk). It does write 0 "unreadable " *PRG on my computer. However if I disable that feature, it saves successfully. Good thing is, the programs I used had no software fast loader. So accurate disk wasn't really needed for this project.

Anyway, after completing all of the graphics, design, music, and other stuff. It was time for me to install the Code Suck Monitor. This was because I couldn't use freezer cartridges as they are not yet implemented in the current firmware. Each file had to be loaded into the planned addresses for the game project. They were as follows:

GAME CHARSET: $0800-$08FF
IN GAME MUSIC: $1000 - $1FFF
SPRITE GRAPHICS: $2000-$2FFF
GAME SCREEN AND COLOUR DATA: $3000-$37FF
TITLE SCREEN AND COLOUR DATA $3800-$3FFF
SCROLL TEXT: $4000-$47FF
GAME CODE: $4800-$5FFF
TITLE MUSIC (RELOCATED): $6000-$6FFF

I chose a relevant load address to set the M/C monitor specially for loading the files to their specific addresses. The Code Suck Monitor was placed at $7000. After a few saves and resets of theC64. I loaded in the M/C monitor and typed in SYS 28672. Then loaded each file manually with the M/C monitor.

L "GAMEFONT*",8,0800
L "GAMEMUSIC*",8,1000
L "GAMESPRITES*",8,2000
L "GAMESCREEN",8,3000
L "TITLESCREEN",8,3800
L "SCROLLTEXT",8,4000
L "TITLEMUSIC",8,6000
Since I didn't want to keep loading each file individually. I saved a snapshot of the saved files, then saved a complete package of the game files to work with as a single file:

S "GAMEDATA",8,0800,6EA0 

I exit the machine code monitor and load in the TURBO ASSEMBLER, used SYS 36864 to run the assembler. Then I worked on the code. First I mainly focused with the game's code, where routines should control the player's sprite, and move it around. Also the object and screen randomizer routines, which places specific objects. There was also the sprite/charset collision code. Two sets were made. The first set was, so that the snake is able eat or collide into objects as they appear, for example fruit, skulls and bombs. Fruit to give the player points, skulls and walls to kill the snake off, and bombs to clear the screen and also get points for a screen clear.

After the main body of the game code was done. I worked on the front end code. Then added the GET READY and GAME OVER sequences. I ended up with a full game. Now was the time to try and put the game together.

Putting the game together:
In order for me to put the game together. I had to assemble the finished code (saved first) to disk, and then save the target. Before I could do that, I did a save state for just in case something went horribly wrong. After saving to disk (in Turbo Assembler it is BACK ARROW and 5). To assemble and manually RUN the game without setting the target disk, is BACK ARROW and 3).

I reset the computer. Then I load in the Code Sucker Monitor. SYS28672 again and loaded the saved game data file. Then afterwards I loaded in the code object file, which was assembled to disk. Then I saved the file completely as a single file again using:

S "GAMECOMPILED",8,0800,6EA0

The game could not be run from BASIC. So I used the XTC Packer V1.0 to charpack compress and make an executable in BASIC. I reset the computer. Loaded the saved file from BASIC and RUN it. The program unpacked and run flawlessly.

Phase 1 was complete. Now for phase 2. Linking the TND intro presentation to the game. I ripped the intro from one of my previous game creations and put it on to the work disk. Then I use the M/C monitor again to load the TND intro and then load the game to $2c00. I then saved the intro from $0800-the end address of the game. Reset the computer, used XTC Packer V1.0. Then crunched the game with the Fast Cruel V2.5.

I then reset the machine. Loaded the game, then typed in RUN. The game loaded, de-compressed and then run. Resulting with the final production:

All there was to do was to prepare the disk with the code, game and other bits together. This was done on the PC using Style's DIR Master.

The game is currently under the final testing / bug fixing phase, but as soon as it is complete. The game will be released on to both of my pages:

The Forever Extending Hungry Snake

and

The New Dimension

Here's a video of the game in action:

Lockdown and Loaded

13th March - 6th May 2020

Like many of you, I have been stuck indoors in lockdown. While this lock down has been in place I have been very busy on various C64 game projects. I managed to complete a few over the past 2 or 3 months. Since 15th March 2020. Since I suspect you probably be interested in reading about the game projects, rather than lockdown and all of this. Here is the line up.

Nucleo 448

I teamed up with Leonardo Vettori, to help him improve his game Nucleo 447, by giving it a set of in game enhancements. The game was of course renamed Nucleo 448. This game was originally an entry from last year's Official C64 SEUCK Compo 2019 compo. I helped Leonardo ramp this game up to be more playable and fun. With aid of Martin Piper's framework for SEUCK (SEUCK Redux). Nucleo 448 had a new front end presentation power ups (which allowed the player's bullet to fire faster), in game trance music and also enemy fire AI.

Toilet Paper Stacker

I launched a Lockdown fun compo 2020 on CSDB, in which people could enter the compo and submit either a game, demo or graphics. Music was ruled out of the compo, because there was already a music compo in place. Toilet Paper Stacker was one of these stacker type of games, with a funny theme based on past events. The idea of the game was to stack over sized toilet roll on to a cabinet so that it breaks and kill the virus.

Zzapped in the Butt

Craptastic 2020 was launched earlier on this year. Zzapped in the Butt (Guess where the name ZZapped came from ;)) is a retro style space shoot 'em up. A mother ship is waiting to invade planet Earth, but cannot enter the Earth's atmosphere. So instead, it sends out various aliens to help invade the planet. The ship has to defend its military cities from aliens. The mother ship also decides to attempt to zap your ship in the butt. The game consists of more than 30 levels. Everything crammed into 4K. Expect to see that appear on your C64 in June. :)

Cruiser X-79 (Still in progress)

The vertical scrolling shoot 'em up game project was delayed for some time, but now it has come back in action. New alien movement patterns have been added to the game's code. Not all of the aliens have been put in place, as there are still some more movements in operation. A lot more work has been put into the game project today. Where, I try and restore the alien sprite/sprite collision and do a bit more debugging. Hopefully some time later on this week (or perhaps next week) I should be able to try and restore the game's main game play and get those aliens happy blasting.

All of these games can be found and downloaded from THE NEW DIMENSION for your C64, Ultimate, or theC64

(Except for the latest Cruiser-X 79 preview and Zzapped in the Butt)

Aliens Unleashed

23rd March 2020

Last Saturday, I mentioned about the problems I had with the alien movement patterns, where I made things a lot harder for myself. Especially the previous weekend. This weekend, I started on working on the alien movement groups. After Saturday's major change of the code and pointers. After following the Starfysh code, I finally got somewhere and I am now ready to continue with working on the alien movement groups.

Alien movement is based on time instead of position. Once the timer table has reached the end, the next group of aliens can spawn. I have a lot more groups of aliens to work on, which will take some time time to make. Or should I say, a lot of time to make. Especially when the total number of enemy sprites drawn result to 26. I have used the border cycle on screen as a clock, so I can count which byte the table is read at, and also where I should time out the aliens to stop them wrapping across the screen.

On the plus side, since the game preview was released Summer last year. The majority of the game code is still there. Although at the moment I have disabled the collision, in order to test the aliens for their movement.

The new set of tables are as follows:

enemy1framelo !byte <Frame_AlienType2 ;Store low-byte of alien frame
enemy1framehi !byte >Frame_AlienType2 ;Store hi-byte of alien frame 
enemy1colour  !byte $0a               ;Store colour of alien
enemy1startx  !byte $0c               ;Start X-Position   
enemy1starty  !byte $f0               ;Start Y-Position
enemy1score   !byte $01               ;Amount of points to score
enemy1lives   !byte $01               ;Number or hits to kill alien
enemy1time    !byte $18,$18,$18,$1c,$18,$18,$18,$18 ;Timed movement
enemy1speedx  !byte $00,$00,$00,$00,$00,$00,$00,$00 ;Speed of movement accordingly X
enemy1speedy  !byte $fe,$fe,$fe,$fe,$00,$00,$00,$00 ;"                             Y

Aliens in self-isolation

21st March 2020
 
This post is a quick update on the Cruiser-X 79 project. Unfortunately, once again I made things much harder for myself. Last week's post caused me more trouble on the project, instead of making things easier for myself. So once again I deleted all of the alien movement/spawning code which I started last week. I made an alternative plan for the aliens, which is to basically use a timed movement, similar to Starfysh, rather than a positional movement trigger. . This will reduce the amount of programming I would have to do for each enemy. On the plus side, the Starfysh method is a whole lot easier to master. Mind you, I will be using more than just 4 bytes on the table to move those alien groups. Wish me luck :)

Where have all the aliens gone?

14th March 2020

Great news. Cruiser-X 79 continues this month. Today has been quite a long session. You might probably notice that the game was delayed for a very long time over several months period. This was mainly because of some other game projects I was working on. Happy Blocks DX, Amazon Tales, Mega Tank Blasta, Toxic (2020 Edition). Amazon Tales was made as a practice piece in order to attempt to develop custom enemy movement patterns which didn't require wasting $200 bytes of data. Plus I wanted to add a mixed batch of enemies in to the game project.

Since the game engine in Amazon Tales was successful. I have decided to try a similar attempt for Cruiser-X 79. In order to do that. I have to start the enemies attack patterns from scratch. Before I could do that, I had to delete the existing alien attack patterns. Therefore on today's build of the project, I concentrated on setting up table values per enemy type.

For example:

Alien1SpawnX = The starting horizontal position for the alien to spawn from
Alien1SpawnY = The vertical horizontal position for the alien to spawn from
Alien1Dir = Direction for the alien to move whilst in operation. 0 = Up, 1=Down, 2=Left,3=Right. This consists of a table of 8 bytes (Since the aliens are supposed to switch to the next direction every time a path limit has been reached).
Alien1Speed = Speed of the alien which is moving, once again 8 bytes.
Alien1ChangePosition = Horizontal or Vertical position in which the alien must reach before it can change to the next direction (or leave the screen)
Alien1ObjectLo = Low byte of the animation frame read from the sprite animation subroutine
Alien1ObjectHi = Hi byte of the animation frame read from the sprite animation subroutine
Alien1Colour = Alien sprite colour
Alien1Lives = Amount of lives the alien has before it can be destroyed
Alien1Score =  Multiple number of points to be scored per alien destroyed

I also made different lo/hi byte tables which should somewhere in the game code (once implemented) copy the self-modifying pointers in to the correct self-modifying code. For example, after the last change position has been breached, and all aliens are off set. A new group should spawn.

For now, there's no aliens in this current build, because the code needs to be started from scratch. This will be continued during my next coding session on this game project.

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!

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.

theC64 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.

CHALLENGE #1 - OLDSCHOOL INTRO

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

Coding/Linking:

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)


Compression:

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