TND Productions, C64 News + Updates

(Last updated 17 March 2021)

Added VICE + Exomizer tips on how to save your finished game and crunch it as a whole without additional cartridges

Important notice:
All of these SEUCK enhancement tips mainly involve programming 6502 assembly. Action / Retro Replay, TASM/Codenet is recommended if you are using a C64 with 1541Ultimate 2 cartridge or Ultimate 64. The tips might work on other programming software. TND tries to make SEUCK enhancement tips as easy where possible.

For those who want to use crossplatform. It is recommended you download the SEUCK Framework to use in C64Studio with Exomizer.

Making your game single file
Action Replay freezer and backup tips /
Housekeeping; Cleaning, Packing/Crunching SEUCK
/ Using VICE Monitor and Exomizer (I got no Cartridge Method)

Bugfixing and PAL/NTSC fixing:
Fixing Sideways SEUCK Flicker / Fixing Player 2's score per object collected / Working the PAL score on NTSC machines
Player properties
/ Controlling 2 Players with 1 joystick / Peek-A-Boo Hide and Seek / Decorate my Score Panel / Hires/Multicolour Sprites
/ Player Re-Spawn tips / Linked Players and Score + Lives Sharing/ Status Panel Hack trickDirectional Movement using More than 2 frames
In game enhancements
/ I want Big Aliens / Level Detection - Colour changing
/ Common SEUCK Subroutine Tricks / Power Ups and Detecting an enemy hit / Destroying all Enemies on screen in one go Background Animation and Push Parallax Scrolling Full Level Control (Stopping a timed STILL level / Making Jumping/Platform style games out of SEUCK / Flip Screen Techniques/
/ Background Terrain Tricks (Detecting Background Char type)
/ Getting to know the Front End  
// Adding some music SEUCK Front End - Hi Score DetectionAdding an Invincibility Cloak to the Player
Media + Resources
/ The SEUCK Vault and  SEUCK Enhancing Videos
/ SEUCK Framework / SEUCK REDUX / Kick Assembler SEUCK Framework V1 / Kick Assembler SEUCK Framework V2 / Kick Assembler SEUCK Framework V3 / Kick Assembler SEUCK Framework V4
Special features / Complete projects:
Dark Force Disected

Greetings students. Welcome to SEUCK School. The goal of this page is to try and help you be able to help you IMPROVE your own or friends SEUCK creations. On this page, come some random tips and tricks. However before all this the first step is to try and learn the BASICS of assembly programming. As this section requires a bit of programming knowledge and BASIC concepts. I recommend you check out CODEBASE in order to learn a bit more about assembly hex/decimal, but this school does give examples of some things for you to try. Have your Action Replay / 1541U2 / Retro Replay / Fridge Freezer at the ready. Now and then this page will be updated as any more tips/tricks pop by. It is also WORTHWHILE check out Jon Well's tips on THE SECRET OF SEUCKCESS @ THE SEUCK VAULT . It features BASIC type ins and also some additional memory locations of where various game code and features  lie. PLEASE NOTE ... C64 tools which are used in this tutorial selection can be found on, otherwise specified.


1-Filing Seuck Games with a Freezer Cartridge

Method 1:Saving a SEUCK game as one file with the Action Replay / Retro Replay freezer cartridge

This is probably the most simplest approach of them all. Most SEUCK users have used this method for many years or so. First of all load in your SEUCK game by typing in LOAD "MYGAME",8,1 and wait a few minutes for the game to load and run.

Now after the game has loaded, press the FREEZE button on your Action Replay / Retro Replay Freezer Cartridge, then press F1 to go to the backup menu. Select the disk save method you wish to use (Turbo is best for speed - not warp mode, as not everybody can run Warp mode!). Reset your C64 and load in the game, and type in RUN. The program will unfreeze your SEUCK game.

Method 2: Saving a SEUCK game as one file with the Action Replay freezer cartridge more professionally

Although a SEUCK game will unfreeze, you might see some mess on the screen while the C64 is setting its state to your SEUCK game. There is a more professional approach to freezing, known as the black screen method. Load up your SEUCK game as normal. Once loaded, press the freeze button on the title screen with your cartridge. Now this time don't go into the backup menu yet. Go to the screen editor option, then press F3 to change the background colour until everything is black on your title screen. Press return and then go to the backup menu (F1) and save your finished game with the fast disk (not warp) save option. Now reset your C64, load and run the game like normal. You will see that this time round the screen is black while unfreezing and restoring your game to its original state.


Tools required: (C64) M/C Monitor (Action Replay/Retro Replay/1541U2, Your SEUCK game, native C64 packer/Cruncher) (PC - optional D64 editor)

Have you written a SEUCK game? Have you seen the file size of your game. Eurgh. Horribly huge isn't it?. Finished game states saved from SEUCK on disk consist of 2 files. You may have already noticed this before.

MY DISK             64 00
1    "MYGAME"
249  "MYGAME        "

The size is huge. You probably might want to consider to reduce the file size and be able to load the game quicker. So the first thing to do, is load your game on disk. Grab a cup of tea or something while waiting for the loader to load in your saved game. As soon as your game has loaded. You may ask why is the game data huge in size?. That is because SEUCK saves the editor data and code along with the finished SEUCK game. Pretty much a wast of memory. So what we are going to do is CLEAN up the mess. Press the FREEZE button (or emulate it).

Before we clean the data, a quick fix should be made in order to allow enemy random fire take place. Enter the M/C monitor and change the load value of $8000 (random firing) to $5000. The reason behind this is so that the random firing isn't clear. Zero filling the unwanted memory will fill the random shooting data. So it has to be read elsewhere.

> 54EF lda $5000,y

Now let us ZeroFill the unwanted data to make room for additional data / code.

F 6580 B6C0 00

There you go. Now let's do a save of the cleaned version of your game.


Once again 249 blocks has been saved. Now it is time to break it down more. Before we decide to PACK/CRUNCH the program to make the file size shorter and run from BASIC. You'll want to find out the JMP address for the game. $37 will be $01 value and jump address will be $4245. So, in the M/C monitor, type in:

G 4245

The front end comes on. and the game should work nicely.

Now, use the D64 editor to extract the game to the Exomizer directory. Go to the Exomizer using the command prompt and access the directory where Exomizer is, for example

C:\> cd\exomizer\win32

... compress your SEUCK game using the following command:

C:\exomizer\win32> exomizer.exe sfx $4245 mygamenew.prg -o mygamecrunched.prg

If wanted, at the end of the command add -x2 for a flashing border depack fx, or -n for no effect at all. You can create your own custom depack effects if you want, by using the -x "(machine code)" for example, thin stripes -x "dec $d020 inc $d020"

The program will crunch in a few seconds, and then is ready to be added to your .D64.

If you feel very adventurous and wish to pack/crunch the SEUCK game the old school way, then here's a an old school method. For this example, I am using Oneway's Zipper Optimizer V5.0 for packing the program. Then Abuze Cruncher V3.2 for the crunching. Here's the screen shots (If you don't want a depack effect, then you could go for the Equal Sequence V2.2 or 2Mhz Time Cruncher V5.0 instead of Abuze V3.2+:)

Packing with Zipper Optimizer V5.0 (CSDB Release ID: 97926)

Step 1: Type in the parameters as the above example - Make sure the file name is correct. $01 value should be $37, and SEI/CLI should be SEI after depack. As indicated above. Jump address to run the SEUCK game is $4245.

