Jonathan Thomas

Written by ST Graveyard

1) Introduction
2) History with computers
3) The Atari ST comes into play
4) Why Lotus?
5) The Amiga version of Lotus
6) Blitter power
7) Recycling the Pole Position code
8) 16 vs 32 colors
9) Jamie/Junosix
10) No MOD
11) Frustrations
12) Obsessed by racing games
13) Outrun
14) Professional life
15) Favorite games
16) The Atari community
17) Idols
18) Words of Wisdom

The Texas Instruments TI99, Jonathan's first computer and his introduction to programming.

Jonathan even went to the darkside, just for a second, using the Commodore VIC 20 ;-)

The magazine that started it all!

Roadblasters, an Overlander clone. Or is it the other way around?

Outrun was the first game Jonathan bought. What a disappointment it was. With some luck, he will be making a new version on the STE ;-)

Formula One Grand Prix, one of his favorite games of all time.

Pole Position was the first STE game by Jonathan.

The original ST version of Lotus was missing a lot of the technical details Amiga owners could enjoy.

The Amiga version of Lotus Esprit Turbo Challenge

Because Stardust was a one screen game, more processing power could be used to play Amiga-type MOD music.

Another one of Jon's projects, Pole Position 3D. How cool is that!

Droid Special Edition is a nice showcase by Jamie Hamshere of what the STE can do.

When Jon saw Strike Commander, he moved on to the PC.

The release picture of the STe enhanced Lotus game.

Obsession was another fine example of a game featuring MOD type music.

Midwinter 2, one of Jon's favorites, and the grand-daddy of the open world genre.

GTA 5 ... fun for a short while.

Stunt Car Racer, another amazing Geoff Crammond game!

An attempt to create Super Sprint in STOS 3D was made, without much success.

The Overlander review in issue 10 of The Games Machine.

1) Jonathan, first things first, can you introduce yourself to the readers?

I’m forty-something years old and live with my family in the city of Leeds, UK. I spend most of my spare time walking to keep in good shape, and tinkering with computers to satisfy my intellectual curiosity.


2) What is your history with computers? How did it begin? And what was your first machine?

I think I was seven years old when we acquired a second-hand Texas Instruments TI99/4A. It came with some pretty awful BASIC games on cassette tape, but also some wonderfully thick reference manuals of the type you rarely see these days. One of those manuals was some kind of “Learning BASIC” book, and my young mind was greatly fascinated by typing in the examples from the manual to see what they did.

In the same way as I imagine many programmers get started, I experimented with modifying the example programs, and this gradually led to me writing my own rather primitive programs in BASIC.

My grand plan was to create a Formula 1 game called “Nigel Mansell’s Grand Prix”in BASIC for this machine. I have vague recollections of designing the car sprite on graph paper and subsequently writing a program to get the car displayed on screen. I remember planning out the BASIC listing for the entire game on a pad of A4 paper before attempting to enter it into the machine!

Needless to say, the project never reached completion – I imagine it was a combination of excessive ambition and losing interest in favour of other things.

We also had a Commodore VIC-20 that I briefly flirted with. I don’t remember so much about that one. It didn’t come with a tape drive so any BASIC programs entered were gone when the machine was switched off!


3) When did you acquire an Atari ST, why and what did you use it for?

I think I must have lost interest in computers for a couple of years after my failure to complete my “Nigel Mansell’s Grand Prix” game.

