Conference hydra::amiga_v1

    Don't know if this is even related but I had trouble (similar but
    not the same) with my system.  I bought my sytem with 2meg commodore
    board and GVP 40meg hard card.  My system was acting "flakey" for
    the lack of a better term.  By that I mean random "boot failures"
    GURU's for no apparent reason, system "freezes".
    
    I never brought it in for service because I couldn't demonstrate
    a failure.  I decided to do some experiments on my own and found
    that:
   
    My problems went away if I removed either my hard disk or my memory
    option.  Then, thanks to note somewhere in this file regarding a
    proplem with slot positions with a different GVP product I reversed
    the option positions and my system has been working fine ever since.
    (Memory now closed to the CPU, followed by the hard disk)  I don't
    understand what the problem was or why this fixed it and I've been
    negligent in calling the GVP people to try and understand it.
    Point is - "physical slot position has an effect in Amiga 2000's" 
    
    After gaining confidence that my system was now working correctly
    I upgraded to 1.3 and things started to go flakey again.  After
    a lot of frustration and experimentation I found that by taking 
    the "FASTMEM FIRST" out of my startup sequence was the cure. System
    now solid again!  I don't understand why, but it works.  I'd
    try the sam if I were you, anything is possible.
    
    Good Luck,  hope this helps.
    Frank
    

    I did some more playing and here is what happened.
    
    Moved everything from scratch: (used disksalv)
    Typed 'format drive fshd1: name scratch' - system crash
    Removed memory board
    Formats OK!
    Replaced memory board - system crash if i try to format
    Removed memory board (for now)
    
    On my system the 2090A is first and then the memory board, mainly
    because of the cables that go to my external ST506 drives. I will
    try to reverse them. I just called Pro Periph and they don't know any
    reason why it should fail, but he said he would try some tests and
    i'll call back next week. If reversing them fails i'll try the removing
    the FastMemFirst stuff and see. Thanx.
    
     mark
    

    When i am formatting, my screen does a little dance - looks like
    it loses sync with every cylinder move. The monitor is close to
    the drive (about 1 1/2 feet), but is stable for all other head
    movement. Is this normal, or is it an indication that the 2090A
    has a problem and the extra memory causes it to show up?
    
     mark

    I took out FastMemFirst and everything appears to work fine. Formats
    OK and no screen dancing. What does this mean? Does anything require
    that i run FastMemFirst? 
    
     mark

    FastMemFirst is supposed to be a performance improver only---everything
    should still work without it.  However, removing it probably just hides
    the symptom---as soon as you pile enough load onto your system to use
    FastMem, even though it is last, you'll probably get the symptoms
    again.
    
    I have an A2000 with the 2MB expansion and an A2090.  My screen remains
    solid when I format, even though I use FastMemFirst.  Recently I added
    another 2MB and a 68020, but formatting still works fine.
    
    I suspect something in your system is marginal.
        John Sauter

    I'm not that familiar with mountlists but isn't there something
    in the mountlist that says what type of memory to use for buffers?
    You might want to force the harddisk to use chip ram.  Maybe then
    you can use fastmemfirst...
    
    -steve

    bufmemtype  or something like that.
    0 & 1 = any available
    2 & 3 = Chip memory
    4 & 5 = Fast memory
    
    Warning the above was from memory and I have a few bad spots myself.
    It is in the Enhancer manual.
    
    You could try playing playing with this and see what happens.  The way
    I look at it if you use chip memory for your drives the CPU has to
    contend with the custom chips for access, plus there is that much less
    chip memory for sound and graphics.
    
    Here is an idea.  I am not familure with your memory module but if it has
    chips in sockets maybe you can remove some to get to a minnimum
    configuration and test that.  Then swap those for the rest and
    test again.  ***KEEP YOUR SELF GROUNDED TO PREVENT STATIC DAMAGE***
    
    Alan
         
    
    

    I'll have to agree with John in .5. Removing FastMemFirst has only
    masked the problem. I had the drives on an IBM XT and they formatted
    fine. I rebuilt them again with the extra memory removed. I still
    can't get an 'Initialized' message back after formatting. I get
    an 'Initialized' message for my first 100K partition, but not for
    the 10M partition (FFS). I have
    to use the 'quick' option - i still assume that this means it found
    bad sectors. I put the extra memory back in and started copying
    from the floppies to the harddrive. If i did 'copy df0:x hd0:',
    the pgm x would not run. If i did 'copy df0:x ram:' and then 'copy
    ram:x hd0:', the pgm x would run from hd0:. I'm not sure what this
    means... It also crashed when copying multiple files. I guess i'll 
    have to try moving the memory board in front of the 2090A, but 
    i have my doubts. 
    I have 1M on the memory board, but i can reduce it to 512K. I'll
    try it as a last resort. I will also try another 2090A next week.
    I'm open for suggestions.
    
     mark

    Well, a weekend of frustration...
    
    Removed A2300 Genlock - no change
    I reconfigured the board for 512K - no change
    I moved it in front of the 2090A - no change
    I checked +5V (4.92) - OK
    I used the extra 1M with floppies only - no apparent problem
    
    So, it appears to be an interaction between the 2090A and the memory
    board. I'm hoping to try another 2090A this week and rule it out.
    I'll give PP&S a call today to chat about the problem, but i guess 
    it's into the Amiga shop and start trying my memory board on another
    A2000.

     mark

    When I bought my 2000, I also purchased a 2052 2Mb board, all was
    fine.  I then bought a A2090A and a 20Mb drive, this ran fine for
    about 2 months, then the GURU started to appear, at first only using
    DPaintII, but more and more using programs that used large amount
    of memory.  I tried a second hard drive, another HD controller,
    checked everything, reaseated everything.  I started working when
    I removed the extra memory (running "nofastmem" did NOT help). 
    I replaced it with a 2058 board with 2Mb on it and now it's running
    fine all the time.  The kicker is that the dealer is using MY old
    board and he runs fine!  I have a feeling that either the buss drivers
    are not up to the task at hand or some kind of termination is needed.
     
    A friend has a 2000 with no memory expansion and he gets the GURU
    when he tries to run transformer, we have tried all kinds of tests,
    but it appears to be a memory problem.  It would help a lot if there
    was parity on the memory, or GOOD memory tests.
    
    Jean
    

    re .10
    
    Is it true that there is NO parity?  I've heard that but didn't
    want to believe it.  I certianly didn't realize that when I
    bought the machine!
    
    Are there expansion boards available that have memory parity.
    
    Is it common in the PC world to have non-parity memorry?  That's
    absurd but would account for a lot of strange behavior.

    Frank
    

    
    None of the popular 68*** PCs have parity, while IBM's and good clones
    do.
    
    The Starboad II from MicroBotics has a ninth socket for every eight
    chips, used for parity.  They also include some software to recognize
    the parity chip.
    
    Ed.

    As Ed said, parity memory is unusual in the PC world, though you do
    find it in the expensive systems.  There was a time when even IBM
    mainframes didn't have parity memory: the IBM 7090 comes to mind.
    
    Today, all commercial-grade computers have at least parity, and usually
    ECC.  However, if you're looking to build a minimum-cost home computer,
    omitting parity is a wonderful way to reduce costs and increase
    performance.
    
    There was once an argument within Digital that adding parity or ECC to
    a system would _decrease_ its reliability, since the additional
    circuits needed to do the checking might fail.  I don't think anyone
    within DEC takes that argument seriously today.
        John Sauter

    I have heard that CRAY does NOT use parity or ECC, because all these
    add ons slow down his systems, he doesn't even use cache memory
    for the same reasons. 
    
    Jean
    

