Repton 3 "Now" Screen H

[gfoot]

Word of warning -- looks like some of these discs need a Watford DFS, or you won't see all of the files present ...

Ah! That explains things. I looked through the code and started indexing the entry points, and there are clearly a lot missing, I was about to ask about it!

[gfoot]

Some observations then regarding this bug -

• The game time appears to be stored in the "watch" variable (2 bytes) and is decremented by an event handler (EVENT) defined in T.SCROL on line 750 - the decrement is on lines 860 and 870.
• The event handler doesn't check which event actually occured, but it enables event 4 (vsync I believe) in the INRUP routine (B in T.SCROL, line 670). It seems to only process every third vsync, so I guess it ticks just over 16 times per second.
• This would seem to technically mean that the rate of time decrease would be consistent in real-world time regardless of the speed the game is running - which seems odd, if the game is struggling due to having a lot of animation on the screen you'd run out of time quicker
• This code also hooks IRQ2V but uses that for music playback only I believe
• T.CTRLM handles the map and status screens, turning off the event when they're active and chaining back to INRUP to turn the event back on

This doesn't really explain why holding keys during the password screen or intro music would make the game run faster, but it does mean that if the game is indeed running faster then the player has an advantage.

[Diminished]

Has anyone actually built this yet? I get the impression it may have been circulating behind the Discord iron curtain for a little while.

I"m just wondering how a rebuilt binary would compare to the V2 retail -- it may not be identical.

[gfoot]

Has anyone actually built this yet? I get the impression it may have been circulating behind the Discord iron curtain for a little while.

I"m just wondering how a rebuilt binary would compare to the V2 retail -- it may not be identical.

I was going to try that soon, as I really need to try changing the code to understand it more. I also have some annotations to share if you're interested - I don't know the best way to share though. How far did you get with analyzing the disassembly before Matthew sent the source code?

I do have this index of all the relevant source files, trampoline entry points, and addresses: https://docs.google.com/spreadsheets/d/ ... r1Eb7FHMKQ

For actually understanding the code though I didn't use the spreadsheet much, I just grepped your detokenised version for symbol names to find which files referenced or defined them. I also made a python script to try to index it better, but it's hard to tell references accurately as there are no spaces after the opcodes.

[Diminished]

The last time I did any work on my own disassemblies was back in the "fungus thread", in which I was attempting to document the differences between versions. I haven't really looked at them since -- I have other things I should probably be doing right now, unfortunately. :/ (Somehow I ended up with three completely independent disassemblies of the same game, because apparently that's my idea of sane version control). If you wanted a textual listing of the work I did on R3 rather than my annoying WFDIS files, I might be able to produce those (I'd have to see if I still have the nasty scripts I wrote to extract ASCII output from my Citadel WFDIS sessions -- that process was a pain).

I know that for some of the 8271 reverse engineering, Chris and Rich made a collaborative Google Doc in order that they could both work on it together. I'm not sure how you'd feel about this approach but it might be worth considering something like that if you wanted to attract collaborators. You might end up with quite a lot of documents, though, and I suppose the source isn't officially GPLed or otherwise licensed yet, so I'm not sure how that works.

If you wanted to "project manage" further work on Matthew's source (whatever that means in this case) I doubt anybody would complain, but I just wondered whether any previous efforts had been made in this area yet. I imagine that some work of this nature would probably help in "greasing the wheels" of getting the thing onto GitHub.

[gfoot]

For sure, greasing wheels is always good

I've made a little script to actually build it, and after getting a few data files in the right places it seems to work fine - it produces the REPTON2, REPTON3, and REPTON4 files. I copied !BOOT and REPTON1 from source disc 5, and injected the PRELUDE scenario.

I haven't done any comparisons with other versions yet. There's a lot of dead space between chunks that will probably be different for sure though - it'll be a bit trickier to diff the actual code only.

But the really curious thing is that the timing issue I was debugging doesn't occur in this version at all! I have a very repeatable test case, easier than Now screen H - I time how long it takes (in-game time) to run across the line of boulders at the start of PREHIST screen A, from the wall on the right until just above the final boulder on the left (not all the way to the wall). Without pressing a key it's 36-37 ticks; with a key pressed on startup it's 33-34. But in the version I built from source, it's 33-34 every time, regardless of pressing additional keys.

Another test case is on PRELUDE screen A - going to the left of the level, running straight down, and timing in-game how many ticks it takes to go all the way to the top. That's 50-51 ticks in fast mode or 53-54 ticks in slow mode.

I'll try building the disc version in case that's different. I'm not sure how best to compare against the versions you've already looked at but it'll be interesting to figure out what is or is not different here.

[scarybeasts]

This doesn't really explain why holding keys during the password screen or intro music would make the game run faster, but it does mean that if the game is indeed running faster then the player has an advantage.

Ah, the possible link to "holding keys" is worth highlighting. There a rich tradition of games behaving screwy if a key is held as they load and start. For example:

- Camelot: viewtopic.php?t=16974
- Castle Quest: Can't find a stardot link; I thought I posted an analysis once. Hold down space bar to start the game on the title screen until the main game scrolls into view. Now, the keyboard won't work.
- Time Traveler fails to load at all if the keyboard buffer fills: viewtopic.php?p=326590#p326590


Cheers
Chris

[Diminished]

For sure, greasing wheels is always good

I've made a little script to actually build it, and after getting a few data files in the right places it seems to work fine - it produces the REPTON2, REPTON3, and REPTON4 files. I copied !BOOT and REPTON1 from source disc 5, and injected the PRELUDE scenario.

Very good!

I haven't done any comparisons with other versions yet. There's a lot of dead space between chunks that will probably be different for sure though - it'll be a bit trickier to diff the actual code only.

I already regret saying this, but if you can get me a dump of the 32K of RAM at the title screen, I could maybe take a look. I did write some awful script to do binary diffs of RAM dumps. I'd need the disc version though.

But the really curious thing is that the timing issue I was debugging doesn't occur in this version at all! I have a very repeatable test case, easier than Now screen H - I time how long it takes (in-game time) to run across the line of boulders at the start of PREHIST screen A, from the wall on the right until just above the final boulder on the left (not all the way to the wall). Without pressing a key it's 36-37 ticks; with a key pressed on startup it's 33-34. But in the version I built from source, it's 33-34 every time, regardless of pressing additional keys.

Ahh, now then. I wonder if the original phenomenon occurs on V1 only? One of the changes I found was that an OS event handler was replaced in V2 with a raw IRQ handler instead, and it wasn't obvious to me why. Maybe this is why.

[gfoot]

I already regret saying this, but if you can get me a dump of the 32K of RAM at the title screen, I could maybe take a look. I did write some awful script to do binary diffs of RAM dumps. I'd need the disc version though.

I'll see if I can figure out how to get files off an SSD image. Doing the comparison on the PC would probably be easier for sure.

On the other hand... I wrote a BASIC program to at least get an idea, nothing fancy just a byte-for-byte comparison. So it doesn't deal well with inserted bytes!

There are substantial differences between my home-built version (based on Matthew's "tape" disc 5) and Thru Time, and also between my home-built version and the original Repton 3 - but apart from the dead space between chunks, my home-built version is byte-for-byte identical to Life Of Repton and to Around The World! So it looks like the "tape" source Matthew provided is that slightly older version.

I'll have to try the "disc" source and see if it matches Thru Time. I guess it's possible there were later versions too, on compilations, with more bugfixes... I think you concluded before though that Thru Time was the last one.

Ahh, now then. I wonder if the original phenomenon occurs on V1 only? One of the changes I found was that an OS event handler was replaced in V2 with a raw IRQ handler instead, and it wasn't obvious to me why. Maybe this is why.

Ah I'll have to reread that thread, it does sound like that would be the change that's caused this! Again though note that it's v2 that's broken, so the change must have been made for some other reason and this was a side-effect.

[Diminished]

I'll see if I can figure out how to get files off an SSD image. Doing the comparison on the PC would probably be easier for sure.

I'd only need a 32K "live" RAM dump from e.g. beebjit -- I don't need the disc it was loaded from.

There are substantial differences between my home-built version (based on Matthew's "tape" disc 5) and Thru Time, and also between my home-built version and the original Repton 3 - but apart from the dead space between chunks, my home-built version is byte-for-byte identical to Life Of Repton and to Around The World! So it looks like the "tape" source Matthew provided is that slightly older version.

I'll have to try the "disc" source and see if it matches Thru Time. I guess it's possible there were later versions too, on compilations, with more bugfixes... I think you concluded before though that Thru Time was the last one.

Ahh, now then. I wonder if the original phenomenon occurs on V1 only? One of the changes I found was that an OS event handler was replaced in V2 with a raw IRQ handler instead, and it wasn't obvious to me why. Maybe this is why.

Ah I'll have to reread that thread, it does sound like that would be the change that's caused this! Again though note that it's v2 that's broken, so the change must have been made for some other reason and this was a side-effect.

OK. I'm totally baffled at this point because I concluded that there were only two versions of the binary code (on disc, at least), with vanilla V2 having an identical engine to all three expansion packs. No idea about tapes, other than to say that obviously disc versions and tape versions won't match. (Some of the "disc versions" floating around out there are actually tape-to-disc transfers.)

My brain hurts.

EDIT: FWIW, Chris posted definitive captures of three distinct original discs here. It's confusing because we used "v1", "v2" and "v3" there to refer to variants 1,2 and 3, whereas I'd previously used v1 and v2 to mean "binary code version 1 and binary code version 2". When I've talked about v1 and v2 here I've been talking about the binary code revisions rather than those disc variants arrrrgh help

[gfoot]

Oh cool, I'll check those out as well.

I also just ran my script to build the "disc" version, disc 3 of Matthew's upload by your numbering, and it too works fine, and this one does have the time bug. It also compares byte-for-byte identical to Thru Time, except for some of the dead space between chunks.

So to summarize, the source Matthew provided has two versions - the "tape" version on disc 5 matches STH's LifeOfRepton/AroundTheWorld discs, and the "disc" version on disc 3 matches STH's ThruTime disc. STH's Repton 3 disc is different to both. I'll update if I can get the three versions posted in the other thread compared against these as well.

[Diminished]

STH stuff is a bit suspect as far as version purity goes (cracked copies, tape-to-disc transfers, hacks of various sorts). A big collection of high-quality archival-quality HFE stuff is linked here, which is preferable to the Stairway stuff in these sorts of cases, although it has the disadvantage that a lot of those discs have protection systems that can't be represented by humble SSD images and so can't be loaded by the more humble emulators.

I think my "v1" and "v2" disassemblies were probably done off the Stairway disc version and the bbcmicro.co.uk disc version respectively, since I don't think we had the HQ captures at that time.

[gfoot]

Right - it's great to preserve things in a more authentic format but unfortunately I don't have a good way to read HFE images, and probably won't have time to find one.

bbcmicro.co.uk images also seem very different in odd kinds of ways - they have instructions etc, they don't include the editor, and they have sub-titles on the main menu in-game. Based on my (poor quality) memory of playing Life of Repton back in the day, I don't think it had those things.

I compared your text source dumps for disc 3 and disc 5, with interesting results. The EVENTV/IRQ2V change isn't here - both these versions hook both vectors, for very much the same purposes. There is a key difference though relating to the time bug that's the subject of this thread - in the disc 5 version, the keyboard interrupt gets disabled just before the jingle plays. But in the disc 3 version, it's disabled after the jingle instead. I'm not sure why this makes a difference later in the game, but it would be quite a coincidence if this wasn't at least the reason holding keys works around the bug.

There are also obvious changes like handling the disc interface better than the tape version does (things like setting the drive and directory properly).

It looks like in the disc 3 version there's a bugfix for the fact that pressing 'M' on a level that doesn't allow maps stops the music as a side effect.

Anyway, it's interesting to see all these differences, and having the source code definitely helps in understanding them!

[joachim]

Disabling the music also appears to work around the bug. However it's not obvious whether that's because the bug is directly related to interrupts (or the sound buffer) or just because the music is one more thing that slows the game down.

(Experiments performed with PREHIST Screen A on bbcmicro.co.uk. I'm able to reproduce gfoot's timings give or take one tick. But with music disabled it's 32–33 ticks no matter what I do on startup.)

[scarybeasts]

Right - it's great to preserve things in a more authentic format but unfortunately I don't have a good way to read HFE images, and probably won't have time to find one.

The beebjit emulator has decent support for loading, running and manipulating HFE images directly.


Cheers
Chris

[scarybeasts]

STH stuff is a bit suspect as far as version purity goes (cracked copies, tape-to-disc transfers, hacks of various sorts). A big collection of high-quality archival-quality HFE stuff is linked here, which is preferable to the Stairway stuff in these sorts of cases, although it has the disadvantage that a lot of those discs have protection systems that can't be represented by humble SSD images and so can't be loaded by the more humble emulators.

The archive linked above is the FSD->HFE archive, which is based on billcarr2005's extensive collection of discs. It's a great resource and many of the discs in this archive don't exist anywhere else.

For historical spelunking, I'd recommend the "accurate HFE" archive which is summarized in this spreadsheet here: https://docs.google.com/spreadsheets/d/ ... edit#gid=0

The accurate HFE archive has the following advantages:
- Discs are fingerprinted, so it's possible to identify exactly which disc version we're talking about, e.g. B323E0B1 instead of "v1".
- Both sides of double sided discs (e.g. 40/80) are captured.
- An explicit goal is to identify different variants of the same title, and archive all of them alongside each other.

In the case of Repton 3, we appear to have 4 variants, although I'd caution that not every variant necessarily represents a game play difference; many variants can be very superficial differences in sector ordering, DFS title, etc.

We also have the Repton 3 which is part of the Play It Again Sam 2 release.


Cheers
Chris

[gfoot]

For historical spelunking, I'd recommend the "accurate HFE" archive which is summarized in this spreadsheet here: https://docs.google.com/spreadsheets/d/ ... edit#gid=0

The accurate HFE archive has the following advantages:
- Discs are fingerprinted, so it's possible to identify exactly which disc version we're talking about, e.g. B323E0B1 instead of "v1".
- Both sides of double sided discs (e.g. 40/80) are captured.
- An explicit goal is to identify different variants of the same title, and archive all of them alongside each other.

Great, I might be able to help with that then at least for the Repton ones, as it's fairly easy now for me to compare different versions of the actual data files. So we'd be able to tell if they're the same in spite of loading menu changes.

In the case of Repton 3, we appear to have 4 variants, although I'd caution that not every variant necessarily represents a game play difference; many variants can be very superficial differences in sector ordering, DFS title, etc.

We also have the Repton 3 which is part of the Play It Again Sam 2 release.

For now I'm focusing on Repton Thru Time, which you've got one copy of as a standalone game. It has some very simple copy protection which just obfuscates the loading a bit, but with that bypassed I was able to save out the hidden data and it compares byte for byte identical with the data in the STH version - so that's good. The STH version appears closer to the 80 track HFE image, though it has an extra loader program for some reason, perhaps increased compatibility.

beebjit's debugger was very helpful for disassembling the copy-protection loader, by the way - nice one!

[scarybeasts]

For now I'm focusing on Repton Thru Time, which you've got one copy of as a standalone game. It has some very simple copy protection which just obfuscates the loading a bit, but with that bypassed I was able to save out the hidden data and it compares byte for byte identical with the data in the STH version - so that's good. The STH version appears closer to the 80 track HFE image, though it has an extra loader program for some reason, perhaps increased compatibility.

Cool. Looks like we've seen standalone Repton Thru Time twice, and the second one was the same fingerprint.

We also have Play It Again Sam 10, which features Repton Thru Time. Excepting !BOOT, the DFS files appear to have the same CRC32s though (-log disc:catalog in beebjit is useful for variant analysis, at least for those titles which put most of their data in DFS files).

beebjit's debugger was very helpful for disassembling the copy-protection loader, by the way - nice one!

Thanks! Given that historical spelunking appears to be on the rise, I'm thinking that making the debugger better could be one of the more useful contributions I can make. Suggestions welcomed.


Cheers
Chris

[gfoot]

We also have Play It Again Sam 10, which features Repton Thru Time. Excepting !BOOT, the DFS files appear to have the same CRC32s though (-log disc:catalog in beebjit is useful for variant analysis, at least for those titles which put most of their data in DFS files).

I extracted the hidden data from PIAS10 as well, and it compares identical - however the CRC32 is reported different. Does your CRC32 include more than just the data itself?

[scarybeasts]

We also have Play It Again Sam 10, which features Repton Thru Time. Excepting !BOOT, the DFS files appear to have the same CRC32s though (-log disc:catalog in beebjit is useful for variant analysis, at least for those titles which put most of their data in DFS files).

I extracted the hidden data from PIAS10 as well, and it compares identical - however the CRC32 is reported different. Does your CRC32 include more than just the data itself?

Are you referring to the overall disc CRC32? This is a lower level fingerprint that includes every byte of every sector, so a different DFS disc title will change it. I went into the disc CRC32 and reasons for variants in a previous ABUG talk here: https://www.youtube.com/watch?v=cKwet1Dv9LM


Cheers
Chris

[gfoot]

Are you referring to the overall disc CRC32? This is a lower level fingerprint that includes every byte of every sector, so a different DFS disc title will change it. I went into the disc CRC32 and reasons for variants in a previous ABUG talk here: https://www.youtube.com/watch?v=cKwet1Dv9LM

No, these:

Code: Select all

info:disc:file: P.REPTON2     001200 002F00 004600 076  (CRC32 BE9BCFEC)
info:disc:file: D.REPTON2     001200 002F00 004600 030  (CRC32 C525CB70)

P.REPTON2 is extracted from the PIAS10 disc, D.REPTON2 from the RTT disc, and I believe they are byte-for-byte identical files.

[scarybeasts]

Are you referring to the overall disc CRC32? This is a lower level fingerprint that includes every byte of every sector, so a different DFS disc title will change it. I went into the disc CRC32 and reasons for variants in a previous ABUG talk here: https://www.youtube.com/watch?v=cKwet1Dv9LM

No, these:

Code: Select all

info:disc:file: P.REPTON2     001200 002F00 004600 076  (CRC32 BE9BCFEC)
info:disc:file: D.REPTON2     001200 002F00 004600 030  (CRC32 C525CB70)

P.REPTON2 is extracted from the PIAS10 disc, D.REPTON2 from the RTT disc, and I believe they are byte-for-byte identical files.

I don't see a P.REPTON2 on either disc. Both discs have a D.REPTON2 but is't only 0x90 bytes long.

There's a chance that a v0.9.6 bug could be muddying the water (fixed after: https://github.com/scarybeasts/beebjit/ ... bcd7808ebc) but I don't see that it could be the whole story.

Here's the complete file list I see for both discs (with the fix above in use):

Repton_Thru_Time_D1S1_40T_HG3_199AD68A_1.hfe

Code: Select all

info:disc:DFS catalog, 18 files 800 sectors cycle count 22 title 'RTT         '
info:disc:file: D.REPTON2  L  FF0970 FF0970 000090 12F  (CRC32 14CD3708)
info:disc:file: $.FUTURE   L  0031E0 0031E0 002620 108  (CRC32 9F993939)
info:disc:file: $.NOW      L  0031E0 0031E0 002620 0E1  (CRC32 1EC80F43)
info:disc:file: $.VICTORI  L  0031E0 0031E0 002620 0BA  (CRC32 C7E7D3A4)
info:disc:file: $.EGYPT    L  0031E0 0031E0 002620 093  (CRC32 97BA0327)
info:disc:file: $.MV       L  FF1900 FF802B 0001FD 091  (CRC32 AF175C85)
info:disc:file: $.MASTER   L  FF0E10 FF0E10 0002B0 08E  (CRC32 E1AFEDAC)
info:disc:file: E.REPTON3  L  FF0400 FF0400 000400 08A  (CRC32 0D20EFBD)
info:disc:file: E.REPTON2  L  FF1200 FF2DD0 004600 044  (CRC32 0028DF10)
info:disc:file: E.REPTON1  L  FF2F00 FF2F00 002900 01B  (CRC32 0439FEE7)
info:disc:file: E.EDITOR   L  FF0E00 FF802B 0000E9 01A  (CRC32 AD5BC6A0)
info:disc:file: D.REPTON4  L  FF5810 FF6000 000860 011  (CRC32 D8B320AA)
info:disc:file: D.REPTON3  L  FF0400 FF0400 000400 00D  (CRC32 9613ECD3)
info:disc:file: D.REPTON1  L  FF0E00 FF802B 000153 00B  (CRC32 4301FDD2)
info:disc:file: $.NPIC     L  007C00 007C00 0001B6 009  (CRC32 844CA1D0)
info:disc:file: $.FONTS    L  FF0C00 FF0C00 000100 008  (CRC32 FB5AA2D8)
info:disc:file: $.MENU     L  FF0E00 FF802B 00045E 003  (CRC32 6F1F242E)
info:disc:file: $.!BOOT    L  00FFFF FFFFFF 000015 002  (CRC32 7F5648E1)

PIAS10_Repton_Thru_Time_D1S1_40T_90015718_1.hfe

Code: Select all

info:disc:DFS catalog, 18 files 800 sectors cycle count 23 title 'PIAS10'
info:disc:file: D.REPTON2  L  FF0970 FF0970 000090 12F  (CRC32 14CD3708)
info:disc:file: $.FUTURE   L  0031E0 0031E0 002620 108  (CRC32 9F993939)
info:disc:file: $.NOW      L  0031E0 0031E0 002620 0E1  (CRC32 1EC80F43)
info:disc:file: $.VICTORI  L  0031E0 0031E0 002620 0BA  (CRC32 C7E7D3A4)
info:disc:file: $.EGYPT    L  0031E0 0031E0 002620 093  (CRC32 97BA0327)
info:disc:file: $.MV       L  FF1900 FF802B 0001FD 091  (CRC32 AF175C85)
info:disc:file: $.MASTER   L  FF0E10 FF0E10 0002B0 08E  (CRC32 E1AFEDAC)
info:disc:file: E.REPTON3  L  FF0400 FF0400 000400 08A  (CRC32 0D20EFBD)
info:disc:file: E.REPTON2  L  FF1200 FF2DD0 004600 044  (CRC32 0028DF10)
info:disc:file: E.REPTON1  L  FF2F00 FF2F00 002900 01B  (CRC32 0439FEE7)
info:disc:file: E.EDITOR   L  FF0E00 FF802B 0000E9 01A  (CRC32 AD5BC6A0)
info:disc:file: D.REPTON4  L  FF5810 FF6000 000860 011  (CRC32 D8B320AA)
info:disc:file: D.REPTON3  L  FF0400 FF0400 000400 00D  (CRC32 9613ECD3)
info:disc:file: D.REPTON1  L  FF0E00 FF802B 000153 00B  (CRC32 4301FDD2)
info:disc:file: $.NPIC     L  007C00 007C00 0001B6 009  (CRC32 844CA1D0)
info:disc:file: $.FONTS    L  FF0C00 FF0C00 000100 008  (CRC32 FB5AA2D8)
info:disc:file: $.MENU     L  FF0E00 FF802B 00045E 003  (CRC32 6F1F242E)
info:disc:file: $.!BOOT    L  00FFFF FFFFFF 00004F 002  (CRC32 23C3DB15)

Cheers
Chris

[gfoot]

Ah sorry, I wasn't clear - what I've done is extract the hidden data from the disc and store it in a file, then I'm trying to use your crc32 to compare them.

So I extracted the hidden data from Repton Thru Time disc and stored it in a file called D.REPTON2, and extracted the data from the PIAS10 disc and stored it in a file called P.REPTON2, both on the same disc (my own, not one of the originals). The checksums are coming out different though even though the file content is the same.

In fact I've done this for all of the Repton 3 variants in that spreadsheet - PIAS2, 8, 9, 10, and the various HFEs for the different games. In each case I've loaded the data from the unused tracks on the disc, and overwritten D.REPTON2 with that data, undoing the copy protection. So they're still fairly authentic, they boot and run fine, but now all the data is in proper DFS files.

I then used the -log disc:catalog feature to compare them, but as above it looks like the CRC isn't always coming out the same even if the data is actually the same, so this isn't really effective. I have all this CRC data though if you're interested in seeing it.

So for example you already observed that RTT and PIAS10 appear the same apart from the !BOOT file being different - I can confirm that's also the case for the game code that's hidden on the disc outside of the DFS files. The two standalone versions of Life of Repton appear to be completely identical, including the hidden data on the disc being identical.

[scarybeasts]

Ah sorry, I wasn't clear - what I've done is extract the hidden data from the disc and store it in a file, then I'm trying to use your crc32 to compare them.

So I extracted the hidden data from Repton Thru Time disc and stored it in a file called D.REPTON2, and extracted the data from the PIAS10 disc and stored it in a file called P.REPTON2, both on the same disc (my own, not one of the originals). The checksums are coming out different though even though the file content is the same.

Oh, dear. Could you zip / attach the affected SSD with these two files on it?


Cheers
Chris

[gfoot]

I was able to use the terminal/headless mode to dump the contents of these files to files on the PC (which would have been pretty tedious without it!) and analyze them there. I truncated the files to just the code - from 1200 to 31E0 - as after 31E0 they tend to contain different scenario data.

Code: Select all

0958d92d866b7317e04fc1ab8d82e99a *Repton_3_D1S2_80T_HG3_9B93B07F_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *PIAS10_Repton_Thru_Time_D1S2_80T_0EA51A9D_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *PIAS2_Repton_3_D1S2_80T_HG3_FB2DF022_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *PIAS8_Repton_Around_the_World_in_40_Screens_D1S2_80T_HG3_CFB3E800_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *PIAS9_Life_of_Repton_D1S2_80T_6475B42D_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *Repton_3_D1S2_80T_HG3_32A353DD_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *Repton_3_D1S2_80T_HG3_8C958E9A_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *Repton_3_D1S2_80T_HG3_F0DC732F_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *Repton_Around_the_World_in_40_Screens_D1S2_80T_HG3_64834B97_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *Repton_Around_the_World_in_40_Screens_D1S2_80T_HG3_85923C1D_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *Repton_Around_the_World_in_40_Screens_D1S2_80T_HG3_BD8ADC30_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *Repton_Thru_Time_D1S2_80T_HG3_ABA748C2_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *The_Life_of_Repton_D1S2_80T_HG3_791C61A5_1.hfe.dat
3cec2a215ba1d1a35be349610656aec0 *The_Life_of_Repton_D1S2_80T_HG3_F2C1F989_1.hfe.dat

This correlates with differences in the D.REPTON3 and D.REPTON4 files - the first disc image listed above is different to the others in all three game code files. And it matches Diminished's observations of there being only two disc versions of the Repton 3 code released. So I guess there were no bugfixes as late as Thru Time - the bugs were fixed in the original Repton 3 releases, and the expansion packs just shipped new levels with that final code version.

The other differences I saw earlier, especially regarding this time/speed issue, must have been due to some of STH's SSD files being based on tape versions of the game rather than disc versions. There are subtle differences between the tape and disc files, beyond the disc ones having better support for discs, but they're not exactly bugfixes, just accidents. A case in point is that in some cases some lines of code have been swapped over when it makes no difference at all - e.g. the fungus fix was added in a slightly different place. It looks like it was manually applied to each version, and happened to go in a slightly different spot by accident.

As requested I've attached an SSD file which has D.REPTON2 and X.REPTON2 files on it, with identical content but different CRC32 readings.

[scarybeasts]

As requested I've attached an SSD file which has D.REPTON2 and X.REPTON2 files on it, with identical content but different CRC32 readings.

Seems to work ok on the latest master.

Code: Select all

info:disc:file: D.REPTON2     001200 002F00 004600 176  (CRC32 D9A0E51C)
info:disc:file: X.REPTON2     001200 002F00 004600 130  (CRC32 D9A0E51C)

Probably the v0.9.6 bug that was fixed later: https://github.com/scarybeasts/beebjit/ ... bcd7808ebc


Cheers
Chris

[picosonic]

Attached are the Repton 3 discs as recovered by Phil & Chris (cheers guys!) I have given permission for them to be made public at some point but with

Thanks for posting, I can now match up some of the source code I managed to recover from unused sector data blocks on the released disc to the B.MONST file.

I found it amusing to see some of the labels were named after drinks

.beers
.spirit
.tonic
.wines
.vodka
.water

lostcode.pdf

Code fragments recovered from Repton3 retail disc release

(30.56 KiB) Downloaded 44 times

[Diminished]

Thanks for posting, I can now match up some of the source code I managed to recover from unused sector data blocks on the released disc to the B.MONST file.

See also these few posts

[picosonic]

See also these few posts

Thanks for the link. The pdf I posted was from investigations I did i nApril 2016 when I was looking at it with Gerald Holdsworth of the Repton Resource Page.

There are many other games out there with snippets of code in between the data and in unused sectors. All very interesting.

[picosonic]

Thanks for the link. The pdf I posted was from investigations I did in April 2016 when I was looking at it with Gerald Holdsworth of the Repton Resource Page.

Further to this, these were my notes at the time ...

I found in the disk image a few tiny snippets of assembler source code which I've managed to match up to some of my disassembled code. See .pdf attached above.

These snippets were either in the files themselves (weird) or on the disk in-between the files in the unused space.

On the left is the disassembly from the game code (of a different Repton3 BBC disk game) with memory location, raw bytes, disassembly.

On the right are the matched up code snippets complete with BASIC line numbers. I've tried to match them up line for line.

There is a little section where I've put in some XXXX's where it doesn't match up, maybe the source is from an earlier version of the code.

It gives some insights into the memory locations used and function names anyhow. Interesting to see the spirits / beers / wines.

The first snippet is from between the files "MASTER" and "MV". The second longer snippet is from within "E.REPTON2".

I also found the following code snippet between the files "MENU" and "FONTS".

380 *COPY 01 E.EDITOR
385 *COPY 01 E.REPTON1
387 *COPY 01 E.
390 *COPY 01 E.REPTON3
395 *COPY 01 MASTER
397 *COPY 01 MV
400 *COPY 01 PRELUDE
405 *COPY 01 TOCCATA
410 *COPY 01 FINALE
430 *L.:0.RE