hamilton@intersil.uucp (08/26/90)
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
<LEEK@QUCDN.QueensU.CA> (08/28/90)
In article <144.26d7d916@intersil.uucp>, hamilton@intersil.uucp says: > >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 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 You can get away without disconnecting the 4.7K pull-up... >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). Can we not have a custom (small) Kickstart in the WCS that execute modeload code to map the 2.0 image from Frances and continue boot there ? Check the ML* (pin 18) on the Frances PAL to make sure it doesn't go active on reboot. My instinct tells me to check that even though that shouldn't happen. > >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 Hope you find answers to #1, and #2. I am looking forward to a 030 in my Lucas. Good luck !! K. C. Lee Elec. Eng. Grad. student
<LEEK@QUCDN.QueensU.CA> (08/28/90)
In article <144.26d7d916@intersil.uucp>, hamilton@intersil.uucp says: > >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. ... stuff deleted ... >Part 2: Putting AmigaDOS 2.0 in FRANCES ram. > >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. > Hmmm. You went into the same problem I was facing in the 512K WCS hack... When you do a reboot, the boot rom takes over at 00XXXX and F8XXXX on a1000. It stays there untils it is sure kickstarts is loaded into WCS properly. The problem is REMAPK maps 32-bit memory into F8XXXX & FCXXXX area. I would think the boot code ended in the 32-bit ram instead of what is supposed to be in the boot rom and the computer hangs. :( This might be the problem other than the 8421 modeload as you mentioned yesterday. One thing we (Derek Noonburg & I) are trying to do right now (well sort of) for the 512K WCS hack is to relocate the Boot rom (hardware and software-wise) to F0XXXX and to make sure it branches to the proper address for different versions of kickstarts. Before I finished 1/2 of the code, he was done disassembling 8K worth of boot rom. This might be a second solution to booting 2.0 other than a custom kickstart. >-- >Fred Hamilton Any views, comments, or ideas expressed here >Harris Semiconductor are entirely my own. Even good ones. >Santa Clara, CA K. C. Lee Elec. Eng. Grad. Student (All my ideas/recommendations have been ignored. Almost got into a big fight with my boss today because of this. Think anyone care about my views ??)
daveh@cbmvax.commodore.com (Dave Haynie) (09/05/90)
In article <144.26d7d916@intersil.uucp> hamilton@intersil.uucp writes: >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. >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. SetCPU, as of V1.5 at least (latest is V1.6), always turns on Write Allocation. That's 100% necessary, because User and Supervisor data spaces are shared. >This would permit the possibility that the 030 was writing to a DMAable >location and caching the data (*CIIN is ignored during writes). Actually, the chances of problems with that "feature" (we call it a bug) is reasonably minimal, and in practice mainly a problem for systems in which there exist 32 bit wide I/O ports. DMA devices, to be safe for use with cache, clear the cache after they do transfers (the A2091 and A3000 hard disk drivers, for example, do this). But I/O ports aren't so easily taken care of. The cache is only updated on a longword write to a longword port, though, so you're pretty safe on an A1000. In any case, SetCPU V1.6 will set up a memory map with the normal Chip and I/O regions uncachable if you use FASTROM, if you're worried. But that's definitely not enough of a problem to cause instant crashes. >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. The problem is very likely that your FRANCES memory isn't cachable. In order to be considered data cachable by the '030, your memory board must always read its full port width, regardless of SIZ1-0 or A1-0. Simply put, all four bytes of your 32 bit memory must be valid for reads, or it won't be cachable. Most 68020 memory designs use the same byte enable logic for reads as writes, and therein lies the problem. >Fred Hamilton Any views, comments, or ideas expressed here >Harris Semiconductor are entirely my own. Even good ones. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Get that coffee outta my face, put a Margarita in its place!
<LEEK@QUCDN.QueensU.CA> (09/05/90)
In article <14194@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) says: > >>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. > >The problem is very likely that your FRANCES memory isn't cachable. In order >to be considered data cachable by the '030, your memory board must always >read its full port width, regardless of SIZ1-0 or A1-0. Simply put, all four >bytes of your 32 bit memory must be valid for reads, or it won't be cachable. >Most 68020 memory designs use the same byte enable logic for reads as writes, >and therein lies the problem. Yeap. Memory banks are enabled with A0, A1, Siz0, Siz1. Seem to me the fix is to have a new Frances PAL. We can use the AMY (pin 11) for R/*W20 and have !CS-AMY at pin 16 (Currently *CS) and !CS-NAMY at Pin 19 (currently unused ). !CS-AMY is just !CS hardwired for amy space while !CS-NAMY is hardwired for outside amy space. !CS-AMY = !MA23 & MA22 & !A31 & !A30 !CS-NAMY = !MA23 & MA22 & !A31 & A30 One can always cut a trace and solder a jumper to use *CS-NAMY putting Frances outside the lower 16M space. Still need to work out the !UUD, !UMD, !LMD, !LLD for selecting memory banks... How's that for minimize changes in Frances circuit board ? Hope you can get the 030 to cache Frances... Can't wait to get a 030 in my Lucas/Frances... Fun thing to do is to separate the 881/882 clock from 020 clock - need to do that before soldering in the socket. > >>Fred Hamilton Any views, comments, or ideas expressed here >>Harris Semiconductor are entirely my own. Even good ones. > Hope you get this to work... Get ready for a 040. @B^) >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > Get that coffee outta my face, put a Margarita in its place! Thanks !! That's probably the problem. K. C. Lee Elec. Eng. Grad. Student