[Oberon] Oberon-1 or Oberon-2?
lab.eas at gmail.com
Thu Oct 16 12:11:31 CEST 2014
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?
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
Importantly: the 'Pie-sector' of Colors.Panel shows the continuous range:
==> 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.
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.
More information about the Oberon