home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6464 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.5 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: CHIP RAM speed test resul
  5. Date: 28 Mar 1996 11:18:59 +0100
  6. Organization: dis-
  7. Message-ID: <4jdp2j$t1a@serpens.rhein.de>
  8. References: <4j6jv0$1im@serpens.rhein.de> <5827.6659T112T770@mbox.vol.it>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. bizzetti@mbox.vol.it (Fabio Bizzetti) writes:
  12.  
  13. >It would be sufficient to modify the interface   CPU <->chipram<-> Alice.
  14.  
  15. You say as if this were easy.
  16.  
  17. >>Yes. That's why "dual ported RAM" is nonsense.
  18.  
  19. >Come on.. I didn't mean to simply change the chips!!!!
  20. >There must be a circuit to exploit the new chips' nature, and getting a fast
  21. >SIMM and multiplexing data is perfectly fine, allowing practical dual access,
  22. >but (perhaps) could be more complicated at the end than real dual access ram
  23. >(ofcourse with the circuit to use it).
  24.  
  25. I am just talking about that. Real "dual ported RAMs" just exist in tiny
  26. sizes, they are used for communication between several CPUs or as
  27. register banks. Then there are chips that are just multiplexed RAMs with
  28. the multiplexer inside. Still small and still very expensive and
  29. effectively the same as standard RAM on a multiplexed bus. And then
  30. there is the variety of VRAM that is just usuable for special applications.
  31. It still is multiplexed but one side uses a very wide bus so that
  32. multiplexing overhead is neglible if you can use the ~1024bit word.
  33.  
  34. So, except for the true dual ported RAMs there is no real advantage for
  35. our application. What you really want is just a RAM controller that is
  36. as fast as todays RAM chips.
  37.  
  38. >Maybe the "ram controller" that you wish (to multiplex data) would be more
  39. >expensive than 2Mb of real dual access ram,
  40.  
  41. The RAM controller is called Alice. You would need a version that runs
  42. faster, at least on the memory bus. And no, 2kbyte of real dual ported
  43. RAM is more expensive than the current Alice. These chips are made of
  44. fast static RAM. Think about building main memory of cache RAMs and then
  45. double the price.
  46.  
  47. >Everything is good to improve performances, and AGA has already a very good
  48. >22Mb/sec bandwidth to RGB, giving another 22mb/sec CPU-chipram would be *nice*.
  49.  
  50. Oh, a state-of-the-art video controller that reads 200MByte/s and leaves
  51. 60MByte/s for the CPU is even nicer.
  52.  
  53. >> We already have "dual port RAM", just the multiplexing is done outside the
  54. >> chip.
  55.  
  56. >This is the problem: it's performed by the 7Mhz (bus clock) of Alice.
  57.  
  58. Yes, that's why you want a much faster graphics controller.
  59.  
  60. >AGA can be improved a lot though,
  61.  
  62. Hah. Could you afford to improve AGA ? The fact that something is
  63. theoretically possible doesn't mean that it is feasible.
  64.  
  65. >> They need geometry engines,
  66.  
  67. >A skilled assembly programmer can avoid multiplications/divisions and all
  68. >these things that normal programmers learn from standard books.
  69.  
  70. You mean those books that show how to write efficient rendering routines
  71. too ?
  72.  
  73. >It would mean to blow the PC away.
  74.  
  75. It just means that you know more about c0d1ng than about hardware.
  76.  
  77. >They cost a lot, the PCI GfxBoard isn't flexible (it gains all from Pentium's
  78. >MIPS, that are quite more than Walkers' ones)
  79.  
  80. The PCI board is much more flexible _because_ it gains all from the
  81. Pentium's speed. With a custom chipset like AGA you are more or less
  82. stuck with 5-10 year old technology.
  83.  
  84.  
  85. -- 
  86.                                 Michael van Elst
  87.  
  88. Internet: mlelstv@serpens.rhein.de
  89.                                 "A potential Snark may lurk in every tree."
  90.