[Oberon] [EXT] RISC5 Project Oberon on Digilent's NexysA7

[Joerg]

Wojtek

>> An onboard VGA socket
> 
> It is using 12 bits, 4 bits per R,G,B. In principle it can display 4k colors. It is rising the question how Project Oberon wants to handle color? A one-off Display per each board will lead to explosion of possible combinations. Are there any "official" plans to provide a universal color handling for Oberon System in general, which could be then customized to a particular palette: single bit B/W, four bit 16 colors, 8-bit pseudocolor with a lookup table, 12-bit color for Nexys, and other color depths for other boards?

The current Oberon API is not as bad as it might look at first sight.

The current „official“ graphics API provided by Display.Mod does already support colors.
The first parameter of all drawing routines is the color „col“ declared as INTEGER, so offers the possibility to distinguish 2^32 = 4 billion colors.

The proof of this fact is, that I implemented a color display. I „only“ had to provide the color HW (VID.v) and the corresponding driver Display.Mod. I did not touch the other parts if the Oberon system.

Officially supported by the current Display API are the color names „Display.black“ and „Display.white“. These can be used by the applications and it’s up to the driver to map those two colors to what ever internal color system it implements. A possible set of color systems a driver might implement is index4, index8, color332, color444, color565, color888...

The only thing that is really missing in the „official“ standardized API is the possibility to allocate a specific color to the parameter „col“. So, currently „col“ is just a number, and the meaning of this number is left to the driver.
As example: Currently it is well possible to call Display.Dot(13524, x, y, Display.paint);

But the program doing so has no means to tell the driver whether color 13524 is yellow, dark pink or marine blue. The driver defines the colors.

There are different possibilities to improve this situation:
1) we could define an official standardized way how „col“ is coded, eg define that „col“ uses color888 (aka TrueColor) and all drivers have to map this color coding to their color system. So, col=0FF0000H is red, col=00FF00H is green and so on.
This definition has the benefit: you don‘t need a new API. It‘s a convention how to use the „col“ parameter every driver has to know and to follow.
    Display.Dot(0FF0000H, x , y, Display.paint) draws a red dot.

2) Alternatively, we could define an extension to the API, eg 
   PROCEDURE RGB(r, g, b: INTEGER): INTEGER;
It returns the „col“ value to be used in the internal color system.
If the driver uses internally color332 a call to
  RGB(255, 0, 0) returns 224.

  Display.Dot(Colors.RGB(255,0,0), x , y, Display.paint) draws a red dot.

Other nice-to-have features would be
- To display patterns it is nice to have a foreground and background color. So these two variables could be introduced.
- it is nice having a query function to ask the driver’s color capabilities (IO address, color depth, with/without palette)
- it is nice but not mandatory being able to change the color depth while Oberon is running in case the driver offers this capability.
- the current Oberon system does not support changing the screen dimensions while Oberon is running. This is not only something the driver would have to offer, but some adaptions to the Oberon system must be done to support this dynamism.

The explosion of SW you mention can hardly be avoided. For N different HW types you need N drivers. The HW driver for your HW has to be written.
In a first step you might have N different Display.Mod. Eg. I have the files
- jr.Display768x1024x1.Mod   (BW)
- jr.Display800x600x4.Mod    (16 colors)
- jr.Display768x1024x8.Mod  (255 colors)
all implementing the same driver API Display.Mod.

br
Jörg