Commander X16

The first 16 colors (32 bytes) are supposed to reflect the C64 color palette but they are too saturated on the x16 ?

I think the "pepto" version of it is much closer to how the colors should look https://www.pepto.de/projects/colorvic/

 

On 12/3/2022 at 7:49 AM, neutrino said:

Maybe "BIOS" (Kernal) could make life easier for programmers, if the boot procedure set VERA color registers?



Reminds me of 0xD012 on C64 ?



 

I think it’s a good idea that the original values of the palette can be found in some official context, either by being read from the registers themselves or by simply including them in the VERA Programming Reference. The reason for this is that make it easier for developers to make clean exits, in this case which include setting at least the 16 first colors back to their default values. 



 

On 12/4/2022 at 2:32 PM, Johan Kårlin said:

I think it’s a good idea that the original values of the palette can be found in some official context, either by being read from the registers themselves or by simply including them in the VERA Programming Reference. The reason for this is that make it easier for developers to make clean exits, in this case which include setting at least the 16 first colors back to their default values. 



 

It's always good to have a reference somewhere! Whether the concept of a "clean exit" will be a thing on the tiny machine remains to be seen though ? I doubt it

 

On 12/4/2022 at 2:32 PM, Johan Kårlin said:

I think it’s a good idea that the original values of the palette can be found in some official context, either by being read from the registers themselves or by simply including them in the VERA Programming Reference.

The problem is when a programmer reads the default color values from the programming reference and use them in the code. And then the programming reference is updated but the code isn't etc. While if the values are in the machine as a part of the BIOS etc. Then getting default values is as simple as just reading them.

On 12/4/2022 at 2:32 PM, Johan Kårlin said:

The reason for this is that make it easier for developers to make clean exits,

Restore palette on exit from program?

If there were a BIOS restore_color_palette() function it would be easy.

Anyway 8-bit and clean never felt like it was a thing in the same sentence. Any dirty code trick was often used to get the job done ?

 

I wrote some untrue stuff here.

On 12/4/2022 at 8:52 AM, neutrino said:

The problem is when a programmer reads the default color values from the programming reference and use them in the code. And then the programming reference is updated but the code isn't etc.

Well, then, maybe the default palette should be located somewhere in ROM. Then it's just a small chunk of code to copy the default palette to VERA.

On 12/4/2022 at 5:21 PM, Ed Minchau said:

Well, then, maybe the default palette should be located somewhere in ROM. Then it's just a small chunk of code to copy the default palette to VERA.

It's probably the best idea. Just like the original character set is in ROM and easily can be uploaded to VRAM (by printing #8e) when exiting a program.

I get that this is not a big deal but I am rather fond of clean exits, it feels like a quality stamp, the developer is not just leaving a mess. If it is a BASIC program you can exit the program and immediately continue to change the code and then run it again. If it is a machine code program, you might want to enter the monitor to disassemble the code to learn something. If the program is written in assembler of course it should also be possible to run it again ... ? ?

For reference, the original colors are here:

https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md

I don't know if the colors are initialized by the FPGA code or from the KERNAL, but it is easy enough to use @RickDangerous's table above to reload the palette on exit. 

If the colors are initialized by the FPGA code, there's no real reason to initialize them in the ROM code, since a reset (set bit 7 of $9f25 to 1) should reset the palette. However, this hangs the emulator, which is probably the incorrect behavior. However, a cold boot (Control-R in the emulator) definitely resets the colors. 

Regardless, if your application requires specific colors, it's always better to load the palette yourself, rather than depend on the kindness of the previous programmer to have the colors you expect. 

 

On 12/5/2022 at 2:07 AM, TomXP411 said:

since a reset (set bit 7 of $9f25 to 1) should reset the palette. However, this hangs the emulator, which is probably the incorrect behavior

This is not exactly what's happening, if you call the appropriate ROM routines after resetting the vera like this you'll get the normal text screen back. The emulator doesn't hang but it seems like it because the rest of the vera registers isn't set up anymore to display text mode etc.

The routine to call is CINT ($FF81) this will reactivate normal text mode setup after Vera was reset.

 

On 12/4/2022 at 5:49 AM, desertfish said:

The first 16 colors (32 bytes) are supposed to reflect the C64 color palette but they are too saturated on the x16 ?



I think the "pepto" version of it is much closer to how the colors should look https://www.pepto.de/projects/colorvic/

PAL systems had much more consistent color depiction. NTSC systems were subject to the user tweaking the manual color controls on their monitors. Never Twice the Same Color, you know... so no two people in the US seem to have quite the same memory of what they 'should' look like.