[Oberon] Oberon bare metal on the Raspberry Pi

[eas lab]

This is very interesting.
Did you discover/analyse the mysterious/pressumed-hidden layers between
rPi's hardware, the Microsoft initial-loader and reading the SD?

Let's name/ID it as "Native ..." in order to reuse the existing notation.
[minimal forking of syntax is a (perhaps unstated) main aim of NW/Oberon].

NativeOberon *BROKE* when OFSTools.Unmount & OFS.Tool
together-came-into-existence.
This is *DISASTEROUS*!!  Users continually fall in a hole/trap!!
The syntax is <ModuleName>.Tool, <ModuleName>.<command>
It's like a fundamental flaw in the constitution of some banana-republic.
Imagine if the highways of 1st-world societies didn't constrain [prohibit
forking] the traffic to ONE-side, and like India, there were animals
wondering in
the roads, and 'drivers' improvising on keep-left/right.
-----------------
> Better compilers will come!

How does the compiler, which normally relates to the HLL:Oberon relate to
the LLL-function of driving a single OutPort-line - blinking LED?

It would be educational to discuss this HERE, rather than to point to 'videos'.
I want to throw out some original ideas/experience re. assemblers, IF there are
readers-here who have knowledge/interest of such LLL.
==============
Re. Astrobe - LPC1769 Microcontrollers:
 I failed to find [via http] the comparative power consumption.
IMO rPi IS a remarkable substitute-PC; but the extra layers make it unsuitable
for  eg. controller applications.
Would Astrobe-Oberon7 also be subject to random delays due to GC?
I expect the FPGA hardware would be a small-fraction of the RPi's 300Ma average?
====
The ignoring of the OFS.Tool broken syntax, show that nobody else *USES* ETHO.
It's just a demo/toy; never to leave the show-room to make a serious journey.
Unfortunately for me: Astrobe/Oberon7 is NOT ETHO, and no knowledge about the
<halfShading> of the MenuFrame is needed/available - or ?
To help me get a clue, I looked at V4 again. It's also a magnificent project;
and there, the MenuFrame reverse-videos.
 If I could find the V4 code that reverse-videos; I could perhaps relate that
to the S3 code, and find the underlying hardware-control function, which on my
preferred display loses <half-shading> the MenuFrame; but only after cycling
through a random/unknown number of linux apps; but not with the other linux
distro.

It's the non-awareness of such subtleties that exposes the difference between
show-room-models and real-life usage.

!! => PETER MATTIAS of LNO may be able to help me, since he fixed an early
version of ALO's MenuFrame <change appearance on activation>.

As a further example of real-life subtlety: I NOW noticed that ALO's top-screen
MenuFrame was blacked-out, but the lower one was less dark and slightly visible.
How is that possible ? !!
So I stood up, to avoid viewing the screen from below, and realised that the
effect is due to the <semiconductor viewing angle>.

Again: What hardware/video function is use on the MenuFrame - PLEASE ?!

Thanks,

== Chris Glur.