Saturday, August 29, 2015

New graphics modes

Today I did a little bit of poggling around with the VGA driver and started adding some new functionality to it. There's still some tweaking to be done, but here's a taster.

Last year, I did some experimentation around a hardware GigaScreen mode which did some tricky work interpolating pixels from the main and shadow screens depending on if it was an odd or even frame. This was an interesting experiment but the results left a lot to be desired on most monitors. Today I tried a different method - looking up the physical colour for the corresponding pixels on the main and shadow display, then blending the two. This seems to work quite nicely.

Some blended colours, yesterday.

A couple of days ago I was reading up on the various graphics modes on other computers and came across documentation on the Commodore 64's low-res multicolour mode which halves the number of pixels per colour cell (from 8x8 to 4x8) but increases the number of colours per colour cell from 2 to 4. I decided that this sort of thing would be easy to add to Prism.

I toyed with two different ideas - the first maintained the usual 256x192 resolution, and the second halved it, like the C64 mode. In both cases, a pixel is defined by two bits instead of the usual 1 bit - but in the first case pixel data bits are read 'progressively' and in the second they're read in pairs:

256x192 res: (Bit 7 + Bit 6)   (Bit 6+Bit 5)   (Bit 5 + Bit 4)   (Bit 4 + Bit 3)  (Bit 3 + Bit 2) etc
128x192 res: (Bit 7 + Bit 6)   (Bit 5+Bit 4)   (Bit 3 + Bit 2)   (Bit 1 + Bit 0)

Normally, this pixel data would be 1 or 0 indicating ink or paper, the colours of which are defined in the associated attribute byte. In both these modes, the pixel data has 4 states: paper, ink 1, ink2 and ink 3. Paper is defined by the attribute byte in the usual way - bits 3 to 5 of the byte give the paper colour 0-7 and bit 6 indicates bright or not.  The ink colours ignore the bright bit (bit 6) and instead, inks 1, 2 and 3 are all the colour 0 to 7 as defined by bits 0 to 2 of the attribute byte but their intensity differs:

00 - Paper (colour 0-7, bright 0 or 1)
01 - Ink (colour 0-7, brightness intensity 1)
10 - Ink (colour 0-7, brightness intensity 2)
11 - Ink (colour 0-7, brightness intensity 3)

This isn't quite how the C64 chooses the colours, but it's sufficient for this experiment.

In short, the first method produces a sort of "anti-alias" effect, and the second is similar to the Commodore's "rectangular pixel" mode. Whilst some spectrum owners laughed at the blockiness of the Commodore mode, there's no denying that in the right application and with a little bit of thought, it can produce some great results.

The following pictures show these modes in action on Prism. The images were basically chosen at random to show the effect, rather than being selected to showcase it....

"Antialias" or "progressive" 256x192 4 colour-per cell mode


Glorious Chunk-o-vision! 128x192 4 colour-per-cell mode

X-Out in Chunk-o-vision

Mr Heli's scoreboard in chunk-o-vision.
More or less readable even though the resolution's halved 

X-Out in-game Chunk-o-vision. Not too bad if you squint.
(apologies for the bad picture but you get the idea)

Mr Heli in-game Chunk-o-vision
It looks a little better when it's all moving

This is all early stuff anyway - future experiments may include centring the screen and making the pixels square again so it's less chunky. I'll also experiment with different ways of deriving the ink colours - currently its 3 intensities of the same base colour... The C64 has registers for selecting the other two inks. I could also try making the new 2 colours being blends of the ink and paper. Hmmm.

3 comments:

  1. could anyone get their hands on the music code for the ay8912 in the amstrad version please
    http://www.worldofsam.org/node/670
    how to get ay8912 code running on the saa1099 it is possible!

    https://youtu.be/WK3yqT8lF74
    https://www.youtube.com/watch?v=Jrc_IMrzTgY
    https://www.youtube.com/watch?v=GYj6Kyzfopg

    ReplyDelete
  2. Sorry Roger, I don't see how that's relevant to the Prism - it's neither a Sam or an Amstrad and doesn't try to implement compatibility with either ;)

    ReplyDelete
  3. Nice to hear from you again though! Glad you're still following the project.

    ReplyDelete