GCR encoding

[ross]

Originally Posted by Zer0-X

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

I've no idea if eADF support 4us cells.
If yes a full working "original" copy of this game can be easily made.

[Toni Wilen]

Originally Posted by ross

I've no idea if eADF support 4us cells.

It would be easy to support: if total track size is about half the normal 2us size, assume it is using 4us bit cells.

[ross]

Originally Posted by 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.

Hi Toni, another theory for you . Play with precomp.

What actually you do in your code is using MFMPREC=0.
But what this mean? In my mind the precomp is like a 'voluntary jitter' inserted 'cause the non-linear properties of magnetic recording surface
(we've a ~300RPM fixed rotation, a fixed clock and different track length..).

In your test you write on track 0 where the precomp need to be minimal
(higher precomp is needed in cyl closer to the center, well, rarely used on Amiga because it work anyway, but this is another story..).

There is documentation on what GRC precomp do?
If we look at the other bits for the precompensation we can suppose that probably it insert a 'jitter' of 1120ns, that is exactly the wrong thing to do in our case!
Seems that "00" GCR work because of more bits density, we instead are enlarging distance.
So for GCR is important to distribute properly precomp in the various tracks if you trick with it ("00" bits..).
[I remembered something from my archaic tests: with the "0000" MFM I had to carefully use the precomp otherwise I had problems on the internal tracks]

With a simple "0" GCR we are really relaxed and a 'median' jitter is the best thing to do.
Well, always if actually GCR precomp does this, sure we really need a probe to check the flux..

Problably doesn't work anyway, cause the bad timing on successive bits and propaganting error, but.. if you have some spare time play with it

[coder76]

In Wikipedia there is an article about GCR format and some of its variations. Apple used three different encodings, of which the two first were pretty poor in terms of encoding efficiency. Then later Commodore used a fourth GCR format in C64, which is the most space efficient, 4 bits becomes 5. It seems that Amiga can't read and/or write this C64 format entirely correctly and maybe also fails at the third apple format (6 and 2-encoding), as it allows also two consecutive 0's at some places.

https://en.m.wikipedia.org/wiki/Group_coded_recording

[ross]

Ok, time for a synthetic extended ADF, full original version, containing GCR track.

Thanks to all involved!

Into the Zone.

[NorthWay]

Originally Posted by coder76

It seems that Amiga can't read and/or write this C64 format entirely correctly

I have made .d64 files from my old floppies using an A1020 without any trouble.
There are several utilities and sundry on AmiNet for accessing floppies from a 1541 on an A1020.

So, what is "entirely" in this context?

[Toni Wilen]

Originally Posted by NorthWay

I have made .d64 files from my old floppies using an A1020 without any trouble.
There are several utilities and sundry on AmiNet for accessing floppies from a 1541 on an A1020.

I think the point was that Amiga may not be able to read it in GCR mode (or it can if floppy is written with correct pre-compensation) but 2us mode probably works fine.

At least Paula's GCR sync mode is incompatible with C64 GCR, software track decoding is always needed.

Originally Posted by ross

Ok, time for a synthetic extended ADF, full original version, containing GCR track.

It already worked (at least without cycle-exact) but now also correct track speed is used when track is "half-size".

[ross]

Originally Posted by Toni Wilen

.. but now also correct track speed is used when track is "half-size".

Tried the ADF with latest beta in CE mode.
Perfect

Thanks.

PS. just curiosity: where is the break point between normal and half-size?

[coder76]

Originally Posted by NorthWay

I have made .d64 files from my old floppies using an A1020 without any trouble.
There are several utilities and sundry on AmiNet for accessing floppies from a 1541 on an A1020.

So, what is "entirely" in this context?

Yes, but we were talking about handling GCR format with Amiga's native disk drives. This A1020 is some external disk drive which has its own drive mechanism, and probably is connected to Amiga via parallell port (ok im not sure here). I would really need to experiment on my own to tell you more, but the disk drive in my A1200 seems to be broken.

[Toni Wilen]

Originally Posted by ross

PS. just curiosity: where is the break point between normal and half-size?

Less than 66% of nominal 2us track size.

[desiv]

Possibly wrong and/or just way off, but if GCR is what is used by the Macintosh, didn't AMax read/write GCR from an Amiga drive with it's mini transfer disk format?