Sometime in 1988, some spark of inspiration ignited within me, and I asked my parents if they wouldn’t mind buying a computer games magazine for me. The magazine they came back with was issue 10 of “The Games Machine” (UK), featuring Overlander, Fire and Forget and Roadblasters on the cover. (https://archive.org/details/the-games-machine-10/mode/2up)

I was absolutely mesmerized by that cover image of Overlander, and spent some time imaging how it would look in action, with the car moving smoothly along the landscape, and up and down the hills. The magazine featured content on all of the 8-bit and 16-bit machines, but it was Overlander that caught my attention. Overlander was the only game that I wanted, and the only version that looked good enough was the Atari ST version!

After much nagging, my parents kindly bought me an Atari 520STM from Silica Shop (a well-known UK seller of ST and Amiga hardware, amongst other things). The ST came bundled with Overlander, Star Wars, Space Harrier and a fourth game I can’t recall! Overlander was just as amazing as I’d imagined and I eventually played it through to completion.

The first game I purchased for the ST was OutRun. I’d played the arcade machine maybe a year earlier, so I knew exactly what to expect from this arcade conversion on my new and powerful machine. The game arrived in the post about half an hour before I was due to head to school, so I had a chance to briefly check it out. After a brief period of confusion trying to work out why there was an audio cassette in the box, I popped the game into the floppy drive, switched on the machine and marvelled at the colourful and detailed title screen containing the start line and all of the people bracing themselves for the Ferrari to zoom away! Do I need to tell you what happened in the minutes following this? Probably not!

Probably around three-quarters of the ST games I purchased were driving or racing games, with the highlights being F1 Grand Prix, Lotus (of course!), Toyota Celica GT Rally, Super Hang-On and Stunt Car Racer.

It took me a couple of years to get into programming for the ST. The version of BASIC that came bundled with the ST wasn’t at all suited to the creation of action games.

I obtained a copy of STOS BASIC shortly after launch, but it took a year or two before I started using it. The only game I managed to complete was a very basic effort called “Bombs Away”, in which a man named “Billy Bomb” carrying a metal plate over his head had to catch bombs falling from the sky in order to stop them landing on and destroying the city. The plan was originally for the game to feature multiple bombs falling from the sky simultaneously, but the COLLIDE command in STOS BASIC required an understanding of binary numbers, which I didn’t grasp until much later!

I attempted to create a number of other things in STOS Basic – 3D racing games like Overlander, 2D racing games like Super Sprint and an attempt at a scrolling platform game. None of them came to much – I didn’t have the theoretical understanding I needed to bring these ideas to life.

I gave away the ST in 1993, seduced by the world of PC games, and in particular, Origin’s Strike Commander. The last ST game I enjoyed playing on the ST was Powerdrome. It still plays very well today in my opinion.


4) Today, I suppose you still are a big Atari fan, as you recently enhanced the Magnetics Fields' classic Lotus Esprit Turbo Challenge for the Atari STE. Why did you pick this game?

I’ve had an interest for many years in reverse engineering, emulation and the internal workings of games.

Games magazines of the 1980s and 1990s often featured interviews with the programmers alongside reviews of their games. Programmers would, from time to time, boast how they were pushing a machine to its limits, or inventing a brand new technique to display graphics or play sound. Such claims were of course shrouded in mystery and secrecy.

The world of emulation has given us an enviable set of tools to look back on this era and put into context the claims being made by the developers. Hatari and Steem Engine (the two most common Atari ST emulators) both come with comprehensive debuggers that enable you to stop a game at any point and have a good look around the internals – the code that runs the game and the data used by that code.

Sometime in 2019, I was looking to start a new project, and was using the Hatari debugger to examine the internals of a few different ST racing games. I suspect I settled on Lotus as a result of a couple of different factors.

Firstly, I’d only recently come to realise how different the ST and Amiga versions were, and was able to assess from my previous experience with Pole Position how the gap between the two versions might be narrowed through use of the additional hardware in the STE.

Secondly, of all the games I looked at, Lotus was the one with the most accessible and understandable code. I located the code to draw the road first, and felt from looking at this in detail that there may well be potential to leverage an adapted version of the Blitter-based road drawing code I’d previously used for Pole Position.

The combination of these two factors gave me sufficient momentum to settle on Lotus and produce the first proof of concept in late 2019 (https://www.youtube.com/watch?v=q0n4mpMRiaw).

5) Lotus Esprit was specifically developed for the Amiga. It used this computer's full hardware capabilities. Still there was an ST conversion made. I personally think they did a good job. How do you feel about this? And how do you think they managed to create still a very fast and fun game on a vanilla ST? Are there any aspects of the Amiga code that you find amazing? What is your opinion of the original game from a coder's perspective?

Game development on these old platforms is all about compromise, and there are few better illustrations of this than the ST. If you want to make the game run faster, or move sprites around the screen more smoothly, you can utilise larger amounts of RAM to do that. Classic examples of this are pre-shifting graphics and unrolling code loops. However, you may then find that you want to add more features to the game, and you’re running out of RAM to do this, so you then have to remove some of the improvements you’ve made to speed up the game. It becomes one big balancing act, where you have to carefully choose your priorities.

Lotus on the Amiga appears to run at a steady 25fps. My perception is that maintaining the high framerate across both platforms was very important to the development team, and they chose to keep the framerate high on the ST version by reducing the visual quality, retaining only the elements that the ST was well suited to delivering.

The ST version therefore dispenses with the majority of road detail, along with the fine sideways movement of the cars, roadside scenery and background – these are all features that would have been very difficult to implement on the standard ST. On the upside, it maintains the same quantity of cars and roadside objects as the Amiga version, and (more or less) exactly the same graphics for these objects. The background mountains are also retained using the same graphics as the Amiga version.

Lotus is a special game to me for three reasons – firstly, the high framerate, secondly, the perfect representation of hills and corners, and finally, the sheer quantity and size of the objects moving around the screen. Amazingly, all of these are retained in the standard ST version. One of my favourite moments in the game is the start of the Mexico track where you’re parked up at the top of the hill, looking down on 19 other cars in front of you. You’re unlikely to see that in any other ST game.

We only encountered the Amiga source code at a relatively late stage in this project, and so far haven’t gained much utility from it. We may well undertake further work in future to reverse engineer the track and scenery formats to start allowing for modifications – I imagine this is the point at which we’ll start to reap the benefits.

Regarding the quality of code in the Amiga version, I have a general understanding of the Amiga architecture, and what the 68000, Copper, Blitter and Paula do, but I don’t know much about it from a programming perspective. It’s plainly obvious that Shaun was passionate about the machine and wanted to create a title that would showcase it. I think he certainly succeeded in doing so!


6) In your version of Lotus, you have made full use of the STE’s Blitter capabilities, just like the original on the Amiga. Can you explain a bit to the complete NOOB (like me) what the Blitter actually does? How it works and how a game like Lotus benefits from it (compared to the normal ST version)?

One of the most challenging aspects of doing graphics programming on the standard ST is that it uses a planar graphics memory layout. A major downside of this is that when drawing sprites (e.g. cars or roadside scenery) on the screen, it becomes very computationally expensive to draw those sprites at sideways pixel positions that are not increments of 16 pixels. For example, it’s fast and easy to draw a car sprite at sideways pixel position 0, or 15, or 31. If I want to render that car sprite at sideways position 3 or sideways position 20, the 68000 is suddenly faced with a series of quite intensive calculations in order to do that. These calculations will take a while to perform, and the frame rate of my game will be affected.

In order to get around this issue, many ST games perform a technique known as “pre-shifting”. This technique performs the calculations required to render a sprite at various sideways positions ahead of the game being played, and then stores the resulting graphics data in RAM so that sprites can be rendered at increments of (for example) 4 pixels just as quickly as they can be rendered at increments of 16 pixels.

The downside of pre-shifting is that it quickly starts to consume large amounts of RAM. For example, the data required to store a 64x64 pixel sprite might be 2048 bytes (2K). If I decide I want to render that sprite at 2 pixel increments so that it moves across the screen more smoothly without affecting the framerate, I need eight times more RAM. That’s 16384 bytes, or 16K. On a machine with 512K, you can imagine how easy it would be use up all of the available RAM!

When using the Blitter, all of these problems suddenly go away. The Blitter is a specialist piece of hardware, particularly suited to graphics work, that can perform the calculations associated with pre-shifting in real time. Instead of storing a pre-shifted sprite at sideways pixel position 4 in RAM, the 68000 can ask the Blitter to perform a series of graphics operations in real time to draw that sprite at sideways pixel position 4. Having the Blitter draw this sprite will almost certainly be faster than having the 68000 draw the pre-shifted version, and there’s no need to consume vast quantities of memory with pre-shifted sprites.

Note that the Blitter does not run in parallel with the 68000 – they take it in turns to perform tasks (with a slight exception that’s a little too technical to go into here). The benefit of having the Blitter is that it can perform some tasks much more quickly than the 68000. We therefore use the 68000 for general processing work, and the Blitter for specialist graphics processing work.

It’s possibly time to explain how this relates to Lotus.

