rjc@geech.ai.mit.edu (Ray Cromwell) (03/14/91)
From a discussion in comp.graphics: In article <1991Mar13.053548.18866@ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >In <1991Mar12.193951.634@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: >>>In article <1991Mar12.082113.16351@ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >>>Another thing to consider: I read that its RAM is loaded by sending the >>>R,G,B components as separate images from the Amiga video output lines. >>>In the highest res mode, that would take 6 Amiga display frames to do. >> >> 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. > >Yes and No. Here's the bottleneck: CPU --> DISPLAY RAM --> COLORBURST > slow--^ fast--^ > >Sure, you can easily get 5.5 megabytes/sec coming out the video connector, >or around 100K per 60Hz field. Assuming the data is sent out continously, >the Amiga could output the 192K needed for a static 320x200x24-bit picture >in 1/30th second, just as you said. > >The question is: _Where_ does all that data come from? :-) It comes >from data being placed into the Amiga display RAM. A friend and I sat >down this afternoon and did some animation figuring: > >At the res needed to output 100K/second, the cpu access to Amiga CHIP ram >(display ram to others) is tied up by video DMA around 80% of the time. >Nothing unusual; this shut-out is well known when using the Amiga display >in higher res modes. > >But in blunt terms, that means only around 3,000 16-bit transfers into >the CHIP ram can be done (obviously fewer if the cpu is doing it), >per field, at the same time as the data is being sent to the Colorburst. >At 24-bits/pixel, that's roughly a 50x40 pixel area every 1/60th second. >Maybe double that on an Amiga 3000 with 32-bit CHIP access. > >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. > >It's a useful board, but at the same time, reality must be observed :-). >Followups to c.s.a.graphics, where I'll also be happy to answer your HAM-E >questions, if you still wish. best - kev <kdarling@catt.ncsu.edu> Your example provides a worst case scenario, I am going to provide the best case. Clever tricks are always availible to help: A 320x200x24 screen is 192k In one refresh frame the Amiga can send about 100k, and in 60 frames this is the 5.5 megabytes figure we recognize. The Colorburst has 1.5mb of onboard memory, this is enough to store 8 lores 24bit screens. The Amiga can send a full colorburst frame about every 2 vertical blanks which gives us 30 frames per second assuming we had infinite chip ram or no processor lock-out. My solution? Preload the colorburst's memory with 8 frames, allocate 572k of chip ram and stuff three frames in chip. Here's the procedure to get 20fps 320x200x24 animation. 1)display frame from colorburst's memory 2)erase frame in colorburst's memory 3)display next frame from colorburst's memory 4)start transfering one colorburst frame amiga chipram (takes 1/30th second) 5)TURN VIDEO DMA COMPLETELY OFF, and copy a colorburst frame from fast memory to amiga chip memory (takes 1/15th second) 6)turn dma back on, and go to step 2 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. On a 9mb Amiga this amounts to 3 seconds of animation. This however does not take into account compression which can dramatically increase the length of the animation. I believe MAST advertised 20fps in their adds, and by simple calculations you can see it is possible. Let's stop for a second and assume colorburst was totally incapable of animation. A board that can display 24bits of true color, and in addition 24bits of overlay, with 1.5mb of ram onboard, and works with all Amiga's? And it only costs $400! The next comparable board costs $1600? Colorburst is a great deal, even if it couldn't animate, which it can. Let me give you some background. I have never read a single marketing add for Colorburst, all of my informatin on it came from their BBS directly from the designer of Colorburst, and my calculations were based on the figures from the Amiga Hardware Manual. Looks like reality has been observed at last. ;-)
tucker@tahoe.unr.edu (Aaron Tucker) (03/14/91)
People have been wondering about how the video DMA contention will lock out Amiga CPU access to chip ram and therefore reduce access speed by the CPU to chip ram. If you consider a High resolution 4 bitplane Amiga screen, (the size screen required to pass 8 bits to ColorBurst) you will find that the CPU is locked out during the Screen DMA fetching for about 80% of the time. DCTV and HAM-E all have this bottle-neck as well. BUT - With ColorBurst you can still display the full 24 bit Picture with Amiga DMA TURNED OFF! This means that you can have 100% access speed to Amiga chip ram and still display your last frame. Then after operating on your chip memory, then turn DMA back on and update that bank of ColorBurst Video RAM. Also, a different trick you could use would be to use a 3 bitplane Hi-res screen which would give 6 bits each for RED, GREEN and BLUE. you would then be shifting less data, have less display DMA contention (only about 33 % lockout) and still be displaying your Animation in TRUE 18 bit video (still pretty smooth). Remember also that ColorBurst supports full double buffered animation, Allowing you to display 1 bank while updating the other. The ColorBursts custom PROCESSOR can also be used to scroll and move 24 bit objects around at 60 fps and also page flip animate at the same time with virtually NO Amiga proc essing. A good example of this is a cute little ColorBurst demo that replaces the Amiga system mouse pointer with a 24 bit sprite (that can be as large as the whole screen) and move it at 60 fps working with ANY intuition software (eg DPAINT, WORKBENCH, DTP, WORD PROCESSORS). With the Firecracker, the Amiga CPU can only access its display memory during ] Horizontal and vertical blank (80 % lockout) also. The only way around this with video cards is to use Dual Port Video RAM on a card. But you cannot double buffer animate or scroll with firecracker. You cannot expect to be able to animate with uncompromised 24 bit at the same speed as speed as units that only shift 8 bits of data (DCTV and HAM-E) but the quality is far superior with true 24 bits. As a service to ALL ColorBurst owners, MAST is installing a full single frame edit Bureau onto Laser disk (then onto tape if desired) and unbelievably in- expensive rates. You will be able to Render your 24 bit frames and send the files to MAST and they will Put them to laser disk in RGB (Yes the laser disk recorder accepts RGB) at 30 frames a second in pure hi-res overscan 24 bit! This is a service MAST calculates to be yet another competetive edge! You may be wondering, How will I get my files to MAST if I have a 100 megabyte Animation ? MAST will supply you free of charge with an encoder to encode 300 megabytes of Data onto a standard 3 hour VCR tape with a standard VCR. You then just send us the VCR tape with the Data on it and we will send you back a laser disk or Tape. For a true 24 bit card, ColorBurst's animation is about as fast as 24 bit comes. And the quality is so much higher than DCTV or HAM-E. Gary Rayner Colorburst Designer You cannot reply to me via the INTERNET, but you can leave me a message on the MAST BBS at (702) 359-0132. Thank you for your responses and inquiries. D D D D The Firecracker also has the same problem of DMA lockout about 80%
mark@calvin..westford.ccur.com (Mark Thompson) (03/15/91)
In article <5739@tahoe.unr.edu> tucker@tahoe.unr.edu (Aaron Tucker) writes: >As a service to ALL ColorBurst owners, MAST is installing a full single frame >edit Bureau onto Laser disk (then onto tape if desired). > MAST will supply you free of charge with an encoder to encode 300 >megabytes of Data onto a standard 3 hour VCR tape with a standard VCR. >You then just send us the VCR tape with the Data on it and we will send you >back a laser disk or Tape. Wow! This is quite a service! I would be interested in hearing more, including the rates. %~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~% % ` ' Mark Thompson % % --==* RADIANT *==-- mark@westford.ccur.com % % ' Image ` ...!{decvax,uunet}!masscomp!mark % % Productions (508)392-2480 (603)424-1829 % % % ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kdarling@hobbes.ncsu.edu (Kevin Darling) (03/15/91)
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. 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 <grin>. best regards - kev <kdarling@catt.ncsu.edu>
jlange@oracle.com (Jim Lange) (03/15/91)
In article <13948@life.ai.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes:
Your example provides a worst case scenario, I am going to provide the
best case. Clever tricks are always availible to help:
A 320x200x24 screen is 192k
In one refresh frame the Amiga can send about 100k, and in 60 frames
this is the 5.5 megabytes figure we recognize.
The Colorburst has 1.5mb of onboard memory, this is enough to store
8 lores 24bit screens.
Also, the Colorburst apparently allows selectable bit-plane depth with full
24-bit color look-up. So you could conceivably use 8, 10, 12, or 16 bits per
pixel for 256, 1024, 4096, and 65536 colors respectively out of 16.7 million
(this assumption is based on what little information I have on the board).
I would expect 4096 colors from a palette of 16.7 million to look quite good.
Does anyone know if the Colorburst will come with software that will allow a
series of 24-bit pictures to be converted into some kind of special anim file
that takes advantage of all these ColorBurst specific tricks?
I also get the impression that the Colorburst is somewhat programmable. Would
it be possible to program it to support special HAM-like modes for extended
colors with fewer bitplanes (ala HAM-E)?
It does sound like a very exciting product. I was ready to buy DCTV or HAM-E,
but now I am prepared to wait until I can at least see the Colorburst in
action.
Jim Lange
Oracle Corporation Jlange@oracle.comtinyguy@cs.mcgill.ca (Yeo-Hoon BAE) (03/16/91)
One thing I always wondered about 24bit cards: Is it really necessary to use all 24 bits? From quick calculation, 18 bits are more than enough to display 640x400 screen with every pixel having different colors. So why not have 24 bit palettes and use 18 bits or less for the lower resolutions? This should give some improvements to the overall animation performance... +-----------------------------------------------------------+-------------+ | Yeo-Hoon Bae tinyguy@homer.cs.mcgill.ca | Amiga /// | | Dept. Computer Science, McGill University, Canada | 2000 /// | |-----------------------------------------------------------| \\\/// | | Amiga2000 + 5MB + 104MB + KX-P1124 + DiamondScan + A2320 | \XX/ | +-----------------------------------------------------------+-------------+
cullip@sargent.cs.unc.edu (Timothy Cullip) (03/16/91)
In article <1991Mar15.193235.2926@cs.mcgill.ca> tinyguy@cs.mcgill.ca (Yeo-Hoon BAE) writes: > >One thing I always wondered about 24bit cards: > > Is it really necessary to use all 24 bits? > From quick calculation, 18 bits are more than enough to > display 640x400 screen with every pixel having different > colors. So why not have 24 bit palettes and use 18 bits > or less for the lower resolutions? This should give some > improvements to the overall animation performance... > > The problem is that with 24 bits you have true color and don't need a color lookup table (or palette as you would call it). The 24 bits directly define the color. If you wanted say an 18 bit frame buffer with a palette of 24 bit entries you need 2^18 entries (each 3 bytes). Now the 18 bits don't directly define the color but rather an address into the palette that holds the color (indirect color). This is 7.8 Mbytes for the palette table. So now your palette table is larger than your frame buffer! Most people don't use palette tables above for frame buffers above 16 bits but rather go with true color. -- Tim Cullip cullip@cs.unc.edu
raible@cbmvax.commodore.com (Bob Raible - LSI Design) (03/16/91)
In article <1991Mar15.193235.2926@cs.mcgill.ca> tinyguy@cs.mcgill.ca (Yeo-Hoon BAE) writes: > >One thing I always wondered about 24bit cards: > > Is it really necessary to use all 24 bits? > From quick calculation, 18 bits are more than enough to > display 640x400 screen with every pixel having different > colors. So why not have 24 bit palettes and use 18 bits > or less for the lower resolutions? This should give some > improvements to the overall animation performance... > > Unless I misunderstand your question, I believe you are confusing palette depth and width. 24 bits refers to the width of the palette output, in this case 8 bits of red,green, and blue. This means that over 16 million colors are displayable, and you are correct in stating that this greatly exceeds the 307,200 pixel positions on a 640 by 480 screen. However this is pretty much irrelevant since often what we desire to do is display 307,200 pixels in colors thta are indistinguishable from the colors of the original image. In this case there are two separate issues. First do we have sufficient DEPTH in the palette to display the image? Obviously in the case of VGA display systems 256 colors is spreading things pretty thin(256 vs 307200). The second issue is whether we have sufficient color resolution(palette width) to accurately display an individual pixel. Often in the case of flesh tones or solid modeling we have pixels in adjacent screen positions that are only slightly differeentiated. In this case palette width is extremely important and 24 bits might not be enough. I hope this has helped explain the roles of palette width and depth, and why 24bits really has no connection to display size.
rjc@geech.ai.mit.edu (Ray Cromwell) (03/16/91)
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 <grin>. best regards - kev <kdarling@catt.ncsu.edu> 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. :-)
sschaem@starnet.uucp (Stephan Schaem) (03/17/91)
320x200x12 at 20 frame second? the amiga video dma can 'support' 320x200x8 at 60 frame second, to do the transfere use hires. But you can transfer MORE in 1/60 of a second... why stop the video dma? I dont know what colorburst can support, but you can have the video working for more than 250 lines and horizontal 'overscan'. So lets say that you want to transfer only... use the sprite DMA also.so start at 24 and go to 216.So (216-24)*16 /8 = 384. put hires you get 384*2=768 pixel wide with 4bitplane in hires. So in less than 2 frame you can transfere for a 320x200x24 screen... Thats 30 frame second to me.... or Am I misiing something in the calculation (suposed colorburste support 768*250*4. HOOPS sory with 255 line verticaly you just transfer a 320x200x24bit screen a the BIT CLOSE:-) To take a closer look: 320*200*24 / 8 = 192000 bytes AND : 768*250*4 / 8 = 96000 bytes :-) time 2 now... S So to correct things up, a 320x400x24 bit image can be animated at 15 frames seconds... And what can I say a 320x200x12 at 60 frame second! not 30! 1280x1024x24 ? I think know people can anderstand why real time 3D (or 4d graphics are OUT of this worlds:-) Also with some calculation you could animate 50 sprites of 16X16 in 24 biplane during the transfere and have the blanking gap all for yourself:-) If you have a 68020 or best (cache) and even better a fast memory bus, well you could do magic! If MAST can confirm you can transfer with a screen of 768x250x4 (Amiga posible without problems, on any in the world:-) than you can have FULL screen anymation with 50 24bit color sprites on it. And with if you can do block transfere?! you can have a full 2 24 bit map (like the bay area) scrolling at 60 frames seconds in 640x400x24. (if colorburst support). The FUN thing would be a dual playfield support, setting all second plane to the background color and transfere screen that way, not disturbing you WB display during buffer fill... I like to play with display processor (since I made a 70 frame second display on a 1084 without the video processor , all DMA cut, only with a 68020 running the all thing..I can stop:-). And by the way there is a way to put a 1084 in 50hz mode by changing to video beam position...
sschaem@starnet.uucp (Stephan Schaem) (03/17/91)
Since not the all 17million colors are used, you have ALWAY a range to assign a color transletion before output... So you can have a small buffer assign to an unused aray and use the array for the lookup. Also 1280x1024x24/8 is 3840K.
kdarling@hobbes.ncsu.edu (Kevin Darling) (03/17/91)
In <14058@life.ai.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >>> 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. >> >> [and I reply] -- >> 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. [...] > Using movem's (copymemquick()) with video dma off, you can transfer > almost an entire colorburst frame to chip in 1 screen. [ = 15fps] Better make that triple oops :-). I was being generous letting you say 192K can be moved in only 1/15th second. Considering that an impossibly best case transfer (no waits, totally zero overhead) with a 68000 will take 4 cycles to read 16-bits, and 4 cycles to write those 16-bits back out, I'll let you do the calcs yourself for the full memory updates/second: (amiga 68K cycles/sec) / (96,000 words/frame * 8 cycles/word) So even 10fps is unlikely for fullscreen 24-bit animation in the situation we were talking about, unless perhaps you have the A3000 32-bit CHIP access, or full memory DMA, etc. Otherwise, continuous 7fps transfers, maybe. > Now that I think about it, HAM-E and DCTV are going to have more of a > problem animating than Colorburst. Depends on the resolution, width, etc. But first a comment: someone inadvertently claimed that HAM-E/DCTV would have the same 80% CHIPRAM lockout as the Colorburst. Obviously for 320x200 this is untrue. The Colorburst at 320x200x24 requires extra CHIP bandwidth to send the larger data (24-bit) as quickly as possible. But at 320x200x8, the others' continuous lockout will "only" be about 55%. Still, some rough figuring indicates that the Colorburst (by cutting down the video DMA when needed) could, even at 12-bits, keep up with the 8ers. At 8bits/pixel, it can be twice as fast; at 24, twice as slow as them. > You could easily reduce Colorburst > to 12bit mode and get 4096 colors out of 16.7 million and do animation. Now _that_ is impressive. You're saying that it has enough fast palette RAM to hold 4096 24-bit colors?! Decent! Or is another technique used? Thx! kevin <kdarling@catt.ncsu.edu>
peterk@cbmger.UUCP (Peter Kittel GERMANY) (03/20/91)
In article <1991Mar15.193235.2926@cs.mcgill.ca> tinyguy@cs.mcgill.ca (Yeo-Hoon BAE) writes: > > Is it really necessary to use all 24 bits? > From quick calculation, 18 bits are more than enough to > display 640x400 screen with every pixel having different > colors. So why not have 24 bit palettes and use 18 bits > or less for the lower resolutions? Indeed, 24-bit palettes were nice to have, BUT: Do you know one existing chip that can hold that palette data (or color lookup table)? Remember, you want 2^24 entries in your palette with 18 bits each, this is, well, let's calculate, 48 Megabytes. Umpf, a little much for a CLUT chip, or what? (I love such speculations:) And the reason to use palettes is to have such nice effects like color cycling easily available. Now a Copper or someone would have to cycle 16 million palette entries at maximum. Let me guess that this color cycle would not turn out as the fastest one on earth :-) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
neil@celia.UUCP (Neil Richmond) (03/20/91)
In article <19919@cbmvax.commodore.com> raible@cbmvax.commodore.com (Bob Raible - LSI Design) writes: >In article <1991Mar15.193235.2926@cs.mcgill.ca> tinyguy@cs.mcgill.ca (Yeo-Hoon BAE) writes: >> >> Is it really necessary to use all 24 bits? .spreading things pretty thin(256 vs 307200). The second issue is whether .we have sufficient color resolution(palette width) to accurately display .an individual pixel. Often in the case of flesh tones or solid modeling .we have pixels in adjacent screen positions that are only slightly .differeentiated. In this case palette width is extremely important and .24 bits might not be enough. I hope this has helped explain the roles .of palette width and depth, and why 24bits really has no connection to .display size. Actually, I have seen some amazing pictures in 8 bits. Thses were scanned in photos of peoples faces. They virtually indistingushable from 24 bit pictures. Oddly, or maybe not so oddly, the computer generated images suffered the most from only being displayed in 8 bits. With the right algorithms, you can make an excellent image in eight bits. neil -- Only 3210 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
sschaem@starnet.uucp (Stephan Schaem) (03/20/91)
Talking about 68000 cycle for calculating Colorburst transfere is
totaly wrong!.
You dont need to cut the video DMA and use the processor to replce
it by write data yourself.
Since Colorburst is on the RGB port, th only way to send data is
with the video processor or bypassing the dma (if you need to get
data from the 32bit memory).
I already wrote a post with the actual figure.and you get a
320x200x24
at 30 frame second.and a 640x400x24 at 7 frame second (full
screen
animation).
Using hires 'overscan' data 'transfere'.
Video DMA access the chip bus every cycle, not the 68000.And again the
CPU will be use the do transfer over the RGB port for non chip data (
and only 4 time slower from my tests).
Colorburst use the bus at the same rate has a 4bit DCTV overscan display
but update frame 6 time slower.(1 buffer example, if both are in chip).
DCTV simply change the dma adress, and first time it pass trought the
RGB port its displayed But you need 6 more pass for Colorburst.
You have 192 bus cycle per HLine, and let set YLine to 250.
thats 5760000 bytes transfer per second.a 320x200x24 is 192000bytes
and if you divide... you get 30, 30 frame seconds...
30 frame second is VERY nice! and you can get 15 frame second in
320x200x24 with 0 bus cycle stolen from the 68000!!!
So you can update/create/decompact/read you next frame while display the
previews one, transfering the curent...mark@calvin..westford.ccur.com (Mark Thompson) (03/21/91)
In article <947@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: >Actually, I have seen some amazing pictures in 8 bits. Thses were scanned in >photos of peoples faces. They virtually indistingushable from 24 bit pictures. Truly amazing was the IVS demo at the AmigaWorld Expo where they used DCTV with only *3 bitplanes* to do realtime playback of a digitized "Back to the Future III" sequence from a hard drive. Even though only 3 bitplanes were used, it looked like it was coming right off of video tape. If only computer generated imagery compressed so well. %~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~% % ` ' Mark Thompson % % --==* RADIANT *==-- mark@westford.ccur.com % % ' Image ` ...!{decvax,uunet}!masscomp!mark % % Productions (508)392-2480 (603)424-1829 % % % ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jlange@oracle.com (Jim Lange) (03/21/91)
In article <13948@life.ai.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: > A 320x200x24 screen is 192k > In one refresh frame the Amiga can send about 100k, and in 60 frames > this is the 5.5 megabytes figure we recognize. > The Colorburst has 1.5mb of onboard memory, this is enough to store > 8 lores 24bit screens. > The Amiga can send a full colorburst frame about every 2 vertical blanks > which gives us 30 frames per second assuming we had infinite chip ram or > no processor lock-out. > My solution? Preload the colorburst's memory with 8 frames, allocate > 572k of chip ram and stuff three frames in chip. Here's the procedure > to get 20fps 320x200x24 animation. > 1)display frame from colorburst's memory > 2)erase frame in colorburst's memory > 3)display next frame from colorburst's memory > 4)start transfering one colorburst frame amiga chipram (takes 1/30th second) > 5)TURN VIDEO DMA COMPLETELY OFF, and copy a colorburst frame from fast memory > to amiga chip memory (takes 1/15th second) > 6)turn dma back on, and go to step 2 > 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. > On a 9mb Amiga this amounts to 3 seconds of animation. This however > does not take into account compression which can dramatically increase > the length of the animation. Given that Colorburst supports the trick of turning off DMA, it could even be used as a pure graphics "accelerator" by buffering 16 color hi-res images that are then used as input into DCTV (or HAM-E). Since DMA contention is one of the bottlenecks for realtime DCTV animation and the Colorburst allows selectable bitplanes/colors, it could display 16 color animations compatible with DCTV without the DMA lockout while fetching or decompressing the next frame. Plus several frames (or delta data) could be stored in Colorburst's 1.5 meg. If the Colorburst graphics processor can decompress delta information on its own, then the amiga would only need to send the next "chunk" of anim data to the Colorburst (from fast ram or even a hard disk). > A board that can display 24bits of true color, and in > addition 24bits of overlay, with 1.5mb of ram onboard, and works with > all Amiga's? And it only costs $400! The next comparable board costs $1600? > Colorburst is a great deal, even if it couldn't animate, which it can. Considering that you can own both DCTV and Colorburst for under $1000, it could be the best of both worlds--full 24 bit output for stills or limited animation AND high-speed NTSC color anims when frame rate is a priority. Anybody wish to speculate on the maximum realistic frame rate with Colorburst and DCTV working together? Jim Lange Oracle Corporation
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (03/21/91)
From article <979@cbmger.UUCP>, by peterk@cbmger.UUCP (Peter Kittel GERMANY): > In article <1991Mar15.193235.2926@cs.mcgill.ca> tinyguy@cs.mcgill.ca (Yeo-Hoon BAE) writes: >> From quick calculation, 18 bits are more than enough to >> display 640x400 screen with every pixel having different >> colors. So why not have 24 bit palettes and use 18 bits > Indeed, 24-bit palettes were nice to have, BUT: Do you know one > existing chip that can hold that palette data (or color lookup > table)? Remember, you want 2^24 entries in your palette with > 18 bits each, this is, well, let's calculate, 48 Megabytes. > Umpf, a little much for a CLUT chip, or what? You've reversed what he was saying. He was saying that there's only 2^18 possible pixels on a 640x400 screen, so that there was no need for more than 18-bitplane resolution, indexing into a table of 24-bit values (for smooth color shadings and such). This would still require a fairly hefty lookup table (2^18 is 256K, so 256K * 3), but not as outrageous as the 48 megabytes that you quote. A 768K lookup table is within the realm of possibility, though not within the realm of affordability ( :-} ). -- Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg
jbickers@templar.actrix.gen.nz (John Bickers) (03/22/91)
Quoted from <979@cbmger.UUCP> by peterk@cbmger.UUCP (Peter Kittel GERMANY): > In article <1991Mar15.193235.2926@cs.mcgill.ca> tinyguy@cs.mcgill.ca (Yeo-Hoon BAE) writes: > > Is it really necessary to use all 24 bits? > > From quick calculation, 18 bits are more than enough to > > display 640x400 screen with every pixel having different In no time at all people will want to have 1K x 1K displays, if not larger. I know I see little value in splashing out $$ on a 24-bit board if it has significantly less resolution than that. > > colors. So why not have 24 bit palettes and use 18 bits > > or less for the lower resolutions? > > Indeed, 24-bit palettes were nice to have, BUT: Do you know one > existing chip that can hold that palette data (or color lookup > table)? Remember, you want 2^24 entries in your palette with > 18 bits each, this is, well, let's calculate, 48 Megabytes. It'd be 1 << 18 entries, with 24 bits each, wouldn't it? If you're going to have 24-bit pixels anyhow, then having an 18-bit palette seems a bit ridiculous. > (I love such speculations:) And the reason to use palettes is to > have such nice effects like color cycling easily available. Now Is there a scheme where a 24-bit board could use a (very small) palette for these sorts of effects, or some table of colors that can be used to fiddle with the palette easily, even if its some sort of restricted mode? Like a table of 48-bit entries, where the 1st 24 bits are the color to fake (yeah, like an alias table!), and the other half of the entry contains the color to replace the 1st half with when displaying. This table could have some sort of queueing scheme set up so that aliases could be replaced when the table got full. > Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
peterb@intacc.uucp (Peter James Bowmar) (04/06/91)
In article <1991Mar15.193235.2926@cs.mcgill.ca> tinyguy@cs.mcgill.ca (Yeo-Hoon BAE) writes: > >One thing I always wondered about 24bit cards: > > Is it really necessary to use all 24 bits? > From quick calculation, 18 bits are more than enough to > display 640x400 screen with every pixel having different > colors. So why not have 24 bit palettes and use 18 bits > or less for the lower resolutions? This should give some > improvements to the overall animation performance... > > >+-----------------------------------------------------------+-------------+ >| Yeo-Hoon Bae tinyguy@homer.cs.mcgill.ca | Amiga /// | >| Dept. Computer Science, McGill University, Canada | 2000 /// | >|-----------------------------------------------------------| \\\/// | >| Amiga2000 + 5MB + 104MB + KX-P1124 + DiamondScan + A2320 | \XX/ | >+-----------------------------------------------------------+-------------+ Well, that's the theory behind the Targa 16. It only uses 15 color bits (32000 someodd colours) but it displays accurate video images. THe only time you get nasty non-smooth transitions is in something like the sky, that might require more colours than the Targa can output. Sure speeds up render times, let me tell you. They're way too expensive though.