[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Disk ][ Drives not working
In article <pan.2004.07.01.09.07.07.214677@alirossdotco.uk>,
Alistair J Ross <mailat@alirossdotco.uk> wrote:
> Hey,
>
> Well, I tried a CALL-151 and looked thru addressess 0800-08FF and the
> vast majority was as you said - FF's and 00s in sequential order.
>
> However, on the first attempt at doing this the following was evident:
>
> 0840 CD FF 00 00 FF FF 00
> 0850 EF FF 00 00 FF FF 00
> 0870 FB FF 00 00 FF FF 00
>
> And on the second attempt, the values changed:
>
> 0830 FD FF 00 00 FF FF 00
> 0840 FD FF 00 00 FF FF 00
>
> Does this mean that it was able to read six bytes from the disk on the
> first try, and four bytes from the disk on the next try?
Nope... Part of the power-up tests involve writing values into RAM on
16-byte boundaries - No telling what the value is going to be (at least
as far as I know. The testing is where the "FF FF 00 00" pattern comes
from, otherwise, it'd be all zeros or random garbage. Disks are
read/written a sector at a time, and it's an "all or nothing"
proposition - Either the sector is read completely (and then
de-nybblized, and then moved to where it's supposed to land) or nothing
is read at all.
What you're showing there looks like a classic example of what I'd
expect to find in memory on a freshly powered up "driveless" machine -
Namely, nothing whatsoever. For a "warm-started" machine (three-finger
salute) the pattern is going to be pretty much random, and depend
entirely on what all has been done with the machine since power-up, with
a sprinkling of "poison" bytes scattered through RAM (Usually starting
with byte 00 of page 00, and shifting one byte to the right for each
successive page as the page count goes up - That was Apple's single
biggest concession to the demands of the copy-protection crowd - Prior
to the II+, a three-finger salute, immediately followed by a
control-reset would leave all of RAM exactly as it was, with only a few
well-known memory regions (Most notably, zero page, some vectors in th
first half of the $0300-$03FF range, and $0800-$08FF) places getting
stepped on. This meant that someone with the right knowledge could
defeat a copy-protection method with nothing more than a couple of
keystrokes, since it was COMPLETELY possible to boot into the protected
software, give a three-finger salute followed by control-reset wihile
the disk-=recalibrate was still happening, then go into the monitor and
move the "at risk" pages out of the way, boot a normal DOS, move the
previously moved sections back to where they belonged, and BSAVE the
entire protected program to an unprotected disk. On either the II+ or
the IIe (I'm not sure where the "boundary" was) code was added to the
ROMs to deliberately stomp a byte on each page of RAM, in order to
prevent bypassing copy-protection this way.
All of this tells me that if the disk has any data on it, that data is
never reaching RAM. Now it's a question of isolating WHY - Is the disk
good, and does it actually contain data? (Not that there's any way I
know of to tell wihtout a "known good" machine and drive to test with,
and even less way to test from where I sit)
Is it the drive failing to transfer the data from the disk to RAM?
Is it the controller card not having the right ROMs aboard? <shrug> A
great big "Idunno" to all of those possibilities.
Your next move is to figure out why. As Bill Garber mentioned, one
possibility is that the disks are 16 sector, while the drives (Or more
properly, as explained by Paul, the controller card(s)) are 13 sector.
Other possibilities include drive/controller malfunction, or the disk
being unreadable for some reason (Most probably, not written or the
format got blown somehow)
--
Don Bruder - dakidd@sonic.net - New Email policy in effect as of Feb. 21, 2004.
I respond to Email as quick as humanly possible. If you Email me and get no
response, see <http://www.sonic.net/~dakidd/main/contact.html> Short
form: I'm trashing EVERYTHING that doesn't contain a password in the subject.