home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / amiga / misc / 18605 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  10.8 KB

  1. Xref: sparky comp.sys.amiga.misc:18605 comp.sys.amiga.advocacy:31412 comp.sys.amiga.hardware:21568
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!pacbell.com!pacbell!oracle!unrepliable!bounce
  3. Newsgroups: comp.sys.amiga.misc,comp.sys.amiga.advocacy,comp.sys.amiga.hardware
  4. From: dnavas@oracle.uucp (David Navas)
  5. Subject: Re: WOC Toronto: Amiga's Future
  6. Message-ID: <1992Dec15.173535.24953@oracle.us.oracle.com>
  7. Sender: usenet@oracle.us.oracle.com (Oracle News Poster)
  8. Nntp-Posting-Host: mailseq.us.oracle.com
  9. Organization: Oracle Corporation, Redwood Shores CA
  10. References: <20068@ucdavis.ucdavis.edu>
  11. Date: Tue, 15 Dec 1992 17:35:35 GMT
  12. X-Disclaimer: This message was written by an unauthenticated user
  13.               at Oracle Corporation.  The opinions expressed are those
  14.               of the user and not necessarily those of Oracle.
  15. Lines: 282
  16.  
  17. To csa.hardware to attempt to get clarification from some kind of person
  18. who knows :)
  19. There are a LOT of questions here, and anyone that knows anything about what
  20. was said, or even simple things like chip design cycles are welcome to
  21. respond.
  22.  
  23. Please followup to the appropriate newsgroup, though.  I read all three,
  24. thanks.
  25.  
  26. In article <20068@ucdavis.ucdavis.edu> Shawn_E_Switenky@engr.usask.ca (Shawn E Switenky) writes:
  27. >[ Thanks for putting in the work, Shawn!     -Dan             ]
  28.  
  29. Indeed.
  30. And now, a few questions if you please.
  31.  
  32. >pleasure of sitting next to him for the Saturday night seminar.  He is a
  33.  
  34. Is it public what was covered in the Sat. night seminar -- I didn't see any
  35. specific mention of it?  If you compiled both seminars into these posts,
  36. nice job!  Of course, I like my news -raw- rather than well-done :)
  37.  
  38. [cringe]  anyway.
  39.  
  40. >Low End:
  41. >    - 57 MHz Pixel Clock
  42.  
  43. This isn't the gfx bus speed, just the pixel clock.  From what I gather here,
  44. the bus speed will be 14Mhz, correct?
  45.  
  46. Anyway, that's a 17ns pixel -- which is what we need for 1024x768x60, right?
  47. Any mention of such a mode?
  48.  
  49. >    - 8x Memory Bandwidth Increase
  50.  
  51. This is relative to?  ECS?  AGA?
  52. This is memory bandwidth from CPU to CHIPbus or CHIPbus to video?
  53. And on what machine architecture (if the former -- memory bandwidth is
  54. already different between the CPU and the CHIPbus in the A3000 vs. the A500,
  55. for example).
  56.  
  57. >    - 2x Blitter Performance ( gets twice as many clocks as on AGA )
  58.  
  59. Yeah, for free.  This, along with the 100% backwards compatible makes it
  60. yet-again a 16bit blitter.  Sigh....
  61.  
  62. >    - 800x600x8bit Non-Interlace 72Hz Refresh Rate
  63.  
  64. Goodness, I should hope so.
  65.  
  66. >    - Larger screens at lower Refresh Rates
  67.  
  68. ;)  Specifically?  Like 1024x768x60 for example?  I could really dig a $700
  69. computer (A1200+) that did that ;)
  70.  
  71. >    - 16 bit True Color mode ( although recent developments with the
  72. >      completion of the first cycle of chipset design indicate that this
  73. >      will actually be a 24 bit True Color Mode )
  74.  
  75. As Ty pointed out to me in email, this sounds rather the funny thing to say.
  76. I mean, they asked for a 16bit TC mode and it came back from the designers
  77. with an extra 8bits layed out or something?  ;)
  78.  
  79. What resolution would such a mode run in?  And goodness, does this mean 24
  80. separate bitplanes.  Yeesh!
  81.  
  82. >    - FIFO serial ports
  83.  
  84. About time.  Will this include DMA as well (like, say, the IIfx?).
  85.  
  86. >    - increased Chip Ram ( 8Mb )
  87.  
  88. Good idea ;)  How are they going to make this 100% backwards compatible
  89. though?  Are they ripping ZorroII space into Chip RAM?  Personally, I've
  90. always thought it a good idea for ZII memory-space to become fully
  91. devoted to CHIP (except maybe the IO space).
  92.  
  93. All in all, pretty reasonable for, say, six months in the future.
  94. My guess is that it's going to be longer than that, in which case a DRAM
  95. backwards compatible chipset seems kinda silly.
  96.  
  97. ---
  98.  
  99. >High End:
  100. >    - 4 Chips ( 750k transistors each )
  101.  
  102. Each or total?  I seem to remember these being -totals- in the WOC Pasadena
  103. address?
  104.  
  105. >    - 32/64 bit VRAM Chip Memory ( could be DRAM for mid range machines )
  106.  
  107. Pass on the DRAM please.  64bit VRAM seems like a minimum for work designed
  108. to be one year in the future.  128bit would have been better....
  109. [Hey, I can't afford an SGI, doesn't mean I don't want one :)]
  110.  
  111. >    - 57/114 MHz pixel clock
  112.  
  113. Hmm, 1280x1280x60 pretty easily there....  That seems very reasonable for
  114. future chipsets.
  115.  
  116. >    - Chunky Pixel Mode as well as Bit Planes Modes ( Blitter works with
  117. >      both )
  118.  
  119. About time -- 24bitplanes are kinda sloppy...
  120. Plus bitplanes and wide busses often give rise to bizarre alignment pre-
  121. conditions....
  122.  
  123. >    - 1280 x 1024 24 bit color 72 Hz Refresh Rate
  124.  
  125. Okay, BIG quesiton here.  This is REALLY THE QUESTION I'm posting this
  126. whole message because of!
  127.  
  128. Is this really 1280x1024x24?  Or is it simply a note that says -- hey,
  129. we have a 24bit palette in our hi-res mode?  The former is impressive, the
  130. latter is marketing ;)
  131.  
  132. >    - 16 bit 8 channel 100KHz sampling rate Audio ports
  133.  
  134. Impressive. So is lots of other stuff.  Let's hope they get the
  135. audio state machine -fixed- this time :)
  136.  
  137. >    - New 'On-Demand' DMA Architecture for Balanced DMA Usage
  138.  
  139. You're kidding, right?  This is for us "balanced" dweebs out there that
  140. keep longing for the days when our systems seemed "balanced".
  141.  
  142. What the devil does this really mean?
  143.  
  144. >    - 12 to 20 x Memory Bandwidth Increase ( mostly from VRAM )
  145.  
  146. AGAIN!  Over ECS, over AGA?  20x over ECS doesn't give me a non-interlaced
  147. 1280x1024x24 screen.  Or is this memory bandwidth related to CPU<-->chip
  148. as opposed to chip-->video?  I imagine quite a rise in bandwidth given the
  149. higher bus clock (28Mhz?) and the use of dual-ported VRAM....
  150.  
  151. 20x over AGA is too incredible to believe.
  152.  
  153. What I really want to know is -- what are the max. screen modes -- what
  154. resolutions, what "bitplane" depth?
  155.  
  156. 1024x768x24 seems to be a minimum from where I stand, interpolating one
  157. year into the future....  3-5x AGA screen resolutions, though, seems still
  158. like catchup to current SVGA bandwidth -- hardly the right target to
  159. shoot at.  [Eliminate FUD, thank you :)]
  160.  
  161. >    - 24 bit True Color Mode
  162.  
  163. Guess the question (hint: resolution?).
  164.  
  165. >    - Video Upgrade module ( You can add more chips for parallel processing
  166. >     chip set i.e. multiple blitters, and Higher Resolution Display Modes )
  167.  
  168. Like I really am going to believe this?
  169. Really, I'd prefer a wider CHIPbus....  What is more than one blitter going
  170. to do for me?  I've only -got- one bloody bus (or do I?).
  171.  
  172. >    - Hardware Graphics Decompression Modes
  173.  
  174. GDM == HAM/DYUV/MPEG?  This is a great way to market HAM, is that what they're
  175. doing or are we getting real-time JPEG or something like that....
  176.  
  177. >    - ECS & AGA compatibility
  178.  
  179. Sure....
  180.  
  181. >    - 32 bit Processor Independent Processor Bus ( hinted at RISC by 
  182. >      calling the bus 'RISC ready' )
  183.  
  184. It actually sounds like Lew is trying to raise market expectations for
  185. RISC in the public, forcing Cmdre's upper management to actually commit
  186. to such a product.  This is not unheard of, though it's a really crappy
  187. way to run a company.  If true, this is hardly Lew's fault....
  188.  
  189. At anyrate, I'm all for RISC, so tell me the dweeb I have to shoot to make
  190. this possible :)
  191.  
  192. This sounds like an interesting bus, though....
  193.  
  194. >- There are no plans for virtual memory.
  195.  
  196. Bad, very bad.  For a hardware person, ain't doing too bad.  But this is
  197. a VERY BAD MISTAKE INDEED!  [Hint -- saying "we won't..." will illicit this
  198. type of response....]
  199.  
  200. >- Commodore will release a series of Quad-Syncing monitors in February to 
  201. >  replace their current series.
  202.  
  203. I'll pay the extra price for a Japanese as opposed to Taiwanese import....
  204. I don't want my video having the "shakes" or the "shimmies" thank you, and
  205. every 1950 monitor I've ever seen looks like it needs additional shielding....
  206.  
  207. >- Full motion video support is well on its way.  The feature is here now, but
  208. >  the development systems for this technology is not.
  209.  
  210. Software....
  211.  
  212. >- Prime goal with the CDTV is to cost reduce it and then enhance it.
  213.  
  214. Got that upside down, methinks.
  215.  
  216. >  Instead of being last to bring something out, Commodore is
  217. >  going to be first or second.
  218.  
  219. I'll be the judge of that...
  220.  
  221. >- DSP technology will be available for the A4000 in summer.  DSP will feature
  222. >  the AT&T 32000 series DSP and a 68040 processor module for the A4000.  A
  223.  
  224. AT&T 32000?  AT&T3210?  AT&T32C?
  225. Never heard of the first, might it be ne of the last two?  :)
  226.  
  227. >- A new, higher performance Ethernet card will be available soon, after
  228.  
  229. IE: ZIII?
  230.  
  231. >- Retargetablity is a major goal, and Audio will merge with DSP ( this didn't
  232.  
  233. Well, our friendly audio system's state machine is kinda messy anyway, I
  234. wouldn't mind seeing something better....
  235.  
  236. >  The NewTek people are very difficult to 
  237. >  work with and are resistant to change.
  238.  
  239. Does this remind us of someone?  It's almost a sure sign that, in a battle
  240. between two foes, the accusations that come out of mouth A are more
  241. applicable to person A than person B....  :)
  242. Hence, I suppose, the phrase "takes one to know one."
  243.  
  244. >  I believe he said that if you had one, you can have it fixed on your
  245. >warrantee.
  246.  
  247. I'd rather have it fixed on my desk  (da dum).
  248. [Light humor, make sure I don't get flamed for other things I'm saying here]
  249.  
  250. >More than one year....
  251.  
  252. It was more than one year in September.  It should no longer be more than
  253. one year :)  Not if they truly want to be "first or second".  That concerns
  254. the high-end.  While the low-end is interesting, if the high-end is
  255. promising I could live without it....  :)  Assuming the high-end found its
  256. way into an A1200 style computer....
  257.  
  258. >First design cycle....
  259.  
  260. Someone familiar with chip design cycles?  What does this mean?  How many
  261. cycles does one usually go through?  Does this mean they have a prototype
  262. on someone's desk, or just that the design got run on a simulator?
  263.  
  264. >  The results of this cycle are better than expected and they
  265. >  are ahead of their development plan.
  266.  
  267. Cmdre's design did always seem to be conservative (expecting the worst) --
  268. except maybe where heat dissipation is concerned :)
  269.  
  270. >While he did metion that the exact CPU has not been decided,
  271.  
  272. If something as basic as a CPU hasn't been decided on, then I can only
  273. conclude that this is a pipe-dream.  An interesting one, to be sure, but
  274. one that hasn't been sold to the people that say "OK, go do it".
  275.  
  276. Opinion only, as usual.
  277.  
  278. >a RISC Amiga will be able to run not only UNIX, but Windows NT.
  279.  
  280. Well, if ever I heard a reason for NTs demise :) :)
  281.  
  282. >I am very excited about the future of the Amiga.  The new features are
  283. >nice, but the best part is that, clearly, Commodore has a plan.  This plan
  284.  
  285. Bingo -- a plan is good.
  286. A plan is long overdue.
  287. A plan that says "we will do" instead of "we won't do/it's hard for us to do/
  288. it takes time for us to do" is, like, way OVERdue....
  289. Now, I'd like that same logic applied to the software.  Where VM and Mem.
  290. Prot. is concerned we're still in the "we won't do" phase.  It's going to
  291. be a long haul, sigh....
  292.  
  293. >[Lew] is very capable and has had much success in the industry.
  294.  
  295. Let's try and keep this one in a position to make a difference, shall we?
  296.  
  297. David C. Navas                        dnavas@oracle.com
  298. Working for, but not speaking on behalf of, Oracle Corp.
  299.