GCR encoding

[ross]

..and these are the moments when not having a real Amiga is sad..

[Toni Wilen]

I guess possible conclusions are:

- Emulation seems to be correct, when writing and reading in 4us mode. It matches my test results (except 00 randomly becoming 10)
- Image most likely is not correct or it was decoded using normal MFM 2us bit cell size(?) or protection assumes some Paula weirdness when reading 2us data using 4us bit rate mode.

In other words, we need official ipf

[ross]

Originally Posted by Toni Wilen

It matches my test results (except 00 randomly becoming 10)

Maybe even those who own the original sometimes get the message with the request to insert the original due to the unreliability of the reading

[Zer0-X]

I'll have to take a look at the original raw dumps of that game in the evening.

Also got dumps of Mac 400k and 800k disks aswell if needed. Just wrote a tool to generate KryoFlux raw files from such disks so I could create install disks and software for my Macintosh SE.

[ross]

Originally Posted by Zer0-X

Just wrote a tool to generate KryoFlux raw files from such disks so I could create install disks and software for my Macintosh SE.

Good , you can reverse this? (from a kryoflux raw file to a 4us cells raw file)

[Zer0-X]

Side 0 indeed does looks like Apple GCR. By a quick look it seems all the sectors are empty. So either the protection looks for that specific encoding or there's just a few bytes to look for.

[Toni Wilen]

I didn't test that separate track file because I don't want to bother with any useless hacks to load it.

Track being empty makes sense (but on the other hand, it would have been good idea to obfuscate the data at least a bit..) because protection only checks for few specific byte values. I don't remember which ones and can't check just now.

[ross]

$cc,$96,$aa

[Zer0-X]

Decoded the track.

Sector headers:
GCR after sync : Decoded header
CC 96 AA       : 32 00 00 24 16 27
CC 96 AA       : 32 07 00 24 11 27
CC 96 AA       : 32 05 00 24 13 27
CC 96 AA       : 32 03 00 24 15 27
CC 96 AA       : 32 01 00 24 17 27
CC 96 AA       : 32 08 00 24 1e 27
CC 96 AA       : 32 06 00 24 10 27
CC 96 AA       : 32 04 00 24 12 27
CC 96 AA       : 32 02 00 24 14 27

Data headers:
GCR after sync : Decoded data
CC 96 AD       : 00 00 00 00 00 00 00 ...
CC 96 AD       : 07 00 00 00 00 00 00 ...
CC 96 AD       : 05 00 00 00 00 00 00 ...
CC 96 AD       : 03 00 00 00 00 00 00 ...
CC 96 AD       : 01 00 00 00 00 00 00 ...
CC 96 AD       : 08 00 00 00 00 00 00 ...
CC 96 AD       : 06 00 00 00 00 00 00 ...
CC 96 AD       : 04 00 00 00 00 00 00 ...
CC 96 AD       : 02 00 00 00 00 00 00 ...

[ross]

Originally Posted by Zer0-X

Decoded the track.

This make sense (I have absolutely no idea if they correspond to some existing format so I inserted what could be..):

Sector headers:
GCR after sync : Decoded header

Tag (protection): track, sector, side, marker?, checksum (xor of preceding), end
CC 96 AA       : 32 00 00 24 16 27
CC 96 AA       : 32 07 00 24 11 27
CC 96 AA       : 32 05 00 24 13 27
CC 96 AA       : 32 03 00 24 15 27
CC 96 AA       : 32 01 00 24 17 27
CC 96 AA       : 32 08 00 24 1e 27
CC 96 AA       : 32 06 00 24 10 27
CC 96 AA       : 32 04 00 24 12 27
CC 96 AA       : 32 02 00 24 14 27

Data headers:
GCR after sync : Decoded data

Header (no tag) : faKe_value_for_sector_index, empty
CC 96 AD       : 00 00 00 00 00 00 00 ...
CC 96 AD       : 07 00 00 00 00 00 00 ...
CC 96 AD       : 05 00 00 00 00 00 00 ...
CC 96 AD       : 03 00 00 00 00 00 00 ...
CC 96 AD       : 01 00 00 00 00 00 00 ...
CC 96 AD       : 08 00 00 00 00 00 00 ...
CC 96 AD       : 06 00 00 00 00 00 00 ...
CC 96 AD       : 04 00 00 00 00 00 00 ...
CC 96 AD       : 02 00 00 00 00 00 00 ...

Can you make a raw GCR file (4us, ~$1900 byte) for the track? (containing only the value that Paula need to write)

Thanks!

[dlfrsilver]

I know about a game using GCR tracks or at least with tracks written with a GCR drive :

Albedo from Myriad. I had confirmation by IFW a long time ago now that the tracks were not 2us but 4us.

If interested, i zone the unofficial IPF.

[ross]

Originally Posted by dlfrsilver

I know about a game using GCR tracks or at least with tracks written with a GCR drive :

Albedo from Myriad. I had confirmation by IFW a long time ago now that the tracks were not 2us but 4us.

If interested, i zone the unofficial IPF.

albedo (F) (1988) [Original] (Myriad S.A.) (Amiga OCS 512kb) [Custom MFM Protection].zip ?

[kamelito]

The long track in Albedo was written using a Macintosh drive b/c it is possible to slow the drive rotation and they got access to documention explaining how to do it.

[ross]

I dont see any GCR track in Albedo.. only some MFM acrobacy

[dlfrsilver]

Originally Posted by ross

I dont see any GCR track in Albedo.. only some MFM acrobacy

The game has been mastered and written on a GCR macintosh drive.

It has been confirmed by the authors themselves

And you can't have 4us MFM tracks

[Toni Wilen]

The most important point: does it read using Amiga !FAST (4us) and/or MSBSYNC mode or not. Data being in MFM or GCR is irrelevant, Paula does not really care.

Nothing prevents programs to read 4us data using 2us bit rate and use software to "adjust" the data.

[ross]

Originally Posted by dlfrsilver

The game has been mastered and written on a GCR macintosh drive.
It has been confirmed by the authors themselves

No doubt of it.

And you can't have 4us MFM tracks

Why not? Enconding is absolutely unrelated to bit cell width.
EDIT: well, "absolutely unrelated" is a bit exaggerated ; actually only specific encodings allow certain bit densities and for surfaces like floppy the MFM is certainly more suitable (and simple and fast) than GCR. But require faster interface... so one of the GCR family was used previously.

The point is the MSBSYNC usage that is not present (but I really looked at it quickly and I could be wrong)

[Zer0-X]

The bits on that track are laid out at 3.5 us (1), 6.8 us (01) and 10 us (001) unlike the Amiga at 4 us (01), 6 us (001) and 8 us (0001).

[ross]

Originally Posted by Zer0-X

The bits on that track are laid out at 3.5 us (1), 6.8 us (01) and 10 us (001) unlike the Amiga at 4 us (01), 6 us (001) and 8 us (0001).

Many thanks Zer0-X.

I hope to interpret the data well:

10 us (001)

is really interesting and can explain why the "00" works for Paula.
This packet is normally written in 12us (when 4us cells are selected), that's problaby to much for a decent re-sync, but if written more "dense" the re-sync doesn't fail!

So:
- Paula cannot write effectively a "00" GCR code but can read it in some condition;
- Paula r/w natively support only the simple "0" GCR encoding.

What do you think?


EDIT: Toni, this could explain why there isn't "obfuscation" tentative: Amiga in any case cannot write this track

[Zer0-X]

I don't really know what the Amiga can and can not write.

But here's the clean GCR bitstream of that track.