[comp.sys.amiga.hardware] 2.0 in FRANCES

joost@neabbs.UUCP (JOOST BOERHOUT) (09/05/90)

In msg 440507 news.amigahard 28-08-90 Fred Hamilton wrote:

 FH> The only problem is, FRANCES ram disappears betwen when you reset
 FH> the computer (control A-A) and when the resident AFM program is executed.
 FH>
 FH>  [ ... some stuff deleted ... ]
 FH>
 FH> So the only reason that you can have 1.3 in FRANCES ram is because
 FH> during re-boot the exact same image exists in the WCS/ROMs. So if we ever
 FH> want to have a chance of using this technique to run 2.0 (without 2.0 in
 FH> ROM from a Rejuevenator or the like), we'll have to figure out why the
 FH> 8421 DRAM controller seems to lose its programming and needs to be
 FH> modeloaded after every reset (*RESET only goes to the REMAPK flip-flop,
 FH> it doesn't go to the 8421).

I took a thorough look at the spec of the DP8421 DRAM controller and could
not find anything which matches the above described behaviour. There is no
way that the chip 'knows' that a reset cycle is going on. So what actually
happens during a reset of the 68020 ?  The only important thing I can
imagine is that the address bus will be tri-stated thus writing nonsence
to the chip !  This could be fixed with a pulldown resistor at A23 or A31.
I must admit that the above sounds silly but who knows (Murphy :-).

I myself have two problems with FRANCES:

 1) it needs a warming up of 3 - 5 minutes or so.
 2) AFM alway fails to find FRANCES the first time.

I can't explain why FRANCES needs the warming up except the darn thing
is working on the edge of the (timing) specs. A heated chip will have
a shift in the timing specs so this seems to be the case.
I have version 1.11a of the AFM program. This version does not wait for
the required 60ms initialization time of the DP8421 (I took a gimpse
of the source). This should explain why AFM always finds FRANCES the
second time it runs.
Are these two 'problems' known to anyone of you ? Please confirm.

- joost -

hamilton@intersil.uucp (09/07/90)

In article <444299@neabbs.UUCP>, joost@neabbs.UUCP (JOOST BOERHOUT) writes:
> In msg 440507 news.amigahard 28-08-90 Fred Hamilton wrote:
> 
>  FH> The only problem is, FRANCES ram disappears betwen when you reset
>  FH> the computer (control A-A) and when the resident AFM program is executed.
>  FH>
>  FH>  [ ... some stuff deleted ... ]
>  FH>
>  FH> So the only reason that you can have 1.3 in FRANCES ram is because
>  FH> during re-boot the exact same image exists in the WCS/ROMs. So if we ever
>  FH> want to have a chance of using this technique to run 2.0 (without 2.0 in
>  FH> ROM from a Rejuevenator or the like), we'll have to figure out why the
>  FH> 8421 DRAM controller seems to lose its programming and needs to be
>  FH> modeloaded after every reset (*RESET only goes to the REMAPK flip-flop,
>  FH> it doesn't go to the 8421).
> 
> I took a thorough look at the spec of the DP8421 DRAM controller and could
> not find anything which matches the above described behaviour. There is no
> way that the chip 'knows' that a reset cycle is going on.

I _think_ that was my mistake.  I now believe it was locking up because 
when you reset the Amiga it wants to yank KS down to location $000000 and
it probably does other funky stuff that I don't know about during reset.

** If anyone can tell me what an A1000 does during reset I'd appreciate it! **

I'm trying to figure out where the WCS goes, whether or not the "cold boot"
ROMs are ever used again once KickStart is loaded into the WCS, etc.

> So what actually
> happens during a reset of the 68020 ?  The only important thing I can
> imagine is that the address bus will be tri-stated thus writing nonsence
> to the chip !  This could be fixed with a pulldown resistor at A23 or A31.
> I must admit that the above sounds silly but who knows (Murphy :-).

No, the kickstart image remains there, and intact.

> I myself have two problems with FRANCES:
> 
>  1) it needs a warming up of 3 - 5 minutes or so.

Not mine.  Are you using 70-80ns ram?  What clock frequency?  I run at
18MHz with 80ns ram and the minimum wait states (1 or 2, I can't remember).

>  2) AFM alway fails to find FRANCES the first time.

