October 2015 - Oberon - mailman3.inf.ethz.ch

Astrobe for FPGA
by greim 13 Feb '16

13 Feb '16

Hallo Chris, > > Yes - editing, compiling and uploading are all done on the PC using the > Astrobe IDE. The Oberon source code files on the PC are just text files so > you can use any of your other Windows software development tools (editors, > difference listers, version control systems, grep searches) to maintain > them. The resulting modules (*.rsc files) are dynamically linked on the FPGA > exactly as they are in the full Project Oberon system. > > The core OS modules that I use - Kernel, FileDir, Files and Modules (the > dynamic loader), are identical to the Project Oberon distribution except for > one difference: I have implemented a Files.SetDate function that I call from > the Upload function so that files uploaded from the PC have the same date / > timestamp on the Oberon system. > > As for a 'business model' Astrobe for FPGA RISC5 is free - you'll just have > to register your name and email address to use it: > > http://www.astrobe.com/forum/viewtopic.php?f=13&t=476 > > The downside is that you will get half-a-dozen or so Astrobe-related emails > from me each year ;-) > thats ok, i guess i already got it, because afaik I have a license for ARM... > Support is limited to this mailing list and the Astrobe forum. Anything else > that would create work for me which I am not already doing for myself I > would have to charge for e.g. helping you to get it working on a board that > you have built or purchased for your own or commercial use. An exception > would be for individuals like Magnus (Saanlima) or Enso who were developing > a board specifically aimed at supporting Oberon. I am happy to try and help > them if possible - the only cost to them would be to send me a board to work > with. If Xilinx or Altera was the customer that might be a different story > :) > ok, thats a very fair business model > No Linux version of Astrobe for RISC5 is planned - it requires Windows 7, 8 > or 10. > > If you wanted a Linux version you would be able to use the target system as > long as you had a Linux tool to write the supplied core OS disk image to an > SD Card. You would also need: > > * A Linux text editor to create your Oberon programs > * To port the RISC5 Oberon compiler to Linux. > Gardens Point Component Pascal (GPCP) for JVM might be a good starting > point. It only took a couple of days to port the compiler using GPCP for > .NET > * A Linux terminal emulator that can run at 115200 baud to upload the object > files (*.rsc) to the target. ok, maybe i will make a try with WINE, but i have also Windows in a container on my Linux desktop, i must confess.... > > Sorry - I missed your last question in my previous reply. Yes you can use > the full featured FPGAOberon system as your developing/master system. You > just need a way of transferring the resulting .rsc files from the full > system to your target system. I'll supply a disk image for the full system > as well as the core OS to make sure that the module versions are compatible. > that sounds very elegant... One last question regarding this topic: The timing of the full FPGAOberon is strongly influenced by the CRT refresh rate. Is there any speed/clock-frequency increase with your slim system realized/possible? Best Regards Markus

2 2

Functional programming style for Oberon?
by eas lab 14 Jan '16

14 Jan '16

