[Oberon] Oberon-1 or Oberon-2?

[eas lab]

skulski at pas.rochester.edu wrote:-

> I also wrote a graphics system with System-3 Gadgets, which I later
> converted to Component Pascal. (This graphics is still being used in
> one of the most advanced physics experiments of our times.)

Perhaps you have knowledge of the physics/hardware re. this ETHO problem?

Symptom list:----------------------

LEO [ETHO for Linux x86] starts looking nicely on the <LED>-display,
  but after cycling through several other non-ETHO programs,
  and being un-used, which causes sleep-mode,
  the ETHO-MenuFrame loses it's gray <background> color, which goes white,
  and it's no longer possible to distinguish the several displayed TextFrames.
Also LNO, gets this same problem.

Plugging the vga-lead from the LED-display to an old CRT, shows <no problem>.

Switching the LED-display to show the rPi's ALO [ARM linux ETHO],
 input via HDMI [instead of vga] shows no problem.

A different linux distribution, tested for 3 days, showed no problem.

So, it's a special combination of factors that causes the problem.

While the system is in the problem-state [now]:
 LNO [Ver.ca. 2010], via FrameBuffer shows Colors.Panel
 The color-circle looks ok; is oval, because the LED-display is
"wide":1920x1080.
 Importantly: the 'Pie-sector' of Colors.Panel shows the continuous range:
       black..*gray*..white.

==> Switch to rPi:ALO:HDMI-input to same Display.

Switch to ALO, which needs swapping Keybrd & mouse & fiddling-Display-TreeMenu.
WOW !! ALO is still running the fancy-screen-saver from 3-days-ago.
NB, ALO's screen background is clearly gray compared to the surounding
 LED-display's WHITE, which is an important clue.
LEO via vga-connector was more 'white'.
Let's test <char & background> for all <16 colors> via: ET.Color <N>
NB. colors: 1, 7 = Red, Brown show OK on ALO; but are both=Red on bad-system.
Try: <search *.Mod  for "enu">  easiest via *nix,
     but test: Desktops.OpenDoc Find.Panel =OK!!
=> ALO.TextFrames.Mod ==...    MarkColor := 12; MenuBG := 13; TextBG := 14;
Actually. ALO's MenuFrameBackgroundColor looks more like <12> than <13> ?

===> Now switch back to vga:LEO to paste/post test results.

Yes, bad-symptoms also on non-ETHO programs:
xpdf and <smart-ass full featured browser>'s some places.

But *interestingly* ETHO allows us to analyse this problem to a deeper level:
eg. using ALO's code [which would be the same as LEO's & all ETHO code]
What does *THIS* mean: write "CCCDDDEEE" and 'apply' ET.Color 12,13,14
respectively to the 'triplets'.
They ALL become invisible against the background-color.
But 'Selecting the 9-chars, which gives a black-background, reverse-video-shows
ONLY "CCC". So Colors 13, 14 don't reverse-video when selected.
Since it's easy to select any part of the screen, I can confirm that all colors
that I've used DO reverse-video, when selected; only not color-12.

Conclusion:
The problem is that MenuBackGround:13 & TextBackGround:14 show the same color,
after the system has booted and passed throught an unknown sequence of states.

How do you get from red to brown?
Replace LED-display with old CRT! How could I previously read the small script?!
Viewing LNO:Colors.Panel = very different. Bad/new display was mostly white in
middle of <color-circle>. And CRT's pie slice is not gray/black, but brown.
 and the controls are "visible".

NB. a not yet understood clue:
LNO:Colors.Panel has 5+11=16 <ColorWells> at the bottom.
The group of 5, relate to the problem. They correspond to the circle-mid-area.
I'm guessing:  mid-point = black: Red=0 & Green=0 & Blue=0.

It's as if the red, green & blue are leaking, and can't be reduced below a
ceratain level. But then how is the black achieved.
 And What is the significance of the 5-group color-wells: which have the
problematic ET.Color numbers: 12, 13, 14  ?

NB this is NOT an ETHO problem; but ETHO can solve it.

== Chris Glur.

PS. don't set mail-list's Mail-send, to individuals.
gmail is lame-crap, and can't adjust parameters like good old ETHO.