home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 5308 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.8 KB

  1. Path: informatik.tu-muenchen.de!fischerj
  2. From: fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: doubling pixels horizontally
  5. Date: 12 Mar 1996 18:38:38 GMT
  6. Organization: Technische Universitaet Muenchen, Germany
  7. Distribution: world
  8. Message-ID: <4i4gbe$9av@sunsystem5.informatik.tu-muenchen.de>
  9. References: <4f4ibc$gl9@news.cs.tu-berlin.de> <591.6610T1165T2102@login.eunet.no><1045.6611T753T2256@vip.cybercity.dk><4faoe1$47@sunsystem5.informatik.tu-muenchen.de><2991.6612T1034T625@vip.cybercity.dk><576.6613T1070T1730@login.eunet.no><1257.6614T57T922@vip.cybercity.dk>   <1982.6617T1096T103@ifi.uio.no> <4gbjg3$104@sunsystem5.informatik.tu-muenchen.de>  <4518.6625T1142T92@ifi.uio.no> <4h4hv5$mnn@sunsystem5.informatik.tu-muenchen.de> <2444.6635T982T1557@ifi.uio.no>
  10. NNTP-Posting-Host: hphalle10.informatik.tu-muenchen.de
  11. Originator: fischerj@hphalle10.informatik.tu-muenchen.de
  12.  
  13.  
  14. In article <3072.6644T1140T2815@ifi.uio.no>, ludvigp@ifi.uio.no (Ludvig Pedersen) writes:
  15.  
  16. |> >so anyone of us got a bug or 030 is very different here ?
  17. |> 
  18. |> Its not a bug, bustest also confirmed that. Reading from fastram, move.l is
  19. |> faster than movem. But on writing movem is faster! :-)
  20.  
  21. well, it rather looks like movem read has become slower vs. 020 :\
  22.  
  23. |> 
  24. |> >Do those "free c2p" routines really run 5.6 mb/sec ?
  25. |> 
  26. |> Hehe, no, but you usually don't play Doom without any bitmap-DMA, do you! ;)
  27.  
  28. grrrrrr ;) But it's a useful information for a coder what speed a routine
  29. can go with dma off.
  30.  
  31. |> If you turn on 256 colors you get a slow-down.
  32.  
  33. uh, I didn't know that. :D
  34.  
  35. |> >I said "very fast cpu" and "aproxiamte 7mb/sec" :)
  36. |> 
  37. |> You should have said something like a fast cpu with 1+ MB internal cache! ;)
  38. |> But that would be cheating! :-)
  39.  
  40. or maybe a cool PPC board...
  41.  
  42. |> What is LAME? >:( That you have problems with you math again? :-)
  43.  
  44. probs _again_ ? what ?
  45.  
  46. anyway I parsed your sentense wrong, I thought you get 203300 dbra's per
  47. second. more a language prob than a math prob ;)
  48.  
  49. |> >what ?
  50. |> 
  51. |> What you forget is that a move uses 2 clock cyles.
  52.  
  53. but if I do dbra I won't look at the move cycle-table ;))
  54.  
  55. |> 
  56. |> ONE clock cycles is 20 ns. So TWO clock cycles must be 40 ns.
  57. |> 
  58. |> How *hard* can it really be??? This is pretty elementary math! ;-)
  59.  
  60. hey wait a minute, I'm master of theoretic cycle calculation if
  61. given proper data, I already released 020-14 fastmem timings
  62. before having fastmem in my A1200. baeh! :)
  63.  
  64. we talk about mem moves. i.e 
  65.  
  66. >> move.l (an)+,(an)+ << and nothing more. 
  67.  
  68. where is the move reg,reg you (and writer of bustest) talk about ? ;)
  69.  
  70. |> >yep. no need for ghost-look doing doom, descent etc.
  71. |> >just intuiscreen, supporting all monitors, or genlock or whatever :)
  72. |> 
  73. |> That would be great! :)
  74.  
  75. yeah! :) imagine your routine supports rendering into a intuition window
  76. and you got a genlock.
  77.  
  78. Then you could watch TV action and simultaneously play in a 
  79. small 160x100 window having your interactive action :)
  80.  
  81. hmm genlock supporting doom engine should maybe not use color 0 for rendering.
  82. and genlock supporting demo should always use color 0 for background :)
  83. mixing amigademo with mtv :D
  84. well, genlocks are not ghostlook-compatible I guess, demo must be
  85. switched to 4pass...
  86.  
  87. |> >i.e 1084 -> most users no problemo. ghost-look looks even better
  88. |> >over composite video vs. rgb-port, because of smear (hardware-dither ;)
  89. |> 
  90. |> Dithering looks ok on a multisync too. (Atleast in PAL) But you don't get any
  91. |> smear! ;) "Lace"ing the dither is the way to go in both cases.
  92.  
  93. yep, no smear as their bandwidth is able to display white-black-white...
  94.  
  95. |> 
  96. |> 
  97. |> 
  98. |> <sb>Ludde - Amiga Demo Coder
  99. |> <sb>Virtual Reality & Official Be developer
  100. |> <sb>ludvigp@ifi.uio.no
  101. |> 
  102. ------------------------------------------------------------------------
  103.    fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)   =:)
  104.  
  105.