3 Nov
2022
3 Nov
'22
2:07 p.m.
Hi,
n00b alert
Does anyone have a 101 level boot strap guide for someone wanting to get
into creating better-than-dd disk images?
I'm finding myself back in a position where I want to image / preserve
multiple 5¼ & 3½ inch disks. I think all of them are PC compatible
disks. Probably standard FAT-12 and a handful of super capacity disk
formats from the likes of IBM / Microsoft where they tried to squeeze
1.6 (?) MB on a 3½ inch disk.
I have an internal 5¼ inch floppy drive that is in unknown condition
(I've never used / tested it since I got it).
I also have (at least one) 5¼ disk that I acquired as a scratch monkey
disk to test on before working on disks that I care more about.
I was thinking about acquiring a Kryoflux in the next few months and
starting to collect better quality images of disks. I recently saw
someone on Twitter suggest that Kryoflux wasn't the best route to go and
suggested a SuperCard Pro instead.
I had been using the dd command under Linux against a USB connected 3½
inch floppy drive for most things. But I've come to learn that's not as
good as some people would like to see preserved.
So, does anyone have a 101 level boot strap guide for someone wanting to
get into creating better-than-dd disk images?
--
Grant. . . .
unix || die
3 Nov
3 Nov
2:20 p.m.
I would recommend a Greaseweazle. This is a flux change recorder/copier
that can handle many many different formats because it reads and writes
by flux transitions on the disk, regardless of the encoding scheme (GCR,
MFM, FM, etc.) or format.
This is how I format and copy DEC RX01 and RX02 8" disks.
On 11/3/2022 4:07 PM, Grant Taylor via cctalk wrote:
Hi,
n00b alert
Does anyone have a 101 level boot strap guide for someone wanting to
get into creating better-than-dd disk images?
I'm finding myself back in a position where I want to image / preserve
multiple 5¼ & 3½ inch disks. I think all of them are PC compatible
disks. Probably standard FAT-12 and a handful of super capacity disk
formats from the likes of IBM / Microsoft where they tried to squeeze
1.6 (?) MB on a 3½ inch disk.
I have an internal 5¼ inch floppy drive that is in unknown condition
(I've never used / tested it since I got it).
I also have (at least one) 5¼ disk that I acquired as a scratch monkey
disk to test on before working on disks that I care more about.
I was thinking about acquiring a Kryoflux in the next few months and
starting to collect better quality images of disks. I recently saw
someone on Twitter suggest that Kryoflux wasn't the best route to go
and suggested a SuperCard Pro instead.
I had been using the dd command under Linux against a USB connected 3½
inch floppy drive for most things. But I've come to learn that's not
as good as some people would like to see preserved.
So, does anyone have a 101 level boot strap guide for someone wanting
to get into creating better-than-dd disk images?
2:26 p.m.
On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote:
Does anyone have a 101 level boot strap guide for
someone wanting to get into
creating better-than-dd disk images?
I'm finding myself back in a position where I want to image / preserve
multiple 5¼ & 3½ inch disks. I think all of them are PC compatible disks.
Probably standard FAT-12 and a handful of super capacity disk formats from
the likes of IBM / Microsoft where they tried to squeeze 1.6 (?) MB on a 3½
inch disk.
I have an internal 5¼ inch floppy drive that is in unknown condition (I've
never used / tested it since I got it).
I also have (at least one) 5¼ disk that I acquired as a scratch monkey disk
to test on before working on disks that I care more about.
I was thinking about acquiring a Kryoflux in the next few months and starting
to collect better quality images of disks. I recently saw someone on Twitter
suggest that Kryoflux wasn't the best route to go and suggested a SuperCard
Pro instead.
I had been using the dd command under Linux against a USB connected 3½ inch
floppy drive for most things. But I've come to learn that's not as good as
some people would like to see preserved.
So, does anyone have a 101 level boot strap guide for someone wanting to get
into creating better-than-dd disk images?
If these were formats OTHER THAN PC-DOS, then imaging can be essential.
And, a flux-transition device, such as Kryoflux might be necessary for
some.
And, if they are copy-protected, then flux-transition imaging is
necessary, and still might not be adequate.
But, why do IMAGING on PC-DOS disks?
Why not just copy the files, and "ZIP" them?
Other than bootable or copy-protected, then re-creation is format a disk
and copy the files onto it.
In what way would "better than DD" be needed?
--
Grumpy Ol' Fred cisin(a)xenosoft.com
2:49 p.m.
On 11/3/22 3:26 PM, Fred Cisin via cctalk wrote:
But, why do IMAGING on PC-DOS disks?
My /personal/ and primary use case is for use in virtual machines where
disk images (a la dd) is best (in my experience).
Why not just copy the files, and "ZIP" them?
Ziped (et al.) files are nice for some things. But the aren't readily
usable with virtual machines without access to where the zip files are.
Conversely I can attach a disk image to a virtual machine and start
using it immediately.
As for Zip specific, I'm not aware if /integrated/ Zip file support
prior to Windows XP. So the MS-DOS, Windows 3.x, and Windows NT / 2k
that I want to mess with can't work with Zip files directly.
I also like how I can mount a loop back of the disk image and make the
files therein accessible on Linux, my chosen host OS.
Other than bootable or copy-protected, then
re-creation is format a disk
and copy the files onto it.
I largely agree. However being a person that plays with different
operating systems in virtual machines, I need to boot and / or readily
attach images to the VM.
In what way would "better than DD" be
needed?
I'm too ignorant to be able to answer that. dd has served /my/ needs.
However I think there is some consensus, I don't know how general it is,
that dd or simple file copy tends to not be sufficient for some things.
I believe it's technically possible to re-create an MS-DOS boot disk by
formatting and then copying IO.SYS, MSDOS.SYS, and then COMMAND.COM to
the floppy disk in that order. I think the same methodology can be used
with PC-DOS. But that's /just/ /DOS/ and doesn't cover boot disks for
other operating systems that I play with.
--
Grant. . . .
unix || die
3:29 p.m.
> But, why do IMAGING on PC-DOS disks?
On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote:
My /personal/ and primary use case is for use in
virtual machines where disk
images (a la dd) is best (in my experience).
THAT is a totally valid reason for disk images, rather than file copies.
Another, less common problem, is that SOME installation programs also look
at the disk label, in addition to the files.
Windoze, at least in 3.xx did not. It worked fine to copy everything to a
single directory and install from there.
Other than
bootable or copy-protected, then re-creation is format a disk
and copy the files onto it.
I largely agree. However being a person that plays
with different operating
systems in virtual machines, I need to boot and / or readily attach images to
the VM. In what way
would "better than DD" be needed?
I'm too ignorant to be able to
answer that. dd has served /my/ needs.
However I think there is some consensus, I don't know how general it is, that
dd or simple file copy tends to not be sufficient for some things. I believe it's technically possible to re-create
an MS-DOS boot disk by
formatting and then copying IO.SYS, MSDOS.SYS, and then COMMAND.COM to the
floppy disk in that order. I think the same methodology can be used with
PC-DOS. But that's /just/ /DOS/ and doesn't cover boot disks for other
operating systems that I play with.
Even with MS-DOS/PC-DOS, there CAN [very rarely] be issues of boot sector.
OS other than MS-DOS/PC-DOS likely need an image. SOME OS use system
tracks and/or content that is NOT stored as files in the DIRectory.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
2:26 p.m.
On Thu, Nov 03, 2022 at 03:07:00PM -0600, Grant Taylor via cctalk wrote:
Hi,
n00b alert
Does anyone have a 101 level boot strap guide for someone wanting to get
into creating better-than-dd disk images?
[...]
So, does anyone have a 101 level boot strap guide for
someone wanting to get
into creating better-than-dd disk images?
I am (slowly) on my way to use ddrescue for similar thing(s).
caveat 1: I have not used ddrescue yet, just read a bit and was
convinced I may like it.
pro: ddrescue is said to be able to read image many times, trying only
what have failed before, merging results from various trials
etc. So, in theory, try same media in two drives, merge two images. In
theory, this might work with any block device under Linux (Unix?).
pro: While reading about ddrescue, I have learned that dd might abort
on error, this resulting in defective/uncompleted image. Whereas
ddrescue retries.
caveat n+1: see caveat n-1
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
2:50 p.m.
On 11/3/22 3:26 PM, Tomasz Rola via cctalk wrote:
I am (slowly) on my way to use ddrescue for similar
thing(s).
I've used ddrescue for a /few/ of my disk images. Thankfully /most/ of
the 3½ disks that I've imaged have not needed ddrescue / SpinRite / et al.
--
Grant. . . .
unix || die
2:27 p.m.
I was thinking about acquiring a Kryoflux in the next
few months and
starting to collect better quality images of disks. I recently saw
someone on Twitter suggest that Kryoflux wasn't the best route to go
and suggested a SuperCard Pro instead.
Some people are bothered by Kryoflux's behavior around openness of their
formats and the like. I _think_ they've addressed that, but if you care
about this, you will have to verify. _My_ Kryoflux went deaf -- quit
hearing any flux on the read line from the drive -- but that doesn't
seem to be common.
The SuperCard Pro doesn't seem to support 8" disks. That may or may not
be an issue for you.
The frustrating part of the whole flux imaging arena is that the
hardware is actually the _easy_ part. Software to decode flux images
for all the myriad on-disk formats, copy protection schemes, etc is
both the hard part _and_ the part everyone seems to skip over. If you
just need to process Apple / Atari / Commodore / PC diskettes, you're
probably covered. For anything else you're probably on your own.
Note that some disk types are CLV, not CAV (e.g. some Mac disks), and
reading them without additional hardware support may be problematic.
De
2:58 p.m.
On 11/3/22 3:27 PM, Dennis Boone via cctalk wrote:
Some people are bothered by Kryoflux's behavior
around openness of
their formats and the like. I _think_ they've addressed that, but
if you care about this, you will have to verify.
Ya. I'm starting to see that.
I don't /personally/ care about deeper images than a dd image which I
can attach to a hypervisor or use to re-create physical disks when needed.
If I'm going to re-image my disks, I'm willing to put in a little bit
more time and effort (per disk) and some additional time and cost in
hardware /if/ it's not onerous /and/ the community will benefit from my
efforts.
_My_ Kryoflux went deaf -- quit hearing any flux on
the read line
from the drive -- but that doesn't seem to be common.
:-(
The SuperCard Pro doesn't seem to support 8"
disks. That may or may
not be an issue for you.
I do own some 8" disks, but they are only as a museum piece of ancient
media along with some hard drive platters. I have no aspiration of ever
having an 8" disk drive, much less in a usable state.
The frustrating part of the whole flux imaging arena
is that the
hardware is actually the _easy_ part. Software to decode flux images
for all the myriad on-disk formats, copy protection schemes, etc is
both the hard part _and_ the part everyone seems to skip over. If you
just need to process Apple / Atari / Commodore / PC diskettes, you're
probably covered. For anything else you're probably on your own.
As indicated,
effectively, if not literally, everything I have is PC
compatible disks.
Note that some disk types are CLV, not CAV (e.g. some
Mac disks), and
reading them without additional hardware support may be problematic.
Is Constant Linear vs Angular Velocity (?) anything I need to worry
about when sticking within the IBM PC compatible line from say '90 forward?
The only other thing that I might add to this would be Zip or Syquest
disks if I ever acquire media / drives.
I figure that CD-ROMs / DVD-ROMs are largely a solved problem. Simply
use dd for single track disks and something that does cue / bin files
for multi-track disks. -- I think
--
Grant. . . .
unix || die
3:09 p.m.
> Note that some disk types are CLV, not CAV (e.g.
some Mac disks), and
> reading them without additional hardware support may be problematic.
On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote:
Is Constant Linear vs Angular Velocity (?) anything I
need to worry about
when sticking within the IBM PC compatible line from say '90 forward?
NO.
PC [compatible] was fixed rotational speed of 300 or 360 RPM.
Well, Weltec? made a 180 RPM drive, to be able to use 1.2M on 5150/5160,
and there are many other bizarre oddities.
CLV, or "zone" recording, with vaarying motor speed CAN be worked around
with a constant motor speed, by varying the data transfer rate, . . .
but NO PC [compatible] machines used variable speed floppies, other than
300RPM and 360RPM.
3:17 p.m.
Fred,
The Victor/Sirius 9000 was sort of PC compatible and featured a varial
speed floppy format, no?
Sellam
On Thu, Nov 3, 2022 at 3:09 PM Fred Cisin via cctalk <cctalk(a)classiccmp.org>
wrote:
> Note that
some disk types are CLV, not CAV (e.g. some Mac disks), and
> reading them without additional hardware support may be problematic.
On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote:
Is Constant Linear vs Angular Velocity (?)
anything I need to worry
about
when sticking within the IBM PC compatible line
from say '90 forward?
NO.
PC [compatible] was fixed rotational speed of 300 or 360 RPM.
Well, Weltec? made a 180 RPM drive, to be able to use 1.2M on 5150/5160,
and there are many other bizarre oddities.
CLV, or "zone" recording, with vaarying motor speed CAN be worked around
with a constant motor speed, by varying the data transfer rate, . . .
but NO PC [compatible] machines used variable speed floppies, other than
300RPM and 360RPM.
3:35 p.m.
On Thu, 3 Nov 2022, Sellam Abraham via cctalk wrote:
Fred,
The Victor/Sirius 9000 was sort of PC compatible and featured a varial
speed floppy format, no?
Although MS-DOS capable, the Victor/Sirius 9000 was FAR from PC
compatible!
An amazing machine, but NOT PC compatible.
It is an ideal example of how far away from PC compatible
MS-DOS was capable of being.
Also GCR, not MFM. NOT readable with a PC FDC.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
4:21 p.m.
GCR is Group Code Recording, used on the Apple II, Commodore 1541 drive
and Amiga (and others) use a different encoding scheme than the normal
FM (Frequency Modulation) or MFM (Modified Frequency Modulation)
encoding formats used by a majority of floppy disk controllers.
There is a very good description of floppy encoding formats here:
https://extrapages.de/archives/20190102-Floppy-notes.html
On 11/3/2022 5:46 PM, Grant Taylor via cctalk wrote:
On 11/3/22 4:35 PM, Fred Cisin via cctalk wrote:
Also GCR, not MFM. NOT readable with a PC FDC.
Please expand "GCR".
7:32 p.m.
On Thu, 3 Nov 2022, Mike Katz via cctalk wrote:
GCR is Group Code Recording, used on the Apple II,
Commodore 1541 drive and
Amiga (and others) use a different encoding scheme than the normal FM
(Frequency Modulation) or MFM (Modified Frequency Modulation) encoding
formats used by a majority of floppy disk controllers.
There is a very good description of floppy encoding formats here:
https://extrapages.de/archives/20190102-Floppy-notes.html
Amiga is not GCR; it is MFM, but without the IBM/WD sector/track
structure. WD 179x controllers can read tracks. It is too bad that NEC
chose to implement traack read as multiple sector read, rather than raw
track.
But, you are right about the others.
Apple still used GCR on the 400K/800K Mac format.
PROBABLY also on the Lisa Twiggy disks.
Victor/Sirius 9000
and many others, . . .
4 Nov
4 Nov
2:08 a.m.
On Thu, 3 Nov 2022, Grant Taylor wrote:
GCR is Group Code Recording, used on the Apple II,
Commodore 1541 drive and
Amiga (and others) use a different encoding scheme than the normal FM
No, the Amiga can handle GCR, but never used it. It's plain standard MFM
with different sector layout and IDs. After all, it's a software thing.
Christian
5 Nov
5 Nov
12:09 p.m.
Disk compression gone wrong.
I had a number of files from a hard drive to save to floppies. Even compressed it took 3
floppies.
Al was fine until one night, I was carrying the box of these and other floppies.
As I got out of the car, I dropped several disc and before I could stop, my foot came down
on the first disk, of the three ( in the dark).
I was never able to recover any useful information from any of the three disc. I
didn't create those disc and the person that did had lost the source.
I am willing to waste space to keep the original format, of each file, as much as
possible.
Any problem reading the first information of compressed files may mean the loss of all.
I only use compressed if it is to be re-expanded at it final destination.
Dwight
________________________________
3 Nov
3 Nov
4:23 p.m.
> Also GCR, not MFM. NOT readable with a PC FDC.
On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote:
Please expand "GCR".
Sure, . . . (GROSSLY OVER-SIMPLIFIED, such as "pulse" instead of flux
transition)
FM is "frequency modulated". Well, it is actually a regular clock pulse,
with data bit pulse, or no pulse, between each of the clock pulses.
There is, of course, a limit to how densely packed that can be on a track.
A signal with all zero bits of the data, and a signal with all one bits of
the data therefore are two different frequencies.
MFM is "Modified Frequency Modulated". Clock pulses really aren't
necessary when they fall between two consecutive data pulses. If we leave
those out, we end up with a much less dense pattern of pulses.
(Over-simplified: MFM is FM without any clock pulses deemed "unnecessary")
We can get away with a higher data transmission rate, even TWICE, and
still not be much too overcrowded on the track. Therefore, twice as much
data per track. The marketing people called that "DOUBLE DENSITY", and
immediately started calling FM, "SINGLE DENSITY", although some engineers
would argue that FM was "half density" and MFM would be "about single
density". If you do historical research, you will find the term "double
density" was used in the literature BEFORE the term "single density" was
(Just like the phrase "WORLD WAR TWO" was used in newspapers before "WORLD
WAR I" was ever applied to the "great war")
But, going back to FM, . . .
if you look at all of the patterns of pulses, you'll see that not ALL of
them are dense. In fact, of the 256 possible patterns for an 8 bit byte,
you can find 32, or even 64, that are low enough density that they could
be compressed. We can use 5 or 6 bits to represent those patterns. But,
having only 5 or 6 bits usable to only use the
specific patterns that were low enough density means that we can't use 8
bit bytes directly. but, we COULD recombine, to store 5 8 bit bytes as 8
5 bit patterns, or 3 bytes as 4 6 bit patterns. THAT produced low enough
"density" of the signal that by upping the data transfer rate, about one
and a half times as much data scould be stored on a track, admittedly with
some additional processing overhead. Thus, the Apple2 got about 140K on a
disk, when the TRS80 got about under 100K (89,600). (Both were originally
35 track, using Shugart SA400 and SA390 drives)
"Beneath Apple DOS" has a decent description)
The FDC of PC can only directly handle WD/IBM sector and track structure,
so reading GCR, such as Apple (prior to 1.4M) Victor/Sirius, Commodore,
etc. calls for different hardware.
http://www.xenosoft.com/fmts.html has a list of a few of the different
machines that use formats that CAN be done using the PC FDC. They do
still have different file systems, with various sector sizes, and
directory structures.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
4:26 p.m.
GCR stands for "group Coded Record"
On Thu, 3 Nov 2022, Fred Cisin via cctalk wrote:
>>> Also GCR, not MFM. NOT readable with a PC FDC.
>
> On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote:
>> Please expand "GCR".
>
> Sure, . . . (GROSSLY OVER-SIMPLIFIED, such as "pulse" instead of flux
> transition)
> FM is "frequency modulated". Well, it is actually a regular clock pulse,
> with data bit pulse, or no pulse, between each of the clock pulses.
> There is, of course, a limit to how densely packed that can be on a track.
> A signal with all zero bits of the data, and a signal with all one bits of
> the data therefore are two different frequencies.
>
>
> MFM is "Modified Frequency Modulated". Clock pulses really aren't
necessary
> when they fall between two consecutive data pulses. If we leave those out,
> we end up with a much less dense pattern of pulses. (Over-simplified: MFM is
> FM without any clock pulses deemed "unnecessary") We can get away with a
> higher data transmission rate, even TWICE, and still not be much too
> overcrowded on the track. Therefore, twice as much data per track. The
> marketing people called that "DOUBLE DENSITY", and immediately started
> calling FM, "SINGLE DENSITY", although some engineers would argue that FM
was
> "half density" and MFM would be "about single density". If you do
historical
> research, you will find the term "double density" was used in the
literature
> BEFORE the term "single density" was (Just like the phrase "WORLD WAR
TWO"
> was used in newspapers before "WORLD WAR I" was ever applied to the
"great
> war")
>
>
> But, going back to FM, . . . if you look at all of the patterns of pulses,
> you'll see that not ALL of them are dense. In fact, of the 256 possible
> patterns for an 8 bit byte, you can find 32, or even 64, that are low enough
> density that they could be compressed. We can use 5 or 6 bits to represent
> those patterns. But, having only 5 or 6 bits usable to only use the specific
> patterns that were low enough density means that we can't use 8 bit bytes
> directly. but, we COULD recombine, to store 5 8 bit bytes as 8 5 bit
> patterns, or 3 bytes as 4 6 bit patterns. THAT produced low enough
"density"
> of the signal that by upping the data transfer rate, about one and a half
> times as much data scould be stored on a track, admittedly with some
> additional processing overhead. Thus, the Apple2 got about 140K on a disk,
> when the TRS80 got about under 100K (89,600). (Both were originally 35
> track, using Shugart SA400 and SA390 drives)
> "Beneath Apple DOS" has a decent description)
>
>
> The FDC of PC can only directly handle WD/IBM sector and track structure, so
> reading GCR, such as Apple (prior to 1.4M) Victor/Sirius, Commodore, etc.
> calls for different hardware.
> http://www.xenosoft.com/fmts.html has a list of a few of the different
> machines that use formats that CAN be done using the PC FDC. They do still
> have different file systems, with various sector sizes, and directory
> structures.
>
>
> --
> Grumpy Ol' Fred cisin(a)xenosoft.com
3 Nov
3 Nov
4:57 p.m.
Fred,
There was a project someone did years ago where you can read GCR disks in
an unmodified PC drive by first inserting a PC formatted disk to get synced
and then swapping in a GCR encoded disk, then it can actually read the raw
pulses and they get decoded in software. I forget the website where the
project can be found but a web search will hopefully turn it up.
Sellam
On Thu, Nov 3, 2022 at 4:23 PM Fred Cisin via cctalk <cctalk(a)classiccmp.org>
wrote:
> Also GCR,
not MFM. NOT readable with a PC FDC.
On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote:
Please expand "GCR".
Sure, . . . (GROSSLY OVER-SIMPLIFIED, such as "pulse" instead of flux
transition)
FM is "frequency modulated". Well, it is actually a regular clock pulse,
with data bit pulse, or no pulse, between each of the clock pulses.
There is, of course, a limit to how densely packed that can be on a track.
A signal with all zero bits of the data, and a signal with all one bits of
the data therefore are two different frequencies.
MFM is "Modified Frequency Modulated". Clock pulses really aren't
necessary when they fall between two consecutive data pulses. If we leave
those out, we end up with a much less dense pattern of pulses.
(Over-simplified: MFM is FM without any clock pulses deemed "unnecessary")
We can get away with a higher data transmission rate, even TWICE, and
still not be much too overcrowded on the track. Therefore, twice as much
data per track. The marketing people called that "DOUBLE DENSITY", and
immediately started calling FM, "SINGLE DENSITY", although some engineers
would argue that FM was "half density" and MFM would be "about single
density". If you do historical research, you will find the term "double
density" was used in the literature BEFORE the term "single density" was
(Just like the phrase "WORLD WAR TWO" was used in newspapers before
"WORLD
WAR I" was ever applied to the "great war")
But, going back to FM, . . .
if you look at all of the patterns of pulses, you'll see that not ALL of
them are dense. In fact, of the 256 possible patterns for an 8 bit byte,
you can find 32, or even 64, that are low enough density that they could
be compressed. We can use 5 or 6 bits to represent those patterns. But,
having only 5 or 6 bits usable to only use the
specific patterns that were low enough density means that we can't use 8
bit bytes directly. but, we COULD recombine, to store 5 8 bit bytes as 8
5 bit patterns, or 3 bytes as 4 6 bit patterns. THAT produced low enough
"density" of the signal that by upping the data transfer rate, about one
and a half times as much data scould be stored on a track, admittedly with
some additional processing overhead. Thus, the Apple2 got about 140K on a
disk, when the TRS80 got about under 100K (89,600). (Both were originally
35 track, using Shugart SA400 and SA390 drives)
"Beneath Apple DOS" has a decent description)
The FDC of PC can only directly handle WD/IBM sector and track structure,
so reading GCR, such as Apple (prior to 1.4M) Victor/Sirius, Commodore,
etc. calls for different hardware.
http://www.xenosoft.com/fmts.html has a list of a few of the different
machines that use formats that CAN be done using the PC FDC. They do
still have different file systems, with various sector sizes, and
directory structures.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
5:15 p.m.
On Thu, 3 Nov 2022, Sellam Abraham via cctalk wrote:
There was a project someone did years ago where you
can read GCR disks in
an unmodified PC drive by first inserting a PC formatted disk to get synced
and then swapping in a GCR encoded disk, then it can actually read the raw
pulses and they get decoded in software. I forget the website where the
project can be found but a web search will hopefully turn it up.
There are some strange tricks that you can do to fool the system and get
it to read some stuff that is NOT IBM/WD sector/track structures.
For example, Amiga is MFM data stream, but without IBM/WD sector/track
structures. You can fool the NEC FDC into seeing it, in several ways, one
of which is to switch drives in mid read, and/or to read a "long" sector.
I never succeeded with any of the tricks for Apple2 GCR.
About 35 years ago, I did the file system code to use with an extra board
("Apple Turnover") to go between the FDC and the drive, for Apple2 disks
(Apple-DOS 3.2 (13 sector), 3.3 (16 sector), Softcard CP/M, P System, and
ProDos) It never worked well, and the publisher got in too far over their
heads, and I had to have a lawyer shut them down.
5:44 p.m.
Here's something right out of the Apple II FAQ:
07.007 Can I read Apple II diskettes on my PC?
Yes. There is a way for some PCs to read Apple II DOS 3.3 and
ProDOS 5.25"
floppies which are not copy-protected.
By "some PCs" I mean that the PC must have two floppy drives (only one
has
to be a 5.25" drive) and it must be running MS-DOS or Windows 95, 98, or ME.
(It won't work with NT, 2000, and XP).
You also need a program called "DISK2FDI". (For a link to the program,
see
Csa21MAIN4.txt.)
DISK2FDI reads the Apple floppy and creates a disk image (.do) on the PC.
These images will work on most emulators.
https://stason.org/TULARC/pc/apple2/faq/07-007-Can-I-read-Apple-II-diskette…
Oh yeah, I remember now:
http://www.oldskool.org/disk2fdi/
It requires two drives, where one drive has a PC-DOS formatted disk in it,
and then switches to the other that contains the subject GCR disk. Cool
hack.
Sellam
On Thu, Nov 3, 2022 at 5:16 PM Fred Cisin via cctalk <cctalk(a)classiccmp.org>
wrote:
On Thu, 3 Nov 2022, Sellam Abraham via cctalk wrote:
There was a project someone did years ago where
you can read GCR disks in
an unmodified PC drive by first inserting a PC formatted disk to get
synced
and then swapping in a GCR encoded disk, then it
can actually read the
raw
pulses and they get decoded in software. I
forget the website where the
project can be found but a web search will hopefully turn it up.
There are some strange tricks that you can do to fool the system and get
it to read some stuff that is NOT IBM/WD sector/track structures.
For example, Amiga is MFM data stream, but without IBM/WD sector/track
structures. You can fool the NEC FDC into seeing it, in several ways, one
of which is to switch drives in mid read, and/or to read a "long" sector.
I never succeeded with any of the tricks for Apple2 GCR.
About 35 years ago, I did the file system code to use with an extra board
("Apple Turnover") to go between the FDC and the drive, for Apple2 disks
(Apple-DOS 3.2 (13 sector), 3.3 (16 sector), Softcard CP/M, P System, and
ProDos) It never worked well, and the publisher got in too far over their
heads, and I had to have a lawyer shut them down.
4 Nov
4 Nov
2:02 a.m.
On Thu, 3 Nov 2022, Fred Cisin wrote:
On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote:
[...]
Please expand "GCR".
Sure, . . . (GROSSLY OVER-SIMPLIFIED, such as "pulse" instead of flux
transition)
FM is "frequency modulated". Well, it is actually a regular clock pulse,
MFM is "Modified Frequency Modulated".
Clock pulses really aren't necessary
[...]
And to shorten the discussion: *all* of them boil down to a form of RLL
(run-lenth-limited) encoding.
Christian
5 Nov
5 Nov
2:44 a.m.
On Thu, 3 Nov 2022 at 23:47, Grant Taylor via cctalk
<cctalk(a)classiccmp.org> wrote:
Please expand "GCR".
Group-coded recording.
https://en.wikipedia.org/wiki/Group_coded_recording
Specifically:
https://en.wikipedia.org/wiki/Group_coded_recording#Apple
As opposed to Modified Frequency Modulation:
https://en.wikipedia.org/wiki/Modified_frequency_modulation
In ST-506 hard disks, MFM was supplemented by RLL, Run-length Limited:
https://en.wikipedia.org/wiki/Run-length_limited
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
3 Nov
3 Nov
4:07 p.m.
Is Constant Linear vs Angular Velocity (?) anything I
need to worry
about when sticking within the IBM PC compatible line from say '90
forward?
There aren't that many platforms that used CLV drives. I don't recall
seeing one in the PC world. If anyone did, they would have been
specialty stuff.
The only other thing that I might add to this would be
Zip or Syquest
disks if I ever acquire media / drives.
I haven't seen a flux imaging system for Zip/Jaz drives. MO stuff might
be easier optically. But those don't tend to have the sorts of issues
where you'd need to flux image anyway -- just a bunch of blocks, and a
dd-type tool ought to work fine.
De
4:26 p.m.
> Is Constant Linear vs Angular Velocity (?)
anything I need to worry
> about when sticking within the IBM PC compatible line from say '90
> forward?
On Thu, 3 Nov 2022, Dennis Boone via cctalk wrote:
There aren't that many platforms that used CLV
drives. I don't recall
seeing one in the PC world. If anyone did, they would have been
specialty stuff.
The Macintosh 400K/800K formats were not a continuously variable motor
speed, but they used several speeds for different groups or "zones" of
tracks.
4:28 p.m.
On 11/3/22 5:07 PM, Dennis Boone via cctalk wrote:
There aren't that many platforms that used CLV
drives. I don't
recall seeing one in the PC world. If anyone did, they would have
been specialty stuff.
ACK
I haven't seen a flux imaging system for Zip/Jaz
drives. MO stuff
might be easier optically. But those don't tend to have the sorts
of issues where you'd need to flux image anyway -- just a bunch of
blocks, and a dd-type tool ought to work fine.
I would naively think that a dd (type) process would work for Zip / Jazz
/ Syquest drives, especially for my use case.
I think the biggest thing with dd for CD-ROMs / DVD-ROMs is when there
are multiple tracks.
I know /of/ CUE & BIN file pairs. But I can't describe their
differences other than my understanding is that they deal with
multi-track 'ROMs.
--
Grant. . . .
unix || die
2:46 p.m.
On 11/3/22 16:07, Grant Taylor via cctalk wrote:
Hi,
n00b alert
Does anyone have a 101 level boot strap guide for someone
wanting to get into creating better-than-dd disk images?
Is there a reason to do a real IMAGE backup, rather than a
file backup? I have used Linux to backup a lot of old PC
stuff, including backing up a Win95 system and making it
available to a Win95 virtual machine under VirtualBox. This
enabled me to run a bunch of old CAD programs and
recover/access old schematics and board layouts.
Linux can directly identify and read almost all of the old
FATxx file systems.
Jon
3:48 p.m.
Is there a reason to do a real IMAGE backup, rather
than a file
backup?
People have occasionally found interesting things in the unallocated
sectors of disks. For garden variety PC format disks, it's not
necessary to do flux imaging to preserve that sort of thing, though. A
regime using a dd-like tool is adequate.
De
3:52 p.m.
> Is there a reason to do a real IMAGE backup,
rather than a file
> backup?
On Thu, 3 Nov 2022, Dennis Boone via cctalk wrote:
People have occasionally found interesting things in
the unallocated
sectors of disks. For garden variety PC format disks, it's not
necessary to do flux imaging to preserve that sort of thing, though. A
regime using a dd-like tool is adequate.
Such as the classic Montezuma Micro CP/M for TRS80 Model 3, with "JOHN,
EAT SHIT AND DIE" in some sectors?
Also, an "ERASED" file is not truly erased until the sector is re-used.
By repairing the DIRectory entry, it can be "UNerased".
5 Nov
5 Nov
2:44 a.m.
On Thu, 3 Nov 2022 at 23:52, Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
Such as the classic Montezuma Micro CP/M for TRS80 Model 3, with "JOHN,
EAT SHIT AND DIE" in some sectors?
?!
Do tell...
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
3 Nov
3 Nov
2:57 p.m.
On Thu, Nov 3, 2022 at 2:08 PM Grant Taylor via cctalk
<cctalk(a)classiccmp.org> wrote:
Hi,
n00b alert
Does anyone have a 101 level boot strap guide for someone wanting to get
into creating better-than-dd disk images?
I'm finding myself back in a position where I want to image / preserve
multiple 5¼ & 3½ inch disks. I think all of them are PC compatible
disks. Probably standard FAT-12 and a handful of super capacity disk
formats from the likes of IBM / Microsoft where they tried to squeeze
1.6 (?) MB on a 3½ inch disk.
If they are 5¼ & 3½ inch disks which are not copy protected and are
readable with standard PC compatible floppy controllers, but not
necessarily limited to standard DOS formats, and you had a older PC
with a floppy controller which you could set up to boot into real mode
DOS, I would start with Dave Dunfield's ImageDisk program.
See a link for ImageDisk 1.19 here: http://dunfield.classiccmp.org/img/
Even if a disk is in a standard DOS format, it can be helpful to have
an image of the disk rather than just a ZIP of all of the files copied
off of the disk. In one example I was trying to run a setup program
from a set of files extracted from a ZIP and copied back to disks and
the setup program blocked when it was necessary to change installation
disks because the next disk didn't have the expected disk label. Of
course the disk labels weren't saved in the ZIP, while they would have
been saved in images of the disks.
3:43 p.m.
On 11/3/22 3:57 PM, Glen Slick via cctalk wrote:
If they are 5¼ & 3½ inch disks which are not copy
protected and
are readable with standard PC compatible floppy controllers, but not
necessarily limited to standard DOS formats, and you had a older PC
with a floppy controller which you could set up to boot into real
mode DOS, I would start with Dave Dunfield's ImageDisk program.
See a link for ImageDisk 1.19 here: http://dunfield.classiccmp.org/img/
Thank you Glen. That's where I was sort of hoping to end up.
I may actually see if I can get my IBM PS/2 back in service as a starter
for this. }:-)
Doing so serves as:
- A solution to my desired goal of this thread
- A reason to stand Token Ring up for quasi production. -- Don't
talk to me about Ethernet for PS/2s.
- A Reason to stand up a Novell NetWare server for quasi production.
Even if a disk is in a standard DOS format, it can be
helpful to
have an image of the disk rather than just a ZIP of all of the files
copied off of the disk. In one example I was trying to run a setup
program from a set of files extracted from a ZIP and copied back to
disks and the setup program blocked when it was necessary to change
installation disks because the next disk didn't have the expected
disk label. Of course the disk labels weren't saved in the ZIP,
while they would have been saved in images of the disks.
This is a very good example of why a disk image is better than /just/ a
collection of files.
--
Grant. . . .
unix || die
4:27 p.m.
On Nov 3, 2022, at 5:57 PM, Glen Slick via cctalk
<cctalk(a)classiccmp.org> wrote:
On Thu, Nov 3, 2022 at 2:08 PM Grant Taylor via cctalk
<cctalk(a)classiccmp.org> wrote:
An example of a non-PC format 5.25 inch disk that normal drives can read would be the DEC
RX50 floppy, which has 10 sectors per track rather than the PC standard 9 sectors. But a
standard drive will read and write those just fine, if it's told to use that format.
I did that ages ago in DOS, but in the past 15 years or so I've only used Linux for
that job. It's a simple matter, you just need to know what the format is.
paul
Hi,
n00b alert
Does anyone have a 101 level boot strap guide for someone wanting to get
into creating better-than-dd disk images?
I'm finding myself back in a position where I want to image / preserve
multiple 5¼ & 3½ inch disks. I think all of them are PC compatible
disks. Probably standard FAT-12 and a handful of super capacity disk
formats from the likes of IBM / Microsoft where they tried to squeeze
1.6 (?) MB on a 3½ inch disk.
If they are 5¼ & 3½ inch disks which are not copy protected and are
readable with standard PC compatible floppy controllers, but not
necessarily limited to standard DOS formats, and you had a older PC
with a floppy controller which you could set up to boot into real mode
DOS, I would start with Dave Dunfield's ImageDisk program.
4:38 p.m.
On Thu, 3 Nov 2022, Paul Koning via cctalk wrote:
An example of a non-PC format 5.25 inch disk that
normal drives can read
would be the DEC RX50 floppy, which has 10 sectors per track rather than
the PC standard 9 sectors. But a standard drive will read and write
those just fine, if it's told to use that format. I did that ages ago
in DOS, but in the past 15 years or so I've only used Linux for that
job. It's a simple matter, you just need to know what the format is.
'course MS-DOS/PC-DOS/WINDOWS can't understand anything other than its own
very limited selection of formats. Does Windoze 11 still understand the
original 160K format of PC-DOS 1.00?
It helps to be using a program that can talk to the BIOS, or directly to
the FDC, to be able to use the other sector sizes, and file systems.
But, with a little programming, such as dropping down to BIOS level,
and calling INT13h, you can read most others that use IBM/Western Digital
sector and track structures (generally becaause they used a WD or NEC FDC)
http://www.xenosoft.com/fmts.html is a list of some of the ones that I
implemented in XenoCopy-PC
--
Grumpy Ol' Fred cisin(a)xenosoft.com
4:55 p.m.
On Nov 3, 2022, at 7:38 PM, Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
On Thu, 3 Nov 2022, Paul Koning via cctalk wrote:
Exactly, and that's what I did way back when, in my original implementation of
"flx" -- a utility for accessing RSTS file systems on a PC. Later I added a
Linux way to do that, which is very much simpler -- just a matter of setting the right
mode, either with the fdprm utility or just by issuing an ioctl. My current
"flx" is written in Python, it does that automatically when it sees a floppy
being accessed.
That version includes a small script to use just the floppy access routines, to make an
image copy of an RX50 either in physical sector order or RX50 logical order. Look on
svn://akdesign.dyndns.org/flx/trunk for the code. "rx50.py" is that tool; you
can also find in "fdprm" the configuration file for the fdprm utility to tell it
about "rx50" format.
paul
An example of a non-PC format 5.25 inch disk that
normal drives can read would be the DEC RX50 floppy, which has 10 sectors per track rather
than the PC standard 9 sectors. But a standard drive will read and write those just fine,
if it's told to use that format. I did that ages ago in DOS, but in the past 15 years
or so I've only used Linux for that job. It's a simple matter, you just need to
know what the format is.
'course MS-DOS/PC-DOS/WINDOWS can't understand anything other than its own very
limited selection of formats. Does Windoze 11 still understand the original 160K format
of PC-DOS 1.00?
...
But, with a little programming, such as dropping down to BIOS level, and calling INT13h,
you can read most others that use IBM/Western Digital sector and track structures
(generally becaause they used a WD or NEC FDC)
http://www.xenosoft.com/fmts.html is a list of some of the ones that I implemented in
XenoCopy-PC
4 Nov
4 Nov
1:56 a.m.
On Thu, 3 Nov 2022, Grant Taylor wrote:
Does anyone have a 101 level boot strap guide for
someone wanting to get into
creating better-than-dd disk images?
I'm finding myself back in a position where I want to image / preserve
multiple 5¼ & 3½ inch disks. I think all of them are PC compatible disks.
Probably standard FAT-12 and a handful of super capacity disk formats from
the likes of IBM / Microsoft where they tried to squeeze 1.6 (?) MB on a 3½
inch disk.
Short answer: ImageDisk
For FAT/DOS disks, I have a small script that creates both an .imd file
and a .zip file of the disk contents, essentially this:
DRV=/dev/fd0
DOSDRV="a:"
# Create both .imd and .dd image
imd -i1 -R -a -d $DRV -r "$NAME.imd"
# Compress
pigz -9 "$NAME.imd"
# Create directory listing
mdir -i "$NAME.imd.dd" -a/ > "$NAME.dir"
# Extract contents from .dd
mkdir "$NAME"
mcopy -i "$NAME.imd.dd" -smpv :: "$NAME/"
# ZIP contents
cd "$NAME"
zip -r "../$NAME.zip" .
# Remove temporary files
cd ..
rm -rf "$NAME"
rm -f "$NAME.imd.dd"
Christian
8:46 a.m.
On 11/4/22 2:56 AM, Christian Corti via cctalk wrote:
Short answer: ImageDisk
ACK
For FAT/DOS disks, I have a small script that creates
both an .imd file
and a .zip file of the disk contents,
Nice!
I think that's in the same ball park as I would have assumed I'd do if
someone had asked me this time last week.
essentially this:
DRV=/dev/fd0
DOSDRV="a:"
# Create both .imd and .dd image
Why the two types of image?
I assume that .imd is ImageDisk's native format.
I understand the raw sector by sector (byte by byte?) .dd image.
Aside: Does that mean that ImageDisk's /image/ is not the same sbs / bbb
image that a dd image is?
I assume that ImageDisk's format contains the same type of data,
possibly organized differently and / or compressed thus making the .imd
not directly usable by VM hypervisors or loopback mounts the same way
that a .dd image is.
imd -i1 -R -a -d $DRV -r "$NAME.imd"
# Compress
pigz -9 "$NAME.imd"
# Create directory listing
mdir -i "$NAME.imd.dd" -a/ > "$NAME.dir"
# Extract contents from .dd
mkdir "$NAME"
mcopy -i "$NAME.imd.dd" -smpv :: "$NAME/"
# ZIP contents
cd "$NAME"
zip -r "../$NAME.zip" .
# Remove temporary files
cd ..
rm -rf "$NAME"
rm -f "$NAME.imd.dd"
Interesting.
I'm going to have to look at the man pages to completely grok the
commands that you're using. The thing that stands out to me as the
biggest unknown is where the $NAME.imd.dd file is coming from. It seems
as if img (the main ImageDisk command?) is creating $NAME.imd file.
Does it also create $NAME.imd.dd file at the same time?
I like using mcopy (from mtools?) to extract the files to create a zip.
Nice technique.
--
Grant. . . .
unix || die
531
days inactive
533
days old
38 comments
12 participants
participants (12)
-
Christian Corti -
Dennis Boone -
dwight -
Fred Cisin -
Glen Slick -
Grant Taylor -
Jon Elson -
Liam Proven -
Mike Katz -
Paul Koning -
Sellam Abraham -
Tomasz Rola