[sebhc] Disk formats and emulators

[Dwight K. Elvey]

>From: "Eric J. Rothfus" <eric at rothfus.com>
---snip---
>
>So it looks like we're well on our way to a new format!  But the
>important question is:  "What do we call it?"  :-)
>
>Eric

Hi
 Ok. It looks like we would need something like a
header that describes the data that follows. It would
map data offset to physical tracks with track size and encoding
methods. Even in double sided soft sectored, one can
alternate sides or simply run up one side and down the next.
We should try to make things as universal as we can so that
any oddball condition can be handled. The header portion
should be in both human and machine readable format. Something
like a restricted language. This way, the proper interpreter
can handle the file as well as a human. If all is forgotten,
a human should, from the header be able to recreate the
disk or file. The file it self can be in binary or ASCII.
If in ASCII, I do recommend using hex instead of octal
( very anti-H8 front panel ).
 Other things that would be needed are things like the
encoding methods ( nrz, mfm, fm, m2fm etc. ) and the actual
track format. What ever converter we write doesn't have to
use all this information or provide it. We do need to
define it. If we do it well, it may be more universally
used by others for general floppy exchange.
 Here is an example of a real floppy format that exist to
give an idea of the strange things that exist ( I have a
machine with this ):

8 inch 16 hard sectored disk
single sided
two sectors per track of 8 hard indexes per sector.
Sector size is 1024 by 20 bit words in msb first order.
Tracks are headered by a track number that is in lsb first order
Data is encoded as fm.
There are no special sector marks.

 If our headers were done correctly, we should be able to
handle any odd ball type formats. We would need a central
location for maintaining a centralized document file for
the exact meanings of elements of the headers. Still the
headers would need to be self descriptive enough that for
someone that understands floppy formats they would be able
to create the disk image from that description. The headers
might only describe the format relative to a specific disk
controller but they should also, when available, describe
the format of the raw data.
 We can start with our HDOS, Heath CPM and possibly heath
tape data. We should make each incremental step to not
trap ourselves into thinking we really covered it all.
As you can see from the format I mentioned, there are many
strange things out there.
 Any part of the header that isn't used or interpreted
by the tool that is scanning the file, must report to the
user that some section was skipped and for what reason.
It might even be that it wasn't up to that level or that
it was outside the scope of that tools use. This way if
something didn't work, the user would know where to look.
It would be something they'd find in the header.
 One thing about the centralized ( and mirrored ) definitions.
There should be a web searchable name in the header that
one could use to find the definitions on the web. I know,
I'm assuming that the web still exist in the future. Still,
we need to make things as self useful without just making
grossly large files. I don't like the idea of having the
header information in separate files from the data.
 Sounds ambitious!
Dwight



--
Delivered by the SEBHC Mailing List