koren@hpfelg.HP.COM (Steve Koren) (10/03/90)
I recently bought a (used) Hurricane 2800 '030 card. It seems to work
great with one exception; I was wondering if anyone else had noticed this
exception.
The board itself comes with 4 meg of 32 bit ram. This, in addition to
my 1 meg of 16 bit chip ram gives 5 meg. In this configuration, all
works great.
I also have a 2 meg card of 16 bit fast ram, made by MicroBotics. Normally
this ram autoconfigures. If I set it up that way with the hurricane card,
I expect to have 7 total meg composed of 1 meg of 16 bit chip ram, 2 meg of
16 bit fast ram, and 4 meg of 32 bit fast ram.
However, it doesn't work. More specifically, the MicroBotics memory
autoconfigures OK, but when accessed, it returns seemingly random values
(or at least, not the values which were written there). With the '030
disconnected, the MicroBotics memory works fine.
Someplace in the Hurricane 2800 docs, they mention a "bug in AmigaDos"
which they claim prevents '030 data and instruction caches from working
correctly with normal fast ram. So far I haven't tested this (as their
configuration program turns on caches by itself, and since the ram has
already autoconfigured itself, its too late - system crash). Is there
any way I can use my other 2 meg with the '030 card? Do any other
'030 cards exhibit the same problems?
Thanks to anyone who can offer some insight...
- steve (koren@hpfela.HP.COM)lkoop@pnet01.cts.com (Lamonte Koop) (10/05/90)
koren@hpfelg.HP.COM (Steve Koren) writes: [stuff deleted] > >However, it doesn't work. More specifically, the MicroBotics memory >autoconfigures OK, but when accessed, it returns seemingly random values >(or at least, not the values which were written there). With the '030 >disconnected, the MicroBotics memory works fine. > >Someplace in the Hurricane 2800 docs, they mention a "bug in AmigaDos" >which they claim prevents '030 data and instruction caches from working >correctly with normal fast ram. So far I haven't tested this (as their >configuration program turns on caches by itself, and since the ram has >already autoconfigured itself, its too late - system crash). Is there >any way I can use my other 2 meg with the '030 card? Do any other >'030 cards exhibit the same problems? > >Thanks to anyone who can offer some insight... > > - steve (koren@hpfela.HP.COM) I don't know about that. I have a CSA Mega-Midget Racer 030 board with 32-bit RAM, and 16-bit RAM on the system and it works fine. The data cache is not enabled on the 16-bit RAM, but there is a PAL to do this if I want it (never saw the need...16-bit RAM cacheing probably won't add much perfomance). I'm not sure about this (someone correct me if I'm wrong), but I believe the instruction cache should work fine in the 16-bit environment...the OS itself will enable the ICache, and there are boards out there which have no 32-bit RAM, but run 020s and 030s with the ICache on. In fact, I've done some testing about, and found that in a 16-bit RAM environment, it's possible to make a 25MHz 030 run SLOWER than a 7.14MHz 68000, IF the Instruction cache is off, and no 32-bit RAM is used. The 020, 030, etc... are all very reliant on the ICache as in integral part of their architecture, and to not use them in a 16-bit environment really exposes the processor to the bottleneck of said environment. In short, I'd be just a bit suspicious about the claim that a bug in AmigaDOS prevents the ICache from woring properly in a 16-bit environment. But I COULD be wrong.... UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!lkoop ARPA: crash!pnet01!lkoop@nosc.mil INET: lkoop@pnet01.cts.com
daveh@cbmvax.commodore.com (Dave Haynie) (10/06/90)
In article <4825@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes: >koren@hpfelg.HP.COM (Steve Koren) writes: >>Someplace in the Hurricane 2800 docs, they mention a "bug in AmigaDos" >>which they claim prevents '030 data and instruction caches from working >>correctly with normal fast ram. I read this when I wrote a review of the Hurricane boards. It's total nonsense. Basically, the rules for data caching hadn't been invented at the time the 68000 bus, and by extention the Zorro II bus, were defined. So, in order to support data caching of 16 bit RAM, your 68030 board needs extra logic. The Hurricane board didn't add this extra logic, the A2630 and GV 68030 boards did. I don't hold this against the Imtronics, the current vendor of the Hurricane boards; they bought the Hurricane design from the inital designers. Both solutions work, the only real problem I see is that, when the documentation says it's a bug in the Amiga architecture that prevents data caching of 16 bit memory, it is telling you a baldfaced lie. >The data cache is not enabled on the 16-bit RAM, but there is a PAL to do this >if I want it (never saw the need...16-bit RAM cacheing probably won't add much >perfomance). On the contrary! The greater the difference between cache speed and memory speed, the more the cache helps. If the memory were as fast as the cache, the cache would offer no speed improvement in a single processor system. >I'm not sure about this (someone correct me if I'm wrong), but I believe the >instruction cache should work fine in the 16-bit environment...the OS itself >will enable the ICache, and there are boards out there which have no 32-bit >RAM, but run 020s and 030s with the ICache on. That's true. AmigaOS 1.3 knows about 68020s, but not 68030s. So the I-Cache is automatically enabled, but not the D-Cache. The hardware restriction for data cachability on the 68030 never applied to instruction cache, since that was a read-only cache and instruction sizes were well defined. The D-Cache requires hardware reads to always return the full port size of the addressed item, regardless of the instruction-requested data object size. This wasn't natural for a 68000->68020 CPU, where it made sense to make read and write actual sizes the same. It's trivial to design a 68030 Coprocessor board that will always request full port reads from 16 bit memory to allow cachability, but the folk at Ronin, who did the Hurricane design, decided to sacrifice a little performance and allow only D-caching of 32 bit memory. >In fact, I've done some testing about, and found that in a 16-bit RAM >environment, it's possible to make a 25MHz 030 run SLOWER than a 7.14MHz 68000, >IF the Instruction cache is off, and no 32-bit RAM is used. The 020, 030, etc... >are all very reliant on the ICache as in integral part of their architecture, >and to not use them in a 16-bit environment really exposes the processor to >the bottleneck of said environment. The basic problem here is that the instruction unit in both 020 and 030 always pre-fetches full 32 bit words. If you have 16 bit memory, that's two bus cycles. But, in many cases, the second 16 bit word is thrown out. This is never a penalty on a 32 bit bus, but on a 16 bit bus, you end up fetching and throwing out stuff. A 68000 only does 16 bit prefetch, and therefore never throws out anything in the instruction stream. >In short, I'd be just a bit suspicious about the claim that a bug in AmigaDOS >prevents the ICache from woring properly in a 16-bit environment. But I COULD >be wrong.... But you aren't, and you obviously had the good sense to spot a bad argument. >UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!lkoop -- 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
koren@hpfelg.HP.COM (Steve Koren) (10/10/90)
> I read this when I wrote a review of the Hurricane boards. It's total > nonsense. > when the documentation says it's a bug in the Amiga architecture that prevents > data caching of 16 bit memory, it is telling you a baldfaced lie. > That's true. AmigaOS 1.3 knows about 68020s, but not 68030s. So the I-Cache > is automatically enabled, but not the D-Cache. The hardware restriction for Ok, thanks for clearing this up, Dave. I will try using I-cache and not D-cache and see what happens. Their supplied "hurricaneconfig" program enables both, but I can probably use SetCPU to turn off the one promptly thereafter. Not looking forward to loosing the performance (D-cache makes a big difference), but I guess ya gotta do what ya gotta do. - steve
koren@hpfelg.HP.COM (Steve Koren) (10/11/90)
> time the 68000 bus, and by extention the Zorro II bus, were defined. So, in > order to support data caching of 16 bit RAM, your 68030 board needs extra > logic. The Hurricane board didn't add this extra logic, the A2630 and > GV 68030 boards did. I don't hold this against the Imtronics, the current This may be true, but there is apparently something else going on also. I did a few memory tests last night on the 16 bit memory as follows: Test 1: 16 bit memory enabled, 68030, I-cache, D-cache: FAILED Test 1: 16 bit memory enabled, 68030, I-cache, no D-cache: FAILED Test 1: 16 bit memory enabled, 68030, no I-cache, D-cache: FAILED Test 1: 16 bit memory enabled, 68030, no I-cache, no D-cache: FAILED Test 1: 16 bit memory enabled, 68000, no I-cache, no D-cache: SUCCEDED All configurations failed with the '030 card; however, booting with the 68000 allows the mem to work. (This would tend to indicate that the 16 bit mem card itself is seated correctly, has good chips, etc). The mem test program I have fails on the first test of that memory. This test writes "0"s to each byte, then reads them back to verify that they are really "0"s. They weren't. They were things like "0x01", "0xfd", etc. It was not totally random, as only about 10 or so bytes seemed to show up. At first I suspected that possibly the 16 bit mem and the 32 bit mem were being mapped to the same spot. However, the Hurricane docs say that their mem is mapped to a higher spot in the mem map, thus allowing for something like 4 meg of other fast ram. - steve "clueless..." koren