Page 6 of 9
Re: Stumped on a Cartridge Repair
Posted: Sun Feb 09, 2025 3:03 pm
by Martin_Head
XorA wrote: Thu Feb 06, 2025 1:16 pm
Someone needs to write a toolkit with format_rand command that takes a random from arguments
Take a look at this.
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)
Re: Stumped on a Cartridge Repair
Posted: Sun Feb 09, 2025 4:35 pm
by t0nyt
Martin_Head wrote: Sun Feb 09, 2025 3:03 pm
XorA wrote: Thu Feb 06, 2025 1:16 pm
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
Re: Stumped on a Cartridge Repair
Posted: Mon Feb 10, 2025 3:12 pm
by 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
Re: Stumped on a Cartridge Repair
Posted: Mon Feb 10, 2025 4:43 pm
by 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...
Re: Stumped on a Cartridge Repair
Posted: Mon Feb 10, 2025 4:44 pm
by 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.
Re: Stumped on a Cartridge Repair
Posted: Mon Feb 10, 2025 4:51 pm
by 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
Re: Stumped on a Cartridge Repair
Posted: Mon Feb 10, 2025 5:13 pm
by 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
Re: Stumped on a Cartridge Repair
Posted: Mon Feb 10, 2025 5:20 pm
by 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...
Re: Stumped on a Cartridge Repair
Posted: Mon Feb 10, 2025 6:11 pm
by 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.
Re: Stumped on a Cartridge Repair
Posted: Mon Feb 10, 2025 6:13 pm
by t0nyt
martyn_hill wrote: Mon Feb 10, 2025 5:20 pm
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