June 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

Oberon on Pi: spivey's obc compiles and works
by Frans-Pieter Vonck 22 Jun '13

22 Jun '13

spivey's obc compiler compiles on Raspberry Pi. I disabled the debugger ./configure --disable-debugger More to come... Greets, F.P.

1 0

Oberon language on raspberry pi
by Frans-Pieter Vonck 21 Jun '13

21 Jun '13

I tried to run obc and oo2c on a raspberry pi. Is anyone programming the pi or beagle beagle board in Oberon or Component Pascal? I use free pascal for programming UDP and CGI applications on a pi. But I need explicit imports for teaching programming. Greets, F.P.

1 0

Re: [Oberon] Relationship of Displays.Display to other Display modules.
by Treutwein Bernhard 07 Jun '13

07 Jun '13

Hi Peter, although I cannot clear up the questions about Display.Mod and Displays.Mod nor the hierarchy of imports/hardware specifics ... Maybe the short note about name spaces in Oberon, which can be found under the link below, is of some help: http://www.ocp.inf.ethz.ch/wiki/Documentation/Language?action=download&upna… regards -- Bernhard

1 0

Relationship of Displays.Display to other Display modules.
by peasthope＠shaw.ca 06 Jun '13

06 Jun '13

Hi, Any correction or elaboration of these statements is welcome. My question is at the end. Drivers for specific display adapters are in modules <hardware>.Diplay.Mod such as S3Trio.Display.Mod. Empty.Display.Mod is a template to serve as the basis for writing a new driver. Display3.Mod implements display primitives used in Gadgets. Displays.Display.Mod imports Diplays under the name AosDisplays. Nevertheless, the comment is "Native Oberon display ...". (?) Displays.Display.Mod and <hardware>.Display.Mod all have "MODULE Display". So how does Displays.Display.Mod relate to the <hardware> modules? If a computer is using S3Trio.Display.Obj, for example, what is the role of Displays.Display.Obj, if any? Thanks, ... 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