home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / amiga / graphics / 5273 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  2.7 KB
  1. Path: sparky!uunet!olivea!decwrl!purdue!mentor.cc.purdue.edu!nova.cc.purdue.edu
  2. From: ab@nova.cc.purdue.edu (Allen B)
  3. Newsgroups: comp.sys.amiga.graphics
  4. Subject: Re: OpalVision
  5. Message-ID: <54920@mentor.cc.purdue.edu>
  6. Date: 23 Jul 92 20:24:18 GMT
  7. References: <14mulcINNnbj@matt.ksu.ksu.edu>
  8. Sender: news@mentor.cc.purdue.edu
  9. Lines: 60
  10.  
  11. In article <14mulcINNnbj@matt.ksu.ksu.edu> strat@matt.ksu.ksu.edu (Steve Davis)  
  12. writes:
  13. > ab@nova.cc.purdue.edu (Allen B) writes:
  14. > >The device can run a 24 bit buffer at 768
  15. > >x 480 from just the data available on the RGB port?  I'm not
  16. > >contesting the video slot version, but the RGB port? 
  17. > 
  18. > No, it is a real frame buffer.  The 24-bit image is created and
  19. > held internally, but the external device is *CONTROLLED* through
  20. > the RGB port in this case, and the data appears either above or
  21. > below the video data coming over the port.  It works just like an
  22. > external GENLOCK in this sense.
  23.  
  24. It's got to get all its data from the RGB port if that's the
  25. only connection to it.  I'm aware it has its own memory, but
  26. it's got to be filled via the RGB port if that's where it's
  27. connected.
  28.  
  29. > >784 * 482 * 30 * 4 = 45346560 bits per second
  30. > 
  31. > But, unfortunately, the video bus would be unable to cope with a
  32. > continuous stream of raw data at this speed.  :-(
  33.  
  34. Your RGB port does it all day long.  Scary, isn't it?  But to
  35. feed a box hanging from your RGB port, you need to push the
  36. data in through the Amiga's screen buffer.  You can't push
  37. as fast as it pulls.  So, I'm asking, how fast can expect to
  38. push data to OpalVision? 
  39.  
  40. I ask because they claim the Amiga 500/600 version hangs
  41. from the RGB port instead of being a card inside the
  42. machine.  If there's another connection to the unit, my
  43. questions are answered. 
  44.  
  45. > >So what's the scoop?  Tell me tell me tell me.  I think the
  46. > >makers of OpalVision are not telling us the whole truth.  I
  47. > >want numbers and I want explanations that match with
  48. > >reality.
  49. > 
  50. > Like I said, the image data is created in the device.  They don't
  51. > advertise 30fps animation in 24 bits, so don't expect to get it! :-)
  52.  
  53. My "image data" is most certainly not >created< in the
  54. device!  If I load an image from disk, it's got to go out my
  55. RGB port to get into the buffer.  That's what I'm talking
  56. about.  I question the throughput of this connection.  
  57.  
  58. I'm aware it's held out there, but it has to >get< there. 
  59. That seems problematic to me, but it really depends on how
  60. they encode the data.  That's what I want to know.
  61.  
  62. I especially want to know how I can change OpalVision's
  63. buffer while I'm displaying useful stuff on the Amiga's
  64. screen. 
  65.  
  66. (Maybe I didn't make myself clear.  I think I'm pretty up on
  67. the forces at work here.  I know what a frame buffer is and
  68. what is and is not available on the Amiga's RGB port. :-) )  
  69.  
  70. ab
  71.