Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rochester!rutgers!ames!ucbcad!ucbvax!DMZRZU71.BITNET!mat6013 From: mat6013@DMZRZU71.BITNET Newsgroups: comp.sys.apple Subject: IIgs drive problems Message-ID: <8708021254.aa18395@SMOKE.BRL.ARPA> Date: Sun, 2-Aug-87 13:29:51 EDT Article-I.D.: SMOKE.8708021254.aa18395 Posted: Sun Aug 2 13:29:51 1987 Date-Received: Sun, 2-Aug-87 21:49:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 47 Working with my Apple IIgs equipped with 512K bytes of RAM and two Apple 3.5 drives I recently encountered some problems regarding the smart port daisy chain and the RAM5 volume. - The volume directory of RAM5 doesn't get created if the min size of the RAM disk in the control panel is set to zero. You have to format it before use. Maybe this is a "feature", but I couldn't find something about this in the documentation. - When formatting RAM5 with Apple's filer a directory is created saying it has a size of 800K (it was installed with a max size of 256K). This doesn't occur using Mouse Desk V2.0 . - When formatting S2,D1 or copying S5,D1 to S2,D1 or vice versa (both denoting one of the 3.5 drives) S2,D1 is treated as having a random number of blocks of about 40,000 (20M bytes); the command therefor fails. It seems to be that the program tries to determine the number of blocks by directly reading the 16 bit value at $0/C2FD but there is no ROM. Again, no problem with Mouse Desk. Works also correct if you remove RAM5 (set max size to zero and cold start the machine). - This is the most anoying one (applies also to the //c): The internal boot stage 0 ROM for the 5 1/4 drives (starting at $0/C600) has a timeout feature to detect bad disks, empty drive, open door etc. But the counters are *not* reset for every sector requested to read, but just once at the beginning. This causes problems if not only T/S 0/0 should be read, but several in sequence noted by the first byte in T/S 0/0. If this number exceeds a limit somewhere between 5 and 9 (not exactly tested) the controller will abort the boot process because of the long time to access the sectors in ascending order by physical sector numbers. This can simply be shown with a sector editor and -for example- a bootable DOS 3.3 disk. There are two possibilities for an instant fix: 1) - Copy the ROM from a disk ][ controller using DOS 3.3: BSAVE BOOT gs,A$C600,L$FB - Load it to boot a critical disk: BLOAD BOOT gs,A$8600 - Insert your disk and boot: CALL 8*4096+6*256 (works only if the multi sector read occurs for loading boot stage 1) 2) Reskew track 0 (or any other causing the problem) from a 1- to a 2-ascending sheme (physical sector numbers) or 2 4-descending logical A noteable sideeffect is a significant speedup of the boot process. Matthias Kapffer