Mode 3

[redbox]

Can anyone help explain to me how Mode 3 works (as described on Grim's website here)?


I see it's basically Mode 0 with only a 4 colour depth.  I have an effect I'm working on (which suits a 4 colours and 2 pixels per byte setup), but was wondering if using Mode 3 would give me any benefits over Mode 0 - for example, can you shrink the VRAM space?  Does it make double buffering any easier etc.?

[Optimus]

I think mode 3 is 4 colours in Mode 0 but without the advantages of such a mode. The screen is not 8kb as I'd expect but still 16kb. The bit permutations for the unused colours don't have any effect or maybe they cycle again over the 4 first colours, I don't remember. Now, if this would be an 8kb vram mode it would be great but unfortunatelly I don't see any usefuleness in it. I was told there is no use in Mode 3 but I'd like to hear otherwise.

[Devilmarkus]

It's also 16k screen ram but you can theoretically keep 2 screen contents in the same ram area and toggle them by byte shifting.
For more info, ask Kevin Thacker.
He did a little mode 3 test program, where you can toggle between 2 screens.

[redbox]

It's also 16k screen ram but you can theoretically keep 2 screen contents in the same ram area and toggle them by byte shifting.
For more info, ask Kevin Thacker.
He did a little mode 3 test program, where you can toggle between 2 screens.

Now this sounds very interesting.  Do you have any links for the test program?

[Devilmarkus]

Here you go.

(no palette is set... pure test!)

Use space key to toggle images

[redbox]

Use space key to toggle images

Thanks for the demo. 


Do you mean the here the data is just stored in half bytes, which means two pictures are in 16kb?  It looks like from this demo data still has to be copied to the screen...?  If so, you could also do this sort of thing with normal Mode 0 (albeit with only 4 colours) by also storing the data in this way.


I was hoping Mode 3 gave you some little advantage in some way because Grim's website says it's "a bit weird but may be useful in some very special cases".

[Devilmarkus]

Sure it needs to be copied to screen ram.
But both screens are in the 16k file!
It's done by byte shifting.

[andycadley]

I was hoping Mode 3 gave you some little advantage in some way because Grim's website says it's "a bit weird but may be useful in some very special cases".

Nothing that couldn't be equally accomplished by Mode 0 with careful palette selection. Mode 3 is basically just a quirk of the way the hardware is wired up and not actually useful in any practical sense.

[arnoldemu]

I was hoping Mode 3 gave you some little advantage in some way because Grim's website says it's "a bit weird but may be useful in some very special cases".

Andy is correct, mode 3 gives you nothing.
No advantage, and still takes 16k, just some bits are not used in each byte.

[ssg]

how about saving collision mask for the game screen? although that game would have sucked with such wide pixels and only 4 colors

[redbox]

Thanks for the help guys.

Thought Mode 3 was like this, but worth asking. 

[steve]

Maybe you could generate a 3D display?, two screens switched 50 times a second, using coloured glasses as they do with 3D TV/Films.

[redbox]

Maybe you could generate a 3D display?, two screens switched 50 times a second, using coloured glasses as they do with 3D TV/Films.

Problem is there isn't a way of accessing the data for the 2nd screen directly.

You have to shift the bytes and this takes a long time, way longer than is possible using 50hz. 

[steve]

Could you use double buffering so the processor can write to one 16k ram block while the other block is being displayed?, I don't know if 3D is possible with the CPC, but it would be great if it was.

[steve]

@redbox, are you saying the machine cannot access the second screen data directly, so it must be moved by the cpu to be displayed?

[andycadley]

@steve, yes exactly. However if you do the same thing with Mode 0 you should be able to switch between 4 colour screens with just a palette change.

[redbox]

@redbox, are you saying the machine cannot access the second screen data directly, so it must be moved by the cpu to be displayed?

As Andy said, you're completely right.

It's a shame, because Mode 3 stores the a byte of data as 11XX11XX, with X being unused.  If you could switch to XX11XX11 using the hardware then some good effects could be made (maybe such as you described) but alas it appears it's not possible.

[AMSDOS]

This has me stumped. According to Video Modes MODE 3 uses the same Bits per Pixel (BPP) as Mode 1 and yet it's only 160x200!    Does this mean it's sort of limited to a Spectrum Sized screen? (which a number of games used anyway to allow for more coding?).

I simply interpret it as a quirky mode. Pity the CPC cannot have 80x100 with all 27 colours anywhere on screen (not the split screen effect kind!  )

[arnoldemu]

This has me stumped. According to Video Modes MODE 3 uses the same Bits per Pixel (BPP) as Mode 1 and yet it's only 160x200!    Does this mean it's sort of limited to a Spectrum Sized screen? (which a number of games used anyway to allow for more coding?).

I simply interpret it as a quirky mode. Pity the CPC cannot have 80x100 with all 27 colours anywhere on screen (not the split screen effect kind!  )

Yes it uses the same BPP, and yes it's 160x200. But some other bits are ignored.
It's just how the video hardware creates it.

Think like this:

every microsecond, the gate-array reads 2 bytes of data into it's internal memory.
Then using mode information it decodes the pixels in a certain way.
Then also, depending on mode it then "shifts" the pixels out to the monitor until all are done.
It happens that it shifts at mode 0 rate, but decodes like mode 1.

The screen size is the same as mode 0/mode 1/mode 2 in terms of border size, chars per screen, just looks different, and the other bits in the byte are ignored.
Is it useful, well, not really, I've not found something it can be an advantage for.

[AMSDOS]

I had a look at Markus' example which seems to suggest that it can incorporate 2 screens within a 17k program, so perhaps that's the only good thing about Mode 3, otherwise it's an unusual example.

[arnoldemu]

I had a look at Markus' example which seems to suggest that it can incorporate 2 screens within a 17k program, so perhaps that's the only good thing about Mode 3, otherwise it's an unusual example.

That was actually my test program.

The test was 1) to check mode 3 was decoded correctly in emus, 2) to test on cpc clones to see if they were compatible in this respect, or if they decoded it different.

Yes you can hold 2 screens within the same 17k, but the only way to switch between them is to use a software loop to shift the bits up and down. You can't switch in hardware.

[sigh]

Are we talking split screen?

[arnoldemu]

Are we talking split screen?

no

Mode 3 is an artifact of the cpc's design. It's almost useless because it is same resolution as mode 0 but with 4 colours, some bits in each byte are ignored, so it doesn't take any less ram than normal mode 0.

[TFM]

Well, there is a use for Mode 3 ... think about SHADDOWS ;-)

And as second hint... think about switching between Mode 0 and 3 ;-)

Got it ;-)

[AMSDOS]

That was actually my test program.

Sorry! 

The test was 1) to check mode 3 was decoded correctly in emus, 2) to test on cpc clones to see if they were compatible in this respect, or if they decoded it different.

Yes you can hold 2 screens within the same 17k, but the only way to switch between them is to use a software loop to shift the bits up and down. You can't switch in hardware.

So that means it won't work with SCR SET BASE or LDIR (or simular instructions).