8bit, realtime, 640x480, gfx stream to chip ram...

[Jose]

Hey, First of all, I'm just curious about this. Slowly leaning as it happens but time is scarce, even to be here.
I was wondering if it's possible to have a video stream of 8bit constantly being written to chipram. Talking about realtime here, so it would have to be 640 x 480 x 8bits x 24frames /(8bitsx1024bytes)  Kilobytes per second. This gives more or less 7.x MB/S. I've checked some benchmarks on the net but the very few ones I found have an average writte speed to chipram of about 6MB/s in high end Amigas. Actually some of them have more than 7 but that's probably not in 640x480. This mode probably slows dow things more so it's not possible. Well shame isn't it. I know some video progs work by just writting in the necessary info (just the different bits), but uncompressed would be more cooler.

[Jose]

Ok, I'm gonna say what my idea was. It was to have 24 bit to HAM8 conversion in fast ram, and send it to chip ram. But I REALLY need to get more informed about some stuff.
Yeah, delta should do it, but with delta you can't have like  a screemode or can?
I figured that the benchmarks I saw are probably from systems with that patch already installed cause the vaues of the 060s are higher than the 040s tested and an 040 can pump more than 7 Mbs.
An idea I had was to use only 6bits, since HAM8 uses 2bits for control and the other for data. I'd be stuck to the chosen base colors though. But maybe if I only changed them when needed  it wouldn't be that much additional space. So using 6bits it would be possible. BUT: The data is supposed to be continuous (the control bits are mingled with the data bits), so I really can't take advantage of using only 6 bits can I (the space of the control bits in the data has to have the control bits, so I'll end up being able to writte  less data at the same time?
Give me a discount here, cause I need to dig more into some stuff, but I think the ideas are correct.
If there is a way  to make the last idea work let me know :-o

[Jose]

I may be wrong but I think he's looking at it from a 'lets see how far we can push AGA' point of view.

Of course  :-D  :-o

"..Having said that, in Jose's case I reckon just converting 24-bit to ham8 without using the 'several pixels wide' trick would be the killer anyway."

You're starting to make me think I really got some good stuff, at least in ideas, algorithms, that's how programmers call it right?.  I think I have damn  good one  for that.  Now I have to better dig some 68k programming. I wasn't even worried with the speed of 24bit > ham8 conversion at all.

EDIT: Having thought about it there might a big problems here, because HAM is planar and 24bit is chunky. But if you were refering to 24 to HAM8 chunky I still think my algorithm will rock  :-D
 

Back to the chipram bottleneck:

"If you only use 6-bits of the ham, you waste the colour potential completely. For a typical ham image, most of the pixels on screen are 'ham' colours rather than the base colours (unless you have a very simple image that is)."

But that was exactly my idea. Ham colors are really just 6bits, based on the previous pixel. So if most of the colors on a HAM screen are not base colors, I'll need to change only 6 bits most of the time.
[EDIT]
This part and the following one was wrong I'll still need the control bits to specify wich hue (R, G or  B) I want to change. Doh!