Re: Disk ][ Drives not working

[Alistair J Ross <mailat@alirossdotco.uk>]

Hmm,

    Well, I have two Disk ][ interface cards, one from the Europlus and one
    from an //e. I don't know if either work, as I don't really know how to
    test them. I don't have any reason to doubt them working though.

    Next, I have a number of disks from different sources, the chances of them
    all being faulty is very unlikely.

    Finally, taking a blank DSDD diskette and using a DMP image as previously
    discussed will produce a copy of DOS in memory. I was able to use INIT to
    attempt to save DOS to disk, but unfortunately, the error given was DISK
    I/O error, it simply hits the heads off the top of the disk as with
    recalibration. 

    So, I doubt that both of my controller cards are faulty, looking at the
    drives insides it appears ok, and I would doubt that the machine is 13
    sector, I am using a ][+, not the original ][, so aren't those 16 sector
    machines?

Regards,

Alistair Ross

On Thu, 01 Jul 2004 14:54:28 +0000, Don Bruder wrote:

> 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)

-- 
-- [ Alistair J. Ross ] ----------------------------------------------------
						0x2b2b2b415448300a 	ViM6
	   ,''`.
	  : :' :   "Just one small part of the GNU revolution."
	  `. `'    
	    `-
----------------------------------------[ www.aliross.co.uk / xbolt.net ] --