TND Productions, C64 News + Updates

(NOTE: 1541U2 Users, require TASM/Codenet setup for some of these tips)
Otherwise, use of C64Studio (or ACME) PC cross assemblers and the SEUCK Framework is HIGHLY Recommended

By Richard Bayliss

General SEUCK bits:
First steps; Cleaning, Packing/Crunching SEUCK / Fixing Sideways SEUCK Flicker / Fixing Player 2's score per object collected / Working the PAL score on NTSC machines / Controlling 2 Players with 1 joystick / Peek-A-Boo Hide and Seek / Decorate my Score Panel / Hires/Multicolour Sprites / I want Big Aliens / Level Detection - Colour changing / Getting to know the Front End / Adding some music / Common SEUCK Subroutine Tricks
/ Player Re-Spawn tips Power Ups and Detecting an enemy hit / Destroying all Enemies on screen in one go / *new* Background Animation and Push Parallax Scrolling

Media + Resources
/ The SEUCK Vault and  SEUCK Enhancing Videos
/ SEUCK Framework

Special features:
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.


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 mygamecrunched.prg -x2

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

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

Fix Sideways SEUCK map flicker bug
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.

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.

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


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           ;Read ACTUAL  X position of player 1
                           sta $40a3           ;Place it into SEUCK's default XPOS for player 1
                           lda $bc02           ;Read ACTUAL X MSB position of player 1
                           sta $40a4           ;Place it into SEUCK's default MSB for player 1
                           lda $bc03           ;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            ;Read actual X position of player 2
                            sta $40b6           ;Place it into SEUCK's default XPOS for player
                            lda $bc32           ;Read ACTUAL X MSB position of player 2
                            sta $40b7           ;Store it into SEUCK's default MSB for player 2
                            lda $bc33          ;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

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

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