A pointless nerdsnipe

[Karlos]

As some of you may know, as a hobby project I've built a weird virtual machine that is intended for assembly language programming. It is embedded in an equally virtual host machine that provides basic graphics, sound etc (still working on that).

Right now it supports basic 8 and 32 bit chunky graphics, in conjunction with a built-in beam racer that allows for some copper like effects. The whole thing is just for fun and to trigger some creativity as I get older.

I'm going to add 15/16 bit RGB modes too, just for completeness. Then it struck me. What if you had an 8 bit HAM mode for 15-bit RGB? Imagine you have the lower 5 bits to set one of 32 palette colours from the 32K space. Then, the upper 3 bits specify which of the 3 RGB channels you wanted to modify while holding the last. This would allow you to simultaneously set any combination of the channels simultaneously to the new value and this mean you'd get grey scale for free since you can just do 111xxxxx to set any of the 32 grey levels.

Thoughts?

[robinsonb5]

I like it - an interesting twist on HAM8 - the "free" greyscale is really compelling. (It could be implemented in an FPGA without too much difficulty.)

I seem to remember reading that HAM was originally intended for use with a YCC / YUV colourspace rather than RGB, and when the decision was made to go with RGB it was nearly removed. So exploring HAM-as-originally-intended, in a more video-oriented colourspace is something else that would be interesting.

[Karlos]

Yes, I recall the same. I think Jay Miner had seen it in use in some flight simulators. If you think about how HAM works you can see how it would lend itself better to YUV type encoding schemes. More than likely it's the luminance value you'll be modifying along a scanline when rendering shaded polygons. In this model it makes sense to go for as many palette colours as possible and use as few bits as possible to determine what is being modified, which is exactly how HAM proper does it. If you are sticking with RGB though, maybe there is more utility in a model where you can change the channels more directly.

It's just for fun anyway.

[Karlos]

Remembering this old thread, I finally added this feature to the MC64K project.

[ Show youtube player ]

Excuse the terrible cameraphone capture, it was a lunch break bit of work.

What we have is a (virtual) 320x240 8-bit display in the proposed HAM555 format, where we have:

* Chunky 8 bit pixels
* 15-bit RGB colour model
* 32 15-bit RGB palette entries
* 3 control bits per pixel (for R, G and B), where 000 chooses a palette index and 111 sets the three colour channels simultaneously to the same 5 bit number, giving us black/grey/white. All other combinations hold the previous and set the respective new component values.

The left hand most pixel of each row has been set to black (11100000) and the subsequent pixels all modify the various gun combinations. Every 8th line has the control bits at 000, so those are palette entries.

There's some copperlist type beam racing changing the horizontal scroll offset at various locations so that we can see the fringing effects, which are pretty conspicuous as big gradient shifts.

A simplified version of the code (scrolls the whole display rather than slices) https://github.com/IntuitionAmiga/MC...lay/src/main.s