[Oberon] Oberon on the Raspberry Pi

[eas lab]

Sorry! I've lost control of the email-threads, [being forced to use this
crap gmail - who WANT you to get lost, so they can push adverts in-yo-face].

> every source is included. I don't us a static linker written in c, but
> ALO.ARMBootlinker.Mod. ALO.Make.Tool shows how to compile the system
> and link inner core.

Thanks Peter,
 I appreciate the difficulty, especially when you don't have an rPi
to test with.  I want to re-post something that I've recently thought
hard about, which reduces the "search space":-
Debugging sequential processes [most computing jobs]:==============

After tearing out my guts, to go on-line with a 3G-dongle, I analysed why
it seemed so difficult.
It's because people who have done it don't know the underlying mechamism,
or that they just lazely say "doA, doB...."
The correct method, especially for a 'serial-event-process' is:
 CONFIRM1, CONFIRM2, ....
There's no point in tuning for the station, until it's confirmed that the
'radio-is-switched-on'. For 3G-dongle do:-------------------
1= confirm that usb-dongle is detected by system; lsusb; demesg | tail, ..etc.
2= confirm that method to switch dongle from CDROM to modem works:
   `eject <device>` usually suffices, else there's <mode-switch>
3= my dongle gives feedback via LEDs.
Only after the above stages have succeeded, need you go on to ppp ..etc.
Reading the <measured output from each stage, tells you where to connect
the pipe for the next stage>, and massively reduces the search-space.
===========
Here's my latest log extract:-.....
Here's my latest log extract:-...
Objects loaded.
Socket no.: 00000009
Connect: 00000000
Protocol not supported by server

Please execute 'xhost +' <-- xhost not installed.
Display loaded.
Input 01DBF118
Input loaded.
...

== Chris Glur.



On 4/21/14, Peter Matthias <PeterMatthias at web.de> wrote:
> Am 21.04.2014 01:34, schrieb eas lab:
>> LNO also has problems running under X.
>
> That's not the fault of X ;-)
> Current ALO implementation is much better.
>
>> Whereas the FrameBuffer version has less problems, and it's
>> spectacular to see the 'graphic screen' in console mode.
>
> It's spectacular to see the speed of the frambuffer version. However,
> todays ARMs are fast enough for Oberon on X11 and todays X86 are fast
> enough to emulate Oberon on ARM.
>
> Peter
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>