Stumped on a Cartridge Repair

[t0nyt]

Code: Select all

❯ ls -l 3dslime/
.rw-r--r-- 25k graeme 10 Feb 21:46  '-noASCII-!Game_bIN A!Maps_BIN'
.rw-r--r-- 640 graeme 10 Feb 21:46  -noASCII-A
.rw-r--r-- 26k graeme 10 Feb 21:46  3Dslime_pic
.rw-r--r-- 380 graeme 10 Feb 21:46  boot
.rw-r--r-- 22k graeme 10 Feb 21:46  Game_EXE
.rw-r--r-- 20k graeme 10 Feb 21:46  Game_red
.rw-r--r-- 112 graeme 10 Feb 21:46  h_s__dl1
.rw-r--r-- 46k graeme 10 Feb 21:46  QLG1_OBJ_V24

The filenames on the copy I have! (encoded for Q-Emulator)

That looks like the unprotected version with the QLG1_OBJ_V24 and h_s__dl1 (using 2 files from this I can make mine work, but I'm trying to get the protected version to work so you have to have the master in mdv2_ when running from the backup it creates in mdv1_)

This is the Dir of the original cart (and a dir of my backup copy which has all sectors intact so can use to repair the missing sector from master)

Game_bin & Maps_bin are actually 1 file of course (the use of chr$(10) in the file splits it, also the 'blank file' is also chr$(10) hence the double blank line)

Many thanks

[t0nyt]

I'm having trouble getting my head around which 80 bytes it's reading from the first directory block

The first entry appears to be blank? and then backup is the next entry

But if I work back 64 bytes from backup it seems to give me a header that's too large (I'm expecting 16 or 18?)

Could anyone confirm which 80 bytes would actually be read please?

Many thanks

[Martin_Head]

At offset $00000010 is the header of the directory itself. The $00000300 you see there is the length of the directory file.
768/64 = 12 Not sure if that means it thinks there are 12 filename entries in the directory, or it may be 11. The first being the directories header itself.

I can't remember how the copy protection worked on 3D Slime. You would have to follow on from your FS.LOAD and see what was tested.

If your trying to make a master you may have to make sure you copy all the files in the correct order on to the newly formatted master. Along with any odd characters added. Don't trust WCOPY I think it gets confused with strange filenames.

[t0nyt]

At offset $00000010 is the header of the directory itself. The $00000300 you see there is the length of the directory file.
768/64 = 12 Not sure if that means it thinks there are 12 filename entries in the directory, or it may be 11. The first being the directories header itself.

I can't remember how the copy protection worked on 3D Slime. You would have to follow on from your FS.LOAD and see what was tested.

If your trying to make a master you may have to make sure you copy all the files in the correct order on to the newly formatted master. Along with any odd characters added. Don't trust WCOPY I think it gets confused with strange filenames.

Thanks

I can see one mistake I've been making is I was thinking each entry began with the file name length when actually before that is the size of the file (4 bytes) and 10 x $00

The only problem is that if that is correct then the first entry I thought was a blank entry probably isn't an entry at all as it's only 62 bytes by my reckoning if $000030 is the number of entries (there are 10 actual file entries according to the output of Dir taking into account the chr$(10) effects)

I'm getting closer to understanding, but not there yet it seems

Many thanks

[t0nyt]

Just ran the code snippet to see what it actually reads and it's the "backup" entry starting at $50 for $50 bytes

Can only imagine, at the moment, that something else should have been there.

If that's the case then my original MDV isn't as original as I thought

I think whatever checks the returned values is probably in the supercharged program, so not sure how to get to the bottom of this at the moment. Maybe the next thing is to compare the unprotected version vs the protected version to see what changes have been made

[Martin_Head]

At offset $00000010 is the header of the directory itself. The $00000300 you see there is the length of the directory file.
768/64 = 12 Not sure if that means it thinks there are 12 filename entries in the directory, or it may be 11. The first being the directories header itself.

I can't remember how the copy protection worked on 3D Slime. You would have to follow on from your FS.LOAD and see what was tested.

If your trying to make a master you may have to make sure you copy all the files in the correct order on to the newly formatted master. Along with any odd characters added. Don't trust WCOPY I think it gets confused with strange filenames.

Thanks

I can see one mistake I've been making is I was thinking each entry began with the file name length when actually before that is the size of the file (4 bytes) and 10 x $00

The only problem is that if that is correct then the first entry I thought was a blank entry probably isn't an entry at all as it's only 62 bytes by my reckoning if $000030 is the number of entries (there are 10 actual file entries according to the output of Dir taking into account the chr$(10) effects)

I'm getting closer to understanding, but not there yet it seems

Many thanks

Each directory entry is $40 bytes. And they start at the line $00000010. So the entry at $00000010 is the file header of the directory itself.
$00000050 is the file header of the first file, $00000090 is the second etc.

Note that any deleted files will have a file length of zero. So the file length of $00000300 in the first entry would also include old entries of deleted files. It might indicate there are 11 files in the directory, but if one of them is a deleted entry, there may only be 10 files shown in a DIR.

[t0nyt]

Thanks Martin

I’ve tried a few combinations of putting certain files at the top of the directory but I’ll try adding a dummy file and deleting it after I’ve added the others

Am probably reaching the point now of having to wait until I can get hold of another original copy to get to the bottom of this

Many thanks

[t0nyt]

The 3D Slime conundrum has been resolved now thanks

I'd like to thank everyone whose given help/advise both in the forum and via PM/Email, many thanks

Special thanks of course to the person, who I won't name in case they don't want to be identified, who worked out the solution to my problem (can't believe I got so close earlier in the thread, but then again a miss is as good as a mile and I've a lot still to learn!)

Many thanks

[XorA]

The 3D Slime conundrum has been resolved now thanks

I'd like to thank everyone whose given help/advise both in the forum and via PM/Email, many thanks

Special thanks of course to the person, who I won't name in case they don't want to be identified, who worked out the solution to my problem (can't believe I got so close earlier in the thread, but then again a miss is as good as a mile and I've a lot still to learn!)

Many thanks

Any chance you can document it, protection systems for almost all other computer systems are well documented, on QL they are only documented by hearsay

[t0nyt]

The 3D Slime conundrum has been resolved now thanks

I'd like to thank everyone whose given help/advise both in the forum and via PM/Email, many thanks

Special thanks of course to the person, who I won't name in case they don't want to be identified, who worked out the solution to my problem (can't believe I got so close earlier in the thread, but then again a miss is as good as a mile and I've a lot still to learn!)

Many thanks

Any chance you can document it, protection systems for almost all other computer systems are well documented, on QL they are only documented by hearsay

I'm happy to document it so the information isn't lost

But, currently, I'd not be willing to publish that publicly as I assume there is a copyright issue here given no-one seems to of ever publicly published the unprotected version that's already in existence? (and this protection scheme seems to be specific to 3D Slime, unlike magic numbers and the like)

Will try to think of a way to describe the protection without being too specific