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!

Enter the tiger

18th October 2012

Today's session on Amazon Tales took a while to work on - especially for the first level. But things are starting to shape up quite nicely. I worked on creating more enemy tables for varying the different types of enemies on screen. Although the result still doesn't look correct and the movements are too plain, I have a few tricks up my sleeve this coming Saturday. I also added a new enemy (which consists of sprites), which are the big tigers. :)

It took me a few hours to think about and work on the new extended tables for the sprite animations, start position, movement, etc but so far a not bad result. Check out our latest video showing the progress of the game so far :)

I've got the power

12th November 2011

Today's been quite a long session (Drinking lager, oops, no. Wrong!) working on finishing off Woolly Jumper, 16K version. I have been working on making some tweaks and improvements and also added some power ups to the game, which will enhance game play for the player. Especially when he collects power ups. I also added a random table so that we have different power ups appearing on screen. The powerups are as follows:

- Vaccinator (Power up fire power)

- Sheep Shearer (Award 500 points to the player)

- Drencher (Restore fire power to the weakest bullet)

- Cattle Prod (Avoid at all times, it will cost a sheep's life)

The firepower is something as follows:

- Tiny ball of fluff (Small bullet, slow)

- Medium ball of fluff (Medium bullet, moderate speed)

- Mega ball of fluff (Huge bullet, ultra fast)

I have also been working on upgrading the collision to see whether or not the player can respond to the stopping chars. Sadly this feature didn't work properly for level 8 (The great white rock) and it ended up pushing the player all over the place. This caused an unknown bug, which I don't really know what has been causing it. The level design for just the final stage needs a rethink.

Well, we are nearly there. Hopefully the game will be ready a week before the deadline.

We are on whistle blower alert

6th November 2011

It's just a short one today, because I have been working a very early 6am-2pm shift at my local distribution centre. And right now, I feel very tired, especially after going out last night. 5 and 3 quarters hour sleep (Although there was a party next door full of youngsters partying with fireworks). Anyway here's what has happened today.

I received an email from Shaun about an object which the player can collect, so it can move on to the next stage. Brilliant, that's helped me a lot. I imported Shaun's whistle (And painted it cyan) into the game source code. Then I programmed a simple box collision, where the player picks up the whistle. If the collision occurs, the rocket will appear on screen and pick the player up.

The second and final thing I did today, due to tiredness was added a little routine, to stop the player from holding the fire button, making the player constantly shoot, also to avoid the title screen skipping sensitivity.

Well, it looks as if the game is nearly finished for the 16KB cartridge compo. I just need to tidy a few things up, which I should hopefully get round to doing this week. One of which is to create random power ups through a timer, and also fix an additional sprite/background detection in which (during parts of the game) the sheep cannot walk through the rocks of level 3 and 8. If the game turns out to be larger than 16K then I'll have to compose some music for just the 16K version of this game, using the John Player. Toodloo, until Friday!

It's getting there ... :)

5th November 2011

Things are getting on pretty well with Woolly Jumper and I feel that I could be nearly finished with the 16KB CRT version of this fun game project. Well, estimated time for finishing the 16KB cartridge is probably between next week and 20th November 2011. I am dedicating myself to at least one hour to this project during my spare time all this week, as we are coming closer and closer to the deadline.

So then what has been happening today? Well, basically I have been concentrating on some minor bug fixing and also getting the enemies to roam across the screen with their new attack patterns. So how did I go around to working on those? It started with some experiments with sprites. Before I could build the sinus patterns, I had to work out the starting and ending position for where to put the enemy sinuses. To be able to do this, I did a little poke that would display a square sprite. Did a little maths to work out the: start and stop position of the sprite sinues for the top, middle, and bottom portions of the screen. These mainly took effect on the penguin ships, green alien saucers and chickens. The meanest enemy of them all were the pink bugs. The bugs have a different kind of behaviour compared to the three aliens (penguin, green saucer and space chickens) . The bugs shall also be appearing less frequently, compared to the other aliens.

After programming and storing the new sinus movements for each enemy, I restored the sprite/sprite collision and discovered a silly bug. For every second enemy shot, you could see an explosion appear again after the death animation had finished. That was one heck of a daft mistake I discovered today. To to fix that problem, I added a routine that switched off the enemy dead mode, so that the enemy is offset. I also made it so that the enemies don't appear on the screen, or move in a Y-axis if they are supposed to be offset - and it worked.

The last thing I did today was added a little ending to the game, for after the final level was complete. It was something too basic, but because of size restrictions, I was unable to do a very good ending - but the full game will of course have a better ending than what I did for this version.

The hobby project continues through to December after the .CRT version's finished!

Kung Fu, POW!

27th August 2011

I was going to do a little more on Woolly Jumper today, but decided to leave that until Wednesday afternoon :). Instead I received some text and graphics for the ending of 2000 Kung Fu Maniacs. The hardest part was actually getting the actual .C64 file to save in CCS64. The best option I had was to store the all data (For the ending) and put that on to a .tap image. Load in the Sideways Scrolling SEUCK in WinVice, and then load the .tap image into it. That method worked quite nicely. I watched the example of the end. It looked interesting, and I thought to myself that it was most definitely worth a try.