Step 2: Wait for the packer to load the program, then pack it (Black border + white stripes = loading ... Multi-colours = packing

Step 3: Screen turns grey. Press SPACEBAR to save the packed program to disk.  

Step 4: Load program from DIRectory and enter SYS2049 to run ... Depacker will start ... NOTE: Different packers use different jump addresses. Some have BASIC SYS addresses, but this one doesn't. So $0801 will be the target address for the depack routine. Therefore type SYS2049.The game will depack and run.

Crunching with Abuze V3.2 (CSDB Release ID: 132950)

You can use a different cruncher if you like, but I chose Abuze V3.2 for this example, because it is a very fast cruncher, should option '1' be selected and compression rate is pretty good as well. Anyway pick 4 depack effects then press 'Y'

Step 1: Enter the following parameters (like before), this time use $0801 as the jump address (if using a different packer for the game, that has a BASIC SYS address. Use M/C monitor to work out the hex address of the jump address, using N SYSvalue or use a decimal-hexadecimal convertor. For example you listed SYS2061, N 2061 should be typed in the M.C monitor. $01 Value still must be $37. Wait for loading

Step 2: Wait for program to crunch for a small number of minutes. Press space bar to save crunched program when ready.

Step 3: Load in your game, and run it. Then allow it to De-Crunch and run your game in a moment of seconds.

Game runs nicely

Using VICE Monitor and Exomizer (The I got no freezer cartridge method)

I have showed you an example of how to pack and crunch your SEUCK games with Zipper and Abuze crunch. This was pretty much a traditional oldschool method of saving a finished SEUCK game and making it into a C64 executable. If you are a general user of VICE however, you can save a lot of time by using VICE machine code monitor, and Exomizer. The method is as follows.

1. Load your SEUCK game from the save finished state, frozen or whatever. Ensure it is running.
2. Go to the VICE monitor (ALT+M in Vice V2.4 - 3.2 using GTK, ALT+H if using the GTK V3.3 or above)
3. Type in bank ram - you need to do this to enable the monitor to switch to RAM mode and enable saving of all VIC2 banks. SEUCK games use all 4 bank memory areas for code, graphics, etc.
4. Save the game memory from $0900-$ffff using:

s "lasthugger.prg" 0 0900 fffa

5. Copy mygame.prg to Exomizer's directory
6. Using the command prompt, go to the Exomizer directory and then run the program through exomizer via the commandline


c:\exomizer\win32> exomizer.exe sfx $4245 lasthugger.prg -o lasthugger+.prg -x2

After a few seconds, Exomizer will compress the saved project and then make a C64 executable of the finished game. After completed the Exomizer method. Load and run your compressed program in VICE. The border will flash on decrunch, then the game will run. (If you don't like decrunch effects, you can use -n instead of -x2 ).

Fix Sideways SEUCK map flicker bug
The Sideways scrolling SEUCK is fun to use, but sometimes it can be very annoying when it is flickering like hell at times. For a slightly more STABLE version of the the Sideways scrolling SEUCK engine. Use:

POKE 17651,25 

WARNING although this kills the constant map flicker bug - it can make the upper border look pretty odd - unless default background colour used is set to BLACK (#00), otherwise you may need to create a raster split after saving your finished game. This example is what I used for Sarada Doja to stabilize the scroll more.  

Note: In order to INIT this subroutine into the code. You will need to change $44F4 to:


... or wherever you want to put the code.


>6900 LDA #$00
>6902 STA $D020
>6905 STA $D021
>690D LDA #$32
>6912 BNE $690F ;If using assembly instead of M/C monitor. Change to BNE *-3 instead
>6916 STA $D021
>691C RTS


Fix Player 2's score 
by Loflo

SEUCK had a bug left in the score system, where player 2 scored points for every time player 1 collected an object. This bug isn't too serious, but it can be annoying for the opposite player, who would find it to be unfair. There is a simple fix (with thanks to Loflo on Lemon64) which will

While I was working with Alf Yngve on some games in the past, I came across some interesting things, that could be done by aid of some simple pokes. If you have an Action Replay cartridge handy, then here are the POKES which you can type in to modify your game settings. This will also work in the editor itself.

> 54A2 JMP $8000 ;Or wherever you want to put the fix up

> 8000 STA $5DBB
> 8003 LDA #$00
> 8005 STA $09 ;Select correct player
> 8007 JMP $54A5 ; Jump back to main code again

PAL / NTSC compatibility (SEUCK/Assembly)
by Richard Bayliss

Detecting PAL/NTSC the quickest and possible way can be done by detecting the value of hex $02a6. A value of 1 on the hardware classes as PAL and the value of 0 is classed as  NTSC. It is possible to use NTSC checks to time SID music players, etc to play at the correct time. Simply by creating an assembly command subroutine, which controls a delay to the music player cycle.

Does the PAL version of SEUCK work on NTSC machines? The answer is simply YES, but you won't be able to see the score panel. It's buried right inside the bottom borders, and NTSC machines cannot cope with it. In order to fix the problem, a simple command could be added before starting the actual title screen. The code look something like this. Place this code anywhere where there is free space between $6580 and $A000, and use a decruncher to call the movement subroutine:
ONETIME       LDA $02A6        ;Hardware machine type???
              CMP #$01 ;PAL    ;PAL Detected - Run title screen immediately
              BEQ PAL
NTSC          LDX #$00         ;NTSC detected, call the new position for the
MOVELOOP      LDA #$FF         ;game's status panel to display on NTSC.
              STA $5EAF,X
              CPX #$12
              BNE MOVELOOP
PAL           JMP $4245

WARNING: The score display on NTSC machines will flicker at times during playing of the game. At least you get the score display on NTSC, but you wil get only half the lives indicator. . :)

However, should you want to have PAL music playing on a SEUCK front end, and also be NTSC compatible. A little extra coding would need to be made. You would have to STORE the value of $02a6 to a single byte and then init the ONETIME code once again. This time underneath LDA $02a6, add STA MACHINETYPE. This example init shows you how:

ONETIME       LDA $02A6
              STA MACHINETYPE
              LDA MACHINETYPE

              CMP #$01 ;PAL    ;PAL Detected - Run title screen immediately
              BEQ PAL
NTSC          LDX #$00         ;NTSC detected, call the new position for the
MOVELOOP      LDA #$FF         ;game's status panel to display on NTSC.
              STA $5EAF,X
              CPX #$12
              BNE MOVELOOP
PAL           JMP $4245

In the music player area, you would need to change the code to time correcty with NTSC machines. For example on the SEUCK title screen:

              JSR PALNTSCMUSIC
              JMP $4138

or if ingame music at $4503, or inside an interrupting subroutine

                              JSR PALNTSCMUSICPLAYER  


               LDA MACHINETYPE
               CMP #$01
               BEQ PALM
               LDA MUSPTR
               CMP #$06
               BEQ RESETPTR
            STA MUSPTR


2 Players with one control
By Richard Bayliss

Source: Strike School by Carl Mason (TND Contributors)

Carl Mason's Strike School used this example, where two players are linked to one control, and the player had to shoot a limited number of targets before time ran out, otherwise both players will die. A medal gives out extra lives. 

POKE 16578,2

Results can be pretty much interesting if your have more than one player linked to the same joystick. I first noticed this trick, but Carl Mason came up with this clever aspect first.

Should any compo entries use 2 players at the same time, I'll be very happy to add shared score routine. - Make sure extra lives at every 10,000 points milestone is disabled as that will cause some complications.

... should you use 2 Players to 1 control, you might want to consider :)

Peek-A-Boo, Hide and Seek
By Richard Bayliss

Source: Noxus by Alf Yngve (SEUCK Compo 2014)

Alf Yngve's 'Noxus' used this hack in which hidden one of the players behind background at the start of the game. Then after part 1 finished, the player could enter where background could cover it. A similar trick was used in a few other of Alf's games.

POKE 17424,0 (IN FRONT) 255 (BEHIND)
POKE 17426,27  ;REPLACE $D020

This will allow the game hide sprites behind certain background chars (the main char colour most of the time). This would be handy for games, which require STEALTH type of action. I.e. hiding behind trees, crawling underneath nets, tunnels etc..

Hires / Multicolour Sprites
By Richard Bayliss

Maybe you wanted to create something like a SEUCK Asteroids clone or something like that. This POKE below makes all sprites single colour.
POKE 17968,0 (Hires sprites) or 255 (Multicolour sprites (Default)).

Decorate my score panel
By Richard Bayliss

Source: Nyaaaah! 11 by Richard Bayliss (TND Games)

Nyaaaah! 11 usese a multi-coloured scoring charset. Where I originally drew the scoring chars in hires. Saved the charset data $f400-$fc00 and loaded the charset into Dunex Char editor (CSDB ID: 19811), and made a multi-colour version of the score/status. Then loaded my SEUCK game again, loaded the edited charset and added the POKE to enable multicolour.


Load your own SEUCK game. Freeze the game, enter the M/C monitor and type in:

S "font",8,f400,fc00

Now edit the status chars with a Public Domain char editor of your choice - make it multicolour. Then save the full font again.

Now load in your game again, FREEZE it again, enter the M/C monitor and type in:

L "newfont",8,f400,fc00

Type X to exit the M/C monitor and go to the menu. Select POKES and type in the following POKE bellow

POKE 17765,255 (Multicolour) 0 = Hires

This will make the score panel multicolour. Setting it as '0' will restore it back to single colour.

I want BIG aliens 
By Richard Bayliss

Source: Gigablast by Alf Yngve (SEUCK Compo 2015)

Alf Yngve's SEUCK Compo used huge sprites which went over the vertical scrolling landscapes. This made less room for the player - and harder, but cooler game play. It is just plain bonkers :)

Want massive sprites? Go to the VICE M/C monitor and edit:

A 4503
> 4503 JSR $0800
> 0800 LDA #$FF    
> 0802 STA $D017 ;Expand X
> 0805 STA $D01D ;Expand Y
> 0808 JSR $5C94 ;Play SFX
> 080B RTS

... Would be worthwhile to reduce the status panel sprite size, and disable multicolour. Try this :)

> 080C LDA #$00
> 080E STA $D01C ;NO multicolour
> 0811 STA $D017 ;Expansion X
> 0814 STA $D01D ; Expansion Y
> 0817 RTS

... and to link this routine to work 100% would be:

A 4566
>4566 JSR $080C

This will reduce the size of the score panel back to its correct state. Should the routine $080c - $0818 been added.

Note: If you're saving a final version of your SEUCK game, with the example code placed at $0800-$0900, you will need to save your SEUCK game from $0800-$fffa, instead of from $0900-$fffa.

Example from Action Replay cartridge M/C monitor:

s "mygame",8,0800,fffa

Level Detection (Background colour changer)
By Richard Bayliss

Source: Dark Force by Alf Yngve and Richard Bayliss (TND Games)

Dark Force by TND Games is a prime example of background colour colour changing per chosen level.

On some SEUCK games, background multi-colour schemes are always the same. Should you have wanted the background scheme to change on a different level, you need to check every seventh positrion on the level pointer. Compare the value to that particular pointer. Then make the new colours of the background. Remember that after the game is over, you should RESET the background colour pointer (if using a table to set each colour). Otherwise this trick should work. :)

This trick was used in Dark Force and allows the game to change the colour of the border, according to the level parameters. In order to get this clever trick to work, I linked the routine to the main loop (>4503) with SFX / MUSIC.

You will need to check level parameters for this sort of effect to occur:

>4503 JSR $MYROUTINE;Main loop.


> 7C03 JSR $5C94 ;Play sound effects
> 7C06 rts       ;Expandable if you wish

Say we use $7D00 for the level check routine. Based on the level parameters - you'll need to look at these before adding this subroutine


> 7F03 CPX #$00 ;LEVEL 1?
> 7F05 BNE $7F0B ;
> 7F0B CPX #$07 ;LEVEL 2?
> 7F0D BNE $7F10 ;
> 7F13 ... etc until done enough times.
> 7XXX RTS ;Not equal to any of those levels


>7E00 LDA #$06 ; Colour blue - MCOL1
>7E02 STA $D022
>7E05 LDA #$0E ;Light blue - MCOL2
>7E07 STA $D023


>7E10 LDA #$05 ;Colour Green
>7E12 STA $D022
>7E17 STA $D023

