Using the Amstrad CPC disk data format as an example, the sector IDs are C1, C6, C2, C7, C3, C8, C4, C9, C5. Is it possible to lay these IDs on a track without actually formatting each sector or does setting these IDs on a track entail formatting the sectors too?
3
3 Answers
A disk could exist with only the sector headers being well-formed and the parts in between being only random noise, but could not be created with the built-in FDC. The CPC uses an FDC765, which is the same as that in a PC, and that has only an atomic 'format track' command.
Although it would be possible with a commercial disk duplicator, it'd be more likely that a producer would either just deliberately write bad CRCs or else deliberately write fuzzy (i.e. placed so as seemingly to shift location on each reading due to uncontrollable factors) or weak (actually a lot like being unformatted, but a deliberately written low-amplitude section rather than just whatever's there) bits as home machines can producer neither, but the results of reading are predictable.
For a disk track to be properly formatted, it is necessary that certain bit patterns (synchronization markers) appear at the start of each sector and nowhere else on the track. If a disk might initially contain arbitrary data, the only practical way to ensure that those markers don't appear anywhere they shouldn't is to erase the entire track. While it might be possible to scan the track for those bit patterns, and refrain from erasing it if they're not present, such an approach could be unreliable if some drives are more sensitive than others. If a disc contains some sync markers which are too weak for some drives to read, but strong enough for others, drive #1 might decide the track contains no sync markers when it writes information to it, but drive #2 might see--and get confused by--synchronization markers that drive #1 didn't see.
It would be possible to design a disk system whose block map could mark tracks as "not formatted yet", and which would format each track the first time code attempted to write data to it. If one doesn't try to write a track until one has enough information to fill it, the time to format and write a track may on some controllers be the same as the time to format the track and write all the sectors as blank.
Without being Amstrad-specific, the answer is yes.
For example, the way Electronika BK interacted with its PC-compatible floppy drive through the interface board which had a simple PLA rather than a true floppy controller chip, necessitated formatting tracks by writing individual bytes and issuing "write marker" commands guided solely by instruction timing. Thus it would be possible to skip writing exactly the 512 bytes corresponding to the data part of each sector, and making a formatted "write-only" disk.
-
I think we might just have applied different definitions; I took unformatted to mean no intentional magnetic pattern. I'll expand my answer to explain how we're seemingly at odds, because I don't think we really are.– TommyJul 31, 2017 at 10:23
-
@Tommy That's exactly what I meant: If a "write byte" command is not issued, the magnetic pattern on the disk will not change.– Leo B.Jul 31, 2017 at 16:27
-
I'm pretty sure the erase head will be on for the entire period (so, more semantics to argue, I guess) and would be amazed if the FDC didn't either keep writing something should your output stream vanish, or else declare an error immediately and do nothing further. Am trying to look into it, but maybe you have a source to hand?– TommyJul 31, 2017 at 17:36
-
@Tommy The FDC of the Elektronika BK was extremely dumb: it was effectively a few byte buffers, a PLL, and a modulator/demodulator. No block size counters of any kind. It would declare an underflow, but that is normal for the termination of every block write operation. The ROM of the Electronika BK floppy controller is here. (It may also contain the code for the IDE interface). The start address of the ROM is 160000. The (disassembled) source exists somewhere, but I couldn't find it.– Leo B.Jul 31, 2017 at 19:37
E5bytes, so reading a formatted sector that had nothing else written to it would give you a string ofE5bytes, usually 512 of them since that was the default sector size. Assuming you could read an unformatted sector ignoring any errors that might occur, I would expect some sort of noise data, probably changing each time it's read, like weak sectors.