Commander X16

Hi, Thank You.
I was not finished yet.

see back

greeting

funkheld wrote: ↑Mon Mar 18, 2024 11:35 am Hi, Thank You.
I was not finished yet.

see back

greeting

I am not sure what it is you are asking ?

This basload rom is now permanently installed in the latest x16.

https://github.com/X16Community/x16-emu ... #artifacts

greeting

funkheld wrote: ↑Mon Mar 18, 2024 11:39 am This basload rom is now permanently installed in the latest x16.

https://github.com/X16Community/x16-emu ... #artifacts

greeting

I know. I helped test it during development ....lol....

my rgb:
240 60 55
........

my rgb :
CX16-R = INT(240 / 16) + .5)
CX16-G = INT(60 / 16) + .5)
CX16-B = INT((55 / 16) + .5)

I write this into my file 255 x GB and CX16-R :
GB = (CX16-G*16) + B
CX16-R

and then upload my file here :
$FA00 = GB
SFA00+1=CX16-R
SFA00+2= GB
$FA00+3=CX16
.....
...

Can one make it like this?

thanks

If everyone uses this latest x16 with the built-in basload rom then it
is better than if different basload rams are in use.

thanks
greeting

CX16-R = INT((RGB-R / 16) + .5)

255/16 = 15.9375 + .5 = 16.4375
INT of that = 16

theres only 4 bits per rgb, its a 12bit color - IE -
GGGGBBBB ....RRRR
with '.' meaning the bits are unused / don't matter ...

so that means 0 to 15 only ..

no +0.5 ....

on the flip side, if you were converting a palette from the x16 to a higher bit format, like say 24bit true color / 8bit per color, you may have to scale it differently to match the intended brightness on the other system..

IE - $F / 15 *16 would become 240 in 8bit, but if you compare that value on your modern system to what you see on-screen on the X16 itself, it might be more correctly 248 or even 255 ...

Due to differences in display hardware like this, colors may need tweaking to match what you expect... And obviously you can't exactly take a 24-bit image and convert it to 12-bit without -some- loss in quality... Just in practice it averages out, the human eye generally not so sensitive to subtle differences in hue... differences in luminosity tend to be noticed more. (which is why NTSC color signal is mostly a crisp Black and White image with a less-detailed color information supplied separately ) .

Cheers.

hstubbs3 wrote: ↑Mon Mar 18, 2024 4:33 pm CX16-R = INT((RGB-R / 16) + .5)

255/16 = 15.9375 + .5 = 16.4375
INT of that = 16

theres only 4 bits per rgb, its a 12bit color - IE -
GGGGBBBB ....RRRR
with '.' meaning the bits are unused / don't matter ...

so that means 0 to 15 only ..

no +0.5 ....

In the code I actually use I've done both. And I just clip it to 15 if higher. It's subjective but it seems as if the colors are a little more accurate if I do the Round as opposed to just the int. There's no getting around the fact that your losing a lot going from 24 bit palette to a 12 bit palette. BTW That ONLY happens on Values > 247

hstubbs3 wrote: ↑Mon Mar 18, 2024 4:33 pm so that means 0 to 15 only ..

no +0.5 ....

That is how you round a number in BASIC. The INT() function should actually be called FLOOR, since it simply truncates the fractional part of a number.

Consider the number 14.999. In practical terms, that might as well be 15. But the INT(14.999) returns 14. This biases the whole spectrum downward by 8 values, which will cause dark colors to wash out and affect the hue of certain colors in some undesirable ways.

So when rounding a number, we push any fractional part.5 and above to the next whole integer. Fractional parts below .5 get truncated.

So a value of 9.5 becomes 10, while 9.4 becomes 9. This creates a more even distribution of values when dividing integers.

The simple way to do that is to add 0.5 before using the INT() function.

So to convert a color component from 8 bits to 4 bits requires 3 steps:

• Divide by 16
• Add 0.5
• Convert to integer

So expressed in BASIC, that is: C4 = INT(C8 / 16 + 0.5)
In this example, C4 is the 4-bit color component, and C8 is the 8-bit color component.