On Wed, Dec 16, 2009 at 2:05 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
I can;t see why that would be a problem. The HP
protocols are all block,
not file, baeed (unlike the Commodore drives for the PET). The drive
doesn't have any idea what OS is talking to the it, it has no
understanding for the directory or the filesystem.
While Commodore disks do indeed have a firmware "DOS" that handles
file-level access and formatted directory listings and such, the
firmware fully supports block-level access by the B-R/B-W (or U1/U2)
commands. Infocom used that method for their VM implementation for
their Z-machine (once you used "CBM DOS" to read in a ~700 byte
bootstrap loader).
It's a fully-manual scheme - you tell the disk drive to read track X,
sector Y into a buffer, then issue a Memory-Read command to pull the
bytes out, or Memory-Write to stuff bytes in, then tell the drive to
write that buffer back out to wherever on the media you prefer.
Generally speaking, 90%+ of software written for Commodore drives just
uses the native file scheme, especially if it's load-and-go and
doesn't need to do in-application disk accesses, but there's no
technical reasons one can't implement an entirely different disk
layout scheme (except that the disk might look strange if you did a
usual LOAD"$",8 on it, and trying to "Validate" the disk might be
dangerous).
I think even the commercially-available SYM-1 interface to the 1541
drive depended on the native filesystem/command set. In practice,
there was rarely a reason to go beyond it, but the drive would allow
it.
-ethan