April 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

Proof of Concept, ARM Linux Oberon
by Peter Matthias 14 May '14

14 May '14

Hi all, I put the current state of ARM Linux Oberon public. Only the modules needed for development are included. More information here: http://matthias.dnsdynamic.com/oberon/doku.php?id=alo (it's my Desktop, so it might have downtimes) Regards, Peter

2 9

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

Re: [Oberon] RISC5
by eas lab 28 Apr '14

28 Apr '14

Thanks for the pointers. Today I tried to trace the M.P route of how eg. ET.* gets to the VGA-port. [Like you CAN trace how http* arrives via a serial-port-modem ...etc.] For ETH Oberon (2.4.3) for Linux x86 and V4/oberon-1.7.02/Source and my source1, 2, 3.arc which I guess comes from Native; in all cases the path is concealed at: IMPORT SYSTEM. Some of us resent that. Oberon may have had a better following if it had been open. OTOH perhaps that was not possible? == Chris Glur. On 4/17/14, Jörg <joerg.straube(a)iaeth.ch> wrote: > Chris > > 1) The RISCv5 machine has a memory of 1 MByte = 000000H.. 0FFFFFH. > This memory is used to hold your code and store your variables. > A dedicated region at the high end of this memory (namely from > 0E7F00H .. 0FFF00H) is called "framebuffer"; this memory region > is used to store all pixels that are displayed on the screen. > > 2) The module "Display.Mod" provides all low layer routines to > store pixels into this memory region. E.g. the procedure > Display.Dot(col, x, y, mode: INTEGER) "draws" a dot at location > (x/y). But it does not actually draw the point but "just" stores > a bit in this dedicated "framebuffer" memory. > > 3) In parallel, the video driver "VID" (written in Verilog) permanently > reads this special framebuffer memory and copies all bits over and > over again to the VGA monitor. The whole framebuffer memory > (96 kByte) is copied 70 times per second to the monitor. > > Hope this helps. > > br > Jörg > > -----Original Message----- > From: Paul Thomas Melville [mailto:ptmelville@gmail.com] > Sent: Donnerstag, 17. April 2014 13:46 > To: ETH Oberon and related systems > Subject: Re: [Oberon] RISC5 > > On Thu, Apr 17, 2014 at 10:58 AM, eas lab <lab.eas(a)gmail.com> wrote: > >> The hidden/mysterious part for me is the display/textFrames. >> Does V5 drive standard VGA? >> Where's the code showing; >> VGA -> FrameBuffer -> ETHOviewer. > > You can find information in section 9.1, 4.5 and 17.2.4 of Project Oberon. > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon >

5 12

Project Oberon 2013 on GitHub?
by volkert＠nivoba.de 27 Apr '14

27 Apr '14

Dear all, as i understand the "Project Oberon 2013" Book and Sources are maintained / updated by NW itself. But i ask myself, if it makes more sense to put the full Project on GitHub and hope that some volunteers help cleaning things up, offering patches, etc ... I would help ... The nice "Oberon RISC Emulator" is a good example here ... BW, Volkert

14 48

Pictures of Ceres Workstation?
by volkert＠nivoba.de 26 Apr '14

26 Apr '14

I am looking for pictures or videos of the Ceres Workstations. The only pics i found are - http://www.ethistory.ethz.ch/rueckblicke/departemente/dinfk/forschung/weite… - http://www.computerhistory.org/collections/catalog/X2321.2002A - http://www.computerhistory.org/collections/catalog/102674736 The only video i found is - http://www.youtube.com/watch?v=HoZuzE7Lq5E BW, Volkert

4 6

Re: [Oberon] Oberon on the Raspberry Pi
by Chris Burrows 26 Apr '14

26 Apr '14

> -----Original Message----- > From: eas lab [mailto:lab.eas@gmail.com] > Sent: Saturday, 5 April 2014 5:58 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Re (2): suggestions for documentation. > > When will we have ETHO running on ARM, eg. rPi? > My question is not 'when' but 'why bother'? Also do you mean the Oberon OS hosted on Linux on the Raspberry Pi or the Oberon OS running standalone on the rPi hardware? Here are some thought-provoking views on the Raspberry Pi: http://www.theregister.co.uk/2013/10/28/opinion_is_raspberry_pi_really_the_s aviour_of_uk_it/ If you believe that porting Oberon to the rPi is something worth doing then you should start by trying to do it yourself. All the facilities are available (assuming you already have an rPi?) I recommend that you approach it step by step to test the level of interest rather than jumping in at the deep end. Something along the lines of: 1. Investigate if Peter De Wachter's RIDC Oberon emulator would run on the rPi. (e.g. will the SDL libraries work OK?) 2. Implement the emulator on the rPi. 3. Release it and measure if the level of feedback / demand for it is significant. 4. Investigate what would be gained by replacing the emulator with a native ARM version. If you don't believe you can implement the last part yourself you might then have a better chance of convincing others like myself that it is worth the effort of porting it to the rPi, Regards, Chris -- Chris Burrows CFB Software Astrobe: Oberon development system for ARM7 and Cortex-M3 http://www.astrobe.com

