Thrust Disassembly

[SteveBagley]

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.

From my experience of the BeebEm source (I spent sometime playing around with it last year to get it running on OS X), it would be very easy to add the sort of functionality we've been discussing. The hardest part will be implementing a decent sparse array to hold the data ((2^16)^2 potentially requires 4 billion counters)!

Steve

[tom_seddon]

I spent about fifteen minutes writing out a justification of why you only needed 9 bits/cycle and could therefore just store events in a big buffer and analyse them later. (I used something like the buffer approach when working on model-b, and it worked out quite well, though I didn't do anything very clever with it - so this approach sprang immediately to mind.) But then I noticed one of the figures in my calculations, and remembered: everything these days is really fast. And that includes disks.

With this in mind, there might be no need for a table, and there might be no need for anything clever in the emulator. Just record what the CPU is doing each cycle, and save 26 bits: store access reason (read/write/instruction fetch - 2 bits), store the address accessed (16 bits), and store byte read or written (8 bits). This would produce 52,000,000 bits/sec, or ~6MBytes/sec. You could save to disk at that rate. Even my old laptop (5400rpm laptop hard drive...) could write to disk a lot faster than 6MBytes/sec.

(Which means there's plenty of scope for saving more data here. For example, you might want more bits to indicate memory access reason, so it's easy to distinguish opcode fetch from operand fetch. Maybe even dump register contents every cycle - or at least every time there's a new instruction fetched - as this would simplify analysing the data.)

Since this would just be saving the raw data, you'd need to write some kind of post-processor afterwards. But you could do that in Python/C#/etc., rather than having to write it all in C++ inside the emulator.

Things you could do with this data, that would be potentially useful when working on a disassembly:

* locate all instructions that read or wrote a particular address
* locate all instructions whose operands were written to after being executed, and which instruction overwrote them
* for any indexed/indirect instruction, find all effective addresses

If you dumped register contents you could also enumerate all register values for a particular instruction, which could be useful sometimes.

[kieranhj]

It's silly o'clock so I'm just going to leave this file here and write a proper post tomorrow. I think this proves that (a) I can't be trusted to go to bed at a reasonable hour when my wife is away and (b) I must be slightly crazy to have gone to all this trouble for a 30+ year old video game.

Should be formatted nicely in Notepad++, can't vouch for anything else. Should build under BeebAsm. Let me know what you think..!

[kieranhj]

So I've started a technical discussion on RS for those interested in the finer points of the assembly (!?) But in general it would be good to document the algorithms for the landscape / terrain, sprite plotting, physics simulation and the Bresenham line drawing (spelt incorrectly in the source - it was late last night.)

In terms of fun stuff for those that want to tinker:

• - All strings are in end_of_level_messages and in_game_messages_relocated (although watch out for matching up the labels)
  
  - you can change the particles generated when an object is destroyed in the table obj_type_explosion_particle but sadly not turn them into player bullets as these are special
  
  - object score values are in the table obj_type_score_value
  
  - should be easy to locate all sprite data (although how this is stored needs documenting)
  - ditto font data
  
  - door / switch logic is all hard coded per level - look in tick_door_logic
  
  - key controls are all defined as INKEY constants at the top of the file
  
  - terrain data for each level can be found in terrain_data_level_* - the format is quite opaque because very few bytes are used to iterate loops that control the x extents of the left & right walls across the possible y extent of the level - this needs documenting
  
  - all level object data (positions, types etc.) can be found in level_*_obj_pos - object type enums are defined at the top of the file
  
  - gravity value for each level is in the level_gravity_FRAC_table - I never realised before that gravity gets heavier with each level!
  
  - colour palette for each level can be found in level_landscape_colour and level_object_colour
  
  - the demo mode fakes keypresses on a timer to play the game automatically - you can change these in demo_keypress_bit_mask_table
  
  - sound envelopes can be found at envelope_* and the OSWORD 7 sound parameters at sound_data_*
  
  - high score table initial values & names are in high_score_table_relocated
  
  - MODE 7 instruction screen is found at mode_7_instructions
  
  - MODE 1 status bar (top two rows of screen) can be located at status_bar_bytes

Just fiddling the pod_sprite_data pointer.

[davidb]

Well done on getting so far with this! It looks like the game could be quite customisable.

[Wookie]

gravity value for each level is in the level_gravity_FRAC_table - I never realised before that gravity gets heavier with each level!

- the demo mode fakes keypresses on a timer to play the game automatically - you can change these in demo_keypress_bit_mask_table

Very interesting, I always thought this game was a bit special but reading through your dissasembly makes you realise it's really clever.

Like you I never realised the gravity increased with each level, a very nice touch, and I love the fact that demo mode is actually playing the game, very clever thinking by the programmer.

[SimonSideburns]

Anyone else notice a slight graphics glitch at the bottom right of the status bar at the top? Is this there in the normal game?

[kieranhj]

Good spot! I'm missing one zero byte at the end of the status_bar_bytes array. I accidentally removed this when I removed the duplicated bootstrap / relocation code that I had from the first disassembly. It's picking up the first LDA from RELOC_START. I will fix this in any updates. (Again, I blame the 3am post. )

[BeebInC]

For what its worth, I disassembled it a while ago...

thrust.txt

(586.49 KiB) Downloaded 359 times

[kieranhj]

I wish you'd told me before I started. Great minds think alike, and all that I guess. We can probably say Thrust is sufficiently documented in this thread now!!

[kieranhj]

Tom's Exile disassembly has reminded me to publish this in GitHub: https://github.com/kieranhj/thrust-disassembly

[martinburchell]

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"

Sorry to be late to the party but thanks for the reminder of my extra-curricular undergraduate projects and niche humour! I think I spent a year poring over dot-matrix printouts of Thrust code on long rolls of paper. Sorry the extra levels are too hard (I think I checked they could be completed in normal and reverse gravity).

I also wrote a hack for Snapper to allow other players to control the ghosts but I don't think that was ever released into the wild. I expect it would have been a bit one-sided.

[KarateEd]

The levels may be too hard but I think doable if one has the patience.

I'm not sure I have but I did test them out about 1/2 hour ago in Beebem and found the first 2 anyway quite playable, if not really difficult.

Very nice job in giving 'expert' levels to those that have completed Thrust original, btw, I've only been able to get part way through reverse gravity, something like the 3rd or 4th level in that group.

Ed......

[pjk]

Hi Martin, did you create the extra levels? I've tried playing it, but i only get to the second level and then that's it. I've written a PC clone of thrust and would like to discuss including your levels - or at least slightly easier versions thereof. Are you interested?

Sorry to be late to the party but thanks for the reminder of my extra-curricular undergraduate projects and niche humour! I think I spent a year poring over dot-matrix printouts of Thrust code on long rolls of paper. Sorry the extra levels are too hard (I think I checked they could be completed in normal and reverse gravity).

I also wrote a hack for Snapper to allow other players to control the ghosts but I don't think that was ever released into the wild. I expect it would have been a bit one-sided.

[martinburchell]

Hi there pjk

Sorry I don't check these forums very often. I'm quite easy to find on Google if you ignore the darts player with my name (-darts). I live in Cambridge and have IT day jobs.

Yes I created the extra levels. I don't know if the "source code" was included on the PD disc or not. I will have it all somewhere. From what I remember each extra level takes exactly the same amount of memory as the original. Anyway you are welcome to use them in your clone.

[Arcadian]

I also wrote a hack for Snapper to allow other players to control the ghosts but I don't think that was ever released into the wild. I expect it would have been a bit one-sided.

I've just noticed this! There's no chance you might still have a copy lying around, no?

[martinburchell]

I also wrote a hack for Snapper to allow other players to control the ghosts but I don't think that was ever released into the wild. I expect it would have been a bit one-sided.

I've just noticed this! There's no chance you might still have a copy lying around, no?

Yes almost certainly. Will try to put it up somewhere if I get a chance. I have competing demands on my time from
a 1-year-old and 4-year-old.

[Arcadian]

Goodness, I wasn't expecting a positive answer at all. That's superb news - please drop me a PM if you locate the disc. If you need someone to 'dump' it to SSD format I'm more than happy to help out if you're willing to post it!

Are there any other hacks you can remember making?

[martinburchell]

Goodness, I wasn't expecting a positive answer at all. That's superb news - please drop me a PM if you locate the disc. If you need someone to 'dump' it to SSD format I'm more than happy to help out if you're willing to post it!

Are there any other hacks you can remember making?

https://github.com/martinburchell/multi-player-snapper

The files are from a backup of an A5000 running !65Link

I can't remember any other hacks worth sharing. At a young age I realised I could change the envelopes and character set in Killer Gorilla. Like most people who did this kind of thing I was interested in getting cassette games on to disc.

[davidb]

This is incredibly cool!

The keys are as follows (left, right, up down):

Code: Select all

Snapper: V B J N
Green ghost: Z X F C
Cyan ghost: Q W 4 E
Magenta ghost: < > : /
Red ghost: P @ \ [

I'm guessing that \ is up for the red ghost because I can't make it work in B-Em, even when redefining keys.

[Arcadian]

Wow, what an ingenious hack! Love it! Thanks for sharing Martin!

I'm guessing that \ is up for the red ghost because I can't make it work in B-Em, even when redefining keys.

Yes \ is moving the red monster up for me (using BeebEm on Windows).

[martinburchell]

Wow, what an ingenious hack! Love it! Thanks for sharing Martin!

I'm guessing that \ is up for the red ghost because I can't make it work in B-Em, even when redefining keys.

Yes \ is moving the red monster up for me (using BeebEm on Windows).

Thanks for the kind words. I remember it being a fun project once I'd thought of the idea. The (sad) truth is I've never actually managed to try out the multi-player version with other people. I imagine there might be some practical considerations getting everyone round the keyboard. Now we need player 6 to move the fruit around.

[Michael Brown]

Hi Martin,
I would like to include the both Thrust and the Snapper Upgrade on one of my new Alternative discs.
Is this OK with you?
Also, When was the Snapper upgrade written?

regards,
Mick.

[martinburchell]

Hi Martin,
I would like to include the both Thrust and the Snapper Upgrade on one of my new Alternative discs.
Is this OK with you?
Also, When was the Snapper upgrade written?
regards,
Mick.

Hi Mick

Hi yes that's fine. Thrust Extra Missions appeared on a BBC PD disc in the early 1990s. I can't remember when I wrote the Snapper hack. I would guess some time between 1995 and 2000.

[vanekp]

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.)

I though it was https://github.com/stardot/beebem-windows there is also https://github.com/stardot/beebem but it has not been updated in a long time.

[lurkio]

Recently I've been casually playing a few games on a real Beeb with a gamepad (the SEGA Master System controller) via an adapter. (BITD I just stuck to using the keyboard because I had a Quickshot Pro joystick and it seemed a bit unwieldy and slow.)

For example, the joystick-enabled version of Chuckie Egg works well, and it got me wondering whether it would be possible to tweak another classic, Thrust, to support a joystick..?

(The Clares Joystick Utility which hacks joystick support into a subset of Beeb games doesn't seem to work with Thrust.)

The keyboard-handler code in Thrust is here:

https://github.com/kieranhj/thrust-disa ... 6502#L9113

Is anyone with the requisite skills interested in taking this on..?

Of course, it might well turn out that adding joystick support to Thrust is a terrible idea, because of the fine control that's required to pilot the extremely sensitive spacecraft, but, well, you don't know till you try. It might even be fun..!

[RobC]

How would you want the controls to work?

I guess you'd need to keep the test_inkey function as there are more keys used in the game than the joystick alone could replace?

[lurkio]

How would you want the controls to work?

I guess you'd need to keep the test_inkey function as there are more keys used in the game than the joystick alone could replace?

I was thinking that Up on the joystick/D-pad would activate thrust for your spaceship. (Down wouldn’t be mapped to anything.) Then you have left, right, and fire, as expected.

The rest of they keys aren’t actually used in gameplay per se, so they wouldn’t need to be mapped to the joystick/gamepad.

Oh, hang on! I forgot about Space for the shield! Argh! Not sure now. You could map Down to the shield, but then you wouldn’t be able to thrust and have the shield on at the same time! Oops. Perhaps this is a terrible idea after all..!?

[RobC]

How does your adapter work? I guess it would be possible to map the fire button for joystick 2 to shield (or thrust) but it wouldn't work with any other Beeb joysticks!

[tricky]

The mega drive joyous game pad adapters that I make have a switch to map a second button to the second fire or have one fire for each controller.
I think that some of the floppy analogue sticks also have both fire buttons, but you would need to add analogue support to balance out their poor response in a digital game.