GCR encoding

[ross]

Originally Posted by Toni Wilen

I can't find FF<1 or 2 zeros>CC combination from the track buffer.

FF<"0"?

(there are some "00">"1"value in apple '6 and 2' GCR encoding but better focus on normal single "0" encoding)

[ross]

But we are neglecting the simplest thing possible.
Writing a track in GCR with a sequence FF>"0">"1"value on real Amiga and see if it syncs on read
It could also be that the CTraw track is not properly extracted

[Toni Wilen]

Originally Posted by ross

But we are neglecting the simplest thing possible!
Writing a track in GCR with a sequence FF>"0">"1"value on real Amiga and see if it syncs on read
It could also be that the CTraw track is not properly extracted

I am not interested as usual

Amiga_Disk_Drives_Inside_and_Out_1989_Abacus.pdf page 177 has GCR description that does not make sense in my opinion.. (FF55?)

[ross]

Originally Posted by Toni Wilen

Amiga_Disk_Drives_Inside_and_Out_1989_Abacus.pdf page 177 has GCR description that does not make sense in my opinion.. (FF55?)

uh, reading this makes me think I did not understand GCR at all..

[Toni Wilen]

IMHO it isn't important at all how GCR works because Paula surely does not care about it (like it does not care about MFM), it just transfers bits 1:1 from floppy to memory. Only important part is sync (transfer "enable") which is not documented.

[dlfrsilver]

I have the kryoflux dump handy as well.

Check the zone

[ross]

Originally Posted by dlfrsilver

I have the kryoflux dump handy as well.

Check the zone

Thanks Denis.
But i've no idea how to parse a raw kryoflux dump
I pass the ball to Toni.

Could be useful a 4us cells "fake MFM" conversion (and then bit-level parsing this).
What actually count are only the flux inversions.
There exist a similar tool?

[Toni Wilen]

I already lost interest. I thought these images are confirmed valid. I don't debug unknown images.

[dlfrsilver]

the Macintosh GCR tracks are not supported with the actual tool i use.

Make a try Toni, trying is better that not doing

[coder76]

I remember that I tried to implement GCR format reading and writing to floppy disk as described in Amiga Disk Drives Inside & Out, but it didn't work at all. Not sure where problem is, but got only garbage back when trying to read a GCR formatted track. I used this 4 -> 5 bits encoding system.

[Toni Wilen]

http://www.classiccmp.org/cini/pdf/A...pple%20DOS.pdf has very good low level description of this sync method (chapter 3).

Unfortunately implementing this sync algorithm still won't fix it: When loading first bit to 8-bit shift register, skip zero bits. $CC bit pattern is never found.

[ross]

Originally Posted by Toni Wilen

http://www.classiccmp.org/cini/pdf/A...pple%20DOS.pdf has very good low level description of this sync method (chapter 3).

Unfortunately implementing this sync algorithm still won't fix it: When loading first bit to 8-bit shift register, skip zero bits. $CC bit pattern is never found.

wow, this is MUCH better than Abacus description!
And on page 3-8 there is a sync mechanism that's practically the same I've guessed.
So two thing:
- some sync bits are inserted in DMA write like you supposed (and you need a real Amiga GCR write to confirm this)
- the track extraction is faulty (and maybe the kryoflux dump ca be handy)
There can be another reason.. Paula do not do Apple GCR Sync.. but in the Amiga manuals there is written like this.

[modrobert]

Could it be Commodore GCR? Also read this article about decoding, fascinating stuff.

EDIT:

Perhaps Glenn Keller knows if GCR was fully implemented or not in Paula, he designed the floppy logic. Remember him from watching the following interview a while back:

[ Show youtube player ]

[ross]

Originally Posted by modrobert

Could it be Commodore GCR?

Like Toni suggested is highly unlikely that Paula implement a GCR logic (like that MFM in fact..) but only the SYNC handling.
We need to know how MSBSYNC act, so we need a proper cleaned 4us flux track

Also read this article about decoding, fascinating stuff.

Well, lft is a genius and a great guy (i've a casual chat with him in [I don't remember which channel] and was a pleasure).

[StingRay]

Originally Posted by ross

Well, lft is a genius and a great guy (i've a casual chat with him in [I don't remember which channel] and was a pleasure).

Most probably in #c-64. Anyway, I think it would be a good idea to split the GCR discussion from this thread and make a new one. As interesting as it is, it doesn't really have anything to do with "games that were though to crack".

[Toni Wilen]

Originally Posted by ross

We need to know how MSBSYNC act, so we need a proper cleaned 4us flux track

Perhaps there is ipf image of old Apple GCR formatted disk? Writing it with kryoflux and then reading it with Amiga in MSBSYNC mode would be easiest way to confirm it.

[Toni Wilen]

I didn't lose too much interest yet: I did some experiments. I adjust my existing simple disk read/write tester to test GCR.

Results:

MSBSYNC set and WORDSYNC and FAST bits not set: It seems to work exactly like Apple GCR. Every read byte has high bit set. and repeating 111111110 pattern does "autosync" bit stream as documented.

Paula seems to randomly misdetect incoming disk data if data has 2 (or more) zero bits, randomly it becomes one bit. (MFM allows max 2 zeros but bit rate is also 2x faster so it probably is Paula PLL limit)

But first byte protection is looking for is $CC which is 11001100. So does the protection have invalid GCR bit patterns that Paula reads "incorrectly" resulting in correct protection data? It can't use "weak bits" because protection routine uses static test bytes and retries only once before asking for original disk.

[dlfrsilver]

Good Toni

[ross]

Many many years ago I made some tests to see what the limitations of the MFM were and I remember that I did not have big problems to put even 4 zeros in a row.
In theory the MFM allows to put maximum 3 zeros in a row, otherwise you risk losing the synchronization
(synchronization that it achieves through changes in the flux, with the PLL circuit mentioned by Toni that retroactively re-sync, with a Paula clock granularity, I think..).

The problem in fact are the consecutive one because they raise the physical limits of the magnetic support that does not allow more than many flux reversal in a given space
(1 is a flux reversal, and in fact in my tests with more consecutive ones in a row nothing worked..).

This is what compels us to use double-wide cells with the GCR: there are no more problems with the flow changes in the given space since there are half of them compared to the MFM
but then you can not put too many zero because of desynchronization risks.
In practice, having 2 zeros in the GCR is like having 4 zeros in the MFM; a large space without flow changes...
but 8us should be tolerable, especially when seldom used and in a narrow space.

So I do not understand why the $CC byte creates so many problems in Toni's tests.
Maybe a sensitive floppy surface/device?




EDIT: well indeed it could be one of the reasons why GCR has never actually been used on Amiga
too many floppy/driver combo unaffordable (with "00" practically unusable, so 'advanced' encoding unusable too)
and the simple "0" GCR very poorly attractive for data storage..

[Toni Wilen]

Very ugly test program source attached. It only does following:

- seeks to track zero (if not already)
- writes data (buffer contents generated in code)
- reads data to other buffer

I used asmone h command to manually check the disk2 buffer.

For example when reading a7aaaaaa a7aaaaaa, 7 becomes B randomly. Note that sync pattern is not at the beginning of track buffer to prevent gap overwrite but it is easy to find because of very clear pattern change.