Programming the FDC, READ DATA command.

[Joseman]

Hi

I'm reading a loader from a game and i have one doubt...

The parameter number 5 for the command READ DATA is for number of data bytes in a sector

as far as i know

&02 = 512bytes
&03 = 1024bytes

BUT, the loader i'm researching, put a &08 value on parameter 5. (for track 40, sector ID &08)

On cpc-power i see that the disc has this sector with size 256 and real size as 1566 (there are gaps too as i see on cpc-power)

My question is.. what is the real meaning of parameter &08 on parameter 5?

Regards

P.S. the game is Livingstone Supongo II original DSK on cpc-power

[Nworc]

Hi,

I do not expect any magic behind this parameter, the sector size is defined as:   

Sector size = 128 * 2^x

So, 08 just means 32K. The magic lies in what the people intended to with it. I don't recall right know what's the maximum number of bytes you can write with a 765 on a single track, I believe it is somewhere near 6K if I'm not mistaken (physically you could write more bytes onto the outer tracks, but not with the 765). So it should not make any logical difference whether you put a 06, 07 or 08 into that parameter, as all of them are sizes beyond of what can be written onto a single track. But in order to be able to read that sector you have to give the correct sector spec, so if the sector has been formatted and written with sector size 08 you have to read it with that sector spec.

If they managed to format and write a sector like this, which occupies the whole track, you can get as much data out of a track as is possible, as you don't waste the space using that lame stuff like gaps and ids. I just wonder how you could format and write a sector like that, definitely there will be just a fragment of it on that track, which doesn't mean that you can't read it. Some people might have found a way to do tricks like these, maybe to get the maximum out of the disk, maybe to make it hard to create a backup. You might know better why they did that.

Oh, and if you be so kind, it would be great if you could run Discology and tell us how it maps that track.
Thank you!

[Joseman]

Thanks Nworc

here is a snapshot from discology with CPCE emulator

[Nworc]

Yepp, nice. There might be some data in it, presumably not much, just something that's used by the loader to check whether the disk is original.

[Joseman]

Thankyou Nworc

I'm mentioning you in the loader that i'm analyzing.

soon i will publish it on twitter/github

[Nworc]

Ehm, thank you, but no thanks.

I just enjoy to think about tricky stuff and also like to think loud, but honestly I don't want to get involved with cracking/hacking

[roudoudou]

the protection should be testing 7th and 8th sector of the track

i'm seeing in the dump that 7th sector overlaps 8th sector data

the 8th sector looks like a size 1 sector, not written (255 bytes with format value #55 then CRC) then regular GAP

buuuuuuuuut...

at the very end, you can see the data of the 7th sector, kindah lost in the track

if you look at the real size of the track, track40 is very small, in fact smaller than disco shows!

so i guess it's a pure CPC protection made with a regular FDC

format track with 10 (maybe more) sector of size 1
write sector 10 (maybe higher) with garbage
format track with 8 sectors, #55 as format byte and fake the sector 8 size THEN shutdown MOTOR!
read data of sector 8 until GAP change (when the motor was shutted down)
write those data on sector 7
that's all folks

this may be confirmed by what is doing the loader when it checks the protection

[Nworc]

Cool!

Being surrounded by so many nerds on this forum, makes me feel home.

[Joseman]

the protection should be testing 7th and 8th sector of the track

i'm seeing in the dump that 7th sector overlaps 8th sector data

the 8th sector looks like a size 1 sector, not written (255 bytes with format value #55 then CRC) then regular GAP

buuuuuuuuut...

at the very end, you can see the data of the 7th sector, kindah lost in the track

if you look at the real size of the track, track40 is very small, in fact smaller than disco shows!

so i guess it's a pure CPC protection made with a regular FDC

format track with 10 (maybe more) sector of size 1
write sector 10 (maybe higher) with garbage
format track with 8 sectors, #55 as format byte and fake the sector 8 size THEN shutdown MOTOR!
read data of sector 8 until GAP change (when the motor was shutted down)
write those data on sector 7
that's all folks

this may be confirmed by what is doing the loader when it checks the protection

Here is the code:

Code Select Expand

ld b,&ff ;number of data to compare
ld hl,&bfff ;second read, this time sector &7, 255 bytes
ld de,&baed ;first read sector &8, (1.554 bytes)

.comparation
ld a,(de)
cp (hl)
jr nz,pirate

dec hl
dec de
djnz comparation

;copy protection passed
xor a ;Z=1
ret

.pirate
;copy protection NOT passed
ld a,&01
or a ;Z=0
 
ret