By Andrew Braybrook
Monday 13th April
Itís about time I had a proper pause mode in the game, so that I can return to the title screen, or quit to the
monitor properly. All I have to do is round up the routines that ought to be left running in pause mode (colour
updates for instance), and ensure that no routines involving object
update are called. As mentioned last month the sprite display system (or multi-plexor) expects new sprite positions
to have been calculated every cycle to ensure smooth movement, During pause mode everything should stay still (partly
so that magazines can take screen shots), so the easiest way to achieve this is not to call the movement routines.
Trouble is, the sprite system then receives no information regarding sprite positions and shuts down, so they all
disappear - not good.
Tuesday 14th April
The interrupt-driven sprite system was slightly amended to tell it to use the previous sprite positions if no new
ones arrive. I can therefore now pause the game or carry out mega-long calculations in the knowledge that all the
sprites will remain on screen. They may not move a lot, but itís better than disappearing completely. Thus the
pause mode is now implemented. Work has also continued on the control mode to allow the ship to be steered whilst
operating its engines. The three parallax star-fields all move at different speeds and can be made to spin quite
merrily. The shipís speed will vary depending on configuration and engine mounted, but I donít want any sluggish
combinations. I hate games where the control mode prevents you from doing the job in hand.
I also enhanced the object handler to ignore non-existent objects rather than process them anyway. I used to have
to hide them off-screen! I have created my first three classes of object:
1. dead objects.
2. fixed on-screen objects.
3. docking bay sprites that move away from the ship.
This completes the un-docking sequence so the main port slides off the screen as you leave it - itís better than
having it following you around. One design change now has the ship positioned on screen left to give a larger area
in front of the tractor beam unit at the shipís right.
Thursday 16th April
Put in some of the text for the title screen and high score table. With the giant-sized text and only two lines
of characters available I shall only be able to print one line of the Hall of Fame at a time. This does have the
advantage that I donít have to fit the whole table on one screen. 1 will allow for ten entries for now, eight digits
per score and three letters of initials. Thereís not room on one line for a full name.
In preparation for the title screen I had to define some more characters: the joysticks and player symbols and
a double width space. I also put in the colour and monochrome symbols, but I just remembered that I wonít be needing
them because there wonít be a colour option this time - it isnít necessary. Carefully planned painting and decorating
will make the game work on either
type of TV.
I also put in the tractor beam firing mechanism which spits out a sort of cloud, but I donít like the graphics
I may change the whole routine to run that if the graphics require it. Itís no good just putting up with a routine
because you sweated blood over it - if it doesnít work then it has to go.
Tuesday 21st April
Put in some more text for the title screen and a high-score decode table. I may need to put in a save to disk routine
and itís best to keep the amount to be saved as small as possible - we all know how long the breeze block takes.
As long as I can decode this data ready for screen printing fairly quickly I can put in ten entries quite happily,
maybe even 20. I like full zero-suppression on scores, it gives a more professional look - better than hundreds
of leading zeroes. After all, calculators stopped displaying leading zeroes soon after the Sinclair Cambridge,
and that was back in the 14th Century!
Iíve also put in the redocking sequence except that the docking bay sprites that scrolled off so nicely arrive
back on screen in a state of minor disarray. Well, all right - a complete shambles! This smells of an index to
the individual parts getting corrupted somehow.
Wednesday 22nd April
Yesterdayís corrupted docking bay was caused by what we technically refer to as Ďraster overruní. Put in laymanís
terms that means Ďtrying to do too much in too short a timeí. I always wondered what would happen if I ran out
of CPU time. This was caused by attempting to fade out the grids while running 21 sprites. I donít actually need
to do this as the sprites are held offscreen anyway, so I just set them up after the fade-in instead of before.
Tried putting in larger front-layer stars, but they looked too square. Changed the tractor beam to be more of a
Defender-type laser. This required a total rewrite of the firing routine but it looks much better. The process
involved required first working out the routine, testing it and finally tuning in - that is, slowing down some
animation to alternate game cycles so that it is more obvious what is happening. I considered making it a continuous
beam for repeated presses but it loses its effect. I rigged the control mode to fire the tractor beam from either
the unit itself or from the engines section, which removes the necessity to keep running across the ship all the
I also had to increase the time taken to initiate the dematerialisation, as it was triggering too easily by accident.
Thereís nothing worse than dematerialising to another part of the universe just as you are nipping out for a cuppa.
There are quite a number of functions allowed to the joystick while in the engine section, about the same as in
Paradroid (move, transfer and fire).
Thursday 23rd April
Did some sprites for the photon weaponry. I think Iíll use three different brightnesses or colours and a number
of different sizes and sound effects for them. This will enhance the difference between the weapons system. The
enemy will be using similar weaponry.
To implement the weapons I need to set them up on the ship, so Iíve been working out what sort of a system I need
to select new lumps for the ship. Iíll need an installation system, a Ďcommission parts to be builtí system, and
a Ďscrap existing partsí system.
Monday 27th April
Started putting in the self-fired weaponry. There are three stages of initialisation to co-ordinate. First, the
original ship layout set-up which decides what weapons are available, then the individual gun details have to be
accessed when the weapon is activated, and finally the actual firing of the weapon to initiate a bullet. This caused
some confusion as the chances of a game still working is inversely proportional to the number of instructions added.
So I decided to forego the first stage of weapon set-up, as this can be rigged to work using the monitor.
Had a long duel with the assembler again when it decided that I wasnít allowed to modify some code at a Procedure
Name. All subsequent labels were apparently not in the same places on the second pass. How does it know? And why
is it looking anyway? ST and I decided that the assembler is suffering from bad programming. I put in a second
label at the same place as the first and now itís happy. I reckon that will probably earn the assembler the Mickey
Mouse award for April.
Tried out the weapons system. Bit of space station drifted out of the guns in a fairly random direction. Two different
guns produced different effects . . . all wrong, but still . . . Decided that itís time to print off a few routines
for reference. Going grey waiting for printout.
Tuesday 28th April
Fixed the bugs in the bullet routine, Itís much easier when thereís a listing in front of you. The sequential firing
gun is a bit of a disappointment - it works so well on the title screen, releasing particles one or two cycles
apart in a circular motion. . . but the simultaneous firing makes up for it. Four or eight bullets released in
a ring for mucho devastation.
By dinner-time the fundamental flaw had reared its ugly head. The control mode is basically unwieldy and generally
all-round difficult to use. A quick pint down at The Chequers soon sorted this out. The problem was that controlling
a weapon system means leaving the engine section (ĎOch Capíní). Thus youíre left as a sitting duck on the screen
just hitting fire for all youíre worth, with no means of movement, just relying on the meames walking into your
line of fire - not particularly exciting, I trust youíll agree.
The solution is to allow movement of the ship from any weapon system. This allows movement while not firing,and
temporarily locks out movement while giving the enemy a pasting. The latter ensures that you donít fire a joystick-directed
bullet and immediately hare after it. By locking out the movement I only mean that it wonít allow alterations to
the current direction, not that the ship will stop! This also frees up the functions on the engine unit, which
is now only used to dematerialise back to the docking bay. I can also remove the fire tractor beam from the engine
room routine which was attempting to cover up the inadequacies of the control mode.
The assembler definitely gets the April Mickey Mouse award for producing buckets of error messages on lines of
perfectly good code, just for missing out a simple directive on a preceding line which it could have assumed to
be present if it had any idea about user-friendliness. Even the COBOL compilers on the IBM mainframe could cope
with this one, and they just love producing error messages like: ĎFull stop missing, assumed presentí, followed
rapidly by: ĎSuperfluous full stop encountered, assumed not present!í
Remind me to write the next game in COBOL - itís wonderful!
Wednesday 29th April
I put in the system block display routine today. There can be up to eight system blocks on the shipís hull which
carry out various functions and enhance the ships capabilities. Thereís a twirly energy display and a current charge
indicator. This routine also handles system block explosion animation, and runs at one frame every four cycles.
So, by doing the animation on cycles based on the block number, it wonít have to run more than two explosions at
once, It doesnít seem to eat much CPU time anyway. If I ran it on interrupts it wouldnít take any time at all because
as every programmer knows, the way to save CPU time is to run everything on interrupt. This takes no time at all
because interrupts are free. As soon as an IRQ is detected the CPU immediately switches to 20 GigaHertz mode. Only
kidding . . . I'm just bored of people telling me that they Ďrun the scrolling on interruptsí, or Ďpoll the joystick
on interruptsí - it means nothing but it sounds impressive.
Back to the system blocks . . . they can have different colours, which requires colour RAM update,so the addresses
of these have to be noted by a previously executed routine which setup the shipís data. Colour RAM and screen RAM
locations are mathematically related, and the assembler is awfully good at subtraction so this is no problem.
I had to optimise the grid fade-out routine to make it run faster, the docking sequence was running out of time,
as indicated by my coloured order stripes. By optimise I mean fiddle it to execute quicker, which usually involves
doubling the amount of code or using self-modifying code or both! I wish to admit here and now that selfmodifying
code is disgusting and very difficult to debug, but a good assembler makes mistakes less likely. Thereís nothing
like a good assembler, and my assembler is nothing like a good assembler!
Rounded off the day by amending the sprite editor. It has a really . . . whatís the word . . unusualí selection
of default colours - white purple and cyan. It also uses the border to indicate which colour youíre painting with.
This is rather silly, as a bright border completely alters the onscreen colours. These problems were fairly easy
to solve as they all use the VIC video registers, so I just had to look for where it set the border colour and
tell it to use black. The editor also has an annoying habit of printing in black, regardless of background colour.
On a black background this is no use to man or beast - hack!
Friday 1st May
Started putting in the weapon and system selection routine which includes total ship replacement, commissioning,
installing and scrapping of weapons and systems. I will need a means of regulating real time so that units canít
be commissioned quickly by cheating. The selection mechanism must cross-check various lists of parts available,
with parts being built and spaces on the ship to fit all these goodies.
I got out the Paradroid listing to see how the console logging-on routines worked. Morpheus will be allowing updating
of data, so it must be done carefully. Maybe it should just produce update records for the overnight batch to run?
Iíll confine all input to joystick only, and without an on-screen pointer. Although I am more sympathetic to mice
and icons these days, thereís a time and place for everything. I wouldnít use them just because theyíre fashionable
- they must be functional.
Iíve got it displaying the right headings so far, and for most of the categories it studies the appropriate data
and reports whether there are systems or weapons available or present. Itís taken me a long time to figure out
how to clear the sprites from the previous screen. After all the trouble with them disappearing when there wasnít
time to update them, now I canít get rid of them! Even brute force and ignorance didnít work the first time. Got
rid of them in the end though - Iíll not be outwitted by a couple of sprites.
Tuesday 5th May
Chief test pilot and critic Robert Orchard had his first look, the atmosphere was not entirely unlike a Del Monte
advert. De Man from Del Monte, he say: Ďcontrol mode eez not working wery well.í
We also decided that the ship is too wide. Suggestions of allowing it to flip onto its side to fit through narrow
gaps were severely dealt with. The weapons are too near the edge to see the full effect, and meanies approaching
from the top do not give enough warning.
So today is shrink the ship day. I removed the connecting tunnel to the weapon stations and cut down their width.
The only reason they were so big to start with was to allow me to separate the harsh white highlight along the
top edge from the - coloured weapon ports. In the event I made the weapons ports white as well so I can combine
the two in the same graphics space. A full-width ship is now reduced to 13 characters high from 19. It looks a
little more streamlined now. One of the effects was that the ship passed over the grid, which it doesnít do in
its present form, as it doesnít reach. I moved the grids in slightly to restore that effect. This made the docking
port sprites look overly large so I cut them down too. I had wanted to reduce the number of sprites onscreen anyway.
The game has to run on an NTSC C64 as used in the good ole US of A. Their C64s run about 16% slower on raster-synchronised
games because their TV sets have to spit out 60 frames per second as opposed to our 50. Offset by this is the fact
that their C64s actually run slightly faster (not a lot of people know that). Thus everything I run in the game
for the European version has to have 16% spare time at least. I can use that time for increasing sundry items like
the number of background stars, anything that can be altered once the game has loaded in and had a chance to sniff
around and adjust to its surroundings.
Iíve also been tuning up the control mode. Itís now a maze of delays and decisions, all in an attempt to make it
transparent to the player. I rigged the weapons to remember the last-fired direction to reduce joystick-bashing.
It also helps to differentiate between the functions of firing or leaving the weapon. I sometimes wonder whether
I should keep a badly tuned version around to emphasise the fact that the game has actually been tuned up properly.
I managed to wreck the starfield completely in an attempt to improve its randomness - all the stars went and hid
off-screen! Further adjustments put all to rights, so now the stars are tied to the screen with no extra off-screen
areas - Any star leaving on the left will arrive on the right, but at a different height. Similarly, stars are
re-shuffled vertically. The only purpose of the starfield is to give an indication of speed and direction, which
it does admirably. Having done this I can reduce the number of on-screen stars from 30 to 18 and it still looks
like the original number.
ST and I have devised the ultimate cheat mode to incorporate. The most comprehensive POKE of all time. Just hit
any key on the keyboard, the score will set to all nine and it will print ĎGAME OVERí. Just what is the point of
an infinite lives POKE? The game is supposed to be challenging entertainment, not a boring wander through the graphics.
If you want graphics, go and watch a film. Itís not winning that counts, itís how you play the game.
Wednesday 6th May
Adjusted the starfield again to produce more distant particles and less close ones. This should enhance the effect
of depth. I couldnít really spot the difference, but at least I feel better knowing that itís doing it properly.
Iíve put in the hull selection system but left out the bit where I have to pay for it. This makes the testing easier.
The actual gameplay mechanism just gets in the way of program debugging.
Thursday 7th May
Put in some more code for upgrading the ship, namely selection, installation and scrapping of on-board systems.
This appears to be working after a fashion. It did hiccup a couple of times and actually crashed the machine, something
that rarely happens these days.
Eventually disaster struck. I filled up the 384K RAM disk on the Opus with assembler files, so the marvellous assembler
just quietly gives up. It doesnít actually report an error that it couldnít finish writing a file, it waits until
the next stage falls over when it unexpectedly reaches the end of the file. A massive re-organisation followed
to split the main code into two smaller lumps. This involved isolating the code that is unlikely to change from
the stuff that Iím still working on. Of course, saying that a piece of code is finished is a guarantee that itíll
need changing tomorrow at the latest, but itís time to be brave. This makes the assembly time shorter as well -
it was getting boring, taking over two minutes.
Having a lot of trouble linking the two modules together. All my routines have gone undefined, even though I can
see them in front of me. Come seven in the evening, ST and I suss out what it is in order to not have to key in
all the routine names to make them known to other modules you can just put ĎALLPUBLICí which says that all the
names encountered will be made available. However, this marvellous option doesnít pick up procedure names, which
is what most of my routines are. Apparently sometimes procedure names are labels, and sometimes theyíre not. You
can JUMP forwards to them but you canít forward reference writes to them. You can make them PUBLIC by naming them
one by one, but not by declaring them public all at once. This makes the Avocet AVMAC65 assembler a dead-cert for
the May Mickey Mouse Award, the first to hold it for two months in a row. I canít see anything beating this!
Friday 8th May
This scrap weapon facility is causing an embarassment. itís elevated itself to a Ďscrap
whole programí facility! Iím not entirely sure why this is, Iíll need to look at a listing.
Meantime the select system facility requires that I display an individual system. I can only display eight at once
and some configurations require that I display nine on screen, so Iíll have to convert the character data into
sprite data. The way Iíve organised it requires colour changes by adding one to each bit pair in the byte with
no overflow, for the multi-colour data. Rather than painstakingly separate each bit pair in turn, I worked out
the logical operations to achieve this in one go.
Andrew Hewson came along to discuss business and declared Morpheus to be ĎEccentricí. Iíve no idea whether thatís
good or bad!
Monday 11th May
Discovery of the day: my new programmerís calculator has a delete key on it, so no longer do you have to re-key
the whole ten-digit number if you make a mistake - brilliant. How come itís taken this long?
Mr Penn himself rolled up yesterday with Mr Liddon but I didnít have Morpheus at home so they didnít see it. It
can be very dangerous showing the press very early versions, even if he was on holiday. The freshness of a game
wears off, I never did get my Gold Medal for Uridiwn! Nevertheless Mr Penn suggested a recoiling gun at the front,
while Mr Liddon suggested finding some food! Iím all in favour of recoiling guns, so 20 minutes of updating the
code and the recoil mechanism is in and working. Itís quite a small gun anyway but it comes under the Ďnice touchí
Found the bugs in the install and scrap sections. I was tying myself in knots trying to ensure that the right messages
appear on screen, supressing later ones in favour of important early ones. This resulted in sometimes not resetting
internal pointers, so having installed the last weapon it still thought there was another one left, so it picked
up rogue data and fell base over apex.
Tuesday 12th May
Finally completed the set of ship enhancement features. The game now allows all functions to be used without having
to fiddle anything. I havenít yet put any restrictions on commissioning new ship parts. If I put in the bit where
you have to pay for them, Iíll need some money, which is derived from points scored - but thereís no way of scoring
points at the moment!
I keep running out of RAM disk space again on the Opus, itís just not big enough for a growing program, and certainly
not enough for a grossly inefficient assembler.
I had to move the text bars further apart to allow more of the weapons stations to be visible.
In order to control the time taken for units to be built, the game notes how long youíve been flying the ship.
Pausing will stop the clock, so itís no good leaving it paused overnight to get the extra weapons built! Iím just
wondering what units of time I should use - days I suppose. Iíd rather use something more mystical, like the Dalekís
ĎRelsí - they use them to measure everything: time, distance, energy, mass, the lot. It must make Dalek Physics
lessons much shorter.
Iíd just like to add my two penníorth to the Ďwhich 16-bit machine should I buy to play games on?í argument. Letís
get some facts sorted out.
1. There are as many arcade games out for the Amiga as for the ST, mainly due to the higher numbers of Amigas in
the US. At the moment you just have to search harder to find the Amiga software.
2. The Amiga hardware was designed primarily by the designer of the Atari 8-bit hardware (Jay Miner, a very clever
guy), and is aimed at doing all the things that games need to do, smooth scrolling, manipulating large graphic
images quickly and producing high quality sounds.
3. The Atari ST contains just enough hardware to make it graphically superior to most 8-bits. It has a large colour
palette, but cannot smooth scroll using hardware. The only smooth scrolling possible will thus be limited in colour,
vertical only, on a small area or very s-l-o-w. Sonically it has a very old chip indeed, as used in the Amstrad
CPCs and Spectrum 128s, not as powerful even as old SID.
4. Despite what Commodore still maintain, the Amiga chips were designed with games in mind and will be used as
such. How much business software uses four voice stereo sound? Or smooth scrolling?
There will be some great games appearing on both machines, some already have, but anything the ST can do, the Amiga
can do equally well, usually better. The reverse will never be true, provided programming standards are similar.
In conclusion I would say that the Amiga to the ST is like the C64 to the Spectrum.
Wednesday 13th May
Added one or two new graphics to the set of onship systems which look quite nice. Itís difficult to come up witha
whole set of graphics which all look different but have to blend in with the same surroundings, but Iím sure you
donít want to know about that I Iíve started to organise the Ďecosystemí within the game for the meanies. Each
level will be played over two alternating phases with the ship able to commute between the two via the docking
bay. I want to create different atomic-style structures of a central charged impenetrable nucleus surrounded by
charged particles that have to be recharged by a chargecarrier that shuttles between them and the nucleus (phew).
Each particle decays with time and must be revisited periodically. The main ship gun, nicknamed the toothpaste
tube, can suck out and store this charge. This may cause other things to occur, and you may not be the only one
trying to steal the charge!
Richard Groome paid us a visit and he may be able to help us with a little surprise on the music front, weíll have
to do some feasibility studies, but weíre hopeful. Canít say any more about that yet, very hush-hush, top secret
and all that.
To Be Continued...