Method to the madness

[Karlos]

last time I counted them, I only got 262,000 colors in HAM8 not a mere 256,000

Actually, it's 2^18, which is 262144.

Unlike HAM6, however, the base colours are still 8 bits wide. Altering a pixel by changing any of the RGB guns of the previous one does not affect the lowest 2 bits of the gun you are altering. If you use the copper to alter the base palette for each scan line, you can actually achieve considerably more than 262144.

[Karlos]

But with what sort of performance hit?

Well, for displaying static images, none really. HAM in general, however, is not ideally suited for realtime graphics applications.

[Karlos]

One thing I am curious though and possibly this would be more into UAE territory is would it be possible or even desirable to run a similar type of software inside CUDA?

How do you mean exactly? CUDA excels at parallel processing. For example, I'm currently using it to solve the optimal spacing of points on the surface of a sphere. Running on the Q9450, the system starts to struggle at 2000 points. With CUDA, it's still fast at over 10 times that number thanks to the inherent parallelism in the problem at hand.

I'm not sure where you see it fitting into Amiga hardware emulation, though I expect it could emulate things like high resolution HAM displays etc without any problem, but then you have RTG for that job anyway.

[Karlos]

One of the biggest issues with Amiga emulation as I understood it was the graphics. Would it not be possible to have the CUDA processor deal more directly with it rather then needing the cpu to handle that particular facet?

This isn't my area of expertise so I could be viewing this in completely the wrong way.

Ah right, now I get you. I've wondered about that too. You could probably use it to speed up planar to chunky (yes, that's right, not chunky 2 planar) and rendering of HAM framebuffers to the host display format, you could probably use it to speed up blitter emulation too.

However, the thing is that on current CPU's these aren't really too taxing. A more widely supported solution I think would be to leverage multiple core support on the CPU. Since AmigaOS 3.x exec just isn't cut out for SMP (something else I've pondered for UAE is a hacked exec that can use multiple concurrent JIT instances for handling as many AmigaOS "ready to run" processes as the host feasibly allows), you can have the JIT on one core and offload things like display emulation to another core. Worth noting too is that if you are using UAE for anything beyond a spot of retro gaming you are probably going to be using RTG anyway and not even worried about "native" amiga modes.

Also, anything you do with the GPU is probably best left until OpenCL becomes more widespread as it'll work on more systems than CUDA.

[Karlos]

A good idea, but I haven't perused the UAE source code, or looked at the CUDA specific commands. It seems like the logical progression though.

CUDA doesn't have commands, per se. You write code for it using a modified subset of the C++ syntax.

[Karlos]

Also allow WinUAE to run in multiple sandboxes.

How's that different from running multiple instances of UAE?