Questions on Disk ][ error checking
D Finnigan
As I understand it, checksums are used to verify that the data read from the
disk are valid and error-free. However, would there be a way to skip these
checks? Is there any software that does so?
I ask because I have more than one disk which has some data and programs
which can be read successfully, and some data which cannot. These disks are
not copy-protected. Would it be worth my time to make a disk image of a disk
with only partially good data? Is this even possible?
Also, would there ever be a circumstance where the disk has become damaged
in an area such that the Disk ][ cannot tell whether a bit is 1 or 0 and
thus refuses to read that disk?
rtk
As I recall, DSK2FILE can make images with back sectors/blocks, by
simply ignoring any errors and continuing.
Ron
Toinet
If you have a DOS 3.3 RWTS disk, B942:18 is your friend ;-)
Go to brutal-deluxe.fr / Products / Apple II / Disk Copiers, download
the image, use Advanced Demuffin 1.4 which does the job of copying
disk even with read errors (ensure that addres B942 is correctly set
to 18)
Or use Ron's technique...
antoine
sicklittlemonkey
> As I understand it, checksums are used to verify that the data read from the
> disk are valid and error-free.
> Also, would there ever be a circumstance where the disk has become damaged
> in an area such that the Disk ][ cannot tell whether a bit is 1 or 0 and
> thus refuses to read that disk?
Just FYI, I once saw these facts combine in interesting way. There was
an error on a particular sector, and with a sector editor that ignores
errors (perhaps the CIA Files) I could read that sector and the data
would change with every read.
There was obviously a bit flip or slip, and the error propagated into
the following data. In this case I could just read the sector until I
saw good data and then wrote it back to disk. No problems after that.
Of course, this kind of manual correction is only practical if (1)
there aren't too many errors, and (2) you can easily tell if the
sector data is good or bad.
Cheers,
Nick.
Zardo Zapp
>I have a question about the error-checking mechanism used on the Disk ][.
>
>As I understand it, checksums are used to verify that the data read from the
>disk are valid and error-free. However, would there be a way to skip these
>checks? Is there any software that does so?
>
>I ask because I have more than one disk which has some data and programs
>which can be read successfully, and some data which cannot. These disks are
>not copy-protected. Would it be worth my time to make a disk image of a disk
>with only partially good data? Is this even possible?
I worked with Sheppy a while back to get a version of ImageMaker that
can do this. It worked well for me.
Yes, it's worthwhile. The corruption may not be on an area of the disk
you care about, and so you can salvage the rest.
What would be nice, though, is to get a list of the damaged sectors so
you know where the trouble may be. So far, I don't have a good way to
do that.
>Also, would there ever be a circumstance where the disk has become damaged
>in an area such that the Disk ][ cannot tell whether a bit is 1 or 0 and
>thus refuses to read that disk?
The hardware isn't that sophisticated. It'll read a 1 or a 0 no matter
what - whether that's what supposed to be on the disk is anothe story.
The checksum is only 8 bits, so if the disk is so bad that you get
essentially random data, then on average 1 out of 256 reads the
checksum will still match. In other words, the checksum only does a
fair job of detecting data corruption.
Jerry
Having looked around a bit, I cannot find any ROM images for the Apple
III other than the 4K boot ROM. There are a number of other ROMs used
for combinational logic:
341-0030 III ROM (Timing logic?)
341-0032-00 III ROM - Video Mode Select
341-0035 Apple III Keyboard Controller
341-0042 PROM - Apple III 12v Memory Board (Address Logic Section)
341-0043 PROM - Apple III (Address Logic Section)
341-0044 PROM - Apple III 12V Memory Board (Address Logic Section)
341-0045 PROM - Apple III (I/O Logic Section)
341-0046 PROM - Apple III (Timing Logic Section)
341-0055 PROM - Apple III (Address Logic Section)
341-0056 PROM - Apple III (Address Logic Section)
341-0057-5C PROM - Apple III (Paralell Printer Card)
341-0061 PROM - Apple III 5v Memory Board (Address Logic Section)
341-0062 PROM - Apple III 5v Memory Board 128K (Address Logic Section)
341-0063 PROM - Apple III 5v Memory Board 128/256K (Address
Logic section)
Does anyone have these, or have an Apple III and the tools needed to
dump them?
I have the WAP Apple III DVD and they are not on there either.
--
Jerry awanderin at yahoo dot ca
Steve
Hi Jerrey,
Ive got the PROM's and ROM's, and I just got my vintage ALL-07
programmer up and running so I can read these old devices. I hope to
put them all up at;
http://www.applelogic.org/APPLEASICs.html
If there are a few important devices you need the contents from, I can
organise to read them out and make a start on this job. I have not
tried as yet, so im not sure if the security fuses have been blown or
not.
steve
Michael J. Mahon
> dog...@macgui.com (D Finnigan) wrote:
>
>
>>I have a question about the error-checking mechanism used on the Disk ][.
>>
>>As I understand it, checksums are used to verify that the data read from the
>>disk are valid and error-free. However, would there be a way to skip these
>>checks? Is there any software that does so?
>>
>>I ask because I have more than one disk which has some data and programs
>>which can be read successfully, and some data which cannot. These disks are
>>not copy-protected. Would it be worth my time to make a disk image of a disk
>>with only partially good data? Is this even possible?
>
>
> I worked with Sheppy a while back to get a version of ImageMaker that
> can do this. It worked well for me.
ProSel's volume copy will retry reading a bad sector/block several
times, then ofer the choice to continue re-trying or ignore it (and
write a block of zeroes).
> Yes, it's worthwhile. The corruption may not be on an area of the disk
> you care about, and so you can salvage the rest.
>
> What would be nice, though, is to get a list of the damaged sectors so
> you know where the trouble may be. So far, I don't have a good way to
> do that.
You can use Cpoy II Plus' "disk verify" functiion to get a list of
"bad" sectors, and the "map files" function to find which files they
lie within, if any.
>>Also, would there ever be a circumstance where the disk has become damaged
>>in an area such that the Disk ][ cannot tell whether a bit is 1 or 0 and
>>thus refuses to read that disk?
>
>
> The hardware isn't that sophisticated. It'll read a 1 or a 0 no matter
> what - whether that's what supposed to be on the disk is anothe story.
> The checksum is only 8 bits, so if the disk is so bad that you get
> essentially random data, then on average 1 out of 256 reads the
> checksum will still match. In other words, the checksum only does a
> fair job of detecting data corruption.
But in the more usual case of a few errors, it is quite effective.
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon
"The wastebasket is our most important design
tool--and it's seriously underused."
Jerry
> Hi Jerry,
>
> Ive got the PROM's and ROM's, and I just got my vintage ALL-07
> programmer up and running so I can read these old devices. I hope to
> put them all up at;
>
> http://www.applelogic.org/APPLEASICs.html
>
>
> If there are a few important devices you need the contents from, I can
> organise to read them out and make a start on this job. I have not
> tried as yet, so im not sure if the security fuses have been blown or
> not.
Take your time. I will be grateful to get them when you get around to
reading them out, if possible.
thanks!
mwillegal
the nibblized sector data that has already been through the decode
process. Valid values are from 0 to 0x3f. The upper two bits
are part of the check, but should always be zero. If you look at the
data before packing it into bytes (denibblizing) and you see
either of the high bits set, you know that that particular byte had an
issue.
From there you can determine what was the actual bit pattern that was
read off of the disk.
Sometimes, if the sector was written on a drive with a marginal
rotational speed,
a single missed or picked bit will cause the rest of the sector to be
skewed throwing
the rest of the data for that sector out of whack.
It may be worthwhile to try tweaking the speed of the drive to see if
you can better
recover the data.
Regards,
Mike Willegal
On Nov 12, 12:13 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> Zardo Zapp wrote: