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

[Joerg]

Sorry, I wanted to write: the implementation module is not imported at all, having a reference count of 0 and hence can be System.Freed

br
Jörg

> Am 15.09.2020 um 08:57 schrieb Joerg <joerg.straube at iaeth.ch>:
> 
> Your split in „high level“ and „low level“ will be done by my HW enumerator as well but due to another reason.
> I would call the „high level“ = definition module and „low level“ = implementation module.
> The important difference is, the definition module is imported several times by higher modules, therefore having a high reference count, and the implementation module is only imported once with reference count 1, hence can be „System.Free“d easily.
> This can be useful to change from a mono implementation to a color implementation at runtime.
> 
> In your FT813 case the implementation is „just“ an Oberon wrapper around the HW routines.
> The implementation will have the same set of procedures with the same set of parameters as today’s Display.Mod and will generate the needed SPI sequences to mimic the procedure‘s intended behaviour.
> 
> br
> Jörg
> 
>> Am 15.09.2020 um 07:50 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>> 
>> 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
>> --
>> 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