In article , Alistair J Ross 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? 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 Short form: I'm trashing EVERYTHING that doesn't contain a password in the subject.