Star Fire was a revolutionary game, no doubt about it. It introduced a number of firsts: the first high score table, the first colour monitor in an arcade game, and the first sit-in cabinet. I couldn't believe it when I found one in an arcade, two years after seeing Star Wars – this was the real deal. And it appealed to my appalling arcade skills, too. You could keep playing as long as you pumped credits in, which kept me alive longer than my median 30 seconds on Galaxian.

​

It wasn't so much a game as a ride, really. But what a ride it was. Of course, it was quickly eclipsed by later games, notably the proper arcade Star Wars. But I remembered it fondly, and I wasn't the only one – there was a lot of celebrating when the long-lost ROMs turned up and it found its way into MAME.

​

And then, many many years later, the original programmer David Rolfe put the source code up on the internet. i looked at that, and looked at my Spectrum, and thought right.

​

Or rather, wrong. Because this was NOT an easy port.

​

Thanks for the Memory

​

First of all, the original machine had a lot of memory, more than the 40-odd kilobytes available in a 48k Spectrum. The graphics alone were huge – perspective was simulated by creating images of different sizes, with no compression. The code itself contained references to cross linking; it certainly didn't look like pure Z80 and was almost certainly written on a more powerful machine and squirted down onto the target hardware.

​

However, there was one bit of luck, which was the limitations of Star Fire's graphics system. Playing the original showed some colour clash, much like on the Spectrum. Although it didn't quite use the same form of attribute mapping, the results were broadly the same and, with a bit of work, it was possible to adapt the colour mapping system to the Spectrum's attribute memory. So there are still colour clashes, just different ones.

​

But memory was a real problem. I'd planned to use a trick I'd seen in Melbourne House's game Starion: build a screen in high memory and then run a fast routine on the stack to load it into screen memory. This was 3-4 times faster than the Z80's native LDIR, and allowed for flicker-free images. But it meant having kilobytes of free memory mid game, and there simply wasn't room for that. So there are still flickers, but mostly in the lower third of the screen, the Spectrum's 'slow screen' area.

The controls were a problem too. There wasn't enough memory to implement redefineable keys and joystick control, and I felt that the latter was pretty important in terms of preserving the spirit of the game. In the end, I used a neat little module that had code for both cursor and Kemptson joysticks built in. I figured that old Spectrum diehards would have no problem with the cursor keys. Hell, even Ultimate had to resort to bit masking to poll the QWERT keys to save memory.

​

Neighbourhood Witch

​

