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

[Karlos]

Chip ram, eh?

Tricky to get that throughput. For a start, you can't write every cycle and chip ram is uncacheable.
On 060 systems you can accelerate chip ram writes a bit by marking the area you want to write to as imprecise in the data cache. IIRC patches such as speedychip do this.

Basically you are up against the top limit of the chip ram bus however. If you want to synchronise to a display refresh you'll need to do triple buffering (double buffering can stall, with triple you can always be writing to one buffer even whilst the other two are involved in the switch).

Ultimately I'd expect to get the full framerate, using a delta buffer of some kind is the only realistic way forward.

-edit-

And it goes without saying that you want 32-bit aligned transfers...

[Karlos]

Well, I meant delta buffer as in 'compare with last frame and write only changed areas' buffer.
IIRC, lots of 'high res' c2p stuff does this (like ShapeShifter video drivers). So it's not a problem to use different screen modes, your delta buffer just has to be an appropriate size (same as the screen, I guess). Perhaps 'comparison buffer' would have been a better phrase for me to use :-)

However, using ham8 would most likely result in most of the 'comparison' buffer changing every frame anyway (due to the way ham renders colours using ramping) so it might end up slower!

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).

A point to note, 24-bit -> ham conversion is not a trivial process, especially for 680x0. It's likely to dominate the rate at which you can pump frames out at your chosen resolution (640x480) long before you get into the bottleneck of writing the data to chip ram.

I don't want to sound all doom and gloom here. The sort of thing you are thinking about has been done (not sure about at such a high resolution though).

You should look at AMP (AmiDogs Movie Player) to see some good quality 18-bit ham output stuff. The documentation describes the process he uses.

Incidentally, you may have seen a lot of seemingly low resolution 2x2 (ie 160x120) ham8 animated stuff in demos etc. In reality, many of these are actually 640x120 ;-)

As you probably know, from any starting colour it takes a theoretical maximum of three pixels for the ham colour ramping to get to any other colour - unless of course a well chosen base colour can be used.

So, the trick is that using 4 pixels on screen for 1 in the image allows the ham colour ramping mechanisms to hit the desired colour on every '160' width pixel in the image. Used a lot in demos ;-)

[Karlos]

bloodline wrote:

I think if you try it... you will find this really isn't possible... From my own experience anyway.

I suggest you look at a GFX card for such activities...

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.

This kinda stuff is good fun :-)

To be honest, it may surprise some but from the tests I got folks to run a while ago hinted that most graphics cards available for amiga (be it 'native' or via a PCI bridge) aren't much faster than AGA when it comes to shovelling data into a framebuffer :-)

Of course, you don't have c2p to worry about, but once you get to 68040 most c2p routines operate at copy speed anyway.

For example, my 68040 @25MHz can pump data to the BVision at about 10Mb/sec for longword aligned writes.

A 68060@50MHz / Mediator4000 / Voodoo5 gave a similar result.

Not such a vast improvement over AGA's 7Mb/s, is it?

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.

[Karlos]

Yep, for planar gfx, you can still do 32-bit writes.
In fact, it's essential if you want the best speed utilisation.

Consider, for example, 8 successive 32-bit writes, one to each succesive bitplane results in a horizontal span of 32 8-bit pixels.

Most c2p alogrithms do something like this. Generally for whole screen spans :-)

You could interleave some code so you reduce chunky 24-bit to an 8-bit ham pixel and c2p at the same time. Maybe...

You need to talk to some proper demo coders, really. I'm afraid I went the gfx card route some time ago and as such never got too much into AGA programming.

Pity really, it was a lot more entertaining :-)

[Karlos]

Hey, does anybody know if the akiko chip actually cares about the format of pixels it converts?

I assume its a dumb c2p engine only. In which case chunky ham8 is a 'real' possibility on a CD32 :-D