Before I got into the programming side of things, I had to try import the charset from the SEUCK ending into Cuneiform. Then import the font that Alf made for 1000 Kung Fu Maniacs. We imported the files okay into the PC C64 char editor, and I copied the background chars (which formed the Master of Exposition's HQ) and put it into place with the 1x1 charset, which I used for 1000 Kung Fu Maniacs. I save the charset data, and raw data as well. Now was time for the next phase.

Because I can't really use more SEUCK background for the ending, I decided to import the character sets into the Graphic Editor by Firebird Software. It is quite an interesting piece of kit for the Commodore 64. So I loaded it up from the original .tap file that was created using the DC2N. Set Vice to warp speed so that the program loaded quicker. Then loaded the charset in. I also opened another window with VICE, and the Sideways SEUCK with the work file which Alf originally made. I then designed the background (Made it similar to the SEUCK background) although found a slight glitch in the FB Graphic Editor. The white pillars should have been hires, but they seemed to have ended up in multicolour instead. I then captured the image with the Retro Replay and used the MC monitor to transfer the screen to $2000 and colour to $2400. I then saved both files and then imported those into the ACME SEUCK Enhancements project file for 2000 Kung Fu Maniacs.

Next I copied Alf's text and I input it into the ACME cross assembler source. I saved and imported the sprite data into Spritepad 1.8, and I selected the sprites that were used for the ending. I also used the sprites of one of the enemy ninjas as well as the player - for the Get Ready and Game Over sequences. That will do for today, as I'm off out in a few minutes time :)

28th August 2011

Today was probably the most important of the day with 2000 Kung Fu Maniacs, where it comes to the end part. I have decided to program it in today. Mainly because the end part will probably be one of the longest parts to make in assembly before the Front End, Get Ready, Game Over and High Score entry parts :). So I programmed each frame, checked the ending out. Had a few problems at first, but they were resolved. The ending features the Master of Awesome and the Master of Exposition. But I will not tell you what it's all about though. It's a big secret and pretty much a funny ending :) There's still something that needs sorting out with this ending. Getting the background's pillars the correct colour. That should hopefully be no problem. :). On to Woolly Jumper on Wednesday. :)

Another Last Amazon front end

Tuesday 7th April 2009 + Wednesday 8th April 2009

Bah, TV sucks. Well that doesn't surprise me. I had nothing else too exciting to do, so I decided to work on a new front end for Last Amazon 2. This time it was a bit of a challenge, but I knew that it should be possible. I prepared a work disk .D64 and transferred all the C64 files into the cross-assembly directory for use with ACME, the same way as I did with The Last Amazon.

