up vote 11 down vote favorite
3

This question is specifically aimed to the Amiga hardware.

Let's assume a floppy track is read via DMA using sync word to trigger the start.

Let's also assume the track contains the sync word multiple times (e.g. 3 times).

I assume I will have 3 random ways to read the track depending on what sync word comes first under the head.

But then what happens to the DMA?

  1. It ignores the other 2 sync words and just completes respecting the DMA size
  2. it stops early confused by the unexpected sync words
  3. any other behavior

I expect 1) as the answer but I have not the time to setup the test. Maybe someone​ already knows the answer or has a handy dev environment where he can test this.

Answer: the right answer is 1

Credit to @pndc for pointing out that AmigaDOS specs say each sector starts with 2 sync words. This makes sense since it is faster to start transfer from the wrong sector and then​ fix this in RAM than wait a full disk revolution for the start of the track. It is well described here

share|improve this question
up vote 5 down vote accepted

Intuitively, the answer can only be "3. any other behavior", in that it resyncs every time it sees the sync word.

Why? Let's look at the standard Amiga disk format. All eleven sectors in a track are written together, and each sector starts with two copies of the magic "4489" sync word. However, because floppy drives are not precision devices, there is a random number of bits between the end of the last sector and before the first sector and its sync words come round again.

Now consider the read process, which is also performed on a whole-track basis. A track read will start at a random point in the track, and there is just a one in eleven chance that the read will happen to start before the first sector and thus get the sectors in order. More usually, it'll get the last N sectors, then the random-sized gap, then the first (11-N) sectors.

If the sync only happened the first time the sync word was seen in a DMA transfer, only the last N sectors would be correctly aligned in memory. The remaining (11-N) sectors would have random alignment (with a one in sixteen chance of being correct) and be very difficult to find in memory. So this is clearly not the case.

Likewise, if the transfer aborted on seeing multiple sync words, it would choke on the two sync words at the start of every sector.

share|improve this answer
  • Sounds convincing to me. Also: it'd be interesting to know what goes into the output stream if the FDC has collected, say, 14 bits of what it thinks are the next 16 when it realises it has spotted a sync word. The 14 padded with 0s on one side or the other, the 14 with 2 from the previous word as mid-shift, nothing at all, something else? I've assumed a 16-bit unit, that being the sync word size; if it's larger then adjust question appropriately. – Tommy Apr 4 '17 at 21:48
  • Thanks pndc for pointing out that, by AmigaDOS specs, each sector starts with two sync words. This is confirmed here lclevy.free.fr/adflib/adf_info.html . Anyway the correct answer is 1) the DMA starts at the sync word and transfers the programmed amount of words then stops ignoring what was transferred. Plus, your answer seems to imply that sync words are used to keep the DMA in sync, something is not true. Sync words are just a way to trigger the DMA. I will answer my question but I will give you the credit. – Valentino Miazzo Apr 5 '17 at 19:38
up vote 5 down vote

Amiga or not, DMA or not, the algorithm for IBM PC-compatible floppies is largely the same: wait for a sector header marker, read the header, compare the sector number with the desired number; if no match, start from the beginning, otherwise wait for the data marker and do the read. If the index hole flag was raised the second time during the search, abort and report "sector not found". I know this from implementing a low-level floppy interface simulator. Checking, after a successful read, for sectors with the same number would be a waste of effort.

share|improve this answer
  • 3
    I'm specifically interested in how the Amiga hardware behaves in this corner case. I'm not interested in how other platforms work. – Valentino Miazzo Apr 3 '17 at 18:12
  • 3
    @LeoB. the Amiga's hardware is very custom indeed; it's track oriented and, I believe, reports the bitstream directly (well, via DMA). So it's the data separator, the PLL and not much more. Though clearly there's some automatic framing synchronisation, per the question posed. – Tommy Apr 3 '17 at 18:31
  • 3
    The Amiga doesn't use sectors at all, and the disk areas normally taken up by the sector gaps are used for data which is what allows for the larger formatted capacity (880kB). Instead, the floppy controller reads and writes entire tracks at once, sacrificing some performance for increased data density. – mnem Apr 3 '17 at 18:48
  • 1
    @mnem As far as the hardware is concerned, sectors are delimited by markers; there may or may not be gaps. To eliminate gaps, of course, the whole track must be written at once; but as soon as the "sync words"/markers to initiate the DMA for reading are mentioned, the algorithm is the same as described (NB that it doesn't mention any gaps). – Leo B. Apr 3 '17 at 19:12
  • 2
    @LeoB a regular disk controller has to do all of that but the level at which you communicate differs. If I'm talking to a WD177/9x or an 8272 or something I ask for a sector and the FDC does what you say: it obeys synchronisation marks, it waits until the sector appears, it streams that data, after deciding the MFM or whatever. On the Amiga you ask for track X and get told "bit stream was this, find your own darned sectors!". So different strategies for handling synchronisation (swallow an incomplete value or output it as a partial?) are perceivable. And GCR, MFM, etc is 68000's choice. – Tommy Apr 3 '17 at 19:26

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.