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
www.csdb.dk, otherwise specified.
ACTION REPLAY FREEZER SAVING TIPS (1-filing)
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.
CLEANING, SAVING AND COMPRESSING A SEUCK GAME WITH A M/C MONITOR
Tools required: (C64) M/C Monitor (Action Replay/Retro Replay/1541U2, Your SEUCK game, native C64 packer/Cruncher) (PC - optional D64 editor)
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
249 "MYGAME "
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).
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.
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:
The front end comes on. and the game should work nicely.
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
... compress your SEUCK game using the following command:
C:\exomizer\win32> exomizer.exe sfx $4245 mygamenew.prg -o mygamecrunched.prg
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.
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)
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
Step 2: Wait for the packer to load the program, then
pack it (Black border + white stripes = loading ... Multi-colours =
Step 3: Screen turns grey. Press SPACEBAR to save the packed program to disk.
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)
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
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
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
although this kills the constant map flicker bug - it can make
the upper border look pretty odd - unless default background colour
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:
>44F4 JSR $6900 ;JSR FIXSCROLL
... or wherever you want to put the code.
FIXSCROLL: $6900>6900 LDA #$00 >6902 STA $D020>6905 STA $D021>6908 LDA #$19 ;STABILIZE VERTICAL SCREEN POSITION>690A STA $D011 ;HARDWARE VSP>690D LDA #$32>690F CMP $D012 ;COMPARE RASTER POSITION>6912 BNE $690F ;If using assembly instead of M/C monitor. Change to BNE *-3 instead>6914 LDA #$09 ;PLACE YOUR SEUCK GAME BACKGROUND COLOUR HERE>6916 STA $D021>6919 STA $D021 ;ERM WHY DID I DO THIS TWICE? HEHEHEH. >691C RTS
ADDITIONAL TIPS AND TRICKS
Fix Player 2's score
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
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
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
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
ONETIME LDA $02A6 ;Hardware machine type???
CMP #$01 ;PAL
;PAL Detected - Run title screen immediately
;NTSC detected, call the new position for the
MOVELOOP LDA #$FF ;game's status panel to display on NTSC.
PAL JMP $4245
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
CMP #$01 ;PAL
;PAL Detected - Run title screen immediately
;NTSC detected, call the new position for the
MOVELOOP LDA #$FF ;game's status panel to display on NTSC.
PAL JMP $4245In
the music player area, you would need to change the code to time
correcty with NTSC machines. For example on the SEUCK title screen:
or if ingame music at $4503, or inside an interrupting subroutine
NTSCM INC MUSPTR
PALM JSR MUSICPLAY
RESETPTR LDA #0
MUSPTR !BYTE 0
2 Players with one control
By Richard Bayliss
Source: Strike School by Carl Mason (TND Contributors)
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
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)
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
POKE 17427,208 ;WITH $D01B, AS NOT NEEDED
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
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
Decorate my score panel
By Richard Bayliss
Source: Nyaaaah! 11 by Richard Bayliss (TND Games)
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
Load your own SEUCK game. Freeze the game, enter the M/C monitor and type in:
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:
Type X to exit the M/C monitor and go to the menu. Select POKES and type in the following POKE bellow
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)
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:
> 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:
>4566 JSR $080C
This will reduce the size of the score panel back to its correct state.
Should the routine $080c - $0818 been added.
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:
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.
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.
> 7C00 JSR $7D00 ;JSR CHKLEVEL
> 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
> 7F00 LDX $5DC9 ;LEVEL POINTER (USED IN MULTIPLES OF 7)
> 7F03 CPX #$00 ;LEVEL 1?
> 7F05 BNE $7F0B ;
> 7F08 JMP $SETCOLOUR1
> 7F0B CPX #$07 ;LEVEL 2?
> 7F0D BNE $7F10 ;
> 7F10 JMP $SETCOLOUR2
> 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
>7E15 LDA #$0D ;LIGHT GREEN
>7E17 STA $D023
Getting to know the Front End
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.
PICK A COLOUR
Source: Tau Zero by Alf Yngve and Evil Wizard 2 by Pingo (TND Contributors)
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.
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
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:
Adding some Music
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:
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.
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
If using PC
- High Voltage SID Collection (www.hvsc.c64.org)
- SIDPLAY (CSDB ID: 103781)
- Goat Tracker or Cheesecutter (www.covertbitops.c64.org or http://theyamo.kapsi.fi/ccutter/)
- 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
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:
Go to FILE / PROPERTIES
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
FILE / SAVE as
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
IF USING SIDRELOC METHOD - SKIP THIS PART ... Otherwisee
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.
TITLE MUSIC WITH SFX ONLY
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:
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
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
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:
>41BC JMP $6580 ;JMP NEWPLAYER
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
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
> 41A4 JMP $6586 ;JMP INITSID
Now for the main INIT SID code:
>6586 LDX #$00
>6588 LDA #$00 ;ZERO ALL SID REGISTERS
>658A STA $D400,x
>658E CPX #$0F
>6590 BNE $6588
>6592 JMP $4260 ;JMP GAMESTART
Now type in
... and you'll get a result of the title music playing in the background.
What about in game music?
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
>6594 JSR $A000 ;INIT INGAME MUSIC
>6597 JMP $4260
Now change the SFX player at $4503 to play in game music instead ...
>4503 JSR $A003 ;PLAY INGAME MUSIC
Adding High Score Detection
First of all, you will need to DOWNLOAD TANK BLASTA GAME + ENHANCEMENT SOURCE CODE.
The directory consists of the following files:
FB - Filebrowser/Disk menu
BLASTA /TND - Fully enhanced version of the game (Made as a
bonus treat to accompany this feature). More about it later on :)
- 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
- 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.
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 :)
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.:
the RESET button on your Turbo / Action / Retro Replay freezer
cartirgde. Then press F7 to enter the fastload option. Then enter the
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:
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).
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.
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
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
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.
;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
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
;fix SEUCK collect bug
lda #$4c ;force jump
;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
;clear all scores + hiscore
clearsc lda #$00
jmp $4245 ;run óåõãë front end
;seuck score bugfix (colletable)
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
;code to display the score (text)
disploop lda scoretext,x
eor #$80 ;convert to title chrs
cpx #$78 ;3 lines read
jmp $4138 ;òaster rolling code
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
bpl chkp2sc ;no hi for 1up
;1up score is the new hi score
newhi1up lda p1score,x
cpx #6 ;6 bytes max/digits
;like with player 1's score,
;check it with the current
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
;2up's score overwrites the
;current high score
newhi2up lda p2score,x
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
convloop lda p1score,x
cpx #$06 ;ócore length
;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
not1 cmp #$02 ;score digit = 2?
bne not2 ;no. check next
not2 cmp #$03 ;score digit = 3?
bne not3 ;no. check next
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
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:
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.
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:
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
Exomizer users type in:
exomizer sfx $6700 tankblasta.prg -o tankblasta.prg -n
AN EXTRA TREAT FOR YOU
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!
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
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
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:
INITSID ldx #$00
KILLSND lda #$00
SFX Player (For where enhancements can be linked): - CAN BE USED FOR LINKING SUBROUTINES
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.
... add a subroutine to FLASH the side border, then play the Sound
Effects again. Always RTS each subroutine when it has finished.
ENHANCEMENTS INC $D020
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
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
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
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
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:
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
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
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
Spare / Wasted Memory ...
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:
for programming the in game enhancements (which are linked as
subroutines to the most of the above memory locations)
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)
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:
this where there's free memory if using a M/C monitor, for example
$8000 for LifeLostPlayer1 and $8100 for LifeLostPlayer2).
;BAM. Player cops it.
;Read ACTUAL X position of player 1
;Place it into SEUCK's default XPOS for
;Read ACTUAL X MSB position of player 1
sta $40a4 ;Place
it into SEUCK's default MSB for player 1
;Read ACTUAL Y position of player
$40a5 ;Place it into
SEUCK's default Y pos for player 1
;Return from subroutine
;Bam! Player 2 cops it!
actual X position of player 2
;Place it into SEUCK's default XPOS
lda $bc32,x ;Read ACTUAL X MSB position of
$40b7 ;Store it into
SEUCK's default MSB for player 2
$bc33,x ;Read ACTUAL Y position of
;Store it into SEUCK's default Y
pos for player 2
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
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 $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)
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
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:
LDA $BC00,Y ; OBJECT NO
LDA $09 ; PLAYER either $00, $01
LDA $BC06,Y ; SCORE TO ADD IN JUMPS OF 10
LDA $BD06,Y ; YOU MUST END THE ROUTINE WITH THIS
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:
KillObject LDA $BC00,Y ; OBJECT NO STA ObjectType
LDA $09 ;
PLAYER either $00, $01 STA RewardPlayer
LDA $BC06,Y ; SCORE TO ADD IN JUMPS OF 10 STA ScoreType
LDA $BD06,Y ; YOU MUST END THE ROUTINE WITH THIS RTS
The code can be expanded underneath STA ScoreType to use something like THIS:
cmp #(ObjectNumber) ;Check if object by looking at
the SEUCK object editor
beq BossDestroyed ;Boss type hit?
sta ExplodeTimer ;Set explosion timer (see next
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.
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:
WITHOUT FRAME TABLE:
lda #124 ;Sprite number for single
framed object (for player)
lda #82 ;Bullet number for single framed object (for bullet)
WITH SPRITE FRAME TABLE (18 BYTES):
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
from table by referring to the 18 sprite values in SEUCK.
PlayerTable1 !byte 000,000,000,000,000,000
Adding an Invincibility Cloak to the player and fairer player spawning
By Richard Bayliss
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
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.
LDA #$FF ;(COLLISION WITH CHAR 255)
STA $40AC ;Player 1 to background
LDA #$FF ;(COLLISION WITH CHAR 255)
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 19986,234 ;FOR PLAYER 2
OR ALTERNATIVELY IN A M/C MONITOR create an installation source, which does as follows say we put it at $8d00
in the M/C monitor, type G $8D00 and play the game. You'll notice that
both players have invincibility against enemy sprites.
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?
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):
$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
;run main game.
initshield lda #255 ;Starting counter for
sta shieldpointer ;shieldpointer
;Target collision char as 255 for
sta $40ac ;Player to
;Make player invincible to enemy attack
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
;has the shield pointer reached 0?
bne shieldok ;Shield is still active and has not reached 0
lda #(collision char) ;Restore background collision char
lda #(default player colour)
shieldok dec shieldpointer ;Decrement shield value by 1
ldx flashpointer ;Call flash pointer to flash player
lda shieldtbl,x ;colour table
cpx #shieldtblend-shieldtbl ;Length of table
resetflash ldx #$00
shieldpointer .byte 0
flashpointer .byte 0
shieldtbl .byte $09,$02,$08,$0a,$07
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
'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
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
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
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...
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
;Check if explode_timer = 0
;Else keep it switched on
LDA #$00 ;Switch off the explosion 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 #$BD ;Restore SEUCK scoring pointers
STA $5568 ;back to normal, until yet another
LDA #$F7 ;boss / smart bomb effect has been
STA $5569 ;featured.
DEC explode_timer ;Decrease the explosion timer
LDA #<Explode_Main_address ;Low byte
LDA #>Explode_Main_address ;Hi byte
explode_timer !byte $00 ;Pointer to time explosion effect
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:)
sta $d021 ;Background Colour
sta $d022 ;Background
sta $d023 ;Background
cpx #$0b (Hex Amount of colours
to read = 12)
ldx #$0a (Hex
Last but one position for pointer = 11)
;Colour table ... Make sure the Last byte matches the colour of your background
ExplodeFlashPointer !byte 0
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
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
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
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:
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:
The result is:
Now what about the code, regarding scrolling chosen background character?
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:
... rest of code
scroll_char_up ;can be modified to a different subroutine
Scrolling the char upwards
By Richard Bayliss
Example: Night of the Valkyrie by Eleanor Burns
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.
;Get first byte of selected char
(Char number 252)
;store it to a temporary byte (any free byte that is available in
memory i.e. $6900)
;Starting loop to move
$ffe1,x ;Fetch next byte of same char
sta $ffe0,x ;Store to current byte of char
;Move on to the next char byte
;Until reached the 8th char byte
bne chrloop1 ;loop
;Fetch the stored byte of selected char
sta $ffe7 ;Store it as the last byte
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:
;Speed of delay limit..... Can be changed if you need to
beq docharscroll ;If limit reached, move to
scrdelay ;Increment delay value
;Return To Subroutine
docharscroll lda #$00 ;Reset scroll delay
... NOW COPY THE ABOVE CODE char_scroll_up
Scrolling the char downwards
By Richard Bayliss
Example: Trash Course by Inferior
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.
Scrolling the Char to the left / right
by Richard Bayliss
Example: Dodo's Deep Doodoo by Carl Mason
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..
two lines to increase
;char scroll speed.before adding 'inx' - rol = rotate to left
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
the two lines to increase
ror $ffe0,x ;char roll speed.- ror = rotate to right
Push/Scroll Parallax Technique
by Eleanor Burns, Richard Bayliss and Jon Wells
Example which uses this trick: Laser Hawk by Shaun Coleman
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.
scroll_char_up, but before rts add ...
Full Level Control
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
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.Examples:
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.Making Platform Games with SEUCK
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).
by Eleanor Burns
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.
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)
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
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).Linked Players and Score + Lives Sharing
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 ...
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
;Remove player 2's status panel, and centre player 1's panel
lda CentreScorePlot,x ;Read new position table for score panel
sta $5eaf,x ;Store sprite X/Y position for score panel
... do rest of code ...
;... at the end of your code, add Actual table for CentreScorePlot
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.
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
jsr CalculateScore ;Call subroutine to add p1+p2 score
jmp $4245 ;Run back to the title screen
Now for the main score calculation.
clear01 sta borrow,x ;Clear score digits
ldx #$05 ;We are reading 6 digits
calc01 lda $5ea3,x ;Read player 1's score
adc $5ea9,x ;Read player 2's score
calc02 lda result,x
sta store,x ;Print result on panel
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)
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.
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
mud, and slightly in the water.
The SEUCK VAULT andTutorial Videos
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
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
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
DOWNLOAD SEUCK FRAMEWORK
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).
2. Load in the framework (FILE/OPEN/SOLUTION OR PROJECT/SEUCK_WITH_MUSIC.s64
The source code should then display.
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:
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,
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.
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,
Dark Force - Disected
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).
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'.
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
This way for Dark Force - Dissected
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
KICKASS SEUCK FRAMEWORK
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
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