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