CGX4 with AGA

[bloodline]

Karlos wrote:

fancy making an AGA.hidd?

No, because it would seriously suck :lol:

To justify that, you'd basically end up with a lot of the problems CGX-AGA had anyway, not the least of which would be the 256-colour limit.

Or how about an 8bit "Low colour" mode... 2bits red, 4bits green, 2bits blue... scaling hi/tru colour pixels down to their lo colour equivalent :-) This was an idea suggested by Fabio...

CGX-AGA could have been so much more. Especially since it "relied" on the ppc.library (in the same way that your fridge relies on your kitchen floor)

I remember playing with the various EVD that were available for shapeshifter at the time. There were some which used PPC for C2P, able to convert an entire frame and copy only the changed areas to the display faster than the 68K could actually update the source framebuffer. There was also a 16-bit colour -> HAM8 driver which delivered suprisingly good results (very little HAM artifacts) and was faster than most of the 68K 256-colour EVDs.

IMNSHO, this is the sort of functionality CGX-AGA should have delivered - support for chunky 8/15/16-bit (possibly even 24/32-bit) framebuffers in fast ram and a PPC colourspace-converter/C2P *if* it was going to lay claim to using the PPC for anything.

Yeah, I agree, but I imagine the complexity of PPC->68k context switches made it undesierable... though I can't remember how horrible it was... the PPC on my A1200 simply doesn't get used any more and since UAE doesn't have a PPC emu... I'm not going to find out anytime soon...

I do remember thinking about setting the PPC up as a GFX co-processor... but you would have to have assigned a seciton of the PPC memory space as non cacheable.. then written a smal GPU emualtor for the PPC to read the non cacheable region as registers... actaully that does sound like fun...

[Karlos]

Yeah, I agree, but I imagine the complexity of PPC->68k context switches made it undesierable

I disagree here. The worst case scenario is a 68K->PPC->68K context switch per frame, assuming something changes on screen each frame. This would of course, depend on having all drawing operations accumulated in the fast ram buffer and invoking a chip ram update only on refresh, but again that is doable. Most WarpOS/PUP games already have worse switching overhead than that.

Secondly, a smart implementation would evaluate the amount of work required to update the screen (in terms of pixels requiring conversion). Below a certain threshhold (user tunable) it would stay purely 68K. The PPC would kick in where larger areas need modifying.

Regarding the low colour thing, you might be better off using the web 216 palette, since it basically gives 6 levels per gun, which is better than any bitwise aportioning of the space.

[Karlos]

I do remember thinking about setting the PPC up as a GFX co-processor... but you would have to have assigned a seciton of the PPC memory space as non cacheable.. then written a smal GPU emualtor for the PPC to read the non cacheable region as registers... actaully that does sound like fun...

A different approach would be to have library that employs the PPC as a graphics device. You send it rasterization requests (just basic function calls in reality), which get buffered up then executed (as part of a context switch minimisation job). It would handle all the drawing, colourspace conversion and C2P.

That would be a fun thing to try :-)

[bloodline]

Karlos wrote:

I do remember thinking about setting the PPC up as a GFX co-processor... but you would have to have assigned a seciton of the PPC memory space as non cacheable.. then written a smal GPU emualtor for the PPC to read the non cacheable region as registers... actaully that does sound like fun...

A different approach would be to have library that employs the PPC as a graphics device. You send it rasterization requests (just basic function calls in reality), which get buffered up then executed (as part of a context switch minimisation job). It would handle all the drawing, colourspace conversion and C2P.

That would be a fun thing to try :-)

There might be synchronization issues with that approach..? You ould send your display list to the PPC and then have to poll to determine when the PPC had actually completed the operations... unless the 68k could wait on an interupt generated by the PPC... I'm sure this is a very sticky issue...

[Karlos]

Who said it has to be asynchronous? I simply envisaged doing the buffered rendering immediately the next screenbuffer becomes free :-)

You can do asynchronous context switches but I'm not sure they'd be that useful in this scenario. Or rather they could be, were they not such a pain to use.

[bloodline]

Karlos wrote:
Who said it has to be asynchronous? I simply envisaged doing the buffered rendering immediately the next screenbuffer becomes free :-)

You can do asynchronous context switches but I'm not sure they'd be that useful in this scenario. Or rather they could be, were they not such a pain to use.

oh, yeah... ok... are you talking about PowerUp or WarpOS?

[Karlos]

Either. The choice is purely academic since later versions of PUP improved the context switch times. The approach I'm talking about really only requires a context switch pair per frame.

I wrote some test code in VBCC some time ago for WOS that basically defined a display context for PPC native apps. It used one context switch per frame (PPC->68K and back). The 68K code called all the OS routines for swapping the buffers and gathering the IDCMP messages into a local buffer before switching back. The PPC then called ppc-native mouse/keyboard callbacks with the captured IDCMP data, so basically the 68K only handled interfacing with the OS.

What I am talking about here is simply the inverse approach, using the PPC to perform rendering operations and screen updates (specifically the colour conversion and C2P, not flipping buffers etc which would still be done on the 68K)