High Density Drive Suggestion

[Loedown]

I know that many of the problems with Amiga drives is that in some cases due to copy protection and alike, the timing of the drive had to be critical. Now that's probably not the case for the high density drives but still the problem of making the disk spin at 150 RPM remains.

Thinking about the way the disk takes the data, what's to say that the data cannot be buffered in an analog buffer? I propose that it may be possible to read the entire sector of data, store it in a CCD which is basically a huge array of capacitors and then let the Amiga read it as it wants it.

Thoughts please.

[pandy71]

Why analog, just store this in large FIFO - at least there is one known solution like this (i don't remember name for this device, it have on board DRAM - ZIP package to store track - i assume signal INDEX is used to simplify overall circuitry)- if sampling is made with 2x speed can be fully asynchronous, You can start outputting data when FIFO will be half full (from slower Amiga to faster FDD), opposite direction can be almost immediately sent to Amiga (thus no latency).

--
uC with relatively large RAM on board and SPI interface as serializer/deserializer can be used can - to store whole track with 2Mbps RAW you nedd approx 50000 bytes - i assume that some 64KB RAM uC can be sufficient (probably ARM/PIC32 family, perhaps DMA can be used to process SPI, if 2 SPI are on board then everything should be very simple as one SPI can be dedicated to Amiga and second to Floppy)

[Loedown]

Does the sampling not cause errors or are the margins so clear cut in the case of the flux changes that it simply doesn't matter?

I thought the CCD idea was a novel approach to a possible problem, I am simply not interested in pursuing it.

[mc6809e]

I would think investigations into the encoding scheme might yield good results.

RLL(2,7) for example vs MFM or something else.

Are there any results concerning Paula's ability to keep its clock in sync with the bits coming off the disk with the number of flux reversals is more limited than MFM?

[pandy71]

Originally Posted by Loedown

Does the sampling not cause errors or are the margins so clear cut in the case of the flux changes that it simply doesn't matter?

I thought the CCD idea was a novel approach to a possible problem, I am simply not interested in pursuing it.

There is no analog signal between Amiga and floppy drive - all signals are TTL (digital) - if there is something interesting then it is coded in edge, with 2x sampling speed you retain this information quite accurately.

CCD perhaps can be OK for analog signal (analog delay line) but in floppy case you don't have access to analog signal, look at R/W amplifier IC - it is full of blocks to process analog signal and later to restore digital waveform.

Originally Posted by mc6809e

I would think investigations into the encoding scheme might yield good results.

RLL(2,7) for example vs MFM or something else.

Are there any results concerning Paula's ability to keep its clock in sync with the bits coming off the disk with the number of flux reversals is more limited than MFM?

Not sure to be honest especially that Paula has two modes - one MFM and second GCR - GCR is probably like raw bitstream copy - this is one of Amiga big mysteries as GCR mode is almost undocumented (even in Paula patent, similar to line drawing for Agnus that seem to be completely not covered by any patent - perhaps to avoid patent problems)