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

[Charles Perkins]

Confirming what Jörg said,

I just this week finished adding color support (just 1, 2, and 4 bits per
pixel) to my local copy of Peter De Watchter's risc emulator and when I ran
Tetris on it I was surprised to see the blocks showing up in colors!

My reason for having 2 bits per pixel is to support black, dark grey, light
grey, and white for smoother fonts and nice looking UI elements with a low
memory-bandwidth impact. I can see Oberon being useful in the very small
and cheap chips like the BL602 and the ESP32-C3 that are just coming out
and don't have enough resources for full color displays at desktop size but
could possibly support less bandwidth and memory-intensive ones. I would
like to see a $5 Oberonstation with wifi...

The only changes I had to do to Oberon itself was to adopt drawing routines
taken from Display.Mod in the Color Oberon image of MIchael Shierl's
Javascript emulator, which says in the source was based on Jörg's code. The
code was not difficult to port and works for me now in monochrome as well
as 4 and 16 colors. Here's what I'm using at the moment:
https://github.com/io-core/Oberon/blob/main/Display.Mod

This emulator identifies the video capability by checking for a "depth"
field along with "width", "height", and "base" fields with a new magic
number, extending Peter's emulation scheme.  I think it would be better
though to have several registers at the top of memory that gave that
information and also, perhaps, allowed for setting color palette values,
video base, resolution, etc.

Best Regards,
Chuck

On Thu, Dec 24, 2020 at 4:25 AM Joerg <joerg.straube at iaeth.ch> wrote:

> 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
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20201224/32976b07/attachment.html>