How to read differnt formated floppies
Bill Vermillion
Peter Michel <proORGA-Leime...@web.de> wrote:
>Hallo,
>i have floppydisks written by a tar, but they are formated with 17
>sectors/track and with 77 tracks per surface, each sector has 512
>bytes on a 5.25" media.
>How can i set parameters of the diskettes drivers to read (and perhaps
>write) it, this stupid format?
>Thanks a lot!
>Peter
>
Have you tried using the designated drive designation for the
5.25" disks. If so please show us the errors you get.
Those would typically be the /dev/fd096* entries.
However - the 17x77 is more akin to a 8" image - perhaps some
transfered those to 5.25".
can you do a dd on the disk. Try it - and see if you can save
the image - and if so try tar on the image.
There used to be charts on the older systems that showed how
to change the parameters of such things and I had to do that on
an old IBM-80 with 5.25" add on drives.
Bill
--
Bill Vermillion - bv @ wjv . com
James J
news:612ogv06j0dcdgi4i...@4ax.com:
> Hallo,
> i have floppydisks written by a tar, but they are formated with 17
> sectors/track and with 77 tracks per surface, each sector has 512
> bytes on a 5.25" media.
> How can i set parameters of the diskettes drivers to read (and perhaps
> write) it, this stupid format?
> Thanks a lot!
> Peter
>
I think you may be out of luck. "man fd" should show you the supported
floppy formats. I don't see 17 sectors/track in the list.
You could try one of the "autosense" device names (eg. /dev/rinstall).
Maybe that'll work. Here's a quote from "man fd":
> However, when accessing a floppy disk for other
> operations (read and write), the autosense nodes
> (/dev/[r]install, /dev/[r]install1,
> /dev/[r]dsk/finstall, and /dev/[r]dsk/finstall1)
> can be used. In this case, the floppy disk driver
> will automatically determine (autosense) the format
> previously established on the disk and then perform
> the requested operation.
Good luck.
James
Bill Vermillion
> Good luck.
I wonder if he might have luck with the /dev/dsk/f05ht.
It's 18 sectors per track and most closely emulates the 8" DD
format - which is what the 5" seems to look like.
I'd suggest trying the dd and if it fails after sector 17, and he
saved that, then maybe skip _might_ work to take him to the next
track - as the f05ht is an 18 sector format if I'm reading things
correctly.
Then he could just cat the pieces together, and then dd them out ot
a regularly formatted disk.
Bela Lubkin
> >>> i have floppydisks written by a tar, but they are formated with 17
> >>> sectors/track and with 77 tracks per surface, each sector has 512
> >>> bytes on a 5.25" media.
> >>> How can i set parameters of the diskettes drivers to read (and perhaps
> >>> write) it, this stupid format?
>
> the diskettes where written by an Xenix derivat on normal 5.25" Floppy
> media. The HW had a programmable device under /dev, which also was
> possible to use with the old ecma formats.
> Yes, they wrote it with 2*77*17*512 Bytes on a 5.25" HD disc 8-[:]
> But, the old HW isn't longer available :-(( and on the medias is
> source code we needed.
> Will try and see what will go.
The floppy driver isn't terribly picky about actual physical formats; at
least, not if the sector numbers written in the sector headers make
sense. What happens if you:
dd if=/dev/rfd0135ds18 bs=512 count=1 of=/dev/null
Do you get an I/O error or not? If not, the physical sectors are
probably readable. You just need to be sure to only read the sectors
that are actually present.
Let me digress for a moment about device names. I used the "r" device
(raw) because it doesn't go into the buffer cache, and doesn't attempt
to do readahead. If you try to read from the block device, readahead
will attempt to read sectors you didn't actually ask for (and which
aren't actually present), leading to failure. I used the device name
"fd0135ds18" because that refers to an 80-track, 18-sector format. Both
of those parameters are larger than your actual format. The benefit is
that every sector that exists on _your_ format also exists somewhere in
this format. (As do a few which don't exist on your format.) I used
"fd0" but you'll probably actually be using "fd1" (whichever position
your 5.25" drive is on.) "96" vs. "135" isn't important, they're
actually the same thing inside the driver.
So. The trick is to request all the blocks that _do_ exist, while
avoiding the ones that don't.
When you read linearly from the 135ds18 format, you get:
track 0 head 0 sectors 1..18
track 0 head 1 sectors 1..18
track 1 head 0 sectors 1..18
track 1 head 1 sectors 1..18
track 2 head 0 sectors 1..18
track 2 head 1 sectors 1..18
...
track 79 head 0 sectors 1..18
track 79 head 1 sectors 1..18
and what you want is:
track 0 head 0 sectors 1..17
track 0 head 1 sectors 1..17
track 1 head 0 sectors 1..17
track 1 head 1 sectors 1..17
track 2 head 0 sectors 1..17
track 2 head 1 sectors 1..17
...
track 76 head 0 sectors 1..17
track 76 head 1 sectors 1..17
A "C" program to extract just those sectors wouldn't be too difficult.
But it can also be done in the shell (maybe with a bit of awk). For
instance:
awk 'BEGIN {
dev = "/dev/rfd0135ds18"
for (tk = 0; tk < 77; tk++)
for (hd = 0; hd < 2; hd++)
printf "dd if=%s bs=512 count=17 iseek=%d\n", dev,
(tk * 2 + hd) * 18
}' > /tmp/get-image
sh /tmp/get-image > /tmp/image
tar tvf /tmp/image
If you look at /tmp/get-image, you'll see a bunch of separate `dd`
statements. If this works partially but gets some I/O errors, you can
fiddle around with the specific contents of /tmp/get-image to work
around whatever goes wrong. Of course if you can't read a single sector
then this isn't going to help...
>Bela<