One of the key decisions made on the original ST version of Lotus was to dispense with pre-shifting almost entirely for the drawing of cars and roadside scenery. This means that the 68000 has time to display a lot of sprites on screen in each frame, and those sprites are available in many sizes (to make them scale smoothly towards the player), but with a few exceptions they can only be displayed at 16 pixel sideways intervals. This explains why the cars and roadside scenery “jerk” across the screen in the ST version of Lotus. It’s a lot more noticeable when you’ve seen the Amiga version in action.

In contrast to the car and roadside scenery sprites, there are four pre-shifted copies of the background mountains. This allows the game to scroll the background mountains in 4 pixel increments, which is a reasonable compromise between visual quality and consumption of RAM.

Finally, the detailed road with all of the white lines is rendered by the Blitter on the Amiga version. In order for this amount of road detail to be displayed on the ST, the road detail would need to be pre-shifted, and there’s simply not enough RAM in a 512K to do this. It also wouldn’t be feasible to display the horizontal lines of the road at 16 pixel sideways positions in a similar fashion to the car and roadside scenery sprites – it would look absolutely awful! The standard ST version therefore uses a highly optimised CPU algorithm to render the road, making heavy use of unrolled loops and self-modifying code to maintain the framerate.

You’ve probably guessed that the presence of the Blitter takes all of these problems away. We can now render car sprites at any single pixel sideways position. We can make the background mountains scroll at single pixel increments. We can store the road as an image, and render each horizontal line of the road at any sideways position we wish, mirroring the way in which the road is rendered on the Amiga version.

In summary, what we’ve done is take the vast majority of existing ST 68000 code that renders the in-game view, and replace it with code that uses the Blitter instead, making visual improvements where the Blitter gives us the ability to do so. We’ve quite aggressively optimised some areas of the screen (the status panel at the right being a prime example) in an attempt to get the framerate of the STE version as close as possible to that of the Amiga version.

7) So if I understand correctly, you did not use any of the Amiga code for the Blitter enhancements? You actually used the things you learned from the Blitter code of the Pole Position conversion you did a few years back and used this in the Lotus STE version?

Regarding the use of the STE Blitter, all the code associated with that was written from scratch rather than adapted from the Amiga code. The code to draw the road started off as a derivation of what was used in Pole Position but has changed quite significantly since. I know very little about programming the Amiga Blitter but I suspect that it's too different from the STE Blitter to allow the code to be effectively adapted from one platform to the other.
What did help in the creation of Lotus STE was the fact that the features we were attempting to add in already existed in the Amiga version, so we would be reasonably confident that some of the work for a given feature would already have been done for us. For example, with the smooth sideways movement of the cars, we knew that the Amiga version was calculating the sideways positions of those cars to an exact pixel position, so the likelihood was that the ST code would also be calculating this exact pixel position and then rounding it off to the nearest 16 pixels to be drawn on the screen. This turned out to be a correct assumption in most cases and made our lives quite a lot easier.

8) The new Lotus STE now features the gradient sky effect (as seen on the Amiga). You mention that for this effect the enhanced color palette of the STE is used. But this is what I don’t understand. The STE has a palette of 4096 colors, the ST 512 but both computers can ‘only’ display 16 colors on screen at once. The Amiga however has also a palette of 4096 colors, but can display 32 colors at once. But if both the STE and ST can only display 16 colors at once, why couldn’t the ST version feature a gradient sky? Or does this has to do with processing power and without a Blitter the 8Mhz processor can not handle a gradient and the game would become too slow? I don’t understand that in your version, an STFM with a Blitter, has less colors in the gradient compared to the STE version, since both computers can only display 16 colors at once.

The technique used by the gradient sky is common, and you’ll no doubt have seen it in other games and demos.

It’s common to say that the standard ST can display a palette of 16 on screen colours from a total of 512. However, one of a number of ways to break this 16 colour limit is through use of a hardware feature named ‘Timer B’ that allows the programmer to change one or more of those 16 colours at given lines of the screen.

The palette index of the sky colour in Lotus is 15, and we leverage ‘Timer B’ to change the value of that palette index through a number of slightly different colours as the electron beam within the display moves down the screen, creating a pleasing gradient effect. As far as the ST is concerned, it’s never displaying more than 16 colours at any time. Obviously, the electron beam is a relic of CRT technology and doesn’t physically exist for most people now playing the game, but the principle still applies!

