[Coco] Playing around with SuperIDE CF
gene heskett
gheskett at wdtv.com
Sat Apr 28 13:01:25 EDT 2012
On Saturday, April 28, 2012 12:08:48 PM Paulo Lindoso did opine:
> Hi,
>
> I am playing around with the dd dump of SuperIDE CF, so that I can
> create an easy way to expand toolshed.
>
> The problem is that I can't seem to split the image into the different
> disks.
>
> Here's what I am trying:
>
> dd if=/dev/disk1 of=cf-dump.dsk
Effectively copying /dev/disk1 to a file, cf-dump.dsk
> dd if=cf-dump.dsk of=os9disk1.dsk count=315 (315 512-byte block will
> yield a 160K disk)
Did it? S/b decimal 161280 bytes, $27600 hex.
> os9 dir os9disk1.dsk (success! I can see a os9 directory);
But this only cares about that which is in the file structure. The file
itself, if there wasn't much on the disk, could be as short as 3 or so
kilobytes and still return valid dir -e information.
> dd if=cf-dump.dsk of=os9disk2.dsk skip=315 count=315 (skip 315 blocks,
> save the next 315... in theory would get os9disk2)
> os9 dir os9disk2.dsk (hangs...)
I suspect that somewhere, in the generation of these disk images, unused
space was skipped. so the second image is quite likely missing its LSN0 as
it was appended to the first image in order to fill out the 161280 bytes.
> What am I missing?
Look at the first file with dEd. Get the occupied size from the FAT, then
search to that area. Or just search to sector 275 (hex value here), which
s/b the end of that image if its all there (subject to an off by error in
my thinking). If that sector is filled with e5e5e5's or a similar pattern,
and the + key redisplays that or 276, again with the same byte value from
the formatter, then I am likely wrong. If the data looks scrambled, or is
readable text, start tapping the - key until you find the second disks
LSN0. Use that for the skip value for disk2.dsk's extraction.
Not knowing how the cf image was created, you may have to do it that way
for all disks in the cf image.
Here on linux, I would make the original copy like you did, then fire up a
hex editor like okteta on that file and use it to search for the disk
demarcations in one window, and dd to extract from the cf itself, the
individual disk images themselves. By searching a copy, but pulling from
the original, access and file locks won't get in the way.
The above wouldn't be correct if the cf creator just started the cf at the
disk0 address of an os9/HDBDOS partition, used dd, and just copied the 256
disk0-disk255 area of a hard drive. It also highly unusual if all 256
rsdos 'disks' were actually backups of an os9 diskette, leading to the 'os9
dir' returning lots of garbage from what it thinks is os9 file structured
disk images. I might have, out of those 256 disk images, 10 that might be
formatted as os9 images, even less as rsdos images as I've not played with
rsdos enough to actually claim I have used them.
Please report what you found as I'd sure there will be others who would
like to know how it actually is done.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
Furious activity is no substitute for understanding.
-- H.H. Williams
More information about the Coco
mailing list