6 Oct
2007
6 Oct
'07
9:09 p.m.
Hi Guys,
I've been approached by an artist who has many 5.25" Cromemco
CDOS disks containing artwork from early in her career the
she would like to recover. She has already made arrangements
with the supplier of the original software to convert the files
to something she can use on a modern PC, however she needs the
files extracted from the CDOS disks.
As there are several hundred disks, I would really like to find
a PC based solution which I can automate.
So far I can have tried the shareware version of 22disk, which can
list the directory, however it reports multiple linked sectors in
two of the three sample disks I am looking at, and also gets
unrecoverable errors on sector 1 of every track (sector 1 on
Cromemco disk is problematic with a PC - I've already got the
drive slowed slightly, which allows ImageDisk to read and
recreate the entire disk. So I have access to all of the sector
data, but no way to feed it to 22disk.
I've also tried Uniform, however it gets an unrecoverable error
on any attempt to access the disk - in fact the error comes at
the moment the drive selects, so I don't believe it's even trying,
possibly because the P200 PC in my imaging station is "Way too fast"
for software timing loops etc.
So I am left with the option to extract the files from the ImageDisk
images - what I need are technical details on the CDOS file system.
CDOS is "CP/M compatible", does anyone know if the file system is
identical - if not, can anyone point me at technical details. If yes,
can anyone point me at a good description of the CP/M file system (It's
been years since I needed to dig deeply into it).
Anyone got source code ('C' preferred) for extracting files from
CP/M?
I have found sector->cluster mapping tables in the back of the CDOS
manual, which hopefully will help sort out the XLT issues etc.
Any other assistance/suggestions/pointers etc. would be most welcome.
Regards,
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
6 Oct
6 Oct
9:14 p.m.
On 6 Oct 2007 at 21:09, Dave Dunfield wrote:
So far I can have tried the shareware version of
22disk, which can
list the directory, however it reports multiple linked sectors in
two of the three sample disks I am looking at, and also gets
unrecoverable errors on sector 1 of every track (sector 1 on
Cromemco disk is problematic with a PC - I've already got the
drive slowed slightly, which allows ImageDisk to read and
recreate the entire disk. So I have access to all of the sector
data, but no way to feed it to 22disk.
Mask out the index pulse if all you're going to do is read. 22Disk
needs an index only for formatting (the old 10x512 problem). The
same should be the case with Uniform. Also, I show FOUR different
5.25" CDOS formats, which one are you using? Usually when you get
cross-linked files, it's an issue with the definition that you're
using. AFAIK, at least from the CDOS samples I have here, the
allocation and naming setup is the same as CP/M.
Cheers,
Chuck
9 Oct
9 Oct
3:15 p.m.
Mask out the index pulse if all you're going to do
is read. 22Disk
needs an index only for formatting (the old 10x512 problem). The
same should be the case with Uniform. Also, I show FOUR different
5.25" CDOS formats, which one are you using? Usually when you get
cross-linked files, it's an issue with the definition that you're
using. AFAIK, at least from the CDOS samples I have here, the
allocation and naming setup is the same as CP/M.
Hi Chuck,
Thanks for the suggestions.
I was told that these are DSDD CDOS diskettes, and reading them with
ImageDisk gives me double density on both sides except for the first
track which is single density.
The shareware 22disk has four Cromemco types:
CRO1 Cromemco CDOS - SSSD 48 tpi 5.25"
CRO3 Cromemco CDOS - SSDD 48 tpi 5.25"
CRO4 Cromemco CDOS - DSDD 48 tpi 5.25"
CRO6 Cromemco CP/M - SSDD 48 tpi 5.25"
Of these, CRO4 (and only CRO4) gives me what looks like a readable
directory with reasonable filenames. However it reports that files
have cross-linked blocks.
Masking out pin 8 (Index) on the 34-pin connector has no effect, I
still get:
Error reading diskette B: (Cyl 1, Side 1, Sect 1)
Sector not found
This sector DOES exist, both ImageDisk and TeleDisk can read it fine,
however no amount of "Retry" will convice 22disk to read it.
I'd try my hand at extracting the files from the images, however this
isn't going to be easy due to the "invisible" sector interleaving...
hopefully the tables in the back of the CDOs manual are correct.
Unfortunately ALL the files on the three sample disks I have are
binary in nature, so I can't easily tell if I actually got the right
data (as you usually can with a readable text file).
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
3:41 p.m.
> Mask out the index pulse if all you're going
to do is read. 22Disk
Definitely, but it still doesn't work sometimes.
On Tue, 9 Oct 2007, Dave Dunfield wrote:
Hi Chuck,
Thanks for the suggestions.
I was told that these are DSDD CDOS diskettes, and reading them with
ImageDisk gives me double density on both sides except for the first
track which is single density.
The shareware 22disk has four Cromemco types:
CRO1 Cromemco CDOS - SSSD 48 tpi 5.25"
CRO3 Cromemco CDOS - SSDD 48 tpi 5.25"
CRO4 Cromemco CDOS - DSDD 48 tpi 5.25"
CRO6 Cromemco CP/M - SSDD 48 tpi 5.25"
Of these, CRO4 (and only CRO4) gives me what looks like a readable
directory with reasonable filenames. However it reports that files
have cross-linked blocks.
That is likely to be a slightly different format than what you've got.
Can we see hex of the 32 bytes of some of the directory entries,
preferably with a LARGE file?
IIRC, Cromemco used at least 3 different ways of handling extended entries
for large files.
Do you have access to how many records per block?
How many blocks per extent?
(Is the block number stored as 8 or 16 bits?)
Masking out pin 8 (Index) on the 34-pin connector has
no effect, I
still get:
Error reading diskette B: (Cyl 1, Side 1, Sect 1)
Sector not found
This sector DOES exist, both ImageDisk and TeleDisk can read it fine,
however no amount of "Retry" will convice 22disk to read it.
Can you use ImageDisk or TeleDisk to copy the sector contents, to produce
a "copied" disk that has readable sector 1s?
IIRC, some CDOS variants (there were several) had a skew, resulting in
some other sectors on the disk being hard to get at.
If the Cromemco machine is still in existence, they don't seem to mind
disks that have reasonable gaps, so long as you get the flag in the "boot
sector" to show the correct disk size.
I'd try my hand at extracting the files from the
images, however this
isn't going to be easy due to the "invisible" sector interleaving...
hopefully the tables in the back of the CDOs manual are correct.
Unfortunately ALL the files on the three sample disks I have are
binary in nature, so I can't easily tell if I actually got the right
data (as you usually can with a readable text file).
I probably won't have access to any of my stuff in the next week or two,
but I can eventually get my notes of the CDOS interleave pattern(s).
Good luck,
--
Grumpy Ol' Fred cisin at xenosoft.com
10 Oct
10 Oct
7:16 p.m.
Can we see hex of the 32 bytes of some of the
directory entries,
preferably with a LARGE file?
IIRC, Cromemco used at least 3 different ways of handling extended entries
for large files.
Do you have access to how many records per block?
How many blocks per extent?
(Is the block number stored as 8 or 16 bits?)
Sorry, I haven't delved back into the CDOS/CPM filesystem yet - It's been
years, and I haven't found a good technical description yet (any pointers?)
I have put ImageDisk images up at: www.dunfield.com/pub/index.htm
You can use my IMDV (IMageDisk View) utility to browse through the sectors.
Can you use ImageDisk or TeleDisk to copy the sector
contents, to produce
a "copied" disk that has readable sector 1s?
Nope - the copy behaves exactly like the originals. Reads fine with IMD/TD,
but 22disk has trouble - Since 22disk also reports file mislinks, it's possible
that it's looking somewhere that isn't (I don't know if the Cyl1, Side1, Sec1
indication is real or logical - if logical, it might refer to a physical sector
that doesn't exist... Chuck?)
IIRC, some CDOS variants (there were several) had a
skew, resulting in
some other sectors on the disk being hard to get at.
If the Cromemco machine is still in existence, they don't seem to mind
disks that have reasonable gaps, so long as you get the flag in the "boot
sector" to show the correct disk size.
I've always had trouble with Cromemco disks - I find that slowing the drive
to about 290 rpm makes a huge difference in being able to read the disks.
The original machine used to create the disks is long gone, although I can
get a Cromemco machine setup if necessary - I don't relise the thought if
transferring files from a few hundred disks by serial tranfer, which is
why I would really like to get a PC based solution working...
I probably won't have access to any of my stuff in
the next week or two,
but I can eventually get my notes of the CDOS interleave pattern(s).
Thanks, anything would help. The CDOS manual has some tables at the back,
but I don't know how complete or accurate they are for all versions.
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
7:23 p.m.
New subject: Extracting CDOS and CP/M) files
On Wed, 10 Oct 2007, Dave Dunfield wrote:
Sorry, I haven't delved back into the CDOS/CPM
filesystem yet - It's been
years, and I haven't found a good technical description yet (any pointers?)
I can't immediately find one to point you to, so here is an off the top of
my head rundown of the CP/M DIRectory structure (which may be completely
indecipherable without illustrations or more careful wording):
CDOS had one or more bytes in the first physical sector of the disk to
identify which format. There ARE multiple (user modifications?) variant
formats that may have the same ID byte(s)!
There are track(s) set aside for system and boot.
Each DIRectory entry is 32 bytes.
The first byte is "user number", 0 through 31, usually 0 - a crude
substitute for subdirectories, from when disks were expensive, and
multiple people might share a floppy :-). If that byte is E5, then that
entry is unused or deleted.
Bytes 1 through 8 are "filename", padded to right with 20h
Bytes 9 through 0B are "extension", padded
One of the bytes 0C through 0F (I forget which, sorry) is the "extent"
number.
The remaining sixteen bytes, 10h through 1Fh contain a list of blocks
occupied by the file. That can be up to sixteen 8 bit entries, OR up to 8
sixteen bit entries, OR even four sixteen bit entries. Depending on
how many records per block there are, there might be more than one
"extent" represented within that block list. Unused block
numbers in the list are set to 00. Once the list is full, then the OS
starts an additional DIRectory entry with a larger "extent" number.
If you find alternating 00 and numbers, then it is normally a sixteen bit
number. If a program is wrong about THAT, then it will think that block 0
is being crosslinked many times.
If the last 8 or 12 bytes are all 00, then either it is a short file, or
that particular variant is using an 8 byte, rather than sixteen byte long list.
(and not putting more than one extent in the block list)
Obviously, the number of records (128 byte "sectors") per block makes a
difference in whether the block numbers will be 8 or sixteen bits.
Later, with some more time, we can go back and clean this up to be
readable.
--
Grumpy Ol' Fred cisin at xenosoft.com
7:36 p.m.
New subject: Extracting CDOS and CP/M) files
On Wednesday 10 October 2007 20:23, Fred Cisin wrote:
On Wed, 10 Oct 2007, Dave Dunfield wrote:
(Snip)
Let me add to that the high bit of the "name" and "type" fields being
used
for "attributes", like a file being read-only, etc. Some of these were
pretty consistent and some of them varied from one implementation to another,
thinking CP/M, CDOS (which I have no direct expierience with), Turbodos,
MMMOST, and so forth. Some were, I think, "user flags", which an
application could use, as well.
--
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
Sorry, I haven't delved back into the
CDOS/CPM filesystem yet - It's been
years, and I haven't found a good technical description yet (any
pointers?)
I can't immediately find one to point you to, so here is an off the top of
my head rundown of the CP/M DIRectory structure (which may be completely
indecipherable without illustrations or more careful wording): 
10:53 p.m.
New subject: Extracting CDOS and CP/M) files
On Wed, 10 Oct 2007, Fred Cisin wrote:
If you find alternating 00 and numbers, then it is
normally a sixteen bit
number. If a program is wrong about THAT, then it will think that block 0
is being crosslinked many times.
Can't speak for CDOS, but in CP/M block zero contains the first block of
the directory; it can't be allocated to a file. Disk allocation is kept
in a bitmap in memory, with one bit per block (I'm talking 2.x here; I
think 3.0 used two bits per block, but I'm not up on 3.0). The BIOS
indicated which blocks were allocated to the directory by supplying the
first 16 bits of the allocation bitmask, making block 0 the first block
of the directory. Since there must always be at least one block in the
directory, block 0 can't be allocated to files.
Of course, I may be wrong; wouldn't be the first time.
--
roger ivie
rivie at ridgenet.net
11:15 p.m.
New subject: Extracting CDOS and CP/M) files
> If you find alternating 00 and numbers, then it
is normally a sixteen bit
> number. If a program is wrong about THAT, then it will think that block 0
> is being crosslinked many times.
On Wed, 10 Oct 2007, Roger Ivie wrote:
Can't speak for CDOS, but in CP/M block zero
contains the first block of
the directory; it can't be allocated to a file. Disk allocation is kept
in a bitmap in memory, with one bit per block (I'm talking 2.x here; I
think 3.0 used two bits per block, but I'm not up on 3.0). The BIOS
indicated which blocks were allocated to the directory by supplying the
first 16 bits of the allocation bitmask, making block 0 the first block
of the directory. Since there must always be at least one block in the
directory, block 0 can't be allocated to files.
Of course, I may be wrong; wouldn't be the first time.
Yes, and if a program other than CP/M is attempting to analyze the disk,
and it sees what LOOKS like block 0 having been allocated to a file, then
it will choke and start talking about cross-linked files, or some other
error message. THAT is what Dave was getting from 22Disk, which is why we
are suggesting the possibility that the configuration of 22Disk might be
expecting an 8 bit number for the block number, and when encountering a
sixteen bit number less than 100h, it mistakes that for two 8 bit numbers,
one of which is ZERO.
GIGO: If the program is given wrong information about the disk format,
or the disk format is different from what is expected, the program can not
handle it successfully.
When considering a program running on another OS that is attempting to
read the CP/M disks, do NOT assume that allocation is kept in a bitmap in
memory, and/or that the BIOS preloads those bits. There are other ways to
handle it, including even making a linked list "virtual FAT".
The current question is NOT whether block 0 can be allocated to a file.
You are right that it can't (or shouldn't be able).
The current question is "WHY is 22Disk telling Dave that there are
cross-linked files?" (on a presumably valid disk)
11 Oct
11 Oct
1:06 a.m.
New subject: Extracting CDOS and CP/M) files
I don't know exactly what Dave's having a problem with, but from his
images, I could extract files using 22Disk with no problems at all.
The definition I used was CRO4.
Cheers,
Chuck
6:18 a.m.
New subject: Extracting CDOS and CP/M) files
I don't know exactly what Dave's having a
problem with, but from his
images, I could extract files using 22Disk with no problems at all.
The definition I used was CRO4.
Hi Chuck,
Exactly what version of 22disk were you using?
Is it the newer version 2.x that you mentioned earlier?
The version I am trying to use is 1.44 shareware. I am
using the CRO4 definition. I've never actually used 22disk
before, but I think I've got it right - here is a transcript
of an attempt to copy files from the diskette:
------------------------------------------------------------------------
C:\22DISK>cdir b:
CDIR Ver. 1.44-Oct 31 1996, Copyright 1996, Sydex. All rights reserved.
THIS IS AN UNREGISTERED COPY--SEE DOCUMENTATION FOR DETAILS.
Enter 1-4 character disk format type, or ENTER alone for list - cro4
Cromemco CDOS - DSDD 48 tpi 5.25" format
* WARNING! * Two files found to use same diskette block
-- You may be using the wrong disk definition
Block: 0003, File: FRAME2.PIX
B0:FRAME1.MAP B0:FRAME1.PIX B0:FRAME2.PIX
142K free on drive B:
C:\22DISK>ctod b:*.* d:
CTOD Ver. 1.44-Oct 31 1996, Copyright 1996, Sydex. All rights reserved.
THIS IS AN UNREGISTERED COPY--SEE DOCUMENTATION FOR DETAILS.
Enter 1-4 character disk format type, or ENTER alone for list - cro4
Cromemco CDOS - DSDD 48 tpi 5.25" format
Copying B0:FRAME1.MAP to D:FRAME1.MAP
Copying B0:FRAME1.PIX to D:FRAME1.PIX
Error reading diskette B: (Cyl 1, Side 1, Sect 1):
Sector not found
Enter R - retry operation, A - abort program, I - ignore error
Error reading diskette B: (Cyl 1, Side 1, Sect 1):
Sector not found
Enter R - retry operation, A - abort program, I - ignore error
Error reading diskette B: (Cyl 1, Side 1, Sect 1):
Sector not found
Enter R - retry operation, A - abort program, I - ignore error
C:\22DISK>
------------------------------------------------------------------
A little more information which may or may not be relevant:
Mike Stein reproduced one of the ImageDisk images and use his
Cromemco system to read the files and transfer them via serial
cable to the PC (thanks Mike!) - The three files I received from
him were:
FRAME1.MAP - 128 bytes
FRAME1.PIX - 88576 bytes
FRAME2.PIX - 9984 bytes
I sent these files to the author of the graphics program that
is supposed to have originated them, and he things they should
be bigger. He says the .MAP should be 768 bytes, and that the
.PIX files should be much larger - they are 512x512x256 color
images with RLE encoding, which means they could be up to 256k.
As seen above 22disk reports 143k free on a 400k disk, quick
math shows over 150k unaccounted for - There will of course
be some overhead, but not that much ... but with the cross
linked files reported, I don't know if the 143k free number
can be trusted.
Then, I dug out an XT and got it up and running (man I had
forgotten the pain involved in getting a hard drive working
on an XT)...
UNIFORM works on this machine, and I am able to extract the
same three files from the same disk.
I get FRAME1.MAP and FRAME2.PIX exactly the same size
and content as the files Mike sent to me - FRAME1.PIX
comes out at only 6144 bytes in size, although it
appears to be the same content as the first 6144 bytes
of Mikes file.
So it would appear that UNIFORM has issues as well.
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
10:39 a.m.
New subject: 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)
0020 00 46 52 41 4d 45 31 20 20 4d 41 50 00 00 00 01
0030 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 46 52 41 4d 45 31 20 20 50 49 58 00 00 00 80
0050 04 05 06 07 08 09 0a 0b 00 00 00 00 00 00 00 00
0060 00 46 52 41 4d 45 31 20 20 50 49 58 01 00 00 80
The extents continue for FRAME1.PIX:
00e0 00 46 52 41 4d 45 31 20 20 50 49 58 05 00 00 34
00f0 2c 2d 2e 2f 00 00 00 00 00 00 00 00 00 00 00 00
And then we see a new file, FRAME2.PIX:
0100 00 46 52 41 4d 45 32 20 20 50 49 58 00 00 00 4e
0110 02 03 04 05 06 00 00 00 00 00 00 00 00 00 00 00
But it's allocated using the same clusters as the first two, i.e. 02
03 04 05 06! This is a problem. How did it get that way? Disks
swapped, OS bug; any number of other things. But it's clearly wrong.
One very ugly way I've seen for this to happen is for a rogue
application program to clear part of the BDOS allocation bitmnap in
CP/M.
We do have the definitions correct; note how the record count in byte
offset 0Fh in each directory entry agrees with the number of clusters
allocated. This ain't rocket science. 22Disk got it exactly right--
cluster 03 is double-allocated in the directory. I thought it better
that 22Disk stop complaining at the first message, since additional
warnings won't tell you anything you didn't already know.
Sorry to be the bearer of bad news, but I've seen this before--and
it's why 22Disk checks for stupid OS tricks like this--and CP/M
doesn't until something goes wrong.
Cheers,
Chuck
6:27 a.m.
New subject: Extracting CDOS and CP/M) files
I can't immediately find one to point you to, so
here is an off the top of
my head rundown of the CP/M DIRectory structure (which may be completely
indecipherable without illustrations or more careful wording):
Fred, thanks for the useful info.
CDOS had one or more bytes in the first physical
sector of the disk to
identify which format. There ARE multiple (user modifications?) variant
formats that may have the same ID byte(s)!
Anyone have more info on this? - One of my main problems is determining
exactly what format these disks are in.
The remaining sixteen bytes, 10h through 1Fh contain a
list of blocks
occupied by the file. That can be up to sixteen 8 bit entries, OR up to 8
sixteen bit entries, OR even four sixteen bit entries. Depending on
how many records per block there are, there might be more than one
"extent" represented within that block list. Unused block
numbers in the list are set to 00. Once the list is full, then the OS
starts an additional DIRectory entry with a larger "extent" number.
Does each entry represent a cluster? The CDOS manual does have tables
relating physical sectors to clusters, which can be represented with an
8-bit value. These are listed for "large disks" and "small disks",
although
it's not clear where a DSDD 5.25" disk fits (it's large for a 5.25,
small compared to 8") - I'm guessing the "small disks" means any 5.25,
but I'd love to be corrected if anyone knows differently.
If the last 8 or 12 bytes are all 00, then either it
is a short file, or
that particular variant is using an 8 byte, rather than sixteen byte long list.
(and not putting more than one extent in the block list)
Obviously, the number of records (128 byte "sectors") per block makes a
difference in whether the block numbers will be 8 or sixteen bits.
Is there any information recorded on the disk which will indicate the size
of a cluster? Or the logical interleave? Or are these quantities that the
OS "just knows"?
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
12:22 p.m.
New subject: Extracting CDOS and CP/M) files
On Thu, 11 Oct 2007, Dave Dunfield wrote:
Does each entry represent a cluster? The CDOS manual does have tables
relating physical sectors to clusters, which can be represented with an
8-bit value. These are listed for "large disks" and "small disks",
although
it's not clear where a DSDD 5.25" disk fits (it's large for a 5.25,
small compared to 8") - I'm guessing the "small disks" means any 5.25,
but I'd love to be corrected if anyone knows differently.
In CP/M, each entry represents a cluster and "small disk" means
"has fewer than 256 clusters".
--
roger ivie
rivie at ridgenet.net
12:58 p.m.
New subject: Extracting CDOS and CP/M) files
> CDOS had one or more bytes in the first physical
sector of the disk to
> identify which format. There ARE multiple (user modifications?) variant
> formats that may have the same ID byte(s)!
On Thu, 11 Oct 2007, Dave Dunfield wrote:
Anyone have more info on this? - One of my main
problems is determining
exactly what format these disks are in.
It might be stored in the first sector, or it might be known only to the
OS.
On a functioning CP/M 2.x? machine, STAT DSK: gives some of the
parameters.
Does each entry represent a cluster?
Yes, each
of the numbers in the block list represents a "cluster" (which
is the MICROS~1 word for a block) Each OS company seems to have had their
own unique word (like "standards") for an allocation unit.
Remember that CP/M calls a 128 byte record a "sector" disunirregardless of
how many there are in each physical sector.
3:14 p.m.
New subject: Extracting CDOS and CP/M) files
On Thursday 11 October 2007 13:58, Fred Cisin wrote:
Yeah, "cluster" is a _DOS_ thing! CP/M called 'em "allocation
units" or
somesuch...
--
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
Does each
entry represent a cluster?
Yes, each of the numbers in the block list represents a "cluster" (which
is the MICROS~1 word for a block) Each OS company seems to have had their
own unique word (like "standards") for an allocation unit.
Remember that CP/M calls a 128 byte record a "sector" disunirregardless of
how many there are in each physical sector. 
9 Oct
9 Oct
3:45 p.m.
From: dave06a at dunfield.com> > > Mask out
the index pulse if all you're going to do is read. 22Disk > > needs an index
only for formatting (the old 10x512 problem). The > > same should be the case with
Uniform. Also, I show FOUR different > > 5.25" CDOS formats, which one are you
using? Usually when you get > > cross-linked files, it's an issue with the
definition that you're > > using. AFAIK, at least from the CDOS samples I have
here, the > > allocation and naming setup is the same as CP/M.> > Hi
Chuck,> > Thanks for the suggestions.> > I was told that these are DSDD CDOS
diskettes, and reading them with> ImageDisk gives me double density on both sides
except for the first> track which is single density.> > The shareware 22disk has
four Cromemco types:> CRO1 Cromemco CDOS - SSSD 48 tpi 5.25" > CRO3 Cromemco
CDOS - SSDD 48 tpi 5.25"> CRO4 Cromemco CDOS - DSDD 48 tpi 5.25"> CRO6
Cromemco CP/M - SSDD 48 tpi 5.25"> > Of these, CRO4 (and only CRO4) gives me
what looks like a readable> directory with reasonable filenames. However it reports
that files> have cross-linked blocks.> > Masking out pin 8 (Index) on the 34-pin
connector has no effect, I> still get:> > Error reading diskette B: (Cyl 1, Side
1, Sect 1)> Sector not found> > This sector DOES exist, both ImageDisk and
TeleDisk can read it fine,> however no amount of "Retry" will convice 22disk
to read it.
Hi
Not all the formats that 22DISK has are correct. Cross linked files
would indicate that your just not seeing the disk correctly.
Interleaving is the most likely problem but it might be just that
the tool is pointing to the wrong location for the directory.
The fact that it sees some meaningful names indicates
that is is close. I suspect interleaving may still be the
main issues.
It is too bad there are no text files, these can often
help to figure these out interleaving. You should still scan the binary
images. Sometimes there are old deleted files still on the
disk.
Dwight
_________________________________________________________________
Climb to the top of the charts!? Play Star Shuffle:? the word scramble challenge with star
power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct
3:50 p.m.
On Tue, 9 Oct 2007, dwight elvey wrote:
It is too bad there are no text files, these can
often
help to figure these out interleaving. You should still scan the binary
images. Sometimes there are old deleted files still on the
disk.
Are they binary data, or machine code?
If binary data, are there any obvious patterns or format of the records?
Run some of them through a Z80 assembler. See if the code straddling
sector boundaries has bad op codes v making sense.
Rather tedious and difficult, but worth the effort.
10 Oct
10 Oct
7:16 p.m.
Hi
Not all the formats that 22DISK has are correct. Cross linked files
would indicate that your just not seeing the disk correctly.
Interleaving is the most likely problem but it might be just that
the tool is pointing to the wrong location for the directory.
The fact that it sees some meaningful names indicates
that is is close. I suspect interleaving may still be the
main issues.
It is too bad there are no text files, these can often
help to figure these out interleaving. You should still scan the binary
images. Sometimes there are old deleted files still on the
disk.
Dwight
Yeah, I've scanned the disk images using IMDV, and there appears to be
essentially no significant text - My next step is to see if I can read
the disks on a real cromemco system, and if so, try creating a disk full
of text files and see if I can work out how to extract 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
9 Oct
9 Oct
4:23 p.m.
On 9 Oct 2007 at 15:15, Dave Dunfield wrote:
I'd try my hand at extracting the files from the
images, however this
isn't going to be easy due to the "invisible" sector interleaving...
hopefully the tables in the back of the CDOs manual are correct.
Unfortunately ALL the files on the three sample disks I have are
binary in nature, so I can't easily tell if I actually got the right
data (as you usually can with a readable text file).
If you can get TeleDisk files of them, send me a couple of samples
and I'll work the 22Disk stuff out for you. After we did 22Disk 1.x,
we ran into a bunch of formats with bizarre formatting (dissimilar
sector sizes, tracks distributed alternately from the middle of the
diskette, varying sector numbering from track to track, etc.) We
built a 22Disk 2.0 to handle them, but it requires that the format
definitions be compiled in, rather than as a text file. On the other
hand, it caches directory tracks and works out the fastest way to
read a track (I/O is track buffered). So there may be some hope
there if things are really strange.
Cheers,
Chuck
10 Oct
10 Oct
7:18 p.m.
If you can get TeleDisk files of them, send me a
couple of samples
and I'll work the 22Disk stuff out for you. After we did 22Disk 1.x,
we ran into a bunch of formats with bizarre formatting (dissimilar
sector sizes, tracks distributed alternately from the middle of the
diskette, varying sector numbering from track to track, etc.) We
built a 22Disk 2.0 to handle them, but it requires that the format
definitions be compiled in, rather than as a text file. On the other
hand, it caches directory tracks and works out the fastest way to
read a track (I/O is track buffered). So there may be some hope
there if things are really strange.
Thanks Chuck,
That would be really awesome!
I've posted both TeleDisk and ImageDisk images of the three sample
disks that I have at: www.dunfield.com/pub/index.htm
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
6639
days inactive
6643
days old
20 comments
6 participants
participants (6)
-
cclistï¼ sydex.com -
cisinï¼ xenosoft.com -
dave06aï¼ dunfield.com -
dkelveyï¼ hotmail.com -
rivieï¼ ridgenet.net -
rtellasonï¼ verizon.net