I considered this and it's slightly awkward - the hardware isn't memory mapped so the drivers would all need to be adapted, and there's no realistic way it'd get upstream. There's also the problem that the Amiga is big endian and Linux on the Pi is little endian so even if you could memory map it you'd still need to byte swap everything. Not literally impossible, but a giant pain.
Given we have AROS, that is mostly AmigaOS compatible and has an ARM port, and that also has a classic Amiga port, it'd be fun to see the ARM version of AROS ported to this...
The way HAM works, a pixel can be either one of only 16 colours, or the colour of the pixel to the left and change one component: red, green or blue.
Back in the day, I used a program that loaded GIFs in 256 colours and converted them to HAM. The resulting images had lots of edge artefacts, and that is what I would expect out of that too.
Given there's no need to run any code on the 68K bus it's probably actually possible to do the palette calculations per line and use the copper to reprogram the colour registers every line, getting way more colours than plain EHB without the HAM side-effects
Hmm actually the Copper probably isn't fast enough for this - it takes about 8 pixel scanout equivalent to update one register, and hblank isn't going to be large enough to update all of them. But Copper's performance is restricted by having to read instructions out of RAM before executing them, so if I just use another core on the Pi to read the scanout location I can have that update the palette during scanout much faster without blocking the main thread from continuing to render the next frame.
If you're willing to do your own timing and race the beam, pump $0RGB values to $DFF180 with no bitplanes enabled at all.
Alternatively, on a AGA system you could use HAM8 mode and judicious use of colour palette to get 18-bit truecolour? Every pixel is 4 HAM8 pixels, displayed in SuperHiRes mode to look like 1 lowres pixel: First is the base colour, from one of 64 palette colours, which are 4 intensities of R, G and B in the MSB (e.g. 00xxxx 40xxxx 80xxxx C0xxxx times xx00xx xx40xx xx80xx xxC0xx times xxxx00 xxxx40 xxxx80 xxxxC0; 4*4*4 combinations = 64 colours). Next, three modifier pixels, modifying R then G then B to set the lower 6 bits of each. See https://youtu.be/pjiBhrqKxk4?t=41 (or http://aminet.net/package/gfx/show/h8jpg and http://aminet.net/package/gfx/show/h8ilbm if you want code)
This was known as “Sliced HAM” back in the day. I don’t recall anyone doing anything more than pre-processed still images with it though I wouldn’t be surprised to see a few demos with some real-time SHAM effects.
So the Amiga is a graphics card for Doom running on the Pi. Can we make that general purpose? Does Linux still have Amiga drivers?
I considered this and it's slightly awkward - the hardware isn't memory mapped so the drivers would all need to be adapted, and there's no realistic way it'd get upstream. There's also the problem that the Amiga is big endian and Linux on the Pi is little endian so even if you could memory map it you'd still need to byte swap everything. Not literally impossible, but a giant pain.
Like a Vampire but with honest intentions. It accepts it is wearing the Amiga as a hat.
Given we have AROS, that is mostly AmigaOS compatible and has an ARM port, and that also has a classic Amiga port, it'd be fun to see the ARM version of AROS ported to this...
Would it be possible (and/or a good idea...) to calculate the best HAM approximation of the frame, rather than an EHB version?
The way HAM works, a pixel can be either one of only 16 colours, or the colour of the pixel to the left and change one component: red, green or blue.
Back in the day, I used a program that loaded GIFs in 256 colours and converted them to HAM. The resulting images had lots of edge artefacts, and that is what I would expect out of that too.
Given there's no need to run any code on the 68K bus it's probably actually possible to do the palette calculations per line and use the copper to reprogram the colour registers every line, getting way more colours than plain EHB without the HAM side-effects
Hmm actually the Copper probably isn't fast enough for this - it takes about 8 pixel scanout equivalent to update one register, and hblank isn't going to be large enough to update all of them. But Copper's performance is restricted by having to read instructions out of RAM before executing them, so if I just use another core on the Pi to read the scanout location I can have that update the palette during scanout much faster without blocking the main thread from continuing to render the next frame.
If you're willing to do your own timing and race the beam, pump $0RGB values to $DFF180 with no bitplanes enabled at all.
Alternatively, on a AGA system you could use HAM8 mode and judicious use of colour palette to get 18-bit truecolour? Every pixel is 4 HAM8 pixels, displayed in SuperHiRes mode to look like 1 lowres pixel: First is the base colour, from one of 64 palette colours, which are 4 intensities of R, G and B in the MSB (e.g. 00xxxx 40xxxx 80xxxx C0xxxx times xx00xx xx40xx xx80xx xxC0xx times xxxx00 xxxx40 xxxx80 xxxxC0; 4*4*4 combinations = 64 colours). Next, three modifier pixels, modifying R then G then B to set the lower 6 bits of each. See https://youtu.be/pjiBhrqKxk4?t=41 (or http://aminet.net/package/gfx/show/h8jpg and http://aminet.net/package/gfx/show/h8ilbm if you want code)
This was known as “Sliced HAM” back in the day. I don’t recall anyone doing anything more than pre-processed still images with it though I wouldn’t be surprised to see a few demos with some real-time SHAM effects.
"Racing the scanline"?
Yes, but without the hassle of counting instructions. The copper is made for that purpose.
this deserves a video at the end.