Getting to know the Front End 
Every single SEUCK game, which you load consists of a basic front end, which consists of a logo built with chars, or just plain character text. Some front ends consist of a rolling raster bar behind it. This gets boring, and you might want to consider to code a brand new front end, add music or some additional cool features, like a starfield or something like that. If you can open your imagination for presentation, and invest some time on learning to code a bit (You don't have to know TOO MUCH about code, and how it works for enhancing SEUCK ...  More about building a new front end later on.


Source: Tau Zero by Alf Yngve and Evil Wizard 2 by Pingo (TND Contributors)

Okay, let's get this straight. The built in rolling raster bars colours are quite ugly and out of place in standard SEUCK. The one used in Alf Yngve's Tau Zero is very nice to look at. Only two nice colours in the raster roller are the red scheme and the silver scheme. The rest of those are just plain ugly. 

This is a modified front end colour scheme I did for Pingo's Evil Wizard 2, which splits two colour bars in half. I used to use this more often. Now I am going to show you how to achieve this interesting masterpiece. NOTE: Your game NEEDS to have the colourbar mode on in order to achieve this.

After loading your game press the FREEZER button and enter the M/C monitor. Type I* and scroll down to area $41c0-$4200. You should see this snippet below. Move your cursor to the area, and type in the colour code until you reached $4200. 
Remember to press the Return key at the end of each line. Have a playaround typing in some letters and characters to see if you can make cool colours. Be very careful to NOT change the first 2 bytes at $41c0 or after $4200 else you will crash your program. I have generated a key to indicate each colour:

The example uses the front end for Nuclear Strike Force. I originally used the SILVER colour bar scheme. To be able to edit the existing colour bars I had to find the following pattern: @KLOAOLK

Now what happens if change it to IECMAMCEI? ... THIS:

Have a little play around, and see what cool colours you can do. We will be taking a look at making brand new front ends later on.

Adding some Music
Want to learn how to add music to SEUCK games? Well, before you do, you will need to be able to relocate a whole tune first. I strongly recommend that you use the All Round Relocator by Syndrom, and my DMC music collection. Unless you want to use SID tunes that are in HVSC and relocate those. For this part of the tutorial. I am going to show you how to add music to the front end, and also give you the possibility to add in game music as well. Here's what you will need to help you get started.

If using PC

- High Voltage SID Collection (
- SIDPLAY (CSDB ID: 103781)
- Goat Tracker or Cheesecutter ( or
- SidReloc (For relocating most players) (CSDB ID: 109000)

If using normal C64

- DMC music collection (TND music section)
- All Round Relocator (Included in the DMC collection) (Relocates some JCH tunes, and DMC V1 - DMC V5 tunes) (CSDB ID: 40005)
- A C64 music editor which can relocate tunes you composed yourself

Using SidplayWin32. Pick a SID file, which you wish to play. Before you decide to extract it to SIDReloc's directory. You may want to take a look at the INIT/PLAY address of your tune. If you need to do this then do as follows:


A window will display the information of the player. The ones you need to look out for is the one highlighted in yellow

Name:            Nuclear Strike Force
Author:          Richard Bayliss
Released:        2015 The New Dimension
Load range:      $1000-$1BA6
Init address:    $1000
Play address:    $1003
Number of songs: 1
Default song:    1
Clock speed:     PAL
SID model:       8580
Player routine:  Vibrants/Laxity
Reloc region:    Auto

Now close the file box and then select


Select the option to save as PSID, then type in the filename which you wish to save in the SideReloc directory.

Go to SIDReloc using the Windows command prompt


Now type in:

C:\>sidreloc.exe -p 90 mysid.sid myrelocsid.sid

Play the relocated SID music in Sidplay WIN/2, and then save the tune as a .PRG or .DAT file

Load .D64 editor and import the  .dat / .prg of the relocated tune into the directory and then save the new .D64


Load in All Round Relocator and enter the name of one of the tunes which you want to use from my DMC collection. Relocate to $9000 and save the new tune. Nothing else to it.


Load in your cleaned up SEUCK game as normal. Freeze it with Action Replay, and then enter the M/C monitor.

Using the M/C monitor, load your music file which you have relocated for example:


Music will load at $9000, as we will be using it for the title music. Don't run the game yet, as the music will not play. In order to get the game title to play, we need to initialize the music player data, and then play it continuously in a loop. In order to do this, we need to make some minor alterations to the title screen's code. Some mini subroutines.

If you look at $40DD, it sets the border colour to the title screen as black - but that also happens elsewhere in the title code. So we can remove that bit and change the routine to INIT the title music. In the M/C monitor type in as follows:

>40DD jsr $9000 ;Init Music

Music will initialize, but we still have now loop in the player. So make a new routine, which will play the music inside a loop. To call the music player loop enter the following:


Not quite there yet. We need to make the player loop now.


> 6580 JSR $9003 ;Play music
> 6583 JMP $4138 ;Continue to the main title loop

Nearly there. Just a couple of changes. Location $41A4 jumps to the main game code, which starts at $4260. We don't want to jump to the game straight away. We want to clear the SID before SFX can init/play inside the game. If this isn't done, not all 3 channels of the C64's SID will play the sound effects - unless sound pointers are initialized. So where the location calls the main game to run. The following code needs to be added:

> 41A4 JMP $6586 ;JMP INITSID

Now for the main INIT SID code:

>6586 LDX #$00
>658A STA $D400,x
>658D INX
>658E CPX #$0F
>6590 BNE $6588
>6592 JMP $4260 ;JMP GAMESTART

Now type in

G 4245

... and you'll get a result of the title music playing in the background.

What about in game music?

Well, you can use the same method as before, but put this time let in game music be located at $a000. Select the tunes like you did above, but select a0 if using sidreloc, or $a000 if using allround relocator. Now alter the INITSID routine at $6592, before adding JMP $4260, add the following:

>6592 LDA #$00
>6597 JMP $4260

Now change the SFX player at $4503 to play in game music instead ...


Adding High Score Detection


The directory consists of the following files:

FB - Filebrowser/Disk menu
TANK BLASTA   /TND - Fully enhanced version of the game (Made as a bonus treat to accompany this feature). More about it later on :)
TANKGAME - RAW SEUCK finished game (Crunched with Exomizer). So you know how this game was originally before enhancements were made in place.
TANKRAW     .I - SEUCK work data (To be loaded in to the Shoot Em Up Construction Kit)
SCORETEXT - The score text data, which accompanies this feature
HISCORE.CODE - Source code to load into Turbo Assembler (or convert/view into PC text, ASM format). To load the HISCORE.CODE, you need to press BACK ARROW and E. Since the file is sequential
HISCORE.OBJ - Assembled code of the hi-score detection installer and routines
TANK HI - Compiled Tank Blasta, crunched with Exomizer.
TITLEMUSIC   .GTK - Relocated title music used for the enhanced version of Tank Blasta
GAMEMUSIC   .GTK - Relocated in game music used for the enhanced version of Tank Blasta
TANKENH.CODE - Source code to load into Turbo Assembler that contains complete code of the in game enhancements
TANKENH.OBJ - Assembled source code to load into the machine code monitor.

There has always been something missing inside a standard SEUCK game creation, and I also had a suggestion from someone regarding this particular feature. SEUCK games have a score panel, but they don't have any form of high score detection. In this part of the SEUCK school. We are going to try and implement some code which will check and also display the last score player 1 had, also the same for player 2. Not only that. We are also going to be detecting a high score. You also have a new SEUCK game to play around with for this feature. TANK BLASTA. In order to be able to work on this feature. You will need an assembler and machine code monitor (VICE, U64, 1541U2 users, etc please use the Turbo Action with TASM/Codenet. Alternatively, you can use the SEUCK Framework to add the high score detection code if you have ACME or C64STUDIO :)


Load in your SEUCK game like normal. Depending on how you saved your game. You should have a front end like you have already right now.

Test the game to ensure it works instead of the file being corrupt.:


Press the RESET button on your Turbo / Action / Retro Replay freezer cartirgde. Then press F7 to enter the fastload option. Then enter the M/C monitor.

Clear the wasted memory, by using the command F 6580 B6C0 00 (If you want to that is).  Otherwise don't worry too much about it :) A clean memory where the editor originally lies is best wiped away, if you want to add additional data and code to your own game productions. Plus we don't need to use the editor anyhow.

The first thing we want to do is prepare a high score (Consisting of 6 digits). You may use any spare memory location you like. I have decided to fill 6 bytes at $6580 (F 6580 6586 00). I decided to use the area $0800-$0806 for the high score. A snippet of the method is shown below:


Clear the screen. Prepare some text for the score and high score detection. You won't need to enter any number scores in the text. It will simply be added when we do the detection code. After typing in your 3 lines of text (PLAYER ONE SCORE, PLAYER TWO SCORE, HI SCORE) move the cursor to the middle or lower position of the screen. Type in T 0400 07A0 0820 (Or to which spare address you wish to place the text). The text will then be transferred to that position. Please note that it might be wise to save your text, just in case you're lost while entering the code. Simply use S "TEXT",8,0820,08c0 (Or whatever address is used to place your text in place).


We don't need to use the M/C monitor for now. So what to do now is exit the program. Then enter the Turbo Assembler, that is built in the cartridge's fastload (TYPE IN 'TASS'). If your cartridge doesn't have a built in TASS. Don't worry. It is still possible to use a native turbo assembler, but you'll need to manually assemble and save the object code to disk, then reload the game and prepare the score text again (unless you saved that also). Then load the object code to disk.

We start with a set of variables. The score text is the address of the text which we originally created for the hi score detection program

p1scorepos, p2scorepos and hiscore pos are set to the last 12 chars for each row where score player one, score player two, hi score text is positioned

screenpos is the actual SEUCK title screen RAM position but starts on the next row (We leave the top row of chars as blank).

hi score is positioned at $0800. 

;seuck school
;player scores and hi score detection
;and displayer. by richard bayliss


;actual text positions to read

scoretext = $0820

;position to place the score digits

p1scorepos = $0820+39-11
p2scorepos = $0820+79-11
hiscorepos = $0820+119-11

;seuck front end screen ram area
;starting one row below top row

screenpos = $e828

;seuck score data, and hi score area

p1score  = $5ea3
p2score  = $5ea9
hiscore  = $0800

The next set of code is part of the onetime init process. (Also fixes a few bugs). First a start address $6700 is set for the onetime code. We then force the code to bugfix the random firing address, to make addresss $54ef to use $5000, instead of $8000 for random firing. This is because if memory $6580 - $B6C0 was zerfilled, the random firing goes to the right instead. A patch for the SEUCK score bug is also added. Then we force the title screen to check for new high scores, before a new game starts. Then force the looping title screen control to display the text.


         *= $6700 ;installer / onetime

         ;fix SEUCK random fire bug

         lda #$50
         sta $54f1

         ;fix SEUCK collect bug

         lda #$4c ;force jump
         ldx #<bugfix
         ldy #>bugfix
         sta $54a2
         stx $54a3
         sty $54a4

         ;force score read, write and
         ;hi score check code before
         ;running new front end.

         lda #$20 ;jsr
         ldx #<hicheck ;low+hi byte of
         ldy #>hicheck ;hi score check
         sta $40dd ;s.e.u.c.k front end
         stx $40de ;init area. usually
         sty $40df ;black border set.
                   ;but not needed now.

         ;íain interrupt on front end
         ;can have a small routine here

         lda #$4c ;jmp
         ldx #<dispsc ;display score
         ldy #>dispsc ;low+hi bytes
         sta $41bc
         stx $41bd
         sty $41be

         ;clear all scores + hiscore

         ldx #$00
clearsc  lda #$00
         sta p1score,x
         sta p2score,x
         sta hiscore,x

         cpx #6
         bne clearsc

         jmp $4245 ;run óåõãë front end

;seuck score bugfix (colletable)

         sta $5dbb
         lda #$01
         sta $09
         jmp $54a5

The next line calls a loop that will display the score text to the SEUCK title screen. Before the score text is displayed, it has to be converted from PETSCII chars into SEUCK title screen chars. 3 rows of text are read in the loop, then the SEUCK title will loop the colour bar player.

;code to display the score (text)


         ldx #$00
disploop lda scoretext,x
         eor #$80 ;convert to title chrs
         sta screenpos,x
         cpx #$78 ;3 lines read
         bne disploop
         jmp $4138 ;òaster rolling code
                   ;and loop.

The next set of code occurs every time the title screen has been refreshed. Basically after finishing playing a game or aborting current game. This code below will do a check on each digit. It compares the score of player 1 or player 2 with the high score. If the 6 bytes on each score are lower on the hi score, compared to the player's score. A new loop is processed to overwrite the 6 bytes of hi score with the 6 bytess of the player's score. Of course both player 1 and player 2 should be checked with the high score.

;code to setup the scores

         ;check player 1 score and
         ;high score together to see
         ;which is higher/lower

         lda p1score   ;grab first byte
         lda hiscore+5 ;grab last byte
         sbc p1score+5 ;check with 1up
         lda hiscore+4 ;and keep
         sbc p1score+4 ;comparing all
         lda hiscore+3 ;6 bytes of the
         sbc p1score+3 ;player score
         lda hiscore+2 ;and hi score
         sbc p1score+2
         lda hiscore+1
         sbc p1score+1
         lda hiscore
         sbc p1score
         bpl chkp2sc ;no hi for 1up

         ;1up score is the new hi score

         ldx #$00
newhi1up lda p1score,x
         sta hiscore,x
         cpx #6 ;6 bytes max/digits
         bne newhi1up

         ;like with player 1's score,
         ;check it with the current
         ;hi score.

chkp2sc  lda p2score+5 ;grab first byte
         lda hiscore+5 ;do same for 2up
         sbc p2score+5 ;as we did with
         lda hiscore+4 ;1up
         sbc p2score+4
         lda hiscore+3
         sbc p2score+3
         lda hiscore+2
         sbc p2score+2
         lda hiscore+1
         sbc p2score+1
         lda hiscore
         sbc p2score
         bpl nohiscore

         ;2up's score overwrites the
         ;current high score

         ldx #$00
newhi2up lda p2score,x
         sta hiscore,x
         cpx #6
         bne newhi2up

The last part of the code is to convert the player's score and hi score bytes into digits from the SEUCK score panel chars. The score panel digits are 1x2 based, thus the loop should be 1x2 based. We read the score of either player, call subroutine convert to check the actual value of the current score. Then it transforms into the first half of the digit from the score panel. We then read the stored line position and then move one character forward to display the second half of the digit.

;finally convert all score and hiscore
;bytes into the status panel charset.
;íanually position those as specific

         ldx #$00
         ldy #$00
convloop lda p1score,x
         jsr convert
         sta p1scorepos,y
         lda p1scorepos,y
         adc #1
         sta p1scorepos+1,y
         lda p2score,x
         jsr convert
         sta p2scorepos,y
         lda p2scorepos,y
         adc #1
         sta p2scorepos+1,y
         lda hiscore,x
         jsr convert
         sta hiscorepos,y
         lda hiscorepos,y
         adc #1
         sta hiscorepos+1,y
         cpx #$06 ;ócore length
         bne convloop

;convert bytes into the first half of
;the s.e.u.c.k's score panel chars.
;(this is linked to the loop above)


         cmp #$00 ;score digit = 0?
         bne not0 ;no. check next
         lda #$21     ;otherwise
                  ;convert to cha²

not0     cmp #$01 ;score digit = 1?
         bne not1 ;no. check next
         lda #$23


not1     cmp #$02 ;score digit = 2?
         bne not2 ;no. check next
         lda #$25


not2     cmp #$03 ;score digit = 3?
         bne not3 ;no. check next
         lda #$27


not3     cmp #$04 ;score digit = 4?
         bne not4 ;no. check next
         lda #$29;convert to char

not4     cmp #$05 ;score digit = 5?
         bne not5 ;no. check next
         lda #$2b ;convert to char

not5     cmp #$06 ;score digit = 6?
         bne not6 ;no. check next
         lda #$2d ;convert to char

not6     cmp #$07 ;score digit = 7?
         bne not7 ;no. check next
         lda #$2f ;convert to char

not7     cmp #$08 ;score digit = 8?
         bne not8 ;no. check next
         lda #$31 ;convert to char

not8     cmp #$09 ;score digit = 9?
         bne not9 ;no. check next
         lda #$33 ;convert to char
not9     rts      ;no more checks

;end of code


Type backarrow and 5 to assemble to disk (or alternatively, assemble and run with 3). If you have the TASM/CODENET - Turbo Replay, press back arrow and 3 to assemble and run. After a few seconds your title screen should display like the image below:

If you don't have TURBO REPLAY, and use just a standard C64 cartridge like Action Replay. Load and run your SEUCK game, press the RESET button, load in the score text, and object code enter the MC monitor then type in G 6700. You should have a front end with hi score.


The final step will be to save the game, complete with front end and update. Enter the M/C monitor and type in the following command:


Now when you use a packer with cruncher (there are plenty of those around, or just use the PC based C64 compression tool Exomizer. Instead of using $4245 as the jump address. Use $6700 (The one time init of high score). Or alternatively, you can just freeze the game title and just save to disk / tape using the freeze menu.

Exomizer users type in:

exomizer sfx $6700 tankblasta.prg -o tankblasta.prg -n


As well as the raw Tank Blasta, with the game code. I am also happy to bring you an enhanced version of Tank Blasta, which also includes some of the code that has been featured in the later chapters of SEUCK School. Have fun with it!

The game consists of title and in game music (with sfx options), power ups, background animation, smart bomb boss explosion effects, and the featured hi-score detection enhancement. A sequel in co-op with Alf Yngve is intended, with SEUCK Redux.

A new war has broken out. It has been caused by an evil spy, who has migrated to the United States in a spy trawler. He has spread chaos across 3 zones, where he sends military forces to cause as much carnage is possible. The 3 zones are the Desert, The Himalayas and The City. The president has called in two highly trained and qualified service people, which are yourself and / or a friend. Your mission is to drive a heavy amoured tank across each of the 3 zones, doing battle against the militia and their defences. At the end of each zone, you will encounter a boss. Once successfully complete one of the 3 missions, you will enter a target range, where you can pick up bonus points. Collect parachute power ups to enhance your shell firing. WARNING: Pick up too many of those, you will restore to the normal state.

Common SEUCK Subroutine Area Tricks
By Richard Bayliss

When writing enhancements for SEUCK games. There are certain areas which you need to be aware of, where clever tricks can be placed. The next load of tips below are something to do with those areas.  These areas are as follows:

Game init and start

In SEUCK $41A4 normally uses the JMP $4260. This will jump straight into the main SEUCK game. If however music was used in the game. A subroutine would need to be called to silence the SID chip, in order for the SFX to play properly. This is usually done at $41a4 as:

                JMP INITSID

INITSID         ldx #$00
KILLSND         lda #$00
                sta $d400,x
                cpx #$18
                bne KILLSND
                jmp $4260

SFX Player (For where enhancements can be linked): - CAN BE USED FOR LINKING SUBROUTINES

This area is usually marked with JSR $5C94 when playing SFX. If you call it to another memory area and say, call a different subroutine to it. Other things can often happen in place in your SEUCK game. For example. Say at $4503 we change JSR $5C94  it to call THIS. Then say at $6580 in the cross assembler, we call a label called ENHANCEMENTS.

                 JSR ENHANCEMENTS

then ... add a subroutine to FLASH the side border, then play the Sound Effects again. Always RTS each subroutine when it has finished.

                 JSR $5C94

You can call  various subroutines in enhancements, to enhance your game even more. For example, background animation, full screen explosion, and other fun features.

Player 1 object Frame table

This area is where the 18 bytes of sprite data (read from SEUCK) is stored to the actual sprite's frame. By creating custom tables, it is possible to transform the player to something else, simply by duplicating existing table sequences, or altering those. Slightly. This trick was used in Zap Fight.

Player 1 bullet Frame table

The same type of feature as above, but this time it takes effect on player 1's bullet object.

Player 1 colour, and anim type.

Player 2 bullet colour and anim type

The colour and anim type is set by a byte. The second digit in the byte indicates the colour, and the first digit indicates the object animation type. Thus it is possible to transform from a directional hold animation, to a different type of animation.

Player 2 colour, and anim type.

Player 2 bullet Frame table

Player 2 colour, and anim type.

In game Loop process

By triggering this to JMP END SCREEN instead of loop. It will automatically jump directly to the end screen after completing the final game. 

Sprite/Sprite Collision Player 1 Lose lives

$4B0F indicates a routine, which will destroy and deduct a number of lives from player 1. It is also possible to do a trick in this area to call a small subroutine, to add some more effects. Say for example, if player 1 is linked to player 2 and both share lives. A trigger should be performed to destroy player 2. The trick I did as a split second for doing Dark Force, as a sprite/background collision for BOTH players. $4B0F look something like this:

                                                        STA $5DBF

If changed.  The routine above still needs to be stored inside the code.

Sprite / Sprite Collision Player 2 Lose lives

 Same as above, but for player 2. STA $5DC0 is used instead of $5DBF to destroy the second player.

Player 1 Re spawn

First the player's life is deducted (after the death). The routine inside that area checks whether or not the player should re spawn after a loss of a life. If so, then it can be re spawned. A custom subroutine linked to $4B6C (JSR INITPLAYER1 for example) could make players lose all power ups, or setup pointers for the player to go invincible at the start of the game. The player 1 re spawn can also be used to reposition the player at exactly the same position where it has died. A subroutine for this trick features in a later chapter.

Player 2 Re spawn

As above, but refers to player 2.

Enemy killed, and scoring code

This is a crucial area for where the player destroys an enemy by blasting it, or collecting an object and scoring points for every object picked up. There was a nasty bug in $5E4F, where only one player could be awarded points should another player have collected the object, and it can be patched easily enough. At $55C3, a subroutine could be called in order to check which object type has been picked up / killed, check which player killed the enemy and give out a power up or something similar.

Spare / Wasted Memory ...

After saving a standalone SEUCK game. The SEUCK editor + code is usually still stored in memory. There is no need for this at all. In fact, memory can be overwritten by extra data, such as enhancements, etc. Since we no longer need the editor. It is possible to zero fill that memory and use it for additional code + data. Of course it does involve having to program raster interrupts, using upper video banks and a lot of additional programming.

Most of the time. I use the following areas for various tricks in SEUCK games:

$6580-$7000 for programming the in game enhancements (which are linked as subroutines to the most of the above memory locations)
$7000-$7800 for char set or logo graphics (if a logo char set is being used instead of a bitmap picture - else use it for text)
$7c00 is used as BANK 2's screen RAM for displaying the char set logo and text characters
$8000 is mostly used for front end code.
$8400-$8800  is used for the multi colour bitmap picture colour video RAM data
$8800-$8C00 is used for the multi colour bitmap picture's colour RAM data
$9000-$9FFF is used for music (Goat Tracker/DMC/JCH) ... Range can be bigger if no multicoloured bitmap is used
$A000-$B6C0 is used for the multi colour bitmap, bitmap data

If spare memory left between these locations. It is even possible to add more code, text or even sprites on to the screen.

Actual player 1 position and speed in action

Actual player 1 bullet position and speed in action

Actual player 2  position and speed in action

Actual player 2  bullet position and speed in action

Re spawning players at last position after dying
By Richard Bayliss

Source: Cops the Final Chapter by Alf Yngve (Psytronik Software)

After the players have died. SEUCK seems to want to re spawn the player to an area, where it shouldn't really be placed. This problem mostly occurs in games, that use the PUSH SCROLL. When the player is shooting against an enemy, dies and re spawns. The player appears on a background which the player cannot move from. In order to resolve this, a subroutine has to be called to reposition the player from where it dies. Basically. Following the previous chapter. Add a subroutine to Areas $4B0F, $4E1E the following commands:

$4B0F                      jsr LifeLostPlayer1
$4E1E                      jsr LifeLostPlayer2

(Place this where there's free memory if using a M/C monitor, for example $8000 for LifeLostPlayer1 and $8100 for LifeLostPlayer2).

LifeLostPlayer1            sta $5dbf           ;BAM. Player cops it.
                           lda $bc01,x         ;Read ACTUAL  X position of player 1
                           sta $40a3           ;Place it into SEUCK's default XPOS for player 1
                           lda $bc02,x         ;Read ACTUAL X MSB position of player 1
                           sta $40a4           ;Place it into SEUCK's default MSB for player 1
                           lda $bc03,x         ;Read ACTUAL Y position of player
                           sta $40a5           ;Place it into SEUCK's default Y pos for player 1
                           rts                 ;Return from subroutine

LifeLostPlayer2             sta $5dc0          ;Bam! Player 2 cops it!
                            lda $bc31,x        ;Read actual X position of player 2
                            sta $40b6          ;Place it into SEUCK's default XPOS for player
                            lda $bc32,x        ;Read ACTUAL X MSB position of player 2
                            sta $40b7          ;Store it into SEUCK's default MSB for player 2
                            lda $bc33,x        ;Read ACTUAL Y position of player 2
                            sta $40b8          ;Store it into SEUCK's default Y pos for player 2
                            rts                ;Return from subroutine

This trick does work well in the game, but there is a slight drawback. When you start a new game, the player gets repositioned in an incorrect position. To solve this issue, all you have to do is initialise the position of the player by setting the defaults from the original SEUCK game. To do this, you need to use an Action Replay M/C monitor and map out the bytes. Simply by typing in

m 40a3 (For player 1)
m 40b6 (For player 2).

Note down the first 3 bytes, then create an INIT routine (Jump routine linked to $41a4), which is:

jmp  initgame

initgame                            lda #(player_1_default_x)
                                    sta $40a3
                                    lda #(player_1_default_xMSB)
                                    sta $40a4
                                    lda #(player_1_default_y)
                                    sta $40a5

                                    lda #(player_2_default_x)
                                    sta $40b6
                                    lda #(player_2_default_xMSB)
                                    sta $40b7
                                    lda #(player_2_defauly_y)
                                    sta $40b8
                                    jmp $4260 ;Start game

Power Ups and Detecting which Enemy has been hit
By Jon Wells (Additional routines added by Richard Bayliss)

Source: Super Tau Zeta 2 by Alf Yngve (Psytronik Software)

When I was doing some features with Kung Fu Maniacs. I wanted to work out which enemy could be killed, in order to change sprites to make power ups for the game. Jon gave me some technical information, and the results have been very rewarding. Here's what Jon said. And here's his example:

Basically, the on screen sprites are stored between $
BC00 - $BCFF in clumps of $08, the First byte is the object number and $06 along holds the score to be added in jumps of 10's for that enemy so HEX $0A would award 100 points, HEX $14 - 200 points and HEX $28 - 400 points. Now I found a piece of code that handles the score and killing of a sprite around the $5500 onwards point. To make this easy for you here's a piece of code that if added stores 3 bytes at $8000-$8002 which hold the last enemy object killed, which player did it and how much was awarded. Anyway, here goes:

At $55C3 change the LDA $BD06,
Y to JSR $8200, then add the following code starting at $8200:

STA $8000

LDA $09            ; PLAYER either $00, $01
STA $8001

STA $8002


Right now you have 3 bytes of data $8000 holds the actual object number that was last killed / collected, $8001 holds the player number which did it. If it is $00 then that's player 1 joystick port 2, if it is a $01 it's the other player using port 1. Finally, the score is held in $8002.

Actually this code provides a few interesting things you could adapt. For a start you could make it so that if it is a power up it could be set so that a specific player can only use that if collected. Thus for example if player $00 picks it up they only get the score added, if player $01 picks it up then they get the power up. You can even change how many points are awarded as long as you add the points to STA $BC06,Y before returning the LDA $BD06,Y and ending the routine, so that one off score would be awarded instead of the preset amount.

Anyway, this should allow you to do what you need, if you have any probs let me know.

Alternative assembler version would be:


                    LDA $BC00,Y    ; OBJECT NO
                    STA ObjectType

                    LDA $09            ; PLAYER either $00, $01
                    STA RewardPlayer

                    LDA $BC06,
                    STA ScoreType

                    LDA $BD06,Y    ; YOU MUST END THE ROUTINE WITH THIS

The code can be expanded underneath STA ScoreType to use something like THIS:

                    lda ObjectType
                    cmp #(ObjectNumber) ;Check if object by looking at the SEUCK object editor
                    beq BossDestroyed    ;Boss type hit?
                    lda $BD06,Y
                    lda #$0a
                    sta ExplodeTimer ;Set explosion timer (see next chapter)
                    lda $BD06,Y
If you wanted to, you could make different power up types, such as increase the player's speed, or bullet speed. Change a bullet frame, etc. Remember to keep $BD06,Y at the end of the power up process code.  Okay, assuming you want to make actual power ups, for the player. You can easily refer to Jon Well's "Secret SEUCKcess Part 3". Where he gives out a memory map of the player's speed, and bullet pointers.

Object Transformation:
Used in: Zap Fight by Alf Yngve (Psytronik)


Say you wanted to change the shape of the player or a bullet, when making a power up, which increases the player or bullet, itself. The game Zap Fight used the player/bullet frame transformation. When doing a power up like this you would need to set up a table of 18 bytes (Unless you game uses just one frame). You will need to read from the sprite value in SEUCK, and store it into a table, consisting of 18 bytes. For example in Zap Fight. The player transforms its ship after it boosts firepower:


                      lda #BulletSpeed1
                      sta PlayerBulletSpeed
                      ldx #$00
                      lda #124 ;Sprite number for single framed object (for player)
                      sta PlayerFrame,x
                      lda #82 ;Bullet number for single framed object (for bullet)
                      sta BulletFrame,x
                      cpx #18
                      bne BoostFrame1
                      lda $bd06,y


Please note that if you are using directional/directional hold mode for the object which should transform, make sure you copy the sprite values for each frame from the table - like you would in a table, which consists of 18 frames (anim type 18). Don't copy the table from the Direction/Directional hold mode, otherwise the table in the code will be inaccurate.

                    lda #BulletSpeed1
                    sta PlayerBulletSpeed
                    ldx #$00
                    lda PlayerTable1,x
                    sta PlayerFrame,x
                    lda PlayerBulletTable1,x
                    sta PlayerBulletFrame,x
                    cpx #18
                    bne BoostFrame1
                    lda $bd06,y

                                                    ;Set values from table by referring to the 18 sprite values in SEUCK.
PlayerTable1         !byte 000,000,000,000,000,000
byte 000,000,000,000,000,000
                     !byte 000,000,000,000,000,000
                     !byte 000,000,000,000,000,000
                     !byte 000,000,000,000,000,000
                     !byte 000,000,000,000,000,000

Adding an Invincibility Cloak to the player and fairer player spawning
By Richard Bayliss

When playing a SEUCK game, it is much easy to discover that during game play, there are some issues of the player spawning on to a deadly background at times and you just cannot move the player off the deadly background, and just allow it to die. This makes game play unfair to the player, and some game developers accidentally make a fault where a player gets stuck while respawing. In this chapter. We are going to be making a much fairer game play, and allow the player move freely while respawned. Also we are going to create a shield power up

First of all some basics.  With sprite / background collision. You should take a look in SEUCK at your game project, to view the background collision char. Number, as that would be vital to note down when coding a shield routine. The idea is in shield and spawn mode, the player should be able to fly freely over the deadly background, and once out, restore the player back to its state.

STA $40AC ;Player 1 to background

STA $40BF ;Player 2 to background

This feature can easily be triggered to allow the player fly over deadly background.

But what if you want the player sprite/enemy sprite protection? Well, here's the genious part to it.

$4B03 to $4B05 reads player 1's sprite/sprite collision death activation code.
$4E12 to $4E14 reads player 2's sprite/sprite death activation code

If you wanted to make the player invincible you'd need to POKE out $4B03-$4B05, and/or $4E12-$4E14 with #$ea (234)

Load in a SEUCK game and try using the POKES option in your cartridge and type in the following pokes:

POKE 19203,234  ;FOR PLAYER 1
POKE 19204,234
POKE 19205,234

POKE 19986,234  ;FOR PLAYER 2
POKE 19987,234
POKE 19988,234

OR ALTERNATIVELY IN A M/C MONITOR create an installation source, which does as follows say we put it at $8d00

> 8D00

STA $4B03
STA $4B04
STA $4B05

STA $4E12
STA $4E13
STA $4E14

Then add
JMP $4245

Now in the M/C monitor, type G $8D00 and play the game. You'll notice that both players have invincibility against enemy sprites.

However, that is just the basics of protecting the player by allowing it to fly over background and protect itself against alien attack. Now what about putting it to the test in a SEUCK game?

Well, we have to create some subroutines, in which creates a temporary shield and also protects the player from enemy attack and allow the player to fly over the background. Also we need to control the duration of the protective shield, for whenever a player either spawns, or maybe come in to use with a power up. A small example for spawning a player, with a temporary shield would look a little something like this:

(A small example to try):

At $41A4, change JMP $4260 to another address, for init a temporary shield, and allow free flight over background. For example, say we use $8D00 (Although a different address can be used)). This example is for a 1 player only game, where player 1 is the target player.

initgame    jsr initshield      ;Call subr. initshield
            jmp $4260           ;run main game.

initshield  lda #255            ;Starting counter for
            sta shieldpointer   ;shieldpointer
            lda #255            ;Target collision char as 255 for player 1
            sta $40ac           ;Player to background collision
            lda #$ea            ;Make player invincible to enemy attack
            sta $4b03
            sta $4b04
            sta $4b05

Also at $4b6c add jsr initshield
At $4503, add a jsr enhancements routine. Then as the new routine add the new code

            jsr shieldtest    ;Call shield test routine
            jsr $5c94         ;SEUCK SFX player

Now let's do a shield test routine

shieldtest  lda shieldpointer  ;Countdown shield check
            cmp #0             ;has the shield pointer reached 0?
            bne shieldok       ;Shield is still active and has not reached 0
            lda #(collision char) ;Restore background collision char
            sta $40ac           
            lda #$ad
            sta $4b03
            lda #$be
            sta $4b04
            lda #$5d
            sta $4b05
            lda #(default player colour)
            sta $2c93

shieldok    dec shieldpointer   ;Decrement shield value by 1
            ldx flashpointer    ;Call flash pointer to flash player
            lda shieldtbl,x     ;colour table
            sta $2c93
            cpx #shieldtblend-shieldtbl ;Length of table
            beq resetflash
            inc flashpointer

resetflash  ldx #$00
            stx flashpointer

shieldpointer .byte 0
flashpointer  .byte 0

shieldtbl   .byte $09,$02,$08,$0a,$07
            .byte $01,$07,$0a,$08,$02

I have provided an example SEUCK game I made specially for this feature. Also there are a few samples of code included in the D64, which can be run from Turbo Assembler (Your C64 1541Ultimate, VICE or Ultimate 64 cartridge plugin needs to be the Final Replay with Turbo Assembler + Codenet (TASM/Codenet), one specially made for 2 player games. . This was already mentioned in the hi-score detection chapter.  The final code sample on the .D64 features the full enhancements added to the game, to make it even more playable. The only thing not changed is the front end. :)


Rocket 'n Roll is a zany blast 'em up for 1 or 2 players, in which you have to try and fly a Rocket safely into 4 dangerous zones in order to take a trip of a life time... To the Sun! :). During play, you will encounter assorted aliens, which just don't like rockets very well and try their damned hardest to stop you from flying over their territory. Luckily, your rocket consists of a super fast ray gun. Firing a few hits will knock those aliens flying (or perhaps making them toast). You have to fly through 4 different zones. There are as follows: Space, above and beyond, alien water planet, bubble planet, and the planet of death. Avoid hitting deadly obstacles. Collect shields to allow free flying and also protect yourself from aliens.

TASS Code snippets are documented. 

View TASM/CODENET shield code 1 (1 player only)

View TASM/CODENET shield code 2 (2 players)

View TASM/CODENET Rocket 'n Roll full game enhancement code

Destroying all Enemies on screen in one go
By Jon Wells

Source: Twin Tigers by Alf Yngve (Binary Zone PD)

So here's a few pointers that will help you to do it. For a start you should make sure that the linked boss you want to blow up is the only enemy present on the screen as the routine will kill all enemies (this can also be tweaked to use as a smart bomb!), I used this code in Archetype for the potion that kills all on-screen enemies!
Right, first you'll need to ensure that all the linked enemy sprites are set to the same score, for example 2,000 points if you kill any of the linked sprites. Only the bosses should have this score so make it unique. Next, you'll need to create a routine to check for an increase in this score to determine that a boss sprite has been killed. Just code a simple routine to check that the score of a player has increased by 2,000 on any v-blank..
You can easily do this by copying the players score into a temporary data score every v-blank, then, before you refresh the next score on the next v-blank, check the present player score with the stored previous score. If there is an increase that matches the boss sprite death points then you'll need to set the explode_timer to any number above zero for v-blank number of frames that is enough to kill all enemies. For example setting explode_timer to $0a will make an attempt to explode all enemies for the next 10 v-blanks. That should be enough to kill all enemy sprites...
Anyway, here's the main explode routine that you'll need to add...
IMPORTANT: If you use this feature on boss enemies. Please ensure there are no other small enemies or collectable items amongst the boss. This code operates the in-game SMART BOMB effect.
Explode_Init_loop: ; call this every v-blank
                LDA explode_timer    ;Check if explode_timer = 0
                BNE Turn_Explode_on  ;Else keep it switched on
                LDA #$00  ;Switch off the explosion timer
                STA explode_timer
                LDA #$4C  ;Restores the standard/sideways
                STA $55E1 ;SEUCK scoring features after a
                LDA #$A5  ;full linked enemy explosion
                STA $55E2 ;(Store JMP $5BA5).
                LDA #$5B
                STA $55E3
                LDA #$08
                STA $531D
                LDA #$BD  ;Restore SEUCK scoring pointers
                STA $5568 ;back to normal, until yet another
                LDA #$F7  ;boss / smart bomb effect has been
                STA $5569 ;featured.
               LDA #$B6
                STA $556A
                DEC explode_timer ;Decrease the explosion timer
                LDA #$00          
                STA $531D
                LDA #$4C
                STA $5568
                LDA #<Explode_Main_address ;Low byte
                STA $5569
               LDA #>Explode_Main_address ;Hi byte
                STA $556A
                LDA #$60
                STA $55E1
                JSR $55B6
                LDA #$4C
                STA $55E1

explode_timer    !byte $00 ;Pointer to time explosion effect
In some games, such as Zap Fight, it is possible to also add a timer, which will flash the screen. For example (To be linked with the loop which contains the enhancements code:)

                         ldx ExplodeFlashPointer
                         lda ColourTableToReadSet1,x
                         sta $d021 ;Background Colour
                         lda ColourTableToReadSet2,x
                         sta $d022 ;Background Multi-Colour 1
                         lda ColourTableToReadSet3,x
                         sta $d023 ;Background Multi-Colour 2
                         cpx #$0b (Hex Amount of colours to read = 12)
                         beq StopFlash
                         inc ExplodeFlashPointer

StopFlash                ldx #$0a (Hex Last but one position for pointer = 11)
                         stx ExplodeFlashPointer

;Colour table ... Make sure the Last byte matches the colour of your background

ExplodeFlashPointer !byte 0
ColourTableToReadSet1 !byte $09,$02,$08,$0a,$07,$01,$07,$0a,$08,$02,$09,$00                             
ColourTableToReadSet2 !byte $02,$08,$0a,$07,$01,$07,$0a,$08,$02,$09,$00,$0b
ColourTableToReadSet3 !byte $08,$0a,$07,$01,$07,$0a,$08,$02,$09,$00,$0b,$0c

There is an alternative to this trick. The SMART BOMB trick. In which you use a similar subroutine from the previous chapter. If the enemy equals the object that should generate such explosion. Set the ExplodePointer as $0a.

Note from Richard. The subroutine needs to be linked to a subroutine linked at $4503 in order to set the explosion up. Under the main enhancements code where you have the SFX routine. Add JSR Explode_init_loop. Now referring to the power up listing in the chapter before hand. This trick to destroy all sprites can be done, if the explode_timer is set inside the power up routine. BEWARE... If you use the routine as a boss explosion. Make sure there are no other enemies or collectibles on screen otherwise they, too will explode. And the player might gain another power up or something like that (if the feature is implemented).

Background Animation and Parallax Scrolling
By Richard Bayliss, Eleanor Burns and Jon Wells

Source: Renovator by Simon Peterson

There have been some requests on background animation, where charset animation is concerned. In this chapter, we take a look at scrolling single chars inside a SEUCK game. We will be looking at scrolling the char upwards, downwards, left, right and also a push/scroll parallax operation.

There are 8 bytes inside a single char, and the value of the char is noted down. The background char address is set at $f800-$ff00. Where there are 254 chars, instead of 256.

To calculate the address for where the char lies. In a M/C monitor, you type:

N CharNo*8+$f800

Say for example in the game Renovator, the characters that represent a blue void are chars 252 and 253. To work out the char value 252 inside a machine code monitor, we type:

N 252*8+$F800

The result is:


Now what about the code, regarding scrolling chosen background character?

Assuming you know $4503 and adding enhancement code. Simply add JSR before adding RTS. So that a new subroutine can be called. Which of course will be this one. For example

At $4503, in assembler add something like:

                jsr enhancements
                ... rest of code
                jsr scroll_char_up ;can be modified to a different subroutine
                jsr $5c94

Scrolling the char upwards
By Richard Bayliss

Example: Night of the Valkyrie by Eleanor Burns

This trick can be used for making a parallax scrolling effect, in a SEUCK game. Say for example you created a space game, which used just a plain black background, and replace the background char with something more exciting? Maybe add a subroutine, where a scroll moves at the speed of 2. Pick out a single char, and then that single char upwards to give a an parallax effect. This trick is perfectly brilliant. The trick would also be good for scenarios where a player is traveling along on a conveyor belt, while the screen is scrolling. BEWARE, pausing the game will also scroll the chars up. In oder to fix this problem, I suggest you refer to the Push/Scroll Parallax feature.

                     lda $ffe0            ;Get first byte of selected char (Char number 252)
                     sta chrtemp1         ;store it to a temporary byte (any free byte that is available in memory i.e. $6900)
                     ldx #$00             ;Starting loop to move bytes backwards.
chrloop1             lda $ffe1,x          ;Fetch next byte of same char
                     sta $ffe0,x          ;Store to current byte of char
                     inx                  ;Move on to the next char byte
                     cpx #$08             ;Until reached the 8th char byte
                     bne chrloop1         ;loop
                     lda chrtemp1         ;Fetch the stored byte of selected char
                     sta $ffe7            ;Store it as the last byte

If you find the scrolling is just too fast, and you want to slow it down. A simple delay subroutine (using a delay pointer) will help show things down a little. For example in scroll_char_up before the main code add:

                     lda scrdelay
                     cmp #$03         ;Speed of delay limit..... Can be changed if you need to
                     beq docharscroll ;If limit reached, move to docharscroll subroutine
                     inc scrdelay     ;Increment delay value
                     rts              ;Return To Subroutine

docharscroll         lda #$00         ;Reset scroll delay
                     sta scrdelay
                     ... NOW COPY THE ABOVE CODE char_scroll_up

Scrolling the char downwards
By Richard Bayliss
Example: Trash Course by Inferior 

It is also possible to add a downwards scrolling effect to your characters. All that you'd need to do is reverse the process. Simply by fetching the last character, store it, call a loop and then push all the bytes of the character forwards. Then fetch the temp byte and store to the first character again. The code below shows you this trick - although it will not give you any sort of parallax effect :). This is best used for things like flowing rivers, waterfalls, etc.


                                    lda $ffe7
                                    sta chrtemp1
                                    ldx #$07
chrloop1                            lda $ffdf,x
                                    sta $ffe0,x
                                    bne chrloop1
                                    lda chrtemp1
                                    sta $ffe0

Scrolling the Char to the left / right
by Richard Bayliss
Example: Dodo's Deep Doodoo by Carl Mason

You can also scroll the char to the left, simply by using ROL. This can be used a number of times to increase scrolling speed for the single char. This effect is best used with single colour hi-res characters, otherwise the scrolling could look odd..

                                  ldx #$00
scrloop3                          lda $ffe0,x
                                  asl                 ;Repeat the two lines to increase
                                  rol $ffe0,x     ;char scroll speed.before adding 'inx' - rol = rotate to left
                                  cpx #$08
                                  bne scrloop3

You can also rotate chars to the right inside a SEUCK game, using the similar, but also by rolling the 8 bytes of a characters the opposite direction.

                                  ldx #$00
scrloop4                          lda $ffe0,x
                                  lsr                 ;Repeast the two lines to increase
                                  ror $ffe0,x    ;char roll speed.- ror = rotate to right
                                                                                                                             cpx #$08
                                  bne scrloop4

Push/Scroll Parallax Technique
by Eleanor Burns, Richard Bayliss and Jon Wells

Example which uses this trick: Laser Hawk by Shaun Coleman

If you wish to use this feature, it is best used with scroll speed 2 (Push screen 2) with the scroll_char_up subroutine. If push scroll speed 2 is used, no delay subroutine to control the speed of the upward scrolling would be required. Therefore the trick will work nicely. This trick can also be used for games which use SCROLL as well as PUSH. So that any time the background stops pausing, the rolling characters should also stop. Here's how the trick works:

The VIC2 Vertical Screen Position - $D011, is checked to see whether there is movement or not. Basically if $D011 does not equal the value of the last tempbyte (tempbyte 2) the char rolling should still take effect. It is also possible to use this feature in Sideways SEUCK, but instead of using VIC2 Vertical Screen Position, use VIC2 Horizontal Screen Position - $D016, and use the charset rolling technique.

                                                                                        lda $d011
                                   cmp tempbyte2
                                   bne scroll
scroll                             ... see scroll_char_up, but before rts add ...
                                   lda $d011
                                   sta tempbyte

Full Level Control 

During some exploring around the SEUCK Editor. Eleanor Burns has discovered some cool tricks in which could give you control over the levels inside a SEUCK Game. The actual current level timer is located at $408D and is shortly followed by an instruction.

> 46A9 DEC $408D

By changing this instruction to a simple RTS, you can make a persistant still screen level. By then creating another condition set $408D to a value of ZERO
(Eleanor POKEd it in Action Replay). could be set to an object destruction, for example. A boss stage - If a big boss is destroyed, and object detection code is triggered. The end of the level can be set and jump directly to the next level at discretion, instead of having to wait for a new level to come.  This could be a way for designers of still-screen SEUCK games to set proper missions and goals, and also for boss levels to actually end once a boss has been destroyed (Rather than the usual survive ten-twenty seconds, boss killing strictly optional scenario). This could be a clue to making non-linear games.

Level settings in SEUCK editor. These settings are saved in the program in 22 data sets from $B776 to $B808. When the game runs, the game checks the level pointer ($5DC9) and loads in the corresponding data set accordingly. Among other things, this resets the current level timer to the time limit set for a still screen level in editor.

This short routine checks the current level timer ($408D). If it is zero, the level updates. Otherwise, the timer is decreased.

By removing the decrement instruction from $46A9 and changing it to a simple RTS, thus ending the subroutine prematurely, the level timer is frozen. Now a still screen level can last forever. Not much good by itself, but since the earlier part of the routine is stil lthere, it opens possibilities.

CCS3 = An example game, stuck on level 1, going nowhere.

However, as an example for how this could be used to set conditions in-game, let's POKE the level timer down to zero (memory address $408D = 16525 in Action Replay) ...

... and the level changes. Instead of POKEing, one could set an in-game condition to reduce the level timer to zero: killing a boss, collecting an object (both using object detection), or reaching a certain on-screen position by detecting the player's X and Y positions. By carefully manipulating the level pointer as well, it would also be feasible to repeat levels or have them load in unconventional orders (by setting it one level below the level yo uwant loaded before triggering the transition).

Making Platform Games with SEUCK
by Eleanor Burns

A lot of people have been bragging about the lack of possibilities of what can actually be done with the SEUCK engine. Of course we have a frame work, with the good old SEUCK Redux - With that anything is possible. However, if you are not too familiar with the ACME cross assembler, and  you wanted to make SEUCK games that run on a standard SEUCK engine,  but wanted to implement code to make the player use a platform game style engine in Sideways SEUCK via an Action Replay Cartrirdge. With special thanks to Eleanor Burns, the impossible has now become possible. Here's her amazing tips for this.

 The first step will be to reroute the code from the SEUCK main game code, to custom code. Then create the custom code which will check the jump counter value and then perform various other operations depending on joystick control and also player area size. It is generally possible to make a float 'em up style game with Sideways Scrolling SEUCK - Simply by creating an increment of the player's Y position - until, of course it reaches a collision background. Eleanor's idea is much better. Check this out :)

Example jump download available

Flip Screen with SEUCK (Continued from jump example)
by Eleanor Burns

The accompanying demo shows a simple layout of three screens in an L-shape, thus showing the possibility of controlled flick-screen movement in all 4 directions using a new subroutine to manipulate SEUCK’s level timers, map settings, and level redraw feature. Before beginning this, however, it is necessary to make changes elsewhere in the code.

In order to use still screen levels as persistent, rather than timed (as is standard for SEUCK), we must reprogram existing code. Go to $469F and change the instruction to “LDA #$01.” This tells SEUCK to stop counting spaces between seconds, so there is no delay before a redraw. Then change the instruction at $46A9 to “RTS.” This stops SEUCK from counting down altogether. Now, the level will only redraw when we decide (according to any trigger we are to set – in this case, player screen position).

Also notice how I have set the levels in the SEUCK editor. Level 3 is doing all the hard work, and is the one which will be re-used throughout the game, its map settings ($B784 and $B786) changed with each change of room. These settings can be 0-255, and are counted in background blocks. Since each screen is five blocks high, that allows for a map of up to 51 still screens. Level 2 is just used for redraws, so make sure it is set accordingly. Its location is irrelevant. Level 1 is not used at all: in a finished game, I would use it for a “get ready” screen where I would reset all new variable, but in this demo it does nothing, so make sure when testing the demo to always start on cheat mode (or the player will just materialise in empty space).

This demo already has a platform jumping routine programmed in at $1980, with both players linked. That code is explained separately (and is thankfully much quicker to implement). It is important to note two of its settings when doing flick screen, though: the jump counter (upward momentum) at $4E9B and the jump recovery counter (checking if player without momentum has held the same y-pos long enough that they are on a platform and not falling) at $4E9C.

When linking two players this way, it is important also to unify their char collision coordinates (or the top half of a linked player does not necessarily know that its bottom half has touched a platform, leading to glitches). I do this by giving player 1 player 2’s char collision settings (Make the following program changes: $4A8B LDA $BC32, $4A8E LDA $BC31, $4A91 LDA $BC33. If you’d rather make player 1 the main “collision” player, program $4D9A LDA $BC02, $4D9D LDA $BC01, $4DA0 LDA $BC03 instead). You can also unify their directional animations (recommended, if using that mode) by saving the X-value you get after the jumping routine into a tempbyte ($19CC here) and feeding it into the other player’s joystick routine (I do this with the following changes: if player 2 is “main” then $4B8D LDA $19CC, $4B90 TAX. For making player 1 the main, this would go at $4E9D instead).

Now, for the flick screen code. Please refer to the screenshot for the addresses. As with most SEUCK extra coding, this is rerouted from $4503 with a command “JSR $6580”, so the first thing we must do is type “$6580 JSR $5C94” to let SEUCK do its normal things. Now for the new stuff …

$6583 - $6595: bolts player 1 onto player 2 with a 21-pixel offset (15 in hex) to make a character two sprites high. In a finished game, this would require a linked death routine as well (cf. “spawning players at last position after dying” in SEUCK School).

$6598: Just jumps to the address where the main routine is. For unclear reasons, it is necessary to finish with the “smart bomb” routine, but in the interests of getting it out of the way I just decided to branch here (so I could do it first, but run it last).

$659B - $65EE: The “smart bomb” routine, from SEUCK School ( Very important, this will clear the screen of all unwanted sprites before redrawing a new one, so nothing will carry over as the player flicks to a new screen. In the game, I could also use this as a standard bomb, or for solving puzzles. The “timer” for the bomb (i.e. how many v-blanks to run the routine in order to maximise effectiveness) is a tempbyte, $19CD.

$65EF - $66B3: The bulk of the screen redraw code is four positional checks to see if the player has reached any of the screen edges. At maximum player area (in SEUCK’s player limitations), the edges correspond to the following hex numbers: top edge = 32, bottom edge = E5, left edge = 16, right edge = 33). Whenever player is not at one of these coordinates, we can branch past a chunk of code and onto the next (with CMP, BNE commands). If, on the other hand, they are, the player is teleported to the opposite screen edge, though not quite to the furthermost point (to avoid an instant redraw back). The “almost there” hex coordinates are 33, E4, 17, and 42. When changing x-position, it is also important to change the player’s X-MSB ($BC02 for P1 or $BC32 for P2). For the left side it should be 0, for the right side it should be 1.

After the teleport, take the changed coordinate value(s) and save it / them into a tempbyte (Here, I am using $19CF for old X, $19D0 for old Y, and $19D1 for old X-MSB). This is necessary as player is going to be frozen during the redraw (and it is useful, in any case, to have that option at other times). Also, set to zero another variable I call the “redraw boolean” ($19CE). This will later be used to tell the program it is time to flick screens. Also, the bomb timer ($19CD) needs to be filled. I give it 4 v-blanks to clear all sprites, which seems sufficient (More would possibly be more reliable, but the more you give it, the more delayed the transition).

Next, we need to alter level 3’s map positions to find our new screen. For this demo (and, hopefully, game), I envision a 40-screen map in a 10x4 pattern. Moving right moves one screen ahead (or five blocks on the vertical SEUCK map), moving up moves 10 screen ahead (or 50 blocks). Vice versa for left and down. I use a DEY loop in each of the four position checks, tied to level 3’s map settings ($B784 and $B786), to find the right screen (32 = 50 in hex).

After this is done, we need to set the level pointer back to level 2 (by putting a value of #$0E in $5DC9). We are now ready to activate the changeover …

$65B6 - $66DC: Check that boolean at $19CE to see if it’s set to zero. If it isn’t, everything is running normally and the routine is bypassed. If it is, a redraw is in effect, and we now need to check the bomb timer $19CD. If that’s higher than zero, the old screen is still being wiped, so freeze the player (feed those old coordinate tempbytes $19CF-D1 into the current player positions) and bypass the final redraw. If the timer is zero, proceed to the redraw: deactivate the boolean (feed a value greater than zero into $19CE) and then knock the main level timer $408D down to zero.

Almost done, but in the interests of neatness …

$66DF - $66E8: If a redraw is in effect and the player is detected at E4, thus meaning they are moving up a screen, it’s a good idea to give them some more jump momentum, as they will have lost a little during the wipes. This just puts a value of 32 (hex 20) into the jump counter at $4E9B. It’s a bit of a cheat with physics, but makes sure they have enough momentum to reach the platforms above.

$66EB - $66FA: Saves all current player coordinates into the aforementioned tempbytes in case we need to freeze the player.

$66FD - $6706: This last bit before the RTS simple corrects a bug. As the Y coordinate is frozen during the wipes, the player can end up thinking they are on solid ground and able to jump (which is a big problem if they are actually falling between screens, for example). To avert this, whenever the level pointer is set for level 2 / #$0E (the transition phase), refill the jump recovery counter at $4E9C.

And that’s it. A crude but functional flick screen routine that will enable SEUCK to make non-linear games (possibly of the Monty Mole, Jet Set Willy variety, or Cybernoid, Cyberdyne Warrior stylee if violence and shooting is still one’s preferred thing). One limitation to remember, though: since you are basically bombing all enemies whenever you leave a room, it’s best to forget scoring. Just make survival the goal …

Oh... and here's the full listing

Example Flip screen download available

... Additional information, and a quick bug fix:

The code from 66E2 to 66E8 (that refills the jump counter when player detected at the bottom margin during a screen transition) is not always reliable (and it tends to fail further up the map you get, for some reason). A more reliable method is just to put a couple of lines of code to refresh the jump counter (LDA #$20, or thereabouts, into whatever tempbyte is serving that purpose) into whichever of the screen checks registers an upward screen transition (In the example, from 65EF to 6617).

The debug to stop the player from jumping on the bottom edge of the screen is also not especially reliable, but this may be because I set the "teleport" margins too tightly (causing the program, on certain screens, to instantly redraw back again because the player is touching the edge when they shouldn't be). I managed to solve this by just making the player materialise a bit further down from the very top edge of the screen when they fall a screen (In the example, by setting the line 661E to LDA #$3F instead of LDA #$33).

Hopefully this will nicely fix the flip-screen routine for a full game, touch wood ...
Linked Players and Score + Lives Sharing
by Richard Bayliss

Example: Re-Alienator by Alf Yngve

Earlier on in this chapter, I gave you a quick tip on which you could link 2 players with one joystick (POKE 16578,2 or in Assembler LDA #$02 : STA $40C2). SEUCK will display two score panels. Unfortunately however, with linked players it doesn't really make any sense to have two scores. When I was enhancing Alf Yngve's Re-Alienator for a past TND Christmas release update. I needed to generate some code in which linked the player's score data from player 1 with  player 2's score panel, along with the amount of lives that had to be deducted. Also, Player 2's score panel sprite needed to be removed. Luckily I still have the Re-Alienator source for you to check out.

First off, here's a simple code routine, which will remove one of the player 2's score sprite, and align player 1's score panel to the centre of the screen. It basically reads the sprite position table, and places the score panel sprites in a different place. It also removes player 2's score panel.

;Remove player 2's status panel, and centre player 1's panel 

ldx #$00
lda CentreScorePlot,x ;Read new position table for score panel
sta $5eaf,x ;Store sprite X/Y position for score panel
cpx #17
bne PlotCentreStatus
... do rest of code ...

;... at the end of your code, add Actual table for CentreScorePlot

!byte $03,$89,$07,$a1,$07,$b9,$07,$d1,$07,$77
!byte $77,$77,$77,$77,$77,$77,$77,$77,$77,$77

Now then. If implemented correctly before your game is run to the front end. The score panel for player
1 will be centered and player 2's score panel is hidden. GREAT! However, shared scoring in
no way has been implemented yet. You would need to add some additional code.

Under the last subroutine (bne PlotCentreStatus) we should create a poke which will force a new
score result, simply by plotting a low and high byte of the calculated shared score.

;Replace player 1's score with the final score added up
;between both players.

lda #<store
ldx #>store
sta $5a2a
stx $5a2b

Now, what about sharing the score? In the main SEUCK Enhancements in game loop. We create
a subroutine that will share player 1's lives with player 2's lives. Also call a subroutine to calculate
the final score, according to the score of both players (Player 1 and Player 2). The Enhancements
routine should be JSR'd to $4503 (4503 JSR Enhancements)

lda $5db8 ;Grab player 2's amount of lives
sta $5db7 ;Store to player 1's lives counter ... you can also reverse
;this trick if you wish to.
cmp #$00 ;Life counter = 0
beq .GameOver
jsr CalculateScore ;Call subroutine to add p1+p2 score
jsr $5C94
jmp $4245 ;Run back to the title screen

Now for the main score calculation.

ldx #$05
lda #$00
clear01 sta borrow,x ;Clear score digits
bpl clear01

ldx #$05 ;We are reading 6 digits
calc01 lda $5ea3,x ;Read player 1's score
adc $5ea9,x ;Read player 2's score
and #$0f
cmp #$0a
bcc noborrow
inc borrow-1,x
sbc #$0a
ora #$30
sta result,x
bpl calc01

ldx #$00
calc02 lda result,x
sbc #$30
sta store,x ;Print result on panel
cpx #$06
bne calc02

Now here comes a table for plotting the score panel points.

borrow !byte $00,$00,$00,$00,$00,$00
store !byte $00,$00,$00,$00,$00,$00
result !byte $00,$00,$00,$00,$00,$00

Although the example should work on the score panel, there is also another tip you should also
if you're using linked players or twin mode in your own games. You need to generate linked deaths
to player 1 and player 2, unless of course one of the two players is invulnerable. Shared lives should
still take place.

An Alien Autopsy

I have uploaded the complete C64 project Re-Alienator on to this page, should you wish to explore through the game code to see the enhancements working in place. Click the disk icon to download
the complete project and its source code. This is a stunning SEUCK game creation, which was written by Alf Yngve back in 2013, for the TND Christmas 2013 update. This game features score
sharing and lives sharing, and a few other enhancements, including a new front end. If you just want to see just the source in full. Click on download link underneath the disk icon.

Re-Alienator Enhancements Code

Score Sprite hack trick

by Eleanor Burns

here are two identical instructions for plotting the life counters:

$5AFD   BD A7 F5   LDA $F5A7,X (Player 1 lives)

$5B65   BD A7 F5   LDA $F5A7,X (Player 2 lives)

By changing the value $F5A7 in increments or decrements of 8 (corresponding to the characters in the front end set) it is possible to change the character displayed for either of the life bars, including using the editable but otherwise unusable "F1, F3, F5, F7" chars. In a one-player game that makes surreptitious use of the second player (maybe for a multi-sprite player character, as a power-up, or just as an invisible presence to add some extra gameplay element) one of the bars could thus be used as an energy bar, or to store money, ammo, mission goals, smart bombs, etc.

Using MORE than 2 animation frames for player directional movement (for 1 player games only)
By Eleanor Burns

I've long wanted to improve directional animations from the lousy two-frame cycles SEUCK allows, and I had a stab at that in Legion of the Damned 3
 by using otherwise useless frame tables as "storehouses" for
quickly pasting in extra player frames ('cos whoever needs 8 enemy deaths anyway?).
Then I realised it might be simpler if I just changed
player 1's object number, which is even better as it also changes animation speed, though, as in this
 demo, it's still better to have the
same number of frames in the table, or the animation can get caught on empty frames and make the player disappear until
it cycles again.

The code:

This is just a simple demo to demonstrate how in a one-player game improved walking animations could be added by using the player 2 frame tables and using joystick checks to switch to them, and back again. It shamelessly uses a copyrighted character, so I can't see it becoming a full game in its own right, though. I just really liked his animation. ;)

Download example demo and code snippets (Code snippets requre Action Replay M/C monitor)

A quick note on that subroutine: since it's only reading rather than hacking the joystick, one can (and probably should) use BIT rather than AND to make the boolean checks. However, doing so saved me no memory at all in this demo, but it may be worth bearing in mind for longer versions of this, as in a full platform game this will also be the best place to put in the jumping and gravity code.

Background Terrain Trick (Detecting background type)
by Eleanor Burns

Eleanor is back with another trick that might come in handy for developers. By playing around with the char collision routine for player 1 you can customise your own
terrain effects. First, reroute (to be on the safe side, I unconditionally JMP)  to a new subroutine at $4AA7 ($6580 in the example).
Then, at $6580, you can pretty much add in as many char checks
as you like, as long as you finish by JMPing to $4AB6. In the example,
CMPs are used to check the char number P1 is in collision with. If it matches up, a simple effect is carried out (border flash or background
flash in this example), if not it branches ahead to the next check or the end of the routine. Instead of these simple effects, though, it
could be used to add in object transformations (say, turn the player into a boat or a half-submerged figure on water chars), alter player
speed (slow on rough terrain), or trigger death as per usual. There will be similar code for P2 around the $4D9A mark, which could most probably
be rerouted through the same subroutine (unless the designer wanted the players to have different responses to the terrain, of course).

Example 1: Background Flashing Trick

The second example is a more practical example of how the routine should be used to effect an
object transformation on different terrain: when the car touches water (CHAR 002), the first sprite
in player 1's object table ($2C80) is switched from SPRITE 000 (Standard Car) to SPRITE 001
(Aqua Car). Vice versa if the car is touching any other char.

In game speed is determined by two separate addresses per player, BC04 for the x axis and
BD00 for the y axis (and for player 2 it seems
to be BC34 and BD30). Both need to be hacked
 to change speed, and this
new version of the demo does that, slowing speed drastically on the
and slightly in the water.
One thing to note, though, in its current form this routine can cause problems with solid stopping chars (though it seems to work OK with fatal ones), so I may have to refine it if I can, though it shouldn't be too difficult to approximate a solid check (Save the last "clear" x,y, and x-msb point to tempbytes, reload them back in if player collided with chars over a certain value). Anyway here's the routine that performs the background check and transformation:

Here's the download to see the example in action

The SEUCK VAULT andTutorial Videos

For more tips, which include music installation, charsets background animation, and others please visit the SEUCK Vault web site, and have your action replay handy - or 1541U2 maybe :o)
Also check out the video tutorial on YOUTUBE.COM on how I added music and other features on to SEUCK games.

VIDEO 1: Enhancing SEUCK games - Part #1 (Adding title and in game music and bug-fixing games, using packers/crunchers for compression of games)
VIDEO 2: Enhancing SEUCK games - Part #2 (Adding animated charsets background)
VIDEO 3: Adding only title music to your SEUCK game


Now for something special for you to play with. It is a little something I have prepared for you, to help you enhance your own SEUCK game creations. It is the SEUCK FRAMEWORK, a programming source, in which allows you to add music, additional code and other great things. In order to be able to use this framework, you will also need Exomizer and possibly SID Reloc. You probably might have those already, but they all should be found on various cross-platform based web sites, and CSDB. Ensure that you security software allows all the C64 cross platform programs to run.

Assuming that C64Studio is installed on your PC. It is time to download and have a play around with the SEUCK framework. It comes with an example game work file and a couple of tunes. You can use C64Studio or .D64 editor to rename and extract the SEUCK work disk files and rename the !BIN "NYAAAAH.PRG" with one of your SEUCK 'ALL DATA' or second file which you saved 'FINISHED GAME' (249 blocks). Alternatively, if you don't have any work disks or 249 block finished game state. You can freeze the current game state and then save your game data from $0900-$fffa using the M/C monitor. (S "game",8,0900,fffa).


This version allows you to alter colour of the colour bars, play title music, in game music or neither of these. Here are some quick instructions to get you started:

1. Load C64Studio, set up the configuration for testing in VICE (FILE/PREFERENCES, select path of VICE and executable).

The source code should then display.

Assuming that the project has been extracted correctly and Exomizer is in C:\Exomizer\Win32. Try a test run of the framework. Wait a few seconds for Exomizer, then you're ready to launch.

Here's what you should get from the front end:

To comment out certain features, just add a ; by EXAMPLE = 1. For example, if you wanted just title music, and no in game music. ;InGameMusic = 1, etc.

Things to try:

Relocate different tunes to the same addresses, using either native C64 music relocators or SidReloc

Change music filenames to something like "mytune1.prg" for title music and "mytune2.prg" for in game music

Create your own 8 rasters over the front end.

Import PRG images of your own SEUCK work files (ALL DATA file or 249 block FINISHED game). Have a little play around with the current framework, and get used to the music player, before we move on to enhancing the games more with the same framework, by altering the player at $4503, to call multiple subroutines to do other tricks (Background animation, etc).

Dark Force - Disected

Right then folks. Who remembers the classic 'Light-Force' by FTL, released by Hewson back in the 1980's? You probably might have remembered it. A pretty good vertical scrolling space shoot 'em up of its time. Highly difficult and very playable. Now fast forward the tape further along, I stumbled across issue 41 of Commodore Format's 'Secret of SEUCKcess feature', which had a POKE 16578,0 for 1 player only or POKE 16578,1. However I tried POKE 16578,2 and ended up having 2 players linked to one joystick control. Interesting. Of course back in the 1990's I didn't actually make any SEUCK games that used that easter egg POKE. Someone else beat me to it (Check out Strike School on the contributors' page).

While I was trying to explore the expanding limitations of SEUCK further, I came across with some possibilities on how to actually link players together and make them re spawn together. The first game I enhanced to use that exact effect was 'The Huntress of Midgard'. A horizontal scrolling SEUCK game which bolts 2 players together. Then in 2014, I set myself a challenge. To write a Light Force style game, with Alf Yngve, using SEUCK. Behold 'Dark Force'.

I have dedicated a page and source code to Dark Force. You can browse the source on each page, or just download the the binary data and  source and try it out in C64 studio.

This way for Dark Force - Dissected

Now for something special. SEUCK games have always been the same? Now what if you wanted to program SEUCK to do things your way?. Well enter SEUCK REDUX, a scroller with a difference. This framework allows you to import your own SAVE ALL DATA files from SEUCK, and import them into a more stable, and flexible scrolling engine. SEUCK Redux allows you to PUSH SEUCK to its limits even further. We have specially written a page, dedicated to getting you started with this excellent framework. Maybe one day you'll be able to program a stonker, rather than a stinker of a game :)

SEUCK Redux Special


Do you remember the previous C64studio based framework for SEUCK game creations. Well, a new framework engine has been created for SEUCK games, which can be operated in Kick Assembler. Unlike the C64Studio version, I did a long while back - which has just the old RAW front end used time and time again in SEUCK. The KickAssembler based framework, has the complete works. You are able to create and implement a new front end for your SEUCK games, with a high score table. All you need to do is use Charpad to design your screen and export it to the source files, read through the code carefully, and implement what is possible. It is also possible to add additional in game enhancements code to your SEUCK game, by following other tips in SEUCK School, and of course the SEUCK Vault. Please note - you'll need to learn basic assembly language if you are to implement additional routines, and features into your SEUCK game. SEUCK School Tips is a good start to get you going. The link below is a complete guide to setting up your SEUCK games to work with the framework. Should any upgrades be made in the future, it will be announced on the TND news page.

KickAss SEUCK Framework

Version 4 has also been added to the KickAssembler SEUCK Framework page. This will be the final upgrade (for now). Version 4 has some of the old favourite features, but there are also a lot of NEW features. Including multicolour bitmap logo, sprite multicolour panel, power ups upgrades for both player and player bullet, and a whole lot more. Plus there is a D64 with a free utility to help fit your 40x10 Koala Paint logo bitmaps into the SEUCK framework (or your own demos and/or intros).