21 Apr
2000
21 Apr
'00
4:24 a.m.
Ok, so thanks to Don Maslin who sent me an NEC APC system disk
and a bit of luck I have finally been able to boot my NEC APC. I believe
the drive heads were dirty, but constant running of the disk in the drive
finally scraped away enough grime to make it read (couldn't find an 8"
head cleaning disk...must organize warehouse; drives are enclosed and I
couldn't seem to extract them from the machine to clean with
alcohol...oh well).
I stuck the disks I'm trying to recover data from in the B: drive and did a
DIR but they all come back with "NO FILE". Now of course this means
that the disks contain no files but I'm thinking there has to be something
wrong here.
The system disk is CP/M-86. I still don't know what format the disks in
question are but I assumed they were also CP/M-86. What could be
amiss here, aside from the possibility that the disks ARE empty? What
utilities are available to me on the system disk to view a raw dump of the
target disks?
I can't believe after all this effort that these damn disks contain nothing.
As always, any help or suggestions would be greatly appreciated, and
please reply directly to sellam(a)vintage.org.
Thanks!
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF Europe: April 29th & 30th, Munich, Germany
VCF Los Angeles: Summer 2000 (*TENTATIVE*)
VCF East: Planning in Progress
See http://www.vintage.org for details!
21 Apr
21 Apr
5:48 a.m.
the drive heads were dirty, but constant running of the
disk in the drive
finally scraped away enough grime to make it read (couldn't find an 8"
head cleaning disk...must organize warehouse; drives are enclosed and I
couldn't seem to extract them from the machine to clean with
alcohol...oh well).
I stuck the disks I'm trying to recover data from in the B: drive and did a
DIR but they all come back with "NO FILE". Now of course this means
First I would clean the heads. Use one of those long Qtip on a stick things.
11:28 a.m.
Sellam,
<snip>
-> I stuck the disks I'm trying to recover data from in the B:
-> drive and did a
-> DIR but they all come back with "NO FILE". Now of course this means
-> that the disks contain no files but I'm thinking there has to be
-> something
-> wrong here.
->
-> The system disk is CP/M-86. I still don't know what format the disks in
-> question are but I assumed they were also CP/M-86. What could be
-> amiss here, aside from the possibility that the disks ARE empty? What
-> utilities are available to me on the system disk to view a raw
-> dump of the target disks?
->
-> I can't believe after all this effort that these damn disks contain
nothing.
I hope the following is some help to you. I don't know CP/M very well yet.
However, I do know enough to be dangerous. What I write below pertains to
CP/M 3 and most of it is directly from the DR CP/M 3 manual. I don't have
any exposure to CP/M 86 (yet) so I don't know if this is true for that
version, but I imagine it should be.
CP/M further identifies all files by assigning each one a user number which
ranges from 0 to 15. The number is assigned when the file is created and
allows you to separate the files into sixteen file groups. This number will
precede the drive identifier as in "4B>" means user number 4, drive B. Use
the command USER to change the user number as in "A>USER 3" to change to
user area 3 on drive A. You can change both the user number and the drive by
entering the new user number and drive specifier together at the system
prompt as in "A>3B:", which will return a prompt of "3B>" to
signify the
change.
Most commands can access only those files that have the current user number.
For example, if the current user number is 7, a DIR command with no options
displays only the files that were created under user number 7.
So, perhaps the files you are looking for are under a user number other than
0?
The SHOW command can also be useful for you. The format is SHOW {d:}{[SPACE
|LABEL |USERS |DIR |DRIVE]}
d: refers to the drive number you wish to examine.
Of particular use to you will be SHOW {d:)[USERS} as in A>SHOW[USERS] or
A>SHOW B:[USERS]
This will display the current user number and all the users on the drive and
the corresponding number of files assigned to them. For example:
A>SHOW[USERS]
Active User : 1
Active Files: 0 2 3 4
A: # of files: 95 40 1 26
A: Number of free directory entries: 350
A>
With this, at least you can tell if there are any files on the disks you
have.
I hope this is some help to you.
Bill
whdawson(a)mlynk.com
11:39 a.m.
On Fri, 21 Apr 2000, Sellam Ismail wrote:
I stuck the disks I'm trying to recover data from
in the B: drive and did a
DIR but they all come back with "NO FILE". Now of course this means
that the disks contain no files but I'm thinking there has to be something
wrong here.
The system disk is CP/M-86. I still don't know what format the disks in
question are but I assumed they were also CP/M-86.
Why?
What could be
amiss here, aside from the possibility that the disks ARE empty? What
utilities are available to me on the system disk to view a raw dump of the
target disks?
The APC cupported both CP/M-86 and MS-DOS. Later today I'll look up some
specs to try to predict what the CP/M-86 would see on the MS-DOS format.
I can't believe after all this effort that these
damn disks contain nothing.
Happens all the time. People often send the wrong diskettes.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
3:29 p.m.
On Fri, 21 Apr 2000, Fred Cisin (XenoSoft) wrote:
On Fri, 21 Apr 2000, Sellam Ismail wrote:
It gives you a big fat error message. His report of the "NO FILES" response
I stuck the disks I'm trying to recover data
from in the B: drive and did a
DIR but they all come back with "NO FILE". Now of course this means
that the disks contain no files but I'm thinking there has to be something
wrong here.
The system disk is CP/M-86. I still don't know what format the disks in
question are but I assumed they were also CP/M-86.
Why?
What could be
amiss here, aside from the possibility that the disks ARE empty? What
utilities are available to me on the system disk to view a raw dump of the
target disks?
The APC cupported both CP/M-86 and MS-DOS. Later today I'll look up some
specs to try to predict what the CP/M-86 would see on the MS-DOS format. from DIR would indicate that the disk(s) are CP/M-86
format, and would be
consistant with either no files at all and also no files in
the user area -
normally 0. There is, regrettably, no program like SHOW on the CP/M-86
system disk. You just have to step through each user area and issue the
DIR command.
- don
I can't
believe after all this effort that these damn disks contain nothing.
Happens all the time. People often send the wrong diskettes.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
3:53 p.m.
Don Maslin <donm(a)cts.com> wrote:
It gives you a big fat error message. His report of the "NO FILES" response
from DIR would indicate that the disk(s) are CP/M-86 format, and would be
consistant with either no files at all and also no files in the user area -
normally 0. There is, regrettably, no program like SHOW on the CP/M-86
system disk. You just have to step through each user area and issue the
DIR command.
Hi
Does CP/M-86 have a direct call to read a sector like
CP/M-2.2 does? If so, it wouldn't take much code
to make a sector viewer.
Dwight
4:35 p.m.
On Fri, 21 Apr 2000, Don Maslin wrote:
In THIS case, due to sector size differences. But not ALWAYS. I have
seen non-CP/M disks with E5 where a CP/M directory would have been.
MS-DOS will give a big FAT :-) error message when trying to read CP/M
(actually "Probable Non-DOS disk") because it is picky about what it
expects to see in the F.A.T.
Due to reserved tracks, on 8" double density, CP/M's DIRectory will
fall AFTER the end of the MS-DOS directory, where the first file would
otherwise be likely to be. You're right that that would almost certainly
be content that would choke CP/M. But with very short files and large
clusters, and with sector interleave, it is entirely possible to have CP/M
looking at unused sectors.
Both MS-DOS and CP/M will accept and assume "empty" when encountering
a DIRectory (not the MS-DOS F.A.T.) sector of all E5. MOST MS-DOS formats
fill the empty directory sectors with 00, but not all. Some use E5, some
F6 with E5 every 32 bytes, ... What would CP/M-86 report for a directory
sector of all 00? An MS-DOS format with a large directory could easily
leave the END of the MS-DOS directory sectors where the first of the CP/M
directory sectors would be.
I don't often see use of USER in CP/M disks. Sometimes, but not often. I
think that it is more likely that they gave Sellam blank formatted
diskettes.
--
Fred Cisin cisin(a)xenosoft.com
XenoSoft http://www.xenosoft.com
2210 Sixth St. (510) 644-9366
Berkeley, CA 94710-2219
what the
CP/M-86 would see on the MS-DOS format.
It gives you a big fat error message.
5:01 p.m.
"Fred Cisin (XenoSoft)" <cisin(a)xenosoft.com> wrote:
I don't often see use of USER in CP/M disks. Sometimes, but not often. I
think that it is more likely that they gave Sellam blank formatted
diskettes.
Hi
I agree with Fred but one must make all attempts when
people have valued data. I have known programs that bypass
the OS to improve speed in data logging. This usually makes
for interesting problems when soemone tries to read
them without the right tool.
I wouldn't give up until I saw the data on all the sectors,
or at least the first 3 or 4 tracks. It is also possible
that someone erased the files, giving the empty directory.
The data would still be on the disc but it might be fragmented.
Dwight
7:02 p.m.
On Fri, 21 Apr 2000, Fred Cisin (XenoSoft) wrote:
On Fri, 21 Apr 2000, Don Maslin wrote:
In THIS case, due to sector size differences. But not ALWAYS. I have
seen non-CP/M disks with E5 where a CP/M directory would have been.
I don't recall running across that, but I'll be alert now.
what the
CP/M-86 would see on the MS-DOS format.
It gives you a big fat error message.
MS-DOS will give a big FAT :-) error message when
trying to read CP/M
(actually "Probable Non-DOS disk") because it is picky about what it
expects to see in the F.A.T.
Agreed.
Due to reserved tracks, on 8" double density,
CP/M's DIRectory will
fall AFTER the end of the MS-DOS directory, where the first file would
otherwise be likely to be. You're right that that would almost certainly
be content that would choke CP/M. But with very short files and large
clusters, and with sector interleave, it is entirely possible to have CP/M
looking at unused sectors.
Possible, but...
Both MS-DOS and CP/M will accept and assume
"empty" when encountering
a DIRectory (not the MS-DOS F.A.T.) sector of all E5. MOST MS-DOS formats
fill the empty directory sectors with 00, but not all. Some use E5, some
F6 with E5 every 32 bytes, ... What would CP/M-86 report for a directory
Rather like a CP/M directory that had its files deleted :)
sector of all 00? An MS-DOS format with a large
directory could easily
leave the END of the MS-DOS directory sectors where the first of the CP/M
directory sectors would be.
Agreed. I'll have to try the 00 bit and see what does actually
happen. I'll let you know.
I don't often see use of USER in CP/M disks.
Sometimes, but not often. I
think that it is more likely that they gave Sellam blank formatted
diskettes.
I wouldn't argue that. On the other hand, it would be prudent to check.
If he would mail one or more of the disks to me, I could examine them
and probably provide an answer.
- don
22 Apr
22 Apr
4:47 p.m.
On Fri, 21 Apr 2000, Fred Cisin (XenoSoft) wrote:
On Fri, 21 Apr 2000, Don Maslin wrote:
In THIS case, due to sector size differences. But not ALWAYS. I have
seen non-CP/M disks with E5 where a CP/M directory would have been.
MS-DOS will give a big FAT :-) error message when trying to read CP/M
(actually "Probable Non-DOS disk") because it is picky about what it
expects to see in the F.A.T.
Due to reserved tracks, on 8" double density, CP/M's DIRectory will
fall AFTER the end of the MS-DOS directory, where the first file would
otherwise be likely to be. You're right that that would almost certainly
be content that would choke CP/M. But with very short files and large
clusters, and with sector interleave, it is entirely possible to have CP/M
looking at unused sectors.
Both MS-DOS and CP/M will accept and assume "empty" when encountering
a DIRectory (not the MS-DOS F.A.T.) sector of all E5. MOST MS-DOS formats
fill the empty directory sectors with 00, but not all. Some use E5, some
F6 with E5 every 32 bytes, ... What would CP/M-86 report for a directory
sector of all 00? An MS-DOS format with a large directory could easily
leave the END of the MS-DOS directory sectors where the first of the CP/M
directory sectors would be.
CP/M-80 displays the full directory except that the "00"s are displayed
as ":"s. I zeroed out the first 512 byte sector of a CP/M-80 directory
and it displayed 16 colons followed by the actual file names in the
remaining sectors. I would assume that CP/M-86 would do the same, and
it does.
- don
what the
CP/M-86 would see on the MS-DOS format.
It gives you a big fat error message.
I don't often see use of USER in CP/M disks.
Sometimes, but not often. I
think that it is more likely that they gave Sellam blank formatted
diskettes.
--
Fred Cisin cisin(a)xenosoft.com
XenoSoft http://www.xenosoft.com
2210 Sixth St. (510) 644-9366
Berkeley, CA 94710-2219
21 Apr
21 Apr
11:50 a.m.
"Sellam Ismail" <dastar(a)siconic.com> wrote
---snip---
I stuck the disks I'm trying to recover data from
in the B: drive and did a
DIR but they all come back with "NO FILE". Now of course this means
that the disks contain no files but I'm thinking there has to be something
wrong here.
Hi Sam
You could try putting the disk into dir A after booting
and then do a DIR. The DIR function should be memory
resident and work without the system disk installed.
This would eliminate problems with the B drive.
It could be that the data was written directly to the
disk as well and may not have a directory. It
is also possible that someone accidentally formatted
the disk, in which case, the only people with the
equipment to recover it have one of those three
letter acronyms and claim to work for the US government.
Did the response come back right away or was there
a few seconds delay. If it came back right away, that
means that the drive correctly read the tracks. If
there was some delay or a bunch of seeking, the disk
was not being read correctly.
Anyway, try it in the A drive since that seems to
be working with the system disk.
Dwight
12:26 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1164 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000421/d6706f37/at…
2:12 p.m.
On Fri, 21 Apr 2000, Tony Duell wrote:
Also, by not getting error messages, that it's finding the sector numbers
that it's looking for, therefore it has the expected number of bytes per
sector and range of sector numbers (do the numbers start at 0, 1, 20, ...)
I just checked, and the NEC 8" CP/M diskettes that i"ve seen have 256
bytes per sector; but not the MS-DOS ones, therefore I retract my previous
suggestion that these might be MS-DOS diskettes.
DIR but they
all come back with "NO FILE". Now of course this means
This message is
also telling you a couple of good (?) things. Firstly
that the drive/controller is managing to read valid sectors off the disk
(so the drive is working, the heads are clean enough to read something,
etc). Otherwise you'd be getting the well-known BDOS errors. And secondly the directory makes some sense as a CP/M
directory. At least
the system thinks it does, and it thinks its empty. So it's likely (not
certain ) that the disks are CP/M86 ones.
Definitely not CERTAIN. An empty CP/M directory is indistinguishable from
a blank formatted track, and similar to empty MS-DOS directory sectors.
Since CP/M had reserved track(s), the CP/M directory would miss the FAT,
and could easily occupy sectors at the end of an MS-DOS directory. MS
Stand-alone-BASIC, which was used on a lot of NEC products, but which I
haven't seen on the APC, had a directory similar to the Coco on a middle
track; the track used by CP/M for its directory could be empty. The NEC
8" CP/M diskettes that I've seen have had several different numbers of
reserved tracks; therefore it could be a CP/M format, but not the RIGHT
one.
I think one option to the STAT command (STAT USERS,
STAT [USERS] ???)
will tell you at least which user numbers have files on the disk
Do you have any communication with the makers of the disks? Is THEIR APC
working? If so, try STAT DSK: on both machines and compare.
--
Fred Cisin cisin(a)xenosoft.com
XenoSoft http://www.xenosoft.com
2210 Sixth St. (510) 644-9366
Berkeley, CA 94710-2219
2:32 p.m.
"Fred Cisin (XenoSoft)" <cisin(a)xenosoft.com> wrote:
On Fri, 21 Apr 2000, Tony Duell wrote:
Also, by not getting error messages, that it's finding the sector numbers
that it's looking for, therefore it has the expected number of bytes per
sector and range of sector numbers (do the numbers start at 0, 1, 20, ...)
I just checked, and the NEC 8" CP/M diskettes that i"ve seen have 256
bytes per sector; but not the MS-DOS ones, therefore I retract my previous
suggestion that these might be MS-DOS diskettes.
Hi Fred
I take back what I said earlier. You are correct, the fact
that it did respond with "NO FILE" indicates that the
surface was being read. I haven't fiddle enough with
CP/M86 but I'd think that the post about USERs might have
some relevance. I don't think is is a MS-DOS disk
either. The FAT and such take up a lot of space and
surely wouldn't return "NO FILE" if CP/M tried to read it.
I think the first step is to try the STAT command as was
suggested by someone else. That will at least tell you
if space was reserved for any data by the CP/M OS.
It is still possible that someone used the disk to
write directly to sectors. There is a program called
VIEW or something that allows direct sector viewing.
That might be a good thing to try.
Dwight
PS Sellam Ismail doesn't subscribe to this group
so could people responding to his questions please CC
him at:
dastar(a)siconic.com
I have forwarded all of the earlier post so far.
DIR but
they all come back with "NO FILE". Now of course this means
This
message is also telling you a couple of good (?) things. Firstly
that the drive/controller is managing to read valid sectors off the disk
(so the drive is working, the heads are clean enough to read something,
etc). Otherwise you'd be getting the well-known BDOS errors.
4:05 p.m.
On Fri, 21 Apr 2000, Dwight Elvey wrote:
. . . I don't think is is a MS-DOS disk
either. The FAT and such take up a lot of space and
surely wouldn't return "NO FILE" if CP/M tried to read it.
In THIS case, I take it back, but because the NEC 8" CP/M disks that I've
seen used 256 bytes per sctor.
Although the FAT and such take up a lot of space, it's not THAT much, and
CP/M skips some tracks. A typical 8" (or 1.2M 5.25") MS-DOS uses 1/2K for
the boot sector, 2 copies of the FAT at 3.5K each, and 7K for the
DIRectory sectors. That is all done with by the end of the second side of
the first cylinder (#0). On double density CP/M 8", the directory hardly
ever starts before the first side of the second (#1) cylinder. Plus, the
latter parts (unused if the disk isn't full) of the MS-DOS DIRectory
sectors could be misinterpreted by CP/M as an empty directory.
Therefore, it's possible (although somewhat demented - BTDT) to actually
have two different DIRectory structures that access the same files in
order to create a distribution disk that is readable by multiple OS's!
BTW, MS-DOS CAN have reserved tracks, but I can't remember anyone other
than DEC Rainbow doing so.
BTW2, MS-DOS uses the sectors in consecutive order, CP/M often does not.
BTW3, MS-DOS uses both the second head of the cylinder before stepping to
the next cylinder. Many CP/M formats use all tracks of the first head
before using the second head.
I think the first step is to try the STAT command as
was
suggested by someone else. That will at least tell you
if space was reserved for any data by the CP/M OS.
Since the info reported by STAT is based on what it sees in the DIRectory
sectors, it would be based on the same wrong source data, and the NO FILE
diskette would be reported as empty.
It is still possible that someone used the disk to
write directly to sectors. There is a program called
VIEW or something that allows direct sector viewing.
That might be a good thing to try.
That would be great. But we'd need to get a copy onto Sellam's APC.
Does DDT86 have a read sector command?
--
Fred Cisin cisin(a)xenosoft.com
XenoSoft http://www.xenosoft.com
2210 Sixth St. (510) 644-9366
Berkeley, CA 94710-2219
4:45 p.m.
"Fred Cisin (XenoSoft)" <cisin(a)xenosoft.com> wrote:
On Fri, 21 Apr 2000, Dwight Elvey wrote:
Hi Fred
I hadn't thought this through. I just assumed that since DOS
has two copies of the FAT that it would stretch past the area
that CP/M usually uses. I guess that Sam needs some way to
look at raw sectors. I don't think we can assume anything other
than it looks like he can at least read the directory area.
Although there are not as many basic tools for CP/M-86 as
were made for CP/M 2.2, I'm sure someone had a sector viewer
program. My gut feeling is that the disk have no data on
them and were either accidentally formatted or no data was
originally copied to them.
From what you say, it is still possible that they might have
a DOS format. If one can extract the FAT, the data can be found.
Of course the DOS directory would tie it all together.
Dwight
. . . I don't think is is a MS-DOS disk
either. The FAT and such take up a lot of space and
surely wouldn't return "NO FILE" if CP/M tried to read it.
In THIS case, I take it back, but because the NEC 8" CP/M disks that I've
seen used 256 bytes per sctor.
Although the FAT and such take up a lot of space, it's not THAT much, and
CP/M skips some tracks. A typical 8" (or 1.2M 5.25") MS-DOS uses 1/2K for
the boot sector, 2 copies of the FAT at 3.5K each, and 7K for the
DIRectory sectors. That is all done with by the end of the second side of
the first cylinder (#0). On double density CP/M 8", the directory hardly
ever starts before the first side of the second (#1) cylinder. Plus, the
latter parts (unused if the disk isn't full) of the MS-DOS DIRectory
sectors could be misinterpreted by CP/M as an empty directory.
Therefore, it's possible (although somewhat demented - BTDT) to actually
have two different DIRectory structures that access the same files in
order to create a distribution disk that is readable by multiple OS's!
4:03 p.m.
On Fri, 21 Apr 2000, Fred Cisin (XenoSoft) wrote:
But MS-DOS does not use E5H and does use 00H fill in directory areas. I
suspect that this might confuse the CP/M-86 directory program a bit - a
whole bunch of null filled directory entries, all at user 0!
- don
On Fri, 21 Apr 2000, Tony Duell wrote:
Also, by not getting error messages, that it's finding the sector numbers
that it's looking for, therefore it has the expected number of bytes per
sector and range of sector numbers (do the numbers start at 0, 1, 20, ...)
I just checked, and the NEC 8" CP/M diskettes that i"ve seen have 256
bytes per sector; but not the MS-DOS ones, therefore I retract my previous
suggestion that these might be MS-DOS diskettes.
True, it is finding the sector numbers it is looking for, but it also is
finding E5H where it expects to find the user area number or there could
be either an error message or perhaps a garbaged directory display if it
found 00H by chance.
DIR but
they all come back with "NO FILE". Now of course this means
This
message is also telling you a couple of good (?) things. Firstly
that the drive/controller is managing to read valid sectors off the disk
(so the drive is working, the heads are clean enough to read something,
etc). Otherwise you'd be getting the well-known BDOS errors. And secondly
the directory makes some sense as a CP/M directory. At least
the system thinks it does, and it thinks its empty. So it's likely (not
certain ) that the disks are CP/M86 ones.
Definitely not CERTAIN. An empty CP/M directory is indistinguishable from
a blank formatted track, and similar to empty MS-DOS directory sectors. Since CP/M had reserved track(s), the CP/M directory
would miss the FAT,
and could easily occupy sectors at the end of an MS-DOS directory. MS
Stand-alone-BASIC, which was used on a lot of NEC products, but which I
haven't seen on the APC, had a directory similar to the Coco on a middle
track; the track used by CP/M for its directory could be empty. The NEC
8" CP/M diskettes that I've seen have had several different numbers of
reserved tracks; therefore it could be a CP/M format, but not the RIGHT
one.
I think one option to the STAT command (STAT
USERS, STAT [USERS] ???)
will tell you at least which user numbers have files on the disk
Do you have any communication with the makers of the disks? Is THEIR APC
working? If so, try STAT DSK: on both machines and compare.
--
Fred Cisin cisin(a)xenosoft.com
XenoSoft http://www.xenosoft.com
2210 Sixth St. (510) 644-9366
Berkeley, CA 94710-2219
4:53 p.m.
On Fri, 21 Apr 2000, Don Maslin wrote:
True, it is finding the sector numbers it is looking
for, but it also is
finding E5H where it expects to find the user area number or there could
be either an error message or perhaps a garbaged directory display if it
found 00H by chance.
But MS-DOS does not use E5H and does use 00H fill in directory areas. I
suspect that this might confuse the CP/M-86 directory program a bit - a
whole bunch of null filled directory entries, all at user 0!
Actually, MS-DOS will accept 00 OR E5 for directory fill. I've seen
bothIf the first byte of a directory entry is E5, then the space used by
that entry is available. If 00, then it is available, and no subsequent
entries have been used, so any directory search routines, including DIR
can stop. Any time a file is deleted, in addition to appropriate
manipulation of the FAT data, the first byte is changed to E5. There
used to be some silly "prevent this deleted file from being undeleted"
shareware programs that would e5 the rest of the entry.
A freshly formatted MS-DOS SHOULD be filled with 00. But E5 will still
work, and SOME companies used it, particularly in the early days.
Also, some used F6, with a 00 or an E5 every 32 bytes.
We are talking about MS-DOS, but NOT IBM compatible. There were some
weird ones.
ALSO, due to reserved tracks, the MS-DOS directory is earlier on the disk
than the CP/M one. Depending on size of the MS-DOS directory, number of
CP/M reserved tracks, side patterns, and interleave, they might or might
not overlap. The CP/M directory is more likely to start at about cluster
number 2.
--
Fred Cisin cisin(a)xenosoft.com
XenoSoft http://www.xenosoft.com
2210 Sixth St. (510) 644-9366
Berkeley, CA 94710-2219
3:40 p.m.
On Fri, 21 Apr 2000, Tony Duell wrote:
Good thought, Tony. The command is STAT USR: and it will return two
lines of information. The first reflects the current user area, while
the second reflects user areas that contain files.
- don
I stuck the
disks I'm trying to recover data from in the B: drive and did a
DIR but they all come back with "NO FILE". Now of course this means
that the disks contain no files but I'm thinking there has to be something
wrong here.
This message is also telling you a couple of good (?) things. Firstly
that the drive/controller is managing to read valid sectors off the disk
(so the drive is working, the heads are clean enough to read something,
etc). Otherwise you'd be getting the well-known BDOS errors.
And secondly the directory makes some sense as a CP/M directory. At least
the system thinks it does, and it thinks its empty. So it's likely (not
certain ) that the disks are CP/M86 ones.
One quick question. Have you tried using the USER command to look at
other users files on the disk? The user facilty of CP/M is pretty
useless, actually and mainly serves to cause problems like this. At
boot-up you're likely to be user 0, but you can change this to a number
between 0 and 15 IIRC.
I think one option to the STAT command (STAT USERS, STAT [USERS] ???)
will tell you at least which user numbers have files on the disk -tony
9017
days inactive
9018
days old
18 comments
7 participants
participants (7)
-
ard＠p850ug1.demon.co.uk -
cisin＠xenosoft.com -
dastar＠siconic.com -
donm＠cts.com -
elvey＠hal.com -
mikeford＠socal.rr.com -
whdawson＠mlynk.com