Imaging a floppy disk

[Martin Gregorie]

I have some floppies (3.5", 1.4MB) with non-standard formatting which I
need to copy into a disk image so an emulated system, which runs under
Linux [Microware OS-9/68000 v2.4 in case you're curious], can read them.
There are no Linux disk drivers available that can read these disks,
hence the use of a disk image. The emulator, os9exec, can work with disk
images in its native format or the Linux filing system.

I thought I could make a suitable image with:
dd if=/dev/fd0 of=imagefile bs=256

since the blocksize it uses is is 256 bytes, but all that happens is that
dd does nothing for a minute or so and then reports a read error and
exits after saying that zero records were read and written.

What did I miss doing? Is dd not, in fact, the right tool for this job. I
know the disk drive is OK because it successfully mounted a DOS disk.

TIA.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Johann Klammer]

There are similar problems with ancient AMIGA disks(most are bitrotten
by now, anyway).

Perhaps you need to build something like this?
http://afr.back2roots.org/

[Dave Farrance]

Martin Gregorie <mar...@address-in-sig.invalid> wrote:

>I have some floppies (3.5", 1.4MB) with non-standard formatting which I
>need to copy into a disk image so an emulated system, which runs under
>Linux [Microware OS-9/68000 v2.4 in case you're curious], can read them.

Are you sure that it's 1.44MB? I recall working with a Microware
OS-9/68000 system at some company in the 1980s and it had a 3.5" 720MB
floppy drive. (I vaguely recall that it might've had 9 rather than 18
sectors per track and half the usual data rate.)

>There are no Linux disk drivers available that can read these disks,
>hence the use of a disk image. The emulator, os9exec, can work with disk
>images in its native format or the Linux filing system.
>
>I thought I could make a suitable image with:
> dd if=/dev/fd0 of=imagefile bs=256
>
>since the blocksize it uses is is 256 bytes, but all that happens is that
>dd does nothing for a minute or so and then reports a read error and
>exits after saying that zero records were read and written.
>
>What did I miss doing? Is dd not, in fact, the right tool for this job. I
>know the disk drive is OK because it successfully mounted a DOS disk.

I suspect that this is a non-trivial task. It's likely that the low-level
sectoring is different somehow, even if it is 1.4MB. It's probably
possible in theory to read it with a 3.5" floppy drive intended for a PC,
but I suspect that a specialized driver would have to directly access the
drive's controller chips, rather than the usual drivers.

So Googling something like "floppy media unknown format analysis" gives
stuff that might be worth reading for ideas like:
http://www.hp9845.net/9845/projects/fdio/

But it seems that it's a difficult enough task, that there exists a
specialist company that will provide quotes for recovering OS-9 data
(presumably costed according to whatever the market can bear, or the
desperation of the customer) if you fill in a form detailing the job:
http://www.reischke.de

[Nick Leverton]

In article <spj778pgiqrba5hq9...@4ax.com>,

Dave Farrance <DaveFa...@OMiTTHiSyahooANDTHiS.co.uk> wrote:
>Martin Gregorie <mar...@address-in-sig.invalid> wrote:
>
>>I have some floppies (3.5", 1.4MB) with non-standard formatting which I
>>need to copy into a disk image so an emulated system, which runs under
>>Linux [Microware OS-9/68000 v2.4 in case you're curious], can read them.
>

>But it seems that it's a difficult enough task, that there exists a
>specialist company that will provide quotes for recovering OS-9 data
>(presumably costed according to whatever the market can bear, or the
>desperation of the customer) if you fill in a form detailing the job:
>http://www.reischke.de

Microware don't seem to have used a format compatible with IBM PCs:
http://cdibits.blogspot.co.uk/2011/10/cd-i-floppy-inventory.html

"Microware has defined a number of OS-9 disk formats for floppies,
the 38U0 one supposedly being the “universal” 3.5" format (there
is also a 58U0 “universal” 5¼" format).

"The problem with the “universal” formats is that track zero can be
(and on my floppies, is) in a different density which makes it a bad
fit for most tools, both on CD-i and PC. "

Nick
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996

[chris]

You know the drive is OK, but can you be sure the disk is?

I tried something similar a while back with a few DOS-based floppies and
several were unreadable. The longevity of floppies is not great.

[Dave Gibson]

Martin Gregorie <mar...@address-in-sig.invalid> wrote:
> I have some floppies (3.5", 1.4MB) with non-standard formatting which I
> need to copy into a disk image so an emulated system, which runs under
> Linux [Microware OS-9/68000 v2.4 in case you're curious], can read them.
> There are no Linux disk drivers available that can read these disks,
> hence the use of a disk image. The emulator, os9exec, can work with disk
> images in its native format or the Linux filing system.
>
> I thought I could make a suitable image with:
> dd if=/dev/fd0 of=imagefile bs=256

Set the fd parameters first (untested):

setfdprm /dev/fd0 COCO720

[Mike Davies]

Nick Leverton wrote:

> "Microware has defined a number of OS-9 disk formats for floppies,
> the 38U0 one supposedly being the “universal” 3.5" format (there
> is also a 58U0 “universal” 5¼" format).

It's probably best not to cut and paste from a GUI app like a browser
into a text-mode app if the latter has no way of specifying the character
set.

[Nick Leverton]

In article <k50vc1$957$1...@speranza.aioe.org>,

I hoped I might get away with it if it wasn't for those pesky UTF characters !

[Giovanna Stefani]

Nick Leverton scrive:

> In article <k50vc1$957$1...@speranza.aioe.org>, Mike Davies
> <nos...@no.nowhere.com> wrote:
>>Nick Leverton wrote:
>>
>>> "Microware has defined a number of OS-9 disk formats for floppies,
>>> the 38U0 one supposedly being the “universal” 3.5" format (there is
>>> also a 58U0 “universal” 5¼" format).
>>
>>It's probably best not to cut and paste from a GUI app like a browser
>>into a text-mode app if the latter has no way of specifying the
>>character set.
>
> I hoped I might get away with it if it wasn't for those pesky UTF
> characters !
>
> Nick

You did. It displayed fine here.


--
Giovanna
Debian 6 user

[Richard Kettlewell]

Giovanna Stefani <giov...@notmail.com> writes:
> Nick Leverton scrive:

>> Mike Davies <nos...@no.nowhere.com> wrote:
>>> Nick Leverton wrote:
>>>
>>>> "Microware has defined a number of OS-9 disk formats for floppies,
>>>> the 38U0 one supposedly being the “universal” 3.5" format (there is
>>>> also a 58U0 “universal” 5¼" format).
>>>
>>>It's probably best not to cut and paste from a GUI app like a browser
>>>into a text-mode app if the latter has no way of specifying the
>>>character set.
>>
>> I hoped I might get away with it if it wasn't for those pesky UTF
>> characters !
>

> You did. It displayed fine here.

Where it works it only does so “by luck” - it lacked any header to
identify the character encoding used.

--
http://www.greenend.org.uk/rjk/

[Nick Leverton]

In article <87626jh...@araminta.anjou.terraraq.org.uk>,

Trn considerably antedates these new fangled non-ASCII character sets
and nobody's got round to adding them in yet ...

[Steve Niven]

On Tue, 09 Oct 2012 13:48:30 +0000, Nick Leverton wrote:

> Trn considerably antedates these new fangled non-ASCII character sets
> and nobody's got round to adding them in yet ...

𝚃𝚑𝚊𝚝'𝚜 𝚊 𝚙𝚒𝚝𝚢. 𝙸 𝚔𝚗𝚘𝚠 𝚝𝚑𝚊𝚝 𝚝𝚎𝚡𝚝-𝚖𝚘𝚍𝚎 𝚊𝚙𝚙𝚜 𝚌𝚊𝚗 𝚋𝚎 𝚏𝚊𝚜𝚝.

[Tony Houghton]

In <k51aqi$tf8$1...@news.datemas.de>,

slrn can do UTF-8 nowadays.

--
TH * http://www.realh.co.uk

[Steve Niven]

𝓣𝓱𝓪𝓽'𝓼 𝓰𝓸𝓸𝓭. 𝓔𝔁𝓬𝓾𝓼𝓮 𝓶𝔂 𝓱𝓪𝓷𝓭𝔀𝓻𝓲𝓽𝓲𝓷𝓰 '𝓬𝓸𝓼 𝓶𝔂 𝓴𝓮𝔂𝓫𝓸𝓪𝓻𝓭 𝓳𝓾𝓼𝓽 𝓫𝓻𝓸𝓴𝓮.

[Chris F.A. Johnson]

On 2012-10-09, Tony Houghton wrote:
> In <k51aqi$tf8$1...@news.datemas.de>,
> Steve Niven <s...@nowhere.invalid> wrote:
>
>> On Tue, 09 Oct 2012 13:48:30 +0000, Nick Leverton wrote:
>>
>>> Trn considerably antedates these new fangled non-ASCII character sets
>>> and nobody's got round to adding them in yet ...
>>

>> ????'? ? ????. ? ???? ???? ????-???? ???? ??? ?? ????.

>
> slrn can do UTF-8 nowadays.

I've heard that, but have been unable to get it to do so.


--
Chris F.A. Johnson <http://cfajohnson.com>
Author: =======================
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

[Theo Markettos]

Martin Gregorie <mar...@address-in-sig.invalid> wrote:
> I have some floppies (3.5", 1.4MB) with non-standard formatting which I
> need to copy into a disk image so an emulated system, which runs under
> Linux [Microware OS-9/68000 v2.4 in case you're curious], can read them.
> There are no Linux disk drivers available that can read these disks,
> hence the use of a disk image. The emulator, os9exec, can work with disk
> images in its native format or the Linux filing system.

try libdsk:
http://www.seasip.demon.co.uk/Unix/LibDsk/

Note that the floppy controllers in modern PCs are generally terrible, as is
the support for floppies in modern Linux. If you can run Linux 2.0 or 2.2
on the oldest machine you can find (eg a Pentium or P2) you might have more
luck. Debian slink, potato or woody might do the trick.

Theo

[Theo Markettos]

Tony Houghton <h...@realh.co.uk> wrote:
> slrn can do UTF-8 nowadays.

tin can too.

Theo

[Martin Gregorie]

On Tue, 09 Oct 2012 08:53:20 +0100, Dave Farrance wrote:

> Martin Gregorie <mar...@address-in-sig.invalid> wrote:
>
>>I have some floppies (3.5", 1.4MB) with non-standard formatting which I
>>need to copy into a disk image so an emulated system, which runs under
>>Linux [Microware OS-9/68000 v2.4 in case you're curious], can read them.
>
> Are you sure that it's 1.44MB? I recall working with a Microware
> OS-9/68000 system at some company in the 1980s and it had a 3.5" 720MB
> floppy drive. (I vaguely recall that it might've had 9 rather than 18
> sectors per track and half the usual data rate.)
>

Yes, absolutely. 80 track, DS, 34 x 256K blocks per track comes out
formatted at 1.32 MB. I have a relatively old (a few years) copy of my
OS-9 system plus the os9exec emulator on my Linux hard drive, so I was
able to fire it up and read the floppy disk descriptor with moded.

>>There are no Linux disk drivers available that can read these disks,
>>hence the use of a disk image. The emulator, os9exec, can work with disk
>>images in its native format or the Linux filing system.
>>
>>I thought I could make a suitable image with:
>> dd if=/dev/fd0 of=imagefile bs=256
>>
>>since the blocksize it uses is is 256 bytes, but all that happens is
>>that dd does nothing for a minute or so and then reports a read error
>>and exits after saying that zero records were read and written.
>>
>>What did I miss doing? Is dd not, in fact, the right tool for this job.
>>I know the disk drive is OK because it successfully mounted a DOS disk.
>
> I suspect that this is a non-trivial task. It's likely that the
> low-level sectoring is different somehow, even if it is 1.4MB. It's
> probably possible in theory to read it with a 3.5" floppy drive intended
> for a PC,
> but I suspect that a specialized driver would have to directly access
> the drive's controller chips, rather than the usual drivers.
>

I've found out a few things since I posted that, both from a bug report I
posted and by experiment:

- Since the systemd daemon management system replaced sysVinit in Fedora
distros (which more or less coincides with the move to Kernel 3.x, they
regard floppies as obsolete and the installer ignores them. The result
is that if the want to use floppys, you can either use
'modprobe floppy' as and when you need load the floppy driver or you
can create the file /etc/module-loads.d/floppy.conf with a single line
'floppy' alongside any #comments you feel like adding. This loads the
floppy driver at boot time,

- This suddenly made the floppy drive burst into life and let me mount
a DOS disk successfully and let dd make good disk images from it.

- However, it still absolutely refuses to read OS-9 formatted floppies.
My guess is that this is something to do with the floppy drivers:
for some reason it seems like they may not allow raw access to any
disks where they don't understand the format. A floppy drive
reads blocks full stop and does it without the need to recognise
anything inside the block. Could it be that it has to deal with the
interleave factor, since that's normally hard coded into the driver?

> So Googling something like "floppy media unknown format analysis" gives
> stuff that might be worth reading for ideas like:
> http://www.hp9845.net/9845/projects/fdio/
>

Yes indeed. I have a copy of anacron somewhere: maybe its worth digging
that out and seeing if it can do the job any better. That, if it works,
would leave the image on a Windows box, from where it can be ftped onto
the Linux system and tested.

> But it seems that it's a difficult enough task, that there exists a
> specialist company that will provide quotes for recovering OS-9 data
> (presumably costed according to whatever the market can bear, or the
> desperation of the customer) if you fill in a form detailing the job:
> http://www.reischke.de
>

Thanks for that: it should be trivial for anybody with a working OS-9
system: all I need is a set of LHA archives (one per floppy and only
three of those) put on a medium that Linux can read - say, an SD card.

But, it takes time and the need to ship one-off disks, so I'll look at
Anacron and have another attempt to get the OS-9 box to run before using
them.

[Martin Gregorie]

On Tue, 09 Oct 2012 08:08:22 +0000, Nick Leverton wrote:

> Microware don't seem to have used a format compatible with IBM PCs:
> http://cdibits.blogspot.co.uk/2011/10/cd-i-floppy-inventory.html
>

Thats scarcely surprising: OS-9 was up, running and on sale as a multi-
user, multi-tasking OS a good two years before the first IBM 5150
Personal Computer was announced and have always used directory
structures. Remind me how long it took M$/IBM to realise that directories
might be a good idea?

> "Microware has defined a number of OS-9 disk formats for floppies,
> the 38U0 one supposedly being the “universal” 3.5" format (there is
> also a 58U0 “universal” 5¼" format).
>

I've been aware that my kit would die some time - its been running like a
good 'un since 1992. I was aware that it would die some day and so I've
always had up to date backups.

My mistake was to leave them on OS-9 format floppies at least partly
because, although FAT-12 floppy drivers eventually arrived, they were and
are horribly slow. What I should have done was to move my backups onto
DOS-formatted CF cards (I even have an IDE interface for them) because
that would have fixed the speed issue.

> "The problem with the “universal” formats is that track zero can be
> (and on my floppies, is) in a different density which makes it a bad
> fit for most tools, both on CD-i and PC. "
>

That depends. Its the same density on the OS-9 disk format I'm using.
Can't recall the format name, but it uses 2 sided 80 track disks with 34
256 byte blocks on all tracks for a total capacity of around 1.32 MB.

[Tony Houghton]

In <58sdk9-...@cjlocal.com>,

Chris F.A. Johnson <cfajo...@gmail.com> wrote:

> On 2012-10-09, Tony Houghton wrote:
>> In <k51aqi$tf8$1...@news.datemas.de>,
>> Steve Niven <s...@nowhere.invalid> wrote:
>>
>>> On Tue, 09 Oct 2012 13:48:30 +0000, Nick Leverton wrote:
>>>
>>>> Trn considerably antedates these new fangled non-ASCII character sets
>>>> and nobody's got round to adding them in yet ...
>>>
>>> ????'? ? ????. ? ???? ???? ????-???? ???? ??? ?? ????.
>>
>> slrn can do UTF-8 nowadays.
>
> I've heard that, but have been unable to get it to do so.

I see you're on a 0.9.x release, it probably needs 1.x which has been
available as "pre-release" for ages.

[Martin Gregorie]

On Tue, 09 Oct 2012 09:53:17 +0100, chris wrote:

>
> You know the drive is OK, but can you be sure the disk is?
>

Yep, I know both the disks I tried are. Both were written within the last
few days on the drive I'm now attempting to read them on.

It also successfully made an image from a rather older DOS-format floppy,
probably made on the same drive, that must have been written by OS-9
using the PCFS IOManager rather than the more usual RBF IOManager (OS-9
is very modular) because the disk contents are:
(1) the C source of an OS-9 utility
(2) the corresponding OS-9 binary.

[Martin Gregorie]

On Tue, 09 Oct 2012 11:26:24 +0100, Dave Gibson wrote:

> Set the fd parameters first (untested):
>
> setfdprm /dev/fd0 COCO720
>

That looks interesting, but I don't have a copy. Its not installed on
either of my Linux boxes. Is it in a Fedora package? If not, where might
I find a copy?

[Martin Gregorie]

On Tue, 09 Oct 2012 17:51:10 +0100, Theo Markettos wrote:

>
> try libdsk:
> http://www.seasip.demon.co.uk/Unix/LibDsk/
>
> Note that the floppy controllers in modern PCs are generally terrible,
> as is the support for floppies in modern Linux. If you can run Linux
> 2.0 or 2.2 on the oldest machine you can find (eg a Pentium or P2) you
> might have more luck. Debian slink, potato or woody might do the trick.
>

Thanks, I'll look into that. As it happens I still have an ancient PC
that dual boots into Fedora Core 1, which sounds old enough to be worth a
try.

Actually, there is a Linux RBF driver still knocking around, but IIRC its
kernel 2.4. As I know nothing about kernel/driver programming or the
amount of hackery it would need to make it work with Kernel 3.x I've
rather ignored it.

OS-9 is very modular: there's total separation between the disk drivers
and the IO Manager. The IOManager presents a standard API to programs and
understands the logical disk structure, directories, files etc., and
thinks the disk is simply a list of sequentially numbered blocks. The
drivers understand the drive geometry and do the translation from block
number to surface/track/sector. I have two IOManagers installed: RBF (the
standard OS-9 disk structure) and PCFS (FAT-12 DOS structure). Both use
the same drivers to access a particular drive and any program can access
both RBF and FAT-12 format disks.

[Gordon]

Mounting a partion/file_system/disk does not try and read it. dd trys to
read sector by sector.

dd told you it could not read the disk. Now, we can be sure beyond
reasonable doubt that the disk is dead.

Try some other floppies if you have them. the dd command you give looks good
to me.

[Morten Nygaard Åsnes]

On 2012-10-09, Chris F.A. Johnson <cfajo...@gmail.com> wrote:
>> slrn can do UTF-8 nowadays.
>
> I've heard that, but have been unable to get it to do so.
>

I've got slrn (pre1.0.0-18) set up with

charset config utf-8
charset display utf-8
charset editor utf-8
charset outgoing utf-8

And my locale set to en_US.UTF-8
Works great.

--
Morten Nygaard Åsnes
http://www.twitter.com/mortenaa

[Chris F.A. Johnson]

On 2012-10-10, Morten Nygaard �snes wrote:
> On 2012-10-09, Chris F.A. Johnson <cfajo...@gmail.com> wrote:
>>> slrn can do UTF-8 nowadays.
>>
>> I've heard that, but have been unable to get it to do so.
>>
>
> I've got slrn (pre1.0.0-18) set up with
>
> charset config utf-8
> charset display utf-8
> charset editor utf-8
> charset outgoing utf-8
>
> And my locale set to en_US.UTF-8
> Works great.
>

Unsupport character set: utf-8
Default character set: isolatin
SUPPORTED CHARACTER SETS:
isolatin ibm850 ibm852 ibm857 ibm737 NeXT koi8
slrn fatal error:
Failed to select character set.

[Nick Leverton]

In article <dfcfk9-...@cjlocal.com>,

Chris F.A. Johnson <cfajo...@gmail.com> wrote:
>On 2012-10-10, Morten Nygaard �snes wrote:
>> On 2012-10-09, Chris F.A. Johnson <cfajo...@gmail.com> wrote:
>>>> slrn can do UTF-8 nowadays.
>>>
>>> I've heard that, but have been unable to get it to do so.
>>>
>>
>> I've got slrn (pre1.0.0-18) set up with
>>

>> And my locale set to en_US.UTF-8
>> Works great.

User-Agent: slrn/pre1.0.0-18 (Linux)

>Unsupport character set: utf-8
> Default character set: isolatin
> SUPPORTED CHARACTER SETS:
> isolatin ibm850 ibm852 ibm857 ibm737 NeXT koi8
>slrn fatal error:
>Failed to select character set.

User-Agent: slrn/0.9.8.1 (Linux)

HTH

[Daniel James]

In article <k526i7$dda$1...@localhost.localdomain>, Martin Gregorie wrote:
> My guess is that this is something to do with the floppy drivers:
> for some reason it seems like they may not allow raw access to any
> disks where they don't understand the format.

There's more to it than that.

> A floppy drive reads blocks full stop and does it without the need
> to recognise anything inside the block. Could it be that it has to
> deal with the interleave factor, since that's normally hard coded
> into the driver?

No. The floppy disk driver doesn't just "read blocks full stop", it has
to issue commands to the drive to tell it what sectors to read.

It may depend on the floppy disk controller chip being used, but IIRC at
least some FDCs need different command bytes to read sectors of
different sizes and densities.

I don't recall exactly how the PC's FDC works (I haven't written a
floppy disk formatter since CP/M-80 days, and the kit I used had a
Western Digital FDC rather than the Nec (?) thing the PC had (the WD
controllers would have happily allowed 10 sectors per track, so a 400k
floppy could really have been 400k, rather than 360 (or 320!))) ... but
I expect that's where the problem lies.

If that's so, you may be able to tell the driver to use 256-byte sectors
using setfdprm ... I've never had to use that -- and the man page is
terrible -- but I believe it's /meant/ to do what you need.

Cheers,
Daniel.

[Dave Gibson]

Martin Gregorie <mar...@address-in-sig.invalid> wrote:
> On Tue, 09 Oct 2012 11:26:24 +0100, Dave Gibson wrote:
>
>> Set the fd parameters first (untested):
>>
>> setfdprm /dev/fd0 COCO720
>>
> That looks interesting, but I don't have a copy. Its not installed on
> either of my Linux boxes. Is it in a Fedora package? If not, where might
> I find a copy?

fdutils.

<http://www.fdutils.linux.lu/>

<http://www.fdutils.linux.lu/fdutils-5.5.tar.gz>
<http://www.fdutils.linux.lu/fdutils-5.5-20081027.diff.gz>

Some (old?) version of setfdprm was also part of util-linux until version
2.13 (you need one with the 20081027 patch).


Here's how to build it:

tar xzf fdutils-5.5.tar.gz
cd fdutils-5.5
gzip -cd ../fdutils-5.5-20081027.diff.gz | patch -p1

#
# You'll probably need flex -l -P instead of lex -P.
# Some versions of flex won't like the -l there.
# Explicit archive creation required for make 3.82 work-around.
#
mv src/Makefile.in src/Makefile.in.orig &&
sed -e 's/lex -P/flex -l -P/' \
-e '/^libfdutils.a:.*/c\
libfdutils.a: $(LIBFILES)\
\tar r $@ $(LIBFILES)' < src/Makefile.in.orig > src/Makefile.in

# Hopefully your version of sed will expand '\t' to an actual tab.

# Depending on your installed kernel headers, src/fdmount.c may need
# to include <linux/fs.h> directly.
mv src/fdmount.c src/fdmount.c.orig &&
sed -e '/linux\/fd\.h.*/a\
#include <linux/fs.h>' < src/fdmount.c.orig > src/fdmount.c


# For installation, $pre is the general prefix, $cnf is the system
# configuration directory.

# pre=/usr
# cnf=/etc
pre=/usr/local
cnf=/usr/local/etc

./configure --prefix="$pre" \
--mandir='${prefix}/share/man' \
--infodir='${prefix}/share/info' \
--localstatedir=/var \
--sysconfdir="$cnf" \
--enable-fdmount-floppy-only &&
make



You're interested in src/setfdprm and the configuration file src/mediaprm.

You should be able to test-run setfdprm (as root, with a floppy in the
drive) without installing.

src/setfdprm /dev/fd0 DS DD sect=18 cyl=80 ssize=256 tpi=96 zero-based



#
# To install into a staging directory:
#

su

# make sure $pre and $cnf match those used with configure.
pre=/usr/local
cnf=/usr/local/etc
stage=/var/tmp/fdutils

mkdir -p -- "$stage/$pre" "$stage/$cnf"
make prefix="$stage/$pre" sysconfdir="$stage/$cnf" install

# Clean up a little
# better version of fd.4 in man-pages package
rm -- "$stage/$pre/share/man/man4/fd.4"
# empty directories.
rmdir -- "$stage/$pre/share/man/"man[48]

exit

[The Real Doctor]

Tin can? Allez!

Ian

[Theo Markettos]

Martin Gregorie <mar...@address-in-sig.invalid> wrote:
[libdsk]

> Thanks, I'll look into that. As it happens I still have an ancient PC
> that dual boots into Fedora Core 1, which sounds old enough to be worth a
> try.

I used it to read Acorn discs a decade ago, which is did fine. Some of the
same discs I tried on a modern PC (well, Athlon XP 2400+) running Ubuntu
11.10 and Linux couldn't cope. It could read DOS discs from the same era.
So I suspect the driver has bit-rotted. An additional issue is that
apparently single-density discs are poorly supported by modern floppy
controllers (modern=after about 1996), so if you have any those it's a
bigger problem.

> Actually, there is a Linux RBF driver still knocking around, but IIRC its
> kernel 2.4. As I know nothing about kernel/driver programming or the
> amount of hackery it would need to make it work with Kernel 3.x I've
> rather ignored it.

If you want to get data off the discs, I'd use libdsk or similar to get data
off the physical media and make image files. Then you could run an old
Linux distro in a VM with the appropriate filesystem and use that to mount
the images. Doesn't matter if the bits aren't all compatible with each
other - you're only doing this once.

Theo

[Theo Markettos]

Daniel James <dan...@me.invalid> wrote:
> No. The floppy disk driver doesn't just "read blocks full stop", it has
> to issue commands to the drive to tell it what sectors to read.
>
> It may depend on the floppy disk controller chip being used, but IIRC at
> least some FDCs need different command bytes to read sectors of
> different sizes and densities.

Correct, you need to tell the controller what data rate you're expecting
(250Kbps for a single density floppy, up to 2Mbps for a 2.88MB thing that
nobody actually used). I think it's written to a data rate register rather
than different commands, though. When you read or write sectors you need to
know how long they are - that information is encoded in the sector ID on the
disc.

But yes, the bottom line is there's no such thing as 'blocks'. It's quite
feasible to have a disc where every track is formatted to a different
density, sector length, and sector numbering pattern. (In fact, that's how
a lot of copy protection worked). You can find that out if you make a guess
at the density and listen out for the sector IDs, but just saying 'give me
block 47' isn't going to work until all those parameters are set up. And
possibly changed for the next track.

> If that's so, you may be able to tell the driver to use 256-byte sectors
> using setfdprm ... I've never had to use that -- and the man page is
> terrible -- but I believe it's /meant/ to do what you need.

Stupid question to the OP: you aren't using a USB floppy, are you? Here
you're in for a whole pile of pain. In theory, the USB floppy spec is quite
flexible, but in the Acorn case it fails because their sectors are numbered
from 0, not from 1 as DOS' are. The USB spec stupidly only allows access to
sectors numbered 1 upwards. And the other issue is that the driver may not
support the full variable sector sizes/etc even if the hardware does. Use a
motherboard floppy controller, USB floppies are one more thing to go wrong.

Theo

[Martin Gregorie]

On Thu, 11 Oct 2012 00:10:40 +0100, Theo Markettos wrote:

> Stupid question to the OP: you aren't using a USB floppy, are you?
>

Definitely not.

Its been a really long time since I dealt with a floppy drive &
controller at the register level: some time in the mid-80s to be precise,
when I scratch-wrote the disk access subroutines in the ROM monitor for
my Flex-09 (6809) box. I'd quite forgotten that you have to tell the
controller with the required sector ID and sector length before twisting
its tail and waiting for it to find the required sector.

Today I've been thinking about it and collecting software (fdutils and
LibDsk in case I really get stuck), and researching the LinuxRBF driver
to discover if (a) it can access floppys and (b) as it was written for
2.4 kernels and then upgraded to 2.6, has it been made compatible with
3.4 kernels.

BTW, fdutils is no longer part of the Fedora distro. LibDsk is meant to
run in user space and access its drive through the floppy driver, so
there's a chance that it will work.

[Martin Gregorie]

On Wed, 10 Oct 2012 23:52:49 +0100, Theo Markettos wrote:

> Martin Gregorie <mar...@address-in-sig.invalid> wrote:
> [libdsk]
>> Thanks, I'll look into that. As it happens I still have an ancient PC
>> that dual boots into Fedora Core 1, which sounds old enough to be worth
>> a try.
>
> I used it to read Acorn discs a decade ago, which is did fine. Some of
> the same discs I tried on a modern PC (well, Athlon XP 2400+) running
> Ubuntu 11.10 and Linux couldn't cope. It could read DOS discs from the
> same era. So I suspect the driver has bit-rotted. An additional issue
> is that apparently single-density discs are poorly supported by modern
> floppy controllers (modern=after about 1996), so if you have any those
> it's a bigger problem.
>

Either that or the floppy driver's ABI has changed during the last 10
years. However, the copy of LibDsk I've found is dated 2010, so its
probably been adjusted to a 2.6 floppy driver - but does that mean it
works with a 3.4 one?

>> Actually, there is a Linux RBF driver still knocking around, but IIRC
>> its kernel 2.4. As I know nothing about kernel/driver programming or
>> the amount of hackery it would need to make it work with Kernel 3.x
>> I've rather ignored it.
>
> If you want to get data off the discs, I'd use libdsk or similar to get
> data off the physical media and make image files.
>

The data files are to be fed to an OS-9 emulator that can directly access
the Linux filing system or 'mount' a disk image, so I don't much care
whether I end up with a disk image or with the data files transcribed
onto DOS media (either floppy or flash is fine - my Linux box can read
both.

> Then you could run an
> old Linux distro in a VM with the appropriate filesystem and use that to
> mount the images. Doesn't matter if the bits aren't all compatible with
> each other - you're only doing this once.
>

Would you believe I still have an ancient, slow AMD K6 based box with
Fedora Core 1 installed? IIRC that's kernel 2.4. It has floppys and is
networked to my F16 box, so I don't care which box's hdd the files end up
on initially.

[Richard Kettlewell]

Theo Markettos <theom...@chiark.greenend.org.uk> writes:
> Correct, you need to tell the controller what data rate you're expecting
> (250Kbps for a single density floppy, up to 2Mbps for a 2.88MB thing that
> nobody actually used).

Not _quite_ nobody...

--
http://www.greenend.org.uk/rjk/

[Whiskers]

Just remember to keep the string tight.

--
-- ^^^^^^^^^^
-- Whiskers
-- ~~~~~~~~~~

[Martin Gregorie]

I've now got the first and most important disk imaged using dd and the
contents of the fdutils package. The image is clean: os9exec mounted it
without complaint (it has to read the first 256 bytes and like what's in
them to do this), lha successfully verified the archive in the disk and
unpacked it into the /dd (main hard disk) image.

I did this by using setfdprm from fdutils 5.5 to tweak the parameters in
floppy.ko on my Fedora 16 (kernel 3.4) system and then reading the disk
with dd. The OS-9 disks I need to read were recorded in a 3.5" HD (1.4
MB) drive. They are formatted using 34 sectors per track, two sides and
80 tracks. The sectors are 256 bytes and, the main reason I couldn't
initially read the disks, the track and sector indexes are zero based
rather than using the more usual 1-base.

Once I started playing with setfdprm I was able to read 8KB (i.e. 33
blocks plus a bit of crud and so had something to look at: it was
immediately obvious that the first (ID block) had been skipped over and
there was a clue in the /usr/local/etc/mediaprm file, which defined the
OS-9 level 1 disks for the Color Computer required 'zero-based'. Once I'd
worked out how to get that accepted (see below) I was able to read the
day-1 backup disk I'd been using for testing with 'conv=noerror' set on
dd, but although the disk was mountable it wasn't clean. Fortunately, the
day-0 backup read cleanly on first try with no errors being reported.

Problems.
=========
As another poster said, the documentation for fdutils isn't great: a huge
understatement. Its not only badly organised and an 'info' package, but
its internally inconsistent (there are at least four different names and
locations given for the disk formats library) but incomplete (there's no
mention of the 'zerobased' parameter that I could see).

'fdmount' won't compile because it needs a header that lives deep in the
kernel-specific file structure and there's no simple way to tell make
where it lives: I don't need fdmount so commented it out of 'make all'.

'make install' failed to install the disk format library so I copied in
in place manually.

Parameter names are not consistent in the code: the zero based flag
appears in the code as both 'zero-based' and 'zerobased': as the code
stands both names upset one of the programs. Even worse, setfdprm
expected 'zerobased' if supplied from the command line, but 'zero-based'
in the disk format library. So, I did a search&destroy through the source
to standardise on 'zerobased' and then edited the disk format library to
use 'zerobased'. This was needed because this value is defined by string
literals scattered through the codebase rather than as a single #define
in a header. That problem fixed, I was able to successfully read a floppy
with zero based track and sector indexing.

Summary: this is a useful package. A lot of effort has obviously gone
into it, so its a pity that the documentation is so unfriendly and that
the build is flawed. I'll provide feed back to its maintainer about these
problems and will also document the particular OS-9 floppy format that my
system uses.

Thanks to all on ucol who helped me solve this problem: my accounting
system is up and running again and the other stuff I use OS-9 for will
shortly be joining it.

[Mike Tomlinson]

En el artículo <spj778pgiqrba5hq9...@4ax.com>, Dave
Farrance <DaveFa...@OMiTTHiSyahooANDTHiS.co.uk> escribió:

>Are you sure that it's 1.44MB? I recall working with a Microware
>OS-9/68000 system at some company in the 1980s and it had a 3.5" 720MB

720KB :-)

>floppy drive. (I vaguely recall that it might've had 9 rather than 18
>sectors per track and half the usual data rate.)

That would be single-density, as used with the original Acorn DFS in the
BBC micro using the Intel 8271 controller.

To the OP: I see you've solved your problem, but in case it's useful:

There are older utilities that talk to the PC disk controller at a low
level and can successfully read and image disks with odd formats. They
have to be run in DOS to obtain the required access to the disk
controller hardware. Google the following: Anadisk, FDC.

On Windows 9x/Me, which run on top of DOS, google OmniDisk.

You will probably get good results with OmniFlop, which runs under
modern Windows using its own floppy controller driver to get the
required hardware access:

http://www.shlock.co.uk/Utils/OmniFlop/OmniFlop.htm

OK, so it's not Linux. Sue me. :-)

As another poster pointed out, floppy controllers in modern PCs are crap
and/or can't deal with single density. You'll get the best results if
you use a machine with a genuine 8272 or uPD765 or close compatible
floppy controller, which means finding an old one, something from the
486 or early Pentium era. You mention in another post that you have an
AMD Kn-based system; that'd probably be perfect.

--
(\_/)
(='.'=)
(")_(")

[tin...@isbd.co.uk]

Mike Tomlinson <mi...@jasper.org.uk> wrote:
> En el artículo <spj778pgiqrba5hq9...@4ax.com>, Dave
> Farrance <DaveFa...@OMiTTHiSyahooANDTHiS.co.uk> escribió:
>
> >Are you sure that it's 1.44MB? I recall working with a Microware
> >OS-9/68000 system at some company in the 1980s and it had a 3.5" 720MB
>
> 720KB :-)
>
> >floppy drive. (I vaguely recall that it might've had 9 rather than 18
> >sectors per track and half the usual data rate.)
>
> That would be single-density, as used with the original Acorn DFS in the
> BBC micro using the Intel 8271 controller.
>

Double density I think. The 1.44Mb ones are called High Density which
was the next step.

5.25" disks came in single density (360k), double density (720k) and
high density (1.2Mb) and I'm pretty sure that 1.44Mb 3.5" disks were
(are?) also called high Density.

--
Chris Green

[Mike Tomlinson]

En el artículo <usb2l9-...@chris.zbmc.eu>, tin...@isbd.co.uk
escribió:

>Mike Tomlinson <mi...@jasper.org.uk> wrote:
>> En el artículo <spj778pgiqrba5hq9...@4ax.com>, Dave
>> Farrance <DaveFa...@OMiTTHiSyahooANDTHiS.co.uk> escribió:
>>
>> >Are you sure that it's 1.44MB? I recall working with a Microware
>> >OS-9/68000 system at some company in the 1980s and it had a 3.5" 720MB
>>
>> 720KB :-)
>>
>> >floppy drive. (I vaguely recall that it might've had 9 rather than 18
>> >sectors per track and half the usual data rate.)
>>
>> That would be single-density, as used with the original Acorn DFS in the
>> BBC micro using the Intel 8271 controller.
>>
>Double density I think.

no, the words 'half the usual data rate' are the clue. These are FM-
encoded disks, i.e. single density. Double density is MFM.

> The 1.44Mb ones are called High Density

yes.

>5.25" disks came in single density (360k), double density (720k) and
>high density (1.2Mb) and

There's data density and track density.

In the PC world, 360k 5.25" disks are 40 track, double density, double
sided. There were no 720k 5.25" drives - that came in with 3.5" drives,
and those are 80 track, double density, double sided.

1.2Mb 5.25" drives are 80 track, double sided, high density. The
correct disk has to be used - double density disks might work but will
not be reliable; the magnetic coercivity is different.

>I'm pretty sure that 1.44Mb 3.5" disks were
>(are?) also called high Density.

they are. Like 1.2Mb 5.25" disks, the recording surface is different,
and there's an extra hole in the disk to tell the drive a high density
disk is present and to modify the write current accordingly.

[Martin Gregorie]

On Wed, 17 Oct 2012 06:18:48 +0100, Mike Tomlinson wrote:

> To the OP: I see you've solved your problem, but in case it's useful:
>

Yes indeed. The combination of setfdprm and dd seems pretty capable and
I'd guess that if I replaced the 3.5" HD drive with an old DS/DD 80 trk
or a SS/DD 40 trk drive (yes, I have these and they still work) I'd be
able to image my Flex09 floppies too. That's on the list of Things To Do,
if only to let the Flex Users Group know if it works.

> There are older utilities that talk to the PC disk controller at a low
> level and can successfully read and image disks with odd formats. They
> have to be run in DOS to obtain the required access to the disk
> controller hardware. Google the following: Anadisk, FDC.
>

I tried Anadisk on the Flex09 disks but I'm not convinced that it did a
particularly good job: I don't have a usable emulator to try them on at
present. In any case Flex09 disks need to be fettled with Ana2dsk after
Anadisk has done its thing.

> On Windows 9x/Me, which run on top of DOS, google OmniDisk.
>
> You will probably get good results with OmniFlop, which runs under
> modern Windows using its own floppy controller driver to get the
> required hardware access:
>
> http://www.shlock.co.uk/Utils/OmniFlop/OmniFlop.htm
>

Noted, but I'd guess that at a pinch Anadisk and OmniDsk might work on
DosBox - it would be worth a try, anyway.

> As another poster pointed out, floppy controllers in modern PCs are crap
> and/or can't deal with single density. You'll get the best results if
> you use a machine with a genuine 8272 or uPD765 or close compatible
> floppy controller, which means finding an old one, something from the
> 486 or early Pentium era. You mention in another post that you have an
> AMD Kn-based system; that'd probably be perfect.
>

In view of that, I was a little surprised that the setfdprm/dd
combination worked as well as it did on my dual Athlon box under kernel
3.4.

And, there's always the possibility of writing a program to use the LibDsk
floppy munging library. I have the library but haven't done anything with
it so far.