NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/6970

Internet Message Format | 1996-08-05 | 8.7 KB

Path: news.vol.it!news
From: [e-mail] (Fabio Bizzetti)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: CHIP RAM speed test resul
Date: 3 Apr 1996 15:06:33 GMT
Organization: Video On Line
Distribution: world
Message-ID: <[e-mail]>
References: <4j6jv0$[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: molcl10.vol.it
X-Newsreader: THOR 2.22 (Amiga;TCP/IP)



>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     |     [e-mail]

>         "Feeling ... Pretty ... Psyched" -R.E.M.




  /-----------------------------------------------------------------------\
  |  Fabio "Maverick" Bizzetti - [e-mail] - Maverick* at IRC  |
  |            The maker of "CyberMan" and "Virtual Karting"              |
  |              working on "VirtualRally" & "StarFighter"                |
  \-----------------------------------------------------------------------/