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

Thu Dec 24 17:45:40 CET 2020

I look forward to seeing what you come up with.

Perhaps we can learn something from the "device tree" dtb and dts that ARM
devices use to make sense of the diverse devices that show up in phones,
tablets, embedded devices, etc.

Perhaps what we learn is "don't do it like that..." because parsing a dtb
is complicated!

We need something that matches the Oberon style of "lean code"

My own code often does not match up to that ideal, which I regret.

Cheers,
Chuck

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

> Chuck
>
> I‘m working on a more general approach HW devices (like eg graphics) can
> reveal its capabilities to the Oberon system than spending memory addresses
> for graphics.
>
> br
> Jörg
>
> Am 24.12.2020 um 14:46 schrieb Charles Perkins <chuck at kuracali.com>:
>
> 
> 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
>>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
> --
> 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/14132ef1/attachment.html>