Quote:
9 bit data bus (nice for 3-bit-per-component RGB among other things).
Nice from a theoretical standpoint, but in practice the human eye is least sensitive to changes in blue, and most sensitive to changes in green, so 3-3-3 RGB is probably not noticeably different from 3-3-2 RGB.
Quote:
I haven't had a chance to look at the assembler for 'org16. I wonder how much work it would be to convert it to 18.
There are two. My first thought was "just make macros to emit the instructions and data you want until you're satisfied with the set, then hard-code a native version".
But then it occurred to me that, at least in HXA's case, it doesn't know anything about 18-bit "byte" sizes. It knows 8-, 16- and 32-bit "byte" sizes. Binary output is not a problem in any case, and it's not too difficult to create more-or-less familiar-looking Intel and Motorola output files.
So...generalizing to "byte" sizes that are not multiples of eight seems doable but not simple. Offhand, it would appear to involve packing the non-standard "bytes" into the least common multiple of eight and the non-standard size for output, since the creation tools "think" in terms of eight-bit bytes.
If a text output is desired (ie., non-binary), there'd have to be some way to indicate to a loader what the "byte" size is - as well as writing a loader that can handle non-standard sizes in the first place. Maybe not too difficult if only one non-standard size is involved - then it would "know" and not need any kind of flag - but there are a lot of different sizes being tossed around here, and a standard solution might be preferrable to multiple one-offs.