[Oberon] [EXT] Display patterns [WAS Re: ORD for typecasting Pointers]

[Skulski, Wojciech]

Paul:

  I looked at the Extended Oberon Display.Mod, which according to github is just two hours old. One thing which I immediately liked was:
VAR arrow*, star*, hook*, updown*, block*, cross*, grey*: INTEGER;

Wow. This is an electrical engineer's dream. We know what we are dealing with. Plain and simple. Forget this POINTER stuff.

I also noted that this Display.Mod is heavily monochrome. I cannot even think how to possibly handle color in the raster operations, CopyBlock, etc. This is actually good. It looks that one has to rethink the entire design rather than try fixing the monochrome pixel manipulation.

To this end I think that Display can be broken into a high level module defining the opaque high level patterns, and a low level implementation module written in terms of pieces of memory.The high level module will use the notions of a character, a cursor, etc. But the actual bit layout of these will not be known to the high level module. The low level module can then be mapped onto some new hardware, like you said. 

The present Display.Mod looks like both the high and the low level modules merged into one. It is sort of hard to think of it as a high level general interface to low level hardware, because the bit map operations are low level. 

Imagine how you could possibly implement the interface to FTDI FT813 where all these bit operations are on chip, and the commands are high level. Converting the present Display.Mod to an FT813 driver could be an interesting challenge to provide only the high level commands, but no implementation.

https://www.ftdichip.com/Products/ICs/FT81X.html

Wojtek

________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Paul Reed [paulreed at paddedcell.com]
Sent: Monday, September 14, 2020 5:57 AM
To: ETH Oberon and related systems
Cc: Andreas Pirklbauer
Subject: [EXT]  [Oberon] Display patterns [WAS Re: ORD for typecasting Pointers]

>> Fonts should import Display!
>     > The type Pattern should be in Display, as only Display knows the
> bit layout if you add colors to the system.
>     > br
>     > Jörg
>
> Agreed (and done in EO).

I don't disagree, certainly that was the way it was originally; but I
thought of this pattern as a sort of device-independent bitmap,
specifying which pixels should be some foreground colour (or inverted,
whatever that means in >1bpp) and which should be left at background,
but of course all of this is quite messy as it meets varied real
hardware.

Also I always like the removal of a dependency, ceteris paribus. Maybe
that clouded my judgement. :)

Certainly loading the font is probably a good time to map this
device-independent pattern to some sort of device-dependent bitmap,
assuming lots of memory and a rich set of raster operations - and I
agree that needs to be done by Display. OTOH, Display could perhaps
maintain a hash table of patterns which are passed to it to keep the
mapping private.

Yet another example of how an apparently simple and desirable feature,
colour, can have a huge and unexpected cost.

It's the philosophy of Oberon to force an evaluation of what could
possibly be worth the cost, looking from the point of view of those who
have to design, implement and document, and later, understand again.

Cheers
Paul