[Coco] SuperIDE backup/restore

[Gustavo Ranaur Schoenaker]

I just did the test you asked. Worked great on the "good" card. ?VF errors
every time on the bad card (tried 10 times to different drives).

Well ... I'm on this just for stubbornness (and the pleasure of CoCo
hacking :-)) ... the good cards are very reliable on SuperIDE. I'm having a
lot of fun with them.

If you have Ed's "bad" card, I ask you to try to make a disk 2 serial dump
to see the error by yourself. It may shine a light on the root cause.

Any other test?

On Mon, Aug 12, 2013 at 4:07 PM, Mark Marlette <mmarlette at frontiernet.net>wrote:

> Gustavo,
>
> No special program needed.
>
> VERIFYON:BACKUP X TO Y
>
>
> Any error will confirm that there is a hardware issue.
>
> As I have no reason to doubt your programming abilities....This test uses
> no program and uses established calls to verify.
>
> The sIDE doeshave 16 bit wide databus.
>
> Use a for next loop and copy disk #4 to 6-254
>
> Please let us know your results.
>
> Thanks,
>
> Mark
>
>
> ________________________________
>  From: Gustavo Ranaur Schoenaker <ranaur at ranaur.net>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Monday, August 12, 2013 1:34 PM
> Subject: Re: [Coco] SuperIDE backup/restore
>
>
> Ed,
>
> Can you replicate the test I made with your cards? Just transfer a disk
> from both cards (the original and the copy) and compare the result. If you
> find the same pattern of erros, at least we are on the same boat.
>
> Timing problems can be a good theory. Maybe some cards send data to the
> controller with different timings and SuperIde can't handle all of them in
> a reliable form. If this is true, is something useful to know. It won't be
> a bug, it will be a documented feature. :)
>
> Any ideas on how to test it? I may try to write disks with specific
> patterns to see which of them cause errors ...
>
> On thing is certain, the bytes are "swallowed" in pairs. And after
> swalloing a pair, it doesn't swallows the next pair of bytes. I never found
> a 4 byte swallow, but it may be just coincidence.
> I know nothing about the IDE/CF standard. The data bus width is 16 bits?
> (could be ... they have 40 pins ...)
>
> BTW, my image copy from good cards (I have 3 good cards!) works flawlessy.
>
> After my vacations I'll take a look on HDB-DOS source.
>
> On Mon, Aug 12, 2013 at 7:53 AM, Mark Marlette <mmarlette at frontiernet.net
> >wrote:
>
> > Mark
> > I don't recall the mode ATM. 2904 long time ago.
> > I did have Ed runn a test and he expanded on it.
> > Basically. ..VERIFYON DSKINI
> > He did this for all drives incrementing up down sideways, etc. No
> problems
> > detected.
> > The problem in Ed's case is when he uses an external program on CF to
> > image or transfer.
> >
> > My results was that sidewalk was not creating a clone. Aaron gave an
> > explanation but as I recall it acted just like Ed had noted and I
> > observed.  Ed then tried Winhex, which jis what I use and is still having
> > issues.
> >
> > I had Ed's CFs once before, imaged them did hist test that he just
> > described and had no issues here in the lab.
> > He has sent in his color code CFs and his sIDE and I am going to test
> > again when I get some free time towards this next weekend.
> >
> > Regards
> > Mark
> > Sent from Yahoo! Mail on Android
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>