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.


On Wed, Oct 12, 2016 at 6:06 AM, Eric Smith <space...@gmail.com> wrote:

> On Mon, Oct 10, 2016 at 6:42 PM, Fred Cisin <ci...@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.

Reply via email to