[comp.sys.amiga.tech] Help with Frances

collins@well.sf.ca.us (Steve Collins) (08/20/90)

I seem to have narrowed my frances troubles to two main problems:
1   The modeload doesn't program the controller most of the time.
If I call it several times in sucession, I can manage to get the controller
properly programmed. I have observed that the CAP pin on the controller
seems to be high when the controller is sucessfully programmed and
low if it is not. What does the CAP pin do anyway?

2 When I managed to get the controller programmed and working, I looked
at the memory at 0x400000 and it seems to exist and be stable, eg I can
change values there and they stay changed. The problem occurs when I try
to add the memory to the system using addram. Addram reports that the memory
test succeeded, but after the memory is added to the system, the computer
crashes when I first try to execute a command, or when I resize the CLI
window. I have noted that after addram, each keypress causes the
frances CS line to blip low. This occurs only after calling addram and I'll
be darned if I can figure out what is going on. 

The frances is in an A500 and as I said before, my Lucas works fine as far as
I can tell. I have a grounded copper clad board under the frances and the
symptoms seem to dependable to be a noise related problem. 

Has anyone seen either of these problems before or have any ideas?
Could the system somehow be thinking that the frances ram is CHIP ram?
How would that explain the keypress !CS toggles?

                              Thanks again in advance
                                         steve collins

 {_     ALT rep^?{ly : !hacgate!trwind!mcosm!collins

vincelee@tornado.Berkeley.EDU (Vincent H. Lee) (08/21/90)

In article <19626@well.sf.ca.us> collins@well.sf.ca.us (Steve Collins) writes:
>
>I seem to have narrowed my frances troubles to two main problems:
>1   The modeload doesn't program the controller most of the time.
>If I call it several times in sucession, I can manage to get the controller
>properly programmed. I have observed that the CAP pin on the controller
>seems to be high when the controller is sucessfully programmed and
>low if it is not. What does the CAP pin do anyway?

I had the same problem with modeloding myself.  I never actually fixed the
problem.  I finally "solved" the problem by recompiling AFM so that it
modeloads repeatedly.  The modeloading is done in one line of code by reading
from an appropriate address.  I just put that line in a loop of 1000 or so
and never had another problem.  BTW, another prob with AFM seemed to be that
it always thought I had twice as much ram installed on the Frances as I did.
There was some sort of math error in the code, as I recall.

>
>2 When I managed to get the controller programmed and working, I looked
>at the memory at 0x400000 and it seems to exist and be stable, eg I can
>change values there and they stay changed. The problem occurs when I try
>to add the memory to the system using addram. Addram reports that the memory
>test succeeded, but after the memory is added to the system, the computer
>crashes when I first try to execute a command, or when I resize the CLI
>window. I have noted that after addram, each keypress causes the
>frances CS line to blip low. This occurs only after calling addram and I'll
>be darned if I can figure out what is going on. 

perhaps you have some shorted address lines.  Then, looking one byte at a time,
all the ram would seem to be fine.  Even the memtest program would report the
same.  What you need is a small C program to write a different value to all the
RAM in a range first, and then go back to check it.  That way, all the ram
would be guaranteed to be not only good, but distinct as well.

-vince
>                                         steve collins

swarren@convex.com (Steve Warren) (08/21/90)

In article <1990Aug21.083830.26826@agate.berkeley.edu> vincelee@tornado.Berkeley.EDU (Vincent H. Lee) writes:
>same. What you need is a small C program to write a different value to all the
>RAM in a range first, and then go back to check it.  That way, all the ram
>would be guaranteed to be not only good, but distinct as well.

Write the address of the data to the data.  Then when you read bad data
out you know which address it came from.  Of course any code will work,
but the address code is easiest to interpret.

--
            _.
--Steve   ._||__      DISCLAIMER: All opinions are my own.
  Warren   v\ *|     ----------------------------------------------
             V       {uunet,sun}!convex!swarren; swarren@convex.COM