Re: .14

The story I heard was someone asked Cray why the Cray I didn't use
cache memory.

Cray replied saying that he loved cache memory, and that in fact
all the memory in his machine was cache memory.

    I tried another 2090A last night and it behaved similar (but
    different). This makes me believe that is a marginal timing/signal
    level problem between the 2090A and the memory board. I will try
    my hardware in another A2000 ASAP and see what the results are.
    I am suspecting the memory at this point.
    
     mark

    I called Commodore (Canada) today to explain the problem to them
    and get some ideas. It seems that if you have a 68000 chip manufactured
    by 'Sigmunds' (sp?) you may experience flakey problems with hardware
    add-ons. The fix is to have it replaced with either a Motorola or
    Rockwell version. I will check mine tonight and hopefully have the
    dealer replace it, otherwise, i will try my 2090A and memory in
    a dealers machine to see what happens.
    
     mark
    
    PS (i hope i have a 'Sigmunds' 68000)

    Re .17
    	99.9% sure that "Sigmunds" is really Signetics. 
    
    Miguel A. Alvarez

    My 68000 has a big "S" on it, so i assume it must be the flakey
    one. I called the dealer last night and he doesn't stock 68000's
    and didn't sound like he believed me either. I will talk to him
    this morning and hopefully after he calls CBM i can get this resolved.
    
     mark

    I swapped the Signetics 68000 for a Hitachi and still have the
    same problems. I will have access to another A2000 tomorrow and will
    attempt to isolate the failure. Wish me luck...

     mark

OK - here's how it went...

My buddy came with his A2000 - same rev motherboard 4.4 with a
Signetics 68000 + 20M ST506 + 2M expansion - all working OK

o gave my disks a try with his A2000 + A2058 - OK
o tried my memory expansion - OK
o examined difference between the A2000's
    * found a 3.3k resistor tacked between pins 11-20 of U604
    U604 is a 74LS245 located just left of the CPU expansion connector
    pin 20 is +5, pin 11 is BD08
    so Commodore had installed a pullup on this line for some reason?
o installed resistor
o my machine now works fine!

I am going to call Commodore and have a chat with their technical
staff about this ECO and post the results.

 mark

    re .21
    
    I was talking with Roy at the memory location and he confirmed that
    the U604 pullup described in .21 is in fact, an official ECO for
    A2000's.  It's a buss termination fix that could remedy some of
    the flakeys in this system.
    
    Frank
    

Path: shlump.dec.com!decwrl!ucbvax!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!cbmvax!daveh
From: [email protected] (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Use of SuperState() call
Message-ID: <[email protected]>
Date: 31 May 89 16:57:26 GMT
References: <[email protected]>
Organization: Commodore Technology, West Chester, PA
Lines: 67
 
in article <[email protected]>, [email protected] (Mark Huth) says:
> Keywords: supervisor guru
> 
> While working this weekend on my 2620 system I experienced a lot of
> gurus.  In an attempt to isolate the cause, I wanted to turn of the
> cache.  
 
It's probably nothing to do with the cache; more on that in a bit...
 
> I've tried not tracing through the exec call, but I never get control 
> back from the SuperState call - it's always off to the guru.
 
> Is there a secret that I'm missing?
 
Yup.  For starters, UserState() is broken, at least on 68020/30 machines.
So you can never get back that way.  Here's how I do it in SetCPU:
 
	LVOSupervisor	EQU	-30
 
	;======================================================================
	;
	;	This function sets the value of the 68020/68030 CACR register.  
	;	It assumes a 68020 or 68030 based system.
	;
	;	void SetCACR(cacr)
	;	ULONG cacr;
	;
	;======================================================================
 
	_SetCACR:
		move.l	4(sp),d0		; New CACR is on stack
	 	move.l	4,a6			; Get ExecBase
		btst.b	#AFB_68020,ATNFLGS(a6)	; Does the OS think an '020 is here?
		bne	1$
		rts				; No CACR here, pal
	1$
		move.l	a5,-(sp)		; Save this register
		lea	2$,a5			; Get the start of the supervisor code
		CALLSYS	Supervisor
		move.l	(sp)+,a5		; Give it back
		rts
	2$
		movec	d0,cacr			; Set the CACR
		rte
 
Note that the Supervisor function isn't often mentioned.  I figure the main 
reason for that is that, as it's exited via RTE instead of RTS, it can't be
called directly from C.  In any case, this method will work on your A2620.
 
If you installed your A2620 yourself, and you're using a DMA driven hard
drive, you may have a known problem.  A2000s built with a 74ALS245 bus driver
chip made by Signetics at the U605 position can run into trouble with DMA
and an A2620 or possibly any other fast Coprocessor card that supports DMA
into it's fast memory.  The problem is that with the Signetics part, a
critical expansion bus signal doesn't get pulled up fast enough at the end
of a DMA transfer.  Changing the buffer chip would of course fix the problem,
but the suggested fix (dealers are supposed to know this) is to add a 3.3k
pullup resistor to the signal in question.  This resistor goes between pin
20 and pin 11 of U605.  The Signetics part can be identified by a big "S"
on it; no other manufacturer's part has shown any signs of this problem.
 
> Thank You,
> Mark Huth
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession
    
    
     mark

In the previous note Dave Haynie says U605 (which is correct),
while i had said U604 (which is wrong). I guess i can't read
silkscreening properly (i think i must have read the capicitor
#). Sorry for any inconvenience.

 mark

    BTW, pins 11 and 20 are at the corners of the right side of the
    chip as you look at it from the front of the 2000. It is located
    to the left of the coprocessor slot. It is an easy solder job as
    long as you are careful not to glop the solder all over the adjacent
    pins (12 and 19).
    
    Paul

        A friend's 2000HD is showing the exact same symptoms as those in
        the base note.  In his case he had just added a Supra 2000
        2/4/6/8 card with 2 meg on board. The only problem, is that when
        I popped the top off we found the the 3.3K resistor was already
        there and they had switched to Mitsubushi(sp?) 74ALS245's for
        the bus drivers at positions U602 and U605.  The CPU is the
        Signetics 68000.  Without scoping the line, any suggestions? 
        Try replacing the 3.3k with a slightly smaller value (keeping in
        mind they already have a 10k pullup on the line).  The Supra
        people were ready to hand out a RA number, but I don't think
        it's the memory, it passed all diags, and the system runs fine
        with the 2 Meg in, booted off the floppy drive.

        Any ideas?  Suggestions on where to start?

        jimf
    

The other suggestion the CBM had (before i added the resistor) was that ther
were some problems with the Signetics 68000. CBM swapped mine for an Hitachi
unit (which didn't make any difference at all), but i am stii running the 
Hitachi with no problems.

 mark

Re: Expansion Memory and Hard Disk Problems

The problems sound like the same problem I have with my Pacific Peripherals
disk controller and my ASDG memory card.  Search for "Pacific Peripherals"
and you'll find my notes.

The Pacific Peripherals disk controller manages to transfer data into
the memory card during time that should be set aside for hidden refresh.
The result is the system crashes a lot with Guru 3 or Guru 4.

The problem can be solved (at a great decrease in disk speed) by
using the Mask entry in the mountlist to confine hard disk I/O
to chip memory.

Pacific Peripherals once game be a "fix" that involved soldering two
or three resisters onto the motherboard.  This is NOT the CBM resister
fix: it's completely different.  PP said that this fix was given out
by CBM at the last US DevCon. I sent mail to Dave Haynie about it,
and he either hadn't heard of the ECO, or hadn't heard of it in relation
to this problem (his mail wasn't clear).

I haven't tried this fix.  I'll see if I can find it and post it
if there is interest.  I did have the Commodore resister fix (to
U605) done;  it made no difference.

My mail to Haynie and his reply follows:

From:	TLE::RMEYERS      "Randy Meyers 381-2743 ZKO2-3/N30" 15-AUG-1989 22:20:26.20
To:	DECWRL::"[email protected]"
CC:	RMEYERS
Subj:	Amiga 2000 DMA problem

I hope that I'm not bothering you, but I have an Amiga hardware problem
and I've been told that there was a fix developed by Commodore and
released at the last DEVCON.  I'd like to get your opinion on it.

I have a Pacific Peripherals disk controller (the controller was
designed by Interactive Video Systems; Pacific licensed the design
and manufactures/sells the controller).  I also have an ASDG 8 Meg
card (4 Meg installed).  These two devices do not work well together.
DMA from the disk controller corrupts the contents of the ASDG memory
board (results in Guru 3 and 4, usually).

Of course, both Pacific Peripherals and ASDG claim that the
other causes the problem (I won't ask you to get in the middle
of that argument).  ASDG's version of what is going wrong is
that the PP controller's bus signals are 180 degrees out of
phase, and this causes the refresh logic of the memory board
to malfunction.  Pacific Peripherals doesn't seem to have
any idea of what is going wrong except that "It's the bad
design of the ASDG memory card."  Personally, it sounds to
me like ASDG knows what they're talking about.

Anyway, in my last conversation with the head guy of Pacific
Peripherals, he said that there was a hardware fix for this
problem given out by Commodore at the last DEVCON.  The
fix is to add two 2.2K pull-up resisters to the Amiga 2000
motherboard.  The first goes between DTACK and 5v, and the
second goes between AS and 5v.  The resisters should be added
"as close to the 68000 as possible, before any of the buffer
chips.  Mumble, mumble, pins 6 and 10."

(Don't worry if I've screwed up the details of this "fix":
if I have it done, I'll have my dealer do it, and he'll get the
details direct from Pacific Peripherals.)

My questions are:

Have you ever heard of this fix?

Do you think it will work?

Is this fix likely to affect (for good or ill?) other expansion
devices in the machine?

Will this fix make cause problems if I junk the disk controller
and buy a different manufacture's?  Will it cause problems if
I get a A2620 or A2630 board in the future?

Since I've been thinking about getting the A2620, I've been thinking
about having the 1K pull-up added between pins 20 and 11 of U605 (I
know this *is* a Commodore developed and recommended fix).  Is this
likely to interact with the fix from Pacific Peripherals?

Random additional information:

In case you've not figured it out, I don't know anything about
hardware.  I plan on solving my problems by throwing money at
my dealer.

I have a rev 4.2 motherboard.  My dealer is going to install the
1 meg Agnus and 1.3 ROMs next week.

My dealer has agreed (in principle) to do this fix for me.  He's
already warned me that hacking the motherboard makes it ineligible
for any sort of credit if it needs to be replaced.  So, you don't
need to add that warning.

The problem doesn't seem to exist if I keep the environment of the
computer at 65 degrees.  Easy to do in Winter here in New Hampshire,
bit difficult in Summer, though.

The problem doesn't manifest itself if I use the slow file system,
but that's pretty painful!

I'll probably eventually solve this problem by buying a different
brand of disk controller.  I've been waiting for a Commodore
controller with hard block support...

I hope I've not taken up too much of your time!  I appreciate
your participation in comp.sys.amiga.

Randy Meyers

From:	DECWRL::"[email protected]" 16-AUG-1989 16:54:54.55
To:	decwrl::"[email protected]", tle::rmeyers 
CC:	
Subj:	Re:  I hope that I'm not bothering you, but I have an Amiga hardware problem 

Cc: Amiga.2000.DMA.problem

>Anyway, in my last conversation with the head guy of Pacific
>Peripherals, he said that there was a hardware fix for this
>problem given out by Commodore at the last DEVCON.  The
>fix is to add two 2.2K pull-up resisters to the Amiga 2000
>motherboard.  The first goes between DTACK and 5v, and the
>second goes between AS and 5v.  The resisters should be added
>"as close to the 68000 as possible, before any of the buffer
>chips.  Mumble, mumble, pins 6 and 10."

>My questions are:

>Have you ever heard of this fix?

Well, not in that context.  The 2000 motherboard has always had pullups on 
DTACK and AS.  Originally, the DTACK value was around 3.3K, but as of the 
Rev 4.3 release it was changed to 470 Ohms to support a forthcoming (at the 
time) change in the Gary chip. That could have an effect on DMA device, 
especially those that are a bit marginal on their sampling of the DTACK
signal generated by the A2000 or by a memory board.  In essence, that may
work, but make sure you need it first.  Adding an additional 2.2K pullup to
the DTACK line that's already got a 470 Ohm pullup on it could cause trouble.

As for AS, the only change we've had for that is actually on BAS, the buffered
version of AS that's on the expansion bus.  They sound pretty confused on this
one.  The need for it was to correct a floating bus problem that occurs with
DMA and one brand of bus buffer chip, but in any case it's a good idea.  The
only thing we've seen actually have a problem with the incorrectly floating
bus is the A2620/A2630, mainly because they're so much faster than any other
memory, DMA or not.  The actual fix is to add a 1k pullup on the BAS line, which
can be added between pins 20 and 11 on the bus buffer, U605.  That's the
difference between Rev 4.4 and Rev 4.5 of the motherboard, and like I said, it's
in general a good idea.  That _might_ be a fix for your problem, and it 
couldn't hurt, though without knowing just what the two boards are doing, I
can't be sure.

>Is this fix likely to affect (for good or ill?) other expansion
>devices in the machine?
>Will this fix make cause problems if I junk the disk controller
>and buy a different manufacture's?  Will it cause problems if
>I get a A2620 or A2630 board in the future?

Should only help, as long are you're careful about not fixing an already fixed
machine.

>Since I've been thinking about getting the A2620, I've been thinking
>about having the 1K pull-up added between pins 20 and 11 of U605 (I
>know this *is* a Commodore developed and recommended fix).  Is this
>likely to interact with the fix from Pacific Peripherals?

Sounds like the same thing, only they got it slightly wrong.  Or possibly,
they found the same problem on an older board, and picked a different value
to fix it.  Best to go with the Commodore fix.

>Random additional information:

>In case you've not figured it out, I don't know anything about
>hardware.  I plan on solving my problems by throwing money at
>my dealer.

The dealer should know about the Commodore fixes, and really shouldn't charge
that much -- I'm no technician (engineers are always clumsier), but I could add
both parts in about 5 minutes, and the total parts cost is about 25 cents, at
Radio Shack prices.

>I have a rev 4.2 motherboard.  My dealer is going to install the
>1 meg Agnus and 1.3 ROMs next week.

It shoulds like the DTACK fix couldn't hurt you, then.  You already have a 
resistor on DTACK, so you don't want to add a 480 ohm value; I'd recommend
something in the 560 Ohm-1K range, the value isn't extremely critical.  I
guess Pacific Peripherals is correct after a fashion, but they really should
not make blanket statements; their updates on a Rev 4.3 or later board might
cause problems.

>The problem doesn't manifest itself if I use the slow file system,
>but that's pretty painful!

Yeah, I had heard that one before.

>Randy Meyers

-Dave Haynie

==================== Internet mail headers ====================
Received: from RUTGERS.EDU by decwrl.dec.com (5.54.5/4.7.34)
	id AA03890; Wed, 16 Aug 89 13:57:23 PDT
Received: from RUTGERS.EDU by decwrl.dec.com (5.54.5/4.7.34)
	for tle::rmeyers; id AA03890; Wed, 16 Aug 89 13:57:23 PDT
Received: from cbmvax.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP 
	id AA14449; Wed, 16 Aug 89 13:03:56 EDT
Received: by cbmvax.UUCP (5.57/UUCP-Project/Commodore 12/21/87))
	id AA23041; Wed, 16 Aug 89 11:12:35 EDT
Date: Wed, 16 Aug 89 11:12:35 EDT
Message-Id: <[email protected]>