Repton 2 disassembly/reassembly

reminisce about classic bbc micro and acorn electron games here
Related forum: adventures


Post Reply
gfoot
Posts: 134
Joined: Tue Apr 14, 2020 9:05 pm
Contact:

Repton 2 disassembly/reassembly

Post by gfoot »

Hi all

I recently did a disassembly of Repton 2 using SteveF's excellent py8dis tool. It's on github here along with the Python script that drives py8dis, and a Makefile to rebuild it from source using Andre Fachat's xa assembler. https://github.com/gfoot/repton2disassembly

If you just want to browse the actual disassembled source, that's here: https://github.com/gfoot/repton2disasse ... /repton2.s

It'd be great to hear any suggestions for any other markup that would be useful, or especially if you spot any subtle references to addresses that I've missed.

If you want to reassemble this yourself you'll probably have to use a different assembler for now - I hackily added xa support to py8dis myself, but you're probably better off using BeebAsm or Acme which are already well-supported by py8dis.
User avatar
TobyLobster
Posts: 162
Joined: Sat Aug 31, 2019 7:58 am
Contact:

Re: Repton 2 disassembly/reassembly

Post by TobyLobster »

Looks good! It would be nice if the constants at the start of the disassembly were split up into separate areas for constants and memory locations.
I don't know how easy that would be - is it a py8dis feature?

EDIT: Wait, I'm going mad, it already is split up that way, except that screen_base is a memory location I guess.
gfoot
Posts: 134
Joined: Tue Apr 14, 2020 9:05 pm
Contact:

Re: Repton 2 disassembly/reassembly

Post by gfoot »

TobyLobster wrote:
Wed Sep 15, 2021 8:37 pm
Looks good! It would be nice if the constants at the start of the disassembly were split up into separate areas for constants and memory locations.
I don't know how easy that would be - is it a py8dis feature?

EDIT: Wait, I'm going mad, it already is split up that way, except that screen_base is a memory location I guess.
Yes, it's some py8dis feedback I'm holding back as I feel like I've flooded Steve enough for now. ;)

Right now py8dis sorts the constants by value, then puts the labels (addresses) afterwards in a separate section also sorted by value. It's confusing though because a lot of the constants are related and would make more sense just listed in the order I defined them.

screen_base is a weird one, I had to define it as a constant for technical reasons. It ought to be an address but that didn't work because of a literal edge case!
SteveF
Posts: 1107
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: Repton 2 disassembly/reassembly

Post by SteveF »

gfoot wrote:
Wed Sep 15, 2021 10:29 pm
Yes, it's some py8dis feedback I'm holding back as I feel like I've flooded Steve enough for now. ;)

Right now py8dis sorts the constants by value, then puts the labels (addresses) afterwards in a separate section also sorted by value. It's confusing though because a lot of the constants are related and would make more sense just listed in the order I defined them.
This is an easy one to fix. I think. :-) I've pushed this change to the "lazy" branch mentioned in the py8dis thread.

(Generally I sort stuff to make the output consistent across repeated disassemblies, but since the constants are generated exclusively by the control file and were already stored in a list there wasn't any real consistency benefit to the sort.)
gfoot wrote:
Wed Sep 15, 2021 10:29 pm
screen_base is a weird one, I had to define it as a constant for technical reasons. It ought to be an address but that didn't work because of a literal edge case!
I see your comment in repton2.py says this causes problems for xa but I'm not familiar enough with it to know what the problem is. Do you think this is something specific to xa or is it something which could/should be improved in py8dis?
gfoot
Posts: 134
Joined: Tue Apr 14, 2020 9:05 pm
Contact:

Re: Repton 2 disassembly/reassembly

Post by gfoot »

SteveF wrote:
Wed Sep 15, 2021 11:11 pm
gfoot wrote:
Wed Sep 15, 2021 10:29 pm
Yes, it's some py8dis feedback I'm holding back as I feel like I've flooded Steve enough for now. ;)

Right now py8dis sorts the constants by value, then puts the labels (addresses) afterwards in a separate section also sorted by value. It's confusing though because a lot of the constants are related and would make more sense just listed in the order I defined them.
This is an easy one to fix. I think. :-) I've pushed this change to the "lazy" branch mentioned in the py8dis thread.
Great, thanks! I haven't update yet but look forward to getting the chance to do that soon.
gfoot wrote:
Wed Sep 15, 2021 10:29 pm
screen_base is a weird one, I had to define it as a constant for technical reasons. It ought to be an address but that didn't work because of a literal edge case!
I see your comment in repton2.py says this causes problems for xa but I'm not familiar enough with it to know what the problem is. Do you think this is something specific to xa or is it something which could/should be improved in py8dis?
The issue I think was that py8dis produces approximately this sequence (after I've swapped the sections around):

Code: Select all

    .byt $10, $41, $04, $11, $44, $10, $41, $04             // 5ff0: .A..D.A.
    .byt $11, $44, $10, $21, $84, $10, $82, $d0             // 5ff8: .D.!....
screen_addr:

    * = $0380
// Referenced 1 time by $0d40
music_nextnotes:
    pha                                                     // 0380: 48
    tax                                                     // 0381: aa
i.e. screen_addr appears right at the end of the code block that ends at 6000. But I think xa treats it as labeling the following instruction, i.e. the pha, and gives it a value of 0380 as a result. I don't know whether it's an xa quirk or whether other assemblers would be affected too.

One fix would be to ensure that we don't output labels at the end of a block like that - declaring it with an explicit value at the start of the file, with the other labels, would work better. Another is to put "screen_addr = *" at that location, to explicitly set it to whatever * is. It is a weird edge case though, for sure.
SteveF
Posts: 1107
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: Repton 2 disassembly/reassembly

Post by SteveF »

Thanks, that makes sense. py8dis deliberately puts labels in those positions as it feels more natural to me when they are "end of a section of code" labels but I don't want it to be generating invalid output. I'll have a play around with xa once I've tidied up the support for different assembler output formats and see if I can stop this causing problems.
caspian
Posts: 65
Joined: Sat Nov 24, 2018 5:15 am
Contact:

Re: Repton 2 disassembly/reassembly

Post by caspian »

I noticed from your disassembly that 0bfc is a timer for repton getting bored, and 007e is a frame counter for animation:

frame_counter = $7e

repton_getting_bored_timer = $0bfc


I looked at the palette code a while back so I have some more detailed comments on that, it might be more than you want for the disassembly.

;0EC5 - palette data:
; 15: magenta trousers. 14: blue trousers. 16: cyan trousers. 36: cyan skin.
0EC5 15 ; magenta trousers
0EC6 14 ; blue trousers
0EC7 16 ; cyan trousers
0EC8 36 ; cyan skin

;0F9F - set palette entry from A - logical colour from high 4 bits, actual from low 4

2410 A9 00 LDA #$00 ; logical colour 0 (background), actual colour 0 (black), also 0 to clear repton getting bored timer.

; clear repton getting bored timer, and set special case palettes for levels 0 and 1, or set colour 0 to black for other screens
2412 20 82 33 JSR $3382

;2 bytes palette data
3380 14 11 ; 14: blue trousers (for screen 0). 11: red trousers (for screen 1)

;3382 - clear repton getting bored timer, and set special case palettes for levels 0 and 1, or set colour 0 to black for other screens
; caller will have set A to 0
Post Reply

Return to “8-bit acorn software: classic games”