larryc@hpfinote.HP.COM (Larry Chesler) (10/10/89)
I'm in the market to add an '030 accelerator to my 2000. My primary reason is to accelerate things like ray tracing. I don't have much backround on the various '030 options available. Several questions come to mind; 1. Are all '030 accelerators equal ? Are they all compatible with existing AMIGA software ? 2. The GVP A3001 comes with it's own SCSI controller, if you add this accelerator card to your system, must it also have it's own dedicated harddrive ? I currently have a GVP Qauntum 80 Meg hardcard in my system. 3. Does AMIGA software like Sculpt 4D automatically notice that you have FPU hardware in the system and use it appropriately ? Alas, perhaps the ability to use FPU hardware in the system has been compiled into the code. 4. Any info on the Ronin '030 accelerators or others. 5. How about the Commmodore '030 board, what will it contain and at what cost ? I'll appreciate any and all answers or editorial comments. Larry Chesler Hewlett Packard Colorado Integrated Circuits Division larryc@hpltbf
easton@aucis.UUCP (Jeff Easton) (10/11/89)
In article <18650001@hpfinote.HP.COM>, larryc@hpfinote.HP.COM (Larry Chesler) writes: > > I'm in the market to add an '030 accelerator to my 2000. My primary reason > is to accelerate things like ray tracing. I don't have much backround on the > various '030 options available. Several questions come to mind; [....] > > 2. The GVP A3001 comes with it's own SCSI controller, if you add > this accelerator card to your system, must it also have it's > own dedicated harddrive ? I currently have a GVP Qauntum 80 Meg > hardcard in my system. > Wrong! The GVP comes with a IDE interface for a Hard disk that has the controller on board. Quantum and Conner's sell these types of drives. The only signals on the interface connector is the data bus, R/W lines and a chip select. Its not even close to SCSI. The card has boot ROM sockets so that you can autoboot this drive. As far as I know, this drive acts like any other Amiga hard disk. Nothing special. It may DMA directly into 32 bit RAM since the interface is on the accelerator card but I'm not sure. The specs are at home. :-( I talked to the GVP people at AmiExpo/Chicago and they sent me later a 8 page technical discussion of the card. I suggest you call them and ask for it. > > Larry Chesler Jeff Easton UUCP: !mailrus!sharkey!aucis!easton Zenith Data Systems OEM Engineering
tope@enea.se (Tommy Petersson) (10/12/89)
In article <18650001@hpfinote.HP.COM> larryc@hpfinote.HP.COM (Larry Chesler) writes:
-
-I'm in the market to add an '030 accelerator to my 2000. My primary reason
-is to accelerate things like ray tracing. I don't have much backround on the
-various '030 options available. Several questions come to mind;
-
- 1. Are all '030 accelerators equal ? Are they all compatible with
- existing AMIGA software ?
-
You could say that a lot of existing games software (and some non-games)
is not compatible with anything but vanilla 68000 Amiga. Proper written
software would work on them all, but there would be a lo more of
compatibility to think of with other hardware (like memory and disk
controllers). I think it is important to have the opportunity to easy
select normal 68000 operation (I have the A2620 and you just press the
two buttons during boot), since so many programs won't work otherwise.
- 3. Does AMIGA software like Sculpt 4D automatically notice that
- you have FPU hardware in the system and use it appropriately ?
- Alas, perhaps the ability to use FPU hardware in the system
- has been compiled into the code.
-
Sculpt 4D has a special 68020 version, which can only be un on
systems with 68020 and up. This would use a FPU, as some other of the
more professional product. Most programs, though, wouldn't care a lot.
- 5. How about the Commmodore '030 board, what will it contain and
- at what cost ?
-
(The rumours that sounded most beleivable) is 68030, 68882 FPU and
2 MB 32-bit memory (MMU built-in).
tope@enea.se
Tommy P.ejkst@unix.cis.pitt.edu (Eric J. Kennedy) (10/13/89)
In article <517@aucis.UUCP> easton@aucis.UUCP (Jeff Easton) writes: > Wrong! The GVP comes with a IDE interface for a Hard disk that has >the controller on board. Quantum and Conner's sell these types of >drives. The only signals on the interface connector is the data bus, >R/W lines and a chip select. Its not even close to SCSI. My friend has this setup, with the Quantum 40 meg drive. Since the system is running a 25MHz 68030, and the controller is 32 bit (right?) and the hard drive is a Quantum, I was expecting to see incredible speed from the hard drive. Instead, the diskperf numbers are more like 450K per second. This is respectible, (lots faster than my C.Ltd.!) but hardly up to the 800K/sec that I've seen reported with, say, the HardFrame. Is there something that could speed this up, or barring that, an explanation for the relatively unimpressive speed? -- Eric Kennedy ejkst@cis.unix.pitt.edu
daveh@cbmvax.UUCP (Dave Haynie) (10/13/89)
in article <19968@unix.cis.pitt.edu>, ejkst@unix.cis.pitt.edu (Eric J. Kennedy) says: > In article <517@aucis.UUCP> easton@aucis.UUCP (Jeff Easton) writes: >> Wrong! The GVP comes with a IDE interface for a Hard disk that has >>the controller on board. > My friend has this setup, with the Quantum 40 meg drive. Since the > system is running a 25MHz 68030, and the controller is 32 bit (right?) The controller is 16 bit, non-DMA. It's bascially a PC-AT expansion bus. > Instead, the diskperf numbers are more like 450K per second. The other thing is, at least last time I checked, GVP device drivers were written in C. If you use SetCPU, and can get a CARDROM entry for the GVP ROMs (assuming they run directly from ROM and don't load that ROM code into RAM), you can boot performance a bit if you have 32 bit memory. > This is respectible, (lots faster than my C.Ltd.!) but hardly up to the > 800K/sec that I've seen reported with, say, the HardFrame. Is there > something that could speed this up, or barring that, an explanation for the > relatively unimpressive speed? The Hardframe, like the Commodore controllers, is DMA driven, and so you can get over 1 megabyte/second, though the filesystem (FFS), with the right hard drive (CDCs, not Quantums). While the PC-AT bus is in theory capable of 4 MB/s transfers, it's not clear that [A] the Quantum goes anywhere near that speed, or [B] what the GVP interface can actually achieve; it could be their interface to the AT drive is less than optimal. And it could always be software, too.... > Eric Kennedy -- 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
ejkst@unix.cis.pitt.edu (Eric J. Kennedy) (10/14/89)
In article <8182@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <19968@unix.cis.pitt.edu>, ejkst@unix.cis.pitt.edu (Eric J. Kennedy) says: [talking about GVP 68030 board with hard drive controller] >> My friend has this setup, with the Quantum 40 meg drive. Since the >> system is running a 25MHz 68030, and the controller is 32 bit (right?) >The controller is 16 bit, non-DMA. It's bascially a PC-AT expansion bus. Then why did they bother? I figured if they go to the trouble of adding a hard drive controller to the accelerator card, there would at least be some reason for it, some distinguishing characteristic. The way they've done it, you're paying for a sub-par controller that you most likely won't want if you're building a fast system. Unvelievable. -- Eric Kennedy ejkst@cis.unix.pitt.edu
theobaby@well.UUCP (Paul Theodoropoulos) (10/15/89)
I'm currently using a Ronin 030 on my A1000, at 14Mcycles. The hardware is excellent. The Ronin 030 for the A2000 supports 28Mcycles. I also have an 881 overclocked to 20Mcycles. Unlike some 030 boards, the Ronin boards support the data cache (video ram must not be cached, so most boards inhibit the Dcache, which kind of limits the value of the board). The Amiga ROM can also be mapped into 32 bit ram, which makes for a VERY fast, tight machine! The ROM math libraries automatically detect an 881/882, but optimized code (like SculptAnimate 4d) helps. ****Let's all fight against bandwidth wasting signatures!!! Paul T.***** ZZ
daveh@cbmvax.UUCP (Dave Haynie) (10/25/89)
in article <19997@unix.cis.pitt.edu>, ejkst@unix.cis.pitt.edu (Eric J. Kennedy) says: > In article <8182@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>The [GVP '030] controller is 16 bit, non-DMA. It's bascially a PC-AT >>expansion bus. > Then why did they bother? They had room left over on the '030 board, and an AT bus hard drive interface only costs a couple of dollars. This might give them an edge in selling the board, since for folks who don't yet have a hard drive controller, this lets them buy the controller and '030 accelerator in one. > I figured if they go to the trouble of adding a hard drive controller to > the accelerator card, there would at least be some reason for it, some > distinguishing characteristic. They're distinguishing the '030 board, not the controller. Commodore chose to distinguish their board by providing built-in 32 bit memory, but that's not the way to make a bargain-basement '030 board. > The way they've done it, you're paying for a sub-par controller that you > most likely won't want if you're building a fast system. Unvelievable. IF you can find an imbedded AT drive with decent performance, it's likely that this drive could be as fast as the SCSI controller GVP makes for the Amiga bus, though not likely as fast as a good DMA controller. It's certainly faster than the simple 8-bit SCSI controllers you can get cheap these days, so I'd guess this would be somewhere in the "medium-performance" category. Though it's a hard call; the AT bus characteristic is only 1/2 the question -- their interface between that '030 and the AT bus could be a big factor. > Eric Kennedy > ejkst@cis.unix.pitt.edu -- 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
daveh@cbmvax.UUCP (Dave Haynie) (10/25/89)
in article <14108@well.UUCP>, theobaby@well.UUCP (Paul Theodoropoulos) says: > I'm currently using a Ronin 030 on my A1000, at 14Mcycles. The hardware is > excellent. The Ronin 030 for the A2000 supports 28Mcycles. I also have an > 881 overclocked to 20Mcycles. Unlike some 030 boards, the Ronin boards > support the data cache (video ram must not be cached, so most boards inhibit > the Dcache, which kind of limits the value of the board). If this new Ronin board is like the Ronin "020 board converted to 030 board", it's not quite up to par with the other '030 boards (GVP and Commodore) in the way it handles the data cache. Ronin's previous board controlled the data cache in software only, via an MMU table. This allowed data caching of the Ronin 32 bit memory only. All other memory in the system was uncached. This has two problems. First of all, requiring an MMU table of any kind is going to waste some memory. Secondly, without any hardware control of data caching, you have to have multiple tables for different data spaces, so that caching can be on for instruction space, off for data space. That at least doubles the size of the MMU table required. Both the Commodore and GVP boards control caching in Hardware. Since I designed the '030 board for Commodore, I can tell exactly what it does -- the GVP board is apparently doing a similar thing. The A2630 hardware inhibits the data cache for chip memory, I/O registers, and the I/O section of expansion memory. It also generates port wide reads for cachable areas of Amiga memory, so that the data cache can operate on $00C00000, ROM, and normal expansion memory. This solves most of the data caching problems based on Amiga system problems. DMA devices need to have a cache dump instruction incorporated in their device driver to properly maintain cache consistency in conjunction with the data cache. And MMU tables can still be used for finer control of the MMU table to support ROM mapping (of the system ROM or and device driver ROMs) or unusual device that don't follow the normal memory-I/O space assignments of the expansion bus (like the bridge card). The SetCPU program manages all of these extras, and should work with any '030 card. -- 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
theobaby@well.UUCP (Paul Theodoropoulos) (10/29/89)
Dave Haynie of C-A writes [regarding the Ronin 030 board] -
>First of all, an MMU table of any kind is going to waste some memory.
Well, i suppose so, though i can't imagine too many folks with 030 systems
having memory constraints so severe that they can't afford a coupla dozen
kilobytes for some page tables.
Secondly, can you explain why the Ronin board tends to do better on almost
all benchmarks against other, equivalently clocked 030 systems (such as the
Commodore 030)? Seems to me that that vindicates their use of software
memory control.
*****Stamp out bandwitdth wasting signatures! Paul Theodoropoulos*****daveh@cbmvax.UUCP (Dave Haynie) (10/31/89)
in article <14325@well.UUCP>, theobaby@well.UUCP (Paul Theodoropoulos) says: > Dave Haynie of C-A writes [regarding the Ronin 030 board] - >>First of all, an MMU table of any kind is going to waste some memory. > Well, i suppose so, though i can't imagine too many folks with 030 systems > having memory constraints so severe that they can't afford a coupla dozen > kilobytes for some page tables. No problem there. Only, the software only method Ronin uses doesn't allow caching of 16 bit RAM. If you're only using 32 bit RAM, that may not be a problem, but it's certainly a disadvantage. Plus, the software-only method will either result in lower performance or more memory wasted on tables than a hardware/software combination. Because you need separate tables for I and D cache inhibit if you're software-only, or you end up inhibiting the I-cache were it's totally unnecessary to do so (in CHIP RAM, expansion RAM, etc). This is a complaint, not the end of the world. > Secondly, can you explain why the Ronin board tends to do better on almost > all benchmarks against other, equivalently clocked 030 systems (such as the > Commodore 030)? Probably because it doesn't. First of all, the Ronin '030 hasn't been compared to the Commodore '030, at least anywhere I've seen. None of the magazines have a Commodore '030 board, and I sure don't have a Ronin '030 board. The Ronin board does use a 28MHz clock, rather than the 25MHz clock used by Commodore and GVP. I think both Commodore and GVP designs work just fine at 28MHz (I run my office board at 28MHz) without changing anything but the CPU (Motorola CPUs come in 16.667MHz, 20.000MHz, 25.000MHz, 33.3333MHz, 40.000MHz, and 50.000MHz speeds -- running a 25MHz part at 28MHz, while you might get away with it most of the time, is "asking for it"). > Seems to me that that vindicates their use of software memory control. No. All software memory control does for you is simplify hardware design by a very small amount, and of course _require_ the use of the software. The use of an MMU will in fact slow the system slightly, since every time that CPU hits a page that's not in the ATC (22 fully associative entries in the '030), the MMU has to go out and find the new page. So to the purist at least, the software only method is guaranteed to be slower than the hardware only menthods. In reality, you probably won't notice the difference, especially if you use short trees in your MMU software -- SetCPU tables never get more than two levels deep, and the second level is only for supporting expansion ROM translations (since expansion ROMs are small). And of course, software is software -- any benefit available on a Ronin board under software control is available on a Commodore or GVP board. Like I said, I don't think there's been a real comparison of real '030 boards. I know some of the magazines are waiting for Ronin and Commodore boards to do just such a comparison. But whatever the results, be assured that you can look elsewhere to explain any performance differences (the 32 bit memory system is always the first place to look). > *****Stamp out bandwitdth wasting signatures! Paul Theodoropoulos***** -- 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
theobaby@well.UUCP (Paul Theodoropoulos) (11/02/89)
Dave, true - no 030 comparisons published yet....i mistakenly pointed to data
from 020 board performance comparisons previously published, which did in fact
show the Ronin board to be somewhat superior in performance. mea culpa.
I do not see that address translation will incur any performance penalty
worth mentioning. The 030 supports 2 clk cycle accesses to physical address
space, while addresses are translated in parallel with D and I cache accesses,
if they are in the ATC. Only in the most demanding CPU core intensive situations will the MMU incur a performance overhead, and even then, i believe it would be minimal (time for me to RTFM!)
>>>>Pummel bandwidth wasting signatures!! Paul Theodoropoulos, theobaby@Well<<<daveh@cbmvax.UUCP (Dave Haynie) (11/03/89)
in article <14405@well.UUCP>, theobaby@well.UUCP (Paul Theodoropoulos) says: > Dave, true - no 030 comparisons published yet....i mistakenly pointed to data > from 020 board performance comparisons previously published, which did in fact > show the Ronin board to be somewhat superior in performance. mea culpa. Yup. The Ronin memory for their '020 board runs 1 wait-state faster than the A2620 memory, due to the A2620's MMU. Clock speeds were the same. > I do not see that address translation will incur any performance penalty > worth mentioning. Yeah, like I said, the only performance hit at all is an ATC miss. Nothing you're likely to be able to measure, but if you're counting every cycle, it is a performance hit. Microcoded tree walks certainly are a good idea. > The 030 supports 2 clk cycle accesses to physical address space, while addresses > are translated in parallel with D and I cache accesses, if they are in the ATC. I though that was impressive, but of course, with the logical caches, you either need a translation or a cache hit, never both. The '040 has physical caches and still manages to run without a slowdown. Of course, in both cases, you can identify the cache line without any translations, since the cache size is always smaller than the MMU's page size. >>>>>Pummel bandwidth wasting signatures!! Paul Theodoropoulos, theobaby@Well<<< -- 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
brant@alberta.uucp (Brant Coghlan) (11/04/89)
Have you heard about the latest oh thirty expanson for the A1000 and A500? The soon to be released Infinity Machine by M.A.S.T. is an inexpensive accelerator and more. MAST claims the board will support SCSI, 8Megs of 16 or 32 bit RAM, a 68K running at 7 or 16Mhz, a '030 at up to 50Mhz, and a 68881/2. This board is not a real speed deamon but a feature freek. Since this board is a RSN product, are their any Beta testers on the net? Does this board really work? How does it compare to the other '030 boards? I have asked MAST for info on their board and I'll post the details if anyone is interested. -Brant I am not affiliated with MAST except as a potenital buyer of their products -- Brant Coghlan (career student) (403) 487-3619 ...!alberta!brant Dept. of Comp. Science, 615 GSB, U of Alberta, Edmonton, Alberta, Canada