Kenz had shown me the mock up screen shot of what he would like me to do for the front end. Oh no ... raster splits :( Seriously, I hate doing raster bars, due to having to get those blasted things timed correctly inside $D012 splits. Ah well, it has to be done, and I shall do that.

I loaded up the Relaunch64 tool and then I created a main source file which will link all the c64 program files (including the game) and got started on the programming side of things. I started off with the IRQ interrupt player routine to see if it will run. The good news was that the player routine did play the music after assembled and crunched with PuCrunch. Now it was time for the serious part of the programming. Getting the bitmap logo and all chars displaying. To do this, I changed the background colour ($D021) so that all small text was white and all large text was yellow. So I built 10 raster splits in total. Everything displayed successfully.

Now it was time to add those raster bars into the text. Well, this I must stress was one of the worse parts of the front end programming. So I built a colour table and a raster timing table for each raster split. It took a lot of time to time out the raster splits so that the text chars looked much more tidier. As soon as I was happy with the result, I worked on the scroll text routine (Which uses raster splits as well) and then added a routine for which the player can press fire in either joystick port to play a 1 or 2 player game. Those worked okay, but sadly timing had altered again. So I moved the raster timing table and also moved the scroll text to a higher location and got everything working. Looks perfect now. Hope Alf and Kenz likes this one.

A Last Amazon master

Monday + Tuesday 31st March 2009

After tea this evening, I decided to work on a loading tune for the first Last Amazon game. So I dug out the DMC V5.0+ music editor and loaded in one of my old work tunes. Kenz fancied a Matt Gray(esque) style tune for the tape loading music. So I loaded in one of my tunes that I done for Last Amazon 2, and then I made a new atmospheric Matt Gray(esque) tune for the loader. Once I was very happy with it I worked on the main tape mastering for the game.

But there was something I just could not resist for the tape loader. Because Martin Piper had done a turbo tape loader routine with a flashing/pulsating sprite. I thought to myself, hmm. I could do a tribute to the classic Cyberload tape loader, but without the CYBERLOAD NOW LOADING GAMENAME thing and draw my own flashing square sprite (But make it look different to the original Cyberload sprite). I positioned the sprite at the bottom and in the middle of the screen and then linked the game music, loading picture and game files into the source code of my version of Martin's loader and then compressed the assembled source and data using the Exomizer, and tested the tape master. Magnificent. I was very pleased with the loader result. I will send this off to Kenz to check out to see what he thinks of it.

DIY Slang :)

Sunday 29th March 2009

Ah. There is nothing quite like a Sunday playing around with SLANG. Well, XLANG really from http://www.ffd2.com/fridge/slang/. What is it precisely? Well, it is a cross-platform programming language that combines sort of BASIC commands with assembly language. Pretty okay stuff if you want to build simple programs to help you do things.

Well, that is what happened this morning. I was writing some commands in the Relaunch 64 text editor, to program some XLANG routines as well as assembly code routines to create a little program that could help me convert pictures that were saved in Vidcom Paint format into one of my own picture formats, so that I could make a much easier tape loader using the Auto boot IRQ Turbo Tape loader source from www.codebase64.com. But I wanted to make a few simple routines that will display the tape loading picture, along with music in the background. After I compiled and compressed the utility. The size it fit was 1K, after Exomizer. A 4 block program? What a result.

I tested the little utility that I made on the C64 and the utility worked fine. So I took one of my old C64 games, repacked it and then I modified the public domain IRQ turbo tape loader source so that it could do the following:

Optional flashing/loading sprite at $0200-$0280
Loading music at $1000-$1fff
Picture data (All bitmap, colour RAM and video RAM in one single load) - $2000-$47e8
Game data $4800-$ffff ;Smaller size is usually preferred.

Of course the game data would not be able to run straight away. So I added a transfer/relocator routine, so that the game that uses a BASIC SYS 2061 address will move from $4800-$xxxx to
$0801-$yyyy and then execute Exomizer's decrunch routine. Loading speed was fast. I sure will use this source for The Last Amazon tape mastering when it is time. :)

A bit of Trash Course

Monday 9th March 2009

Well, no blog over the weekend - how unusual. Nothing much happened, except for that I have been rather ill the past 2 days and today, I feel much better. Man, I really hate those coughs and colds and I do get it bad!