The reason the STE can show more colours in the gradient sky is because of the total number of colours it has access to – 4096 as opposed to 512 in the ST. Say if we had a gradient sky which was black at the bottom, and white at the top. The STE has access to a total of 14 shades of grey between black and white, whereas the standard ST has only 6.

It wouldn’t have been particularly difficult to add the gradient sky to the ST version – it’s not demanding on the CPU and they may well have left it out because the lower number of colours available in the standard ST would have reduced the visual impact considerably.


9) The new version features DMA sound effects. Realistic engine noises, slippery sounds and so on. Was this hard to accomplish? And how was working with Junosix?

Jonathan : The one area of programming in which I’ve always struggled is that of audio. I don’t have a good understanding of either sound theory or sound programming.

There was a turning point in the project where a chap called Masteries came along on Atari-Forum and kindly offered me the DMA mixing code he’d been using in his work-in-progress Metal Slug game for Atari STE. This allowed me to rip the sound effects from the Amiga version, and get them playing back on the STE in place of the existing YM effects. However, this still left me with the YM engine noise. I knew there was a strong desire for the STE version to feature a sampled engine noise as featured in the Amiga version, but I had no idea how to accomplish this.

At exactly the right time, and in a very short time period, Jamie moved from making suggestions of how to implement sound on Atari-Forum to being a full-time contributor to the project. I admire him because he’s taken full ownership of the sound side of things from his early code contributions to the game you see today. I feel that we’ve complemented each other spectacularly well in that we both believe in our convictions and just get on with the job. I’d like to think the finished product speaks for itself from an audio point of view – it’s incredibly polished.

Jamie/Junosix : From those early stages in late 2019 when Jon demonstrated the improvements brought by utilising the Blitter, imaginations were sparked at the thought of visuals being accompanied by the roaring sampled engine sound from the Amiga version.

I had a prod at the original game in the Steem debugger and managed to find where the game deals with the speed of the player car(s). It was cool to discover that real-world rev values are used (and as I later found out when Jon stumbled across a large section of the original Amiga source code, gear ratio values to derive the miles per hour figure from the revs too, rather than just having arbitrary values for everything - nifty!). The pitch of the engine sound in the Amiga version was clearly related in some way to the rev values, but while the Amiga has the ability to represent this by playing samples at a number of different frequencies, the STE is limited to 4 successively doubling individual frequencies. The most CPU-efficient way of achieving something similar to the Amiga version would be to pre-sample the engine sound at a number of different frequencies and then have them played back at one of the STEs fixed frequencies. The issue with this approach is that this very quickly uses up memory - for example, to have 32 different pre-sampled frequencies would have taken around 150KB and would have sounded quite "steppy" as it went through the rev range (we later learned that the Amiga version goes through almost 900 different frequency steps!). It didn't seem ideal but for some time it felt like that was the only option.

Jon later tried some other ideas with the Blitter code which made a phenomenal difference to the framerate, and it seemed plausible that perhaps there was now a little bit of CPU time left over that allowed a reassessment of the approach to creating the engine sound. Now that I was familiar with how the ST dealt with revs, I had a hunch that the same bit of code would be somewhere in the Amiga version, so stepped through it using the debugger in UAE, and - bingo! - yes, both versions internally deal with the revs in the same way. From there I was able to trace through and see how the rev values are used to calculate the 'period' value written to the Amiga soundchip, and hence derive the playback frequency.

Using a spreadsheet, I made a table of the full rev range (1000-7999rpm) and the corresponding frequencies, then used these to calculate a 'scaler' value for each rev to be used in the STE version. The scaler value is used to stretch/squash the rate that sample data is read around the chosen fixed frequency of 12517Hz to closely match the frequency of each of the revs of the Amiga version. The downside is that this variable rate technique has to be done in software, so uses up more CPU time than straightforward hardware-driven linear sample playback. This "rev map" lookup table of scaler values was able to be used in-game, saving CPU usage by not needing to constantly calculate them in realtime.

Luckily, the engine sound and other sound effects were included in a ripped version of the .MOD files of the Amiga version's music that can be downloaded, so it was a question of extracting them using a .MOD tracker giving us the raw samples. The sound effects (such as skidding, crashing, etc.) have a fixed pitch therefore can be pre-scaled, so I wrote a small program for the ST which took the original Amiga sound effect samples and rescaled them to 12517Hz based on the period values observed in UAE's debugger, and writing them back out again.

