Path: 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 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