March 2014 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Re (2): Project Oberon: New Edition
by eas lab 26 May '14

26 May '14

Some ideas on HCI: we techies overlook it's importance; which is demonstarted by stupid notation like "a better experience". What's that ? It needs to be analysed. There's a Swiss HCI specialist who AFAIK is/was associated with ETHO. Focus on the human psychology, not the computer hardware. Although we all differ, some basic evolved human attributes are: short-term memory limited to ca. 3 items; recognision is mot limited by memory. This automatically leads to the menu-concept, which TUI has. We all learned to read and are forced to exercise it in daily life, so menu-items are conveniently: recognisable test-strings. Lifting your arm to point to a screen, is only for short/baby tasks. Perhaps with mobile-devices you can rest your arm. Although the reflexive chording-at-the-mouse position can't be equaled, probably <verb> <noun>...<noun> notation can be efficient. Many tasks can use this. Like: verb:ReplaceAllUntilNextVerb To From1 ...FromN But can mobile devices conveniently/accurately select a text-stretch? ---------------- The other essential capability, where ETHO excels is multiple files simultaneously visible/accessible. Most non-trival tasks needs 4,5,6 files visible/accessible at once. == Chris Glur. On 12/22/13, peasthope(a)shaw.ca <peasthope(a)shaw.ca> wrote: > Claudio and everyone, > > From: Claudio Nieder <private(a)claudio.ch> > Date: Sun, 22 Dec 2013 02:40:43 +0100 >> ... unnecessary fragmentation. > > Yes, fragmentation is probably the biggest obstacle to efficient > use of computing. > >> Some people on this list care mostly about the TUI and are happy >> having that with any other kind of OS running beneath of it. >> Others might even hate the TUI because the mouse-interclicks >> cannot be translated to touch screens ... > > There is a very simple and effective way of integrating the familiar > Oberon TUI with the gestural touchscreen approach. The result, I > believe, is more powerful than any extant interface. > > I have a description of this interface and am working on a prototypical > implementation. To avoid pre-emption of the ideas by commercial > interests, details have not yet been published. > > Best Regards, ... Peter E. > > -- > 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 > Tel +1 360 639 0202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ > > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon >

5 5

FPGA Oberon some news and a reply to F.P.
by greim 30 Apr '14

30 Apr '14

Some news from my FPGA Oberon board: Yesterday i was also able to compile the Verilog code from the source to the Bit-File. That was a big progress for me. I really hope that several hundreds will follow up! Also guys who are more professional then i am. I thinks this Project Oberon, or i prefer FPGA Oberon is a real great and also NEW system! If we you are thinking about the success of Arduinio and Rasberry PI which are much less innovative, then i am not so pessimistic about the future of Oberon. Maybe the fathers of the project should communicate this to Xilinx or maybe Altera . I could imagine that a Oberondinio or a Garnetberry OB ;-) would be a realistic thing. As first small project and proof of concept, i personally like to realize a kind of oscilloscope. This requires: - in Verilog: the ADC converter handling and a ring buffer, with some trigger mechanism. - in Oberon: line graphic and a small user interface for showing the signals. > Still; compare the readabilty of the code of the rs232 driver written in > verilog with one written in vhdl > > verilog > http://www.inf.ethz.ch/personal/wirth/ProjectOberon/SourcesVerilog/RS232R.v > > VHDL > http://opencores.org/websvn,filedetails?repname=rs232_interface&path=%2Frs2… > > Greets and happy coding, > F.P. > > mmm, if VHDL or Verilog in principle is better readable i can't evaluate in details. Both languages are hard to understand, at least for me, and VHDL for me is still more abstract then Verilog. One general thing is, that the Verilog code as well as the Oberon code of ProjectOberon is "poor of comments" as everybody can see at your RS 232 examples. I know that Nicklaus Wirth says: "the code must explain itself", and also the book is explaining many things very well, but at some corners, some comments would be sometimes very helpful... Markus

17 45

MousePoller
by Peter Easthope 10 Apr '14

10 Apr '14

In Native Oberon, TYPE PollMouse* = PROCEDURE ... ... MousePoller = POINTER TO RECORD poll: PollMouse; next: MousePoller END; Native Oberon had only one mouse. One PollMouse procedure should suffice. But MousePoller makes a linked list of procedures. If someone can explain or offer an idea, it will help. Thanks, ... Peter E. -- Telephone 1 360 639 0202. Bcc: peter at easthope.ca "http://carnot.yi.org/ "

3 3

Bug? procedure variable in procedure call parameter
by Volkert Barr 07 Apr '14

07 Apr '14

Dear all, i have a "problem" with the evaluation of a "procedure variable" used as parameter in a procedure call. this case leads to a ABORT or TRAP in Line 1. Procedure variable is FunId. BEGIN (*1*) Texts.WriteRealFix(W, FunId(1.0), 5,3); ... END... this case with the dummy assigment to "Test" gives the correct output BEGIN Test := FunId(1.0); Texts.WriteRealFix(W, FunId(1.0), 5,3); ... END... The complete code can be found in the appended Module Bug or Feature?? I use the Oberon-Image (RISC.IMG) from Paul Reed´s "Project Oberon"-Website with the nice "Oberon RISC Emulator" from Peter De Wachter (thanks for it). BW, Volkert ---- MODULE Scratch; IMPORT Texts, Oberon; TYPE Function = PROCEDURE (x:REAL) : REAL; VAR W: Texts.Writer; FunId : Function; PROCEDURE RealId(x:REAL):REAL; BEGIN RETURN x END RealId; PROCEDURE DoIt*; VAR Test : REAL; BEGIN Test := FunId(1.0); Texts.WriteRealFix(W, FunId(1.0), 5,3); Texts.WriteRealFix(W, RealId(1.0), 5,3); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf) END DoIt; BEGIN Texts.OpenWriter(W); FunId := RealId; END Scratch.

5 15

Re: [Oberon] FPGA Oberon some news and a reply to F.P.
by Chris Burrows 01 Apr '14

01 Apr '14

> -----Original Message----- > From: Chris Burrows [mailto:chris@cfbsoftware.com] > Sent: Tuesday, 4 March 2014 10:43 PM > To: 'fp(a)vonck.nl'; 'ETH Oberon and related systems' > Subject: RE: [Oberon] FPGA Oberon some news and a reply to F.P. > > > -----Original Message----- > > From: Frans-Pieter Vonck [mailto:fp@vonck.nl] > > Sent: Tuesday, 4 March 2014 10:30 PM > > To: ETH Oberon and related systems > > Subject: Re: [Oberon] FPGA Oberon some news and a reply to F.P. > > > > For instance, the oberon compiler for the lpc2000 processors is no > > longer supported. > > > > That is absolutely NOT true. I made an announcement regarding support only > yesterday: > > http://www.astrobe.com/forum/viewtopic.php?f=3&t=422 > Furthermore, we have just announced that version 5.1 of Astrobe for LPC2000 has now been released: http://www.astrobe.com/forum/viewforum.php?f=3 Amongst the new features is full support for the latest 1.10.2013 / 10.3.2014 Revision of The Programming Language Oberon, Regards, Chris Burrows CFB Software http://www.astrobe.com

3 3

Project Oberon, 2013 Edition
by Paul Reed 01 Apr '14

01 Apr '14

Hi Oberoners, As some have already now noticed, Prof. Wirth and I have tidied up and added some new material to his home page, including a pre-release of a new version of the Project Oberon book. The system in the new edition runs on a computer implemented on a field-programmable gate array (FPGA), removing in particular the dependency on the defunct NS32032 processor in the original book. The version of the Oberon language used to implement the new system in its entirety is based on Oberon-07, separate material for which is also already available on Prof. Wirth's site http://www.inf.ethz.ch/personal/wirth/. The new Project Oberon documents should not be considered final and will continue to be updated substantially over the next few months. Best regards, Paul Reed

