[Oberon] FPGA - Display.Mod 4-bit colour

[Jörg Straube]

Tomas

Graphics needs memory: firstly the colored framebuffer and offline bitmaps take a lot of memory, secondly the whole Gadgets system needs a lot of code.

So, with only 1MB of RAM it’s questionable to port all graphics modules over to ProjectOberon. You can do it, you then have a colored OS but there is almost no space left for a reasonable application.

This was the reason why I restricted myself to 800x600 @ 16 colors, and I reduced the stack size a little to have a little more space for the apps.
Hint: stackSize is declared in Kernel.Mod, but Modules.Mod still uses an own hard coded constant (iso of importing Kernel.stackSize!)

I put the map manipulation in Display.Mod and recompiled the system. Be sure you recompile ALL modules and they compile correctly. If not, booting the new system will provide some headache😊

Fonts are stored B/W. So, you have to „colorize“ them. In the first version of Display, you probably stetch the pattern each time you draw a letter, obviously slowing down the whole text system.  In a second step, you might modify Fonts.Mod (and Display) to colorize/stretch the whole font once, and Display can use the pre-stretched font patterns right away...

br
Jörg

> Am 16.10.2018 um 21:57 schrieb Tomas Kral <thomas.kral at email.cz>:
> 
> On Tue, 16 Oct 2018 01:26:45 +0200
> Tomas Kral <thomas.kral at email.cz> wrote:
> 
>> Noticeably, Display does not seem to have the same intensity down
>> across, at the the 1/3 upper top appears slightly darker.
> 
> Hi,
> 
> This seems a matter of vision angle, I have tried to leave out
> hsync/vsync signals just for the thrill of it, than indeed picture is
> dark at the top of the screen.
> 
> So is probably right what is does, except I cannot decide on the
> palette map. In RGB triplet, leftmost byte influences RED most,
> middle green, and last blue. But looking at the map entries, it appears
> as if the other way round.
> 
> $000080H displays as deep red, while I would expect blue.
> 
> Another thought, in `Display.Mod' I can see,
> CONST black* = 0; white* = 1(*5*);  (*black = background*)
> 
> Now white may become 15, $FF or -1 in other terms. But changing it
> would require rebuilding other system modules.
> 
> I have added in the Top module, a simple `IF' instantiating second map
> index based on the mode. Not sure if brightest idea.
> 
> I wish to add two procedures to manipulate the map SetMap(), GetMap(),
> but where?
> 
> `Display3.Mod' might be the option or non-existent Display2. 
> 
> I thought Display3 not only provides simple graphics primitives
> polygons, rectangles, etc but also acts as underlying functionality for
> Gadgets, correct?
> 
> What other functionality of Display3 makes sense porting to RISC?
> 
> Thank you for reading this.
> 
> -- 
> Tomas Kral <thomas.kral at email.cz>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon