So, I have my own emulator that I'm playing with. There are adventures about getting a FIG Forth going on it over in the Forth section.

One of my next steps is to add a "disk drive".

I already have 3 memory addresses for character I/O. One to tell me that a character is ready, another to read the character, and a third that I write to in order to put a character on the screen -- poor mans serial I/O without any actual bits and bauds.

For a "disk drive", what do these tend to look like on other systems?

In the end, for my needs, it really doesn't matter. I'm not performance sensitive, nor am I trying to match any specific piece of hardware in any detail. My assembly code will inevitably call some JSR that shrouds the "real work" anyway.

I could do something as simply as pick an arbitrary sector size (128, 512), have a 2 byte sector number, a 2 byte address pointing to the buffer, and a command byte to write a 1 or 2 to to read or write the sector. That's 8-32MB of data, which is -- ample. Add a byte for a "drive number".

I can do a serial protocol of some kind, copy the buffer through an address that I write to over and over. I won't add a "status" byte to check that the writing is done -- yea, that's how it "should be", but not on this system, not now.

But I was curious what disk interfaces look like on actual systems. Should I bother modeling one of those. Not really motivated to play "head, sector, track" games of yor. Math is hard, let's go shopping.

I generic terms, you could look at Hard drives, CF modules in IDE mode, and flash drives as a sequence of blocks. 512 bytes per block seems to be widely used. So, you create a 512 byte buffer. You write data to the buffer and issue a write block command with the block # as a parameter. Same for reading. Issue a read block command with the block # as a parameter. The 512 bytes get moved into the buffer for processing.

Just one way to look at it.

Daryl

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!