🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #4948

Re: Help with Frances

#4948
From: Vincent H. Lee
Date: Tue, 21 Aug 1990 08:38
36 lines
2703 bytes
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
Technical Details
Message-ID: <1990Aug21.083830.26826@agate.berkeley.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!decwrl!apple!bionet!agate!tornado.Berkeley.EDU!vincelee
References: <19626@well.sf.ca.us>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!decwrl!apple!bionet!agate!tornado.Berkeley.EDU!vincelee
From: vincelee@tornado.Berkeley.EDU (Vincent H. Lee)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Help with Frances
Message-ID: <1990Aug21.083830.26826@agate.berkeley.edu>
Date: 21 Aug 90 08:38:30 GMT
References: <19626@well.sf.ca.us>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: vincelee@tornado.Berkeley.EDU (Vincent H. Lee)
Distribution: comp.sys.amiga.tech comp.sys.amiga.hardware
Organization: ucb
Lines: 36