[Oberon] FPGA - Colour Support

[Skulski, Wojciech]

Joerg:

Please note that a color lookup table can turn a 4-bit or 8-bit color into a vivid palette. I think that 8-bit would be quite perfect for a scientific kind of applications, where one wants to display a contour plot of two dimensional X-Y density distributions. Think of an elevation map, for example.

A 2 MB system seems a minimal requirement because one needs RAM not only for the framebuffer, but also for the map itself. I wonder how far we could go with such a minimal hardware. 

It will be also valuable to think a little bit ahead and setup the scheme where larger memories will be available, like Pipistrello or my future boards.

Thank you,
W.
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Jörg [joerg.straube at iaeth.ch]
Sent: Sunday, October 8, 2017 11:55 AM
To: ETH Oberon and related systems
Subject: Re: [Oberon] FPGA - Colour Support

Hi Tomas

Magnus Verilog code for color does not allow to have a separate B/W screen.
His code assumes that 4 consecutive bits in memory form one color pixel.

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.

But the BIG drawback of such a color memory scheme is, that every color pixel needs several memory accesses, one per plane.
I thnk consecutive pixels are more efficient. Generalizing Display.Mod from 1 to 2,4 or 8 bpp is a good exercise.

br
Jörg

> Am 08.10.2017 um 16:06 schrieb Tomas Kral <thomas.kral at email.cz>:
>
> Hi Joerg, Wojtek, Magnus, All,
>
> Thanks for all your posts and recommendations.
> - 2MB of RAM, something I plan by chip piggy back, while driving upper
>  meg with CS, from `Verilog' code.
> - overclock to 30MHz
>
> As I have got `Pepino' board with 1MB, and 25Mhz, this can make an
> interesting exercise for students.
>
> What I need to solve however first, is how to map b&w screen
> in memory completely separate from colour bit planes. This would allow
> using `Display.Mod' unchanged while programming colour logic.
>
> In other words, one bit in memory tells if the display pixel is
> illuminated or not, the other bit planes, tell if there are also some
> colours to add to it.
>
> In the two designs I have got so far, several bits in memory control RGB
> of a single display pixel, this results in seeing entire display buffer
> duplicated several times on the monitor.
>
> --
> Tomas Kral <thomas.kral at email.cz>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=c-nwIfpG8ZPmfIOKOanqiCS-qsYLg84x0wIrnR5eRc8&s=usJDtJufLWbupgufaCr6CRrH38RqO_rY_K6_0gMJhB8&e=

--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=c-nwIfpG8ZPmfIOKOanqiCS-qsYLg84x0wIrnR5eRc8&s=usJDtJufLWbupgufaCr6CRrH38RqO_rY_K6_0gMJhB8&e=