Le Secret Du Tombeau (translation project)

[Devlin]

I've been wanting to tackle a little amstrad translation project of Le Secret Du Tombeau, which was never released in English.

https://www.cpc-power.com/index.php?page=detail&num=1898

I started with the copy I had to hand from CPC-Power - the french cracked version on disk, but it appears to have some issues in that:
> The attract-demo is completely missing from the cracked version.
> Saving the game hard crashes the system
> Loading the game is impossible because of above.
The other issue I had was that I couldn't find where the mode 1 loading screen was and editable in a way that I could translate the loading page too.
I can do the strings just fine, but I don't want to do the translation to a cracked version that's broken and missing things.

The ideal situation is that I'd like to have a fully cracked version that I can extract to raw files (for usifac2/m4 use) as well for easier editing on PC.
The original disk dump appears to have a bunch of data near the end of the disk that is read while loading, but doesn't appear to have a file associated with it, so without editing the disk image directly which is its own unique headache.

I'd like to make some small edits to the game controls, such as changing the french o/n keys to y/n as per they would be in English.

Would anyone be willing to help me "fix" the game into a mass-storage friendly format?

[Jean-Marie]

The cracked version on CPCPower is pretty botched indeed. Here is a proper one.
The protection in SDT.bin checks for a GAP3 value of F7h on some sector on track 39 (standard value is 4Eh).
I just removed the conditional jump to make the test always valid. And I formatted track 39 with regular sectors.

Code Select Expand

org &19a3
;;jr nz,&19de
nop:nop

[Devlin]

The cracked version on CPCPower is pretty botched indeed. Here is a proper one.
The protection in SDT.bin checks for a GAP3 value of F7h on some sector on track 39 (standard value is 4Eh).
I just removed the conditional jump to make the test always valid. And I formatted track 39 with regular sectors.

Code Select Expand

org &19a3
;;jr nz,&19de
nop:nop

Wonderful! Most of the game data is in a block(?) of data not actually marked as a file around track 36 on the disk?. Is it possible to turn that block of data into a file and tell the game to load that file instead of an arbitrary place on the disk? That would make it both mass storage friendly, and much easier for me to edit instead of manually hacking that one chunk of data on the disk.

You cannot view this attachment.
Here's the disk layout - you can see at the end of the disk where the not-file data is.

[Nich]

Le Secret du Tombeau was one of the many, many entries on my list of cracked games that need to be re-examined. Unfortunately I don't have the time to look at it at the moment, and I won't get a chance to do so for another 6 or 7 weeks - but I'll try to look at it again at some point.

[Jean-Marie]

You're right : those tracks are read by the program using the BIOS Read sector function.
It might be tricky to replace those calls with the standard Firmware function!

[Devlin]

The broken crack managed it, but it was a copy from cassette using Amscopy 2 (the files have an amscopy header)

[dirtybb]

Hi

Perhaps you can have a look at the velus compactage version :
https://www.velus.be/cpc-2982.html

[Devlin]

Hi

Perhaps you can have a look at the velus compactage version :
https://www.velus.be/cpc-2982.html

It looks like it's been trained and compressed, I wouldn't be able to get at the files to translate it. Once the translation is done I can pass it on to them to do the english version too if they so desire.

[Jean-Marie]

I have an idea, but it's a bit tedious cause you'll have to create one file for each sector of tracks 36/37/38, that is 22 files of 512 bytes (actually 1 Kb on disc).
You'll need to give them a name like T24SC1, for track 24h(36) sector C1h.
The files could be loaded with the following patch of 34 bytes long:

Code Select Expand

ORG &BE80
Filename: DB "T2?SC?"
@Loader:
push hl      ;;save hl=buffer address
;;retrieve track number
ld a,d
add &10     ;;sub &20:add &30
ld hl,Filename+2
ld (hl),a
;;retrieve sector number
ld a,c
sub &90      ;;sub &C0:add &30
ld l,Filename+5 AND 255
ld (hl),a
;;Open & read the file
ld b,6           ;;length of Filename
ld l,Filename AND 255
call &BC77     ;;Open file
pop hl          ;;hl=buffer address
call &BC83     ;;Read file
jp &BC7A     ;;Close file & return
Then, you can just replace the Far Call to BIOS-Read sector with a call @Loader.
Before:

Code Select Expand

org &9435
push bc
ld de,&2400
ld hl,(&00e3)
push hl
rst &18
db &a7,&00
pop hl
...
After:

Code Select Expand

org &9435
push bc
ld de,&2400
ld hl,(&00e3)
push hl
call @Loader
pop hl
...
Using Winape, you can copy/paste a sector content to Excel or notepad.
The problem is that memory looks very tight, even for a small patch like this.
Even the BE80h area seems to be overwritten by the stack!
You could try using the VRAM at FFD0h maybe.

[Devlin]

I have an idea, but it's a bit tedious cause you'll have to create one file for each sector of tracks 36/37/38, that is 22 files of 512 bytes (actually 1 Kb on disc).
You'll need to give them a name like T24SC1, for track 24h(36) sector C1h.
The files could be loaded with the following patch of 34 bytes long:

Code Select Expand

ORG &BE80
Filename: DB "T2?SC?"
@Loader:
push hl      ;;save hl=buffer address
;;retrieve track number
ld a,d
add &10     ;;sub &20:add &30
ld hl,Filename+2
ld (hl),a
;;retrieve sector number
ld a,c
sub &90      ;;sub &C0:add &30
ld l,Filename+5 AND 255
ld (hl),a
;;Open & read the file
ld b,6           ;;length of Filename
ld l,Filename AND 255
call &BC77     ;;Open file
pop hl          ;;hl=buffer address
call &BC83     ;;Read file
jp &BC7A     ;;Close file & return
Then, you can just replace the Far Call to BIOS-Read sector with a call @Loader.
Before:

Code Select Expand

org &9435
push bc
ld de,&2400
ld hl,(&00e3)
push hl
rst &18
db &a7,&00
pop hl
...
After:

Code Select Expand

org &9435
push bc
ld de,&2400
ld hl,(&00e3)
push hl
call @Loader
pop hl
...
Using Winape, you can copy/paste a sector content to Excel or notepad.
The problem is that memory looks very tight, even for a small patch like this.
Even the BE80h area seems to be overwritten by the stack!
You could try using the VRAM at FFD0h maybe.

I've had a chance to examine the Velus crack a bit further, and it's the same as the "bad" tape crack - locks up completely when loading/saving the game.

I was thinking a somewhat more "out of the box" method:

Could it be possible to sort-of "merge" the disk/tape version, to make a sort of hybrid version? It'd come at the cost of the attract screen, but I think trying to get it playable with at least the core features working (and saves me editing a disk image directly and risking corruption because of sector boundaries and such)

My thinking is this (please feel free to call me out on my faulty brainworks):

• Locate and extract all the code that handles loading and saving of the game from the disk version
• Locate and replace *tape version's* load/save code with the disk routines
• test and possibly cry/cheer

At least, in this case I'd have a nice clean base to work with (and load/save is always useful for this kind of translation work), and if a future crack comes out that can "fix" the disk version into a translation friendly state, I'd be happy to revisit and go for a 1.1 based off the disk version.

Still super appreciating all the suggestions and help, though. I can use a hex editor and i've figured out a few little things related to the game's internal text system but I don't know how to Z80ASM so the advanced stuff is really bad.

[Jean-Marie]

Yeah, it sounds like a plan. I'll have a closer look at the tape version soon, to see if the save/load code can be changed.
I made some tests to put my theory in practice, and replaced the BIOS/read far calls with the Firmware Read function, but that won't work because at some point, some Data is loaded at offset A690h, which is the AMSDOS Data area used by this very function 🫤 That explains why they had to resort to direct sectors reading. 
These are the changes I made and the DSK, for information :

Code Select Expand

;;load patch in VRAM from loader SDT.BIN
org &15db
call &bb06
jp @InstallPatch          ;;jp &7e66

ORG &1A00
@InstallPatch:
ld hl,Patch
ld de,&FFD0
ld bc,34
ldir
jp &7E66        ;;postchaining
Patch:
db &54,&32,&3f,&53,&43,&3f,&e5,&7a
db &c6,&10,&21,&d2,&ff,&77,&79,&d6
db &90,&2e,&d5,&77,&06,&06,&2e,&d0
db &cd,&77,&bc,&e1,&cd,&83,&bc,&c3
db &7a,&bc

;;Replace Far Calls to BIOS - Read sector
ORG &7EAC file SDT.5
call &FFD6

ORG &943D file SDT.4
call &FFD6
By the way, I found the code to replace the prompt (O)ui/(N)on with (Y)es. It's located in SDT.4 file:

Code Select Expand

;;change keyboard O/N with Y/N
org &a1ae
la1ae:
call &92cb     ;;scan keyboard
;;cp &4f          ;;test O key
cp &59          ;;test Y key
jp z,&7e69
cp &4e         ;;test N key
jr nz,la1ae
rst 0

org &a17e
la17e:
call &92cb
;;cp &4f          ;;test O key
cp &59          ;;test Y key
jr nz,la186
rst 0
la186:
cp &4e
jr nz,la17e

[Devlin]

Yeah, it sounds like a plan. I'll have a closer look at the tape version soon, to see if the save/load code can be changed.
I made some tests to put my theory in practice, and replaced the BIOS/read far calls with the Firmware Read function, but that won't work because at some point, some Data is loaded at offset A690h, which is the AMSDOS Data area used by this very function 🫤 That explains why they had to resort to direct sectors reading.
These are the changes I made and the DSK, for information :

[snip]

Ooh, that'll be really useful. Is that for every y/n prompt, or just one?

At the minute i'm working on just getting the strings translated of the cracked tape>disk conversion as it's the easiest way to go at the minute.
As for hacking - I think for the minute it's best to just get that cracked version at least loading and saving properly, as well as key prompts being changed to their english equivalents - then I can translate as I go more effectively.

If I had that much, I'd be super happy, and once it's done, looking further into hacking (I'd really love to translate the first loading screen, too!)

I've started making a document as well to gather my findings, and keep track of what I've done and knowledge i've put together from my hex editing and examination of the files
https://docs.google.com/document/d/1zfF-XnfZYAT7Wp--Nm54xr2JOAZYQPnqrcy2fi5EhOc/edit?usp=sharing

[Jean-Marie]

Ooh, that'll be really useful. Is that for every y/n prompt, or just one?

The first one (A1AEh) is related to the game over. The second one (A17Eh) is when you complete the game, and when you give up. I'm not sure if I got them all. I saw a prompt in the text data asking you to pull a lever (High, Middle, Low), so I'll have to tackle this one too.
I tried to swap the Save/Load code on the tape version, but it's still crashing when function BC98 (CAS OUT DIRECT) is executed, and I'm clueless. The same function works seamlessly on the Disk version.
Another solution would be to store all the sectors in the extra 64 RAM, but that would let down 464 users 🫤

[Jean-Marie]

I've worked out a version where the sectors are stored in a single continuous file stored in extra-ram (bank 7). All calls to BIOS-Read sector are modified with a call to a patch in VRAM which reads the sector data from extra-ram.

Code Select Expand

ORG &FFD0
@Loader:
push bc:push de
push hl      ;;save hl=buffer address
;;Offset in SDT.6=(((T-24h)*9)+(S-C1h))*512
ld a,d          ;;a=track
sub &24
ld l,a
add a
add a
add a
add l
ld l,a       ;;l=9a
ld a,c          ;;a=sector
sub &C1
add l
add a
add &C0
ld h,a
ld l,0
pop de
ld bc,&7FC1
di
out (c),c
ld bc,512
ldir
ld bc,&7FC0
out (c),c
ei
pop de:pop bc
cp a       ;;return with ZF & CF set
scf
ret
The advantage is that all sectors are now stored continuously in a single file (SDT.6) of 11 Kb, which should make your translation work easier.
I also patched the Lever prompt (H/M/B) with (H/M/L).
It needs to be tested, cause I'm pretty bad with this game. I keep on dying after a few seconds!

[Devlin]

Oh, that's amazing.

I noticed a difference between the tape and disk versions too.
In the tape version, to save on storage space, control bytes (from my tinkerings, it's like 0x8* where * is the number of spaces to inject) are used instead of everything being padded with 0x20(spaces)

Text boxes are 25 chars x4, for 100 characters - Things like the air counter and trap timer are in fixed positions (which seems to be 8th and 9th characters on the third row, for a two character timer), but I can creatively edit around that.

I have a feeling that any modifications the game doesn't like will result in an immediate reset, so I think that it'll be okay.

[Devlin]

a wee sneak of what's going on so far.

[Jean-Marie]

The loading screen is stored in file SDT.0, under a compressed form (RLE).
I replaced the RLE unpacker code with the ZX0 one.
You'll just need to:

• save a 16Kb image
• compress it with ZX0 (without the header!)
• add an Amsdos header to the compressed file
• rename it SDT.0 and store it on the DSK

Or just send me the picture file.
You'll need a graphic artist; I can't help you with that

[Devlin]

The loading screen is stored in file SDT.0, under a compressed form (RLE).
I replaced the RLE unpacker code with the ZX0 one.
You'll just need to:

• save a 16Kb image
• compress it with ZX0 (without the header!)
• add an Amsdos header to the compressed file
• rename it SDT.0 and store it on the DSK

Or just send me the picture file.
You'll need a graphic artist; I can't help you with that

I can do graphics just fine. Can I shoot you a 320x200 PNG to convert for me?

[Devlin]

The loading screen is stored in file SDT.0, under a compressed form (RLE).
I replaced the RLE unpacker code with the ZX0 one.
You'll just need to:

• save a 16Kb image
• compress it with ZX0 (without the header!)
• add an Amsdos header to the compressed file
• rename it SDT.0 and store it on the DSK

Or just send me the picture file.
You'll need a graphic artist; I can't help you with that

I can do graphics just fine. Can I shoot you a 320x200 PNG to convert for me?

I've attached the PNG in question: Are the credits okay for you?

[Jean-Marie]

Waoo, it looks perfect. Bravo!  I'll try to convert it with ConvimgCPC. 

[Jean-Marie]

Lookin' good !

[Devlin]

Top shelf stuff there! I'm doing a ton of testing but I'm getting there, I think!

[cwpab]

This game is very intriguing.

I saw some screenshots in Spanish, so apparently this was translated over here.

And the gameplay style seems more or less unique... But it only got a 6.5 from French magazines at the time, and CPC Game Reviews gives it a 6.

BUT users in CPC Power give it very high scores... What's going on? Is it a very good game or only a decent one?

[Devlin]

This game is very intriguing.

I saw some screenshots in Spanish, so apparently this was translated over here.

And the gameplay style seems more or less unique... But it only got a 6.5 from French magazines at the time, and CPC Game Reviews gives it a 6.

BUT users in CPC Power give it very high scores... What's going on? Is it a very good game or only a decent one?

From what I've played of it, it is very fun, and an excellent little adventure game that's quite tough, but pretty much impossible to figure out the solution without knowledge of French (or Spanish), and I wanted to play it without having to engage in a ton of extra thinking translating it in my head.

And since it never got an English release, I decided I'd do a bit of translation as a little project for funsies.

At this stage, there's only a few more strings of text to convert, and then I can call it "done".

[Devlin]

As part of my hacking efforts, I removed all the walls to help me get about the map and test things out.

This happens far too often