Some years ago when the OO-paradigm was at it's peek, ETHO was extended to handle procedure types, which could be passed as arguments. There's great advantages in avoiding temporary-fads, so I never exercised OOP. Now [using LEO] that it's less easy to access my old NativeOberon files, I failed to find the documentation, and example uses of the <passing PROCs as arguments>. Where should I look? Can Oberon procedure types facilitate the <functional/compositional> style of programming? Which is NOT a passing fad. *nix's <piping of functions/data-transformers> is staggeringly economical in user's effort, but has a terrible syntax. The benefit of removing the need to learn ad-hoc syntaxS is my motivation for syntax-directed-editors & menu-driven-usage: which ETHO already used successfully. An example of *nix's ability to easily get results by piping a sequence of existing/proven/well-tested functions together [but using understand-able syntax] is:-- CheckTheFileDataBaseForFilesNamed *roc*ointer* | ButSkipAllFiles *.pdf *.zip *.ps *.gz | AndListThoseContainingString "beron" The big advantage of this functioal/compositional style is the maintainablity. Which is the whole idea of NW's "MODUL"a and "COMPONENT" pascal. Some years ago, when my then ISP introduced Sender-must-ID for email, it was quite a job to modify the ETHO <emailer>. Now there's a new-fad which messes my TextToSpeech facility: instead of 'saying' "can't", it says "Sea Aye Enn Tea"; because many feature/fad-following clowns are replacing the one-byte single-quote [ASCII] by 3 bytes. Since the substantial processing-stages of fetching [unfortunately these days http-formatted] text, visually scanning it to wipe-out <bad sections> by an ETHO-like editor, and getting the TestToSpeech to a device, as a suitably-named file, needs only a few mouse-chords and typing the chosen name, you don't need to understand the details of each stage. So you can just plug-a-function-into-the-pipe-line to: <translate the 3-byte-quote-fad to ASCII(SingleQuote)>. Which just needs pasting from your library of examples, a 10 char line, and editing/modifying it; into the suitable pipe-line position. That's why I call it MickeyMouse programming. A most convincing argument, for me, for the functional style, is:-- Let's create a list of all even numbers up to 100, and another list omitting the first five of them. The program written in Java. final int LIMIT=50;int[] a = new int[LIMIT]; int[] b = new int[LIMIT - 5]; for (int i=0;i < LIMIT;i++) { a[i] = (i+1)*2; if (i >=5) b[i - 5] = a[i]; } The program written in ### let a = [2,4..100] let b = drop 5 a It is immediately clear that with ###, you can understand what's going on; whereas in Java, or any imperative language, you can barely tell what the code is supposed to do because you are overwhelmed with the low-level minutia. This effect increases as programs grow more complex. From this simplicity and abstraction flow most of ###'s advantages. ----------------------------- end of extract. -------------------- ### <- let's not get stuck on NAMES. Let's rather first understand the CONCEPTS. Of course, the above is an extreme example, but ETHO's already existing facilities could perhaps do: MapFunctionOverElements(DigitToText:PROC, DigitSequence: TextString):TextString; MapFunctionOverElements(TestForPrime:PROC, Ints1toN: IntegerList):IntegerList; There's nothing new about this. Extracting from McCarthy [designed lisp in 60s?]:- These three procedures clearly share a common underlying pattern. They are for the most part identical, differing only in the name of the procedure, the function/job of a used to compute the term to be added, and the function that provides the next value of a. We could generate each of the procedures by filling in slots in the same template: ------ snip lisp code --- The presence of such a common pattern is strong evidence that there is a useful abstraction waiting to be brought to the surface. Indeed, mathematicians long ago identified the abstraction of summation of a series and invented ``sigma notation,'' to express this concept. The power of sigma notation is that it allows mathematicians to deal with the concept of summation itself rather than only with particular sums -- for example, to formulate general results about sums that are independent of the particular series being summed ... What are unforeseen problems in using ETHO to do this too? == Chris Glur. PS. it's very problematic pasting the pre-written text into the web-browser for gmail [designed for F/B-twitter kiddies=modern] compare to the 90's N-O emailer. Can Linux:Aos handle gmail?

6 12

OberonStation
by Paul Reed 04 Nov '15

04 Nov '15

Dear Oberoners, I'd like to announce Victor Yurkovsky's OberonStation, an experimental custom FPGA board he has designed specifically to run the FPGA-based 32-bit RISC computer which is described in the 2013 edition of Project Oberon by Niklaus Wirth and Juerg Gutknecht. Porting the FPGA RISC system to the OberonStation involved adapting the RISC5Top.v and VID.v Verilog modules only slightly from the reference implementation which Prof. Wirth and I developed for the Digilent Spartan 3 FPGA board. I've also added a new MouseM.v module, now supporting Microsoft mice (for either board). The software and boot ROM are unchanged. In the meantime Prof. Wirth has also made portability improvements to the RS232 receiver, and the RISC5 integer multiply and divide, the floating point implementations, and the address width. See the links below for details. http://oberonstation.x10.mx/ http://projectoberon.com/ http://www.inf.ethz.ch/personal/wirth/ Cheers, Paul Reed

9 11

Re: [Oberon] Import hierarchies of display modules.
by Peter Easthope 03 Nov '15

03 Nov '15

References: <E1Zi9VH-0006gr-Gf(a)dalton.invalid> <CAA85NCi_8Bm=2tVrFsRoSKeHAdxUHzM_Ysaw9pwhs_BNFARnjQ(a)mail.gmail.com> <CAA85NCi19_yzvS3x=HHKn1aEw+5BOXdV_HNEsPYM5XUFnkkwNA(a)mail.gmail.com> >From peter at easthope.ca Sat Oct 3 01:12:39 2015 > Import diagrams such as these might help. http://easthope.ca/OberonDipsplays.html >From jan.de.kruyf at gmail.com Sun Oct 4 21:41:41 2015 > ... excellent idea. OK; have a look. http://www.ocp.inf.ethz.ch/wiki/Development/OberonStructure Notice that I failed to omit boundaries of empty cells in the table for Display3. >From jan.de.kruyf at gmail.com Mon Oct 5 18:12:51 2015 > A person could also use awk (a text filtering language) for that and do it > automagically. > > did you ever play with dotty? http://www.graphviz.org My primary objective is to convey the ideas simply and clearly. A pixelmap illustration can have more information and be visually better but the page might open slower. Or might open faster. Improvements certainly welcome. If I am straying too far in the Wiki, Felix or anyone, please let me know. Regards, ... Peter E. -- Telephone 1 360 639 0202 or +13606390202 or 12506293757. Bcc: peter at easthope.ca http://easthope.ca/Shop.html

2 2

bug in FileDir.Match
by Jan de Kruyf 02 Nov '15

02 Nov '15

Good morning all, I finally found the time to sort out the misbehaving Match routine: > To be clear: You get the right result with the code snipped I sent and repeat below? > mask:="*.Mod" > name:="ABCD.Mod" > name:="123"; > IF Match(mask, name) THEN ... You were quite right Peter, I did not. And when I did I saw. So now I fixed it, mainly since the same broken routine is used in FATFiles.Mod and in AOS Strings.Match. So once everybody approves, the fix should go there also. I have attached a test module for the match procedure as such, with Peters test hard coded. And I have attached a modified FileDir.Mod that you can compile and test in your own system. Please let me know. Then I will now pay attention to the trap problems I saw, or thought I saw. Cheers, j.

2 4

trap output problems
by Jan de Kruyf 01 Nov '15

01 Nov '15

Hallo Peter, > I suppose the best way would be to send me the source to reproduce the text corruption fault. You also can use ARM and MIPS targets via qemu to check the behaviour. Here is a barebones module to demonstrate the trap printout problem. There are 2 pointers, one initialized (S) and one uninitialized (T). You can compile and run it as is. it will trap and give 2 values to compare against in the kernel log. It looks to me that the problem is in the trap printing routine. cheers, j.

3 7

Re (2): Mice in Native Oberon.
by peter＠easthope.ca 29 Oct '15

29 Oct '15

From: =?UTF-8?B?SsO2cmc=?= <joerg.straube(a)iaeth.ch>, Wed, 28 Oct 2015 15:06:11 +0100 From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Jan de Kruyf, Mittwoch, 28. Oktober 2015 10:37 > In Linux my laptop also sums the pad and the mouse. So I guess it is > standard behaviour > > and when you want to select mouse only for instance, you switch the pad > off in the bios. Good, thanks, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 or +1 604 822 7107 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Mice in Native Oberon.
by peter＠easthope.ca 28 Oct '15

28 Oct '15

In Native Oberon, ==== MODULE Input; ... TYPE PollMouse* = PROCEDURE (VAR keys: SET; VAR dx, dy, dz: INTEGER): BOOLEAN; (** non-portable *) ... MousePoller = POINTER TO RECORD poll: PollMouse; next: MousePoller END; ... VAR ... mouse: MousePoller; ==== Good! mouse.next can point to a second mouse and etc. That allows a list of mice. Further on, ==== PROCEDURE Mouse*(VAR keys: SET; VAR x, y: INTEGER); ... REPEAT (* get all available mouse events, or until keys change *) p := mouse; rawkeys := {}; ok := FALSE; WHILE p # NIL DO (* poll all mice and sum keys and movements *) IF p.poll(mousekeys, dx, dy, dz) THEN (* Assimilate mouse button information and X,Y coordinate information. *) END; p := p.next END UNTIL ~ok OR (rawkeys # lastkeys); ==== Observation REPEAT .. UNTIL steps through the list of mice, assimilating information from each. When more than one mouse is present, the input from each is equivalent to another. Multiple mice simply allows redundancy. In the sources, I've seen nothing to add a second mouse to the list. Conclusion Input was built to allow multiple mice but the code to configure and use multiple mice wasn't developed. Correct? Erroneous? Comments? Thanks, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 or +1 604 822 7107 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

3 2

A2 on Raspberry Pi
by Treutwein Bernhard 20 Oct '15

20 Oct '15

Reading through Release.Tool in the A2 source directory, it appears to me that A2 is now also supported on the Raspberry Pi. Is there any additional information how to get it running? Does it use Raspbian (or anything else) s hardware abstraction layer or is it running natively? -- Bernhard

1 0

Intel's itty-bitty Curie CPU for wearables is coming to Arduino early next year
by Douglas G. Danforth 19 Oct '15

19 Oct '15

Folks, Intel's itty-bitty Curie CPU for wearables is coming to Arduino early next year <http://www.pcworld.com/article/2994276/components-processors/intels-tiny-cu…> -Doug Danforth

2 1