[Oberon] FPGA - Colour Support
joerg.straube at iaeth.ch
Thu Oct 12 09:32:58 CEST 2017
In your design you foresaw 4 planes so indeed 16 colors.
If you foresee 3 planes then it depends on how VID.v generes color:
- with colornap: if index 0 is black and index 1 is white, it‘s enough to put a 1 in plane 1 to get a white pix.
- without color map: you have to put a 1 in all three planes to get a white pux
> Am 12.10.2017 um 09:18 schrieb Tomas Kral <thomas.kral at email.cz>:
> On Sun, 8 Oct 2017 17:55:09 +0200
> Jörg <joerg.straube at iaeth.ch> wrote:
>> Other memory organization are thinkable. Eg stacked 1bit planes. With
>> such an memory organisation it would be easy to increase the bits per
>> pixel from 1,2,3 and so on. If you clear the whole framebuffer and
>> only write to the first plane, you have B/W.
> Now experimenting with colours and realising I am not too sure how
> stacked bit planes work. I was thinking of this..
> (* display buffer addresses *)
> (* bw_plane := ... *)
> (* red_plane := bw_plane + size of (bw_plane) *)
> (* green_plane := bw_plane + 2 * size of (bw_plane) *)
> (* blue_plane := bw_plane + 3 * size of (bw_plane) *)
> SYSTEM.PUT(bw_plane, 1) (* sets pixel on/off *)
> SYSTEM.PUT(red_plane, 1) (* sets the same pixel red *) OR
> SYSTEM.PUT(green_plane, 1) (* sets the same pixel green *) OR
> SYSTEM.PUT(blue_plane, 1) (* sets the same pixel blue *)
> Perhaps b&w plane could also drive luminosity/intensity, so we could
> have 16 colours in the end?
> Am I close?
> Tomas Kral <thomas.kral at email.cz>
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon