Path: utzoo!attcan!uunet!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga Subject: Re: 2090 HDdisk.device Message-ID: <4158@cbmvax.UUCP> Date: 30 Jun 88 17:46:54 GMT References: <8806280524.AA12822@jade.berkeley.edu> <2320@antique.UUCP> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 45 In article <2320@antique.UUCP> vax135!cjp (Charles Poirier) writes: >I have the new hddisk.device, version 34.4, and I'm still whining. >Oh, I suppose it works better than before - before, it just gave >a R/W error requester. Now, it gets a good 1 kilobyte per second >throughput. In other words, almost, but not quite, nothing at all. >This with NO overscan, 640 wide, four-plane screen, A2090, Quantum Q280 >28ms SCSI drive, Rev. 4.2 motherboard, no FFS. OK, here goes. The thing that is really killing you is that 4-plane screen. With no real fast mem ($c00000 mem is as slow as chip), your driver only can get 1/3 as many cycles as normal (avg), much less when the beam is on-screen. Combined with the CPU not being able to grant DMA requests until the end of each line, and it really slows down transfers. If you haven't noticed, even floppies get a lot slower with such a screen up, even though their driver is in ROM (therefor fast), and they have dedicated DMA slots (i.e. don't have to wait for bus grant). The last thing that is happening is that we're not talking just a Read() request, we're probably talking an EA IFF reader, which isn't blazing itself. One thing the EA code is not known for is speed (especially at bitmaps - since they're stored in pixel form, not bitmap form, and have to be decoded on a pixel by pixel basis). It may be annoying, but there are two easy (though maybe a bit annoying) solutions: drag the screen down while loading things, or hit the screen-to-back gadget. (Or you could buy real fast memory, but that's a bit expensive right now). At least you don't get R/W errors any more. >(I'm no expert, but, 64 *bytes* of FIFO on the 2090?? Wouldn't 512 as >a minimum, make more sense? Could that FIFO chip be just popped out >and replaced by a bigger one?) I'd guess (being a software guy) that would be a MAJOR redesign, plus having to design a new FIFO chip (I believe it's a custom chip designed by MOS (which is part of C=)). The FIFO may also be part of a larger custom chip, I dunno. >Commodore! Yoo-hoo, Commodore! What do I do NOW? Help! Please don't yell. Remember, we do this unofficially, this is NOT C= Tech support speaking. I'm glad to help when I can, but please don't expect an answer automatically. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup