Dead Hackers Society
Select »
 
 

68k Inside

Sommarhack 2024

Silly Venture 2024 SE
External scenelinks  Special feature  Online compos  IRC #atariscne  Garfield vs Atariscene

Select article
Interview with Kalms/TBL
OSX/Atari GCC crossdev
Atari GCC development
PowerPC history
SatanDisk
Overscan
Multicolour
  dhs.nu special feature #6
Published September 2012

ST/STe multicolour conversion
Evil / DHS, ae(at)dhs.nu
 

DHS multicolour graphics

Features
  • 48 "real" colours per scanline, ala Spectrum 512
  • 273 visible scanlines (less if combined with syncscroll ala SPX)
  • Two screens with different graphics data/palettes interlaced at 50 Hz
  • Interlaced palette: 3375 (ST) and 29791 (STe)
  • Interlaced max colours per scanline: 96
  • Max colours on screen: 3375 (ST) and 26208 (STe)
  • Processor time used: 274 scanlines = 87.22%
How it works
Basicly the code driving the display is a mix of Photochrome and SPX techniques. No real magic at all - Photochrome for spitting out the colours/interlacing and SPX for border opening. The work of getting good quality images on screen does however come down to preparation of the graphics. Depending on the image, the result can be very near HiColour (on STe) and sometimes it can be pretty terrible.

The reason why it differs so much is that the screen is constantly getting new colours fed to the colour palette registers. Each row (aka "scanline") starts with a fresh set of 16 new colours. Every 20 pixels there are two new colours set, meaning that the colour palette has changed by two colours. This continues to happen through the entire 320 pixels of the line. In the end there have been 48 colours set for the line.

So the 48 colours are "drawn out" over the scanline and one can't freely use the colours at any pixel. Actually, there are always just 16 colours to select from for a given pixel. This is why "Spectrum 512" mode has never been used in games or demos for actual effects - the colours change all the time and moving a graphics block over the screen with all colour changes going on will look quite absurd. Spectrum 512 animations however are not a problem as that's only a matter of screen address change and colour palette datas offset change.

Don't be tricked to think that the latest demos from BlaBla (JAPAN and STreet Art) uses Spectrum 512 for the effects, no they use static colour bars with colour changes. It gives a real "truecolour" display without shifting any actual bitmap graphics around, at the cost of lower resolution. Quite similar to a plasma screen on the ST, using more than one colour palette entry. Very nifty stuff, but clearly not in class with Spectrum for displaying static images due to the low resolution.

Getting a 273-line picture converted
Alright, back to the multicolour mode.
Now that we have the 48 colours per line technique, we need software to convert a picture into this format. Doug Little of the Black Scorpion Software wrote a genius tool called "Photochrome" back in the days, you might also remember his name from the fantastic APEX Media on the Falcon. You can feed Photochrome with a 24-bit image and it will spit it out in one of many ST/e formats such as Spectrum 512/4096.

As our DHS-mode uses higher resolution than Photochrome (273 scanlines versus 199) we need to split our source image into two.
After the conversion we use a little tool that joins them together as a big file. At this stage we have a nice Spectrum 512/4096 file at 320x273 resolution without very much effort. An example of such use is in our More Or Less Zero demo from 2008. Yep the green guy to the right actually consist of 237 colours with STe colour palette used.

More colours
The next level is getting a higher colour palette. That's made by interlacing two Spectrum 512/4096 images with colour brightness slightly differing bwteeen the two to create "in between" colour vales that normally don't exist.

Below you can see a simple example: By putting red to one screen and blue to the other, then interlacing between the two would create purple. In theory at least. The contrast between the red and blue screens are too much and it will create an intense flickering, it will likely kill your eyes in a matter of seconds. Perhaps rising the refresh to 100 Hz or more will cure most of it, but it's out of the ST/e scope. Instead we only interlace between the closest colour values, such as the grey in the example. That will greatly reduce flicker and we're starting to get an illusion of a greater colour palette.



