Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cbmvax!andy From: andy@cbmvax.UUCP (Andy Finkel) Newsgroups: comp.sys.amiga Subject: Re: Early experience with 2090A controller Keywords: sure doesn't smell like a rose Message-ID: <4986@cbmvax.UUCP> Date: 13 Oct 88 17:28:45 GMT References: Reply-To: andy@cbmvax.UUCP (Andy Finkel) Organization: Commodore Technology, West Chester, PA Lines: 105 In article kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: >> There are a number of things you have to do before you can get Prep >> to work which are not mentioned in the documentation. If you >> don't do them the system will either crash, hang, or make your disk >> assume unnatural positions. >> >> 1. Don't run interlaced Workbench. Huh ? This doesn't make sense. Interlace Workbench works fine with Prep. Maybe he means *overscan* Workbench. >> 2. Make sure your Workbench has enough room on it for the driver, >> its icon, the mountlist, and Prep. Yes. The Installation script actually has a little program that checks for sufficient room, and, assuming a fairly 'virgin' Workbench 1.2 disk, knows about things it can delete after asking you (like the demos) >> 3. Turn off C00000 memory using nofastmem. (This one I couldn't >> believe. I should expect Commodore software to work on a stock >> Amiga 2000). DON'T DO FASTMEMFIRST! Hmm, it seems to work fine with C00000 memory. FastMemFirst is something you are supposed to do. Since C00000 memory is slower than real Fast memory you want your buffers and drivers in the best memory you have. >> 4. Check your mountlist entry carefully. The one generated by the >> Install program doesn't seem to work. In particular, the >> "Reserved" field should have a value of 2. Also, verify that the >> number of heads and blocks per track for your disk is correct. A common misunderstanding. The reserved field only matters for an AmigaDOS partition. Since you aren't going to use the RES0: or RES2: partition for AmigaDOS, 0 works, 2 works, 5 works, etc. Aside from that, yes if your drive has a configuration other than 4 surfaces, 17 blocks per track, you should check the mountlist created for you. >> 5. If all else fails, try using the original Workbench disk (the >> one that came with the machine). Especially if you've deleted commands and libraries. --- Possibly, he has out of date software ? Find out the version numbers of his hddisk.device, prep, and disk, if you can. (look in the t directory) There was an older version where the Install script didn't create the mountlist correctly. Since I happened to be setting up a new hard disk system, I just ran through the sequence and prep'd a drive. BTW, while it works, we're still not completely happy with the Prep software, and the driver, and are/have been working on another update. I'll keep you informed when its ready; and I'll use the same distribution methods. (ie dealers, usenet, etc) >> After I got it to work, Prep took only about 1-2 seconds to initialize >> the disk. Format was another 25 minutes or so (for 40 megs). Though 1.3 has a new 'QUICK' option (just write the reserved blocks, the root block, and the bitmap blocks, I usually run a full format the first time I bring up a drive, just so I know I can write to each track. >> Does anyone know if the fast file system is implemented at the device >> driver level or at the DOS level? The disk access is much faster than >> I expected so I'm wondering if I already have it. FastFileSystem is implemented at the AmigaDOS level. You don't have it unless you have 1.3. It should speed you up substantially. >> The controller board came with two ROMs to be installed with >> Kickstart 1.3 to add autobooting. The documentation said that >> Seagate SCSI drives cannot autoboot because of the long latency >> in initialization. Well, the new driver should handle this. (no, I don't know how I can email eproms :-) ) >> After only 2 days of operation, my new Seagate disk started getting >> massive numbers of r/w errors. DOS couldn't even validate it, and the >> whole thing became corrupted. >> >> The problem was not the disk, but the 2090A controller. It seems that >> the board has thermal problems, and if I plug it in next to my ASDG Hmmm. Time to visit the dealer, perhaps ? >very cool. Perhaps Dave's 2090A has a marginal component. If so, it >would seem that CBM's Manufacturing QA procedures should have caught it. >There *is* a burn-in cycle, isn't there? Yup, there is a burn in cycle. But since I'm not a system test engineer, I'll leave it to them to comment. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "People who post news as root probably have other bad habits, too." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.