After a hard working day, I checked one of my emails and Thorsten (Sledgie), from the C64wiki.de, asked for some help with his game project, Trash Course. He came up with the idea that we could use the Gold Quest 4 background graphics using the Sideways SEUCK engine (If you want Sideways SEUCK for your C64, please visit this page here.) Well, the good news is that the block data converted fine, but there were some problems. The roads that I designed were black and Thorsten could not get the rat sprites to blend well with the background, and suggested that colour should be changed. So the roads were changed to dark grey. I also modified the colour of the windows and doors, so that inside, windows were blue, and the door was black. Of course I could easily make more blocks to have different coloured doors, but to be honest I cannot really be asked at this moment in time.

A later email from Thorsten asked me if I could add a new character to the game. Some cheeky dogs. Well, that was easily sorted out and did not take me that long to make. I went to the sprite editor in Sideways SEUCK and then I drew 8 frames for the dog. Drawing the dog facing upwards was very awkward, but that did not stop me from trying. I loved using SEUCK in my old childhood/student memories, and it was great to be back on there again.

After I had the 8 frames for the dog, I created 6 frames for the bone (Which of course will be the dog's bullet). Then I went into the objects editor and made some corrections to some of Thorsten's enemy settings. Then I made some new settings for the dog and the dog's bullet. As soon as the settings were updated for the enemy, I copied the same enemy 3 times and used 2 new colours for the dog objects.

Now I done a test in the attack waves editor to see if all was working correctly for the dog. Seems it worked alright. I just hope Thorsten likes what he sees so far and that he will be happy to put up the level data for the first level up nicely so far.
The production is still at its early stages yet, but should be something fun for SEUCK lovers out there, once Thorsten has built all the levels and I added the enhancements and new front end to the game.

Enter the cheetah!

1st March 2009

I read my emails and one of the messages was from Kenz, about the new front end for The Last Amazon that I sent him yesterday. There were a few things missing. I had forgotten to credit him for the logo and also I did not add the Last Amazon's eyes to the end of the fading text. So I worked on the front end a little more and added the missing elements. Now I tested the front end. All was okay, apart from the eyes. So instead of using the !SCR command, I used the !BYTE command, and set values for the eyes chars and .... it worked!

Now the front end (as far as I know) was finished, it was then time for me to add a game over routine for after the last life of the player is lost. Kenz came up with a great idea for the game over sequence, which is to have the Last Amazon running across the screen, and then have some cheetahs chasing after her (Din-dins for the cheetahs). So I ripped some sprites from the game, and stored those to $6c00-$6d00 and imported them into the game over source. I then programmed the game over screen in ACME cross assembler, making new interrupts and sprite expansion routines. Once I did all the programming for the end screen, I bolted it to the SEUCK game and tested it. The game over sequence works nicely.

For the final stage of this game, I programmed a small end screen, which shows just yellow text, using the 1x1 charset and linked the ending to where the SEUCK game scroller loop routine was. For the final test, I played the whole game in cheat mode to see if anything was wrong. It seems that everything was fine. Hopefully another Last Amazon front end finally finished. Finger crossed!

Now that was done, I dug out some tunes for The Last Amazon 2 (I will be doing a new front end and enhancements for this game when the first Last Amazon game has been given the OK), and relocated those. Then I loaded up the Last Amazon 2 SEUCK game and added the music to the game, and compressed it with Exomizer, disabling the effect when uncompressing the file and then I put both Last Amazon games on to the .D64 and sent it to Kenz.

I also could not resist playing The Last Amazon 2. It is another of Alf's memorable classic SEUCK games. Alf made many excellent SEUCK games with the great SEUCK editor. I have played many of Alf's classic SEUCK games in my time. I used to love games that were in the Cops series, and also Archetype was one of my all time favorites.

Once again in the Amazon

28th February 2009

Well it seems as if I have been rather busy on the programming side of things today. Kenz has sent me a .d64 with the enhanced version of The Last Amazon. (See his blog here) The game sure was cool with bonus weaponry, and also the animation of the flowing water was excellent.


Kenz showed me a .gif preview of the type of Front End he would like for this game. It seems to me that he wants a very simple front end with a bitmap logo at the top, a 2x2 charset in the middle of the screen and 1x1 charset at the bottom of the screen. So I took all of the main SEUCK game files , relocated the tunes for the game, and also the other bits of data and created an ACME cross assembler project then I worked on the main code and compressed it, and my result turned out the same as what Kenz expected on the the .gif image example he showed.

Although Kenz did send a text file for me to add to the message lines, I was unable to add the eyes graphics, and numbers, because the text data was being used as !SCR commands in ACME cross assembler. So some of the things had to be left out! After all programming and testing, it seems that I have got a nice result!

Hear the jungle drums playing

23rd February 2009

I was in a music mood today, so I decided to dish out the Demo Music Creator V5.0+, improved by CreaMD/C64.SK (Also available from my web site of course) and do some serious music composing for The Last Amazon 2, as this was the only game that was one game tune short.

I loaded up one of my old tunes and modified some of the instruments slightly. It took about 45 minutes or so to compose, and I ended up with a Tusker-loader(esque) tune in the style of Matt Gray (I loved the original music featured in such a great game by System 3). I kept on playing the tune in the background and boy it did sound catchy. I do hope Kenz and Alf will like this tune.

Now that all of the game tunes for the Last Amazon games are finished, just 2 or 3 more tunes to go for the tape loader. I think the tape loader should use the famous Cyberload colour bars and also a flashing square sprite in the middle. So Martin Piper's IRQ tape loader/master source with some modifications, which I done to display loading picture, etc. should do the trick, quite nicely, just like I did with Egg Catcher as an experiment with the loader source, but I shall remove the 3 digit clock as for picture displays, etc. That'd be rather useless! :)

Lost in the Amazon!

22nd February 2009

Today I have been busy, programming a new front for a Psytronik software SEUCK game. I was given a .c64 image one of the games in the The Last Amazon series. Because I am not all that comfortable with CCS64, I decided to make a .tap of the Sideways Scrolling SEUCK game (Left version as there was no right scrolling version) and then save i to the .tap image.

After I saved the SEUCK game on to a .tap image, I loaded the .tap into WinVice which took some time to load - the stripes are strange? I thought SEUCK used multicoloured stripes like Novaload originally did.

After the game loaded, I filled unwanted data with zeroes (Between $6580-$b6c0) and edited $54EF from LDA $8000,y to LDA $5000,y so that the enemy bullets in the SEUCK game will fire on a random basis. I created a work disk and saved 2 separate files for the SEUCK game. From $0900-$6580 and $B6C0-$FFFF.

Next I loaded a disk with a few different files which Kenz supplied me. The disk contained the logo files, and loaded up the Vidcom paint image and saved the image as three separate files on to my work disk and I also saved the 2x1 charset on to the disk as well. Then I drew some sprites using Faces's Sprite Editor.



Now the next thing for me to do was to extract the title and game music by WAZ, from the very first Last Amazon game (Which was suggested by Kenz that I should use this music for the front end of this game). So I saved two separate music files in Voicetracker/Music Assembler format. Then I loaded up the Dutch USA Team Music Assembler and relocated the tunes to estimated possible locations for when I write my new front end for the game.


Once the music was saved, all I had to do was prepare my cross-assembly project, by making a new folder and put all the C64 data into that folder, along with the and also the ACME cross-assembler and also the brilliant Exomizer cruncher.

Now that all files were prepared, I opened Relaunch 64 and I did a test build of the game, by linking all C64 data into the source, using the !bin "filename.prg",,2 command. So as a small test I entered the two SEUCK files and compiled the source then used the Exomizer to compress the data down and tested it all in WinVice.

It seems that the SEUCK game worked, so now I linked all C64 files to possible locations in the source and got ready to program my new front end for the game.

The first thing which I had to do was make some source files for the scroll text and also the front end text. After that was done, I worked on a once at a time run routine. This is where defaults will be set on the title screen for the very first time after decompression had finished. Next I added a routine that turns off all interrupts and a delay routine, so when game is over, the title screen is delayed for a very short amount of time.


