home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / atari / st / 16337 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  3.2 KB
  1. Path: sparky!uunet!ukma!wupost!usc!chaph.usc.edu!phakt.usc.edu!not-for-mail
  2. From: baffoni@phakt.usc.edu (Juxtaposer)
  3. Newsgroups: comp.sys.atari.st
  4. Subject: Re: WHAT'S GOING ON ?
  5. Date: 6 Nov 1992 14:05:46 -0800
  6. Organization: University of Southern California, Los Angeles, CA
  7. Lines: 49
  8. Message-ID: <1deq7qINNp0d@phakt.usc.edu>
  9. References: <cdf1tb+@rpi.edu> <1992Nov3.101001.12943@elroy.jpl.nasa.gov>
  10. NNTP-Posting-Host: phakt.usc.edu
  11.  
  12. In article <1992Nov3.101001.12943@elroy.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes:
  13. [stuff deleted]
  14. >Personally I think the processor-direct slot is an albatross, just cements the
  15. >machine to the past. There's no reason to go with any "expansion" technology
  16. >that only lets you plug in one expansion device. The Mega STe and the TT have
  17. >a VMEbus slot, I think this should be the standard expansion bus technology
  18. >used for all STs. (I.e., if you're gonna talk about shoehorning a new type
  19. >of expansion onto an old ST, please choose VMEbus, which is a well-established
  20. >standard, instead of going with yet another custom single-device nobody-else-
  21. >in-the-world-uses-it expansion method.)
  22.  
  23.     I have to disagree.  A PDS is the only way to go for CPU upgrades or
  24. other products that require a 0waitstate operation within the machine.  What 
  25. good would it be to have a 50MHz '040 if _every_ access to main memory incurs
  26. one or more waits?  I agree that VME is a good bus architecture - 1WS incurred
  27. very fast, and with the larger bus (6U) it is accesses about everything the CPU
  28. can.  The point is that not everything is appropriate for an external bus like
  29. that.  True, you don't want to put your graphics adapter in a PDS (unless, like
  30. the Falcon it is the only one you have :( ) but you don't want the '040 in the
  31. VME either.
  32.  
  33. >VMEbus is not very different from what you'd have to cram into a processor-
  34. >direct slot. The difference in bus control/arbitration additions is negligible
  35. >now since you can get single-chip VME bus interface controllers and such.
  36.  
  37.     One waitstate (80ns or less) doesn't sound like much...until you try
  38. to access memory.  It is questionable whether a VME based DSP/sound sytem would
  39. do well, besides lacking the ability to bus master (on the Atari, not the spec)
  40. so that sound DMA to the DSP or other chips (like DAC/ADC) would be impossible.
  41. I am not saying that you couldn't transfer to those chips very quickly - 
  42. bandwidth to the 16-bit/8chnl ADC/DAC would only be max 800k/s, but that is not
  43. insignificant even on the TTbus, let alone the MegaSTe bus.  However, a PDS 
  44. based DSP/sound system would definately work (if the PDS supported bus 
  45. mastering, all data/address/interrupts ).  Too bad the MegaSTe and the TT
  46. don't have a (decent) PDS.
  47.  
  48. >Of course, you don't need to put *everything* on the VMEbus. It still makes
  49. >sense for system RAM and ROM to live on a private bus, just like the way STs
  50. >and TTs already work. But you could stick myriad enhancements on the VME -
  51. >graphics boards, custom coprocessors, ethernet network controllers, serial
  52. >port multiplexors, etc. etc. etc... VME is definitely the best way to go.
  53.  
  54.     Agreed.  For those (relatively) low bandwidth applications.
  55.  
  56. >  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
  57. >
  58. >All true wisdom is conveyed in one-line witticisms.
  59.  
  60. -Mike
  61.