11 Oct
2007
11 Oct
'07
9:51 a.m.
-----------Original Message:
Date: Thu, 11 Oct 2007 08:39:00 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: Extracting CDOS and CP/M) files
Looking at the first diskette image, it ppears that it's been
corrupted somehow (the second one is fine). Take a look at cylinder
1, side 0, sector 1. Near the beginning of the directory we see the
entries for two files, FRAME1.MAP, FRAME1.PIX (2 extents)
<snip>
-----------Reply:
That's what I see: the first and third image have cross-linked files
but the second one looks OK; the question is whether the disks
themselves have a problem or whether Dave's IMD program got
confused. The first image seems to start on sector 2 and wrap
around; however, the third does start on sector1 but has errors
nevertheless.
mike
11 Oct
11 Oct
11:40 a.m.
On 11 Oct 2007 at 13:51, M H Stein wrote:
That's what I see: the first and third image have
cross-linked files
but the second one looks OK; the question is whether the disks
themselves have a problem or whether Dave's IMD program got
confused. The first image seems to start on sector 2 and wrap
around; however, the third does start on sector1 but has errors
nevertheless.
(Disclaimer: I haven't looked at the third image yet)
But it's not TeleDisk or ImageDisk that's messed up. Note that in
the first disk, the cross-linking/double-allocation entries are
contained in the same physical sector.
I'll grab a gander at the third disk later today when I have a
chance.
Cheers,
Chuck
12:24 p.m.
From: cclist at sydex.com> To: cctalk at
classiccmp.org> Date: Thu, 11 Oct 2007 11:40:11 -0700> Subject: Re: Extracting CDOS
and CP/M) files> > On 11 Oct 2007 at 13:51, M H Stein wrote:> > >
That's what I see: the first and third image have cross-linked files> > but the
second one looks OK; the question is whether the disks> > themselves have a problem
or whether Dave's IMD program got> > confused. The first image seems to start on
sector 2 and wrap > > around; however, the third does start on sector1 but has
errors > > nevertheless.> > (Disclaimer: I haven't looked at the third
image yet)> > But it's not TeleDisk or ImageDisk that's messed up. Note that
in > the first disk, the cross-linking/double-allocation entries are > contained in
the same physical sector. >
Hi
I wonder if the maximum cluster number is 2F. The rouge
program may have just overflowed the cluster counts.
As you've stated, I don't think programs like IMD could
do such damage.
Knowing the 2F size might help to partition the images.
Dwight
_________________________________________________________________
Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctW…
12:49 p.m.
On 11 Oct 2007 at 12:24, dwight elvey wrote:
I wonder if the maximum cluster number is 2F. The
rouge
program may have just overflowed the cluster counts.
As you've stated, I don't think programs like IMD could
do such damage.
Knowing the 2F size might help to partition the images.
The cluster size appears to be 2K, with 193 clusters on the disk
(386K, with 1K=1024). This jibes nicely with the physical format
(39x2x10x512) = 390K, less 4K (2 clusters) for a directory.
The first file drops right into place using these numbers.
Cheers,
Chuck
1:05 p.m.
On Thu, 11 Oct 2007, dwight elvey wrote:
I wonder if the maximum cluster number is 2F.
Not likely
The rouge program may have just overflowed the cluster
counts.
The rogue program is likely to be the OS/user.
Many people would forget to hit ctrl-C when they switched diskettes.
BTW, Ctrl-C worked with MS-DOS, but wasn't ever documented by MICROS~1.
Now that 22Disk and the rest of the tools have been exonerated, we can
concentrate on ways to read the hard to read sectors - a ubiquitous
problem with Cromemco disks.
2:03 p.m.
On 11 Oct 2007 at 13:05, Fred Cisin wrote:
The rogue program is likely to be the OS/user.
Many people would forget to hit ctrl-C when they switched diskettes.
In theory, that's what the feature of the CP/M directory checksum was
supposed to avoid ("DISK R/O" error). But I don't know if CDOS
implemented it--and, in any case, the hole was big enough that you
could drive a Peterbilt through it. Earlier versions of MS-DOS also
suffered with this problem on 360K drives with no "Disk Changed"
line.
At Durango, we also had the problem. It was fixed it by keeping a
"Files Open" flag for each drive (maintained by the filesystem).
Every 2 seconds or so, each drive's "Write Protected" status was
polled (didn't require turning the drive motor on or loading the
heads, so it was fast). If it changed and there were files open, an
audible alarm was sounded and a message saying in essence "Put that
floppy back, idiot!" was displayed until the disk was again inserted.
The one we never could figure a way around was the customer turning
the power off before an application could terminate and close any
open files, update indices, etc.
The problem is still with us today. Nihil sub sole novum.
Cheers,
Chuck
3:10 p.m.
On Thu, 11 Oct 2007, Chuck Guzis wrote:
The one we never could figure a way around was the
customer turning
the power off before an application could terminate and close any
open files, update indices, etc.
The problem is still with us today. Nihil sub sole novum.
Current method is to
treat "shutdown" as a "request", not a command.
For the youngsters who weren't around in those days:
In MS-DOS 6.00 (and some earlier incidents back to Windoze 3.10) MICROS~1
exacerbated that problem horribly with SMARTDRV.
People would turn off their computers as soon as the DOS prompt reappeared
after word processing, spreadsheets, etc., and some or all of the new data
and DIR would not have been written yet!
The blame was always hung on the disk compression, since that was what
people NOTICED being different; but the compression was NOT the problem.
Eventually, MICROS~1 had to do a free update (6.2x) to fix it.
The repairs that were made to fix the compression related problems
consisted of:
SMARTDRV would default to not doing WRITE caching.
If write caching had been enabled, SMARTDRV would no longer change the
sequence that cached sectors were written (which had provided some
additional performance)
If write caching were enabled, then when an application ended, SMARTDRV
would not relinquish control back to DOS to display tyhe prompt until the
write buffers had been written.
Those were the patches that "fixed the bugs in the compression system".
Infoworld had "proven" that the compression was bad by setting up a script
to WP, Lotus, etc. and a COLD restart in a loop. Bill Gates contacted the
editor, and because billg would not admit to flaws in SMARTDRV (or
anything else), he just told the editor that their testing methodology was
flawed. That resulted in an editorial denouncing MICROS~1 for the call.
Ah, the good old days.
3:25 p.m.
Fred Cisin wrote:
The blame was always hung on the disk compression,
since that was what
people NOTICED being different; but the compression was NOT the problem.
Smartdrv was purely a disk cache, wasn't it? The compression was something
else... umm... doublespace?
Ah, the good old days.
And then Windows came along...
4:11 p.m.
> The blame was always hung on the disk
compression, since that was what
> people NOTICED being different; but the compression was NOT the problem.
On Thu, 11 Oct 2007, Jules Richardson wrote:
Smartdrv was purely a disk cache, wasn't it?
Yes. But MICROS~1 was completely clueless what the risks were and how to
deal with them for WRITE caching (what happens if the power goes off, or a
disk error occurs before the cached stuff gets written?)
The compression was something
else... umm... doublespace?
Therein hangs a bizarre tale of conflict and betrayal between MICROS~1 and
Stac Electronics (billg said, "I'm having a bad day", when the court
awarded damages), and the differences between DOS 6.20, 6.21, 6.22.
Ah, the good
old days.
And then Windows came along...
4:23 p.m.
On 11 Oct 2007 at 16:11, Fred Cisin wrote:
> Therein hangs a bizarre tale of conflict and
betrayal between
MICROS~1 and
Stac Electronics (billg said, "I'm having a
bad day", when the court
awarded damages), and the differences between DOS 6.20, 6.21, 6.22.
The innards of Doublespace got laid out on exactly one MSDN CD, IIRC.
After that, the information mysteriously vanished (Did we make
THAT?). (I still have the CD).
Cheers,
Chuck
4:54 p.m.
> Therein hangs a bizarre tale of conflict and
betrayal between
> MICROS~1 and
> Stac Electronics (billg said, "I'm having a bad day", when the court
> awarded damages), and the differences between DOS 6.20, 6.21, 6.22.
On Thu, 11 Oct 2007, Chuck Guzis wrote:
The innards of Doublespace got laid out on exactly one
MSDN CD, IIRC.
After that, the information mysteriously vanished (Did we make
THAT?). (I still have the CD).
Did they ever do comparable docs of Drivespace?
8:14 p.m.
From: cclist at sydex.com ---snip---> > The one
we never could figure a way around was the customer turning > the power off before an
application could terminate and close any > open files, update indices, etc.> >
The problem is still with us today. Nihil sub sole novum.>
Hi
That is why HDOS for H8/89 had volume numbers assigned
to each disk. If the user was faithful and used a new number
for each formatting, one was protected against overwriting,
or so I'm told.
Most didn't do this and trashed there disk.
I'd always thought that it wouldn't have hurt to use one more buffer
and check to see if the disk in the drive had a matching dir and
allocation table.
Another way might be to keep a random number, create from
a hash of the information on the disk, that would need to be read
before writing.
Dwight
_________________________________________________________________
Boo!?Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmail…
10:29 p.m.
On 11 Oct 2007 at 20:14, dwight elvey wrote:
Another way might be to keep a random number, create
from
a hash of the information on the disk, that would need to be read
before writing.
Uh, that's what CP/M does--that value of CKS in the DPB tells CP/M
how many directory entries to checksum--which it does on open calls.
Unfortunately, one needn't do an open call to create a file--a valid
filled-in FCB usually is good enough. There were applications that
swapped FCBs around--and before CP/M 2.0, there were no random-access
positioning calls, so programs would do their own FCB fiddling. A
hole that you could drive a truck through.
All of that got pretty much taken care of with CP/M 3.0 and MP/M, but
CDOS predates those. But even if you could tell that a disk was
changed, there was no system noficiation function to call in CP/M to
tell the OS to check the disk.
Cheers,
Chuck
11:51 a.m.
-----------Original Message:
Date: Thu, 11 Oct 2007 08:39:00 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: Extracting CDOS and CP/M) files
Looking at the first diskette image, it ppears that it's been
corrupted somehow (the second one is fine). Take a look at cylinder
1, side 0, sector 1. Near the beginning of the directory we see the
entries for two files, FRAME1.MAP, FRAME1.PIX (2 extents)
<snip>
-----------Reply:
That's what I see: the first and third image have cross-linked files
but the second one looks OK; the question is whether the disks
themselves have a problem or whether Dave's IMD program got
confused. The first image seems to start on sector 2 and wrap
around; however, the third does start on sector1 but has errors
nevertheless.
I believe Chuck made his disks from the TeleDisk images, also I
get the cross-link error on the original as well.
I was told that these three disks have already visited several other
people who attempted to recover the files from them...
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
6282
days inactive
6283
days old
17 comments
7 participants
participants (7)
-
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
dave06a＠dunfield.com -
dkelvey＠hotmail.com -
dm561＠torfree.net -
julesrichardsonuk＠yahoo.co.uk