GCR encoding

[roondar]

I wonder if any games used GCR encoding instead. The controller in Paula can apparently read/write this just fine so it might be an interesting thing to know.

[dlfrsilver]

Originally Posted by roondar

I wonder if any games used GCR encoding instead. The controller in Paula can apparently read/write this just fine so it might be an interesting thing to know.

Yes, as stated in the Amiga Bible.

[Toni Wilen]

Originally Posted by roondar

I wonder if any games used GCR encoding instead. The controller in Paula can apparently read/write this just fine so it might be an interesting thing to know.

Very unlikely (I don't trust any rumors as usual) because it requires them to be undumped. UAE does not have any GCR support. I am still waiting for game that requires it.. (It has been very long wait).

[BarryB]

Originally Posted by Toni Wilen

Very unlikely (I don't trust any rumors as usual) because it requires them to be undumped. UAE does not have any GCR support. I am still waiting for game that requires it.. (It has been very long wait).

Alternate Reality has a GCR encoded track according to the WIP on the Softpres site:

Alternate Reality

The first Amiga game found that has a GCR encoded track.

[dlfrsilver]

Originally Posted by BarryB

Alternate Reality has a GCR encoded track according to the WIP on the Softpres site:

Alternate Reality

The first Amiga game found that has a GCR encoded track.

Interesting, one of my contributors sent me this game to check

[BarryB]

Then don't make us wait, does it have any GCR tracks

[Toni Wilen]

I am waiting for image. If there is image format that supports it today..

I guess technically it should work with any raw format but different bit density may cause issues if emulator can't know if track is 2us or 4us or even worse, single track has both densities..

[dlfrsilver]

ok, i will post it tonight

[dlfrsilver]

Originally Posted by Toni Wilen

I am waiting for image. If there is image format that supports it today..

I guess technically it should work with any raw format but different bit density may cause issues if emulator can't know if track is 2us or 4us or even worse, single track has both densities..

I have zoned Alternate Reality v3.0.1 from Datasoft for you Toni.

[ross]

There's really a GCR track on it

[BarryB]

Thanks for uploading Denis!

Originally Posted by ross

There's really a GCR track on it

Woo Hoo, Toni's long 'wait' is finally over

[ross]

Actually the GCR read (track 50) on CTraw image doesn't work (or better, works but the data read is invalid). If you skip the check the game works properly.

[Toni Wilen]

I added GCR sync emulation support but it does not seem to work.

If at least 9 one bits have been read and first zero bit is detected: sync found, allow DMA. Unless Amiga GCR means something else but HRM says "appl(e) type GCR". Or perhaps parts of whole sync word is also written to memory?

[BarryB]

Does that imply the 'dump' was bad, the original disk was bad or that track wasn't mastered correctly?

[dlfrsilver]

Originally Posted by Toni Wilen

I added GCR sync emulation support but it does not seem to work.

If at least 9 one bits have been read and first zero bit is detected: sync found, allow DMA. Unless Amiga GCR means something else but HRM says "appl(e) type GCR". Or perhaps parts of whole sync word is also written to memory?

Paula on the Amiga support GCR reading and writing, i found some informations inside my Amiga Bible book.

here it is :

ADKCON $09E (write) ADKCONR $010 (Read)

BIT - NAME - Function
-----------------------------------------
Bit 15 => SET/CLR => activated bits or disactivated

Bit 14-13 => PRECOMP = those bits contain PRECOMP value :
Bit 14 Bit 13 PRECOMP time

BIT 12 => MFMPREC => GCR = 0, MFM = 1

BIT 11 => UARTBRK

BIT 10 => WORDSYNC => WORDSYNC = 1 activates the GCR synchronisation of the disk controller on the word present in the register DSKSYNC

i guess this BIT 10 is what you need

BIT 9 => MSBSYNC => MSBSYNC = 1 activates the MSB synchronisation

BIT 8 => FAST => Clock rate of the disk controller
FAST = 1:2 microseconds/bit (MFM)
FAST = 0:4 microseconds/bit (GCR)

[Toni Wilen]

Everyone knows that. It is in HRM! It does not tell anything how it actually works. (Just like WORDSYNC, actual exact behavior was not documented).

[ross]

Originally Posted by Toni Wilen

I added GCR sync emulation support but it does not seem to work.

If at least 9 one bits have been read and first zero bit is detected: sync found, allow DMA. Unless Amiga GCR means something else but HRM says "appl(e) type GCR". Or perhaps parts of whole sync word is also written to memory?

Can possibly be only 8 one bits? Then if next bit 0 -> sync found and data written by DMA. (9 one bits seems to be a valid normal sequence)
Sure zero is not inserted by DMA because first byte check is for $CC.

[Toni Wilen]

Originally Posted by ross

Sure zero is not inserted by DMA because first byte check is for $CC.

Yes, it checks for $cc but there is no guarantee it needs to be first read byte.

[ross]

Originally Posted by Toni Wilen

Yes, it checks for $cc but there is no guarantee it needs to be first read byte.

Sure, but if I had to decide how to code a 'sync to MSB' I would do this:
- maximum number of 1 bits consecutive allowed in coding for 1 byte (FF)
- a 0 to invalidate the sequence making an impossible pattern
- a 1 to the MSB of the next byte to indicate valid data
then 'FF' "0" 'CC' it would tell me the first valid byte (CC) after a sync
But they are only suppositions

EDIT: the single "0" can be interpreted as maximum number of consecutive allowed zero on GCR
could be also "00" actual bits, the meaning would not change

[Toni Wilen]

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