[Coco] Copying over an IO ERROR

[John Riddle]

That's actually an interesting sounding project.  I think the best approach
would be to parse the saved track data on something other than the Coco
itself.  Basically the Coco would be used just to read the track and write
out the data into separate files.  These files would then be xfered to
another environment via the CocoSDC or similar methods.  Then have another
program do the heavy lifting.  Wouldn't be too difficult to write up a
program in Perl to parse through it.  But for something of any
sophistication beyond just simple parsing, I've found that C++ or Java are
better for manipulating raw binary data.  If the track image were
well-formed, I could make it just key off of the data that appears before
each sector, like the side#, sector#, sector size, etc, to locate the
sector data in the image.  Could also put in some error-handling to make it
a bit more flexible to deal with any tracks that aren't well formed.
This reminds me of a program I wrote a few years called "RBSM" or RS-DOS
Binary segment manipulator, which I wrote in Java for the command line..
basically what it does is look at the RS-DOS .BIN file and display all of
the load addresses and allow changing around of a lot of that information
in the binary - I'll see if I can dig up the source.

Only disadvantage to this approach is that if it is graphics data that is
stored on the disk, the Coco would have the advantage of easily being able
to display the memory in various different graphics modes.  But I suppose
that could be simulated in some way with a gfx library in C++ or Java.

I remember the Diecom games I bought always had about a 25% load failure
rate.  Years later I traced it to the read track it does for track0.  Each
Diecom game had 1024 byes of executable code as part of the game loader on
track 0.  FWIW the only other software I ever knew to use the read-track
command (outside of Spit-N-Image)  was the later Sundog games.  The ones
that were licensed did a simple check of three bytes on track 0; the ones
that Glen D himself wrote had gfx data stored on it (in the case of
Kyum-Gai, it was the ninja player - consisting maybe about 100 bytes of
so).  Never had a mis-read on that.

I think in the case of Spit-N-Image, I think the goal of the read-track was
to try to glean information about the format of the disk, which it would
then use to format the target track - then it would just read and write
sectors as usual.
John

On Tue, Feb 3, 2015 at 10:34 PM, Arthur Flexser <flexser at fiu.edu> wrote:

> I wonder if anyone has ever written a read-track based CoCo disk zapper for
> recovering damaged data.  I would envision something that would read the
> desired track and use some smart algorithms to try to intelligently guess
> where the sector boundaries lie, allowing the user to modify these in some
> user-friendly fashion (e.g., using the arrow keys to adjust the boundaries
> of a 256-byte region and edit bytes within there) and save a copy of the
> modified sector.
> (I seem to remember hearing, from an author of Spit N Image, that the read
> track command is a little twitchy, so that you don't always get exactly the
> same result if you use it twice in a row.)
>
> One problem is that you can't just do a read track, modify a bit of data,
> and save it back out with a write track.  There are a few byte values that
> the write track command uses for things like "generate a CRC here" that
> mess you up if you happen to have one of these bytes in the data that the
> disk contains.  So saving would have to be by means of sector, not track,
> writes.
>
> Art
>
>
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>