Possible Cache model for ATAPI

Because MSCP sector requests assume 512 byte sectors,
and an ATAPI drive typically uses 2048 byte sectors,
a single block read fills our 4x512 buffer with four consecutive logical sectors.
Maintain these fields for each entry (4) in the cache map:
	FLAG:	entry valid
	LUN:	MSCP unit
	ADDR:	MSCP sector address
On an ATAPI read (device sector, 4 logical sectors), each entry is marked valid, 
its LUN and (MSCP logical) sector address.

The cache has implications for MSCP command queueing and reordering.
* It is assumed the underlying device is read only
* Because the cache is entirely flushed with data from any read,
  all valid cache entries belong to the same logical unit at all times.

When processing a command C at head of queue:
Repeat until C is completed {
  - if remaining part of command requires new read (i.e. cache flush),
    and cache is not empty,
    first check command C and all following queued commands FOR THE SAME UNIT
    (without passing any
    Sequential MSCP barrier) if any part can be fulfilled from cache
    (this may be start or end part only). Partially progress each eligible command,
    copying data from cache and adjusting limits accordingly. (Any commands that are 
    fully satisfied may be removed from the queue and responses queued.)
  - issue required read, update cache map
}


(An ATA read replaces any of the four entries, marking it invalid - 
even LRU, if we keep a last-accessed counter, but interleaved ATAPI 
and ATA accesses may defeat all such optimisations.)

We may assume that the ATAPI device is read only. (A read/write device
would require reading device block (2048), changing written portion,
and rewriting entire device block. This effectively flushes entire cache
with four new sectors.)