The game engine and attract modes were straightforward (and it's a blast to see those attract screens running on a Spectrum). The huge TIE fighters were dealt with by a whizzy little compression/decompression routine. But I had to do something about the gameplay. The insert-coin-for-more-play-time model didn't make for a compelling game, so I gave the player three lives along with an energy bar. But keeping the original lock-on mode still made the game far too easy, so there was a lot of tweaking to get the pacing right. That only left the 'Exidy' mothership.

​

I couldn't find it.

​

it was only when I read an old article about Star Fire that I understood why. When David Rolfe and his team tried to sell the game, they had first approached Midway. Somewhere along the road, a suggestion was made to base it around The Wizard of Oz, and one of the changes included adding witch on a bicycle for you to shoot. They abandoned that idea when they sold the game to Exidy with the Star Wars look and and feel that it finally went out with – but the reference to the witch remained in the source code; and that was where the mothership lurked. I'd simply been looking in the wrong place.

But it was hard to feel frustrated when I started reading some of the comments in the source code relating to the witch. It clearly wasn't a popular choice with the programmers, and routines were tagged with statements such as "GIVE SOUND FOR WITCH HIT... AND GIVE LUDICROUS MESSAGE", "IS STUPID WITCH IN POSITION TO BE HIT?; IF SO, GO DO IN THE OLD BAG", and "DID WE JUST FINISH OFF THE OLD GIRL?"

​

in fact, the source code is peppered with hilarious messages... it reminded me a lot of the sense of humour that permeated the games put out by Design Design in the 1980s.

​

Sadly, the actual image for the witch wasn't in the code. It would have been fun to include that, but there was a very good reason that it was missing.

​

The Sequel Strikes First

​​

You see, the source code that I had access to wasn't actually for the original Star Fire – it was for a sequel called Star Fire II. There's some mystery surrounding this; was it ever released? Online videos seem to indicate that it was actually assembled into a playable form. There was also a version called Rolling Star Fire, which came in a hydraulic cabinet that moved along with the game, much like the Space Harrier cabinet that would emerge nearly a decade later. This certainly existed, but outside of a photo from a trade fair, there's little evidence that it ever made it into an arcade.

​

It's very likely that Star Fire II was coded for this particular use case. The title screen in the source code had a very clear "II" added to the bottom of the logo and (despite what I said above about the attract modes being easy to get up and running) reinstating the original title screen involved going through both the source and the disassembled Star Fire arcade ROMs instruction by instruction to map out the screen drawing instructions.

​

There are some differences in the coding for both versions, although it's hard to be precise without source for the original original game. The Star Fire II code looks more optimised, and I noticed what appeared to be calls to external hardware outside of the normal screen, audio and controller polling. I would guess that this was to drive the servos for the motorised cabinet – it certainly seemed to map on to in-game actions. Calling the code segments had no impact on the game that I could determine.

​

There was an element of serendipity here. The tidy code saved a bit of memory, as did dumping the hardware routines. But what to do with all those glorious bytes of extra RAM? Well...

​

Hidden Gems

​

On a whim, I decided to add another ship to the game, flying right to left at a high speed. Shooting this gains you an extra life. On another whim, I modelled it on the Interstellar Queen from those old Terran Trade Authority books. It was weird sitting down with a pixel editor and designing sprites again after 40 years.

​

But why stop there? Why not add even more ships? Well, two reasons. One, I wanted this to be as accurate a conversion as possible, within the limitations of the target machine; and two, by this point, I was seriously running out of wiggle room in terms of memory. But I felt that there had to be some easter eggs!

 

The original game no only had the first high score table, it had the first high score table easter eggs. Certain initials would flash up messages ("CHECK FOR MAKERS" in the source code), so I had to include those. But I managed to squeeze in a few other message / initial combinations too.

 

And in the end... maybe some extra ships found their way into the game, and maybe you can unlock them if you know how. Maybe there's a cheat mode.

 

But there are definitely only 24 bytes of memory left (20 on the 128k version; but to be fair, I did go to town on the music and sound effects on that one). It's about as faithful an emulation as is possible on the Spectrum, and it plays at a decent pace. It wouldn't have been possible without the source code. It's also worth mentioning that the source code was for Star Fire II – and enhanced and streamlined version of the original. I have a feeling that the v1 source code might not have been quite as tidy.

​

Meet Thy Maker

 

This being a conversion, I felt that I couldn't just release it willy-nilly, even if it was a zero-profit enterprise. So I tracked down David Rolfe, and asked his permission before releasing this. He was fine with it, and said that he was "...happy to see anyone do anything they want with it at this point." I also said that I was honoured to be porting a true classic like Star Fire, and he was very humble about it (and also his very tidy coding).

 

"I don’t know how “classic” Star Fire was, but it was my first professional game, and the software was a mess," said David. "I developed it for a Star Wars fanatic who designed the hardware, including an insane amount (for the day) of ROM and the first color monitor to go out in a CPU-driven game, and letting players input their initials was my contribution to the culture.

 

"It’s a scary number of years ago. Where does time go?"

Where indeed? But Star Fire's not going anywhere. Apart from into your Spectrum.

​

AVAILABLE FROM 30TH NOVEMBER 2026!

 

Instructions

 

If it moves, shoot it.
If it doesn't move, shoot it anyway.

Blast motherships for a big bonus. Blast other motherships for extra lives.

​

Keys:

​

Movement: Cursor keys

Fire: 0

Speed controls: Z / X

Abort game: A