Thrust Disassembly

reminisce about bbc micro & electron games like chuckie egg, repton, elite & exile

Related forum: adventures


SteveBagley
Posts: 128
Joined: Sun Mar 15, 2015 8:44 pm

Re: Thrust Disassembly

Postby SteveBagley » Tue Feb 16, 2016 2:57 pm

kieranhj wrote: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
Posts: 78
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: Thrust Disassembly

Postby tom_seddon » Fri Feb 19, 2016 6:58 pm

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.

User avatar
kieranhj
Posts: 484
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Thrust Disassembly

Postby kieranhj » Sat Feb 20, 2016 2:59 am

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..!
Attachments
thrust7.zip
Thrust disassembly first release
(45.35 KiB) Downloaded 74 times

User avatar
kieranhj
Posts: 484
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Thrust Disassembly

Postby kieranhj » Sat Feb 20, 2016 6:43 pm

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

Image

User avatar
davidb
Posts: 1826
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Thrust Disassembly

Postby davidb » Sat Feb 20, 2016 7:48 pm

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

User avatar
Wookie
Posts: 342
Joined: Sat Aug 27, 2005 10:06 am
Location: Lost in a fog of PSU capacitor smoke

Re: Thrust Disassembly

Postby Wookie » Sat Feb 20, 2016 8:03 pm

kieranhj wrote: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. =D>
cheers Wookie
Overclocked StrongARM RiscPC + Viewfinder
Overclocked Arm3 8MB A310 + vidc extender
BBC Master with Matchbox CoPro
BBC B+ 64K
My original Electron from 1985 with Slogger MasterRam/Turbo,AP1,AP2 rom, AP3+4 & New AP6

User avatar
SimonSideburns
Posts: 251
Joined: Mon Aug 26, 2013 8:09 pm
Location: Purbrook, Hampshire
Contact:

Re: Thrust Disassembly

Postby SimonSideburns » Sun Feb 21, 2016 3:13 pm

kieranhj wrote:Image


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?
I'm writing a game where you can change your character from a Wizard to a monkey to a cat.

Well, Imogen that!

User avatar
kieranhj
Posts: 484
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Thrust Disassembly

Postby kieranhj » Sun Feb 21, 2016 4:06 pm

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
Posts: 107
Joined: Sun Mar 19, 2006 11:58 am
Contact:

Re: Thrust Disassembly

Postby BeebInC » Fri Jun 03, 2016 7:00 pm

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

thrust.txt
(586.49 KiB) Downloaded 113 times

User avatar
kieranhj
Posts: 484
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Thrust Disassembly

Postby kieranhj » Fri Jun 03, 2016 7:31 pm

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!!

User avatar
kieranhj
Posts: 484
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Thrust Disassembly

Postby kieranhj » Fri Sep 16, 2016 1:30 pm

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

martinburchell
Posts: 1
Joined: Tue May 02, 2017 10:44 am

Re: Thrust Disassembly

Postby martinburchell » Tue May 02, 2017 1:38 pm

billcarr2005 wrote: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.

User avatar
KarateEd
Posts: 2919
Joined: Fri Sep 20, 2013 9:15 pm
Location: Squamish, BC, Canada

Re: Thrust Disassembly

Postby KarateEd » Wed May 03, 2017 10:51 pm

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


Return to “software: classic games”

Who is online

Users browsing this forum: No registered users and 3 guests