Category: disk

disk commands

in the SET command post for the 8-bit project, i mentioned disk commands.  so maybe it’s appropriate to talk a bit about what that means for the system as a whole.

i intend to make my computer capable of using an IDE hard drive to store and load data and programs.  while technically a 16-bit interface, it is possible to interface to a drive in a purely 8-bit manner.  my primary references for this so far have been retroleum and andrew quinn.  these methods only allow access to fairly small drives, but for an 8-bit computer with a 64K memory space, that’s not really an issue.  i’ve actually already picked out the drive i intend to use, an ~500MB seagate drive i had laying around.  i won’t be using anywhere near its full capacity though – i will be limiting myself to 16 bits worth of block addresses.  at 256 bytes per block, this means a maximum capacity of 16MB.

in addition to the hardware, i intend to create my own file system rather than use something like FAT, even though information is readily available on that.  doing so would go against my desire to create everything i can by myself.  i’ve done a little thinking about the file system already, but i’ll talk about that in another post.

the main point of this post is to talk about the firmware commands that will be needed to support disk i/o.  i am planning on a simple set of 5 commands that will need to be created:

LOAD – to load a file from disk into memory

SAVE – to save data from memory to a file on disk

DEL – to delete a file from disk

LS – to provide a simple, multi-column list of the names of files on the disk

DIR – to provide a more detailed listing of the names of files on the disk along with their length and default loading address.

the obvious command missing here is for initial formatting of the drive.  that command will of course exist, but i expect that to be software rather than part of the firmware because it’s something that will be needed so infrequently and firmware space will be limited.  if i can fit it into the firmware space, then it will probably move there.

together with the creation of the filesystem itself and the hardware aspects, this is obviously a large and complex subsystem.  but i’m sure it will be an interesting learning experience as i go through it, and that’s the important thing, right?