Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!mips!daver!intersil!hamilton
From: hamilton@intersil.uucp
Newsgroups: comp.sys.amiga.hardware
Subject: 68030 in a LUCAS board, and 2.0 in FRANCES
Message-ID: <144.26d7d916@intersil.uucp>
Date: 26 Aug 90 14:13:42 GMT
Organization: Harris Semiconductor, Santa Clara CA
Lines: 62

This message has 2 parts;  Part 1 concerns getting a 68030 to work (WELL) in
a LUCAS board, and Part 2 explores the possibility of ever getting AmigaDos
2.0 to ever work in a LUCAS/FRANCES-based 1000 without the 2.0 ROMS.

Part 1:

I've adapted my LUCAS board to use a 68030, and it's working fine except
that it's performing just like the old 68020.  So now I'm working on getting
the data cache to work so I can cache FRANCES 32-bit ram accesses.  I'm
inverting the *DATABUSN signal (the one controlling the FRANCES 74LS245 buffers)
and using it to drive the 68030's *CIIN (cache inhibit in) pin.  In this
way the cache is always inhibited for all data accesses except for FRANCES. 
I've hooked the system up to a logic analyzer and everything seems to be
working as I expected.

But the system crashes everytime I do a "SetCPU cache".  My first thought 
was that perhaps SETCPU turns on data cache write allocation when it turns
on the data cache.  This would permit the possibility that the 030 was
writing to a DMAable location and caching the data (*CIIN is ignored during
writes).  I eliminated this possibilty by tying *CIIN low and turning on the
cache: since my Amiga didn't crash, it appears that the 030 wasn't caching
anything.

So it appears one of two things must be happening:  The FRANCES data buffers
are being enabled during reads of non-FRANCES data (yikes!), or the FRANCES
memory is not cacheable, but I have no idea why this would be.  Nothing is
reading or writing to FRANCES except the 030.

So if anyone has any suggestions or ideas of what I might be overlooking,
I'd appreciate the help.

Part 2:  Putting AmigaDOS 2.0 in FRANCES ram.

While I was doing the work above, I was also looking in to how difficult
it would be to remap a 512K 2.0 image into FRANCES using the same hardware
memory re-mapping technique Brad used for the 256K KS ROMs.  K. C. Lee has 
posted a message showing how easy the addressing change was (disconnect
pin 4 of U52 from the 4.7k pull-up and tie it (pin 4 of U52) to pin 4 of
U53.  This works (thanks, K. C.).  The only problem is, FRANCES ram disappears
between when you reset the computer (control A-A) and when the resident
AFM program is executed.  All the information is still there, but the 68020
can't access it until it is "ModeLoad"ed by the resident AFM program.  I
confirmed this by connecting a switch to the REMAPK (re-map KickStart) line
after loading KickStart 1.3 into FRANCES.  If I pulled REMAPK high, everything
worked until I re-booted, at which point the entire computer just hung up until
I pulled REMAPK low (selecting the WCS instead of FRANCES) and re-booted.

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

So again, if anybody has any suggestions for this puzzle, please let me know.

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