CHIP RAM speed test results
Kari-Pekka Koljonen
conversions I decided to time some values myself.
Machine used: A1200/030/28MHz, all caches & bursts on. Both tests took
over the system and disabled all interrupts, fmode was %11.
Test 1: 320x256x8 screen
------------------------
Copy $14000 bytes (screenful) of data from fast to chip using the following
routine:
loop:
rept 8
move.l (a0)+,(a1)+
endr
dbf d0,loop
Time: 336 rasterlines = 21.5 ms (50Hz=20ms=one frame=312 rasterlines, I think)
Test 2: 320x256x5 screen
------------------------
Copy $c800 bytes, otherwise the same as above.
Time: 196 rasterlines = 12.6 ms
So if all Amigas have about the same chip ram speed it's impossible to do a
50Hz 320x256x8 chunky to planar screen, even if you had a 060/80MHz.
***************************************************
K-P Koljonen / Hippopotamus Design / iNSANE
k...@direktor.voima.jkl.fi, kpko...@freenet.hut.fi
http://direktor.voima.jkl.fi/~kp K-P@IRC
***************************************************
Ludvig Pedersen
>conversions I decided to time some values myself.
>Machine used: A1200/030/28MHz, all caches & bursts on. Both tests took
>over the system and disabled all interrupts, fmode was %11.
>Test 1: 320x256x8 screen
>------------------------
>Copy $14000 bytes (screenful) of data from fast to chip using the following
>routine:
>loop:
> rept 8
> move.l (a0)+,(a1)+
> endr
> dbf d0,loop
>Time: 336 rasterlines = 21.5 ms (50Hz=20ms=one frame=312 rasterlines, I
>think)
>Test 2: 320x256x5 screen
>------------------------
>Copy $c800 bytes, otherwise the same as above.
>Time: 196 rasterlines = 12.6 ms
>So if all Amigas have about the same chip ram speed it's impossible to do a
>50Hz 320x256x8 chunky to planar screen, even if you had a 060/80MHz.
You are using a *slow* loop, my 2 pass c2p is actually faster than your copy.
:-)
Use this:
.loop:
move.l (a0)+,d0
move.l d0,(a1)+
dbra d7,.loop
and see if the speed improves! (Was faster on my 030/50mhz)
BTW:
It is possible to do 1x1 fullscreen c2p on a 040 with a scrambled buffer
50 fps, but then you don't have any time left for rendering! :-/
The only reason why c2p is for free is because chipram is so damn slow! :((
<sb>Ludde - Amiga Demo Coder
<sb>Virtual Reality & Official Be developer
<sb>lud...@ifi.uio.no
Aki Laukkanen
>So if all Amigas have about the same chip ram speed it's impossible to do a
>50Hz 320x256x8 chunky to planar screen, even if you had a 060/80MHz.
Ah, but it isn't the same for all Amigas. It's just your (and mine :) Viper
which has a poor access speed to CHIP ram.
--
Daeron
"You wouldn't dare say that if I had my writers here!" -- Jack Benny
Jyrki Saarinen
> Well maybe someone with 040 or 060 could give it a try. I remember
> reading that TextMap-engine by John Hendrikx gave really bad frame
> rates even on 060, just because of the slow chip bus.
No but because it has CPU-only chunky2planar (version 5.7)
which is optimized for the 68020 and the 68030, and it is SLOWER
on the 68040 and the 68060 than a routine made for them which
does chunky2planar completely free.
-- _
a Stellar programmer _ //
"Amiga - back for the future" \X/
Marcus Alanen
> conversions I decided to time some values myself.
> rept 8
> move.l (a0)+,(a1)+
> endr
> dbf d0,loop
What's that rept command? Can I use with Genim2? Or is it a macro?
> So if all Amigas have about the same chip ram speed it's impossible to
> do a 50Hz 320x256x8 chunky to planar screen, even if you had a
> 060/80MHz.
How about a graphics card? I've no idea how fast they are, but
faster than chip mem anyway...
Marcus Alanen
marcus...@tna.nullnet.fi
Kari-Pekka Koljonen
>ChipRAM is the same speed, but chip bus bandwidth is not. Try the following
>code:
>loop:
> movem.l (a0)+,d3-d7/a2-a5
> movem.l d3-d7/a2-a5,(a1)
> lea 32(a1),a1
> dbf d0,loop
>If that's not faster then your accelerator card has a lousy bus interface.
> Michael van Elst
My accelerator card does suck. Movem.l loop was SLOWER than move.l loop.
Here're the busspeedtest results for everyone to laugh at:
BusSpeedTest 0.07 (mlelstv) Buffer: 16384 Bytes
==================================================
loop overhead: 7.9ns
register move: 72.6ns
memtype op cycle bandwidth
fast readw 182.0ns 11.0MByte/s
fast readl 216.5ns 18.5MByte/s
fast readm 243.9ns 16.4MByte/s
fast writew 216.1ns 9.3MByte/s
fast writel 217.5ns 18.4MByte/s
fast writem 198.6ns 20.1MByte/s
chip readw 1065.0ns 1.9MByte/s
chip readl 1066.6ns 3.8MByte/s
chip readm 1097.3ns 3.6MByte/s
chip writew 1061.8ns 1.9MByte/s
chip writel 1064.1ns 3.8MByte/s
chip writem 1064.1ns 3.8MByte/s
rom readw 328.3ns 6.1MByte/s
rom readl 511.0ns 7.8MByte/s
rom readm 488.3ns 8.2MByte/s
Jyrki Saarinen
> We did some speed test on an Amiga 4000/60:
>
> C2P (normal AGA) was about 5.5 Mb/s.
>
> Copying to Cybervision 64 (Buster 11) about 11 mb/s.
>
> Copying to Piccolo about 7-8 Mb/s.
Luckily this new Amiga "Walker" has two CPU local busses,
for possible graphics cards. A decent bandwidth can be
achieved..
Fabio Bizzetti
>> We did some speed test on an Amiga 4000/60:
>>
>> C2P (normal AGA) was about 5.5 Mb/s.
>>
>> Copying to Cybervision 64 (Buster 11) about 11 mb/s.
>>
>> Copying to Piccolo about 7-8 Mb/s.
>Luckily this new Amiga "Walker" has two CPU local busses,
>for possible graphics cards. A decent bandwidth can be
>achieved..
It would be much more wise to have dual port chipram, to write directly
(also bytes if needed) into chipram with no wait-states.
>-- _
>a Stellar programmer _ //
>"Amiga - back for the future" \X/
------------------------------------------------------------------------------
| |
| Stop that fucking imperialist embargo against Cuba. |
| Hasta Siempre Comandante Che Guevara. |
| |
| |
| Fabio "Maverick" Bizzetti - bizz...@mbox.vol.it - Maverick* at IRC |
| The maker of "CyberMan" and "Virtual Karting" |
| working on "Virtual Rally" and "StarFighter", the 3D game that will |
| bring the Amiga to the top |
| |
------------------------------------------------------------------------------
Michael van Elst
>It would be much more wise to have dual port chipram, to write directly
>(also bytes if needed) into chipram with no wait-states.
There is no dual port RAM with no waitstates. If neither side
is slowed down this is because the RAM had to be double speed.
But if it is double speed you don't need a dual port RAM but
just multiplex the bus (just like current chip ram).
Regards,
--
Michael van Elst
Internet: mle...@serpens.rhein.de
"A potential Snark may lurk in every tree."
Fabio Bizzetti
>bizz...@mbox.vol.it (Fabio Bizzetti) writes:
>>It would be much more wise to have dual port chipram, to write directly
>>(also bytes if needed) into chipram with no wait-states.
>There is no dual port RAM with no waitstates.
It's not "all or nothing". Using the same chips speed, but having dual access
would already mean to avoid the syncronization with 7Mhz chipram bus clock.
And, whatever is the amount of DMA activity, the CPU wouldn't be slowed down.
>If neither side is slowed down this is because the RAM had to be double speed.
The ram is ok, it's Alice that runs the chipram bus at 7Mhz.
>But if it is double speed you don't need a dual port RAM but
>just multiplex the bus (just like current chip ram).
Let's do also this way.. any way is good to improve the current speed.
It seems that Escom/AT considers the actual AGA chipset as perfect, or anyway
"adequate". That's why the Amiga games market doesn't exist anymore.
>Regards,
>--
> Michael van Elst
>Internet: mle...@serpens.rhein.de
> "A potential Snark may lurk in every tree."
------------------------------------------------------------------------------
Michael van Elst
>It's not "all or nothing". Using the same chips speed, but having dual access
>would already mean to avoid the syncronization with 7Mhz chipram bus clock.
>And, whatever is the amount of DMA activity, the CPU wouldn't be slowed down.
Obviously this is not true. Since RAM of a given speed just allows
that many accesses per second you will have to slow down accesses.
It is clear that you can do better than current 7MHz chip RAM but
that's because RAM is faster nowadays.
Most "dual port RAM" is just a multiplexed RAM anyway. There are only
very few chips that really have two data paths to the RAM cells and
these are low capacity high speed chips. Nothing you would want to
make video memory from.
>The ram is ok, it's Alice that runs the chipram bus at 7Mhz.
Yes. That's why "dual ported RAM" is nonsense. We already have
"dual port RAM", just the multiplexing is done outside the chip.
>It seems that Escom/AT considers the actual AGA chipset as perfect, or anyway
>"adequate". That's why the Amiga games market doesn't exist anymore.
Modern games do not need smart chipsets. They need geometry engines,
texture mapping and a fast chunky framebuffer. I.e. a Pentium and
PCI graphics board.
Juergen Rally Fischer
In article <2095.6655...@mbox.vol.it>,
bizz...@mbox.vol.it (Fabio Bizzetti) writes:
|> >But if it is double speed you don't need a dual port RAM but
|> >just multiplex the bus (just like current chip ram).
I guess dual ported ram is more expensive than double-speed ram ?
|>
|> Let's do also this way.. any way is good to improve the current speed.
yes.
|>
|> It seems that Escom/AT considers the actual AGA chipset as perfect, or anyway
|> "adequate". That's why the Amiga games market doesn't exist anymore.
|>
IMHO it would be quite easy for a new A1200 board to give lot more
performance with unchanged AGA chipset. Burning new chipsets seems to
be a expensive thing. My point is not that I don't like to see AGA+
but I like to see a updated A1200 board NOW.
features:
faster chipmemacess. should be no real problem to implement.
chipwrite buffer like on A3000. speeds up many loops a lot
(free cycles even when doing fastmem acess!)
and finaly, if a single person can make a donlge that makes
AGA go scrambled chunky (grafitti), maybe a computer company
can throw together some TTLs to get linear chunky up to SHRES ?
Maybe copper would have to cause a cpu interrupt to switch
dongle for vports.
faster cpu as well, would it be difficult to offer multiple
models from EC030-25 up to MMU030-50 with same board ?
------------------------------------------------------------------------
fisc...@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:)
Jonathan Belson
: bizz...@mbox.vol.it (Fabio Bizzetti) writes:
:
: >It would be much more wise to have dual port chipram, to write directly
: >(also bytes if needed) into chipram with no wait-states.
:
: is slowed down this is because the RAM had to be double speed.
: just multiplex the bus (just like current chip ram).
Doesn't VRAM fall into the dual-port catagory?
C-YA
Jon
Michael van Elst
> It seen to be 'very' hard, at least was for CBM... They love to
> save a few penies for not including a socket.
They love to save a few more dollars for having a much higher
production yield and they love to save a few more dollars to reduce
production cost.
> I would have loved to buy a 50mhz 030 and pop it in my A3000,
Oh, and now you would also love to pay for the motherboard that
equally support 50MHz operation and you love to let everyone
pay for it who buy a 25MHz model.
Michael van Elst
>Doesn't VRAM fall into the dual-port catagory?
Sort of. But even there you just multiplex the RAM cells.
Transferring data to the second port will steal cycles from
the other port.
The problem with VRAM and the custom chips is that the second
VRAM port just allows a few access modes with low overhead because
it is just a shift register. Interleaved access to bitplanes,
as done by the Amiga chipset is not a supported access mode.
Regards,
Stephan Schaem
: faster cpu as well, would it be difficult to offer multiple
: models from EC030-25 up to MMU030-50 with same board ?
It seen to be 'very' hard, at least was for CBM... They love to
save a few penies for not including a socket.
I would have loved to buy a 50mhz 030 and pop it in my A3000, alot
less expansive that a 25mhz 040 board that would be slower in some
respect since the A3000 is made for 030 not 040 bus timing.
Also having the a socket VS a 68882 in my A3000 wouldn't have bothered
me, I paied for it and dont really use it.
If you look closely there is many little thing that show that CBM
wanted to please third party HW developer and resealer shop. They
forgot about the actual user.
Stephan
Fabio Bizzetti
>bizz...@mbox.vol.it (Fabio Bizzetti) writes:
>>It's not "all or nothing". Using the same chips speed, but having dual
>>access would already mean to avoid the syncronization with 7Mhz chipram bus
>>clock. And, whatever is the amount of DMA activity, the CPU wouldn't be
>>slowed down.
>Obviously this is not true. Since RAM of a given speed just allows
>that many accesses per second you will have to slow down accesses.
As far as I recall my A1200 chipram is 80ns; while it's exploited as if it was
only 140ns. The rest of ns is wasted because Alice holds control of everything,
and Alice is slower than the CPU.
Since you didn't get what I meant last time, I'll try to explain my thought
better: if you put 10ns ram in your 68030 board, it doesn't mean that it will
be exploited as 10ns. It will be exploited as your ram controller allows, 60ns
or 70ns commonly. Well, the chips inside my A1200 ("chipram") are much faster
than they're supposed to be, but Alice brakes the CPU to gain from this speed
because in fact Alice is chipram's controller.
>It is clear that you can do better than current 7MHz chip RAM but
>that's because RAM is faster nowadays.
It would be sufficient to modify the interface CPU <->chipram<-> Alice.
>Yes. That's why "dual ported RAM" is nonsense.
Come on.. I didn't mean to simply change the chips!!!!
There must be a circuit to exploit the new chips' nature, and getting a fast
SIMM and multiplexing data is perfectly fine, allowing practical dual access,
but (perhaps) could be more complicated at the end than real dual access ram
(ofcourse with the circuit to use it).
Maybe the "ram controller" that you wish (to multiplex data) would be more
expensive than 2Mb of real dual access ram, this is to be examinated.
The implementation is is not our problem though: we know it can be done, then
if a solution is cheaper than another, it doesn't change the final result.
Everything is good to improve performances, and AGA has already a very good
22Mb/sec bandwidth to RGB, giving another 22mb/sec CPU-chipram would be *nice*.
A bit useless if the CPU is slow of course, but a 40Mhz/50Mhz 68030 (finally
standard) is well worth of these 22mb/sec.
> We already have "dual port RAM", just the multiplexing is done outside the
> chip.
This is the problem: it's performed by the 7Mhz (bus clock) of Alice.
AGA is really nothing newer than OCS, the differences are more apparent
(palette, 8bitplanes) than physical (just 32bit interface implementation
and fastpage modes).
AGA can be improved a lot though, the AgaEXTENDER would make it (visually)
better than any SVGA out there (at least for games and Video/MultiMedia
applications), and having (still not needing to modify the chipset) a dual
access ram (any kind, any solution: it has only to "work" ;) ), syncronous
(to semplify the circuit) 24Mb/sec (22Mb/sec is due to vertical blank, but
the limit is 24Mb/sec: well, the AgaEXTEDER doesn't lose these 2Mb, that are
available for audio) would make the AGA *great*.
IMO, instead of 2+4Mb (Walker) it would be much better 2+2Mb, but with an
access speed in chipram of 24Mb/sec. Ofcourse, 2+4Mb would be still better O:)
Just think, 24Mb/sec is nearly the speed of FastRam: you would avoid the
fastram->chipram copy and draw directly in chipram, you would avoid c2p
(thanks to the AgaEXTENDER), it would allow to use 2 byteplanes (or 1 word)
for texturemapping+shading effects, the AgaEXTENDER would allow a lot of great
effects for free (zoom, flip, 4 playfields, hardware handled parallax, hardware
scroll, YUV conversion, antialiasing, any mode/resolution programmable,HiRes
copper, great audio).
AT could sell this solution as single, to SetTopBox / MultiMedia companies,
thus financing the Amiga indirectly.
>>It seems that Escom/AT considers the actual AGA chipset as perfect, or
>>anyway "adequate". That's why the Amiga games market doesn't exist anymore.
>Modern games do not need smart chipsets.
Please believe who (probably) made more games than you: what you said is wrong.
> They need geometry engines,
A skilled assembly programmer can avoid multiplications/divisions and all
these things that normal programmers learn from standard books.
If AT wanna give me voice, allowing the AgaEXTENDER for A1200 and also new
chipmem interface for the Walker, I'll give publicly all the 3D tricks you'll
see in my next demo (for StarFighter and VirtualRally), allowing all the
skilled Amiga coders to exploit the AgaEXTENDER and the 68030 to the limit.
It would mean to blow the PC away.
>texture mapping and a fast chunky framebuffer.
Yes, but dont forget that it's not so important for games, when i.e. AB3D-II
(not talking about BreathLess..) are so slow and bad thought (also if
optimized), where having the best SVGA card would make them faster of 5%-15%
max.
>I.e. a Pentium and PCI graphics board.
They cost a lot, the PCI GfxBoard isn't flexible (it gains all from Pentium's
MIPS, that are quite more than Walkers' ones), the 3D cards *still dont exist*,
they will cost a lot and they aren't flexible (read: only textmap polygons,
a bit wasting of money for a general purpose and versatile *computer*).
>--
> Michael van Elst
>Internet: mle...@serpens.rhein.de
> "A potential Snark may lurk in every tree."
Regards.
/-----------------------------------------------------------------------\
| Fabio "Maverick" Bizzetti - bizz...@mbox.vol.it - Maverick* at IRC |
| The maker of "CyberMan" and "Virtual Karting" |
| working on "VirtualRally" & "StarFighter" |
\-----------------------------------------------------------------------/
PS: will I win the "shortest signature of the year" prize this time? ;)
Stephan Schaem
: > It seen to be 'very' hard, at least was for CBM... They love to
: > save a few penies for not including a socket.
: They love to save a few more dollars for having a much higher
: production yield and they love to save a few more dollars to reduce
: production cost.
: > I would have loved to buy a 50mhz 030 and pop it in my A3000,
: Oh, and now you would also love to pay for the motherboard that
: equally support 50MHz operation and you love to let everyone
: pay for it who buy a 25MHz model.
I payed near 3000$ for my A3000, is it that much to have a socket
and cpu clock?
BTW, if you forgot CBM made a 16mhz A3000, how much diferent is the
motherboard from the 25mhz version?
Stephan
Michael van Elst
> I payed near 3000$ for my A3000, is it that much to have a socket
> and cpu clock?
Yes, because "a CPU clock" is not what you want.
> BTW, if you forgot CBM made a 16mhz A3000, how much diferent is the
> motherboard from the 25mhz version?
There is no difference. The board supports 16MHz and 25MHz operation.
Regards,
Stephan Schaem
: > I payed near 3000$ for my A3000, is it that much to have a socket
: > and cpu clock?
: Yes, because "a CPU clock" is not what you want.
: > BTW, if you forgot CBM made a 16mhz A3000, how much diferent is the
: > motherboard from the 25mhz version?
: There is no difference. The board supports 16MHz and 25MHz operation.
I think there was a significant price diference betwen the 25mhz and
16mhz version... Would have been nice that the 16mhz offer socket, and
optionaly a 68882.
I guess I was just thinking of the simplicity of upgrading in the PC world.
move a jumper, change the chip and you go from a 75mhz cpu to 150mhz, even
so all motherboard operation stay at 50,25mhz. But what I say hold true
if I had a 16mhz A3000 :)
So no 'DX2' type 68030 for easy upgrade?
Stephan
Michael van Elst
>: There is no difference. The board supports 16MHz and 25MHz operation.
> I think there was a significant price diference betwen the 25mhz and
> 16mhz version... Would have been nice that the 16mhz offer socket, and
> optionaly a 68882.
It offered a 68881 standard.
> I guess I was just thinking of the simplicity of upgrading in the PC world.
> move a jumper, change the chip and you go from a 75mhz cpu to 150mhz,
Well, this is a) the exception, b) a waste because the 75MHz board
will still run slow.
> So no 'DX2' type 68030 for easy upgrade?
There is no DX2 type for easy upgrade and with a 030 it wouldn't do any
good. You need a big on-chip cache to get at least a tiny bit of extra
performance.
Michael van Elst
>It would be sufficient to modify the interface CPU <->chipram<-> Alice.
You say as if this were easy.
>>Yes. That's why "dual ported RAM" is nonsense.
>Come on.. I didn't mean to simply change the chips!!!!
>There must be a circuit to exploit the new chips' nature, and getting a fast
>SIMM and multiplexing data is perfectly fine, allowing practical dual access,
>but (perhaps) could be more complicated at the end than real dual access ram
>(ofcourse with the circuit to use it).
I am just talking about that. Real "dual ported RAMs" just exist in tiny
sizes, they are used for communication between several CPUs or as
register banks. Then there are chips that are just multiplexed RAMs with
the multiplexer inside. Still small and still very expensive and
effectively the same as standard RAM on a multiplexed bus. And then
there is the variety of VRAM that is just usuable for special applications.
It still is multiplexed but one side uses a very wide bus so that
multiplexing overhead is neglible if you can use the ~1024bit word.
So, except for the true dual ported RAMs there is no real advantage for
our application. What you really want is just a RAM controller that is
as fast as todays RAM chips.
>Maybe the "ram controller" that you wish (to multiplex data) would be more
>expensive than 2Mb of real dual access ram,
The RAM controller is called Alice. You would need a version that runs
faster, at least on the memory bus. And no, 2kbyte of real dual ported
RAM is more expensive than the current Alice. These chips are made of
fast static RAM. Think about building main memory of cache RAMs and then
double the price.
>Everything is good to improve performances, and AGA has already a very good
>22Mb/sec bandwidth to RGB, giving another 22mb/sec CPU-chipram would be *nice*.
Oh, a state-of-the-art video controller that reads 200MByte/s and leaves
60MByte/s for the CPU is even nicer.
>> We already have "dual port RAM", just the multiplexing is done outside the
>> chip.
>This is the problem: it's performed by the 7Mhz (bus clock) of Alice.
Yes, that's why you want a much faster graphics controller.
>AGA can be improved a lot though,
Hah. Could you afford to improve AGA ? The fact that something is
theoretically possible doesn't mean that it is feasible.
>> They need geometry engines,
>A skilled assembly programmer can avoid multiplications/divisions and all
>these things that normal programmers learn from standard books.
You mean those books that show how to write efficient rendering routines
too ?
>It would mean to blow the PC away.
It just means that you know more about c0d1ng than about hardware.
>They cost a lot, the PCI GfxBoard isn't flexible (it gains all from Pentium's
>MIPS, that are quite more than Walkers' ones)
The PCI board is much more flexible _because_ it gains all from the
Pentium's speed. With a custom chipset like AGA you are more or less
stuck with 5-10 year old technology.
Stephan Schaem
: >: There is no difference. The board supports 16MHz and 25MHz operation.
: > I think there was a significant price diference betwen the 25mhz and
: > 16mhz version... Would have been nice that the 16mhz offer socket, and
: > optionaly a 68882.
: It offered a 68881 standard.
I think a plain socket would have been better.... at least it would give
a choice of: x81, x82 or nothing. I would have choosen nothing, and be
glad to pay for the socket so I could upgrade if I needed to.
: > I guess I was just thinking of the simplicity of upgrading in the PC world.
: > move a jumper, change the chip and you go from a 75mhz cpu to 150mhz,
: Well, this is a) the exception, b) a waste because the 75MHz board
: will still run slow.
The board will run with the same bus clock, so? its not like because
you have a double speed CPU that you can double the speed of your
ram and device sitting on the bus.
: > So no 'DX2' type 68030 for easy upgrade?
: There is no DX2 type for easy upgrade and with a 030 it wouldn't do any
: good. You need a big on-chip cache to get at least a tiny bit of extra
: performance.
Does it really make a diference for a 030 to have a 50mhz bus clock?
25mhz sound even high to me for a chip like the 68030.
How would a 25mhz 030 with a /2 (12mhz) bus clock perform
with 0 waitstate memory compare to 030 design in your A3000?
Stephan
Stephan Schaem
: > They need geometry engines,
: A skilled assembly programmer can avoid multiplications/divisions and all
: these things that normal programmers learn from standard books.
You just discredited yourself by this comment...
On the side: on pentium PC people use float, mul take 1 cycle.
I'm not sure, but I heard it also take 1 cycle to convert from float to int.
: It would mean to blow the PC away.
.... a bit earlyer in the post:
: A bit useless if the CPU is slow of course, but a 40Mhz/50Mhz 68030 (finally
: standard) is well worth of these 22mb/sec.
22meg video bandwidth and 20mhz 030 will be very far from even beying PC
lowend when it comes out...
: >texture mapping and a fast chunky framebuffer.
: Yes, but dont forget that it's not so important for games, when i.e. AB3D-II
: (not talking about BreathLess..) are so slow and bad thought (also if
: optimized), where having the best SVGA card would make them faster of 5%-15%
: max.
geometrie engine, 3d primitive rendering, fast frame buffer will make games
like quake run great in true color with even very slow CPU like a 386.
If the 3d primitives support color masking nothing stop you from using
it for any 2d type game. 100,000 polygon second mean: 100,000 arbritarie
rotated/scaled true color sprites... You would build tiled based scroller
with those primitive... anyway this replace the sprite HW found in the fm
towns for example, no need for linkable sprites.
With a geometrie engine + all the rest, doing very elaborate scrolling game
would be a breeze.
: >I.e. a Pentium and PCI graphics board.
: They cost a lot, the PCI GfxBoard isn't flexible (it gains all from Pentium's
: MIPS, that are quite more than Walkers' ones), the 3D cards *still dont exist*,
: they will cost a lot and they aren't flexible (read: only textmap polygons,
: a bit wasting of money for a general purpose and versatile *computer*).
If you dont know the PC market dont try to judge it:
You can build for ~1000$ a loaded PCI pentium system, with ~500meg meg video
bandwidth to its 220mhz ramdac and 100+meg second bandwidth to main
memory, the gfx processor in HW support a broad range of 2d primitive
and HW 3d primitive support Z buffer mode, blitter can do pixel type
conversion, blit 8-32 bit pixel including YUV from local video memory
or memory to video and do interpolated scaling, local video bus connector
on the video card, upto 8meg of local wram (wram also include special
functionality to accelrate blitter functions) , 16meg of 60ns
64bit fast page memory upgradable to 128meg, 256 of 8ns pipeline
burst L2 cache (upto 512k), motherboard with high performance ports,
support for 25-33mhz PCI bus and 75-200mhz cpu clock, etc... etc... etc..
If your unhappy with the local fastmode eide controler, you can get for
145$ a risc controler based scsi3 ultra fast PCI card that can deliver
20meg second to/from local mem.
Need faster processing, swap the CPU, bigger res, hi refresh 1280x1024
24bit HW double buffered , add ram to the video card... etc...
The most expansive item (not included here) is a good monitor...
Stephan
Michael van Elst
> The board will run with the same bus clock, so? its not like because
> you have a double speed CPU that you can double the speed of your
> ram and device sitting on the bus.
Right. And a 150MHz CPU in a 75MHz board running a 25MHz bus clock
is a waste.
>: There is no DX2 type for easy upgrade and with a 030 it wouldn't do any
>: good. You need a big on-chip cache to get at least a tiny bit of extra
>: performance.
> Does it really make a diference for a 030 to have a 50mhz bus clock?
A 030 with zero-wait memory spends about 50% of the time on the bus in
average programs. That's why you can safely add a few waitstates without
reducing the performance significantly. Now, the A3000 memory already
has waitstates that are ok for 25MHz operation. A 50MHz 030 obviously
needs twice the memory speed and since you cannot simply make the
motherboard faster the 50MHz 030 will suffer badly.
> 25mhz sound even high to me for a chip like the 68030.
That's because you take "MHz" for a performance measure. If you talk
about data transfer speed you have to think in terms of bandwidth
(for average performance values) and latency (important for worst
cases).
> How would a 25mhz 030 with a /2 (12mhz) bus clock perform
> with 0 waitstate memory compare to 030 design in your A3000?
It would be nearly half as fast. You do not gain much if the memory
is faster than necessary (always speaking for average programs).
Regards,
Andre Weissflog
[...bla...bla...]
>
> > They need geometry engines,
>
> A skilled assembly programmer can avoid multiplications/divisions and all
> these things that normal programmers learn from standard books.
>
Interesting (ha ha).
> If AT wanna give me voice, allowing the AgaEXTENDER for A1200 and also new
> chipmem interface for the Walker, I'll give publicly all the 3D tricks you'll
> see in my next demo (for StarFighter and VirtualRally), allowing all the
> skilled Amiga coders to exploit the AgaEXTENDER and the 68030 to the limit.
>
> It would mean to blow the PC away.
>
How do you define "the PC"? The current base level PC is a Pentium 90
with at least 8MB RAM and a PCI graphics card that has mem-to-vmem
transfer rates around 50MB/sec. When it comes to 3d graphics it would be
a bit hard for a 030 machine to "blow" such a thing "away".
> >texture mapping and a fast chunky framebuffer.
>
> Yes, but dont forget that it's not so important for games, when i.e. AB3D-II
> (not talking about BreathLess..) are so slow and bad thought (also if
> optimized), where having the best SVGA card would make them faster of 5%-15%
> max.
>
A "pixel intensive" 3d game, where it takes 3..10 instructions to
render a single pixel cannot expect to get a big performance boost
only because a better SVGA card is used.
> >I.e. a Pentium and PCI graphics board.
>
> They cost a lot, the PCI GfxBoard isn't flexible (it gains all from Pentium's
PCI gfx boards are dirt cheap (around $150). At least they
are way cheaper then Amiga gfx cards.
> MIPS, that are quite more than Walkers' ones), the 3D cards *still dont exist*,
> they will cost a lot and they aren't flexible (read: only textmap polygons,
> a bit wasting of money for a general purpose and versatile *computer*).
>
First, lowcost 3d cards exist, I have a Creative Labs 3D Blaster in
my pc. Ok, it's slow as hell and I would never have *bought* it, but
that was only the first generation, but now they know what's up
and push the 2nd generation to the market.
The useability of such cards is not defined by the card itself,
but by the (software) driver system that the games are using.
If a function is not supported in hardware, it will be done
in software by the driver. Another card may offer this particular
function in hardware. The big question for the game companies
at the moment is not, which 3d hardware to support, but which
3d Game API will rule the world in 2 years [it will be Direct3D
for the Wintel world whether it sucks or not].
Conclusion: The Amiga needs PCI, and a ***driver***system*** for
3d hardware accelerators. It does NOT need yet another obscure
custom hardware. The big game companies WILL publish their games
first for the PC, then probably for other machines, but only
if the port will be cheap and easy.
Bye,
-Floh.
====//=== Andre Weissflog <fl...@mkmk.in-chemnitz.de> =======
...//..........."Spirits in the material world"............
\\//......90% of everything is crap (Sturgeon's Law)......
=\\===============================================Amiga!=
Pacarana
>>> We already have "dual port RAM", just the multiplexing is done outside the
>>> chip.
>>This is the problem: it's performed by the 7Mhz (bus clock) of Alice.
>Yes, that's why you want a much faster graphics controller.
>>AGA can be improved a lot though,
>Hah. Could you afford to improve AGA ? The fact that something is
>theoretically possible doesn't mean that it is feasible.
>>> They need geometry engines,
>>A skilled assembly programmer can avoid multiplications/divisions and all
>>these things that normal programmers learn from standard books.
>You mean those books that show how to write efficient rendering routines
>too ?
>>It would mean to blow the PC away.
>It just means that you know more about c0d1ng than about hardware.
>>They cost a lot, the PCI GfxBoard isn't flexible (it gains all from
>>Pentium's MIPS, that are quite more than Walkers' ones)
>The PCI board is much more flexible _because_ it gains all from the
>Pentium's speed. With a custom chipset like AGA you are more or less
>stuck with 5-10 year old technology.
Pacarana
chipset.
>>AGA can be improved a lot though,
>Hah. Could you afford to improve AGA ? The fact that something is
>theoretically possible doesn't mean that it is feasible.
Well, I do agree with this. AGA is just too old to be starting point for a
new custom chipset. It make it very difficult, make the price go way and maket
the new design take far too long.
>The PCI board is much more flexible _because_ it gains all from the
>Pentium's speed. With a custom chipset like AGA you are more or less
>stuck with 5-10 year old technology.
With one like AGA, but not with one finally updated fully for once. If AT is
too feeble to handle anything, won't/can't go get Amiga hardware people, then
hopefully they can succeed in liscencing out the patented features of the
Amiga. Get the top bandwidth, 3D pc card with the fanciest blitter and stick
all the Amiga specialties into it. Somehow hacking things such as the copper
into a set not designed with anything like that in mind would seem to me
to be more difficult than starting from scratch, however someone
(perhaps even connected with the former CBM engineering) seemed to think that
it was easier and possible.
Michael van Elst
>>Oh, a state-of-the-art video controller that reads 200MByte/s and leaves
>>60MByte/s for the CPU is even nicer.
> That's still less than half the performance of the non-standard M2
>chipset.
Maybe. There is no M2 chipset for sale yet and it surely doesn't cost $35.
The M2 chipset is probably dedicated to low-res games too.
Jonathan Belson
: The M2 chipset is probably dedicated to low-res games too.
I think it does 640x480 max...Edge printed the specs and a few snapshots of
real-time images.....like, Wow!
C-YA
Jon
Fabio Bizzetti
>> If AT wanna give me voice, allowing the AgaEXTENDER for A1200 and also new
>> chipmem interface for the Walker, I'll give publicly all the 3D tricks
>> you'll see in my next demo (for StarFighter and VirtualRally), allowing all
>> the skilled Amiga coders to exploit the AgaEXTENDER and the 68030 to the
>> limit.
>>
>> It would mean to blow the PC away.
>>
>with at least 8MB RAM and a PCI graphics card that has mem-to-vmem
>transfer rates around 50MB/sec.
That's a "PC".
> When it comes to 3d graphics it would be
>a bit hard for a 030 machine to "blow" such a thing "away".
What do you do with 50MB/sec of "transfer rate"? Just *transfer* animations?
Maybe from your 600K/sec CD? Or you render gfx on screen? Making with the
CPU most of the job that a video device should do.
Personally, I never said "we'll blow PC away using PC routines", I said that
making things differently and having the right (programmable) video hardware
it will be just another story than today, and yes: I meant to set the standard
in computer games. 3DO-M2 is not a computer, PC is.
>> >texture mapping and a fast chunky framebuffer.
>>
>> Yes, but dont forget that it's not so important for games, when i.e.
>> AB3D-II
>> (not talking about BreathLess..) are so slow and bad thought (also if
>> optimized), where having the best SVGA card would make them faster of
>> 5%-15% max.
>>
>A "pixel intensive" 3d game, where it takes 3..10 instructions to
>render a single pixel cannot expect to get a big performance boost
>only because a better SVGA card is used.
Agreed, as I repeat since years back.
A lot of people are convinced that stealing the SVGA board from a PC and
putting it into their 50Mhz Amiga will make it fly. Actually, it will make
it *much* slower for everything that is not Doom, where the improvements
will be ridicolous (but remember it's 100% a PC game as programming methods).
Not talking about nice (but static) WorkBench screens here.
>PCI gfx boards are dirt cheap (around $150). At least they
>are way cheaper then Amiga gfx cards.
Amiga GfxCards have nothing to do with Amiga, you know. They're again SVGA.
Of course a PCI SVGA board is better than a ZorroII SVGA board, but what's
the matter?
>> MIPS, that are quite more than Walkers' ones), the 3D cards *still dont
>> exist*, they will cost a lot and they aren't flexible (read: only textmap
>> polygons, a bit wasting of money for a general purpose and versatile
>> *computer*).
>>
>First, lowcost 3d cards exist, I have a Creative Labs 3D Blaster in
>my pc. Ok, it's slow as hell and I would never have *bought* it, but
>that was only the first generation, but now they know what's up
>and push the 2nd generation to the market.
Yeah, untill P6 comes out and we're back again.
I dont want this on the Amiga.
>The useability of such cards is not defined by the card itself,
>but by the (software) driver system that the games are using.
>If a function is not supported in hardware, it will be done
>in software by the driver. Another card may offer this particular
>function in hardware. The big question for the game companies
>at the moment is not, which 3d hardware to support, but which
>3d Game API will rule the world in 2 years [it will be Direct3D
>for the Wintel world whether it sucks or not].
Yesterday I heard the latest thing Direct3D cannot make and thus is not being
used for the coolest games. Developers are masochist to want to make 20
different versions for any gfx chip, or the whole API/realtime_games topic
is naive?
>Conclusion: The Amiga needs PCI, and a ***driver***system*** for
>3d hardware accelerators. It does NOT need yet another obscure
>custom hardware. The big game companies WILL publish their games
>first for the PC, then probably for other machines, but only
>if the port will be cheap and easy.
Too many "if"; I guess AT would run away scared in this case.
>Bye,
>-Floh.
>====//=== Andre Weissflog <fl...@mkmk.in-chemnitz.de> =======
>....//..........."Spirits in the material world"............
>\\//......90% of everything is crap (Sturgeon's Law)......
>=\\===============================================Amiga!=
/-----------------------------------------------------------------------\
Dave Haynie
>As far as I recall my A1200 chipram is 80ns; while it's exploited as if it was
>only 140ns. The rest of ns is wasted because Alice holds control of everything,
>and Alice is slower than the CPU.
You don't understand dynamic RAM. The 80ns rating on a DRAM is the row
address access time. That's usually (depending on the part and the
memory controller), the fastest that data can be accessed from that
part. However, DRAM also has a row address precharge time, which is
usually about 60-80% of the access time. So while you can access a
word in 80ns from the start of the memory cycle, you can't
continuously run random access cycles any faster than around 140ns,
for an 80ns part.
>Since you didn't get what I meant last time, I'll try to explain my thought
>better: if you put 10ns ram in your 68030 board, it doesn't mean that it will
>be exploited as 10ns. It will be exploited as your ram controller allows, 60ns
>or 70ns commonly.
Which is 100ns-120ns cycle times, commonly, for those memory speeds.
>Well, the chips inside my A1200 ("chipram") are much faster than
>they're supposed to be, but Alice brakes the CPU to gain from this
>speed because in fact Alice is chipram's controller.
Not at all. The 80ns parts on the chip bus are exactly as fast as
they're supposed to be. The constraint on speed is not the normal
access time, but the timing for Alice's burst cycles. For video fetch,
Alice runs 64-bits to Lisa every 280ns. The burst cycle timing is
fairly critical, so 100ns parts would not work here.
>>It is clear that you can do better than current 7MHz chip RAM but
>>that's because RAM is faster nowadays.
>It would be sufficient to modify the interface CPU <->chipram<-> Alice.
If Alice were designed in a modern process, and you ran the actual
chip bus timing from a 28MHz or 56MHz basis, rather than the 14MHz at
present, you could probably run four cycle bursts to Chip RAM in the
280ns window. Maybe CPU bursts too, though there's another problem
with memory access, and that's one of matching the cycle to the
CPU. It does you no good if you have data ready when the CPU can't
take it. The chip bus is a synchronous bus, and if you were to burst
four words out of it for a CPU cycle, you would either need a CPU that
perfectly aligned with the chip bus timing, or you would need a FIFO
device to store the fetched data for when CPU could take it.
>Maybe the "ram controller" that you wish (to multiplex data) would be more
>expensive than 2Mb of real dual access ram, this is to be examinated.
Real dual-ported random access memory is exotic. You usually get it in
hundred-byte chips, generally used for contention-free mailboxes in
high performance multiprocessing systems. Video RAM (VRAM) is a
special purpose dual ported RAM, and it's commonly used in graphics
systems to get the video fetch activity decoupled from the "chip
bus". The AAA system supported VRAM, but it's a rather tricky thing to
support, since the video access portion is serial, not random
access. The AAA chips used a double line-buffer scheme to get around
this, but it's not a real cheap solution. More primitive graphics
systems can limit where displays live in order to simplify the
requirements for VRAM.
However, VRAM is expensive, since it's roughly 50% larger per cell
than DRAM. There's no inherent advantage to dual porting over other
methods. The main goal in making a faster graphics system is to speed
up the aggregrate bandwidth of the system. Dual porting can double (or
more like triple) a memory's bandwidth. But if I speed memory access
other ways, like increasing the bus size, I can get the same
advantages by time multiplexing the bus. There's nothing inherently
wrong with the way the Amiga does it, it's just dealing with
technology that began life in the mid 80s.
>> We already have "dual port RAM", just the multiplexing is done outside the
>> chip.
>
>This is the problem: it's performed by the 7Mhz (bus clock) of Alice.
Alice has a 14MHz bus clock.
>Just think, 24Mb/sec
Oh by the way, "24Mb/sec" means "24 megabits per second". I think you
mean 24MB/s in all your talk here...
Dave Haynie | ex-Commodore Engineering | for DiskSalv 3 &
Sr. Systems Engineer | Hardwired Media Company | "The Deathbed Vigil"
Scala Inc., US R&D | Ki No Kawa Aikido | in...@iam.com
"Feeling ... Pretty ... Psyched" -R.E.M.
Gregory Hull
: You can build for ~1000$ a loaded PCI pentium system, with ~500meg meg video
: bandwidth to its 220mhz ramdac and 100+meg second bandwidth to main
: memory, the gfx processor in HW support a broad range of 2d primitive
: and HW 3d primitive support Z buffer mode, blitter can do pixel type
: conversion, blit 8-32 bit pixel including YUV from local video memory
: or memory to video and do interpolated scaling, local video bus connector
: on the video card, upto 8meg of local wram (wram also include special
: functionality to accelrate blitter functions) , 16meg of 60ns
: 64bit fast page memory upgradable to 128meg, 256 of 8ns pipeline
: burst L2 cache (upto 512k), motherboard with high performance ports,
: support for 25-33mhz PCI bus and 75-200mhz cpu clock, etc... etc... etc..
Despite all of this amazing hardware, for some reason or another,
when I let my P5/100 w/ 32M sit idle for about 5 minutes (which I do as
often as I can) and the WindowsNT Maquee screensaver pops up, for some odd
the 1 inch high text still goes across the screen 'chop chop chopity chop'
rather than smoothly like my poor little A1200 can make it go. Under
FreeBSd performance is a little better -- but it still isn't smooth. This
is all no a stock Compaq 586/100 w 32MB, PCI Video and SCSI.
There is no point in having all that great high performance hardware
if it isn't high performing.
Greg Hull
Northeastern College of Computer Science
Lotus Notes C API
Michael van Elst
>What do you do with 50MB/sec of "transfer rate"? Just *transfer* animations?
>Maybe from your 600K/sec CD? Or you render gfx on screen? Making with the
>CPU most of the job that a video device should do.
"should do" ? That's ideology. There is nothing wrong with the CPU
doing calculations and that includes rendering. And if the CPU is faster
as your special purpose hardware then you need very much of your
ideology to justify the special purpose hardware.
>A lot of people are convinced that stealing the SVGA board from a PC and
>putting it into their 50Mhz Amiga will make it fly. Actually, it will make
>it *much* slower for everything that is not Doom,
Why ? Close to everything will be faster.
Jonathan Belson
:
: Despite all of this amazing hardware, for some reason or another,
: when I let my P5/100 w/ 32M sit idle for about 5 minutes (which I do as
: often as I can) and the WindowsNT Maquee screensaver pops up, for some odd
: the 1 inch high text still goes across the screen 'chop chop chopity chop'
: rather than smoothly like my poor little A1200 can make it go. Under
: FreeBSd performance is a little better -- but it still isn't smooth. This
: is all no a stock Compaq 586/100 w 32MB, PCI Video and SCSI.
:
: There is no point in having all that great high performance hardware
: if it isn't high performing.
That's more to do with the Amiga blanker using field syncing and double
buffering - you lose this when you use a graphics card in your miggy 8^(
C-YA
Jon
Fabio Bizzetti
>You don't understand dynamic RAM. The 80ns rating on a DRAM is the row
>address access time. That's usually (depending on the part and the
>memory controller), the fastest that data can be accessed from that
>part. However, DRAM also has a row address precharge time, which is
>usually about 60-80% of the access time. So while you can access a
>word in 80ns from the start of the memory cycle, you can't
>continuously run random access cycles any faster than around 140ns,
>for an 80ns part.
I know the difference between burst-modes and random access.
I still think that the chipram bus is slower than it could be.
As I said many times, the implementation is not my field (I just made
examples about many ways it _could_ be solved, never affirming what works
and what doesn't, since I dont know what chips would be used and I dont
know these chips' details), from a software developer side and hardware
appassionate, I can say what is needed and what can be practically done,
still not providing detailed hardware implementations.
>>Well, the chips inside my A1200 ("chipram") are much faster than
>>they're supposed to be, but Alice brakes the CPU to gain from this
>>speed because in fact Alice is chipram's controller.
>Not at all. The 80ns parts on the chip bus are exactly as fast as
>they're supposed to be. The constraint on speed is not the normal
>access time, but the timing for Alice's burst cycles. For video fetch,
>Alice runs 64-bits to Lisa every 280ns. The burst cycle timing is
>fairly critical, so 100ns parts would not work here.
Perhaps using a .8/.5 micron technology would allow these goals for the Walker:
# full AGA compatibility.
# single chip solution.
# possibility to add the AgaEXTENDER device, that does what every SVGA chip
does, and much more.
# possibility to change the design of Alice's DMA controller, to allow
different chipram solutions and the possibility to select clock doubling for
the other components, to exploit the new DMA design also to increase the
RAM->RGB bandwidth, being the AgaEXTENDER able to get advantage from this.
# cheaper technology than the old one actually used for AGA.
# less consume (eventually for a portable AGA Amiga).
All these points would make the Walker more modern, but would not make become
the A1200 obsolete.
I believe that the problem of the A1200's can't be solved in a different way
than the one the AgaEXTENDER's offers, because using a SVGA board through the
PCMCIA port will not be a big deal (and will be more expensive than many
low-end users are disponible to afford). Of course the CPU connector is busy
for a 68030 board, that anyway is still not sufficient to do on a SVGA what
the SVGA doesn't do by itself (talking about games/demos/multimedia), now
imagine if we've to return to the 14Mhz 68020 to use this SVGA board..
A cabinet with ZorroIII slots is too much expensive.
I believe that the A1200's doesn't deserve to be considered obsolete,
expecially because it's not at all (at least compared with the new Walker),
thus a solution should be found, that is not keeping the A1200 as it is today
though.
I proposed one, and I can show all its hidden potential to speed-up games/
multimedia applications, if not (A1200 case) improving the bandwidth, surely
allowing extreme semplifications in the CPU's routines, that would not have
anymore to do what a raster device should do instead.
>>>It is clear that you can do better than current 7MHz chip RAM but
>>>that's because RAM is faster nowadays.
>>It would be sufficient to modify the interface CPU <->chipram<-> Alice.
>If Alice were designed in a modern process, and you ran the actual
>chip bus timing from a 28MHz or 56MHz basis, rather than the 14MHz at
>present, you could probably run four cycle bursts to Chip RAM in the
>280ns window. Maybe CPU bursts too, though there's another problem
>with memory access, and that's one of matching the cycle to the
>CPU. It does you no good if you have data ready when the CPU can't
>take it.
For writing this is not a problem (using a write buffer), but for reading it
surely it.
But there's to say that every heavy use of chipram is _expecially_ writes,
while the access (as read) is most of the cases from fastram.
The write buffer would still be an important improvement.
>The chip bus is a synchronous bus, and if you were to burst
>four words out of it for a CPU cycle, you would either need a CPU that
>perfectly aligned with the chip bus timing, or you would need a FIFO
>device to store the fetched data for when CPU could take it.
But in case of reads this still doesn't work, since the CPU must wait for the
data, before being able to continue with the execution of the program.
(we can't modify the CPU ;))
>>Maybe the "ram controller" that you wish (to multiplex data) would be more
>>expensive than 2Mb of real dual access ram, this is to be examinated.
>Real dual-ported random access memory is exotic. You usually get it in
>hundred-byte chips, generally used for contention-free mailboxes in
>high performance multiprocessing systems. Video RAM (VRAM) is a
>special purpose dual ported RAM, and it's commonly used in graphics
>systems to get the video fetch activity decoupled from the "chip
>bus". The AAA system supported VRAM, but it's a rather tricky thing to
>support, since the video access portion is serial, not random
>access. The AAA chips used a double line-buffer scheme to get around
>this, but it's not a real cheap solution. More primitive graphics
>systems can limit where displays live in order to simplify the
>requirements for VRAM.
>However, VRAM is expensive, since it's roughly 50% larger per cell
>than DRAM. There's no inherent advantage to dual porting over other
>methods. The main goal in making a faster graphics system is to speed
>up the aggregrate bandwidth of the system. Dual porting can double (or
>more like triple) a memory's bandwidth. But if I speed memory access
>other ways, like increasing the bus size, I can get the same
>advantages by time multiplexing the bus. There's nothing inherently
>wrong with the way the Amiga does it, it's just dealing with
>technology that began life in the mid 80s.
Re-designing the Alice's memory access circuits would solve many problems (not
all) of the Walker, if there's time to do it, but the A1200 still needs another
solution, and the A1200 shouldn't be declared obsolete for much time yet.
IMO, the solution is to allow to the A1200 all the new modern functions needed,
still providing better speed for the newer Amigas. The current bandwidth of
the A1200 is sufficient for every modern game/video application needs, if we
help the CPU with a programmable raster device.
>>> We already have "dual port RAM", just the multiplexing is done outside the
>>> chip.
>>
>>This is the problem: it's performed by the 7Mhz (bus clock) of Alice.
>Alice has a 14MHz bus clock.
Alice offers 4 times the bandwidth than OCS, 2 times more using 32bit wide bus
and the other 2 times more using FastPage modes. This means that the clock
is doubled when Alice access to chipram, but the CPU still access with with
the old 7Mhz speed. I think the real problem is CPU speed access to chipram;
the chipram->RGB bandwidth is still usable for an A1200, considering that we
can't change it.
>>Just think, 24Mb/sec
>Oh by the way, "24Mb/sec" means "24 megabits per second". I think you
>mean 24MB/s in all your talk here...
24Mb/sec is "megabytes", and is referred to the chipram->RGB bandwidth, simply
calculated this way:
384 low-res pixels (max overscan) * 4 (SHRES case) = 1536
312 lines in a 1/50 sec (the blank ones could be exploited for audio) = 312
8 bitplanes selectable in SHRES screens = 1
number of frames/sec in this case (312 lines) = 50
total = 1536*312*1*50 = 23,961,600 bytes / sec.
>Dave Haynie | ex-Commodore Engineering | for DiskSalv 3 &
>Sr. Systems Engineer | Hardwired Media Company | "The Deathbed Vigil"
>Scala Inc., US R&D | Ki No Kawa Aikido | in...@iam.com
> "Feeling ... Pretty ... Psyched" -R.E.M.
Juergen Rally Fischer
: >A lot of people are convinced that stealing the SVGA board from a PC and
: >putting it into their 50Mhz Amiga will make it fly. Actually, it will make
: >it *much* slower for everything that is not Doom,
: Why ? Close to everything will be faster.
It's the other way around: doom will not be that much faster like people
expect (unless you got a very fast cpu, a 040 with fast mem-interface)
while workbench will be lot faster especially in shres modi, even
without using SVGA blitter.
: --
: Michael van Elst
: Internet: mle...@serpens.rhein.de
: "A potential Snark may lurk in every tree."
Juergen Rally Fischer
: >As far as I recall my A1200 chipram is 80ns; while it's exploited as if it was
: >only 140ns. The rest of ns is wasted because Alice holds control of everything,
: >and Alice is slower than the CPU.
: You don't understand dynamic RAM. The 80ns rating on a DRAM is the row
: address access time. That's usually (depending on the part and the
: memory controller), the fastest that data can be accessed from that
: part. However, DRAM also has a row address precharge time, which is
: usually about 60-80% of the access time. So while you can access a
: word in 80ns from the start of the memory cycle, you can't
: continuously run random access cycles any faster than around 140ns,
: for an 80ns part.
ok, so why my 020 needs _12_ cycles , i.e. _846_ ns (!!!!) to load a
byte/.w/.l from chipmem ?
why AGA got the curious quality that _any_ kind of chipmem acess is
just 2 times slower than it is in fastmem ?
that's unlogic, because any acess should be delayed by a fix amount
of time. but: load 6 -> 12 cycles (difference: 6), store 4 -> 8 cycles
(difference: 4).
it's not chipram speed, no offence, but you're imho "hiding" the
true reasons.
BTW imho it should cost almost nothing to add a A3000-alike chipmembuffer,
did you do it in walker ? I really hope so. 4 longwords would even
be better for 8plane modi, which seem to be unideal on LORES,
i.e. it blocks a storing cpu more than 2 planes SHRES.
: >It would be sufficient to modify the interface CPU <->chipram<-> Alice.
: take it. The chip bus is a synchronous bus, and if you were to burst
: four words out of it for a CPU cycle, you would either need a CPU that
: perfectly aligned with the chip bus timing, or you would need a FIFO
: device to store the fetched data for when CPU could take it.
again, beeing no expert at all, I can't stand the feeling that this FIFO
would be just another $0.2 TTLs. again, what about walker ?
I see there's no way for a compatible AGA+ _now_, but adding some TTLs
should really not be that problem for a company.
Am I missing something ?
: Alice has a 14MHz bus clock.
And the cpu can start acess in 4 cyle parts (14 mhz cycles) and
store in 8 cycle parts (funny thing).
exact same timings like on OCS.
: Oh by the way, "24Mb/sec" means "24 megabits per second". I think you
: mean 24MB/s in all your talk here...
please just give us 7mb/sec _copy_ speed in walker.
: Dave Haynie | ex-Commodore Engineering | for DiskSalv 3 &
: Sr. Systems Engineer | Hardwired Media Company | "The Deathbed Vigil"
: Scala Inc., US R&D | Ki No Kawa Aikido | in...@iam.com
: "Feeling ... Pretty ... Psyched" -R.E.M.
Juergen Rally Fischer
: >>AGA can be improved a lot though,
: >Hah. Could you afford to improve AGA ? The fact that something is
: >theoretically possible doesn't mean that it is feasible.
: Well, I do agree with this. AGA is just too old to be starting point for a
: new custom chipset. It make it very difficult, make the price go way and maket
: the new design take far too long.
don't forget the chipram bandwidth record is hold by a ECS Amiga.
huh, ECS ? Yes, the A3000, 7mb/sec _copy_ speed with help of a
buffer. So not the chipset needs a change, just put some ICs around
it.
Don't need no new chipset. need a clever aga-board.
BTW you could use a 100Hz TV for flickerfree 640x512, much quicker
wb-scrolling than 640x512 DBLPAL. maybe those TVs get cheaper soon ?
for AGA they are better than monitors unless you really need a 1280 mode.
: all the Amiga specialties into it. Somehow hacking things such as the copper
: into a set not designed with anything like that in mind would seem to me
: to be more difficult than starting from scratch, however someone
: (perhaps even connected with the former CBM engineering) seemed to think that
: it was easier and possible.
copper is nice, but I would not mind working on a card where screens
are just switched with Amiga-M. Drag is nice for comparing screen
contents, though.
Juergen Rally Fischer
: > It seen to be 'very' hard, at least was for CBM... They love to
: > save a few penies for not including a socket.
: They love to save a few more dollars for having a much higher
: production yield and they love to save a few more dollars to reduce
: production cost.
but then they add things only a little amount of users can need: PCMCIA.
: --
: Michael van Elst
: Internet: mle...@serpens.rhein.de
: "A potential Snark may lurk in every tree."
Stephan Schaem
: >What do you do with 50MB/sec of "transfer rate"? Just *transfer* animations?
: >Maybe from your 600K/sec CD? Or you render gfx on screen? Making with the
: >CPU most of the job that a video device should do.
: "should do" ? That's ideology. There is nothing wrong with the CPU
: doing calculations and that includes rendering. And if the CPU is faster
: as your special purpose hardware then you need very much of your
: ideology to justify the special purpose hardware.
Little comment to say dedicated HW is not alway better...
People in #coders where laughting at some new 3d PC card, because it
was actually slower then rendering with a fast p5 making the HW only
good for people with old pc setup (I guess it was the point since the
card didn't offer a PCI version)
Stephan
Michael van Elst
>ok, so why my 020 needs _12_ cycles , i.e. _846_ ns (!!!!) to load a
>byte/.w/.l from chipmem ?
Maybe chip-bus contention ?
>why AGA got the curious quality that _any_ kind of chipmem acess is
>just 2 times slower than it is in fastmem ?
This obviously depends on the speed of your fastmem.
>that's unlogic, because any acess should be delayed by a fix amount
>of time. but: load 6 -> 12 cycles (difference: 6), store 4 -> 8 cycles
>(difference: 4).
No. Writes are usually faster because a write cycle can complete while
the CPU continues with internal operation. A read must complete because
the CPU needs the data fetched.
>: perfectly aligned with the chip bus timing, or you would need a FIFO
>: device to store the fetched data for when CPU could take it.
>again, beeing no expert at all, I can't stand the feeling that this FIFO
>would be just another $0.2 TTLs. again, what about walker ?
No, it would be more than $0.2 (and very few TTL parts cost $0.2
anyway).
>I see there's no way for a compatible AGA+ _now_, but adding some TTLs
>should really not be that problem for a company.
>Am I missing something ?
Yes. "Adding some TTLs" needs lots of board space. And that is a price
issue.
Michael van Elst
>but then they add things only a little amount of users can need: PCMCIA.
Sure. At that time they thought that PCMCIA would become a source
for cheap peripherals but it hardly became more than an expansion
port for high priced notebooks.
Regards,
K. C. Lee
Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) writes:
>
> ok, so why my 020 needs _12_ cycles , i.e. _846_ ns (!!!!) to load a
> byte/.w/.l from chipmem ?
Remember that the CPU is not the only one that have access to your chip
ram... ( I don't know too much about AGA 64-bit fetch and all the funny
screen modes.) Your CPU have 1/2 of the bandwidth available and also have
to wait if it trys to access the memory at the wrong time.
> that's unlogic, because any acess should be delayed by a fix amount
> of time. but: load 6 -> 12 cycles (difference: 6), store 4 -> 8 cycles
> (difference: 4).
May be it is the memory access pattern ? I wouldn't even try to figure
things in a CPU with caches.
> BTW imho it should cost almost nothing to add a A3000-alike chipmembuffer,
> did you do it in walker ? I really hope so. 4 longwords would even
What chip buffer is that ? The 020 already have 32-bit access to the chip
ram.
> : four words out of it for a CPU cycle, you would either need a CPU that
> : perfectly aligned with the chip bus timing, or you would need a FIFO
> : device to store the fetched data for when CPU could take it.
>
> again, beeing no expert at all, I can't stand the feeling that this FIFO
> would be just another $0.2 TTLs. again, what about walker ?
A FIFO cause more than $0.2. You can't build such a FIFO short of in a
FPGA as it is more like a prefetch cache.
All this silly stuff for just getting a bit more out of old chips is kind
of silly. I would like to see VESA local bus (standard or an optional
board) so that I can put in $100 graphic acelerators cards for the PC market.
> fisc...@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:)
K. C. Lee
K. C. Lee
Fabio Bizzetti (bizz...@mbox.vol.it) writes:
>
> Perhaps using a .8/.5 micron technology would allow these goals for the Walker:
>
> # full AGA compatibility.
> # single chip solution.
> # possibility to add the AgaEXTENDER device, that does what every SVGA chip
> does, and much more.
Sure, but what about the time required for them to redo the chip ? It
would be a lot more productive simply to add a SVGA chip. :) You get
today's performance of SVGA accelerators today. Not some 10 years old
technology 2-3 years down the road.
The AgaEXTENDER is still on paper. every SVGA chip does more today than a
piece of vapourware. What's good is a 5 zillion colours superdouper AGA
Extender if the games developer don't have it in their hands ? I can come
up with better designs augmenting SVGA chips with external Copper.
> I believe that the problem of the A1200's can't be solved in a different way
> than the one the AgaEXTENDER's offers, because using a SVGA board through the
> PCMCIA port will not be a big deal (and will be more expensive than many
The PCMCIA port is useless for a high performance SVGA accelerator as it
only has a 16-bit bus, but still it is faster than the chip bus. Not to
mention the faster 64-bit blitters still running at full speed. Oh yeah,
some of the chips have a FIFO for queuing CPU commands.
> low-end users are disponible to afford). Of course the CPU connector is busy
> for a 68030 board, that anyway is still not sufficient to do on a SVGA what
Agreed. The 14 MHz trap door bus could have been a perfect place for it.
Unfortunately no one have the far sight to have a pass through.
> I believe that the A1200's doesn't deserve to be considered obsolete,
> expecially because it's not at all (at least compared with the new Walker),
> thus a solution should be found, that is not keeping the A1200 as it is today
On the other hand why do you want to cripple the Walker which has a 40MHz
CPU bus by insisting on not making the A1200 obsolete? I want thing the
way it is for my A1000 five years down the road ! :) I am sick of >512K
chip ram :)
Most decent SVGA chips has a VESA support which is based on a 486 CPU bus.
It would even be even faster than the existing ZIII bus (A3000/4000) which
only run at 25MHz. The SVGA solution is IMHO a more compatible way of
tackling the problem for all the existing machines. You just get different
performance limited by your machine.
> | Fabio "Maverick" Bizzetti - bizz...@mbox.vol.it - Maverick* at IRC |
K. C. Lee
Pacarana
>: new custom chipset. It make it very difficult, make the price go way and
>: maket the new design take far too long.
>don't forget the chipram bandwidth record is hold by a ECS Amiga.
>huh, ECS ? Yes, the A3000, 7mb/sec _copy_ speed with help of a
>buffer. So not the chipset needs a change, just put some ICs around
>it.
>Don't need no new chipset. need a clever aga-board.
smallish AGA type improvement.
>copper is nice, but I would not mind working on a card where screens
>are just switched with Amiga-M. Drag is nice for comparing screen
>contents, though.
The copper is used for alot more than instantly draggable screen though.
Dr. Peter Kittel
>
>BTW imho it should cost almost nothing to add a A3000-alike chipmembuffer,
Oops, that Amber chip was one of the most expensive parts in the A3000!
No, not at all like "cost almost nothing".
>did you do it in walker ?
No. Too expensive. We have some of the functionality in the AA chips,
remember, so Amber was only needed for some very special cases, read
games and c0der demos, for practically all other situation mode
promotion (and in worst case some similar tool from AmiNet) does the job.
>: >It would be sufficient to modify the interface CPU <->chipram<-> Alice.
To explain it: This would mean a *complete* redesign of the AA chipset.
And as Paula is still in some antique technology, it's not like just
transferring the old design from 1.0 to 0.35 um, but to reinvent it
from scratch...
--
Best Regards, Dr. Peter Kittel // Visit http://www.amiga.de
Private Site in Frankfurt, Germany \X/ Email to: pet...@combo.ganesha.com
Employed at AMIGA Technologies GmbH in Bensheim, Germany
Michael van Elst
>In article <4k1kk3$i...@sunsystem5.informatik.tu-muenchen.de> fisc...@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) writes:
>>
>>BTW imho it should cost almost nothing to add a A3000-alike chipmembuffer,
>Oops, that Amber chip was one of the most expensive parts in the A3000!
>No, not at all like "cost almost nothing".
Sorry, Juergen meant something completely different.
>>: >It would be sufficient to modify the interface CPU <->chipram<-> Alice.
>To explain it: This would mean a *complete* redesign of the AA chipset.
Sorry, the modification wouldn't require changes in the chipset. It
requires extra logic for the CPU data path and a few address bits.
You could save on the address logic if Alice would generate double-cas
cycles for the CPU too.
Juergen Rally Fischer
In article <4k2fbl$l...@serpens.rhein.de>, mle...@serpens.rhein.de (Michael van Elst) writes:
|> fisc...@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) writes:
|>
|> >byte/.w/.l from chipmem ?
|>
no. all chipdma off. "normal" dma-load (8 planes lores) won't change much.
movem-read can get near to something like 10 cycles (because it does
5 cyles in fastmem ;)
So acess in multiples of 2 cycles, max speed 8 cycles/acess.
|>
|> >why AGA got the curious quality that _any_ kind of chipmem acess is
|> >just 2 times slower than it is in fastmem ?
|>
|> This obviously depends on the speed of your fastmem.
my fastmem is 0waitstate to a 020-14, I should have said "just 2 times
slower than max possible 020 acess". Still courious, how it manages to
make any kind of acess 2 times slower.
I always had the impression that acess times are constants, not factors ;)
|>
|> >that's unlogic, because any acess should be delayed by a fix amount
|> >of time. but: load 6 -> 12 cycles (difference: 6), store 4 -> 8 cycles
|> >(difference: 4).
|>
|> No. Writes are usually faster because a write cycle can complete while
|> the CPU continues with internal operation. A read must complete because
|> the CPU needs the data fetched.
my measurements include continous stores ;) I know a write to chipmem is
2 cycles if it is followed by 3 reg,reg operations ;)
It is really courious. Only the 6 cycles move.l (chip),(chip) is
not done x2 to 12 cycles, because this would be against the
"min 8 cycles chipmemacess" rule, so it is done in 16 cycles.
2 rules:
a) ideal acess x2 (well, on a synced 020-14).
b) if a) is less than "number of acesses x 8 cycles" then increase
to that number (this should be true for all cpus, meaning 8 14-MHz
cycles of course).
|>
|> >: perfectly aligned with the chip bus timing, or you would need a FIFO
|> >: device to store the fetched data for when CPU could take it.
|>
|> >again, beeing no expert at all, I can't stand the feeling that this FIFO
|> >would be just another $0.2 TTLs. again, what about walker ?
|>
|> No, it would be more than $0.2 (and very few TTL parts cost $0.2
|> anyway).
Well, IMHO they should do it in walker. Like they did in A3000.
Lots of people will use it for gaming, it will make sense.
|> >Am I missing something ?
|>
|> Yes. "Adding some TTLs" needs lots of board space. And that is a price
|> issue.
ah :\
what about a inovative $3 sandwitch platine carrying all the TTLs ? ;)
|>
|>
|>
|> --
|> Michael van Elst
|>
|> Internet: mle...@serpens.rhein.de
|> "A potential Snark may lurk in every tree."
------------------------------------------------------------------------
Juergen Rally Fischer
In article <4k1oqk$a...@freenet-news.carleton.ca>, de...@FreeNet.Carleton.CA (K. C. Lee) writes:
|> Organization: The National Capital FreeNet
|> Lines: 41
|> Sender: de...@freenet2.carleton.ca (K. C. Lee)
|> Message-ID: <4k1oqk$a...@freenet-news.carleton.ca>
|> References: <4j6jv0$1...@serpens.rhein.de> <5827.665...@mbox.vol.it> <1996Apr2.2...@scala.scala.com> <4k1kk3$i...@sunsystem5.informatik.tu-muenchen.de>
|> Reply-To: de...@FreeNet.Carleton.CA (K. C. Lee)
|> NNTP-Posting-Host: freenet2.carleton.ca
|>
|>
|> Juergen "Rally" Fischer (fisc...@Informatik.TU-Muenchen.DE) writes:
|> >
|> > ok, so why my 020 needs _12_ cycles , i.e. _846_ ns (!!!!) to load a
|> > byte/.w/.l from chipmem ?
|>
|> ram... ( I don't know too much about AGA 64-bit fetch and all the funny
This is not the reason. same goes for master dma off.
This also won't explain why reads are slower than writes although the
020 can read in 6 cyles, i.e. beyond 8 cycles.
|> screen modes.) Your CPU have 1/2 of the bandwidth available and also have
|> to wait if it trys to access the memory at the wrong time.
|>
|> > that's unlogic, because any acess should be delayed by a fix amount
|> > of time. but: load 6 -> 12 cycles (difference: 6), store 4 -> 8 cycles
|> > (difference: 4).
|>
|> May be it is the memory access pattern ? I wouldn't even try to figure
|> things in a CPU with caches.
It is not the cache, my cpu got no datacache.
Anyway, wrong results dues to caching would mean _faster_ results, not
slower ;->
|>
|> > BTW imho it should cost almost nothing to add a A3000-alike chipmembuffer,
|> > did you do it in walker ? I really hope so. 4 longwords would even
|>
|> What chip buffer is that ? The 020 already have 32-bit access to the chip
|> ram.
The A3000 has 32bit acess, too. but it is buffered so cpu can go on
with fastmemacess while the write is done.
|> > fisc...@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:)
|>
|> K. C. Lee
Juergen Rally Fischer
In article <794.6672...@gramercy.ios.com>,
lar...@gramercy.ios.com (Pacarana) writes:
|> >don't forget the chipram bandwidth record is hold by a ECS Amiga.
|> >huh, ECS ? Yes, the A3000, 7mb/sec _copy_ speed with help of a
|> >buffer. So not the chipset needs a change, just put some ICs around
|> >it.
|> >Don't need no new chipset. need a clever aga-board.
|> But that still wouldn't be enough. That would just be another nice, but
|> smallish AGA type improvement.
Well, walker is lo end, walker is AGA. IMHO there will be done lot
gaming on it. Why not do an improved interface.
|>
|> >copper is nice, but I would not mind working on a card where screens
|> >are just switched with Amiga-M. Drag is nice for comparing screen
|> >contents, though.
|> The copper is used for alot more than instantly draggable screen though.
|>
In copperscreen demos, yes ;) Not so important for Amiga future.
for vports, more interesting. can be emulated on gfx-card.
Time for a new OS revision that lets you do paralax-scrollers without
the blank line between vports.
Pacarana
>Oops, that Amber chip was one of the most expensive parts in the A3000!
>No, not at all like "cost almost nothing".
>No. Too expensive. We have some of the functionality in the AA chips,
>remember, so Amber was only needed for some very special cases, read
>games and c0der demos, for practically all other situation mode
>promotion (and in worst case some similar tool from AmiNet) does the job.
Not all demo makers write like c0DeR.
Anyway, mode promotion can steal too much bandwidth from some games and demos
and 320x200 dual-playfield isn't even possible in doubled modes and copper
list timings can change so you can't always blame coders for having locked
things into 15Khz. Of course, even if AGA had no performance hit and dual-pf
existed in x200 doubled modes, 31khz still might not have been used all
that much thanks to the overly low-end UK games market (TVs even nevermind
monitors in some cases) and also perhaps some copper things,although a second
version could easily have been made if that was a problem.