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.

Refactoring complete

For the last couple of months I've been doing some major refactoring of Prism's glue logic, data bus mux, MMU and SRAM/flash memory control subsystem. This has been a heck of a lot of work for very little in the way of new features - however it's reduced the delay on a lot of signals which means that hopefully, with a little tweaking, Prism should be able to run stable at faster CPU speeds.


The new features added during this time are minimal but potentially useful:

1. Spectrum +2A/+3 special memory modes added. Not much software that I'm aware of uses this "CP/M" or "all RAM" memory configuration - except CP/M of course and John Elliott's wonderful ZxZvm (which lets you play various Infocom adventures like Zork and Hitchiker's Guide to the Glalaxy on the Spectrum). A number of people, including me, have also written utilities to run ROM images (like the Interface 1 ROM cartridges) using this memory configuration.
2. A selectable "Video RAM Aperture". Select between VRAM being accessible by the CPU at memory addresses 0x4000 - 0x5AFF (default) or VRAM being the entire 16K between 0x4000 and 0x7FFF.  The advantages of the default mode are that the system variables, printer buffer and the beginning of BASIC don't get stored in video memory and so allow the user to use video modes which use more VRAM than the standard Spectrum screen mode from BASIC without crashing (careful use of the "planar write mask" lets you write to other parts of VRAM). The disadvantage of the default mode is that software which uses certain Timex screen modes expect VRAM to be at 0x4000 - 0x5AFF and 0x6000 - 0x7AFF. So both modes have their uses. If using SE Basic in double-width mode for example, you will need to switch to the 16K VRAM aperture. 

So just a quick update despite the fact I've just finished a bucketload of work (and still have a metric shitload of testing and tweaking to do!). I'll leave you with an "actual Prism screenshot!!!" teaser from when I was testing the VRAM aperture - a 16 colour, no colour clash image displayed using the 4-plane planar mode: