As I am working on the Replic’Oric project, the second step (and what will become the StratoCumulus) become clearer and clearer and the most important changes is the add for a “recolouring” overlay mechanism.

This blog entry is the first documentation on what will become this new display mode.  Both The “New Oric” and the StratoCumulus will provide it.

There is 16 palettes (4bit), with 8 entry for each palette, the entry will replace the original ULA colours by the defined in the palette.

Each colour have 4 bit per component (total 12bit: 4096 possible colours)
So we could display (without raster & mid-frame change tricks) a total of 16*8 = 128 colours per screen.

There is 8 colour mode, three specialized for both ULA mode (Text and Hires) and “normal mode” where only one palette is set for the whole screen. All other mode are region based colour map.
Mode 7 is still to be defined

So each palette will have a number between 0 to 15, which use 4 bits.

mode 0 = 1 block of 240x200 => Global Screen Mode => Use 4 bit => 1 byte
mode 1 = 40 x 25 block of 6x8 (Text mode) => Text Mode => Use 40*25*4bit => 500 bytes
mode 2 = 40 x 200 block of 6x1 (Hires Mode) => Hires Mode => Use 40*200*4bit => 4000 bytes
mode 3 = 14 x 13 of 18x 16 => Small Region => Use 14*13*4bit => 91 bytes
mode 4 = 8 x 7 of 30x 32 => Medium1 Region => Use 8*7*4bit => 28 bytes
mode 5 = 4 x 4 of 60x 56 => Medium2 Region => Use 4*4*4bit => 8 bytes
mode 6 = 2 x 2 of 120x104 => Large Region => Use 2*2*4bit => 2 bytes
mode 7 = TDB

So there is a maximum of 4000byte to (<4KB) to be transferred for the worst mode (Hires)

/!\ This colour modes does not change the ULA behaviour it will just replace normal colours by a palette system with multiple possible colour maps /!\

The goal of this is to keep maximum compatibility with original hardware and may allow to use the text mode as a more advanced tile-map engine as is it currently.
(sorry still not possible to do pixel precise scrolling.)

Mode 3 to 6 “colour overlay” are slightly larger than the real screen (240×200) this is due to rounding error, and the all region are just cropped (everything that goes beyond the screen 240×200 is just ignored)
Mode 7 could be do to be a “Hicolour Hires mode” in a per pixel palette, but this mode can’t be used (at least to change frequently the colour map) for anything else than still pictures.
This mode will consume 24000 bytes.

This colour-map video memory should be normally accessed via new registers in the $0300 address space. It could also be possible to allow access to it through the overlay mechanism.

I will make an Oricutron Patch to propose this behaviour on emulated Oric to let people try this way of (re)colouring the Oric.

There is no plan on changing the display resolution, or add new behaviour on the standard ULA display buffer.
The only thing I think that could be added is some sort of hardware sprites but at the expense of not being compatible with standard Oric.

All comments are welcome.