Photochrome luckily have it's own interlace display format, so converting an image with interlace to increase the colour palette is actually no more work than doing a normal Spectrum 512/4096. You need to dig out the bitmap and colour data from the Photochrome file and paste the two 320x199 files into one 320x273 as for the plain Spectrum one. The display code has to switch screens and colour banks each VBL and off you go. Again; it's pretty easy and not that much work to get it on screen.

By now we have the code to display and method to convert a 320x273 24-bit file to a format that can show over 26000 colours at once from a palette of over 29000, on a plain STe. Not too shabby.

Dithering
The Photochrome dithering is unluckily not quite up to the task of giving great results. By doing the dithering yourself (say with GIMP or Photoshop), and let Photochrome do a clean conversion, the quality is bound to increase. However, that's a lot more work. It means that you have to convert both screen buffers manually as Spectrum 512/4096 instead of using the Photochrome mode directly. And we have to bring out four images to convert instead of two:
  1. Top 199 lines, screen 1
  2. Top 199 lines, screen 2
  3. Bottom 74 lines, screen 1
  4. Bottom 74 lines, screen 2
To get these four pictures, we need to make a little tool to separate the brightness between the images. Yes it's getting a little hairy now. Anyway after running our homecooked tool, we've got four targas to feed Photochrome with. In they go, and out comes four Spectrum 512/4096 pics converted without any dithering enabled in Photochrome.

Already we can start to see vast improvement over the Photochrome original conversion. But is there any other trick with the dithering that can be applied? By trying some things, it looks like doing separate ditherings over the RGB channels further improve things. In GIMP or Photoshop; separate the channels to independent images, dither them down to 32 colours, then join the channels back again. Now you've got a real 15-bit, channel-dithered image ready for Photochrome. The results are now pretty darn good for many pictures, some which are very near HiColour.

Flickering
Just one thing left to think about; how to reduce the flickering from this god awful interlace? The home cooked tool to separate darker/brighter screen buffers did just that and nothing more. One buffer was brighter than the other. Now, what if we made a little adjustment and let every second pixel be bright/dark, creating a simple pattern? After adding this improvement, more or less all flicker is gone. One has to very look very closely to see any flicker, especially with STe colour palette.

Example pictures from our Drone demo from 2012:



Left/middle: The two screens that interlace eachother
Right: The two screens mixed together as it would look on an STe, showing 1559 colours from a 29791 colour palette.

Close-up of the face to see the pattern to reduce flicker (both screens):




Further improvements
  1. Clearly the entire toolchain process is a nightmare of home cooked tools, available tools and graphics editors. Converting one image can very well be some 10-15 minutes work, and your head will be spinning at the end thinking what did I forget to do this time ?
    The biggest improvement would certainly be to code a tool that will make all these things in one pass. It would possibly be worth spending that time for converting a lot of pictures. But for one or two pics in a demo, no way Jose.

  2. Create a better display mode from the ground up. Using the Blitter chip to feed colours, which will increase the number of real colours per scanline to 56, and interlaced colours to 112. By doing this, the entire 29791 colour spectrum could actually be displayed on screen at once. I've yet to calculate how this would actually work out with the border removing, if it's possible at all. Doing this would require a new custom written conversion tool though.
    For plain 320x199 resolution, Zerkman/Sector One already did a Blitter chip version of Spectrum in the Antiques demo from 2012, great work there Zerky.

  3. Medium resolution version with Blitter chip colour feed and borders removed. Some thing here, needs a custom conversion tool.
    RA of Paradox did his own Med-res multi-colour display, though without Blitter and without removing borders (still 199 scanlines), but very cool stuff.


NEWS NEWS!
Since the release of this article, there have been major updates of Photochrome and a brand new tool from Zerkman has been released. Both which more or less surpasses the methods described above (not in all cases though). The main thing is that using their tools is far easier.

»» Check out Photochrome 5.xx by Doug Little !
»» Check out Zerkmans MPP !

Enough of this..
Are you still reading? Then stop and go code the old Atari instead!


 
Anders Eriksson - September 2012

© 1994-2024 Dead Hackers Society Contact: Anders Eriksson