home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2713 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.6 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: Amiga doesn`t need Planar!
  5. Date: 4 Feb 1996 11:47:39 +0100
  6. Organization: dis-
  7. Message-ID: <4f22sb$nhj@serpens.rhein.de>
  8. References: <john.hendrikx.4biy@grafix.xs4all.nl>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. john.hendrikx@grafix.xs4all.nl (John Hendrikx) writes:
  12.  
  13. >Not really important as it is 8-bit, 16-bit, 24-bit or 32-bit in today's world,
  14. >well except Amiga that is.
  15.  
  16. Guess why. People are using CPUs instead of general purpose hardware.
  17.  
  18. >True, but with a 8-bit bus the Chunky alignment needs are non-existant, while
  19. >planar already has 8-pixel alignment with that bus.
  20.  
  21. We are not talking about an 8-bit bus. No ?
  22.  
  23. >It gets worse for planar
  24. >far faster as planar has a headstart in this.
  25.  
  26. Do your math again.
  27.  
  28. >And I never said the system would be CPU only, would be quite ridiculous to do
  29. >that.  It is just an advantage of Chunky that the CPU can handle the display
  30. >very well too.
  31.  
  32. The advantages of chunky just come from the fact that you use the CPU.
  33.  
  34. >Hmmm...  so what you're saying is that if you had a 64-bit memory bus, and
  35. >'somehow' managed to rearrange memory in such a way that the same bytes of
  36. >every 8 bitplanes are located next to each other you could modify them in just
  37. >one access?
  38.  
  39. I don't have to "manage" that.
  40.  
  41. >Ie, if you plot a pixel in 8-bit you could do it in one access? 
  42.  
  43. If I wished to emphasize on plotting single pixels. Maybe.
  44.  
  45. >That would be nice, but if you do that you lose the main advantage of planar,
  46. >fast manipulation of single bitplanes.
  47.  
  48. No. Because that's just an addressing scheme.
  49.  
  50. >It would effectively turn your planar
  51. >hardware into Chunky hardware, with almost the same advantages and
  52. >disadvantages, except that to the CPU it LOOKS like Planar.
  53.  
  54. In fact, with such a hardware I wouldn't care about the CPU. The
  55. CPU can do better things than rendering graphics.
  56.  
  57. >Question is why would you ever want to do that?  Not only does it require much
  58. >wider memory busses to get good speed,
  59.  
  60. It of course, needs as wide memory busses as you want. It is just the
  61. question how you use the increased memory bandwidth. With 64bit I can
  62. feed two 32bit blitters.
  63.  
  64. >When I come to think of it this isn't possible at all unless you got some
  65. >adaptive memory hardware or something.  I mean, what would happen if you
  66. >displayed 7 bitplanes this way? Would you have 1 byte unused after every 7 used
  67. >bytes?
  68.  
  69. Depends on what I want to use the data for. It wouldn't be a problem to
  70. feed 7 64bit words sequentially, it wouldn't be a problem to feed any
  71. combination of smaller words. As I said, it is just an addressing scheme.
  72.  
  73. >What if I opened a 2nd screen?  Could I use that 'extra' byte for a
  74. >bitplane of a different screen?
  75.  
  76. There wouldn't be necessarily an extra byte. If you want it you can
  77. have it (or funnel it into a different DMA channel).
  78.  
  79. >This would also kill Planar's advantage of
  80. >having multiple bitplane pointers as they would need to be at specific
  81. >locations in memory (kinda like a Interleaved bitmap).
  82.  
  83. Why that ?
  84.  
  85. >I don't think this is a
  86. >reasonable possibility at all, in terms of cost and effort. You might as well
  87. >go Chunky right away and save yourself the mess.
  88.  
  89. If I want bitplane operations I surely wouldn't go chunky.
  90.  
  91. >Because those are irrelevant, 8 bits per pixel is the standard, if planar can't
  92. >handle that fast than planar simply sucks.
  93.  
  94. You mean because planar is not chunky and not suited for standard microprocessors
  95. it sucks ? Why do you look for arguments then ?
  96.  
  97. >Who's talking about the CPU?
  98.  
  99. You are. If you do not use the CPU then your special hardware won't have an
  100. advantage.
  101.  
  102. >It would be kinda unfair to compare CPU Chunky vs
  103. >Hardware Planar (although even then Planar doesn't look too good).
  104.  
  105. So you think it is fair to compare CPU Chunky vs. CPU Planar ?
  106.  
  107. >A fast CPU would laugh at this 'overhead'
  108.  
  109. You mean you start with slow memory from the beginning ?
  110.  
  111. >as memory accesses are so slow it can
  112.  
  113. They aren't. Accessing individual memory cells is slow.
  114.  
  115. >easily handle the extra calculations needed 'in between' memory accesses (like
  116. >040 C2P).
  117.  
  118. As always you just think about Amiga hardware where the planar memory system
  119. is 10 year old technology and the CPU is recent.
  120.  
  121. >Anyway, I explained why I think wider memory busses wouldn't work as good with
  122. >Planar in an other message to you.
  123.  
  124. And I explained why you can use the wider busses more flexible with planar.
  125.  
  126. -- 
  127.                                 Michael van Elst
  128.  
  129. Internet: mlelstv@serpens.rhein.de
  130.                                 "A potential Snark may lurk in every tree."
  131.