Hi there,
On Sun, 22 Sep 2024, barry m wrote:
You have just woke me up ... I don't really need floppies.
As I said, I did wonder about that. :)
Writing a CD image is probably more familiar and there are many tools
for Windows which can make it very straightforward. As for floppies,
I'd written the diatribe below by the time your message came in, so
I'll post it anyway on the off-chance that it might be helpful to
someone coming along later.
... ... ...
Many thanks for the information
You're welcome. :
- which I will have to study to understand.
Of course. I've been working with this stuff for more than fifty
years so it's possible that I might miss things out because they're
"obvious", when in fact if you don't routinely unscramble damaged
filesystems before breakfast those things aren't at all obvious.
If you think I've missed out something which would have made it all a
lot easier to understand please let me know. In the meantime I think
it might be worth quickly explaining WHY there seem to be two ways of
writing data to discs (that is (A) image writes (B) things like the
'COPY' command, and, in fact, more or less everything else as well.).
Three main reasons I think:
1. Discs can have bad spots.
When you use things like the COPY command, and when you use a tool
like 'unzip' to extract the contents from a 'zip' archive file, all
the problems associated with bad spots on the storage media will be
handled for you, transparently, by the operating system's filesystem
handling code. You don't even have to know about it. If for any
reason the error handling code of the operating system can't handle
problems with the storage medium it will tell you (but that's rare,
and it *might* mean your hard disc is dying so you need a new one).
But mostly, if the system finds a bad spot it just marks it bad, so
that it won't bother trying to use it any more, and moves on. You
can for example see the bad blocks on a floppy discs with a tool. [*]
2. The files that are written often change.
The system *could* just write the data on the storage medium in one
great long string on the medium. That's what happens when you use an
image writing program, like what you do when you write an image to a
floppy or CD. But as I mentioned in (1), storage media can sometimes
have bad spots, and that means that when you write an image file to a
floppy there's nothing to cope with bad bits on the floppy. So either
the recording surface of the floppy needs to be perfect, if you write
it in this way, or you need to be lucky. I've actually seen that kind
of luck happen, but mostly it doesn't so you need to try another disc.
And anyway filesystems tend to be used in ways which make this way of
operating very awkward....
Files may be added, changed, deleted, extended or even have new bits
inserted in the middle. If every time you wrote a file you wrote the
whole thing in a long string, eventually there would come a time when,
even though there's lots of free space left on the medium, it's all in
small chunks and there isn't a single contiguous bit of space left on
the medium which is big enough to accommodate whatever you happen to
want to write right now. So most filesystems split up the files they
store into relatively small 'blocks' (or something like blocks), and
if necessary they spread the blocks of the file all over the storage
medium like confetti outside a church. Part of the filesystem design
makes it possible to recover the original file from all the pieces.
This all sounds a bit scary when you first realize the implications,
but you can get used to it, largely because it does actually work.
3. The operating system needs to be able to find any individual file
(or even a part of a file) any time something asks for it, and fast.
If all you ever did when you wrote a file was write it in a big long
string on the storage medium, then when you wanted to read it back
again you'd have to start at the beginnging of the medium and read it
until you found what you were looking for. It would be unacceptably,
horribly, efficient. So the filesystem has ways of indexing the data
so that it can be found much more quickly when random requests for it
are made by some random bit of software - which might not even have
existed when the filesystem code was written.
4. There's a heck of a lot more to it than this but that's a flavour.
There are lots of articles, blogs and whatnot about this stuff and I
had a quick look for some links for you but in the few minutes I spent
searching I didn't find anything which condensed it as much as this so
it was easier just to write it. As you can imagine I type quite fast. :)
73,
Ged.
[*]
Output from a tool which draws a ASCII art to show the bad sectors on a floppy.
This is a 3.5" DD/SD (720kByte) floppy, I wrote the files in March-April 1988.
As it happens the data on the disc was written as Zip archives, and didn't use
the bad blocks on the disc. Presumably that means that the operating system
had noticed the blocks were bad some time before the files were written and it
had marked them not to be used. It might have been luck but that's unlikely.
Everything stored on the disc is readable. Because the files are Zip archives
they can be tested to guarantee that. This floppy has 80 tracks (cylinders),
two heads, and 9 sectors of 512 bytes per cylinder making exactly 737280 bytes
(approximately 720kBytes, or exactly 720 KiB). Each '.' below represents 512
bytes which can be read perfectly. Each 'B' represents 512 bytes which can't.
You can do this sort of thing for representing floppies, but trying to
do the same for the terabytes of modern media is obviously impractical.
8<----------------------------------------------------------------------8<----------------------------------------------------------------------
Tracks -> 1 2 3 4 5 6 7
H.SS 01234567890123456789012345678901234567890123456789012345678901234567890123456789
0. 1
................................................................................
0. 2
................................................................................
0. 3
....................................................B...........................
0. 4
................................................................................
0. 5
................................................................................
0. 6
................................................................................
0. 7
................................................................................
0. 8
................................................................................
0. 9
................................................................................
1. 1
................................................................................
1. 2
................................................................................
1. 3
.............................................BBBB...............................
1. 4
................................................................................
1. 5
................................................................................
1. 6
................................................................................
1. 7
................................................................................
1. 8
.............................................B.B................................
1. 9
................................................................................
Good sectors: 1433/1440 (99%)
Missing sectors: 0/1440 (0%)
Bad sectors: 7/1440 (0%)
IMG: wrote 80 tracks, 2 sides, 720 kB total to 034/034.img
8<----------------------------------------------------------------------8<----------------------------------------------------------------------
Using a tool to read sectors on a 25-year-old 1.44M capacity floppy (3.5"
DS/DD).
This floppy has a defect at cylinder 2, side 1, sector 2:
8<----------------------------------------------------------------------8<----------------------------------------------------------------------
OPTION: 1440kB 3.5" 80-track 18-sector DSHD
SCP: writing 96 tpi double sided file containing 160 tracks
Measuring rotational speed...
Using Greaseweazle GWB0B563AE5976C01007BD1705 on /dev/ttyACM0
Rotational period is 199.6ms (300.6rpm)
0.0: 239 ms in 91874 bytes
43 raw records, 21 raw sectors; 1.00us clock (1001kHz)
sectors: 0.0.1 0.0.2 0.0.3 0.0.4 0.0.5 0.0.6 0.0.7 0.0.8 0.0.9 0.0.10
0.0.11 0.0.12 0.0.13 0.0.14 0.0.15 0.0.16 0.0.17 0.0.18
9216 bytes decoded
Measuring rotational speed...
Rotational period is 199.6ms (300.6rpm)
0.1: 239 ms in 109532 bytes
44 raw records, 22 raw sectors; 1.00us clock (1001kHz)
sectors: 0.1.1 0.1.2 0.1.3 0.1.4 0.1.5 0.1.6 0.1.7 0.1.8 0.1.9 0.1.10
0.1.11 0.1.12 0.1.13 0.1.14 0.1.15 0.1.16 0.1.17 0.1.18
9216 bytes decoded
Measuring rotational speed...
Rotational period is 199.6ms (300.6rpm)
1.0: 239 ms in 91260 bytes
44 raw records, 22 raw sectors; 1.00us clock (1001kHz)
sectors: 1.0.1 1.0.2 1.0.3 1.0.4 1.0.5 1.0.6 1.0.7 1.0.8 1.0.9 1.0.10
1.0.11 1.0.12 1.0.13 1.0.14 1.0.15 1.0.16 1.0.17 1.0.18
9216 bytes decoded
Measuring rotational speed...
Rotational period is 199.6ms (300.6rpm)
1.1: 239 ms in 91093 bytes
retrying; 3 retries remaining
1.1: 239 ms in 91217 bytes
90 raw records, 44 raw sectors; 1.00us clock (1002kHz)
sectors: 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7 1.1.8 1.1.9 1.1.10
1.1.11 1.1.12 1.1.13 1.1.14 1.1.15 1.1.16 1.1.17 1.1.18
9216 bytes decoded
Measuring rotational speed...
Rotational period is 199.6ms (300.6rpm)
2.0: 239 ms in 90969 bytes
46 raw records, 22 raw sectors; 1.00us clock (1000kHz)
sectors: 2.0.1 2.0.2 2.0.3 2.0.4 2.0.5 2.0.6 2.0.7 2.0.8 2.0.9 2.0.10
2.0.11 2.0.12 2.0.13 2.0.14 2.0.15 2.0.16 2.0.17 2.0.18
9216 bytes decoded
Measuring rotational speed...
Rotational period is 199.6ms (300.6rpm)
2.1: 239 ms in 91127 bytes
retrying; 3 retries remaining
2.1: 239 ms in 91193 bytes
retrying; 2 retries remaining
2.1: 239 ms in 91359 bytes
retrying; 1 retries remaining
2.1: 239 ms in 91107 bytes
giving up
189 raw records, 85 raw sectors; 1.00us clock (1001kHz)
sectors: 2.1.1 2.1.2! 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8 2.1.9 2.1.10
2.1.11 2.1.12 2.1.13 2.1.14 2.1.15 2.1.16 2.1.17 2.1.18
9216 bytes decoded
...
...
8<----------------------------------------------------------------------8<----------------------------------------------------------------------
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