Mine fails about 1 in 3 tries, whether "cold" or "warm".

> I can't explain why FRANCES needs the warming up except the darn thing
> is working on the edge of the (timing) specs. A heated chip will have
> a shift in the timing specs so this seems to be the case.
> I have version 1.11a of the AFM program. This version does not wait for
> the required 60ms initialization time of the DP8421 (I took a gimpse
> of the source). This should explain why AFM always finds FRANCES the
> second time it runs.

Actually the FRANCES board itself waits the 60ms by asserting the *RFIP
output of the 8421 until the initialization is over.  This delays *FDSACK
as long as required (top of the second page of the FRANCES schematics).

> - joost -
-- 
Fred Hamilton                  Any views, comments, or ideas expressed here
Harris Semiconductor           are entirely my own.  Even good ones.
Santa Clara, CA

swarren@convex.com (Steve Warren) (09/07/90)

In article <444299@neabbs.UUCP> joost@neabbs.UUCP (JOOST BOERHOUT) writes:
>I can't explain why FRANCES needs the warming up except the darn thing
>is working on the edge of the (timing) specs. A heated chip will have
>a shift in the timing specs so this seems to be the case.

Yes, a common failure on higher-speed systems is the "cold" failure.
Some technicians debug a board like this with a can of freon:

1) Warm the board up and start a looping test that is known to fail cold.

2) Spray a chip with freon until it frosts over.

3) Let the chip warm up, then spray the next chip over.

4) Repeat until you find the chip that makes the board fail when it is cold.

5) Replace the chip.

6) Pray it is fixed.  ;^)

Note - freon cans used for this purpose use a spray nozzle with a metal
tube inserted in the nozzle to direct the spray.  The metal tube is grounded
through a wire so that the freon spray does not carry static charges through
the air, damaging the circuit.

A cold failure usually means there really is a problem with the board.  It
just happens that it is not noticeable most of the time.  That does not mean
you should not try to find the problem...
--
            _.
--Steve   ._||__      DISCLAIMER: All opinions are my own.
  Warren   v\ *|     ----------------------------------------------
             V       {uunet,sun}!convex!swarren; swarren@convex.COM

<LEEK@QUCDN.QueensU.CA> (09/07/90)

In article <153.26e68f95@intersil.uucp>, hamilton@intersil.uucp says:
>
>I _think_ that was my mistake.  I now believe it was locking up because
>when you reset the Amiga it wants to yank KS down to location $000000 and
>it probably does other funky stuff that I don't know about during reset.
>
>** If anyone can tell me what an A1000 does during reset I'd appreciate it! **

Reset -> Boot rom is overlayed into 00000000 where 680X0 picks up reset vector
to branch to itself at 00F80000.  It went and decided whether or not kickstart
should be loaded from disk or not.  When that is done, it write protect WCS &
make itself go away, and then branch to Kickstart (with the help of 680x0
prefetch pipeline)

Now there are 2 problems you'll see if you hardwire the remap logic of Frances.
At reset, boot rom kicks in at 00000000, 68000 got branched to boot rom

JMP $F8008A.L    (location which is now occupied by kickstart)

Since the proper address to jump to in 1.2 or 1.3 is FC0002, your Amiga
suffer a freeze-up.  (F8008A might be different for a different version of
boot rom
                                               (F8008A)
Things to try is to place a Jmp FC0002 at that location.  In 1.2/1.3 that
location is occupied by C= copyright notice.  You should be able to edit that
in without problem.  (Remember to calculate a new checksum foir kickstart !!)
Hardwire the Remap logic and you should be able to reboot from 32-bit kickstart
.

If that works, you might want to sit back and work on the Data Cache problem
with Frances...  Right now Derek Noonburg and I are working on a new boot rom
which is relocated to F00000.  If that works, it would branch to the proper
address for 1.X or 2.X kickstarts.  Other solutions exists too.

>--
>Fred Hamilton                  Any views, comments, or ideas expressed here
>Harris Semiconductor           are entirely my own.  Even good ones.
>Santa Clara, CA

Send me email if you want more boot rom info...  (I had problem reaching you.)

K. C. Lee
Elec. Eng. Grad. Student