Stumped on a Cartridge Repair

[Martin_Head]

Someone needs to write a toolkit with format_rand command that takes a random from arguments

Take a look at this.

ImgUtil.zip

(7.19 KiB) Downloaded 24 times

I thought I did something some years ago. It's for some Qemulator utilities I was working on.

It took a while to find it. But I think the FROMAT_N command is what you want. Just LRESPR the imgutil_bin file. And see the _txt file.

I've not tested it. (I'm a bit short of microdrive cartridges I can write on at the moment)

[t0nyt]

Someone needs to write a toolkit with format_rand command that takes a random from arguments

Take a look at this.

ImgUtil.zip

I thought I did something some years ago. It's for some Qemulator utilities I was working on.

It took a while to find it. But I think the FROMAT_N command is what you want. Just LRESPR the imgutil_bin file. And see the _txt file.

I've not tested it. (I'm a bit short of microdrive cartridges I can write on at the moment)

Thanks Martin, that works great

[t0nyt]

I was wondering if anyone could shed any light on the following please?

I'm looking to understand a bit of code that does, seemingly, the following:

IO.OPEN of MDV2_ (or MDV1_), there's no filename just the drive

Then it reads 80 bytes and closes the channel

I can't get my head around what it's expecting to read in by just specifying the device

Is it the sector table or something please?

Many thanks

[martyn_hill]

Hi Tony

An IO.OPEN call will also be passed a 'Key' in D3 and, if that key is 4, the request was to open the directory-file - of which there is only one on an MDV - the root DIR - and which would have a valid filename of just 'MDVx_'.

So, likely as not, the routine you are investigating is opening the MDV directory-file and then reading the first 80 bytes - which will contain the 64-byte header of the directory file itself, which sits in the very first directory 'slot.' Why 80 and not 64, I couldn't say...

[NormanDunbar]

What's the OPEN Key in D3 prior to the call to IO.OPEN? That might give you a clue. If it's 4 then it's opening the drive's directory. Reading 80 bytes is interesting as directory entries are, if I remember correctly, 64 bytes per entry. I am,of course, assuming that it's reading 8-0 decimal bytes and not 80 hex bytes (128 decimal) although, 128 decimal would be the first two directory entries.

I suspect it's checking to see if something that should be there on the original but which wouldn't be there on a copy. possible they created a file, copied everything over, then deleted the file to leave a state ion the directory that they could check.

This is all hypothetical of course! Without further info.


Cheers,
Norm.

[t0nyt]

Hi Norm,

D3 = 0x4

It's reading 0x50 bytes (80 decimal)

Thanks for the thoughts on what's going on, something for me to play around with

Many thanks
Tony

[t0nyt]

Would the 80 bytes it's reading start at the beginning of the block from $FF, or from byte 17 of the sector please?

Many thanks

[martyn_hill]

Hi Tony

If it's using the io.fstrng trap to read those 80bytes, then I believe it'll actually be the first directory entry itself (plus the next 16bytes of entry#2), which in a directory-file, would be a copy of the directory entry for <root> itself.

Is this what you've decompiled from some copy-protection routine? The context might offer more clues...

[martyn_hill]

...actually, scratch that last comment - those first 80-bytes fetched with an io.fstg IO call would contain the directory entry of the first file in the directory (not as I wrote before, a copy of the root dir entry) plus the first bytes of the second entry.

[t0nyt]

Hi Tony

If it's using the io.fstrng trap to read those 80bytes, then I believe it'll actually be the first directory entry itself (plus the next 16bytes of entry#2), which in a directory-file, would be a copy of the directory entry for <root> itself.

Is this what you've decompiled from some copy-protection routine? The context might offer more clues...

(excuse any typing errors, I've just sliced a finger open on a can of tuna!)

It's using FS.LOAD to read the 80 bytes

I've imaged my master cartridge of 3D Slime to an MDV image (has 1 bad sector) but it's failing the protection check so am trying to work out why

It took a lot of passes to get the image so the master cartridge itself won't work either, and I'd like to repair it or at least make a working cartridge (but with the protection in place and working)

This is the code section I'm trying to understand at the moment please

Code: Select all

0000025C   303c 0001                        MOVE.W    #0x0001,D0
00000260   72ff                             MOVEQ     #0xff,D1
00000262   7604                             MOVEQ     #0x4,D3
00000264   41fa 0866                        LEA       (D_0866,PC),A0		$0ACA MDV2_
00000268   4e42                             TRAP      #2			IO.OPEN OPEN 
0000026A   0c40 0000                        CMP.W     #0x0,D0
0000026E   6600 00a8                        BNE.L     B_318
00000272   4bfa 009e                        LEA       (D_009e,PC),A5		
00000276   2a88                             MOVE      A0,(A5)			channel ID
00000278   303c 0048                        MOVE.W    #0x0048,D0
0000027C   7450                             MOVEQ     #0x50,D2			80 bytes
0000027E   363c ffff                        MOVE.W    #0xffff,D3		
00000282   43fa 5d50                        LEA       (D_5d50,PC),A1		
00000286   4e43                             TRAP      #3			FS.LOAD	
00000288   303c 0002                        MOVE.W    #0x0002,D0
0000028C   4e42                             TRAP      #2			IO.CLOSE

Many thanks