hamilton@intersil.uucp (Fred Hamilton) (02/23/90)
I got bored this weekend and ended up building one of the cheesiest (but least
expensive-$20 in parts) 68020 to 68030 CPU upgraders possible: an 030 socket
to an 020 header with about 100 short wires between them. The Motorola 68030
data book has an applications section explaining that this WILL work and what
needs to be connected to what to make it work, etc., and I just followed that.
Well, much to my surprise it DID work. My goal was to run SetCPU and have it
say "68030" and other neat stuff instead of "FPU Logic Error" which it has
always said in the past (Brad Fowles didn't properly decode the FPU on the
Lucas). If I got that far I could at least go to sleep happy, anyway. I ran
SetCPU and it said "68030...Data Cache OFF...<other neat stuff>". So I turned
the data cache on and...it crashed. In addition, it crashed when I ran AFM
to add the Frances RAM to the system. In all other respects, it seems to
work great! So my questions are:
1) Should I be able to turn on the data cache and have everything work OK,
or should it always be off when accessing chip ram because of DMA going
on? Is that why it crashed? How do other 030 boards deal with it?
and
2) Any ideas why I can't add my 32 bit Frances RAM to the system?
The adapter itself may be causing some problems due to the 30 gauge, 2-3" long
wires connecting the two sockets causing coupling between adjacent wires and
adding resistance. Other than that, though, I feel it should work. Any ideas?
Class? Anyone?
--
Fred Hamilton Any views, comments, or ideas expressed here
Harris Semiconductor are entirely my own. Even good ones.
Santa Clara, CAdaveh@cbmvax.commodore.com (Dave Haynie) (02/24/90)
In article <86.25e424b2@intersil.uucp> hamilton@intersil.uucp (Fred Hamilton) writes: >1) Should I be able to turn on the data cache and have everything work OK, > or should it always be off when accessing chip ram because of DMA going > on? Is that why it crashed? How do other 030 boards deal with it? Chip memory absolutely can't be data cached. You will crash instantly, just as you suspected; the blitter can modify data that's cached, and thus the CPU gets confused about what's really in memory. You also have to disable the cache for all I/O registers; on a stock A1000, these are from $00A00000 through $00DFFFFF. That's not the whole picture, though. Memory that's data cachable has one more restriction -- such memory must always return full port width on read cycles. So basically, on a read you'd ignore the bus sizing and return either 16 or 32 bits wide. I'm not sure how every board does this, but I can certainly tell you how the A2630 does it (and GVP apparently does something very similar). The 68030 has one new pin called CIIN*, which is a cycle-by-cycle cache inhibit. A PAL on the A2630 drives CIIN* for any data space access to chip memory or I/O. During those accesses, it also creates UDS* and LDS* based on actually requested bus sizing. For cachable areas, it won't assert CIIN*, but will drive both UDS* and LDS* for reads, regardless of the sizing information. >2) Any ideas why I can't add my 32 bit Frances RAM to the system? With or without the D-cache on? The 68030 bus timing is the same as that of the 68020's for asynchronous cycles; if it worked before, it should work now. Unless you've added additional noise somehow; a hand wiring job may be a bit noisy for high speed stuff. Use lots of bypass capacitors in varying values near the '030, that could help. It's impossible to tell just what failed from here. However, if FRANCES returns full port data on a read, you should be able to map cachability using the MMU such that only FRANCES is considered cachable. That would allow data caching; this is how the Hurricanes do it. It's not as good as real hardware support for caching, but it can work. >Fred Hamilton Any views, comments, or ideas expressed here -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
valentin@cbmvax.commodore.com (Valentin Pepelea) (02/24/90)
In article <86.25e424b2@intersil.uucp> hamilton@intersil.uucp (Fred Hamilton) writes: > > So I turned the data cache on and...it crashed. In addition, it crashed > when I ran AFM to add the Frances RAM to the system. In all other respects, > it seems to work great! So my questions are: > >1) Should I be able to turn on the data cache and have everything work OK, > or should it always be off when accessing chip ram because of DMA going > on? Is that why it crashed? How do other 030 boards deal with it? Yes, that's what the problem was. The A2630 board disables the cache automatically through hardware (MMUDIS pin) when chip and I/O memory is accessed. You have to do the same thing, but through software. Take the source code to Dave Haynie's Setcpu, and in the translation tables, set the CI bit (cache inhibit) for all the page descriptors that map the chip ram area and the hardware registers area. > 2) Any ideas why I can't add my 32 bit Frances RAM to the system? I don't know what the AFM program is and does. (and how it does it) Send me a Lucas board, and I'll solve these problems for you. (I already have a 68030 to 68020 widget) Valentin :-) -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
daveh@cbmvax.commodore.com (Dave Haynie) (02/27/90)
In article <9813@cbmvax.commodore.com> valentin@cbmvax.cbm.commodore.com (Valentin Pepelea) writes: >In article <86.25e424b2@intersil.uucp> hamilton@intersil.uucp (Fred Hamilton) writes: >>1) Should I be able to turn on the data cache and have everything work OK, >> or should it always be off when accessing chip ram because of DMA going >> on? Is that why it crashed? How do other 030 boards deal with it? >Yes, that's what the problem was. The A2630 board disables the cache >automatically through hardware (MMUDIS pin) when chip and I/O memory is >accessed. That's actually the CIIN* pin, which is the input used to disable '030 caching on a cycle-by-cycle basis. Right idea, though. The MMUDIS* pin is actually for use by emulators to disable the MMU when necessary. The A2630 enables the I-Cache but not the D-Cache for Chip memory or autoconfig space $00E80000-$00EFFFFF; it enables both caches for $00C00000-$00CFFFFF and $00200000-$009FFFFF. >Valentin :-) -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough