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.
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.
could anyone get their hands on the music code for the ay8912 in the amstrad version please
ReplyDeletehttp://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
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 ;)
ReplyDeleteNice to hear from you again though! Glad you're still following the project.
ReplyDelete