Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!ai-lab!geech.ai.mit.edu!rjc From: rjc@geech.ai.mit.edu (Ray Cromwell) Newsgroups: comp.sys.amiga.graphics Subject: Re: Colorburst and Animation Message-ID: <14058@life.ai.mit.edu> Date: 16 Mar 91 01:48:17 GMT References: <13948@life.ai.mit.edu> <1991Mar14.231042.26446@ncsu.edu> Sender: news@ai.mit.edu Organization: The Internet Lines: 86 In article <1991Mar14.231042.26446@ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >In <13948@life.ai.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >>>Now sure, you can fill up the CHIP ram with a limited amount of preset data, >>>use lower bits/pixel, slow down fps, and so on. You can bet that demos do >>>just that. But any way you cut it, their 5.5MB/s figure is akin to those >>>common hard disk xfr specs which ignore seeks, etc.... it's a best-case, >>>limited duration transfer rate... dependent upon source data availability. >>> >> Your example provides a worst case scenario, I am going to provide the >> best case. Clever tricks are always availible to help: >> [ clever trick follows :-] > >You're absolutely right; in fact my friend and I had also immediately >thought of turning off vid DMA during reload (actually, I think you'd only >need to go to a lower res). So as we've both now mentioned (and most >people would've inferred), there are several techniques they could use >to aid in transferring the data... no argument there. > >> So it takes a total of 1/30th + 1/15th second to insure colorburst >> gets a frame constantly. This amounts to 20fps which is acceptable. > >Ooops :-). That totals 3/30th second, which is _10fps_ at 320x200x24. Double oops. I made a mistake. It's not 1/15th, it's 1/60th. I was was dividing 1/30 in half, I (stupidly) halved the denominator instead of doubling it. Using movem's (copymemquick()) with video dma off, you can transfer almost an entire colorburst frame to chip in 1 screen. (the processor will get every availible slot in addition to the horizontal and vertial blanking areas it usually gets) In the worst case (because of overhead) it would take 2 frames to xfer a complete colorburst frame. No problem, 1/30 + 1/30 = 15 frames per a second which is acceptable. Lot's of HAM ANIM's out there only run at 15fps. >Or roughly 5fps at 320x400x24, 20+fps at 320x200x12, and so on. >Which was my main point. The resulting steady rate of 1.9 megabytes/sec >for the given example is not quite what was originally proposed: > >>>> The Colorburst transfers data at 5.5 megabytes/sec through the db23 port. >>>> A lo-res screen is 40bytes widex200 lines deep x 24 bits. That's 192k, >>>> at 5.5mb/sec gives up 30 frames per second. > >That was, as I replied, a short duration best-case scenario for fullscreen, >fullmotion. In addition, you would lose the use of your Amiga screens while >all that was going on, which might be a factor for some users. > >> Colorburst is a great deal, even if it couldn't animate, which it can. > >It's definitely priced extremely well for what you get; there never was >any debate from me on that subject :-). And knowing that animations >are rarely full-screen, and can be dropped in plane count, I've never had >any doubt that nice animation was possible on it. My friend and I just >always cringe when we see top specs stated with no limitations or caveats. >More info was needed to see the whole picture. I think you and I have >covered things now . best regards - kev Yep. I'd certainly want one. Heh, I can picture a multimedia presentation with a small 160x100 window of 24bit animation on the screen. Now that I think about it, HAM-E and DCTV are going to have more of a problem animating than Colorburst. You could easily reduce Colorburst to 12bit mode and get 4096 colors out of 16.7 million and do animation. HAM-E and DCTV can't use the trick of turning video DMA off since they depend on the 'magic cookie' byte sequence at the top and sides of the screen to activate them. HAM-E and DCTV both use a hi-res screen to get a lo-res screen with more colors. HAM-E uses 4 bitplanes, DCTV uses 3 or 4. So DCTV may be able to animate (3 hires bitplanes=same processor lock out as HAM.) But in 4 bitplane mode, the processor gets locked out completely except for the horz and vert blanking periods. Keep in mind, I'm only speculating. I don't know the capabilities of HAM-E or DCTV since I don't own either of them. But it looks like they will have the same animation problems as colorburst. Except Colorburst uses a SEVERELY overscanned screen to send the most data out in one frame. HAM_E and DCTV may be able to animate because the processor isn't locked out as much. I don't feel like calculating it right now. Anyone with a HAM-E or DCTV want to comment? Also, for those of you who went to AmigaWorld EXPO, why not type up a summary of what was shown and your impressions and post them to c.s.a.reviews? It would be a big benefit to those of us unfortunate enough not to be there. :-)