Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!amdahl!pacbell!att!whuts!homxb!antique!cjp
From: cjp@antique.UUCP (Charles Poirier)
Newsgroups: comp.sys.amiga
Subject: Re: 2090 HDdisk.device
Summary: FastMemFirst helps!
Message-ID: <2323@antique.UUCP>
Date: 1 Jul 88 05:19:37 GMT
References: <8806280524.AA12822@jade.berkeley.edu> <2320@antique.UUCP> <4158@cbmvax.UUCP>
Reply-To: vax135!cjp (Charles Poirier)
Organization: AT&T Bell Labs, Holmdel, NJ
Lines: 64

In article <4158@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>In article <2320@antique.UUCP> vax135!cjp (Charles Poirier) whines:
>>I have the new hddisk.device, version 34.4, and I'm still whining.
>
>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),

Actually I do have 2meg of fast mem, but I had not been using FastMemFirst
so as to allow my VD0: to recover.  Having just replaced VD0: with VDK:,
and then turning on FastMemFirst, voila, my hard disk works fine!

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

We-l-ll, I don't see how you would get bus contention on the file
access due to the same process that is making the file request.  It's
either waiting for the next Read() to complete, OR it's processing the
last one.  Though in the case of Deluxe Paint, known to indulge in busy
waiting in at least some circumstances, they may have found a way.

Actually, for me it was failing not just for IFF but for any file
access.  For example, in a comm program called ACO which has the
villainous 4-plane screen, it would open that screen and then be unable
to read its phone listing file.

>>(I'm no expert, but, 64 *bytes* of FIFO on the 2090??
>>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'm also a software guy -- the reason I asked is, theoretically the
software interface to a FIFO doesn't know how big the FIFO is (as long
as it is at least a minimum size to make the system work).  You have
only the front, the back, and full and empty signals.  Since the FIFO
is overflowing, I thought making it bigger might be a painless
solution.  Though quite possibly that wouldn't solve the real problem.
I dunno, I was just trying to help.

>>Commodore!  Yoo-hoo, Commodore!  What do I do NOW?  Help!

>	Please don't yell.
>Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup

Sorry, I feel better now.  I did call some sort of customer support
number at Commodore once.  But between having to wait 30 minutes on the
phone to speak to someone, and their being a relatively nontechnical
phone jockey when I did get through, whose help consisted of relaying
my problem to someone else and bringing back the advice that I should
get hold of the hddisk.device that I was already using, I didn't feel
that was a viable alternative.  I just felt like my machine was
treating me unfairly and I didn't know where else to turn.  Everything
I could think of about my setup was identical to that of people whose
SCSI drives worked fine.  I did forget about FastMemFirst though.

Thank you Randell, DaveH, Andy, and all others who helped me through this.

-- 
	Charles Poirier   (decvax,ucbvax,mcnc,attmail)!vax135!cjp

   "Docking complete...       Docking complete...       Docking complete..."