Jon had put together a clever open-source development environment which made putting new code into the original game a breeze, so it was possible for others to try out new ideas. Masteries' made a vital contribution with getting the bones of the sound routines in to start with, so with that in place it was quite clear where code needed to go. I wrote a routine which mixed the variable frequency engine sound with the fixed frequency effects and included a small example program and description for Jon as to where I thought the code could go - I received a message from him later that day to say he'd slotted it in as suggested and it had worked out of the box! I set to work replicating Jon's build environment on my own computer so I could download his updates, test things out myself, and send him code and ideas as and when I'd implemented something new.

The original Amiga source snippet that Jon had found worked as a set of clues to help refine the sound even further - for example adding a fade out of the engine sound at the end of the race, and allowing sounds to retrigger or take precedence over other sounds after a certain amount of time. After several weeks we both felt that the sound was about as on-par with the Amiga as possible.

It was a brilliantly collaborative team effort working with Jon, we would message each other on a pretty much daily basis with improvements to both the graphics and sound, the game becoming iteratively more polished in front of our eyes and ears. We knuckled down right up to release date - Jon hitting it particularly hard on the final stretch working as much out of the Blitter as he could, and I crammed a few ideas in a day or two before the deadline to allow Mega STs and STFMs with Blitters to enjoy the graphic enhancements without the sampled sound mixing, and a little experimental mode to let Mega STEs run the game at 16MHz.


10) The soundtrack in game are still the original YM tunes. I personally love this, it makes this version, with the enhanced sound effects in combination with the YM tunes, very unique. But why did you not use MOD music like the Amiga? Isn’t the STe capable to do this (thinking of games like Obsession or Stardust)?

Jamie/junosix : I really like the mix of YM+DMA music/effects, it still feels resolutely like an ST game. Jon and I both approached the enhancements with the idea that there was no reason that a stock 1040STE back in the early 90s couldn't have pulled it off. We weren't trying to outdo the Amiga version, just get as close to it as realistically possible. The hard truth is that despite the Amiga and STE looking very close when comparing the cold hard specifications on paper, the reality is that the Amiga works much more in unison with its component parts than the STE, which requires compromise when using more than one of the enhanced features at the same time, as things are fighting against each other instead of sharing their time fairly. The other thing to bear in mind is that the original Lotus was built from the ground up to be an Amiga game, then converted to the ST with a lot of (thankfully for us!) vestigial Amiga code left in, then modifed further to use the STE features, so the original code was not as efficient as it could be in many respects.

Playing .MOD-type music with similar clarity to the Amiga but with a strict limit on RAM usage takes around 45% processor time, which works okay on games like Stardust and Obsession - in the case of Stardust the gameplay mostly takes place on a static screen, and Obsession having few onscreen elements supported by vertical hardware scrolling. Lotus has to deal with many onscreen objects and a oscillating road whilst keeping a high framerate - to lose around 45% CPU time to music playback would decimate the fast-paced arcade gameplay.


11) When looking back at this project, how long did it take to accomplish and what was the hardest thing to do/your biggest frustration?

The initial foundation work on Lotus STE was done from December 2019 to January 2020. I picked up the project again at the beginning of February 2021 and worked heavily in my spare time from that point until the release day. Jamie joined the project around the beginning of March 2021 and also contributed heavily up to the time of release.

The hardest thing to do may well have been the engine noise - there was a lot of discussion and thought in the community around the best way to produce an engine sound until Jamie came up with his mixer code to play a variable rate engine sound and sound effect simultaneously. It’s a real innovation!

The Blitter chip has been both the greatest source of frustration and one of our greatest blessings.

If you look at the Amiga, all of the custom chips are specifically designed to work in harmony and have been designed as a coherent whole.

In contrast, the Blitter feels very much like an third party add-on to the ST, where little thought has been given to how it might be used in practice, especially within a gaming context. You might imagine that you could give the Blitter an instruction along the lines of “render this large red Lotus sprite”, and it would go away and render the sprite while the rest of the ST carries on with business. What happens in reality is that the Blitter stops the 68000 in it’s tracks while it renders the car sprite, and once the 68000 gets control back, the music has been delayed, the sky gradient is broken, and so on.

It’s for the above reason that I almost gave up on this project back in 2019 – I couldn’t work out how to make use of this supposedly amazing piece of hardware, and the game was actually running more slowly than before!

In order to use the Blitter effectively in a game context, it’s therefore necessary to micromanage it. You have to break down the work into very small chunks to minimise the effect on everything else that the game is doing. However, if you break the work down into chunks that are too small, the framerate suffers. If the chunks of work are too large, the music slows down and the sky gradient breaks. It’s a balancing act and there’s no magic formula. There is music slowdown from time to time in the finished product, but it’s about the best balance we’ve been able to find!


12) When I look at your GitHub, I see you are/have been working on other racing games for different systems. Especially Pole Position. Why this fascination with racing games? And how long have you been creating games?

I’m not really sure why – I’ve always loved racing games! Around 75% of my ST collection was racing games. I used to be very interested in cars and Formula One – less so these days.

I’ve never been strong at creating games from scratch – I tend to struggle with the game design and asset creation side of things. I find it a lot easier to either create derivative works (as with the 3D Pole Position remake or Atari ST Pole Position) or adaptations of existing games (like Lotus STE).

I’ve been working on programming projects in some form or another for around 35 years using STOS, Turbo Pascal, C/C++, 80386 assembly and then back to C and 68000 for Atari ST Pole Position from 2014 onwards!


13) I just noticed you are thinking of doing a proper conversion of Outrun for the STe. That would be amazing as the original ST port is so bad. Is this for real? Aren’t you burned out yet?

Ha ha! The OutRun conversion is something of a pipe dream. I like the PC Engine conversion a lot because it’s a heavily cut-down interpretation of the arcade game that still captures the spirit, magic and essence of OutRun. Looking at the level of graphical detail and the way the game moves, I think something very similar, but with less colours, could be realistically accomplished on the STE.

I’ve spent a brief period running through the PC Engine version of the game with a debugger to get an initial feel, but no further.

The final weeks of Lotus STE development were very intense and I did burn myself out a little to be honest! But it’s immensely satisfying to see so many people enjoying the results of our hard work.

It’s likely that I will take a few months away from ST programming to recharge.


14) What do you do in real life?

I work 9-5 as a contract PHP developer. The PHP code in the Lotus repo might be a bit of a giveaway – it’s the language I’m most familiar with these days!


15) Do you play games, and if so, what is your favorite game (apart from Lotus)? Classic and/or new?

The last modern game I really enjoyed was Wreckfest by Bugbear Entertainment. I like it because it’s instantly accessible, nice looking, full of comedy moments and has a worthwhile single player campaign that’s not reliant on DLC. I admire the work and innovation that goes into games like GTA 5 but I don’t have the patience to play them – it feels more like work than play.

My favourite game from the ST days would undoubtedly be F1GP. Absolutely mindblowing at the time, and probably more influential on today’s racing simulations that anybody can imagine. A close second would be Midwinter 2 – Flames of Freedom. I wasn’t very good at it but I was in awe of the possibilities and scope of the open world.


16) What do you think of the Atari ST community of today?

We now have extremely accurate emulation of the STE, which is facilitating a new generation of innovative STE projects. We’re starting to see good use of the Blitter and DMA sound but hardware scrolling remains relatively unexplored. Jamie’s “Droid: Special Edition” is an absolutely fantastic example of an all-round STE showcase and deserves more attention.

I do feel that the ST scene is somewhat modest and we could be better at sharing what we accomplish with the rest of the retrocomputing community. The ST is still relatively low-profile as a retrocomputing platform but I don’t see why it needs to be – the scene has a great deal to offer to the wider world of retrocomputing.


17) Who do you look up to? If you could have a drink with someone, anybody, who would it be and what would you ask him/her?

Geoff Crammond. I could come up with a never-ending barrage of questions about the development of the F1GP games.

If Geoff wasn’t available, I’d hope to speak to Mike Singleton or Paul Woakes, sadly neither of whom are now with us.


18) Do you have anything you like to share with the community? Any last words of wisdom?

I expect to be much older before I’m capable of dishing out anything that resembles wisdom!


Thank you both for this interview and for making this splendid game!


For more details check our YouTube video.