[Coco] SuperIDE backup/restore
Greg Law
glaw at live.com
Sun Aug 11 22:19:02 EDT 2013
I wonder is this might be possible timing issue because you'll see $00 at
the end of each block filling in the gaps that were missed in the middle of
the block.
If you look closer you'll that while FF FF is dropped at offset 12A8, 00 00
is inserted to make up for the two missing bytes at offset 12FE. I see the
same scenario in which 3F FF is dropped at 482E and 00 00 is inserted at
48FE.
The data in the 4A00 block has a lot more data missing, but follows the same
pattern with about fourteen 00's filling in the missing data at the end of
the block.
-----Original Message-----
From: Gustavo Ranaur Schoenaker
Sent: Sunday, August 11, 2013 8:01 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] SuperIDE backup/restore
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?
More information about the Coco
mailing list