cbm1581 in Linux
bighair
1581 floppy disk driver. I downloaded it from Dan's Software page at
http://www.npsnet.com/danf/software/ but I was unable to build the
source because it was targetted at a much older kernel.
Is there anyone here who's made the necessary changes to get it to
compile under a 2.4.x series kernel?
Thanks in advance,
-bighair
Wolfgang Moser
I don't know such a already patched version. There's a patch for
kernel versions 2.2.x at:
http://www.acc.umu.se/~tao/linux/patches.html
Maybe that works.
Another question: Why not simply transferring raw disk images and
handling the files inside with Marko Mäkelä's cbmconvert?
http://www.funet.fi/pub/cbm/crossplatform/converters/unix/index.html
Womo
bighair
Wolfgang Moser <wn...@d81.de> wrote in message news:<3CC47143...@d81.de>...
> Hi big hair,
>
> > I'm running RedHat Linux 7.2 and I'd like to be able to compile the
> > 1581 floppy disk driver. I downloaded it from Dan's Software page at
> > http://www.npsnet.com/danf/software/ but I was unable to build the
> > source because it was targetted at a much older kernel.
> >
> > Is there anyone here who's made the necessary changes to get it to
> > compile under a 2.4.x series kernel?
>
> I don't know such a already patched version. There's a patch for
> kernel versions 2.2.x at:
> http://www.acc.umu.se/~tao/linux/patches.html
>
> Maybe that works.
I've downloaded it and I'll check it out soon. Hopefully it will
work!
>
> Another question: Why not simply transferring raw disk images and
> handling the files inside with Marko Mäkelä's cbmconvert?
>
> http://www.funet.fi/pub/cbm/crossplatform/converters/unix/index.html
>
Well, I could possibly create raw disk images with my real C64, but
I'm not sure if I still have my 1581 disk drive. I figured I would
try the C64 filesystem driver first rather than rummage through my
storage getting the C64 parts together.
Of course, that part is inevitable. :)
Thanks for your help!
-bighair
>
> Womo
Wolfgang Moser
bighair wrote:
> ...
> > Another question: Why not simply transferring raw disk images and
> > handling the files inside with Marko Mäkelä's cbmconvert?
>
> Well, I could possibly create raw disk images with my real C64, but
> I'm not sure if I still have my 1581 disk drive. I figured I would
What are you talking about? You can create raw disk images
with your linux box. All you need to check out is the floppy
disk parameter set file at /etc/fdparm, if it contains the
parameter set for 1581 floppy disks. I'm not sure, if this
is all to do. Then you should be able to dump the disk to
an image file with dd or perhaps with cat like:
cat /dev/fd0 > 1581image.d81
You should find some hints in Dan Fandrich's filesystem
driver set or on Alain Knaff's (linux floppy disk driver
developer) homepage:
http://www.tux.org/pub/people/alain-knaff/
Check out his fdutils for a collections of information about
the linux floppy disk driver:
http://www.tux.org/pub/people/alain-knaff/fdutils/index.html
I hope this helps, Womo
bighair
> Hi bighair,
>
> bighair wrote:
> > ...
> > > Another question: Why not simply transferring raw disk images and
> > > handling the files inside with Marko Mäkelä's cbmconvert?
> >
> > Well, I could possibly create raw disk images with my real C64, but
> > I'm not sure if I still have my 1581 disk drive. I figured I would
>
> What are you talking about? You can create raw disk images
> with your linux box. All you need to check out is the floppy
> disk parameter set file at /etc/fdparm, if it contains the
I wasn't aware you could do that! Cool. I think I see now. The
cbm1581 driver is only for interpreting the file system itself. If
you don't care and want to create a raw disk image (to be interpreted
by a C64 emulator), you can just use the Linux 'dd' command and the
right floppy disk parameters.
Now for the $1,000,000 questions -- (1) can you do the same for 5-1/4"
disks if you have a 5-1/4" drive? (2) What about copy protected
disks?
Thanks again, Wolfgang!
-bighair
Wolfgang Moser
> I wasn't aware you could do that! Cool. I think I see now. The
> cbm1581 driver is only for interpreting the file system itself. If
Exactly.
> you don't care and want to create a raw disk image (to be interpreted
> by a C64 emulator), you can just use the Linux 'dd' command and the
> right floppy disk parameters.
You got it. About the floppy disk parameters I had a discussion
with Marko Mäkelä some years ago, because I found out, that a
slightly modified parameter set would be a little bit better.
I put a desired fdparm file into my 1581-Copy package, here it is:
<textmode /etc/fdparm>
# /etc/fdprm - floppy disk parameter table
# standard floppy disk parameters are left out, you have to add
# them again
# This could be a better entry for Dan Fandrichs cbmfs-0.3 driver.
# I think, the following GAP sizes are much more compatible:
cbm1581 1600 10 2 80 2 0x0C 0x02 0xDF 0x23
# CBMFS does only support the CBM 1581 file system, but if you want to
# transfer only images from and to the different CBM formatted 3,5"
# disks, you won't need CBMFS. The desired FDPRM entry will be enough.
#
# After you inserted such a disk into the floppy drive you have to
# specify the right format, e.g. for a CBM 1581 disk do:
#
# setfdprm /dev/fd0 cbm1581
#
# After having specified the disk format to use, you can transfer the
# sectors between the floppy disk and an image with:
#
# cat image.d81 > /dev/fd0
# or
# cat /dev/fd0 > image.d81
#
# fdformat can be used for formatting specified disks:
#
# fdformat /dev/fd0
#
#
# The following parameter can be used for transferring CMD FD2000 disk
# into disk images under Linux. Don't ask, why there are 20 sectors
# per track specified, the FDFORMATted disk contains definetly only 10
# sectors per track with a sector size of 1024 bytes per sector. Until
# now, I didn't know, that some of the upper bits of the rate specifier
# hold the sector size information (all the other HD formats hold a
# value of 0x00 instead of 0x08 for the CMD FD2000 disks). Marko Mäkelä
# told me, that he found some information about these bits in the
# sources of the Linux floppy drivers, but I didn't check it myself.
# It's enough for me, that this parameter does work.
#
# Finally Jochen Adler sent me some details from the CMD FD2000 floppy
# manual, that contains informations about the different formats, so
# that I'm very sure now, that the CMD FD2000 parameter is ok now.
cmdfd2m 3240 20 2 81 2 0x0C 0x08 0xCF 0x64
# The following assumptions for CMD's floppy drives FD1000 and FD4000
# respective their native disk formats have not been tested
# cmdfd1m 1620 10 2 81 2 0x0C 0x02 0xDF 0x23
# cmdfd4m 6480 40 2 81 2 0x0C 0x08 0xCF 0x64
</textmode /etc/fdparm>
> Now for the $1,000,000 questions --
> (1) can you do the same for 5-1/4" disks if you have a 5-1/4" drive?
No, you can't. This is because the floppy disk controller
decodes MFM disks _only_ and because it does it in _hardware_.
You aren't able to catch the physical bit stream out of the
disk drive, so that someone would be able to decode the
bit stream with a pure software solution (like the 1541).
1541 disks are formatted with a GCR encoding which is in
no way compatible with a MFM or FM encoding. Therefore a
standard PC floppy disk controller cannot read 1541 disk
and it cannot write such disks for sure.
You may have a look into the Disk2FDI software system,
check out the provided documents within the package. It
contains a __very__ interesting way, how GCR disk reading
could possibly work!
http://www.oldskool.org/disk2fdi
This software is able to read non-standard-MFM encoded
Amiga disk into FDI image files.
Another attempt is to use another floppy disk controller
hardware that allows to read the physical bit stream into
memory for software decoding, the Catweasel, which is
available as PC-ISA card:
http://www.jschoenfeld.com/products/catweasel_e.htm
Another cheaper attempt is the ADF-Reader, where you
only need to connect serial data line from the floppy
disk drive to the IRQ input of you parallel port:
http://home.t-online.de/home/ChristianK./adr-project/hardware-e.html
I tried to some similar for reading 1541 disks under
DOS, but never got it to work. Maybe his new linux
kernel driver concept works a lot better. Sure,
currently it supports Amiga disks only, but because
all decoding is done in software, it should really
be possible for 1541 disks, too.
Conceptionally ADF-Reader would be the best solution
in my opinion.
> (2) What about copy protected disks?
1541: Like (1), it doesn't work. But if you would be able
to catch the physical stream in combination with
precise time stamps, nearly every copy protection
should be no problem.
1581: I never heard about 1581 copy protections. Well,
there are some disks with incompatible formats
(disks copied with Maverick), but for 1581-Copy,
the 1581 raw disk reader for DOS, I managed to
read and write such disks, too.
Womo
bighair
Wolfgang Moser <wn...@d81.de> wrote in message news:<3CCA625D...@d81.de>...
...
> You got it. About the floppy disk parameters I had a discussion
> with Marko Mäkelä some years ago, because I found out, that a
> slightly modified parameter set would be a little bit better.
> I put a desired fdparm file into my 1581-Copy package, here it is:
...
Thank you for updated floppy parameter info. It will undoubtedly come
in handy.
>
>
> > Now for the $1,000,000 questions --
> > (1) can you do the same for 5-1/4" disks if you have a 5-1/4" drive?
>
> No, you can't. This is because the floppy disk controller
> decodes MFM disks _only_ and because it does it in _hardware_.
> You aren't able to catch the physical bit stream out of the
> disk drive, so that someone would be able to decode the
> bit stream with a pure software solution (like the 1541).
>
> 1541 disks are formatted with a GCR encoding which is in
> no way compatible with a MFM or FM encoding. Therefore a
> standard PC floppy disk controller cannot read 1541 disk
> and it cannot write such disks for sure.
>
...
Very interesting! I wasn't aware that there was an underlying
encoding format, but that totally makes sense.
Now, I have another question, but I will save it for a new thread. :)
Thank you for sharing your very detailed knowledge with me (and the
other ng readers). Much appreciated!
-bighair