8 29

Re: [Oberon] ARM Oberon Code Generation (was PO.Computer documentation)
by Chris Burrows 26 Apr '14

26 Apr '14

> -----Original Message----- > From: eas lab [mailto:lab.eas@gmail.com] > Sent: Saturday, 26 April 2014 12:41 PM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Re: [Oberon] ARM Oberon Code (was: PO.Computer documentation) > ... > can you confirm IF the following bytes match the source: > ... > Out.Real(a*b, 12); Out.Ln; > ... > eb 00 01 04 BL 468H > eb 00 01 08 BL 47cH > > ?BL sounds like branchOnLess; but HelloWorld has no decisions? > BL is 'Branch with Link' (BLT is 'Branch Less Than'). BL is the ARM instruction used to call a procedure. There are two BL instructions for the above snippet - one for each call to an 'Out' procedure. A list of these instructions is in the 'ARM and Thumb-2 Instruction Set Quick Reference Card' which you can download from: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.qrc0001m/index.… Detailed explanations of the ARM code sequences that are generated by Oberon-07 statements are included in Niklaus Wirth's 2007 paper: 'An Oberon Compiler for the ARM Processor'. You can download a copy of that document from: http://www.inf.ethz.ch/personal/wirth/Oberon/index.html NOTE: The document describes Wirth's ARM Oberon-07 compiler that was the immediate predecessor to his FPGA RISC compiler used in Project Oberon. There will be some differences from the instruction sequences generated by the ARM Oberon-2 compiler (a port of Regis Crelier's OP2 compiler?) that you are running on the Raspberry Pi. Regards, Chris Burrows CFB Software http://www.astrobe.com

2 1

ThisCommand, semi missing
by Jan Verhoeven 26 Apr '14

26 Apr '14

While going through Modules.Mod.txt I encountered the procedure ThisCommand. PROCEDURE ThisCommand* <param list> VAR <declaration> BEGIN res := 5; w := 0; IF mod # NIL THEN adr := mod.cmd; SYSTEM.GET (adr, ch); WHILE (ch # 0X) & (res # 0) DO k := 0; (* read command name *) REPEAT s [k] := ch; INC (k); INC (adr); SYSTEM.GET (adr, ch) UNTIL ch = 0X; s[k] := 0X; REPEAT INC (adr) UNTIL adr MOD 4 = 0; SYSTEM.GET (adr, k); INC (adr, 4); IF s = name THEN res := 0; w := mod.code + k ELSE SYSTEM.GET (adr, ch) END END END RETURN SYSTEM.VAL (Command, w) END ThisCommand; I would have expected a semicolon before "RETURN SYSTEM.VAL (Command, w)" Is this a bug, or a feature? -- Groetjes Jan Verhoeven

7 10

Re: [Oberon] PO.Computer documentation (was: Compiler Modules Empty?)
by Chris Burrows 26 Apr '14

26 Apr '14

> -----Original Message----- > From: eas lab [mailto:lab.eas@gmail.com] > Sent: Wednesday, 23 April 2014 10:56 PM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Compiler Modules Empty? > > => PO.System.pdf <- Ends at 9.5 > => PO.Aplications.pdf ends at pg 86. There should be no appendices listed in the table of contents. It sounds as though you have an obsolete version of PO.System.pdf and you don't have PO.Computer.pdf. Try downloading the documentation again. Chapters 16 'Implementation of the RISC processor', and Chapter 17 'The processor's environment' are included in the separate file: PO.Computer.pdf. > > PS. Nobody ever mentioned the ETHO x86 <dis-assembler>, whose output is quite > fascinating. The equivalent is available for ProjectOberon RISC5: ORTool.DecObj* (*decode object file*) > > IMO writing machineCode in Oberon is as wrong as writing music scores in > natural-language. Huh? I wasn't aware anybody was writing machine code in Oberon. The compiler generates machine code not the programmer. Regards, Chris Burrows CFB Software http://www.cfbsoftware.com

2 1