TL;DR: Verify and/or Search
The scan commands can be used to
- Verify a disk content without CPU interaction, or
- Search of specific data at a specific position
While the first is rather obvious, the second may only become such when adding a 'tiny' detail not mentioned in either manufacturers data sheet: A byte value of x'FF' from either side (data or disk) is considered a default match (wild card). With that in mind one can make up arbitrary search patterns.
Zilog and others (*1) weren't as secret. While the wording is almost exact identical to Intels 1982 data sheet - or NEC's for that matter - one important sentence has been added(*2):
The hexadecimal byte of FF from memory or from FDD can be used as a mask byte because it always meets the condition of the comparison.
As seen on page 933 of the 1985 Zilog Components Databook:
I innocently assumed that they were analogous to hardware key searches in IBM mainframe CKD/ECKD hard disks, but reading the description in the data sheets I'm less sure.
Yeah, a well educated guess knowing the history of magnetic recording, except the 8272 and later compare within the data fields, not key (header) fields. Somewhat more flexible.
Rather than comparing just searching for an initial key field, it sounds like they compare the entire sector data byte-for-byte with data supplied by the host computer.
Yes. And unlike the 8271 it doesn't offer support for pattern repeat (*3), so the whole data stream must be supplied right in time.
Searching for an exact match of an entire sector seems a lot less useful than searching based on a key field (such as the initial N bytes of the sector).
Yeah, that's where knowing the wild card value (x'FF') comes in handy. So if for example each 512 byte sector begins with an 8 byte key, search can be done by providing a those 8 bytes followed by 504 bytes of x'FF'.
This also gives a hint why that feature hasn't been used a lot (or at all). As the controller does not give any indication when starting/ending a sector, one has to set up either a search 'mask' for a whole cylinder (= 9 KiB for 360 KiB disks), which is a HUGE amount for back then, or adequate DMA handling(*4).
Is anyone aware of any software that actually used them?
I have seen it been used for write with verify. To use it the write software issues a regular sector Write command, followed by a Scan Equal using the same buffer. That way the sector gets written during one turn and read and compared during the next. When no error is reported one can be sure that not only the sector is present and valid, but also contains the intended data. Way more than what the PC's BIOS verify (Int 13h, Function 4) does (*5).
Is anyone aware of any emulators that emulate them? I've checked the source code of several emulators, and all those I've checked leave these commands unimplemented.
Well, as so often they only implement until it's somehow working and after that waiting for error reports/change request. With no default software using them, they may stay unimplemented for a long time. Except for some real old embedded/control applications noone writes his own diskette handlers - and such are quite rare found with people using emulators.
*1 - Found it as well in a 2004 application note by SMSC for their FDC765A.
*2 - Well, they also clarified some names, improved layout and dropped some misleading symbols. Over all the better data sheet to refer to.
*3 - The 8271 works with variable key size and record sizes in multiple sectors allowing finer specification what to search.
*4 - For example setting up a single record sized buffer and DMA in autoinitialize mode. Now the FDC would read all sectors starting at the first, compare each record against the buffer and return when found, or the whole cylinder is done. Of course EOP/TC hardware must be made to allow this - and having records fitting evenly into sectors or being multiples thereof would help as well.
Additional hardware could of course exploit this even more.
*5 - The IBM-PC BIOS for example does not really verify a sector, but only reads it. All data read is discarded without further check - that's also why any buffer given in ES:BX doesn't matter. It only 'checks' if the sector can be found, read and it's checksum being a valid one. Intels next FDC, the 81072 implements that behaviour as a dedicated command, so no DMA setup is needed.
I'm not sure right now if (GW)BASIC(A) implemented a verify at all.
