[sebhc] fstools and other things
Eric J. Rothfus
eric at rothfus.com
Tue Jun 1 22:20:25 CDT 2004
OK - the source for the SVD tools are up at:
This is the latest source tree...so it has a couple of
"works in progress" but it all pretty-much works. You
can find the tosvd.html man-page in there...but not the
fstool.html man page...I simply haven't had time to do
it yet. The source, though, is fairly explanatory.
Take a look at the hastily prepared README.TXT for more
When I was testing Steven's blanks, I used the following
command to get an old .H17 file that is compatible.
$ tosvd -s JV1 -o H17 filename > outputfile.h17
This command forced the tool to think of the format as
JV1, which is a binary format and spit out H17 format.
However, because there is no volume number in the images
you'd need to edit the H17 image first line header
(you'll see the bad value) and change it to the octal
Then to check/print the directory of the image I used:
$ fstool -r -F hdos -f filename
I would LOVE to settle on a decent H17 format that
people could agree on. It would be a short-order job
to create a new format.
Regarding the single-sided 80-track image that Steven
put up, (removing foot from mouth) he was right. The
code in HDOS/label.c was broken and used && where a &
should have been when decoding the flags (which is
LBA.VFL). How could I have doubted you Steven! ;-)
In response to Steven's comment:
> Having another side doubles the number of tracks.
> The side isn't included in the sector address.
HDOS expects the tracks to be organized such that odd
tracks are on one side and even on the other. So when
you go after the directory track, or the GRT, it will
be nice to know that the track you're looking for is in
the place you think it is. Or maybe you were just
saying that the organization in the image files IS the
HDOS organization. That is, track by track independent
of where they would have physically resided on the
For those of you reading along, what I mean by the
above is that the image was "dumped" (or hand-crafted
as may be) track by track instead of side by side.
This type of dump would work well in concert with HDOS.
Some formats do side by side and some track by track.
In other words, in the HDOS format the tracks are laid
Side 1 Side 2
Track 0 Track 1
Track 2 Track 3
Track 4 Track 5
On other formats (not HDOS) who "somewhat" think of the
separate side as another image:
Side 1 Side 2
Track 0 Track 40
Track 1 Track 41
Track 2 Track 42
So two OS's looking at the same string of tracks/sectors
from a file may interpret them differently if not otherwise
Note that the "physical" layout on the disk is not only
(normally) important to the OS interpreting the layout.
On most formats, the track number is included in the
header of the sector and the OS may barf if it doesn't
match what track the OS thinks it is looking at.
IMHO it is important to separate the OS on an
image/floppy from the physical format. The physical
format may not change but the higher-level OS may
impose a different interpretation. So there must be
a well-known definition of the image-file format...
even if that definition is "just like HDOS!" Because
another OS (like CP/M) may just think of the format
Enough for tonight!
Delivered by the SEBHC Mailing List
More information about the Sebhc