Jump to content
IGNORED

Fun with Apple IIe color palettes


Recommended Posts

Posted (edited)

I've added custom palettes to the MiSTer FPGA Apple IIe core (and MiST with the kind help of slingshot2)

Is anybody interested in coming up with their own palettes?

 

apple2_palette_example.jpg?ex=665be85d&is=665a96dd&hm=4bb6fc9220bb87932d80d34fc36866c1244457d103d28389de343763cf040568&=

 

There's a bit of story on how this came to be...

 

The other day I came across a recent (2024) Reddit post by somebody claiming to have derived "better" Apple IIe colors,

and it reminded me of a much older newsgroup post from 2005 on the same topic.

 

Now that particular older post has been the sole reference for various FPGA implementations for years,

so of course I got curious and asked how the methods compared...


Turns out, both posts are from the same person (Linard Ticmans) - only 19 years apart!

The method was very nice (and improved) so it inspired me to go tinker again with the FPGA core... 

 

Now, knowing how we are in the retro community, I knew I'd never hear the end of opinions on what palette to use :)

and I did not want to have to keep tweaking the core.  So I added the ability to load a custom palette!

 

I had a bit of fun coming with my own colors (check the MiSTer FPGA thread for link on the files), 

but now I'm curious as to what palettes you consider interesting (not necessarily accurate!)

 

 

 

Edited by Newsdee
  • Like 1
Link to comment
Share on other sites

Posted (edited)

Now a bit more about this "Ticmanis palette":

 

As you probably know by now, the Apple II color was originally done on a TV using composite artifacting,

which means that the real color depends on the hardware and settings (brightness, contrast, chroma, etc) of a specific display.

 

This basically means there are no "true" colors for it; except by replicating the range of possibilities with NTSC hardware,
and, ideally, let users manage their own "knobs" on the emulated device. 

 

Linard explained that his approach was to calibrate a theoretical NTSC display by "turning the knobs",

so that the colors match as close as possible an Apple IIgs which have 4-bit RGB values documented by Apple.

 

He wrote a "solver" program to do the task with high mathematical precision(more than 16 decimal places which is the standard of many programming languages),

and the program worked out the palette above. 

 

In plain speak;  this palette is the closest you can get to Apple IIgs colors by turning the knobs of a NTSC monitor.
(at least in literal theory, by using color theory math)

Edit: so, to me, this palette deserved to be the default NTSC //e colors for the FPGA core :D

Edited by Newsdee
  • Like 1
Link to comment
Share on other sites

  • 2 months later...

I disagree.  While it is true a user can tweak the display, it is entirely possible to compute a reference palette.  The signal timing is known, and the optimal values are also known.  At the very least this is all true for first order artifacts.

 

I have generated some legacy displays on Propeller chips, for example.  They end up almost exactly like the original display.  It really is all about the pixel clock timing relative to the colorburst reference.  So long as the ratios are right, the range of "palettes" available to the user will always contain a nominal palette as shown above.

 

To me, that's as good as "the" palette because it is what you get on reference gear operating in good condition with controls at their default, or "center" position.

 

Having owned a few Apple machines, the only serious variation is actually the GS.  It will display things differently.

 

Second order artifacts are far more display dependant!  My PVM barely displays them, unless I am aggressive on the color levels and even then... that PVM really wants to display a clean signal.  Consumer grade CRT TV's will display those effects far more dramatically.  I am talking about patterns of patterns, say for pink, or a more forest green where there are patterns of patterns.  Say two dots together with a red fringe that appear white.  A large swath of these will appear pink, for example.

 

That palette shown is basically a reference.  A well calibrated display will render colors very close to those because the computer timing is very similar.  Those are essentially what I get on a PVM with tint at zero, brightness and contrast at 50 percent.

 

Finally, yes.  Many users ran with the colors set as they liked them!  

 

When using this palette, and either a display and a real Apple, or a renderer able to tint shift, the result would fall very close to what a user would have actually seen with a twist of the tint and color level knows.

 

IMHO, the most important thing to get right on artifact color is the relative positions on the "color wheel" so that when display controls are or have been used, the resulting tints are true to the hardware of the day.

 

BTW:  Older Zenith ChromaColor, especially the II series, display great second order artifacts due to the nature of those particular color circuits being wide enough bandwidth to allow those artifacts through!

 

Had one growing up, and at one point the CRT died.  It was a big set, 29 inches or so.  I replaced that CRT with a 16 inch or so one, and was able to get a full frame near perfectly converged, corners just touching the inside of the rounded corners!

 

For the time period, it was sharp!  And one could see the full Atari overscan ANTIC 48 byte mode, for example.

 

An Apple 2 displaying both patterns of patterns in HGR, and especially DHGR showed more than the expected colors in both modes.  A look at some games shows a fair number of authors either aware of this, or just getting lucky trying to make the most of a limited capability.

 

I grew up playing games and programming on that set on Atari, C64 and Apple.  Some cheaper sets, like a small Toshiba TV / VCR combo set I have with a composite input appear similar.  Has a lot to do with both the lack of a good comb filter (or none at all in the case of the early 80's Zenith) and a wider bandwidth Luma circuit driving the color decode harder than many sets do.

 

If you run Apple hardware on real composite displays, it is worth trying a few.  Some will do more than you may have seen.

 

Edited by potatohead
Link to comment
Share on other sites

Or... not!

 

Lol, quite a few people do not consider artifacts real color.  I get that.

 

But I do consider them real colors.  It is just a coarse method of signal generation.  Real coarse!

 

Funny thing, I really prefer them most of the time.

 

The thing I like the most when compared to a real color, say 160 pixel display, it it is possible to get a single high resolution pixel to appear as colored.  There are more possibilities for detail pixel art that way.

 

Where there is an actual color signal, often and on Atari and many other machines offering 2 bits per pixel, all pixels are twice as wide.  Some detail potential is lost.

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...