6 7

Software 'examining' its hardware?
by eas lab 31 Mar '14

31 Mar '14

Chris Burrows wrote:- >Being able to mix low-level operations with high-level code without >having to resort to inline assembler is what makes today's Oberon ideal >for programming embedded systems, Yes, it's another example of the economic leverage available by combining systems [like ETHO + *nix = LEO]. My initial impression of reading some of www.inf.ethz.ch/personal/wirth/ProjectOberon/ is that it's the basis of an ideal course for computer engineering students. And with low-level operations immediately available via the Hi-level of Oberon, users can easily look down into the operation of the hardware. It raises the level of understanding, similar to what the microscope did for medicine, when they were able to SEE pathogens, instead of just <this substance seems to fix that ailment>. Since it's difficult to access people who have both hardware & software knowledge, can someone here comment on this:----- >> Going to a remote, isolated location for a few weeks, may be a good >> reason to buy an e-reader. But since e-readers are said to actually be >> linux/android computers, a linux user would not want to be restricted >> to using the e-reader for reading text. > I want to speak to the indjunyear & not the sales-clerk! > I've installed linux on many of my devices of the years, netbooks > WRT54G, iPaq, Psion5, plus rooted snd installed custom firmware on > phones and tablets - but I have no compulsion to "get at" my kobo as a > linux device, it's for reading books, the e-ink screen is too slow to > refresh to be useful for much else ... > Ignoring the e-ink-response-rate, I don't believe the claims to be able to add functionality. Even assuming the device is *nix 'based': * all executable files would be read-only - for economy; so they couldn't be changed. * the 'supervisory-layer' would be omitted, because it's a 'device' and not a general-purpose-computer. It's instructive to look at how the E-reader would be built under PO2013. * only the modules needed - would be in ROM. * the Top/supervisor/main module would be limited to the E-readers functionality. So to modify/extend the device to a general-purpose-computer, you need to ADD: 1. your general purpose module 2. have some method to <direct the program counter to your module>. Both 1 & 2 require hardware hacking ! It can't be done with software only. OK, perhaps you'd put <Your binary executable> in RAM, but how do you <branch to it>? WDYS?

1 0

Re: [Oberon] RISC emulator
by Jan Verhoeven 28 Mar '14

28 Mar '14

Jörg wrote: > Hi > To take the variable "n" into account even for MIN(INTEGER) I would change > it to: > > IF ROR(x, 31) = 1 THEN i:=10; DEC(n); a:="8463847412" Now, ROR sounds nice to assembly language programmers but many HLL people will be on the wrong leg, whereas Oberon does have a native command to tackle it, which is fully understandable by all. I would rewrite to IF 31 in x THEN bla; bla; bla with the proper type conversion for 'x'. -- Groetjes Jan Verhoeven

7 7

RISC emulator
by Peter De Wachter 27 Mar '14

27 Mar '14

I've made an emulator for the Oberon RISC machine. It can boot Oberon and everything seems to work, but it hasn't received much testing yet. It's available at: https://github.com/pdewacht/oberon-risc-emu Screenshot: http://i.imgur.com/YJgE0fp.png Have fun!

12 32

MT versus MTX.
by Peter Easthope 26 Mar '14

26 Mar '14

Apologies to anyone who finds these questions about obscure topics annoying. Better to avoid a predicament than to grapple at recovery. Native Oberon, Input.Mod also has "PROCEDURE Configure*(config, value: ARRAY OF CHAR); (** non-portable *) ... IF config = "MT" THEN (* mouse type *) SetMouseType(value); DetectMouse() ELSIF config = "MTX" THEN (* mouse type explicit *) SetMouseType(value) ELSIF ...". Any ideas about the distinction between "mouse type" and "mouse type explicit". Thanks, ... Peter E. -- Telephone 1 360 639 0202. Bcc: peter at easthope.ca "http://carnot.yi.org/ "

4 5