Next I added a colour and screen routine, for displaying the colour data for the title screen text and also the logo's colour data. Then I worked on with the main IRQ interrupt routines. Before I did this, I switched off the KERNAL by setting #$35 at $01. This allowed me to use higher memory after $a000-$ffff, except for memory between $d000-$e000, which obviously needs to be used as POKE storage lines anyway!

Now I programmed the raster interrupt init routine. Usually I use the KERNAL $0314-$0315, but this time I used something more complex, which was $FFFE and $FFFF. This made IRQs longer, but I did not need to use KERNAL.

I used 3 IRQs to make 3 raster splits. The first one was for the scroll text, the second was for the bitmap logo and the last one was for the still text. I had to fiddle around with the charset values, so that I could display a charset that was at $7000 while screen memory is at $7c00. I managed to succeed to display the logo and the static 2x1 text.

After the success of the splits, I was programming the 2x1 scroll text, until I came across a problem. After assembling and compressing the program, no scroll text displayed. There was a problem there. I was scratching my head wondering what was up with the routine. Well, the routine was correct, but the scroll text was being pasted at the wrong screen memory. I used the $0400-$07e8 screen RAM instead of the $7C00-$7FE8 screen RAM. Hahahaha, how dumb was that? :oD. After I changed the scroll's screen memory I got the text to tick along the screen. There was no smooth scroll, but I managed to fix this problem by updating the bottom split, so that $D016 was run by the scroll control code.

My next step was to add and position the sprites and expand the sprite positions. So I used the typical software sprite expansion mode which I used for many of my games and programs, by ROR-ing $D010 as usual. I got the sprites to display, so now it was time for me to do some functions for the sprites.

So my next job was to program the options routine. This had to be done where the joystick direction from either joystick port can choose the number of players or to choose music or sound effects, pressing fire will take the player to the game. This was done by creating some labels and routines, that could display the correct sprites that correspond to the option the player selects. There is more to it though, because as well as sprite options, I needed to program the functions for each option, by building some extra routines. Just simple pokes really.

Where I had to program the in game music function. I had to put BIT routines where the SEUCK was playing the sound memory for the game sound effects. I also had to add a poke that would initialize and play the in game music, without being interrupted by the sound effects. When I tried this, the routine unfortunately crashed. I found out where I went wrong here. I was POKEing the wrong address, which was somewhere in the SEUCK's IRQ memory. That was bad! I managed to fix the routine by using the correct address to POKE for initializing the in game music.

The sound effects bit was similar to the in game music method, but I had to restore the correct poke values for the where sounds originally had BIT next to them and should be replaced with STA only for sound effects. This worked successfully.

The only thing that was missing in the game options was the player options, so I added some routines to select between 1 or 2 players by using the standard SEUCK player mode pokes. This worked a treat, and I was happy with the final result.

To end it all, I added the typical Richard Bayliss colour wash routine on to the scroll text, so that there is something interesting going on in the front end. Hahahahaha.

Now all I had to do was have a quick test to see if the game is working. Well, seems it is working at the moment. After game was over, I decided to test the whole game to see if all works. Well fantastic news. The game works, no crashes or missing sprites. Fantastic!

Now I shall send it off to Kenz to look at and also pass to Alf to see what he thinks of the new front end bolted to his magnificent sideways SEUCK game.

A new intro

21st February 2009

As well as my normal C64 web site, featuring my own game productions. I have finally built up a blog page for anyone interested to see some of the things that I get up to and what I have been doing as well.

I have been doing a bit of programming this morning in ACME. Well, I did originally start is a few days ago. About a few weeks ago, somebody had emailed me a TND logo, so I decided to program a new TND intro, using the ACME cross assembler. I had a few slowdowns with this piece of code, due to making little mistakes with the raster time. I even had crashed the C64 by making a typo error with the 2x1 scroll text display routine. After the typo was fixed, the intro finally turned out pretty nice. I might use that for any future games, demos or utilities I write :)

Here's a video of the intro in action (Recorded in WinVice and converted to MPEG)