Site index page
Simon N Goodwin's commercial softography, updated September 2010
This is an incomplete list of commercial products I've played a
substantial part in programming since the late 1970s. Recent work is
summarised on the Codies page.
The many games I wrote for publication in magazines in the early 1980s are
not listed here, as the software was not retailed separately. I've made another page with details of some of those games -
such as Whitehall and Space Intruders (Practical Computing), Gladiators and
Holocaust (Computing Today),Shop Steward (Personal Software and CT), Sniper
(Personal Computing Today) Runaway Robot (Games Computing) and the Spectramon
utility, including some background on how they came to be written and the
early days of home computing and the UK games industry. One day I
might start to collate information about some of the hundreds of
features, reviews, hardware articles and software utilities I've contributed
to dozens of hobbyist magazines over two decades. But don't hold your
breath...
Quick index
Eight-bit beginnings
Sinclair QL developments
HiSoft compilers
Silicon Studio Ltd.
Amiga Inc.
Attention to Detail
Codemasters Central Tech
Dance Factory
Brian Lara Cricket
Colin McRae DiRT
RaceDriver GRID
Colin McRae DiRT2
Formula One 2010
Everyone has to start somewhere. In 1979 I wrote a handful of simple games in
Apple Integer BASIC on one of the first Apple ][ computers to reach the UK.
It arrived at my school with a generous 24K of memory and the original red
manual, with handwritten pages, shortly after the maths teacher who had been
lobbying for its purchase gave up and went to work for King's School in
Worcester, which already had a computer of sorts - an elderly mainframe
retired from the manufacturer Metal Box.
![The original Apple ][ (6K)](pix/Apple][.jpg)
This left Wycliffe College with a micro that no one on the staff showed much
interest in, busy as they were making unwilling pupils clean rifles without
pointing them at one another and run round and round the playing fields in
the drizzle for showing insufficient enthusiasm for the school's main focus,
Rugby Football. Somehow I ended up with the book used to log use of the
foundling computer, priority access to the machine, and enough enthusiasm -
having previously attempted to cajole a shop's PET 2001 to work out square
roots the hard way, by Newton Raphson, not knowing about the SQR function -
to teach myself BASIC, 6502 assembler, and the mysteries of GR and HGR
graphics and one-bit sound.
Several of these games were published in early hobby magazines like Computing
Today and Practical Computing, and one of them found its way onto the shelves
of Oxford Street pioneer software retailers called - appropriately generically
- The Softwarehouse, in the days when you could register a company with such
a name and not be told that the term was too general.
Following up a magazine ad seeking new programs and programmers, I gave The
Softwarehouse a 5.25" minifloppy disk with a handful of titles, including a
balloon flight simulator and a Breakout derivative with the innovations of
ball steering and quick return. Returning to London a few months later in
search of magazine payments, after spending my last nine quid on a return to
Euston, I bounded up the stairs to The Softwarehouse's shop and en suite
offices, to see how the world was reacting to my work, only to be told that
my games had been shown to a few potential distributors overseas but they'd
not taken the bait.
This was the first of many encounters with publishers reluctant to pay up,
and on the way in I'd been thrilled to see my game bagged up for sale with
others on display in the shop, so I scooted out of the office, grabbed one
and returned to demand my pound of flesh (I was not a vegetarian on those
days). The game was up, a royalty cheque was forthcoming, and I was on my way
to software stardom (sort of) forewarned of the ways of the industry. The
cheques have got bigger but the ways haven't changed much since.
I still have a copy of the disk, in the eccentric software RLL Apple DOS 3.2
format, but no way to read it, so I can't include a screen-grab or check if
the game was eventually published under the name WALLBALL or the alternative
title DROPOUT. Digging through my old mags I found an advert in the April 1981
issue of Personal Computer World which lists the game at £10 on Apple disc) as
'Wallbanger'. In any case it was written in Steve Wozniak's 6K integer BASIC
(itself written with the one-line mini-assembler in the same ROM). That Apple
][ had some interesting quirks, including a tendency to spontaneously convert
letter Y's in programs in to letter I's (a consequence of the use of the
early 4K 4007 DRAM chips which led to the inclusion of redundant parity bits
in IBM PCs for decades thereafter) so I got into the habit of using X and I
co-ordinates, rather than the X and Y I originally entered. Besides the 130K
floppy drive the Apple was connected to a noisy 10 character per second
ASR-33 teletype and tape punch, so I have several of those early programs on
paper tape as well as disk. Not that they're any more machine readable in
that format, but at least - with a bit of practie - you can read paper tape
by eye - a skill which still eludes me, 25 years on, when it comes to
magnetic disks. ;-)
GOLD MINE, 16K Spectrum, dk'tronics 1983
A few years later I'd
moved from the 6502 processor to the Z80, via my own first computer, a 1.77
MHz Video Genie (TRS-80 clone) and then to the ZX Spectrum which turned up
after a long wait late in 1982 and prompted me to sell the BBC Model B I'd
obtained, for a lot more money and similarly late, six weeks before. The
Spectrum had fewer pixels, half the ROM and less bus bandwidth, but it was a
vastly better machine and after a three-day stint learning the keyboard
layout I started work on what was to become my first chart success, a 48K
Spectrum game, written in a mixture of ZX BASIC and Z80 code assembled from
REMs in the source. This was Gold Mine, published at the height of the first
micro boom the following year.
More about Gold Mine, my game for
dk'tronics
Magic Micro Mission, Atari and Commodore 64, Quicksilva 1984
I worked on
a TV series about home computing, between July and December 1983. The six
programme series, entitled the 'Magic Micro Mission', was made by Central ITV
in Birmingham. It was broadcast at 5.15 on Wednesday evenings in November and
December, in six ITV regions: Central in the Midlands, Ulster, TVS, Border
Television, Tyne Tees and Television South West. We recorded the programmes
on Sunday afternoons, in the studio where 'Bullseye' was filmed during the
week.
The
left column shows some rather grainy grabs from the original Atari 800 title
sequence (via Crash magazine) and the inlay alongside is from the spin-off
game, brutally ported to the Commodore 64 and published by Quicksilva. The
artwork is by David Rowe, who also produced the cover for FirST BASIC (see
later).
My role of 'software designer' - a new title for TV - meant that I designed
and programmed the graphic titles, jingles and credits used in the series. I
worked with Central staff Graphic Designer Dave Beeson and Gus Chandler, a
programmer on the production team. Geoff Negus from Central News was Editor,
and Terry Johnston was Executive Producer.
The
series was thrown together in great haste to beat off a challenge from other
independent TV companies - from green light to recording the series was
prepared in about six weeks. The standard improved steadily and programme six
was 'Pick of the Day' in the Birmingham Post. It was hosted by the talented
Adrian Hedley (fresh from Jigsaw, another kid's TV series) and the pneumatic
Jo Wheeler, with a disembodied computer called 'Prune' for reasons not worth
elucidating, played by good-natured thesp (and comedy German in BBC TV's Allo
Allo series) Hilary Minister and 'Egghead' an escaped and bizarrely disguised
Warwick University academic. It featured full-screen game graphics - a
revolution for broadcast TV, in those days - and guests like funny man Willy
Rushton, musician Rick Wakeman, DJ and self publicist Dave Lee Travis,
cricketer David Gower (gamely reviewing early cricket software with a
one-pixel ball), comedy air traffic controller David Gunston, (testing early
flight-sims) plus a studio audience of schoolkids - typically sweating under
the studio lights in home-made robot costumes - and the Astronomer Royal.
It seems unexceptional today, when computer games are part of mainstream
culture, but the series was a breakthrough in 1983, as issue 4 of Crash
magazine reported in May 1984: "...to date television as such has been
remarkably uninterested in computer games. Central Television's Magic Micro
Mission was the first programme which actually examined the phenomenon."
Unfortunately it was not shown in London, which is why media historians often
claim UK game TV didn't start till years later.
I was closely involved in the production of the series, writing half of the
initial 3000 word proposal after my friend Graeme Kidd (who had been business
manager of the student newspaper I edited the year before) lent my issue 1 ZX
Spectrum to one of the bosses and got the TV company interested in the idea
of making programs featuring the new home computers. I contributed background
knowledge of the micro industry and script material, and appeared in the
final programme, discussing the graphics software used on the series,
nervously waving my hands around and illustrating the sound-effects orally.
Sorry, I don't have a tape of this! ;-)
The specification for the title sequence was that I should produce 'the best
graphics possible on a cheap home computer'. I chose to use an Atari 800
system (retailing at under 200 pounds) although I had had no previous
experience of the machine. The end credits were programmed using a 16K ZX
Spectrum, as that meant I could type the names of the team directly into the
BASIC as they changed from week to week.
The big text and scrolling was handled with code snarfed from Sinclair's
Horizons demo tape, accompanied by animations that played on the names and
roles of key members of the team. The whole lot was genlocked over live
footage with equipment costing 320 times more than the micro producing the
graphics; Spectrums and broadcast TV standards took quite a bit of
reconciliation!
The software which generated the TV title sequence - almost entirely in
real-time - featured some sophisticated techniques. An interrupt-driven
routine was called thousands of times a second, during the flyback period of
every displayed line (allowing a maximum execution time of about 25
microseconds on a processor running at less than 2MHz). This provided a high
resolution display of over 100 colours on the screen at once, even though the
computer could only allocate two bits to the colour of each pixel, presaging
the later Amiga 'hold and modify' mode.
Dave drew the graphics on acetate, then stuck that to the TV screen, traced
and coloured them in using commercial Atari 'Paintbox' software, saved out
the resultant four-colour version and tweaked the colour line by line using
custom software to select the palette registers and new colours progressively
down the screen, to make a data file which could be loaded at the same time
as the basic 160x192 pixel image and copied to the hardware on the fly by my
horizontal display list interrupt server.
Another interrupt-driven assembly language routine controlled the rudimentary
'sprite' facilities of the computer, allowing symbols to move over the
background without altering the bit-map. Up to eight sprites moved fifty
times a second, during TV vertical blanking.
The remaining CPU time ran a control program to move the sprites, detect
collisions, read and respond to the joystick, trigger four-channel sound
effects, and advance the player character through a sequence of screens.
Seven different sections were used to generate the title sequence, which was
different for each episode. Two of those were developed into the game, while
the others were used as rewards and to set the scene.
The initial section displayed a multicoloured version of the Central ITV logo
on a background of stars - a four-part musical rendition of the 'Central
tune' played while a spaceship flew onto the screen, around the 'ball' of the
logo, and vanished (in perspective) into the distance. The next bit used
palette line interrupts for a moving road effect, rather than extra colours,
as UFO sprites flew around the player in a first-person 3D chase sequence
(obviously influenced by the Planet of Zoom arcade game) heading for a micro
screen on the horizon. After some transition graphics the spaceship zoomed
through the screen and into the micro itself and a Pacman-style circuit board
with eight sprites representing chips and resistors wandering around a
maze.
The gameplay took second place to the graphics, which was a pity as the
Commodore 64 tape sacrificed almost all the colour (and even some of the
gameplay) of the Atari 800 version, which was finished but unpublished due to
the small number of punters with a 48K disk-based system capable of running
it. But as it's the only game I've ever had my name on the cover of, I'd love
to hear from anyone with a spare copy as I was never sent one by Quicksilva,
though I did get paid royalties (rather less than the £1200 I got from
Central for the TV work) so presumably a few thousand copies were sold...
ZIP, 48K Spectrum, Sportscene/GK Computing 1983
In 1983 I was a Computing Science student at Aston University
when I was approached by Roger Munford, former editor of Argus Press magazine
ZX Computing, to which I'd contributed Spectramon, an uncommonly large Z80
memory monitor and machine code disassembler. He was moving to Sportscene,
publishers of Personal Computer World (formerly Bunch Books, latterly Dennis
Publishing, the empire of former Oz magazine defendant Felix Dennis :-)
Roger was looking for a series of articles which could illustrate structured
programming in a new magazine, Your Spectrum, which he was about to launch. I
opined that any such series should develop a real, useful and complex program
- not just an exercise - and suggested that a compiler for a substantial
subset of the ZX BASIC language would be a suitable topic.
The result was the ZIP compiler, an elaborate and uncommonly well-documented
integer BASIC compiler which read ZX BASIC tokens directly from memory and
stored the results beyond the reach of BASIC, after a small runtime library.
ZIP and its demo game Star Base featured in four articles in issues 2 to 5 of
Your Spectrum, and later thousands of copies were sold on cassette with
manuals - initially printed on an ancient and smelly Gestetner duplicator
with tapes recorded in parallel on a row of cheap cassette decks screwed to a
plank, later professionally duplicated and printed.
Version 1.2 of ZIP was printed in the magazine, along with coupons inviting
readers to send in three pounds 50 for version 1.4 on tape with the full
manual. Graeme Kidd, later editor of Crash magazine (among others) and mayor
of Ludlow, handled the distribution from his Harborne squat, encouraged by a
cockup that scrambled the text in the second part of the magazine series and
obstructed by a postal strike in London that winter.
ZIP resurfaced a few years later in a version for 128K as well as 48K
Spectrum computers, first on the Tech Tape published by Newsfield Ltd to
accompany the Crash magazine Tech Niche 16 page special, and later in a
mail-order offer managed by CGH Services.
Version 2 of ZIP, distributed on the Tech Tape and in the CHH offer, was
itself compiled, making the compilation process a lot faster, and was
extended with multichannel sound and screen-reading code. Its final
commercial outine was a decade after its launch, when it was 'exclusively'
covermounted with the Christmas 1993 issue of Your Sinclair magazine.
I`m grateful to Jon Smith and Alan Cox for help in the development of various
versions of ZIP.
There were versions of ZIP for other computers. A port to the Timex 2068, the
US version of the Spectrum with a new ROM and improved sound and graphics,
was licenced to Knighted Computers in New York and sold retail and by mail
order to North American Sinclair enthusiasts. This was a challenging port as
I did it without ever seeing a TS-2068, and with only a list of ROM entry
points as my guide. After a few tries I produced a saleable version 1.5 and
royalties, generous even after the 50:50 split with my Texan agent Carl
Zielgler, rolled in for years after.
A version for the Memotech MTX, another Sinclair-spin-off micro, was not
finished before the manufacturers ran out of cash and recalled the
development hardware I did produce a working version for the MGT SAM, with a
few extensions, in the early 1990s but this never lived up the promise of the
hardware and was shelved till a decade later, when it resurfaced and was
published by the SAM/Spectrum Profi club of Cologne, Germany.
Unlike many of my other home computer programs, ZIP is still not freeware; I
have a dwindling pile of printed manuals and still sell them periodically.
Mail me if you'd like one!
Soon after I finished the first version of Zip I returned to Aston University
and needed to come up with a proposal for a final-year project. Having
learned by that time that the only thing you can be sure of delivering on
time is something you've finished already, but wanting to do something new
and cool if I got the chance, and delve into the Motorola 68008 processor in
Sinclair's new QL home computer, I proposed 'a compiler for Sinclair
BASIC' as my project.
With luck this could be a compiler for Sinclair SuperBASIC - the
vastly improved, Comal-based interpreter programmed by Jan Jones and built
into the QL's ROM, alongside Tony Tebby's Unix-influenced Qdos operating
system - but if I got stuck, or busy with something or someone else (maybe
even a girlfriend?) I reckoned I could fall back on ZIP and still earn the
degree.
Staff at Quicksilva obtained early Qdos documentation from Sinclair on my
behalf, and I got a QL from the second batch at the end of May 1984, then
another one which worked (the first lasted only 45 minutes) in June. I made
steady progress, first writing code on my 128K microdrive-based system to
read the tokenised program source from QL memory - then routines to parse the
result and generate corresponding code in the form of calls to intermediate
code and stack operations expressed in Reserve Polish Notation. This text
output was written to microdrive tape and later - once I got onto Metacomco's
Macro Assembler beta-test programme - converted into 68000 machine code by
expanding the text, via assembler macros.
This was enough to prove the symbols table and expression evaluation code,
and get benchmarks compiled and running as standalone multi-tasking
processes, but the generated code was far too verbose to give me any chance
of making the compiled compiler fit on the machine. Like Zip, this was a
four-pass compiler, working from tokenised source in the interpreter's
memory. The first pass collected information about the whole source, to
enable robust error checks later on. The second pass converted the source
into an intermediate code and reported all errors. Only if that worked - and
most programs submitted for compilation fail at this point - were two more
passes used to translate the intermediate code and fix up cross-references to
make a stand-alone code file. The use of compilation from memory made the
extra pre-pass fast, and the separate code-generation phase simplified the
design and allowed the machine code library to overlay the compiler, making
best use of limited RAM and the microdrives - good for large block loads but
slow for sequential filing.
The following spring a demo to my supervisor went well and that and the
report earned me a first class honours for the project. By the time I
graduated I was looking for a publisher, who could turn the compiler into a
product as Quicksilva were no longer interested in the QL and in the throes
of selling out to Argus Press.
Freddy Vachha was setting up Digital Precision as a specialist QL
publisher at the time, and set me up with a 720K CST 5.25" floppy disk
system, 256K extra RAM from Simplex Data, and an advance which I immediately
spent on the HiFi system I'd always wanted but never been able to afford -
Tannoy M20 speakers, a Mission Cyrus amplifier and one of the new-fangled CD
players that were expensive luxuries in 1984 - one of the early 14 bit
Marantz ones, and the only part of the setup I'm not using any more.
It took another year to develop the academic project into a commercial
product - QL Supercharge, £60 boxed with a 100 page manual (written in
Scripsit on my Video Genie, printed with a Juki 6100 daisywheel printer). The
compiler ran overnight for weeks, parsing itself in slow interpreted BASIC,
usually to fall over in the small hours with some unanticipated problem. The
aim was to get it to compile itself, and after weeks of trying it got all the
way to the end and emitted a complete intermediate file. A few weeks later
that assembled into an executable program. It took weeks more to get that to
compile itself, and further weeks to get the compiled compiler to match the
compiled compiled compiler! Compiler bootstrapping is not as simple, or as
easy, as academics often make it seem.
To meet the challenge to get from intermediate to executable code, Freddy
enlisted Ferranti CPU designer and Open University lecturer Gerry Jackson,
author of SuperForth, DP's first QL compiler, to write a custom
code-generator to take the place of the Metacomco assembler. In the process
the design was refined to optimise the speed and size of the generated code.
Memory was tight - it had to run on a 128K computer with only microdrives,
and fit the compiler, its source and intermediate code in RAM (buffered in
screen memory for want of anywhere else) so the third and fourth passes only
loaded, over the top of the parser, if the code was guaranteed correct. It
compiled to an intermediate language which the code-generator could optimise
and convert to either 16 bit threaded code (like Forth) or pure 68K code
selectable on a per-line basis, and then generated a dynamically-built
library to run the threading so the overhead of despatching between templates
(16 bit code pointers) was only two instructions:
move.w (a5)+,d0
jmp 0(a6,d0.w)
Most of the machine-code from the macros could be encoded into a single 16
bit word, followed by any parameters (fetched with move (a5)+ from the
threaded code stream) yet raw machine code could be inserted into the
instruction stream at any point the maximum speed was essential, prefixed
with jmp (a5) to switch out of threaded code, followed by reloading a5 and
restarting the threaded code above when space was more important than speed.
Once Supercharge had compiled itself the overnight runs were reduced to about
20 minutes at first, then trimmed to nine minutes for the compiler to
re-compile itself after optimisation of the code. The code itself shrank from
about 80K of tokens to just 46.5K of compiled code, including the template
library, threads and initialised data - leaving room for 30K of source and 9K
of compile-time data on the unexpanded QL - the other 40K being taken up by
the screen (32K, mostly used to buffer intermediate code during passes three
and four) and the Qdos multi-tasking operating system structures and device
linkage.
Supercharge review in
Sinclair User, March 1986 Supercharge was unveiled in an article in the
October 1985 issue of QL User magazine and went on to earn a 'Sinclair User
Classic' award and sold thousands of copies over the following couple of
years. Some of these sales were gained - and doubtless some lost - by the
revolutionary system of copy-protection built into the product - the infamous
Lenslok.
LensLok
Lenslok, from ASAP Developments, consisted of a plastic holder for a
transparent slatted lens which scrambled the image on screen over which it
was placed, making nonsense of a normal bit-mapped display but shuffling a
correctly pre-scrambled pattern into readable text. The user was required to
read two characters through the lens and type them in at the start of each
compiler run, to prove that they had a genuine copy of the compiler - or at
least a copy of the lens, which was much harder to copy than the unprotected
100K microdrive tape on which Supercharge was shipped.
Lenslok became infamous that year when the programmers who bolted it onto the
Spectrum version of 80s classic game Elite misread the instructions and
generated a pattern which could not be read reliably, with or without the
lens. The QL's floating point scaled graphics and high resolution meant that
the Supercharge patterns were readable and readily compatible with various
sizes of TV and monitor, though after a few days many users learned to
shuffle the rows by eye and live without the lens.
Lenslok was very successful in dissuading commercial pirates from selling
Supercharge, until some ingenious thieves in Belgium found a way to make the
compiler defeat its own copy protection. The rip-off copies of Supercharge
sold by Persoft in early 1986 came with a small program - itself compiled
with Supercharge and hence able to multi-task alongside the compiler itself -
which read the screen memory where the Lenslok pattern was displayed,
re-ordered the data and displayed it alongside 'in clear'.
This was defeated by randomising the position and initial scale of the
pattern in later versions of Supercharge. Eventually a version without the
Lenslok code was produced, for a bundled deal with US QL distributors A+
Computer Response, but by that time Turbo, the inevitable follow-up
product, was on its way....
TURBO, Sinclair QL/CST Thor XVI, 1986
The follow-up to Supercharge. An associated product, Turbo Toolkit, was sold
separately and on ROM to users of CST Thor computers. Both are now
open-source with updates and copious documentation on-line.
Turbo open
source home page
Article in QL Hacker's Journal
More to follow - lots to say!
SpeedScreen, Sinclair QL/CST Thor XVI, Creative CodeWorks 1987
SpeedScreen was a replacement display device driver for Sinclair QL
and CST Thor computers. It made common display operations much faster
and so benefited all users of those systems - even those normally happy
to use just the bundled software supplied with the machine. It taught
me that - after years writing compilers - it was easier to sell speed
by enhancing what people already had, than by giving them new ways to
make fresh and speedier applications themselves. ;-)
SpeedScreen was initially sold on microdrives and 5.25" and 3.5" floppy
discs, priced at £20 with a 16 page manual. Later it was released in ROM
chip form, making the code even quicker (as the ROM was faster than the
DMA-contended RAM in most systems) and leaving more room for applications
- and giving me the chance to sell the same thing a second time to
willing customers, at the same price or £30 for a bundle of both the
ROM and disc or tape versions (which included additional utilities).
SpeedScreen optimised display handling by replacing slow, general-purpose
code in the system ROMs with fast replacement routines. You didn't
need to alter your programs to use it - just load SpeedScreen before
loading€and using your application. The only difference (apart from a
small memory overhead - configurable between 4.5 and 17K) was the extra
speed.
SpeedScreen optimised scrolling, printing in the most common character
sizes, window clearing and cursor operations. The improvement in speed
compared with a standard QL depended on the operation: text output was
typically between four and twelve times faster than normal. SpeedScreen
optimised all OVER and UNDER settings, solid colours and 64 stipples.
By default, SpeedScreen scrolling was at about twice the normal speed,
but a new command let you set higher speeds - up to eight times normal
- for free-scrolling displays such as LIST and COPY, letting users
adjust the rate to control flicker and match their reading speed.
Further new commands allowed extra character-sizes, coloured fonts and
other features that came almost for free out of the code I'd rewritten.
The QL's original display handling code had been written in a great rush
and squashed into a very small amount of memory. So routines were chosen
for their generality, rather than their speed. Thus one routine prints
characters in all CSIZEs and for all values of INK, PAPER, OVER and
UNDER. A single tangled block of code was used to scroll and pan, to
print blocks and borders, to draw and erase cursors and to clear all or
part of any window, regardless of its position. SpeedScreen avoided
those slow routines and uses its own fast code instead.
SpeedScreen emulated Sinclair's OS accurately, despite its speed. Displays
looked just the same, but appeared much more quickly, though pausing and
interruption was supported as before. The code was device-independent and
re-entrant, so one copy of SpeedScreen boosted any€number of windows and
concurrently-running tasks. Apart from a slight tweak to the MODE command
(which changes display resolution) all system commands worked as before.
Features that were not optimised were handled exactly as€usual, at normal
speed, and could be mixed with optimised text or graphics without
restriction. So I only needed to rewrite the bits of the API I could
speed up usefully, and could revert to existing code for all the rest.
SpeedScreen sold thousands of copies by direct mail order and through
dealers in the six months I advertised it. All the duplication and order
fulfillment was handled by student friends of mine, paid generously for
a quick turn-around. Raw material costs were tiny. Soon after, my former
publisher brought out a clone product, heralded by full-page advertisements,
(using a brand name I'd thought up for another product he'd since canned!)
and I moved on. Exploiting good ideas depends upon timing, at the start
and the end, and you have to move fast! As long as you do that you need
not fear copyists, because you'll keep having new ideas and they'll
always be several steps behind.
When HiSoft were in need of a 68K compiler, with the rise of 16 bit home
computer systems in the late 1980s, they licenced Supercharge from me, as the
QL's 68008 processor was binary compatible with the 68000 in the Atari ST and
Commodore Amiga.
My original SuperBASIC parser was ported to the Atari ST by Andy Pennell,
author of MonQL and the 68K versions of Devpac (latterly a lead programmer in
Microsoft's Visual C compiler team). This involved adding support for TOS and
GEM libraries and code to tokenise the input source as - unlike the QL
version - it was not possible to read ready-checked and tokenised source from
the Atari's memory, as there was no BASIC interpreter bundled with the
system. Support for Microsoft QBASIC and MBASIC eccentricities (largely
inherited from DEC BASIC+) was also added, while the Qdos-specific features
like named loops remained in place as they were needed in order for the
compiler to compile itself.
HiSoft BASIC, Amiga, HiSoft 1988
HiSoft BASIC for the ST was subsequently ported to Amiga systems, again using
the parser derived from Supercharge with new tokenisation and codegen
routines and additional support for the custom Amiga hardware and
libraries.
Details to follow
FirST BASIC, Atari Mega-ST, HiSoft 1988
Needing a replacement for the barely usable 'Personal BASIC' (said to have
been cobbled together by a summer intern at Metacomco) bundled with early ST
systems, Atari licenced a cut-down version of HiSoft BASIC for the ST,
repackaged in a nice box with artwork by David Rowe (who produced much of the
classic Quicksilva artwork earlier in the decade). This version lacked the
facility to save stand-alone programs, and a few other features which were
available in the full version. It was bundled with Atari Mega ST systems.
Power BASIC, Amiga, HiSoft 1989
This was an update of the SuperCharge and HiSoft BASIC projects converted
to suit the Commodore AmigaOS. More details may follow.
DIY Toolkit, Sinclair QL/Thor XVI/Emulators, QLW/CGH 1988..1994
Details to follow
Silicon Studio Workstation, Amiga, Silicon Studio Ltd, 1993-2000
I was Technical Director of this company, makers of multitrack digital audio hardware and
software. The hardware was built around 32 bit Zorro III audio cards, each featuring four
128 times oversampled balanced line analogue inputs and four-channel 20 bit outputs
capable of 121 dB dynamic range - top specifications for the early 1990s. Of course
it doesn't take long for top specs to change, and the Amiga hardware failed to keep
up, ultimately leaving Silicon Studio high and dry. But it was fun while it lasted,
and I learned a lot.
Other specifications:
* Standard sampling Rates: 32000, 44100, 48000 and 51200 Hertz
* Typical Signal/Noise Ratio (A weighted) output: 113 dB
* Channel Separation @ 1 KHz : 101 dB minimum, 115 dB typical
* Dynamic Range : 121 dB maximum (20 bit digital data)
The Amiga contributed 32 bit Zorro III slots for one or two synchronised cards, fast async
SCSI hard drive and audio/data DAT tape interfacing, 14..146 Mb internal RAM, display,
MIDI, controller and other interfaces.
System software supported hard disk recording, multi-channel mixing and
parametric equalisation. Less commonplace features, even now, were support
for multiple pointers, flicker-free beam-synchronised displays and
constant-power integrated 'meterfaders' to AES/EBU specifications.
Following the demise of Commodore
and end of compatible Amiga hardware production, the brand was purchased by Silicon Graphics
Inc and our custom Amiga audio development efforts ceased. The associated domain, studio.co.uk,
remained mine until 2004, when it was sold to an eponymous Internet shopping company.
Amiga Desktop Environment, Linux/PC/Taos, Amiga Inc, 2000-2002
Amiga Inc. system software development and documentation.
When Amiga got bought out by former Gateway staff I was initially hired to
document the new Amiga Desktop Environment, a radical processor-agnostic
distributed processing platform built on Amiga and Tao Elate technology, and
edited the 300+ page printed manual for the new SDK on my A4000 computer and
delivered it camera-ready in PDF format within a few weeks. Before long I was
drafted into the tech team developing the replacement for Commodore's
AmigaOS, designing and programming heap memory management tools, taglist and
dataset routines for the Amiga Component Model - a sort of safe,
multi-processor COM, implemented in VP virtual assembler.
As we moved the new
Amiga systems to fresh hardware my Silicon Studio contacts and experience
came to the fore and I was appointed team leader of Amiga Audio development,
and led the implementation of a network streaming MP3 player application
which ran in the AmigaDE, initially hosted on Linux, Windows and Sharp Zaurus
and Iris PDAs.
This
involved managing a team of six people spread around the world. The pictures
alongside show the player's user interface, designed for small (QVGA) PDA
screens - the graphical skins were designed by Kevin Saunders; I coded the
back end with Thomas Wentzel; the GUI was programmed by Davy Wentzler and
Rudi Chiarito.
Much of the
work involved separating the tasks and formalising the communication between
the people and the software sub-systems, to make the development process and
the resultant software scalable and reliable on diverse platforms, such as
multi-processor and distributed computer networks. This remains a key area
for me.
When I joined Attention to Detail in 2002 they were developing a racing game
for toy brick company Lego, to follow up Lego Racers 2, a PC and PS2 title
which they'd recently finished. Drome Racers was known as Lego Racers 3
during development, and themed to tie in with some techie Lego cars.
I arrived too
late to make a significant contribution to the PC or PS2 code, but got
involved in the conversion to the Power PC based GameCube. Ports of the game
for this machine and Xbox were scheduled to follow the PC and PS2 versions,
and benefited from extra development time.
The sad thing about Drome Racers was that - due to publisher interference -
it was a more playable game six months before completion than it was by the
time Lego deemed it fit for release. The management of Lego games seldom
lasted as long as it took to complete a console title, and drew from a pool
of people with little experience of the games industry, which meant
frustrating changes in direction that did not improve the eventual
product.
Despite this, and the problems of the Kaboom group, the Xbox and Nintendo
ports were finished on time, and the Gamecube version of Drome Racers briefly
appeared in the UK top 10 for the platform.
A more ambitious project, Lego Racers 4, was canned after substantial
development effort. This was technically interesting as the design called for
streaming of the entire game world from DVD, allowing much larger and more
intricate play area than earlier Lego games, or most console titles at the
time. The team involved went on to work on Ion Runner, of which more later...
Fatman & Slim, PlayStation 2, ATD/Kaboom 2003
Fatman and Slim started out as a physics demo, built around MathEngine Karma
dynamics library, and was initially funded by Sony. When they passed on their
option Kaboom continued and finished development; the game passed Sony QA at
the end of 2002. By this point the group was running out of money and made
most of the staff at ATD redundant; they were unable to finance the
publication of the game themselves, and sold the rights on to budget
publishers Metro3D in 2003.
Having exhausted the metal-bashing potential of the GameCube I was moved to
the FatMan team late in the development, and given the task of optimising the
code to animate water surfaces, which was taking a large proportion of the
frame time when running in 'optimised' C on the main processor. I reworked
this to run concurrently on the PS2's vector units, using VU0 for updates
(moving the water surface) and VU1 for rendering (stretching the reflection
and adding specular highlights as it caught the light).
Despite the extra specular layer and a tripling of resolution, my optimised
code ran several times faster and imposed very little load on the main
processor, leaving that to concentrate on the physics.
Ion Runner, PS2/GameCube/Xbox/PC, ATD/Kaboom 2003
This grab from the unfinished game Ion Runner, in development at ATD when the
Kaboom group collapsed, includes diagnostic messages showing how it was able
to manage three pools of rippling, specular-glinting water in a single game
level, plus a new heat haze effect streaming from the exhaust of the player's
ion bike.
I wrote the code for these effects, building on routines written for Fatman
the previous year. ATD`s game engine Saracen 2 made great strides during
2003, especially on PlayStation 2 thanks to optimisations by Andy Wright,
till it was comfortably drawing over 100,000 polygons, many of those
'expensive' types to render, at a steady 60 Hertz (over seven million polys
per second, at peak, without dropping frames).
I moved from the Vector Units to the PlayStation 2`s IO Processor and
reworked the ATDIOP sound and data streaming system to improve performance
and reliability.
Two complete levels of Ion Runner were programmed and demonstrated to many
publishers, but there was not time to sign a deal before venture capitalists
3I pulled the plug on the company in August 2003.
Since then the demos have been seen by many in the industry who were
surprised that the project was never finished - but the price, calculated to
refloat the group as well as to cover the development costs, meant any deal
on this new IP was hard to arrange.
This image includes graphics by Chris
Oxenbury, who later found fame as the stand-up comedian Okse and a
lucrative sideline producing comedy-related artwork, and now works for
top children's TV company Ragdoll.
I have since worked for independent publisher Codemasters - follow this
link if you're interested to know what I've been up to relatively recently.
© Simon N Goodwin, Warwick 2005..200, and reviewers
Link to the top of this document
Link to the article index