Thrust Disassembly

[kieranhj]

For reasons that I haven't quite determined (perhaps in small tribute to Jeremy C. Smith) I have decided to disassemble and document my favourite game, Thrust. I thought I would share with you all the first piece of that project. Attached should be a source file that is buildable using BeebAsm on the command line:

Code: Select all

beebasm.exe -i thrust6.6502 -do thrust6.ssd -boot Thrust6 -v

It was created with the assistance of the awesome BeebDis by Phill Harvey-Smith (does anyone know if he is lurking on here BTW, or whether BeebDis has continued to be developed?)

[If you're wondering why it is called Thrust6, the original executable on the ssd is Thrust3. This is encrypted so I named the decrypted version Thrust4. This then has to be relocated in memory, Thrust5, then finally I had to patch the bootstrap to build and run correctly, so Thrust6.]

I continue to document the disassembly and will share the final results with you as soon as it's ready. I was always so beguiled by this game when I used to play it back in the day, so have a strange urge to find out exactly how it was written..!

[davidb]

Sounds like an interesting project.

I briefly looked at the idea of figuring out the format of the maps in the game one lazy Sunday afternoon, but it looked like it might take a bit longer than that.

[kieranhj]

Yeah, given that Jeremy and Peter went on to create the most technically sophisticated game ever made for the BBC Micro, I'm assuming they were both ninja programmers and therefore this is a non-trivial endeavour..!

[jms2]

I once did the same thing myself. .. I didn't figure out everything about the code, but it was fascinating and I discovered quite a few things about the game.

if I can find my notes, do you want them?

[Arcadian]

Phill Harvey-Smith (does anyone know if he is lurking on here BTW, or whether BeebDis has continued to be developed?)

Phill is a regular contributor here at StarDot and posts as 'Prime'.

[kieranhj]

I once did the same thing myself. .. I didn't figure out everything about the code, but it was fascinating and I discovered quite a few things about the game.

if I can find my notes, do you want them?

Yes, please! That would be very helpful.

[jms2]

Here they are - I did this back in 2003!

My approach was not to comment the disassembly (for some reason). Instead I wrote a separate file of notes which explains key points of how the code works.

I think I probably scribbled on a hard copy of the disassembly, and only wrote up some of my discoveries in the explanation file. I might be able to find the paper copy as well.

I hope it is helpful. This was the first game I disassembled and I found the process fascinating. Time consuming though.

[jms2]

Sounds like an interesting project.

I briefly looked at the idea of figuring out the format of the maps in the game one lazy Sunday afternoon, but it looked like it might take a bit longer than that.

I can shed some light on that.

The game maps are deceptively simple. The horizontal lines seen on the screen are not a stylistic feature, they are actually an artefact of how the screens are stored. Each line of the level comprises a left hand "solid part", a middle "gap part" and a right hand "solid part". So each line is just two bytes (or might be two words, I can't remember), giving the X co-ordinates of the start and end of the gap (or maybe the start of the gap followed by the width).

I really must find my marked up paper version!

[davidb]

The game maps are deceptively simple. The horizontal lines seen on the screen are not a stylistic feature, they are actually an artefact of how the screens are stored. Each line of the level comprises a left hand "solid part", a middle "gap part" and a right hand "solid part". So each line is just two bytes (or might be two words, I can't remember), giving the X co-ordinates of the start and end of the gap (or maybe the start of the gap followed by the width).

Ah, so simple! Thanks.

Maybe one day I'll write an editor for it.

[jms2]

The game maps are deceptively simple. The horizontal lines seen on the screen are not a stylistic feature, they are actually an artefact of how the screens are stored. Each line of the level comprises a letft hand "solid part", a middle "gap part" and a right hand "solid part". So each line is just two bytes (or might be two words, I can't remember), giving the X co-ordinates of the start and end of the gap (or maybe the start of the gap followed by the width).

Ah, so simple! Thanks.

Maybe one day I'll write an editor for it.

As a consequence of the way the levels are stored, you can never have a situation where the cave divides (except purely horizontally, and then you are limited by the max width which is presumably 256). Given this limitation, I doubt it would be possible to improve on the current levels very much. Also bear in mind that features such as the sliding doors are written as custom code for the relevant levels.

Taking these factors into account, I think your talents would be better employed elsewhere!

[davidb]

As a consequence of the way the levels are stored, you can never have a situation where the cave divides (except purely horizontally, and then you are limited by the max width which is presumably 256). Given this limitation, I doubt it would be possible to improve on the current levels very much. Also bear in mind that features such as the sliding doors are written as custom code for the relevant levels.

Taking these factors into account, I think your talents would be better employed elsewhere!

Thanks.

The next logical step was the scrolling map in Exile, I suppose. Thrust 2 looks like it was a very different game on the other platforms.

[kieranhj]

Here they are - I did this back in 2003!

My approach was not to comment the disassembly (for some reason). Instead I wrote a separate file of notes which explains key points of how the code works.

I think I probably scribbled on a hard copy of the disassembly, and only wrote up some of my discoveries in the explanation file. I might be able to find the paper copy as well.

I hope it is helpful. This was the first game I disassembled and I found the process fascinating. Time consuming though.

What a star, thank you! This is amazingly helpful and is going to save me a ton of time. I've commented the code pretty much through to the end of all the setup so having the full memory map and entry points for the main game routines is exceptionally useful. I wanted to make the game buildable so that anyone (starting with myself, I guess) could then make changes to and experiment with the code.

A level editor would be interesting or perhaps just a simple way of converting bitmaps to level data for instance. Anyway, I will carry on down the rabbit hole of disassembly and we can have a discussion about what might be fun to do with it. What could Thrust 1.5 look like?

[jms2]

Pleased to be of help!

My best suggestion would be to use sideways ram perhaps to create new levels. Other than that, I would say that Thrust is more or less perfect.

[Rich Talbot-Watkins]

Interesting stuff! Never looked deeply into how Thrust works. One thing that surprised me is that it stores all the graphics as bitmaps rather than drawing them as line segments (as their design so wants you to believe!). I guess that's how it was able to render so smoothly. Very nice game, and interesting to see which aspects of it found their way to Exile later on (the scrolling mechanism, the physics simulation).

Just to add, it looks like there are a few blocks of code in your disassembly which are still rendered as EQUBs - e.g. 3A9F looks like code to me (from what I can disassemble "by eye", it looks like it's reading the keyboard directly from the hardware). Also 2BC6 and 3B40 look like code too (no idea what they do though).

[kieranhj]

Thanks Rich. You have a good eye - I found the keyboard reading routine last night and you're right it is still EQUB's. As the data blocks are interleaved through a lot of the code, I had to give BeebDis directives as to what to treat as data blocks rather than wade through a massive chunk of illegal opcodes. I definitely missed a few spots.

I tend to agree with jms2 that Thrust is more or less perfect, hence being my favourite game.

Anyway, I'm making good progress but now the working week is getting in the way. More updates soon.

[tom_seddon]

Looking forward to seeing more of this. I always wondered what magic (or, perhaps, just trickery...) it did to scroll the screen so nicely, since it didn't appear to be using hardware scrolling.

[kieranhj]

I haven't forgotten about this but has turned out to be substantially more work than I thought. (Who is surprised? Going through 9000+ lines of assembler and data has proven to be fairly time consuming plus I have a day job to do (it does make my train commute pass pretty quickly though.)

I have made substantial progress however - I've located every subsystem, isolated and named every function, identified and named every variable (even if I don't know exactly what all of them do yet) of which there are well over 100 (most of zero page), identified every pointer table and data set - so it is possible to compile your own levels. Oh yeah, there was a load of self-modifying code to isolate and document - par for the course when squeezing the most of out the humble Beeb, I should have realised.

I always thought of Thrust as a such a wonderful and elegant game, even more so now after attempting to "become one" with the code. Perhaps because the game itself is so simple and "sparse" in design, certainly compared with something like Exile, I naively thought it wouldn't be that epic but it really does fill all of memory and is finely tuned to make the most of the Beeb. There is not much fat here at all.

I reckon I must have clocked up at least 60 hours on this so far and TBH I'm looking forward to writing some of my own code for a change. The source is a bit of a mess at the moment but I think what I'll do is try to clean up what I've got ASAP and upload here. That was we can use the collective brainpower of the *. community to really reverse engineer & (ideally) document how all of the different subsystems work.

In answer to your question, no the screen isn't hardware scrolled but redrawn as required by keeping track of the left & right extents of each line of terrain that is visible within the window. If you notice there is a limitation on the angles of the terrain - they only slope by 4 pixels (1 byte) per line. A lot of the player maths is also interesting as x coordinates are 8.8 fixed-point whilst the y coordinates are 10.8 fixed-point (levels are deep not wide.)

Maybe I should have chosen something simpler, like Chuckie Egg, to start with.

[davidb]

Sounds like an impressive feat - both the original game and your disassembly of it!

You'll be doing the Electron version next, I hope. Then Kees can port the game to the Atom.

[billcarr2005]

Found the following - on BBC-PD disk 134, written by Martin Burchell in 1992 which changes the 6 original levels (in the file "ThrExt"), so added it onto the original disk and made sure it loads up OK. Modified "ThrLoad" because it used to give the option to load from cassette or PIAS versions.

Here's a message contained with "TXMCode"

Code: Select all

Thrust Extra Missions written by Martin Burchell (C) 1992.
Original Thrust game by Jeremy C. Smith.
David Braben allegedly says "Play Thrust Extra Missions today - It's much better than Zarch, Elite or Exile!"
Where is David Braben these days anyway?
What ever happened to the Elite sequel?
If you have enjoyed playing these extra missions or think a dog could do better why not write and tell me at 100 Pinkerton Road, Basingstoke (someone has to live there), RG22 6RN.
Perhaps you would like to see a mission designer.
If there is enough response (and I gain sufficient enthusiasm) one will be written!
Hi to everyone who knows or knew me (note the originality - listing a load of people I may have some loose connection with) including Andy "Saloon Cars" Swain - soon to defect to Microprose, Diluk Dias of "The Yorkshire Boys" (I bet they're hard), Myles Rix, Joe "JVM modest graphic designer" Myers (both last seen at QMC), Edward Ramsden, Ben Corby, Chris Milward, Nick Lewis, Richard "say it" Louder, Peter Robinson, everyone at The Centre of Excellence and Jeremy "C" Smith who I don't know but thought I'd include by way of apology - I mean how would you like to have your "highly addictive yet simple and fun to play" (or something like that) game totally ruined by some half-crazed undergraduate with nothing better to do?
Where are all the great BBC games writers today?
Have they found respectable careers?
Answers on a postcard........................................

Welcome to this month's Beeb User.
Later in this issue some reviews of games that are useless but we've still awarded them 80% to please the advertisers.
But first it seems that some people still haven't got the hang of our checksums so here again is our blindingly obvious guide to using them.
First of all make sure you are in the same room as your computer and you are in such a position as to reach your keyboard.
Now turn your micro ON (that's the large switch at the back of your machine)...

PROBLEMS PATRONISED
Q.  I am working on a GCSE project which involves controlling motors from a BBC model B.  Can you show me the circuit diagram I will need?
A.  I can't see why I have to tell you what to do - after all it's your project isn't it?  Instead I'm going to refer you to one of my articles which is now about five years old so you won't be able to order it from our back issues service.

Q.  I own a BBC computer and it doesn't work.  Can you please tell me what's wrong?
A.  Well first of all I'm going to patronise you for being so vague.  I mean how am I supposed to know if you tell me "it doesn't work"?

Next I shall use some jargon you won't understand to sound very knowledgable.

LETTERS PAGE.  * My eight-year-old son bought a tape from our computer game shop which wouldn't load.  We took it back but they said they wouldn't replace it, showing us the large notices in the store reminding customers of this.  I am very angry because now we have a useless tape and a bawling kid...  * I thought I'd let you have some "hints for beginners" which appear every year on the letters page but you seem to publish them despite this.  In fact any old mug could look them up in the User Guide.  @ Well done.  I'm sure these tips for beginners will be very useful.  Have `10.  * I'd just like to give a bit of free advertising to the supplier who was very helpful when my machine recently failed to work.  Words can not describe how grateful I am.  Lick, lick.  Slurp, slurp etc.  * I still don't understand the checksums.  Can you help?

[MartinB]

Ha ha, brilliant sense of humour

Always nice to see people not taking computing too seriously.....

[Wookie]

Found the following - on BBC-PD disk 134, written by Martin Burchell in 1992

Nice One

I think I need to practice the original gane as these new levels are seriously hard.

Thanks for posting it.

[streaks]

Sheesh.. Everyone in this forum is brainy. What do y'all do for a living?

[kieranhj]

Cool! I will definitely take a look. I still haven't forgotten about posting the disassembly. Work has become painfully busy of late but I will get something out in the next couple of weeks. It won't be complete but I'm hoping you lot can crowd-source the rest of the reverse engineering with me.

[jms2]

Hey Kieran,

I had a bit of a tidy up in the attic the other day and found my hand-amended Thrust disassembly. I don't know whether my last amendments made it into the Word file, but my guess is that they did not. There's quite a bit of scribbling on there, would you like me to scan it all in and send it to you?

[kieranhj]

Yes please! All information is helpful. I went back to it last night after a month off (to write some of my own code for a change) and the scope of it is daunting. Currently tidying everything up with consistent naming and commenting to make it easier for others to digest and help document the final pieces in crowd form.

[sirmorris]

One thing I always think about in cases like this is a 'documenting emulator' - an emulation which logs addresses of executed instructions, data reads and writes. At its simplest you take an array of 64k bytes and set a bit to mark each of those events. Dump it out at the end and you have - pretty much - an accurate model of the memory usage.

Obv. I've never done this but if you have an open source emulator I don't imagine the work needed to implement this would be prohibitive.

C

[ash73]

One thing that surprised me is that it stores all the graphics as bitmaps rather than drawing them as line segments (as their design so wants you to believe!)

I read somewhere Elite on the NES was implemented like that, too.

[SteveBagley]

One thing I always think about in cases like this is a 'documenting emulator' - an emulation which logs addresses of executed instructions, data reads and writes. At its simplest you take an array of 64k bytes and set a bit to mark each of those events. Dump it out at the end and you have - pretty much - an accurate model of the memory usage.

I did something like this with an ARM simulator to mark student coursework. I found if you make it a 2D array with the row being the address read/written and the column being the PC of the instruction performing the read/write then you can tell a heck of a lot about the way the program works from the patterns of access. You'd very quickly be able to tell which routines accessed the screen etc. just by drawing the array as a picture.

Steve

[sirmorris]

Nice!

[kieranhj]

On the topic of emulators. There is an effort to put BeebEm into GitHub so it can continue to be developed (see thread in the Emulators board) - I'm sure it would be possible to add the self-documenting capabilty into that, or on a fork. The B-Em source is also readily available although I had some trouble getting it built with the latest version of the dependent libraries (Allegro, OpenAL.)

Matt Godbolt has also posited adding some sort of source disassembly side-band functionality to jsbeeb. This could be particularly useful for the OS sources when stepping through in the debugger etc. Would be great to be able to add game sources along side this, like Exile or Thrust etc.

I have set myself a deadline of this weekend to tidy up what I have and share it with you all. Won't be perfect but hopefully enough for everyone to dig through the various routines and properly document how each of the algorithms work.