[cctalk] Re: Disk imaging n00b
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, . . .
[cctalk] Re: Disk imaging n00b
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".
[cctalk] Re: Disk imaging n00b
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-diskettes-on-my-PC.html
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
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.
>
[cctalk] Re: Disk imaging n00b
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.
[cctalk] Re: Disk imaging n00b
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 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 ci...@xenosoft.com
[cctalk] Re: Disk imaging n00b
> On Nov 3, 2022, at 7:38 PM, Fred Cisin via cctalk > wrote: > > 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? > ... > 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 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
[cctalk] Re: Disk imaging n00b
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 ci...@xenosoft.com
[cctalk] Re: Disk imaging n00b
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
[cctalk] Re: Disk imaging n00b
> On Nov 3, 2022, at 5:57 PM, Glen Slick via cctalk > wrote: > > On Thu, Nov 3, 2022 at 2:08 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. > > 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. 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
[cctalk] Re: Disk imaging n00b
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 ci...@xenosoft.com
[cctalk] Re: Disk imaging n00b
> 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.
[cctalk] Re: Disk imaging n00b
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 ci...@xenosoft.com
[cctalk] Re: Disk imaging n00b
> 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
[cctalk] Re: Disk imaging n00b
> 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".
[cctalk] Re: Disk imaging n00b
> 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
[cctalk] Re: Disk imaging n00b
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". -- Grant. . . . unix || die
[cctalk] Re: Disk imaging n00b
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
[cctalk] Re: Disk imaging n00b
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 ci...@xenosoft.com
[cctalk] Re: Disk imaging n00b
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. Ah, if you are using OS's other than MS-DOS and PC-DOS, then a disk image is likely to be essential. Even the 5150 also had CP/M-86 and UCSD P-System FROM IBM. And the 5170 had Xenix (Santa Cruz Operation Unix, peddled through Microsoft) 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. The USUAL reasoning is to reproduce variance other than content of sectors and files. Such as copy-protection. Unless you are dealing with copy-protection, or seriously alien formats, you are generally better off using the FDC to make your images, rather than flux-transition. There are numerous FDC based imaging programs, but, there are also multiple formats of the image, such as metadata headers, etc. OTOH, flux-transition lets you look at content below the sector level, to view and sometimes even repair damaged tracks. 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 ci...@xenosoft.com
[cctalk] Re: Disk imaging n00b
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 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. >
[cctalk] Re: Disk imaging n00b
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.
[cctalk] Re: Disk imaging n00b
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
[cctalk] Re: Disk imaging n00b
On Thu, Nov 3, 2022 at 2:08 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. 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.
[cctalk] Re: Disk imaging n00b
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
[cctalk] Re: Disk imaging n00b
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
[cctalk] Re: Disk imaging n00b
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
[cctalk] Re: Disk imaging n00b
> 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
[cctalk] Re: Disk imaging n00b
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_r...@bigfoot.com **
[cctalk] Re: Disk imaging n00b
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 ci...@xenosoft.com
[cctalk] Disk imaging n00b
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
[cctalk] Re: 50 Years of the HP 3000
On Nov 1, 2022, at 11:55 AM, Mark Moulding via cctalk wrote: > > I'd like to see $2000, but will cheerfully entertain offers (cheerfully if > they're reasonable, or met with hysterical laughter if not). You may need to adjust your expectations on that front. Even with pandemic-related inflation, that’s quite high for something not a lot of people will know they should be interested in. — Chris — who has a 917LX and A400, and wishes he could find a 37 or Micro Sent from my iPad
