Raw floppy image
Kevin Handy
for use with an emulator?
Using 22disk, or any of the other disk read programs I've found,
creates a "compressed" image with extra headers which is not
acceptable to the emulators, who just want "raw" images.
Is there a program that generates raw image files, or something that
will convert a 22disk image file into a raw image?
Al Kossow
> Is there some way to generate raw floppy disk images of CP/M disks
> for use with an emulator?
>
Look for "libdmk" on sourceforge. There are a couple of small Linux
programs included which can use a PC FDC to read a disc creating a .DMK
formatted output, and DMK2RAW which will convert that to just sector
data.
Al Kossow
oops, dmklib, not libdmk
http://sourceforge.net/projects/dmklib/
John Elliott
: From article <3EDE62E0...@srv.net>, by Kevin Handy <k...@srv.net>:
Alternatively, LibDsk <http://www.seasip.demon.co.uk/Unix/LibDsk/> can
do the same sort of thing, with a command like
dsktrans /dev/fd0 filename.ufi -otype=raw
It really depends on what format your disks are in. LibDsk and dmklib both
support a range of formats, but by no means all (eg: dmklib fails to
recognise PCW disks; LibDsk gets Apricot Xi floppies completely wrong).
(UFI = Uncompressed Floppy Image. Other filetypes for uncompressed
floppies include .IMG, .RAW or .DSK, but these all conflict with compressed
floppy images or graphics files).
--
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Dosius
> Alternatively, LibDsk <http://www.seasip.demon.co.uk/Unix/LibDsk/> can
> do the same sort of thing, with a command like
>
> dsktrans /dev/fd0 filename.ufi -otype=raw
>
> It really depends on what format your disks are in. LibDsk and dmklib both
> support a range of formats, but by no means all (eg: dmklib fails to
> recognise PCW disks; LibDsk gets Apricot Xi floppies completely wrong).
>
> (UFI = Uncompressed Floppy Image. Other filetypes for uncompressed
> floppies include .IMG, .RAW or .DSK, but these all conflict with compressed
> floppy images or graphics files).
.dsk is often used for uncompressed Apple ][ and CoCo disks anyway...
I use .160, .320, .180, .360, .720, .144 as common extensions for raw disks.
-uso.
Arobase, Salle multimédia
By the way, John, since you are English, do you know any
program running on an IBM PC which could read
ICL Quattro floppies?
22DISK does not know it.
Yours Sincerely,
"French Luser"
John Elliott
:> (...) LibDsk gets Apricot Xi floppies completely wrong).
: By the way, John, since you are English, do you know any
: program running on an IBM PC which could read
: ICL Quattro floppies?
Don't know. Never seen an ICL Quattro floppy. I believe you've tried
Anadisk; have you tried Disk2FDI?
Kevin Handy
> Al Kossow <a...@spies.com> wrote:
> : From article <3EDE62E0...@srv.net>, by Kevin Handy <k...@srv.net>:
> :> Is there some way to generate raw floppy disk images of CP/M disks
> :> for use with an emulator?
> :>
>
> : Look for "libdmk" on sourceforge. There are a couple of small Linux
> : programs included which can use a PC FDC to read a disc creating a .DMK
> : formatted output, and DMK2RAW which will convert that to just sector
> : data.
>
> Alternatively, LibDsk <http://www.seasip.demon.co.uk/Unix/LibDsk/> can
> do the same sort of thing, with a command like
>
> dsktrans /dev/fd0 filename.ufi -otype=raw
>
> It really depends on what format your disks are in. LibDsk and dmklib both
> support a range of formats, but by no means all (eg: dmklib fails to
> recognise PCW disks; LibDsk gets Apricot Xi floppies completely wrong).
>
> (UFI = Uncompressed Floppy Image. Other filetypes for uncompressed
> floppies include .IMG, .RAW or .DSK, but these all conflict with compressed
> floppy images or graphics files).
>
Aaack! I've been trying to use these programs, but cannot
get them to work on any of my Linux boxes to read Kaypro-II
disks. The only system I have that seems to be able to read
them is a 286 with a 360K floppy drive in it. Putting this
drive in a newer system doesn't work.
The only programs I have that will read the disks are 22disk,
and it's relatives, which create an image in their own special
format (and won't create raw images). Is the format it stores
them in documented anywhere so a raw image could be created
from one of these images?
An alternative would be a sector dump program running on
the Kaypro, which I could connect to a Linux box (kermit) and
capture the dump. Are there any programs like this for CPM?
Frankie Zsitvay
Kevin Handy wrote:
>
> John Elliott wrote:
> > Al Kossow <a...@spies.com> wrote:
> > : From article <3EDE62E0...@srv.net>, by Kevin Handy <k...@srv.net>:
> > :> Is there some way to generate raw floppy disk images of CP/M disks
> > :> for use with an emulator?
> > :>
> >
> > : Look for "libdmk" on sourceforge. There are a couple of small Linux
> > : programs included which can use a PC FDC to read a disc creating a .DMK
> > : formatted output, and DMK2RAW which will convert that to just sector
> > : data.
> >
> > Alternatively, LibDsk <http://www.seasip.demon.co.uk/Unix/LibDsk/> can
> > do the same sort of thing, with a command like
> >
> > dsktrans /dev/fd0 filename.ufi -otype=raw
> >
> > It really depends on what format your disks are in. LibDsk and dmklib both
> > support a range of formats, but by no means all (eg: dmklib fails to
> > recognise PCW disks; LibDsk gets Apricot Xi floppies completely wrong).
> >
> > (UFI = Uncompressed Floppy Image. Other filetypes for uncompressed
> > floppies include .IMG, .RAW or .DSK, but these all conflict with compressed
> > floppy images or graphics files).
> >
>
> Aaack! I've been trying to use these programs, but cannot
> get them to work on any of my Linux boxes to read Kaypro-II
> disks. The only system I have that seems to be able to read
> them is a 286 with a 360K floppy drive in it. Putting this
> drive in a newer system doesn't work.
Probably because many newer controllers are designed to work
with 360 rpm high density drives and use a 300 kbps data rate.
Since a 360K floppy drive only spins at 300 rpm, the data rate
is off by 16%.
Find a good configurable HD drive like an older Teac and set
up properly. It should work.
-Frankie
Harold Bower
Frankie Zsitvay <fr...@rdwarf.com> wrote:
>
> John Elliott wrote:
> > Aaack! I've been trying to use these programs, but cannot
> > get them to work on any of my Linux boxes to read Kaypro-II
> > disks. The only system I have that seems to be able to read
> > them is a 286 with a 360K floppy drive in it. Putting this
> > drive in a newer system doesn't work.
>
> Probably because many newer controllers are designed to work
> with 360 rpm high density drives and use a 300 kbps data rate.
> Since a 360K floppy drive only spins at 300 rpm, the data rate
> is off by 16%.
The data rate accuracy is not an issue. In newer controllers (which
were in later '286 class machines as well), the data rate was changed in
5.25" disks so that they would be close to the 250 kbps used in 5.25"
diskettes as opposed to changing the motor speed which some (noteably
TEAC) did wtih the early "1.2 MB" 5.25" drives. 300 kbps at 360 rpm
results in the same bit density on the media as 250 kbps at 300 rpm
(which the 40-track and "800 k" 80 track floppies used.
Unless John is using a special program (ANADISK?) to read the disks, the
problem is one of formats, and the fact that Kaypros numbered sectors
starting with 0, while most others started at 1. The NEC 765 derivative
chips don't seem to like zeros.
Hal
John Elliott
: On Wed, 11 Jun 2003 09:12:20 GMT
: Frankie Zsitvay <fr...@rdwarf.com> wrote:
:>
:> John Elliott wrote:
:> > Aaack! I've been trying to use these programs, but cannot
That wasn't me. Someone's mangled the quoting.
dwight elvey
Hi
I believe that there is a track read in these chips that may get
around the sector 0 problem. Otherwise, it would make more sense
to setup a serial transfer of images. I'm currently doing just
that for my H89. I'm working with a friend that has a H/Z90. It
has a few added features that broke my original code but we
are now making progress.
Dwight
Frankie Zsitvay
Try again. Read the old posts. The Aaack! was from a Linux
user crying about how his newer Linux box cannot read a Kaypro
II disk like his older 286 box can, even if he swaps the disk
drive itself over. This definately quacks like a controller
issue.
-Frankie
> Hal
Amardeep S Chana
news:43258753.03061...@posting.google.com...
> > problem is one of formats, and the fact that Kaypros numbered sectors
> > starting with 0, while most others started at 1. The NEC 765 derivative
> > chips don't seem to like zeros.
> >
> > Hal
>
> Hi
> I believe that there is a track read in these chips that may get
> around the sector 0 problem. Otherwise, it would make more sense
> to setup a serial transfer of images. I'm currently doing just
> that for my H89. I'm working with a friend that has a H/Z90. It
> has a few added features that broke my original code but we
> are now making progress.
> Dwight
What is this alleged "sector 0" problem on the 765 core? Can anyone
characterize it or is it just hearsay?
In my own experience, the 765 core can address sector zero perfectly well.
There IS an issue with reading the first physical sector after the index
hole if the post index gap is too short regardless of the number in its
header.
Amardeep
Harold F. Bower
"Amardeep S Chana" <asc...@despammed.com> wrote:
> What is this alleged "sector 0" problem on the 765 core? Can anyone
> characterize it or is it just hearsay?
Most code that tries to set up disk parameters by reading a sector from
the diskette seems to start by reading Head 0, Track 0, Sector 1 and,
based on the characteristics, set BIOS and controller characteristics
appropriately (based on the old Ampro Little Board mechanisms). The
Sector 0 situation required a second read if certain sector size and
density settings might match the Kaypro (which started at Sector 0,
whereas the Ampro/Micromint/On! and others started at 1). With respect
to the 765, it was not so much a problem as more code being required
than with WD chips.
I don't believe that MS-DOS/IBM "PC"s can read a diskette with a sector
0, but assume that tracks start at '1'. That is why I said "Unless John
is using a special program (ANADISK?) to read the disks,..".
The 765-derivative chips did have what could definitely be considered a
problem with other bytes in the Inter-record gaps. I have a diskette
that someone sent me when I was working on the B/P Bios emulation
library that I could never get to work on 765-type controllers, but read
on all WD (1771/2, 1791/3, etc) that I tried. IIRC, that diskette
format used 00H as the "Head 0" byte and 0FFH for "Head 1".
> In my own experience, the 765 core can address sector zero perfectly
> well. There IS an issue with reading the first physical sector after
> the index hole if the post index gap is too short regardless of the
> number in its header.
Yes, the Gap3 size (which is the only adjustable one in this class
controller) is very sensitive to that one, whereas all the gaps are
defineable in WD chips which allowed considerable latitude in 'tweaking'
performance for a single system... provided that you weren't worried
about exchanging diskettes with any other system.
dwight elvey
Hi
The spec for this type of floppy states that the sectors are to
be numbered 1 through s and the tracks 0 through t. It may be that
you can read the sector by directly addressing it but I bet
that you could not auto read it as a multi sector read. This
is because in this mode, 1 would be the first sector of the
next track.
Someone will have to give it a try to see if single sector
addressing works.
Dwight
John Elliott
: "Amardeep S Chana" <asc...@despammed.com> wrote in message news:<bI_Fa.1226$G7....@news02.roc.ny.frontiernet.net>...
:> What is this alleged "sector 0" problem on the 765 core? Can anyone
:> characterize it or is it just hearsay?
:>
:> In my own experience, the 765 core can address sector zero perfectly well.
:> There IS an issue with reading the first physical sector after the index
:> hole if the post index gap is too short regardless of the number in its
: Someone will have to give it a try to see if single sector
: addressing works.
I can confirm that every 765 or derivative I've tested has been able to
read Acorn floppies, which have sector numbers starting at 0.