[Coco] SuperIDE backup/restore
Arthur Flexser
flexser at fiu.edu
Sun Aug 11 21:12:44 EDT 2013
This probably has nothing to do with the problem you're encountering,
but....
the error pattern DOES seem reminiscent of something I ran into years ago.
I attempted to write a fast floppy disk copy utility that did the
formatting and data copy both at once--that is, one that filled in the
sector data to the Write Track buffer that gets written to the disk a track
at a time when formatting, replacing 256 $FF bytes that normally get
written to each sector during formatting with the sector's data contents.
This plausible time-saving scheme turned out to be a nonstarter for the
following reason:
The disk controller chip considers a couple of bytes in the $Fx range as
special codes when executing a Write Track command. (One is for generating
a CRC that is normally written as part of the sector metadata, replacing
the "special" byte; I forget what the other, or others, do.)
So, all the sectors were copied okay except for those that contained data
with certain $Fx bytes. Sound familiar?
Art
P.S. You're welcome for the cabalistic pokes. They involve the only
instance I've ever seen where the CoCo makes use of the PIA's data
direction register.
On Sun, Aug 11, 2013 at 8:01 PM, Gustavo Ranaur Schoenaker <
ranaur at ranaur.net> wrote:
> Hi Guys,
>
> Yes, I have news. Good and bad. The good news is that I could isolate what
> is happening, getting much more information. The bad news is that, it's not
> a simple bug, like something wrong I was making with the offset. As Dr.
> House would say, it's not Lupus! It's never Lupus. :-)
>
> But at least its a shine of light on this mystery. And CoCo hacking counts
> twice of the fun. :-)
>
> It's a long e-mail, so, take your time if you're interested in SuperIDE
> mysteries. :-)
>
> This is what I did ...
>
> 1) I formatted a the card, wrote a .DSK file on it using sidewalk (my test
> data was a disk with mark Data production adventures).
> 2) I used the program do dump each sector of the disk to the bitbanger port
> and captured the serial output to a file.
> 3) I compared the result with the original DSK file.
>
> I did this with two cards: a "good" one and a "bad" one.
> The comparison of the result from the good card was exactly the save (using
> DIFF), while the result from the bad card showed some differences.
> Analyzing the differences (see below the e-mail) I noticed that the bad
> card skips some 2-bytes words sometimes. I noticed that the missing bytes
> are specially when it has a lot of 1's (FF FF, FF FC, 3F FF etc.), but I
> couldn't find a reliable pattern.
>
> Well, my educated guess is a bug in HDB-DOS superide driver. Well, it is
> just an educated guess because:
>
> 1) The problem is not in the card itself. I formatted it on DOS, Windows,
> and MacOS, copied hundreds on 1MB random files and the checksum was ok. So
> the card *is* saving the data correctly.
> 2) The problem is not a hardware fault on my SuperIDE. It works really well
> with the good card.
> 3) As an additional thought, it doesn't makes I/O error when I LOADM the
> programs on the bad disk. The program loads and EXECs. It gets on the first
> screen more or less with some garbage, but it has some resemblance with the
> original game. (the screen gets corrupted in some parts).
> 4) The error is not random. Every time I read it, I get the same (wrong)
> result. Better. Is misses the very same bytes.
> 5) If it was something wrong coming from SuperIDE, the checksum wouldn't
> match and I would get an ?I/O ERROR. So the problem should be after the
> checksum!
>
> Is there an HDB-DOS Unraveled anywhere? I would like to take a look ... :-)
>
> The second possibility is some mega quantum interference somewhere in the
> circuit. Hope this doesn't prove to be right.
>
> Now to the details ... all the files I've used can be found at:
> https://dl.dropboxusercontent.com/u/8896949/sidetest.zip
>
> - SIDETEST.DSK -> a disk with some basic programs to test, including the
> disk 2 serial dumper (SIDEOUT2.BAS)
> - BASELINE.DSK -> the .DSK I used as reference for the tests (GAMES
> 21.DSK)
> - GOOD.DSK -> the output from the good card
> - BAD.DSK -> the output from the bad card
> - *.hxd files -> hexdump of the files
> - differences.txt -> the output from the diff -y command
> - differences-only.txt -> only the lines that mismatched (grep '|'
> differences.txt)
>
>
> To do this I wrote a CoCo program to send a disk sector by sector through
> the bitbanger port. Special thanks to Arthur Flexser for the cabalistic
> POKEs that disabled de carrier detect. :-)
>
> 5 POKE150,16 POKE&HFF23,&H30:POKE&HFF22,&HF9:POKE&HFF23,&H34:POKE&HFF22,010
> CLS20 CLEAR 1000
> 30 PRINT"DRIVE NUMBER: ";
> 40 INPUT D
> 50 FOR T=0TO34
> 60 FOR S=1TO18
> 70 DSKI$ D,T,S,Q1$,Q2$
> 80 PRINT at 96,"DRIVE:"+STR$(D)
> 90 PRINT at 128,"TRACK:"+STR$(T)
> 100 PRINT at 196,"SECTOR:"+STR$(S)
> 110 PRINT#-2,Q1$;
> 120 PRINT#-2,Q2$;
> 130 NEXT S
> 140 NEXT T
>
> To try this at home you'll need:
>
> 1) Get a "good" card (that works on superIDE).
> 2) A "bad" card (that doesn`t works if you DD the image of another card on
> it)
> 3) A CoCo Serial cable (a drivewire cable) to connect the CoCo to a PC via
> serial port. Eventually you`ll need an serial to usb dongle, if you
> computer doesn't has a RS-232 port.
> 4) A Linux, Mac os some gnu utils for windows.
> 5) A program to capture the output of the serial port. I used Realterm for
> windows, but your millage may vary (even a cat /dev/tty.* > output.dsk
> should work) .
>
> First, just to be sure, wipe out both cards. Supposing your card is in
> /dev/sdb (check that!) zero it using
> $ dd if=/dev/zero of=/dev/sdb
>
> Then plug each of them in the coco and format the disks.
>
> DSKINI 0
> DSKINI 1
>
> Then use sidewalk (or any other utility) to copy SIDETEST.DSK to disk 0 and
> BASELINE.DSK (or any .DSK you'll use as test) the disk 1.
>
> Load SIDEOUT2.BAS and capture the output from the serial port on the PC.
> Remember to set the baud rate on the PC to 9600! It takes less than 5
> minutes to get the disk.
>
> Make this to both the good card (GOOD.DSK) and the bad card (BAD.DSK).
>
> Diff them ...
>
> $ diff BASELINE.DSK GOOD.DSK
> $ diff BASELINE.DSK BAD.DSK
> Binary files BASELINE.DSK and BAD.DSK differ
>
> Generate the hex dump of each file ... (trust me ... :-))
>
> $ hexdump -ve '"%07.7_ax " 8/1 "%02x " "\n"' BAD.DSK > BAD.DSK.hxd
> $ hexdump -ve '"%07.7_ax " 8/1 "%02x " "\n"' BASELINE.DSK >
> BASELINE.DSK.hxd
>
> Compare the side by side (get a wide terminal!)
>
> # diff -y BASELINE.DSK.hxd BAD.DSK.hxd | less
>
> As examples I noticed that if looses a couple of bytes sometimes,as shown
> on these examples:
>
> 00012a8 ff ff ed 81 31 3e 26 fa | 00012a8 ed
> 81 31 3e 26 fa 4f 5f
> 00012b0 4f 5f fd 22 e1 1c ef 35 | 00012b0 fd
> 22 e1 1c ef 35 b6 34
> 00012b8 b6 34 12 86 3f b7 ff 23 | 00012b8 12
> 86 3f b7 ff 23 86 37
> 00012c0 86 37 b7 ff 21 34 04 f7 | 00012c0 b7
> ff 21 34 04 f7 ff 20
> 00012c8 ff 20 12 12 12 5c 26 f7 | 00012c8 12
> 12 12 5c 26 f7 35 04
> 00012d0 35 04 30 1f 26 ef 86 37 | 00012d0 30
> 1f 26 ef 86 37 b7 ff
> 00012d8 b7 ff 23 35 92 1a 50 34 | 00012d8 23
> 35 92 1a 50 34 36 10
> 00012e0 36 10 9e 1d 30 a9 01 20 | 00012e0 9e
> 1d 30 a9 01 20 ec 81
> 00012e8 ec 81 ed a1 8c 1b a0 2d | 00012e8 ed
> a1 8c 1b a0 2d f7 cc
> 00012f0 f7 cc ff ff ed a1 10 8c | 00012f0 ff
> ff ed a1 10 8c 1b a0
> 00012f8 1b a0 2d f8 cc 14 00 fd | 00012f8 2d
> f8 cc 14 00 fd 00 00
>
> and this
>
> 0004830 3f ff fc 3f 00 00 00 0a | 0004830 fc
> 3f 00 00 00 0a aa a8
> 0004838 aa a8 2a 01 55 00 0f ff | 0004838 2a
> 01 55 00 0f ff ff ff
> 0004840 ff ff 05 54 80 0a aa aa | 0004840 05
> 54 80 0a aa aa aa 05
> ...
> 00048e8 55 48 a0 28 52 28 55 55 | 00048e8 a0
> 28 52 28 55 55 48 aa
> 00048f0 48 aa a8 52 28 55 55 48 | 00048f0 a8
> 52 28 55 55 48 aa a8
> 00048f8 aa a8 52 28 55 55 48 aa | 00048f8 52
> 28 55 55 48 aa 00 00
>
> and this
>
> 0004a18 00 02 ff ff 00 05 00 03 | 0004a18 00
> 02 00 05 00 03 fc aa
> 0004a20 fc aa aa 00 04 00 04 03 | 0004a20 aa
> 00 04 00 04 03 55 3f
> ...
> 0004a88 01 a0 00 05 00 01 fc 00 | 0004a88 00
> 05 00 01 fc 00 05 00
> 0004a90 05 00 01 aa 00 05 00 02 | 0004a90 01
> aa 00 05 00 02 00 04
> 0004a98 ff c0 00 04 00 02 aa a0 | 0004a98 00
> 02 aa a0 00 04 00 02
> 0004aa0 00 04 00 02 ff fc 00 04 | 0004aa0 00
> 04 00 02 aa aa 00 04
> 0004aa8 00 02 aa aa 00 04 00 2a | 0004aa8 00
> 2a c0 00 00 00 aa aa
> 0004ab0 ff ff c0 00 00 00 aa aa | 0004ab0 a0
> 00 00 00 fc 00 00 00
> 0004ab8 a0 00 00 00 ff ff fc 00 | 0004ab8 aa
> aa aa 00 00 00 ff c0
> 0004ac0 00 00 aa aa aa 00 00 00 | 0004ac0 00
> 00 aa aa aa a0 00 00
> 0004ac8 ff ff ff c0 00 00 aa aa | 0004ac8 *ff
> fc 00 00 00 04 aa 02
> 0004ad0 aa a0 00 00 ff ff ff fc | 0004ad0 00
> 00 00 04 ff 02 c0 00
> 0004ad8 00 00 00 04 aa 02 00 00 | 0004ad8 00
> 04 aa 02 a0 00 00 04
> 0004ae0 00 04 ff 02 c0 00 00 04 | 0004ae0 ff
> 02 fc 00 00 05 aa 01
> 0004ae8 aa 02 a0 00 00 04 ff 02 | 0004ae8 00
> 00 05 ff 01 c0 00 05
> 0004af0 fc 00 00 05 aa 01 00 00 | 0004af0 aa
> 01 00 00 00 00 00 00
> 0004af8 05 ff 01 c0 00 05 aa 01 | 0004af8 00
> 00 00 00 00 00 00 00
> 0004b00 a0 ff 46 45 04 18 c0 00 0004b00 a0
> ff 46 45 04 18 c0 00
>
> and
>
> 0004c38 01 05 00 08 f5 ff 01 3d | 0004c38 01
> 05 00 08 01 3d 01 00
> 0004c40 01 00 41 5a 01 50 00 08 | 0004c40 41
> 5a 01 50 00 08 09 35
> 0004c48 5f ff 09 35 02 02 55 55 | 0004c48 02
> 02 55 55 00 10 aa 02
> 0004c50 00 10 aa 02 55 55 00 10 | 0004c50 55
> 55 00 10 aa 02 55 55
> 0004c58 aa 02 55 55 00 10 aa 02 | 0004c58 00
> 10 aa 02 55 55 00 10
> ...
> 0004ce8 11 00 04 55 00 05 00 01 | 0004ce8 00
> 05 00 01 11 00 04 55
> 0004cf0 11 00 04 55 00 05 00 05 | 0004cf0 00
> 05 00 05 11 00 00 00
> 0004cf8 11 00 00 00 01 00 05 00 | 0004cf8 01
> 00 05 00 00 00 00 00
> 0004d00 05 11 00 00 00 01 00 05 0004d00 05
> 11 00 00 00 01 00 05
>
> and many, many other examples.
>
> Any sugestions?
>
>
>
> On Mon, Aug 5, 2013 at 11:49 PM, Ed Orbea <ed.orbea at gmail.com> wrote:
>
> > Gustavo
> > Unfortunately I have no new news.
> > Mark asked me to send him the CF cards and my SuperIDE cartridge
> > I have been away from my Coco3 due to work (not quite ready to retire
> yet)
> > so I was only able to send it out this,owning via 1st class/priority
> > postage.
> >
> > Ed
> >
> > Sent from my iPad
> >
> > --
> > 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
>
More information about the Coco
mailing list