17 Nov
2007
17 Nov
'07
11:59 p.m.
Date: Sat, 17 Nov 2007 21:59:02 +0000 (GMT)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: "intelligent" disk drives
<snip>
As an aside, IMHO one of the worst mistakes commodore
made was that the
8050 could not at least read the disks of the earlier drives.
-tony
--------
Sort of unavoidable because to get the 500MB/side they went to 100TPI drives.
Not as big a problem then as it may be today, because the high price of
the 8050/8250s tended to put them into a different market, mostly business
and institutional, where price and compatibility with the smaller and cheaper
units wasn't usually an issue. And of course the IEEE bus was compatible
so you could easily convert among drives (until the serial versions came
along) as long as you had one of the (also expensive) IEEE<>IEEE cables.
m
18 Nov
18 Nov
12:21 a.m.
>As an aside, IMHO one of the worst mistakes
commodore made was that the
>8050 could not at least read the disks of the earlier drives.
On Sat, 17 Nov 2007, M H Stein wrote:
Sort of unavoidable because to get the 500MB/side they
went to 100TPI drives.
Well, 96tpi drives would give pretty much the same capacity as 100tpi
ones, with only "half" as many incompatabilities.
'course, if they HAD gotten 500MB/side (v 400-500KB), then it would have
been well worth it.
Not as big a problem then as it may be today, because the high price of
the 8050/8250s tended to put them into a different market, mostly business
and institutional, where price and compatibility with the smaller and cheaper
units wasn't usually an issue. And of course the IEEE bus was compatible
so you could easily convert among drives (until the serial versions came
along) as long as you had one of the (also expensive) IEEE<>IEEE cables.
m
--
Fred Cisin cisin at xenosoft.com
XenoSoft http://www.xenosoft.com
PO Box 1236 (510) 558-9366
Berkeley, CA 94701-1236
4:41 p.m.
On Sunday 18 November 2007 00:21, Fred Cisin wrote:
Speaking of which, I recall seeing announcements every so often of floppy
drives that would have seriously more capacity than the usual stuff.
Something about "vertical format" sticks in my mind, though not much more
than that. Is this what that LS120 was all about? I think I ever only
encountered _one_ of those drives...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
>As an
aside, IMHO one of the worst mistakes commodore made was that the
>8050 could not at least read the disks of the earlier drives.
On Sat, 17 Nov 2007, M H Stein wrote:
Sort of unavoidable because to get the 500MB/side
they went to 100TPI
drives.
Well, 96tpi drives would give pretty much the same capacity as 100tpi
ones, with only "half" as many incompatabilities.
'course, if they HAD gotten 500MB/side (v 400-500KB), then it would have
been well worth it. 
5:42 p.m.
On 18 Nov 2007 at 16:41, Roy J. Tellason wrote:
Maybe you mean perpendicular recording (PMR) that was used in the
2.88MB 3.5" floppies. Very unreliable. DSHD 3.5" diskettes are
rated somewhere around 17-18 kbpi density; an LS-120 exhibits about
45 kbpi--the real capacity gain is achieved by packing more tracks on
the disk. The LS-120 does this with an overlay that guides as IR
laser servo setup to get 1376 tracks per side. The disk is spun
faster to improve S/N.
The Zip drives use an "embedded" servo for positioning; that is, the
servo information is part of the normal track. In addition, Zip
disks have extra tracks called "Z tracks" which, among other things,
track and hide bad sectors so that every disk looks more-or-less 100%
"good". You cannot low-level format a Zip disk--if you degauss one,
it's trash, since the servo information is written at the factory and
nowhere else.
The Iomega drives were not the first floppies to use embedded servo--
Drivetek was--and obtained about 2.8MB and later 6.4MB on a 5.25"
diskette. If you happen to run across one of the 2.88MB ones, try
reading it in a 1.2MB drive--you'll find that you can see every other
track; thus, the Drivetek recorded 160 tracks per side. It used a
dual-positioner technology; a "coarse" positioner and a "fine"
positioner. But like all embedded-servo drives, the media was
factory-formatted. (BTW, Wikipedia is utterly silent on Drivetek).
Hope this helps.
Cheers,
Chuck
'course,
if they HAD gotten 500MB/side (v 400-500KB), then it would have
been well worth it.
Speaking of which, I recall seeing announcements every so often of floppy
drives that would have seriously more capacity than the usual stuff.
Something about "vertical format" sticks in my mind, though not much more
than that. Is this what that LS120 was all about? I think I ever only
encountered _one_ of those drives... 
6:39 p.m.
Just curious.
I know *files* can be compressed*, but are there any disk drives that compressed stuff
before writing to disk, or do all drives simply just *do as they are told* to the disk.
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
* At present I only know how RLE (aka RLC) and LZW compression works.
6:24 p.m.
On Sun, 18 Nov 2007, Roy J. Tellason wrote:
Speaking of which, I recall seeing announcements
every so often of floppy
drives that would have seriously more capacity than the usual stuff.
Something about "vertical format" sticks in my mind, though not much more
than that. Is this what that LS120 was all about? I think I ever only
encountered _one_ of those drives...
IIRC, the 2.8M is vertical recording, with a Barium Ferrite diskette.
(also called "4M" (unformatted capacity) by NeXT)
If'n anybody wants to call it "2.88M", then multiply 2 * 80 * 36 * 512
and tell me exactly how many bytes are in your "megabyte"s.
A lot of the increased capacity of LS120, ZIP, Drivetek, and Floptical
came from cramming a LOT of tracks on the disk, requiring various servo
systems, and generally a significant loss of reliability.
It seems like a long time since I've seen a Bernoulli drive.
--
Grumpy Ol' Fred cisin at xenosoft.com
6:52 p.m.
On 18 Nov 2007 at 15:24, Fred Cisin wrote:
A lot of the increased capacity of LS120, ZIP,
Drivetek, and Floptical
came from cramming a LOT of tracks on the disk, requiring various servo
systems, and generally a significant loss of reliability.
It seems like a long time since I've seen a Bernoulli drive.
I've still got a 150MB dual unit--it does weigh quite a bit.
The remarkable thing about the Bernoilli drives to me was the method
of providing a stable air bearing between the head and the flexible
disk by applying a positive air pressure to the surface of the disk.
It brought to mind the illustration used involving a playing card, a
pin and a thread spool. Push the pin though the card and use it to
center the card over one end of the spool. Initially holding the
card close to the spool, blow through the opposite end of the spool
and then release the card. Instead of flying off, the card remains
attracted to the spool as long as one keeps blowing. Bernoilli
drives weren't much different in principle.
Cheers,
Chuck
19 Nov
19 Nov
6:02 p.m.
IIRC, the 2.8M is vertical recording, with a Barium
Ferrite diskette.
(also called "4M" (unformatted capacity) by NeXT)
If'n anybody wants to call it "2.88M", then multiply 2 * 80 * 36 * 512
and tell me exactly how many bytes are in your "megabyte"s.
Since that's esactly twice the capacity of a MS-DOS format HD 3.5" disk
(36 sectors/track as against 18), I assume the answer to your quesiton is
1024000
-tony
6:37 p.m.
> IIRC, the 2.8M is vertical recording, with a
Barium Ferrite diskette.
> (also called "4M" (unformatted capacity) by NeXT)
> If'n anybody wants to call it "2.88M", then multiply 2 * 80 * 36 *
512
> and tell me exactly how many bytes are in your "megabyte"s.
On Mon,
19 Nov 2007, Tony Duell wrote:
Since that's esactly twice the capacity of a
MS-DOS format HD 3.5" disk
(36 sectors/track as against 18), I assume the answer to your quesiton is
1024000
I don't think that there is any question that 102400 is a totally
indefensible, irresponsible, and ridiculous number for defining a
"Megabyte".
8:59 p.m.
Hi,
I don't think that there is any question that
102400 is
a totally indefensible, irresponsible, and ridiculous number
for defining a "Megabyte".
You're quite right, the actual number is "1048576" or 1024KB. But that's
not
your point is it?
Whilst I agree that "going decimal" is easier to understand for the average
"man in the street", at the end of the day, the *ONLY* reason that hard
drive manufacturers have gone to using 1000 instead of 1024 when calculating
sizes is that it artificially makes the drives seem bigger. Or, in other
words, it's pure marketing!
Point in case, I have a "200GB" Maxtor drive in this machine, which is
*actually* a 186GB drive. Both sizes are quite correct depending on your
definition of "Kilo", "Mega" etc.
Since computers operate in binary, it makes *VASTLY* more sense for "Kilo"
to be defined as 1024 than 1000 (2^10) etc.
Most operating systems I've used tend to agree....
TTFN - Pete.
9:11 p.m.
> I don't think that there is any question
that 102400 is
>a totally indefensible, irresponsible, and ridiculous number
>for defining a "Megabyte".
On Tue, 20 Nov 2007, Ensor wrote:
You're quite right, the actual number is
"1048576" or 1024KB. But that's not
your point is it?
Yes, it is.
There are arguments for 2 ^ 20 (1048576)
There are arguments for 10 ^ 6 (1000000)
But (10 ^ 3) * (2 ^ 10) (1024000) manages to combine the disadvantages
of both systems.
21 Nov
21 Nov
3:38 p.m.
Fred Cisin wrote:
And exactly what's stopping me from assuming a 4-bit byte when making my
calculations? That "160GB" HDD suddenly becomes a "320GB" HDD.
Peace... Sridhar
> I
don't think that there is any question that 102400 is
>a totally indefensible, irresponsible, and ridiculous number
>for defining a "Megabyte".
On Tue, 20 Nov 2007, Ensor wrote:
You're quite right, the actual number is
"1048576" or 1024KB. But that's not
your point is it?
Yes, it is.
There are arguments for 2 ^ 20 (1048576)
There are arguments for 10 ^ 6 (1000000)
But (10 ^ 3) * (2 ^ 10) (1024000) manages to combine the disadvantages
of both systems. 
4:51 p.m.
Whenever I see this argument come up, the first thing I think is that
it really does not matter. Really, if looking at a file and megabytes
will fit but mebibytes will not - you are too damn close to the edge
anyway, and deserve to run into troubles.
--
Will
22 Nov
22 Nov
2:02 a.m.
William Donzelli wrote:
Whenever I see this argument come up, the first thing
I think is that
it really does not matter. Really, if looking at a file and megabytes
will fit but mebibytes will not - you are too damn close to the edge
anyway, and deserve to run into troubles.
Thank you.
Doc
19 Nov
19 Nov
9:16 p.m.
Ensor wrote:
Whilst I agree that "going decimal" is
easier to understand for the
average "man in the street", at the end of the day, the *ONLY* reason
that hard drive manufacturers have gone to using 1000 instead of 1024
when calculating sizes is that it artificially makes the drives seem
bigger. Or, in other words, it's pure marketing!
Except proft margin ... then meg-a-bucks is binary. :)
Point in case, I have a "200GB" Maxtor drive in this machine, which is
*actually* a 186GB drive. Both sizes are quite correct depending on your
definition of "Kilo", "Mega" etc.
Since computers operate in binary, it makes *VASTLY* more sense for
"Kilo" to be defined as 1024 than 1000 (2^10) etc.
It still is.
Most operating systems I've used tend to agree....
Other than windows ... it is 640K OS.
TTFN - Pete.
9:38 p.m.
On Mon, 19 Nov 2007, woodelf wrote:
MICROS~1 was inconsistent. FDISK used 2 ^ 20 for MB, but other modules
didn't. FORMAT calls the 1.4M diskette "1.44", indicating that it used
(2 ^ 10) * (10 *3)
"Kilo" to be defined as 1024 than 1000 (2^10) etc.
It still is.
> Most operating systems I've used tend to agree.... Other than windows ... it is 640K OS.
Windoze 3.10 required that there be some HIMEM.SYS RAM (80286, above 1M)
Windoze 95 required a 80386SX or above.
Windoze 98 would not install unless there was a math FPU.
Windoze XP can not run in the 16M max of an 80386SX
What does "Vista" require?
Note: The college that I work at was named "Vista College" for ~30 years.
Last year, when MICROS~1 announced Windoze Vista, the college changed its
name, to "Berkeley City College".
20 Nov
20 Nov
1:39 a.m.
On 19 Nov 2007 at 18:38, Fred Cisin wrote:
MICROS~1 was inconsistent. FDISK used 2 ^ 20 for MB,
but other modules
didn't. FORMAT calls the 1.4M diskette "1.44", indicating that it used
(2 ^ 10) * (10 *3)
Until the rest of the world decided otherwise, I referred to HD disks
as 1200K and 1440K. At least that was honest. The 1.2MB and 1.44MB
were simply perversions, I assume for shorthand purposes.
To their credit, as of MS-DOS 6.22, the HELP for FORMAT gives 1440K,
1200K and 2800K as the *first* of several alternatives for specifying
capacity. 2K and later drops the "K" forms in the HELP file, but
FORMAT still accepts them.
So honesty is at least nodded at.
Cheers,
Chuck
4:28 a.m.
On Nov 20, 2007 1:59 AM, Ensor <classiccmp at memory-alpha.org.uk> wrote:
Point in case, I have a "200GB" Maxtor drive
in this machine, which is
*actually* a 186GB drive. Both sizes are quite correct depending on your
definition of "Kilo", "Mega" etc.
Since computers operate in binary, it makes *VASTLY* more sense for "Kilo"
to be defined as 1024 than 1000 (2^10) etc.
Most operating systems I've used tend to agree....
Indeed, and Seagate got sued for exactly this not too long ago:
http://news.zdnet.co.uk/hardware/0,1000000091,39290393,00.htm?r=1
Hopefully this "1MB = 1000000 bytes" rubbish the drive manufacturers
keep peddling will be over soon. I can't imagine even the marketers
like class-action lawsuits that much.
Ed.
9:07 a.m.
listmailgoeshere at gmail.com wrote:
On Nov 20, 2007 1:59 AM, Ensor <classiccmp at
memory-alpha.org.uk> wrote:
But we'll still be stuck with "MebiBytes" forever more.
Doc
Point in case, I have a "200GB" Maxtor
drive in this machine, which is
*actually* a 186GB drive. Both sizes are quite correct depending on your
definition of "Kilo", "Mega" etc.
Since computers operate in binary, it makes *VASTLY* more sense for "Kilo"
to be defined as 1024 than 1000 (2^10) etc.
Most operating systems I've used tend to agree....
Indeed, and Seagate got sued for exactly this not too long ago:
http://news.zdnet.co.uk/hardware/0,1000000091,39290393,00.htm?r=1
Hopefully this "1MB = 1000000 bytes" rubbish the drive manufacturers
keep peddling will be over soon. I can't imagine even the marketers
like class-action lawsuits that much.
8:36 p.m.
Hi,
Indeed, and Seagate got sued for exactly this not too
long ago:
Interesting article, thanks.
I hadn't realised flash memory vendors were pulling the same trick....
Hopefully this "1MB = 1000000 bytes" rubbish
the drive manufacturers
keep peddling will be over soon....
Agreed, but I think it's one of those things which rears it's ugly head
every so often. :-(
TTFN - Pete.
2:27 p.m.
> IIRC, the 2.8M is vertical recording, with a
Barium Ferrite diskette.
> (also called "4M" (unformatted capacity) by NeXT)
> If'n anybody wants to call it "2.88M", then multiply 2 * 80 * 36 *
512
> and tell me exactly how many bytes are in your "megabyte"s.
On Mon,
19 Nov 2007, Tony Duell wrote:
Since that's esactly twice the capacity of a
MS-DOS format HD 3.5" disk
(36 sectors/track as against 18), I assume the answer to your quesiton is
1024000
I don't think that there is any question that 102400 is a totally
indefensible, irresponsible, and ridiculous number for defining a
"Megabyte".
3:01 p.m.
On 20 Nov 2007 at 19:27, Tony Duell wrote:
Assuming you meant 1024000 (1024*1000), I agree
totally. I can justify
1024^2 (1048576). I can justify 10^6 (1000000). But to mix the 2 systems
is ridiculous.
Consider that the disk as manufactured is sold as a "2MB" disk.
Let's see, raw capacity is 12500 bytes per track, 160 tracks (80
cylinders, 2 sides) = 2,000,000 bytes exactly.
So getting 1,474,560 bytes billed as "1.44MB" when the manufacturer
uses 1M = 1,000,000 is quite a nice bonus. You get an additional
34,560 bytes.
Cheers,
Chuck
3:07 p.m.
> I don't think that there is any question that
102400 is a totally
> indefensible, irresponsible, and ridiculous number for defining a
> "Megabyte".
On Tue, 20 Nov 2007, Tony Duell wrote:
Especially as you've dropped an order of magnitude
there (sorry, couldn't
resist).
Thanks
If I'm this clumsy with a keyboard, I'd better be very careful when
soldering.
Assuming you meant 1024000 (1024*1000), I agree
totally. I can justify
1024^2 (1048576). I can justify 10^6 (1000000). But to mix the 2 systems
is ridiculous
I wonder what defintions have been used for a gigabyte. 2^30 and 10^9 are
obvious and easy to justify. Did anyone ever use 2^20*10^ or 2^10*10^6 I
wonder?
Well, probably 2^20*10^ 3 (your turn)
I've seen both. But usually expressed in terms of MBs
("A GB is 1024 MB"/"A GB is 1000 MB")
(1024000000/1048576000)?
It's as futile an argument as trying to explain "DB9".
(a 25 pin shell, usually with 1 through 8 and 20)
--
Grumpy Ol' Fred cisin at xenosoft.com
4:37 p.m.
I wonder what
defintions have been used for a gigabyte. 2^30 and 10^9 are
obvious and easy to justify. Did anyone ever use 2^20*10^ or 2^10*10^6 I
wonder?
Well, probably 2^20*10^ 3 (your turn) I've seen both. But usually expressed in terms of
MBs
("A GB is 1024 MB"/"A GB is 1000 MB")
(1024000000/1048576000)?
OK, but since we've already seen 3 definitions for MB, I guess that means
a GB could be :
10^9 (1000 * 10^6)
10^6*2^10 (1000 * (2^10*10^3) or 1024 * 10^6))
10^3*2^20 (1000 * 2^20 or 1024 * (2^10*10^3))
2^30 (1024 * 2^20)
where the parthenesised expressions give the ways each value could be
obtained from onwe of the multipliers you gave and a definintion of MB
we've already seen in the obvious way.
It's as futile an argument as trying to explain
"DB9".
(a 25 pin shell, usually with 1 through 8 and 20)
Although I haev seen 2-7,20 and 22 :-)
-tony
18 Nov
18 Nov
5:11 p.m.
Sort of unavoidable because to get the 500MB/side they
went to 100TPI drives.
How many tracks did they put on the disk? I know that some 100tpi systems
were 77 track. Would it hae been a major loss to use 96tpi drives, which
could at least have read 40 track (48 tpi) disks by double-stepping.
Not as big a problem then as it may be today, because the high price of
the 8050/8250s tended to put them into a different market, mostly business
and institutional, where price and compatibility with the smaller and cheaper
units wasn't usually an issue. And of course the IEEE bus was compatible
so you could easily convert among drives (until the serial versions came
along) as long as you had one of the (also expensive) IEEE<>IEEE cables.
It's been a long time since I used one of these 'in anger' but wasn't
there an issue witch copying one of the random-access file types between
disks? (or maye between disks in different drive units). If I'm
rememebring correctly, it means the converting between 4040 and 8050
disks is a pain even if you haev both drive units .
-tony
6:31 p.m.
On Sun, Nov 18, 2007 at 10:11:14PM +0000, Tony Duell wrote:
It's been a long time since I used one of these
'in anger' but wasn't
there an issue witch copying one of the random-access file types between
disks? (or maye between disks in different drive units). If I'm
rememebring correctly, it means the converting between 4040 and 8050
disks is a pain even if you haev both drive units .
My recollection is that in general, CBM DOS "relative" files weren't
particularly portable from DOS version to DOS version. I think you
had to understand the record structure and copy them one record at
a time. I think you might have been able to copy relative files from
one diskette to another in the same drive unit, but I never tried it,
so that's a faint memory and mere speculation.
Real "random-access" files weren't really supported under CBM DOS - games
like Zork that did do random access across the disc used their own
schemes and just marked the used blocks as unavailable to CBM DOS. Your
code just did block-reads and block-writes and ignored the directory track,
typically.
I did work a little with relative files with a C-64 and a 1541, but I think
that 99% of what I ran across were sequential files (executable code,
picture files, music files, source...) Those are easy to copy.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 18-Nov-2007 at 23:20 Z
South Pole Station
PSC 468 Box 400 Temp -42.2 F (-41.2 C) Windchill -64.8 F (-53.8 C)
APO AP 96598 Wind 6.6 kts Grid 79 Barometer 685.4 mb (10425 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
11:51 p.m.
Ethan Dicks wrote:
On Sun, Nov 18, 2007 at 10:11:14PM +0000, Tony Duell
wrote:
4040 and 2031 REL files were portable to 1540/1541/1571 if one simply
read the records and wrote them out. Writing it sector by sector
probably would have worked as well, but I have not done research.
8050 and on up (8250, SFD, etc.) use Super Side sectors, which made
sector copies impossible, and I think record copies only possible if the
number of records was under a sertain limit.
As I recall the 1581 used an entirely different scheme for REL files, so
all bets are probably off on that unit.
Jim
--
Jim Brain, Brain Innovations (X)
brain at jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Home: http://www.jbrain.com
It's been a long time since I used one of
these 'in anger' but wasn't
there an issue witch copying one of the random-access file types between
disks? (or maye between disks in different drive units). If I'm
rememebring correctly, it means the converting between 4040 and 8050
disks is a pain even if you haev both drive units .
My recollection is that in general, CBM DOS "relative" files weren't
particularly portable from DOS version to DOS version. I think you
had to understand the record structure and copy them one record at
a time. I think you might have been able to copy relative files from
one diskette to another in the same drive unit, but I never tried it,
so that's a faint memory and mere speculation.
6088
days inactive
6092
days old
27 comments
14 participants
participants (14)
-
aliensrcooluk＠yahoo.co.uk -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
brain＠jbrain.com -
cclist＠sydex.com -
cisin＠xenosoft.com -
classiccmp＠memory-alpha.org.uk -
dm561＠torfree.net -
doc＠mdrconsult.com -
ethan.dicks＠usap.gov -
listmailgoeshere＠gmail.com -
ploopster＠gmail.com -
rtellason＠verizon.net -
wdonzelli＠gmail.com