helmutn@cip-s03.informatik.rwth-aachen.de (Helmut Neumann) (09/28/90)
Hi, does anybody out there know, how to activate the Caches of the GVP 3001 to work on Chip-Mem. A 030-Board of a German developer does this, and it makes a tremendous speed-increase. On the 020-Board i had before the 3001 this feature worked too, and it made nearly no problems. (i found only one program running on the 3001, which has not run on my 020). Please answer only, if you have an idea how to solve, i dont want to diskuss about performance-theory ! Bye, Helmut.
rbabel@babylon.UUCP (Ralph Babel) (09/29/90)
In article <3551@rwthinf.UUCP> helmutn@cip-s03.informatik.rwth-aachen.de (Helmut Neumann) writes: > does anybody out there know, how to activate the Caches of > the GVP 3001 to work on Chip-Mem. Get the new set of PALs required for MMUKick. This will enable the code cache in MEMF_CHIP. You cannot enable the data cache. SetCPU 1.6, however, disables all caching in MEMF_CHIP (maybe Dave should make this an option). Ralph
daveh@cbmvax.commodore.com (Dave Haynie) (10/03/90)
In article <3551@rwthinf.UUCP> helmutn@cip-s03.UUCP (Helmut Neumann) writes: >Hi, >does anybody out there know, how to activate the Caches of >the GVP 3001 to work on Chip-Mem. A 030-Board of a German >developer does this, and it makes a tremendous speed-increase. Well, for the instruction cache, you can enable caching, though it's not likely to make much performance difference, since instructions are only rarely located in Chip RAM as long as you have some Fast RAM. Under no conditions should you enable data caching of Chip RAM. The system will crash very quickly after reboot, guaranteed. I don't know the GVP hardware, but it might be possible, with enough effort, to reverse engineer the hardware cache control. The 68030 cache is controlled externally by a signal called CIIN* (Cache In INhibit). The GVP board very likely has a PAL of some kind controlling this signal. That PAL will also have a number of system address lines which are necessary to figure out what should and shouldn't be cached. You will also need the three function code lines FC0-FC2, which aren't likely in that PAL. Caching equations are very easy to figure out for any Amiga system; the problem is, the cache control PAL on the GVP board may generate other controls as well which are GVP rather than Amiga related. These may be difficult to figure out without GVP's help. >Bye, Helmut. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
daveh@cbmvax.commodore.com (Dave Haynie) (10/03/90)
In article <04071.AA04071@babylon.UUCP> cbmvax.commodore.com!cbmehq!babylon!rbabel (Ralph Babel) writes: >In article <3551@rwthinf.UUCP> >helmutn@cip-s03.informatik.rwth-aachen.de (Helmut Neumann) writes: >> does anybody out there know, how to activate the Caches of >> the GVP 3001 to work on Chip-Mem. >Get the new set of PALs required for MMUKick. This will >enable the code cache in MEMF_CHIP. You cannot enable the >data cache. SetCPU 1.6, however, disables all caching in >MEMF_CHIP (maybe Dave should make this an option). There's a good reason for this behavior, which was intended for A3000 support. The 68030 will cache longword data written to a longword port, regardless of the status of the hardware cache enable. That includes Chip memory on the A3000, though of course enhanced A2000s are still dealing with 16 bit Chip RAM. The 68030 cache does, however, obey the caching information set up by the MMU. To handle I and D spaces separately, though, you have to build at least two different MMU tables, which is generally a waste of memory. And it slows down the system, since you'll have twice as many translation entries. If you don't have any Fast memory, you won't be using SetCPU's MMU table setup in the first place. If you do have Fast memory, you aren't going to run into many cases in which there's any code to worry about in Chip memory in the first place. Some of the MMU programs, like SetCPU V1.5 or MMUKick, required I-cachable Chip memory simply because that was the most direct solution to the reboot problem in a system like the A26x0 which supported this. But I really don't see too much advantage to I-caching of Chip RAM. >Ralph -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
rbabel@babylon.UUCP (Ralph Babel) (10/03/90)
In article <14811@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >> SetCPU 1.6, however, disables all caching in MEMF_CHIP. > > To handle I and D spaces separately, [...] Don't handle them separately, just give us an option "CACHECHIP" that doesn't set the CI bit in the MEMF_CHIP table entries. Maybe you should check for non-A3000 first. Thanks, Ralph
helmutn@cip-s02.informatik.rwth-aachen.de (Helmut Neumann) (10/04/90)
Hi, the advantage takes place when you use games, for example damocles. On my old 020-board at 7 Mhz it ran a lot faster then on my 32 Mhz 030. You know, that most games directly use Chipmem, because that is an memory-area, that exists in every Amiga. For this Reason the most Amiga-Games are not relocatable and have the code in Chipmem. But another question, my gvp 3001 is just a few weeks old, and i've loaded the kick2.0 with setcpu 1.6. This worked with no problem except that i had to upgrade the Chip-Mem to 1 Mb before. Is it possible, that i have this new Pals already ? Bye, Helmut.
rbabel@babylon.UUCP (Ralph Babel) (10/08/90)
In article <3565@rwthinf.UUCP> helmutn@cip-s02.informatik.rwth-aachen.de (Helmut Neumann) writes: > On my old 020-board at 7 Mhz it ran a lot faster then on > my 32 Mhz 030. I assume your 020-board didn't include an '851, so you didn't use "SetCPU FASTROM". Maybe you should try "SetCPU NOFASTROM" before starting your game on the GVP 3001. Most games will not disable the MMU or touch expansion memory, so the MMU translation tables will stay alive and inhibit caching MEMF_CHIP. > Is it possible, that i have this new Pals already ? If "SetCPU KICKROM" works, this is indeed very likely. Ralph
daveh@cbmvax.commodore.com (Dave Haynie) (10/10/90)
In article <3565@rwthinf.UUCP> helmutn@cip-s02.UUCP (Helmut Neumann) writes: >But another question, my gvp 3001 is just a few weeks old, and i've >loaded the kick2.0 with setcpu 1.6. This worked with no problem >except that i had to upgrade the Chip-Mem to 1 Mb before. Is it >possible, that i have this new Pals already ? It's possible. SetCPU V1.6 doesn't require cachable Chip memory to effect its reboot (SetCPU V1.5 did, and also wouldn't deal with 512K ROMs). But it does require the RESET instruction to work. As I understood it way back when the GVP problems first surfaced, there was a bug in the GVP reset logic. I though the reset and chip caching issues were resolved in the same PAL fix, but possibly not. >Bye, Helmut. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
visinfo@ethz.UUCP (VISINFO c/o Sascha Schnapka) (10/26/90)
In article <14811@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: [some lines deleted] >But I really don't see too much advantage to I-caching of Chip RAM. > I agree that it is definitely wrong to speak of a 'tremendous performance increase' for Cache in Chip Memory. Yet I was unsatisified with the fact that the A3000 is usually unable to provide it, even more now where the GVP has it. There is in fact one case when you might like I-Cache in chipmemory: for games like flight-simulators that place (like most games) their code in chip-memory. I have experimented with some and found that for example Starglider 2 by Argonaut Software gives you a beautiful smooth moving 3D picture that is indeed better than without cache. Anyone who is interested can now download 'chipcache12.lzh' from abcfd20.larc.nasa.gov to try having I-Cache in chipmemory on the A3000. The solution I made is not the optimum, it globally disables Data Cache to avoid Data Cache in chipmemory. I will try to implement the idea with seperate instruction/data translation trees too and will publish some speed comparison results. F.Burgel (BIX: hardwiz)