February 2016 - Oberon - mailman3.inf.ethz.ch

FPGA-related Project Oberon Customizations
by jwr＠robrts.net 24 Feb '16

24 Feb '16

What FPGA-related Project Oberon customizations are people considering or implementing? At http://oberonstation.x10.mx/smf/index.php?topic=26.0 I posted some questions about how the OberonStation is being used, and what projects and ideas others are pondering. My questions can easily be expanded beyond the OberonStation, to any and all of the Project Oberon 2013 implementations. Within Chris Burrows' response, he indicated "The opportunities for customising the FPGA hardware are what excites me about RISC5 Oberon." That is a particularly interesting observation, and I wonder what types of customizations others are considering or are already actively implementing? One possibility includes enhancement of the RISC5 CPU to include particular special features. [Given that it's supposed to be a REDUCED I.S.C,, which small enhancements would still be desirable?] Other possibilities might involve modification of the display to implement color graphics, or to use some of the I/O pins to implement a different network communication interface. I'm interested in parallel programming, so perhaps some kind of co-processor or multi-core RISC instantiation (perhaps requiring movement toward AOS/A2 concepts) is of interest. What particular types of "hardware" modification within the FPGA [i.e. implemented primarily via changes to the Verilog code] do you think are of interest? -- John Roberts

10 33

Fwd: How to run a module.
by Srinivas Nayak 24 Feb '16

24 Feb '16

Dear All, Anybody has experience with the below problem? Kindly help. With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/ -------- Forwarded Message -------- Subject: How to run a module. Date: Tue, 23 Feb 2016 22:01:49 +0530 From: Srinivas Nayak <sinu.nayak2001(a)gmail.com> To: norayr(a)arnet.am Dear Norayr, I compiled and installed Vishop Oberon compiler 1.1 on my linux. Below is my Hello.Mod file collected from net. I compiled the file using voc -m When I tried to run the module using ./Hello I see nothing. What is that I missed? ~# cat Hello.Mod MODULE Hello; IMPORT Oberon, Texts; VAR W: Texts.Writer; PROCEDURE World*; BEGIN Texts.WriteString(W, "Hello World!"); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf); END World; BEGIN Texts.OpenWriter(W); END Hello. With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

3 2

Re: [Oberon] Vishap Oberon Compiler for BSD/linux and other
by D E. Evans 23 Feb '16

23 Feb '16

I wrote the RPM spec file for it. voc is a fork of Ofront by an ETH programmer. It seems well done, and incorporates several library kits from defunct Oberon compilers.

1 0

WinOberon on GitHub vs. WinOberon at ETHZ
by Alexander Ilin 22 Feb '16

22 Feb '16

Hello, list! Bernhard Treutwein asked me a question about my WinOberon repository on GitHub, and he agreed to have my reply posted in the list in case someone has the same question. Below is his email and my reply. > Dear Alexander, > I stumbled once again over your WinOberon repository at GitHub. > Just a curious question: There are quite some differences between > the version at GitHub and the version available in Zurich > (ftp://ftp.ethoberon.ethz.ch/ETHOberon/Win95NT/PlugIn/). > Some files from Zurich are slightly newer (18.12.2010 > vs. 26.11.2010) many differ just in some small number of bytes. > What was the reason for Emil Zeller to provide you yet another > version. > Is the version from Zurich in some way dysfuntional? > regards > -- > Bernhard The short answer is: I guess Emil's changes were incorporated back into ETH at some point. Now, for the long answer. I have compared several WinOberon distributions, and here is my summary. Things I have compared ("tagged as" refer to my GitHub repository tags at https://github.com/AlexIljin/WinOberon) - [ tagged as v2.5 ] WinOberon v2.5, which back in the day consisted of WinOberon.zip and WinOberonFix.zip. In this distribution the Src/Win32.Kernel.Mod contains version string "Win32 2.5 (19.12.2004)"; - [ tagged as v2.6exp ] WinOberon Experimental v2.6, which I received from Emil Zeller on or about 26.11.2010; - the latest WinOberon.zip contents today (22.02.2016) available from ETH FTP, dated 12.05.2011. In this archive the Src/Win32.Kernel.Mod contains version string "Win32 2.5 (18.12.2010)". Since versioning seems to be a bit of a mess, I'll refer to these archives not by numbers or dates, but as Old, EZ and Last respectively. I presume that versions EZ and Last are based on Old, which predates both of them. The question is in what relation EZ is to Last. More specifically, is Last a strict superset of EZ. To answer that question, I have analyzed the textual differences between the two versions, primarily comparing all of the *.Link, *.Mod, *.Text and *.Tool files, presuming that *.Obj, *.Exe, *.Dll, *.Oaf, *.Arc and *.Def files are automatically derived from the corresponding texts and are not introducing independent changes. Here's the summary of the changes introduced in Last compared to EZ: - Module V24Log: GetPar procedure updated, added GetMC, SetMC and ClearMC; - in Src/Win32.Kernel.Mod version changed from "Win32 2.5 (7.2.2009)" to "Win32 2.5 (18.12.2010)"; - in Src/Win32.Threads.Mod CheckStacks procedure updated; - Src/RXA.Mod file removed; - Src/Win32.OLEFrames.Mod file removed; - Docu/HelloCon.Link file removed; - Src/Win32.DLL.Oberon.Link file removed; - Src/Win32.Oberon.Link file removed; - Src/Win32.Small.Oberon.Link file removed. All of the removed files were previously introduced to Old in the WinOberonFix.zip archive, and were present in EZ, but for some reason didn't make it to Last. Changes in modules V24Log and Win32.Threads don't undo, but build up on EZ's version. This leads me to believe that, apart from the missing files, Last is a strict superset of EZ. I have imported the current ETH version of WinOberon (ftp://ftp.ethoberon.ethz.ch/ETHOberon/Win95NT/PlugIn/WinOberon.zip) into my GitHub repository do eliminate the discrepancy, except I decided not to delete the removed files. I also committed the scripts I used with Git to perform textual comparisons of the Oberon sources. ---=====--- Александр

1 0

Vishap Oberon Compiler for BSD/linux and other
by Lars 22 Feb '16

22 Feb '16

Hi, has anyone used the vishap oberon compiler? http://oberon.vishap.am/ Sources: https://github.com/norayr/voc "ⱱishap Oberon Compiler (voc) is a free (GPLv3) professional oberon-2 compiler." Sounds good, except for the fact that it is GPL and not BSD/MIT licensed. But we can deal with that.. "Platforms: voc produces x86_64, x86, ppc, armv{4-7} binaries and works on those platforms. " Sounds good. "Operating Systems: Currently GNU/Linux, Mac OS X, FreeBSD and OpenBSD sources (with bootstrap binaries) are published." This is great because OpenBSD is a system I like and rarely do you see odd Linux stuff get ported to OpenBSD. Freepascal took a long time, if at all, to get ported to BSD. Some one was working on it but it was very late to even get started on the porting process. "Ports to Solaris, AIX will be made and published in case there is an interest from community. voc should work on MS Windows/ReactOS via Cygwin/gcc, however we did not test it on Windows compatible machine." This is also interesting. To clarify, is this oberon mailing list to discuss all oberon related material, or just the Oberon operating system itself? Thanks! Also the Vishap compiler mentions "aliens" which is funny, considering the alien wirth conspiracy theory discussed in another thread "is Wirth an alien".. Quote: "Vishaps are known in tales, fiction. This page refers to some technologies as computer science fiction. Among them to Oberon. This brings another meaning, Oberon is like aliens, ghosts. And Vishaps." http://oberon.vishap.am/

1 0

Re: [Oberon] Pepino LX9, USB, and other hardware running OBERON
by Bill Buzzell 21 Feb '16

21 Feb '16

Please forgive me for speaking way to vaguely on this important subject. I went into bit of a rant and was speaking in a very generalized way. First, I blatantly suggested that USB should be totally avoided. I should have been more specific and said 'it should be excluded from everything except RS232/UART access'. This is how we have it now via the FTDI chip. In fact, Magnus seems to know his stuff with these chips and has quite a solid foundation going in this department, code wise. I vividly remember when he did an upgrade to this code and I saw the uploads speeds double. IIRC he duplexed the UARTS, was it? The difference was quite impressive. So what we have is a perfect setup now for USB: interfaced via RS232 and no further. That is spot on with the simplicity of Oberon, it appears. Of coarse, if you need lot's of throughput, like Wojetek does, this is a major issue. Question: why not simply use the two UARTS on the FT2xx chip on the Pipistrello/Pepino? Currently this chip is only used for loading the flash memory for the boot loader. Wojtek, why not utilize this chip's UART's in your design at 'run time'. Add some UART's to the Verilog design, jumper the correct pins from the FTDI chip and bam, ProjectOberon now has USB. Will two high speed UARTS provide enough throughput? Am I missing something here? This is simply suggested as a potential workaround/variant on the side, not suggesting this should be standard or in the 'official' distribution, of coarse. Also, concerning the ESP8266, it is quite promising but there are some things to consider. It is a proprietary chip. This means that someone must convince the manufacturer to be smart and fund/back the development of an Oberon target compiler for the ESP8266. Short of that, you would have to design and manufacture your own boards, plus you would have to buy a license to the Soc design from Cadence. And lastly, my statements on the $5 computer were very 'generic'. I just threw the ESP8266 out as an example. It is clearly not the best candidate for this. But my point was is that whatever they are building these $5 toys with simply needs someone to build a small Oberon based OS equivalent for them with the knowledge gained from ProjectOberon. I believe they are mostly ARM M0's, aren't they? Astrobe has proven that Oberon is an excellent match for the ARM 3, 4 and 5 already. Regards, Bill "Bill, I also am in favour of stripping away the USB - it really only makes sense when you want to communicate with a PC and power the board with a fairly stable 5V supply. FTDI have produced USB to serial interface devices for about 10 years - and this is very convenient for connecting low resource microcontrollers that perhaps only have a (TTL) UART for serial comms. You can now get a USB to serial VCP IC that runs at 3Mbaud and costs less than 50 cents. Regarding implementation on an ESP8266: Whilst the current ESP8266 is a capable chip (80-160MHz 32 bit) with only 20% of it's MIPS taken up with the WiFi stack, it might not have sufficient RAM available on chip (<36Kbytes) to support a full Oberon application. This begs the question about an "Oberon Lite" implementation - which I guess is what Chris Burrows has implemented for various ARM and FPGA platforms. There's a new ESP device, the ESP32, currently in beta testing which has about 400Kbytes of RAM https://harizanov.com/2015/12/esp32/ This could make a very attractive platform for an IOT system or pocket WiFi workstation. It is only the mass-market applications that will bring Oberon to the forefront - and the idea of a complete lightweight OS that resides in under 1Mbyte - makes it attractive for IoT devices that really do not need to carry around 20 million lines of source-code baggage. However to develop these applications, we need Oberon platforms - and NW, Paul Reed (& co) Chris B and Magnus are doing their best to furnish us with usable hardware. Ken"

5 6

Re: [Oberon] RISC5 implementation issues.
by skulski＠pas.rochester.edu 21 Feb '16

21 Feb '16

Magnus wrote: > OK, so I decided to try to implement the clocking as Walter suggested Ou of curiosity: Chapter 10 of the book "FPGA prototyping.." by Pong. P. Chu is devoted to SRAM interfacing. He is using the same Spartan-3 board that Paul Reed used. All the timing issues are thoroughly analyzed. Three different designs are presented and discussed. The book has two versions: VHDL or Verilog (two separate books). So I am curious why this discussion is not referencing the textbook but rather it is starting from scratch? Wojtek

2 1

Stripping Looks
by R. P. de Jong 20 Feb '16

20 Feb '16

Hi All, Developing with Oberon in a mixed environment (switching between Oberon, and Mac/PC), i often use a tool to strip the looks-information from .Mod files e.g. to allow easier handling by version control, and to make files ready for distribution. Though most of my personal tools are too quick (and too dirty) for sharing i put a bit more work into the "Convert" command, and made it to accept a wildcard file pattern as argument. The program (for RISC Oberon) is on http://www.reactive-instruments.eu/pages/striplooks.html in case you are interested in such a design. (and don't have already something similar) Regards Roel P. de Jong

1 0

Re: [Oberon] Inexpensive Hardware: Cost vs Objectives
by skulski＠pas.rochester.edu 20 Feb '16

20 Feb '16

All; Let me chime in from the perspective of a product developer. Yes, we develop products that we hope to sell (see www.FemtoDAQ.com) It so happens that our product is built around BeagleBone Black (BBB). BBB is both an inexpensive component (though it costs more than $5) and it is also a very capable development system. BBB is two things in one, which is a bit of a miracle. It is a new situation, which was started by the RPi I think. Before RPi the development system was usually different from the final product. The development system would be either an emulator, or a cross compiler, or perhaps a board with extra features that the final product would not need (such as a JTAG connector). The development system would cost more, it would be physically larger, or it would run on a workstation if it was a cross compiler. The final product could cost a few dollars, while the development system would cost thousands. A case in point is the Xilinx ISE or Vivado, whose full license costs a few thousand $$. And we are not surprised that it does, even though it consists entirely of software. So why do we expect that a $5 machine will serve both roles? Why are we unhappy that the Oberon Station, which is clearly a development system, is not as cheap as the final product would have been? (Notwithstanding the fact that I am barely aware of any final products built with Oberon.) Low cost is *not* the usual requirement for a development system. We should not blame its creator(s) that they added a few extras which cost a little bit. I would say that ~$100 for a fairly capable development system is a very good deal. Concerning those very low cost machines, they are: (a) Quite recent. I am not sure how well they can be used for development. Maybe they can. But I would expect inconveniences because I am not sure if useful diagnostics were included at this price. (b) They are made in tens of thousands or more items. There is an economy of scale. (c) There is clearly a price war going on among major manufacturers. The RPi Foundations is trying to keep its dominant market share, which others are attacking. I would not judge this situation based entirely on technical merits. The guys are trying to win over the competition. The most important metrics seems to be the number of $$. I suspect it is an exceptional situation which will go back to normal once the market settles. I would not put lots of effort into any cheap board, because IMHO they will be soon replaced with even cheaper but different ones. The particular "pi" will go away before we even learn what was inside. In this situation one should rather stay on top of an operating system such as Linux, while avoiding reliance on a particular "pi" feature. These will be soon gone. Finally, it is a bit unfair to discount a magnificent effort by a very small team (Paul, NW, Magnus, Chris...) who are not motivated by money. The Oberon boards were meant to be development systems. They are great and they are very cheap in their category. What is missing IMHO is a more clear vision of "what can be developed with those development systems". Here I can say that the said team is composed of professional developers of development tools (languages, compilers, etc). So they developed what they know: the development tools. The *product developers* are missing in this community. As a consequence, there are no products. To put it succinctly: the Oberon saw is very sharp thanks to the above team. But where is the wood which this saw could possibly cut? Well, there is not much of it because the core team is mostly interested in sharpening the saw. Nothing wrong with this, but we should be aware of the situation. OK, I wrote another very long post. I hope it made some sense. W.

5 6

RISC5 implementation issues.
by jwr＠robrts.net 20 Feb '16

20 Feb '16

Regarding continuing the discussion of FPGA and RISC5 implementation issues by private email vs on this list vs elsewhere, I for one would like to have the discussion continue in a somewhat public forum, so that those of us interested in learning more about the Project Oberon FPGA implementation and related hardware aspects, as well as more general FPGA implementation concerns, can follow along and learn. The insights from Magnus Karlsson and Paul Reed concerning details of the Project Oberon 2013 implementation are very enlightening, and the FPGA-related "best practices" communicated so far from Walter Gallegos and Wojtek Skulski are likewise enlightening and very valuable to know. I want to read and learn more information in both areas!! And other related areas also!! From my perspective, this Oberon List is an appropriate forum. But if most participants prefer to keep this list focused on Oberon SOFTWARE, and encourage the HARDWARE-related discussions to take place elsewhere, that's fine too. Is it easy to set up a parallel hardware list? [eg oberon-hw(a)lists.inf.ethz.ch ??] What about using a portion of the OCP Forum for hardware discussions? I do not know what forum is preferred, but I do know that I would like to continue to follow along. My recommendation would be to continue on right here. Thank you!! -- John Roberts

4 3