July 2013 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] WITH removal in Oberon-07
by Paul Reed 13 Mar '14

13 Mar '14

> Date: Thu, 21 Feb 2013 22:52:05 +0100 > From: "Frans-Pieter Vonck" <fp(a)vonck.nl> > Subject: Re: [Oberon] WITH removal in Oberon-07 Hi Frans-Pieter, > i watched your presentation at MEDIA OberonDay2011. > Am I right that you made an ARM emulator first. No. The virtual machine is RISC, as in Prof. Wirth's Compiler Construction book (published in English in 1996 and updated on his home page http://www.inf.ethz.ch/personal/wirth/) > And did you use this emulator to ran Oberon System07 on top of it? It's not called System07, but it's basically the original system in the Project Oberon book, modified to compile under Oberon-07, run inside a RISC virtual machine executing on a bare-metal PC. > You showed a Spartan FPGA. I scanned through the Verilog ARM code. But > that seems a to big leap to me. I don't know what Verilog code you are referring to here. The Spartan-3 board only has 500K gates and 1MB of external static RAM, so it's much smaller and simpler than a typical ARM system. But ideal for Oberon. > Do you think it is possible to run [The Oberon System, compiled in Oberon-07] on an of the shelf > board with a Cortex M3 processor? I don't see why not, but most small ARM boards don't have a video framebuffer. The Raspberry Pi does, but it's a complicated board, as I've said before. The Oberon inner core (Kernel, FileDir, Files, Modules) and even the text system do not actually require a framebuffer display, so you could build a hybrid system. Using a simple FPGA board allows us to avoid the vast and irrelevant complexity inherent with most ARM System-on-Chip (SoC) systems; but since field-programmable gate arrays are so flexible, they will never be as cheap or as fast as a dedicated ARM. That's life. :) HTH Paul

4 5

Can ETHO be ported to ARM?
by eas lab 13 Jan '14

13 Jan '14

No, not the <language>, but the unique interface of S3/V4. What matters is the human-interface. That's what determines your productivety [maximum gain for minimum pain]. Not needing to switch between awkward F-keys and the screen, and having easy access to multiple text-files together, and each text-view having <what the bottle does, written on the bottle, instead of in the filing cabinet>. Porting ETHO to linux [both S3 & V4] was a killer app:. you get the Inet capability of *nix together with the superior human-interface of ETHO, plus you can view *pdf, LaTex..etc. on the same screen. For tricky problems, needing simultaneous views of: email/s, USEnet/s, your test-logs EHO is unbeaten, especially with the text colouring facilities, which help extract the meaning of difficult explanations. Because opeing/closing a new ETHO-for-linux takes a second, it's viable to have several copies running in the various dirs, which are handling current problems. Real life doesn't allow fixing one problem at a time. Can those of us who want to escape the WinTel monopoly, hope to use ARM based CPUs with an ETHO-like interface, by a porting of the existing/proven code? == Chris Glur. PS. LNO's inability to easily navigate the dir-tree, limits its utility.

3 7

Re: [Oberon] Background Processing for "Instrument" control using Native Oberon / Bluebottle
by Treutwein Bernhard 23 Jul '13

23 Jul '13

Hi Alexander, I guess it is possible, just take a look at Michael McGaws presentation at Oberon Day 2011: http://www.oberonday2011.ethz.ch/talks/rocketengine.pdf and/or Marcel Rohr and Josef Sedláček at Oberon Day 2007: http://www.oberon-industry.ethz.ch/events/oberonday/oberonday2007/presentat… (the latter one is pdf, but the extension is not present. Rename it after download). -- Bernhard

2 1

Background Processing for "Instrument" control using Native Oberon / Bluebottle
by Alexander Hofmann 22 Jul '13

22 Jul '13

Hi, there. Although I've known the Oberon System (and Language) and it's Siblings for quite some time now (should be 18 Years by now), my knowledge of the System is still very limited. At the moment, I'm trying to find an adequate system to control a bunch of old 16Bit ISA D/A and A/D cards (e.g. http://accesio.com/go.cgi?p=../isa/da16_16.html) I'm not using these in any production or "real" lab environment, just for some experiments at home. Until now I'm controlling the cards using LabView. The problem is, they don't have any buffer memory - any sort of "waveform" requires constant updates on the part of the software. Of course, the cards are not meant to be used for such a purpose - but I'm curious if it's possible. So, here comes the question to the Oberon specialists: is it possible to use Native Oberon (my favorite in this case) or Bluebottle to create some "real time"-ish control software for these cards? I used Oberon a view years ago to control some stepper motors, but in these days I modified the Oberon-Loop to accomplish background-processing, which of course lead to glitches and movement errors of the motors when interrupts were generated (Keyboard, Mouse etc.). So this is not the right way to do this. Bluebottle, with it's active objects seems more suited, but as far as I know, the Bluebottle system will threat all active objects equal (no priority classes?), is this correct? If the sample given with the D/A-Cards is to specific, take my question as "Is it possible to do some kind of multi-task real-time processing with Oberon and/or Bluebottle?" The reason why I'm not trying to do this with any other/existing realtime OS is, that I really like the "Spirit of simplicity" in the system, the Oberon language is clean and understandable, and the Gadget-Based GUI of the Oberon-System can be easily reprogrammed without the need to change code, the ideal base for any lab environment! Using LabView's Realtime Module is also very expensive - nothing to experiment with at home, and setting up e.g. WinCe or QNX is difficult, and these to are not OpenSource. Thanks in Advance, Alexander Hofmann

2 1

Experiment with FatFS usage.
by peasthope＠shaw.ca 17 Jul '13

17 Jul '13

This is a brief report of one of my experiments in case anyone is interesed. I have 1248 files in an AosFS partition in a CF card. A partition in another CF card was formatted with this command in Debian Linux. mkfs.vfat -F 32 -n Work -v /dev/sdd2 Although the parameter requested FAT32, mkdosfs produced a FAT16 filesystem. My 1248 files were sent to the Linux system and there copied to the FAT partition on the CF card. This command was put in SYS:Oberon.Text to have the working partition mounted automatically and the system was rebooted with the FatFS card installed. FileSystem.Mount MY FatFS IDE1#2 ~ Then two Texts were opened and an attempt was made to copy three lines from one Text to the other. A photo of the resulting screen is visible here. http://carnot.yi.org/FatFSscreenshot.jpg The picture illustrates that when MR+MM was applied to copy the three lines, "2013-07-17 Wednesday; pe.ebay.nc 5:42-" the target text received these four lines. "2013-07-17 Wednesday; pe.ebay.nc 5:42- 2013-07-17 Wednesday;" The first line was duplicated after the last and the word "Wednesday" was cast in fresh "look". No doubt the explanation is simple enough but for now it eludes me. As always, ideas are welcome. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

1 0