13 Oct
2016
13 Oct
'16
3:39 a.m.
Hi Eric,
First off, thanks for attempting this. I spent last night trying to
recreate a disk using the CP/M-86 streams I had posted with the Kryoflux
and failed. I'm going to play with it a little until I can get a working
reproduction so I would not rely on those Kryoflux streams just yet. I am
guessing the only way I can reproduce a disk is through the Kryoflux
streams written back to a disk but I can't seem to do that.
I noticed that Discferret had a wiki page on the Victor 9000 format. It
looks like it handled the format but it looks like it is a dead project and
I'm guessing you can't get Discferret boards anymore. I was thinking of
trying some of the Commodore GCR formats to see if that might do it (being
that it is theoretically close except for the vartiable speed track part)
but it looks like you can't write back IMG files that it creates.
I'll have to do some playing around first but once I figure it out, I'll
let you know. Since this is the very first disk I am trying on the
Kryoflux, I'll pick something easy and try to reproduce the disk.
Santo
On Wed, Oct 12, 2016 at 6:06 AM, Eric Smith <spacewar at gmail.com> wrote:
On Mon, Oct 10, 2016 at 6:42 PM, Fred Cisin <cisin
at xenosoft.com> wrote:
What Eric is working on is software that can
decode disk formats that are
NOT necessarily WD/NEC FDC compatible! And writing a file similar to the
one created by IMD.
That will most certainly NOT then be convertible by IMD into a Victor
9000
disk!
That's a good explanation. I was thinking of it as non-standard use
of IMD format; the resulting IMD file would contain the logical
contents of the Victor 9000 disk, but because the IMD format doesn't
(yet) have suitable definitions for Victor 9000 format, the file would
purport to contain IBM-compatible MFM sectors.
I don't really have any plan for a way to convert these Victor 9000
pseudo-IMD files back into actual diskettes. I could write an
imdtoflux program as a counterpart to the fluxtoimd program, which
would help with a portion of the problem.
However, OTHER software, that understands the
file systems could then
extract files. For example, if it is successful, then it might be
possible
to take the Victor9000 IMD file produced by
fluxtoimd, run it through
IMD to
write that content onto a disk in a WD/NEC
compatible format with
similarities of parameters other than encoding (eg. Chromemco?), and then
read files from that disk using XenoCopy or equivalent.
I'm not sure how flexible XenoCopy is, but Victor 9000 format used
Zoned CAV, so tracks have varying numbers of sectors, from 11 to 19.
The pseudo-IMD file will preserve that organization. If the IMDU
program doesn't get upset by the variable number of sectors per track,
it might be able to extract the sector data into a raw binary
filesystem image. Assuming that MS-DOS on the Victor 9000 uses the
obvious mapping of FAT cluster numbers to track/head/sector, the
resulting raw binary filesystem image might be usable with existing
utilities for FAT filesystems, such as mtools.
There's always been such a bewildering variety of mappings of CP/M
blocks to track/head/sector that I wouldn't put any money on the same
conversion working for Victor 9000 CP/M-86 disks.
In both cases (MS-DOS and CP/M-86), if it proves necessary I'll whip
up another simple utility to convert the pseudo-IMD file into a usable
raw binary filesystem image.