1 Jan
2010
1 Jan
'10
5:08 p.m.
I have 2 Portable IIs in fairly good shape, except that both of them, one an
HDD model and one with two FDs. Both run Memory Check and POST but fail to
boot.
During POST they both give a
"162 System Options Not Set - Run Setup" message
but when I continue I get a
"Non-system disk or disk error" message
with several known good original disks (Compaq Setup Disk, PCDOS 3.3 StartUp
disk, MSDOS 2.0 disk)
Sometimes I get the message, "Disk Boot Failure"
I tried replacing the 1987 battery in the HDD Portable II with a fresh
battery purchased recently at Frys and had no change in the failure mode.
I have two HDD/FDD controller cards and tried both in the HDD Portable II
with no change in the failure mode.
If I listen to the boot process, it sounds like it cannot read the boot
sector. That is, I can hear one seek (or maybe a rezero) to a single
location and then no more. As I recall during a DOS boot, you can hear
multiple seeks as, first the boot sector loads and then the boot loader (in
the boot sector) loads MSDOS.SYS, IO.SYS and the FAT. Since I never hear
any seeking I suspect the boot sector cannot be read.
I find it surprising that two machines having very different histories will
fail in the same way. BTW, they are not even the same type FDDs, one is a
"push button" type and the other is a "lidded" type.
I am hoping that I am making some sort of operator error which can easily be
corrected.
Any ideas?
Thanks and Happy New Years.
Tom
1 Jan
1 Jan
5:37 p.m.
On 1/1/10, Tom Gardner <thomas.gardner at sbcglobal.net> wrote:
I have 2 Portable IIs in fairly good shape, except
that both of them, one an
HDD model and one with two FDs. Both run Memory Check and POST but fail to
boot.
I got one working the middle of last year.
During POST they both give a
"162 System Options Not Set - Run Setup" message
but when I continue I get a
"Non-system disk or disk error" message
with several known good original disks (Compaq Setup Disk, PCDOS 3.3 StartUp
disk, MSDOS 2.0 disk)
You will probably need to boot a genuine Compaq setup floppy to set
the drive type bits and such. Until then, it's probably confusing
what sort of drive you have and unable to read disks as a consequence.
You say "Compaq Setup Disk", but do you know that the setup disk you
have matches and is some basic (360K) format? That's the problem I
had trying to get mine booting.
I tried replacing the 1987 battery in the HDD Portable
II with a fresh
battery purchased recently at Frys and had no change in the failure mode.
That will help retain the values, but you still have to set them to
non-random contents.
-ethan
5:37 p.m.
On 1/1/10, Ethan Dicks <ethan.dicks at gmail.com> wrote:
On 1/1/10, Tom Gardner <thomas.gardner at
sbcglobal.net> wrote:
I have 2 Portable IIs in fairly good shape,
except that both of them, one
an
HDD model and one with two FDs. Both run Memory Check and POST but fail
to
boot.
I got one working the middle of last year.
During POST they both give a
"162 System Options Not Set - Run Setup" message
but when I continue I get a
"Non-system disk or disk error" message
with several known good original disks (Compaq Setup Disk, PCDOS 3.3
StartUp
disk, MSDOS 2.0 disk)
You will probably need to boot a genuine Compaq setup floppy to set
the drive type bits and such. Until then, it's probably confusing
what sort of drive you have and unable to read disks as a consequence.
You say "Compaq Setup Disk", but do you know that the setup disk you
have matches and is some basic (360K) format? That's the problem I
had trying to get mine booting.
I tried replacing the 1987 battery in the HDD
Portable II with a fresh
battery purchased recently at Frys and had no change in the failure mode.
That will help retain the values, but you still have to set them to
non-random contents.
-ethan
5:47 p.m.
If you take the floppy drive and hook it up to another pc, can you read or
boot from those disks?
Did you put those disks into a windows 2000/xp or newer pc? Possibly as far
back as win 98/95 (I don't remember when they started) the boot sector gets
overwritten if you put a non write protected disk in the drive in windows.
On 1/1/10 5:08 PM, "Tom Gardner" <thomas.gardner at sbcglobal.net> wrote:
I have 2 Portable IIs in fairly good shape, except
that both of them, one an
HDD model and one with two FDs. Both run Memory Check and POST but fail to
boot.
During POST they both give a
"162 System Options Not Set - Run Setup" message
but when I continue I get a
"Non-system disk or disk error" message
with several known good original disks (Compaq Setup Disk, PCDOS 3.3 StartUp
disk, MSDOS 2.0 disk)
Sometimes I get the message, "Disk Boot Failure"
I tried replacing the 1987 battery in the HDD Portable II with a fresh
battery purchased recently at Frys and had no change in the failure mode.
I have two HDD/FDD controller cards and tried both in the HDD Portable II
with no change in the failure mode.
If I listen to the boot process, it sounds like it cannot read the boot
sector. That is, I can hear one seek (or maybe a rezero) to a single
location and then no more. As I recall during a DOS boot, you can hear
multiple seeks as, first the boot sector loads and then the boot loader (in
the boot sector) loads MSDOS.SYS, IO.SYS and the FAT. Since I never hear
any seeking I suspect the boot sector cannot be read.
I find it surprising that two machines having very different histories will
fail in the same way. BTW, they are not even the same type FDDs, one is a
"push button" type and the other is a "lidded" type.
I am hoping that I am making some sort of operator error which can easily be
corrected.
Any ideas?
Thanks and Happy New Years.
Tom
6:55 p.m.
Geoffrey Reed wrote:
Did you put those disks into a windows 2000/xp or
newer pc? Possibly as far
back as win 98/95 (I don't remember when they started) the boot sector gets
overwritten if you put a non write protected disk in the drive in windows.
I don't believe this is true. If it _is_ true, it's news to me, as
I've
been doing stuff with floppies on Windows for years and haven't noticed
anything as odd as that occurring.
Josh
7:23 p.m.
On 1 Jan 2010 at 18:55, Josh Dersch wrote:
I don't believe this is true. If it _is_ true,
it's news to me, as
I've been doing stuff with floppies on Windows for years and haven't
noticed anything as odd as that occurring.
S'true. Early versions of Windows 9x would unceremoniously change
the OEM name in bytes 3-10 to "xxxxIHC" where xxxx was a random
character field on any un-protected diskette. Ostensibly, this was
done for purposes of volume tracking--and done without warning.
Of course, if the write failed by corrupting the boot sector, all
manner of trouble ensued.
I don't believe that later versions (e.g. Win95 OSR2, Win98, WinME)
did this.
I think that some people were stunned by the unmitigated chutzpa of
the Win95 implementors.
--Chuck
7:40 p.m.
Chuck Guzis wrote:
On 1 Jan 2010 at 18:55, Josh Dersch wrote:
Very interesting, I had no idea. Looks like Windows 95/98 only:
http://support.microsoft.com/kb/148637.
Never heard about this before. Sounds like a useful idea poorly
implemented (cue snarky comments). Recent Windows releases definitely
don't do this or I'd have had a lot of trouble with my IBM PS/2 refdisks...
Josh
I don't believe this is true. If it _is_
true, it's news to me, as
I've been doing stuff with floppies on Windows for years and haven't
noticed anything as odd as that occurring.
S'true. Early versions of Windows 9x would unceremoniously change
the OEM name in bytes 3-10 to "xxxxIHC" where xxxx was a random
character field on any un-protected diskette. Ostensibly, this was
done for purposes of volume tracking--and done without warning.
Of course, if the write failed by corrupting the boot sector, all
manner of trouble ensued.
I don't believe that later versions (e.g. Win95 OSR2, Win98, WinME)
did this.
I think that some people were stunned by the unmitigated chutzpa of
the Win95 implementors.
--Chuck
11:35 p.m.
On 1 Jan 2010 at 19:40, Josh Dersch wrote:
Very interesting, I had no idea. Looks like Windows
95/98 only:
http://support.microsoft.com/kb/148637.
Never heard about this before. Sounds like a useful idea poorly
implemented (cue snarky comments). Recent Windows releases definitely
don't do this or I'd have had a lot of trouble with my IBM PS/2
refdisks...
Modern (1.2M 5.25 and 1.44M 3.5) floppy drives come with a "disk
changed" detection feature (really a "the drive gate was opened--
you'd better check" status). 360K and some 720K drives do not.
Microsoft apparently wanted a volume tracking feature that would work
for all removable media and so devised the above-described method;
words in the KB say that the VSN in the boot sector isn't reliable
enough and the implementors apparently didn't want to take the CP/M
route of checksumming the first few directory entries of a disk.
One wonders why MS couldn't have picked somewhere else to write if
they really needed to do it. We used to warn our customers that if
they were set on using Win95 to browse floppies to make sure that
write protect was set on every floppy they looked at--or to disable
writing (by clipping the WG* pin on the floppy connector)
permanently on the floppy drive.
--Chuck
2 Jan
2 Jan
2:24 p.m.
On Fri, 1 Jan 2010, Chuck Guzis wrote:
Modern (1.2M 5.25 and 1.44M 3.5) floppy drives come
with a "disk
changed" detection feature (really a "the drive gate was opened--
you'd better check" status). 360K and some 720K drives do not.
Microsoft apparently wanted a volume tracking feature that would work
for all removable media and so devised the above-described method;
words in the KB say that the VSN in the boot sector isn't reliable
enough and the implementors apparently didn't want to take the CP/M
route of checksumming the first few directory entries of a disk.
A quick over-simplified reminder of WHY, . . .
If you switch diskettes, and then WRITE to it, the system can mess up the
diskette because it "remembered" the directory of the wrong diskette.
Particularly when SMARTDSK is on, with write cacheing!
Simple. Press ^C whenever you change diskettes. We've all seen plenty of
times when that was NECESSARY. But, I have NEVER seen ANY mention by
MICROS~1 about ^C to be used to signal disk change to the OS. NEVER.
OK, if they won't tell people to press ^C, (and people would forget
anyway), there needs to be some other way to know about disk change. The
hardware works reliably, WHEN IT IS THERE. Ever have to mask off pin 34?
("READY" V "DISK CHANGE")
VSN should work, but it was too easy to DISKCOPY and end up with two disks
with the same VSN.
Checksumming the DIRectory works marginally OK, but won't catch a
situation where a disk has been replaced by its backup, particularly when
there have been modifications to a file that didn't change the number of
clusters of its length. Instead of the first few DIR entries, the last few
are more likely to be changed with file additions. A USE for detecting 00
vs E5 in the first byte of a DIR entry!
Instead of messing with my boot sector, howzbout creating a bogus
directory entry, as is done for disk name, or long filenames, at the
physical end of the directory sectors.
--
Grumpy Ol' Fred cisin at xenosoft.com
One wonders why MS couldn't have picked somewhere
else to write if
they really needed to do it. We used to warn our customers that if
they were set on using Win95 to browse floppies to make sure that
write protect was set on every floppy they looked at--or to disable
writing (by clipping the WG* pin on the floppy connector)
permanently on the floppy drive.
--Chuck
3:48 p.m.
On 2 Jan 2010 at 14:24, Fred Cisin wrote:
Instead of messing with my boot sector, howzbout
creating a bogus
directory entry, as is done for disk name, or long filenames, at the
physical end of the directory sectors.
This is particularly ironic since Microsoft had complete control over
what constituted an MS-DOS floppy boot sector since the beginning.
Indeed, they even changed it a couple of times.
The annoying thing about the boot sector rewrite is that it happens
if the floppy is writable (i.e. write-protect is off); it doesn't
matter if a file was opened on the floppy for writing or not.
I'm too lazy to verify this, but I believe that most standard DOS
floppy formats do not fully occupy the last sector of the FAT with
allocation information. So writing the volume tracking data (if you
had to do it) at the end of the last FAT sector in the second FAT
copy would likely do the least damage.
In any case, why track volume information if (a) the floppy doesn't
have files open for writing and (b) one can handle write-protected
floppies anyway?
But then, Microsoft has the top technical talent, don't they?
--Chuck
3 Jan
3 Jan
9:46 a.m.
On Fri, 1 Jan 2010, Chuck Guzis wrote:
> Modern (1.2M 5.25 and 1.44M 3.5) floppy drives come with a "disk
> changed" detection feature (really a "the drive gate was opened--
> you'd better check" status). 360K and some 720K drives do not.
As an aside, I have a machine using standed '360K' 5.25" drives -- that
is Tandon TM100s -- which does correclty implent a disk-changed feature.
How it does it is to have the 2 drives separately cabled to the
controller board and the drives always selected. It then looks for a
change-of-state of the write-protect line. This must change if a disk is
inserted or removed.
Anyone want to guess the machine? I have 3 of them, all different models
(one only has on disk drive).
> Microsoft apparently wanted a volume tracking
feature that would work
> for all removable media and so devised the above-described method;
> words in the KB say that the VSN in the boot sector isn't reliable
> enough and the implementors apparently didn't want to take the CP/M
> route of checksumming the first few directory entries of a disk.
I much prefer having to mount and unmount disks than having an OS that
overwrites the boot sector without asking me....
A quick over-simplified reminder of WHY, . . .
If you switch diskettes, and then WRITE to it, the system can mess up the
diskette because it "remembered" the directory of the wrong diskette.
Particularly when SMARTDSK is on, with write cacheing!
WOuldn't simply re-reading the directory into the cache on any
'open-for-writing' call get round this. Anyone who switches disks when
files are open is going to have problems anyway.
-tony
11:14 a.m.
On 3 Jan 2010 at 17:46, Tony Duell wrote:
As an aside, I have a machine using standed
'360K' 5.25" drives --
that is Tandon TM100s -- which does correclty implent a disk-changed
feature. How it does it is to have the 2 drives separately cabled to
the controller board and the drives always selected. It then looks for
a change-of-state of the write-protect line. This must change if a
disk is inserted or removed.
Anyone want to guess the machine? I have 3 of them, all different
models (one only has on disk drive).
Heh, nihil sub sole novum.
I implemented that on the Durango F85 in 1979, but I don't think
that's the machine you mean. We had a terrible problem with
customers simply changing diskettes whenever they wanted. The drives
were cabled normally, just selected and the status of the write-
protect line checked every few hundred milliseconds. The FDC was a
WD1781, so WP status was available all of the time, regardless of the
state of the motor. The drives were TM-1004Ms or Micropolis 1610s.
If a change in WP status was detected, the open file table was
checked. If a floppy had files open only for reading, a flag was
set, instructing the OS (not CP/M) to re-read the directory. If a
floppy contained drives open for writing, the system locked out any
operator action until the floppy was reinserted--and displayed a
flashing message on the screen and a repeating beep. Very annoying,
but very effective.
Many drive vendors offered a door-lock feature, but that could get to
be annoying should the OS have a problem.
One problem we never did solve was that of the customer powering the
machine down, without exiting an application. But that persisted on
all systems until someone invented the "soft power" button.
--Chuck
2:25 p.m.
On 3 Jan 2010 at 17:46, Tony Duell wrote:
No it's not.
As an aside, I have a machine using standed
'360K' 5.25" drives --
that is Tandon TM100s -- which does correclty implent a disk-changed
feature. How it does it is to have the 2 drives separately cabled to
the controller board and the drives always selected. It then looks for
a change-of-state of the write-protect line. This must change if a
disk is inserted or removed.
Anyone want to guess the machine? I have 3 of them, all different
models (one only has on disk drive).
Heh, nihil sub sole novum.
I implemented that on the Durango F85 in 1979, but I don't think
that's the machine you mean. We had a terrible problem with customers simply changing diskettes whenever they
wanted. The drives
were cabled normally, just selected and the status of the write-
protect line checked every few hundred milliseconds. The FDC was a
WD1781, so WP status was available all of the time, regardless of the
state of the motor. The drives were TM-1004Ms or Micropolis 1610s.
The machine I am thinking of uses a WD1793 or similar. The write-protect
checking is done in hardware -- as I said both drives have separate
cables back to the contrtoller PCB. The MX jumpers are fitted on the
drives, causing them to drive the cable all the time, so the WP signal is
always valid from the drive. There's a littlebit of locking involving a
flip-flop,. etc that detects if the WP line changes state. (I would have
to grab the schematics, it may be it only detects if the WP line goes to
the asseted state, not the revers trasnition. That's certain to occur
when a disk is inserted anyway).
One problem we never did solve was that of the
customer powering the
machine down, without exiting an application. But that persisted on
all systems until someone invented the "soft power" button.
YEs. Another of my machines (an early form of 'unix for the masses' -- it
has a graphical front end over Uniplus+, but you tend to end up in the
shell anyway -- has a touch switch to turn the power on and off For power
down, the service processor detects the touch on the switch and then
tells the main processor to flush the caches, etc before turning off the
main power relay.
The identity of the machines/ The first (WP used for disk change) is the
HP9826 or HP9836, the latter is the Torch XXX (I think the Whtiechapel
MG1 does something similar too).
-tony
12:08 p.m.
Tony Duell wrote:
Well, then don't run Windows 95. Probably good advice on principle.
I prefer having intelligently designed hardware that allows software to
determine when the disk can be ejected rather than allowing the media to
be yanked out at any time. The old Macintosh or Sparcstation floppy
drives are one such example. Alas the PC never had such luxury. (At
least the later-common Zip drive (despite its other flaws) had a nice
"soft" eject button which did the right thing...)
Water under the bridge at this point, I suppose since the only people
who still use floppy disks are on this mailing list :).
Josh
> Microsoft
apparently wanted a volume tracking feature that would work
> for all removable media and so devised the above-described method;
> words in the KB say that the VSN in the boot sector isn't reliable
> enough and the implementors apparently didn't want to take the CP/M
> route of checksumming the first few directory entries of a disk.
>
I much prefer having to mount and unmount disks than having an OS that
overwrites the boot sector without asking me....
12:28 p.m.
On Jan 3, 2010, at 3:08 PM, Josh Dersch wrote:
Well, then don't run Windows 95. Probably good advice on principle.
I prefer having intelligently designed hardware that allows
software to determine when the disk can be ejected rather than
allowing the media to be yanked out at any time. The old Macintosh
or Sparcstation floppy drives are one such example. Alas the PC
never had such luxury. (At least the later-common Zip drive
(despite its other flaws) had a nice "soft" eject button which did
the right thing...)
Water under the bridge at this point, I suppose since the only
people who still use floppy disks are on this mailing list :).
...and LOTS of people using them in test equipment and instrument
control and factory stuff, not to mention the fact that the entire
computing world doesn't move at the breakneck pace of what's
available in retail stores. There are quite a few businesses around
here who are running 486 desktops. Floppies will be around for quite
a while, at least 3.5" 1.44MB ones.
Just sayin'..
-Dave
--
Dave McGuire
Port Charlotte, FL
> Microsoft apparently wanted a volume tracking
feature that would
> work
> for all removable media and so devised the above-described method;
> words in the KB say that the VSN in the boot sector isn't reliable
> enough and the implementors apparently didn't want to take the CP/M
> route of checksumming the first few directory entries of a disk.
>
I much prefer having to mount and unmount disks than having an OS
that overwrites the boot sector without asking me....
1:01 p.m.
On 3 Jan 2010 at 15:28, Dave McGuire wrote:
...and LOTS of people using them in test equipment
and instrument
control and factory stuff, not to mention the fact that the entire
computing world doesn't move at the breakneck pace of what's
available in retail stores. There are quite a few businesses around
here who are running 486 desktops. Floppies will be around for quite
a while, at least 3.5" 1.44MB ones.
Indeed. I'm currently trying to talk a customer out of having to do
a *new* design using floppies. There's no compelling technical
reason for them; he seems to think that his old clients will find
comfort in sneakerneting files around. I proposed a design using
built-in flash and a 'net connection or a USB hookup. The typical
amount of data transfered is normally not more than a few tens of
kilobytes; most of a 3.5" DSHD floppy would go unused.
How many new PCs even have floppy controllers in them or connectors
on the motherboard for a drive?
--Chuck
1:14 p.m.
On Jan 3, 2010, at 4:01 PM, Chuck Guzis wrote:
Wow...a NEW design with floppies? That surprises me.
...and LOTS
of people using them in test equipment and instrument
control and factory stuff, not to mention the fact that the entire
computing world doesn't move at the breakneck pace of what's
available in retail stores. There are quite a few businesses around
here who are running 486 desktops. Floppies will be around for quite
a while, at least 3.5" 1.44MB ones.
Indeed. I'm currently trying to talk a customer out of having to do
a *new* design using floppies. There's no compelling technical
reason for them; he seems to think that his old clients will find
comfort in sneakerneting files around. I proposed a design using
built-in flash and a 'net connection or a USB hookup. The typical
amount of data transfered is normally not more than a few tens of
kilobytes; most of a 3.5" DSHD floppy would go unused. How many new PCs even have floppy controllers in them
or connectors
on the motherboard for a drive?
I honestly don't know, but admittedly the most recent PC hardware
I've worked with is in the 2.8-3GHz range. They've had controllers
and connectors but no drives.
-Dave
--
Dave McGuire
Port Charlotte, FL
9:02 p.m.
...and LOTS of people using them in test equipment
and instrument
control and factory stuff, not to mention the fact that the entire
computing world doesn't move at the breakneck pace of what's available in
retail stores. There are quite a few businesses around here who are
running 486 desktops. Floppies will be around for quite a while, at
least 3.5" 1.44MB ones.
Believe it or not, I still use daily my pentium 233MMX notebook with
windows 2000. And I can do most jobs I do with my quad core, only slower.
I just can't run altium designer :(
2:39 p.m.
I much prefer
having to mount and unmount disks than having an OS that
overwrites the boot sector without asking me....
Well, then don't run Windows 95. Probably good advice on principle.
I prefer having intelligently designed hardware that allows software to
determine when the disk can be ejected rather than allowing the media to
be yanked out at any time. The old Macintosh or Sparcstation floppy
Actually, I object to any system (hardware or software) which thinks it
knows what I want to do better than I do. There are times when I may wish
to remove a disk with files still open. Sure, let the OS warn me it's a
darn bad idea, but don't stop me from doing it if I know it's the thing I
want to do.
Water under the bridge at this point, I suppose since
the only people
who still use floppy disks are on this mailing list :).
Don't bet on it ;-)
-tony
3:22 p.m.
On Jan 3, 2010, at 2:39 PM, ard at p850ug1.demon.co.uk wrote:
> I prefer having intelligently designed
hardware that allows
> software to
> determine when the disk can be ejected rather than allowing the
> media to
> be yanked out at any time. The old Macintosh or Sparcstation floppy
Actually, I object to any system (hardware or software) which thinks
it
knows what I want to do better than I do. There are times when I may
wish
to remove a disk with files still open. Sure, let the OS warn me
it's a
darn bad idea, but don't stop me from doing it if I know it's the
thing I
want to do.
That's what paperclips were made for. :)
Josh
Water under the bridge at this point, I suppose
since the only people
who still use floppy disks are on this mailing list :).
Don't bet on it ;-)
-tony
1:43 p.m.
New subject: Disk change and write cacheing (Was: Compaq Portable II -
On Sun, 3 Jan 2010, Tony Duell wrote:
WOuldn't simply re-reading the directory into the
cache on any
'open-for-writing' call get round this. Anyone who switches disks when
files are open is going to have problems anyway.
Oh, it got much worse than that!
And, you CAN have the wrong disk with identical directory sectors -
I made two copies of "The Great American Novel", I put one into the
machine and rewrote a big chunk in the middle, that did not change the
overall length. Now I put the wrong disk into the drive, . . .
In the case of MS-DOS 6.00, that was compounded by separation of
file-write V sector-write.
SMARTDSK does a through job of screwing that up.
Remember the uproar over MS-DOS 6.00, and how DBLSPACE was corrupting
disks?
SMARTDSK was a fairly simple disk cacheing add-on.
When doing WRITE cacheing, SMARTDSK received the write request, told the
OS that the write had been successfully completed, and then proceeded to
try to do it, when time permitted.
Since the OS had been told that the write had been completed, it declared
the file closed. "Go ahead and change disks now".
If the file write was the last thing that the application program wanted
to do (word processing often ends with file write, followed by human
turning off the computer and dashing out the door), then the OS would
return to the command prompt, before the sectors actually got written!
"All done, you can turn it off now"
If an error occured during a chached write, it could not be recovered
other than RETRY, since the application program had already been assured
that the writes had been done, and had moved on.
MS-DOS 6.2x attempted to deal with the "corruption caused by disk
compression". The repair of DBLSPACE consisted of:
Make write cacheing off by default in SMARTDSK.
IF SMARTDSK write cacheing is on, do not rearrange the sequence of
writes.
IF SMARTDSK write cacheing is on, do not return to the OS prompt until
the write cache writes have been completed.
YES, I AM saying that the brouhaha over "problems with compression" was
incorrectly attributed; those particular problems were ALL caused by write
cacheing.
There can be serious problems from compression; the big problems in 6.00
were NOT.
billg tried to explain to Infoworld that the problem was not in
the compression; but he didn't want to admit to the other problems, so his
statements were misconstrued by Infoworld as attempted intimidation.
--
Grumpy Ol' Fred cisin at xenosoft.com
7:58 p.m.
New subject: Disk change and write cacheing (Was: Compaq Portable II -
Fred Cisin wrote:
Since the OS had been told that the write had been
completed, it declared
the file closed. "Go ahead and change disks now".
If the file write was the last thing that the application program wanted
to do (word processing often ends with file write, followed by human
turning off the computer and dashing out the door), then the OS would
return to the command prompt, before the sectors actually got written!
"All done, you can turn it off now"
In defense of Microsoft, disk caches had been deferring writes for years
before SMARTDRV. It only became a problem for Microsoft because they
deployed this as the default behavior without notifying the user.
I'd been using disk caches since the mid 1980s (anyone remember the 35K
"Lightening"?) and willingly turned that behavior on since it made
working with floppy-only systems tolerable. But the difference with me
is that I, an informed user, made that choice and was aware of the
behavior. I never lost data... but then again, I never suffered media
failure.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
4 Jan
4 Jan
10:44 a.m.
New subject: Disk change and write cacheing (Was: Compaq Portable II -
On Sun, 3 Jan 2010, Jim Leonard wrote:
In defense of Microsoft, disk caches had been
deferring writes for years
before SMARTDRV. It only became a problem for Microsoft because they
deployed this as the default behavior without notifying the user.
They also deployed it at the same time as disk compression, which people
were scared of. When user actions caused deferred writes to corrupt
disks, the disk compression was blamed. Infoworld, who by that time no
longer had competence in testing, set up a loop to do some macros in word
processing, some macros in a spreadsheet, maybe a file copy or two, a
FULL RESET, REPEAT. That, of course, resulted in corruption, since there
were deferred writes waiting each time the RESET was done. Infoworld
had literally dozens of articles about "Disk compression damages disks".
billg contacted the editor and said that their test suite was flawed
(TRUE!). Infoworld ran an editorial accusing billg of intimidation.
(probably TRUE, but not in this specific case)
They also, by default, didn't give users a choice. The installation of
Windoze 3.10 installed and turned on SMARTDRV. On one machine, I
encountered a disk hardware error towards the end, while it was installing
fonts (a consistent error that neither SSTOR nor SPINRITE could find!).
Normally, I would record the filename of the file that had a problem, "IGNORE"
the failed write, complete the installation, rename that file on the disk
"BADSECT", and manually install that file. But, because the file "had
already been successfully written", "IGNORE" was not an option. Nor
"ABORT". Nor "FAIL". The ONLY option was "RETRY". NO WAY
OUT.
Only way out was to reboot. Since SMARTDRV rearranged writes, the
DIRectory had not been written yet, and after reboot, there was no trace
in the directory of the failed attempts, nor any record of WHERE the error
had been.
I was in the 3.10 "Beta" program, so I called MICROS~1.
How to disable SMARTDRV for WIN3.10 installation: "can't be done"
I told them that inability to operate without SMARTDRV created SERIOUS
problems, that would probably result in recalled products.
(Sure'nuff, MS-DOS 6.2x had to be created, and distributed FREE)
"You have a hardware problem, nothing that WE can do about it."
I created a stub program, renamed it "SMARTDRV.EXE" (so that WIN3.10 could
install THAT, and continued without SMARTDRV. and I created a "BADSECT"
file occupying the location with the disk error.
I'd been using disk caches since the mid 1980s
(anyone remember the 35K
"Lightening"?) and willingly turned that behavior on since it made
working with floppy-only systems tolerable. But the difference with me
is that I, an informed user, made that choice and was aware of the
behavior. I never lost data... but then again, I never suffered media
failure.
Fortunately, I hit an "irreparable" problem in the WIN3.10 installation.
Once I knew what was going on, I didn't have any problems.
WRITE cacheing requires an informed user.
BTW, any NEGATIVE feedback would get you dropped from the "Beta" program,
which is absolutely opposite of what a "Beta" program needs to be.
--
Grumpy Ol' Fred cisin at xenosoft.com
2 Jan
2 Jan
3:47 a.m.
I received 2 copies of each diskette that Tom created for he and I. My
Compaq Portable III booted both the setup disks successfully. (also no
write protects were killed in the testing)
The images are created from Soft Paq's that I archived before
ftp.compaq.com had them removed, and are not copies, but rather
generated from those utilities. If anyone needs more information on
those let me know. I have both the 720k and 360k versions. Tom was
careful to use blank diskettes in a high density drive, etc. to create
the 360k ones I tried.
below is a link to the splash screen from the setup disk
http://www.facebook.com/photo.php?pid=206530&l=73238a90bc&id=179563…
The bootup process includes a few second delay, then a long seek, then
about 10 seconds of short seeks / chatter, then another long seek.
Tom is hearing none of this, so it is sounding like something very early
and very fundamental.
Hope this unleashes some other ideas for him.
Jim
Geoffrey Reed wrote:
If you take the floppy drive and hook it up to another
pc, can you read or
boot from those disks?
3 Jan
3 Jan
9:50 a.m.
On 2 Jan 2010 at 3:47, jim s wrote:
Tom is hearing none of this, so it is sounding like
something very
early and very fundamental.
Does Tom have a set of POST ROMs (i.e. those from Landmark, for
example)? They can diagnose a lot of very basic problems right at
the start, including some floppy issues.
If he has the capability to burn EPROMs, I can probably find an image
for him.
--Chuck
12:43 p.m.
jim s wrote:
I received 2 copies of each diskette that Tom created
for he and I. My
Compaq Portable III booted both the setup disks successfully. (also no
write protects were killed in the testing)
The images are created from Soft Paq's that I archived before
ftp.compaq.com had them removed, and are not copies, but rather
generated from those utilities. If anyone needs more information on
those let me know. I have both the 720k and 360k versions. Tom was
careful to use blank diskettes in a high density drive, etc. to create
the 360k ones I tried.
Any chance you could make those available somewhere? I have two
Portable IIs that I need to restore and would like these on-hand.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
2 Jan
2 Jan
9:09 a.m.
Did you put those disks into a windows 2000/xp or
newer pc? Possibly as far
back as win 98/95 (I don't remember when they started) the boot sector gets
overwritten if you put a non write protected disk in the drive in windows.
I knew I had good reasons for disliking Microsoft operating systems. That
is plain ridiculous. No OS should overwrite a boot sector, or for that
matter just about any other part of a disk without the user explicitily
telling it to. Period.
-tony
5248
days inactive
5250
days old
28 comments
11 participants
participants (11)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
cisin＠xenosoft.com -
derschjo＠mail.msu.edu -
ethan.dicks＠gmail.com -
geoffr＠zipcon.net -
jws＠jwsss.com -
mcguire＠neurotica.com -
pu1bzz.listas＠gmail.com -
thomas.gardner＠sbcglobal.net -
trixter＠oldskool.org