April 2024 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Export of Oberon Mail.SendCmd().
by Joerg 30 Oct '26

30 Oct '26

Generally, re-using code instead of copying is a good approach. If you do so, then the whole code of Mail is imported in News. Possible but perhaps there is even a better approach to re-use code. What about this: try to separate all common code in an own module (e.g call it Communication.Mod or MsgBase.Mod or Utilities.Mod or so) and import this new module in Mail and in News. br Jörg > Am 14.06.2023 um 19:53 schrieb peter(a)easthope.ca: > > Hello again, > > Several procedures in Mail are used in Oberon News. Rg.: > Mail.ParseContent(), Mail.DecodeMessage() & Mail.GetSetting(). > > Is export of SendCmd() and use in News objectionable? > Ie. in Mail, change PROCEDURE SendCmd(...) to PROCEDURE SendCmd*(...). > > Thanks, ... P. > > - > mobile: +1 778 951 5147 > VoIP: +1 604 670 0140 > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Re: [Oberon] Oberon Digest, Vol 238, Issue 6
by Daniel Schmid 06 May '24

06 May '24

Dear Elen Honestly speaking i don't understand what exactly you'r going to emulate and so if this information will help, but anyway let me say; i got an Evaluation Board from Digilent with an Artix-7 FPGA on it and then could - with the support of astrobe - program the NW RISC5 processor from the Verilog source. Oberon is running well on it. So this is no original but current hardware. Best regards from Switzerland Daniel On Sun, 2024-03-17 at 12:00 +0100, oberon-request(a)lists.inf.ethz.ch wrote: > Send Oberon mailing list submissions to > oberon(a)lists.inf.ethz.ch > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.inf.ethz.ch/mailman/listinfo/oberon > or, via email, send a message with subject or body 'help' to > oberon-request(a)lists.inf.ethz.ch > > You can reach the person managing the list at > oberon-owner(a)lists.inf.ethz.ch > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Oberon digest..." > > > Today's Topics: > > 1. Emulating Project Oberon's RISC5 Architecture using Icarus > Verilog (Elen Edain) > 2. Re: Emulating Project Oberon's RISC5 Architecture using > Icarus Verilog (Hellwig Geisse) > > > --------------------------------------------------------------------- > - > > Message: 1 > Date: Sat, 16 Mar 2024 10:15:05 +0000 > From: Elen Edain <elen.edain(a)protonmail.com> > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Emulating Project Oberon's RISC5 Architecture using > Icarus Verilog > Message-ID: > <jQ3PCiO9X0FdAiKZeNURSPbsnrvCMK4suFF9FnBwOsH5JKsA4_UGIumFYdAD > tMQ_AoBMO0PNVjKpb41k1n1v0yO8S1uOyBUQX62krC5ve5Q=(a)protonmail.com> > > Content-Type: text/plain; charset="utf-8" > > Hello and Greetings from Iceland, > > I am currently undertaking a project to simulate the Project Oberon > RISC5 system architecture using Icarus Verilog, aiming to replicate > the system?s environment in a manner similar to QEMU for educational > exploration. This endeavor is inspired by Niklaus Wirth's educational > vision, focusing on understanding system design comprehensively. > > Despite progress, I've encountered a challenge with emulating > specific FPGA modules (originally on a Digilent Spartan 3 board), > notably the DCM, RAM16X1D, and IOBUF modules, as a software > simulation. This aspect falls beyond my expertise as a software > engineer, primarily dealing with hardware emulation nuances. Thus I > am on a learning journey as well and it is early days. > > I am seeking the community's expertise and advice on simulating these > FPGA modules in Verilog, to further develop a detailed tutorial > aligned with Wirth's original documentation, thereby eliminating the > dependency on the original FPGA board. > > The ultimate aim is to produce a contemporary, step-by-step guide for > working through the Project Oberon ecosystem without the need for the > original FPGA board. Any advice, resources, or guidance on where to > start with these hardware component emulations would be greatly > appreciated. > > Best regards, > > Elen >

2 2

Re: [Oberon] Extended Oberon running on Pepino
by Skulski, Wojciech 23 Apr '24

23 Apr '24

Peter: thank you! I also posted a shortened version to Minimalist Computing on Facebook. Regards, Wojtek

1 0

Re: [Oberon] Extended Oberon running on Pepino
by peter＠easthope.ca 23 Apr '24

23 Apr '24

Wojciech, From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> Date: Tue, 23 Apr 2024 03:38:24 +0000 > today I booted EOS on Pepino ... Good "State-of-the-Union" message to remind people of the "big picture". Thx, ... P. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Extended Oberon running on Pepino
by Skulski, Wojciech 23 Apr '24

23 Apr '24

Andreas: today I booted EOS on Pepino developed by Magnus Karlsson of Saanlima Electronics. Pepino was specifically designed to run the original firmware and the original 2013 FPGA Oberon System by Wirth and Reed. It is a small FPGA board similar to the Spartan-3 Starter Kit originally used to develop the 2013 System. The board is populated with Spartan-6 LX9, 1 MB of ASRAM memory (the same chipset as used originally with Spartan-3), PS/2 mouse and keyboard, and the VGA connector for the 1024*768 VGA monitor. The FPGA is filled to about 50% with the original RISC5 firmware, adjusted by Magnus for this FPGA. The soft core RISC5 is running at 25 MHz on this board for the same reason it did so on the original board, that is the speed of the ASRAM memory chips. I have been running Magnus' version of the original System on Pepino for quite a while. I first tried EOS under the Michael's version of the PdW Emulator under Windows 10. Michael kindly changed the white-on-grey to the usual white-on-black, so I could see anything. So I launched EOS under Windows 10, using the image downloaded from the EOS github. Pay attention: as far as I know, the image was originally developed under MacOS. So we have the first miracle right here. The binaries produced under MacOS ran under Windows 10 just like that. No recompilation required. Take note. I burned the same EOS image to a microSD using win32 Disk Imager-1.0.0. Then I inserted the microSD into the Pepino socket and power cycled the board. It booted the EOS on the first try in about one second. I demoed it to one of our employees with a few operations like opening, editing, and compiling the files. I also built the whole operating system "with one click" provided in System.Tool. Compilation took about a minute. (I did not measure time.) The build ended up with a file allocation error of System1.Mod. Apparently the disk went full. (Every demo must end with a bug....) But the EOS did not crash. It kept running. Now take another note. I ran the same binaries. The binary files, first developed and compiled on a Mac, were running under Windows, and then (the same binaries, yes, the same...) were running on a soft core on the FPGA. And the installation of this operating system took about one second. It consisted of inserting the microSD into the slot, and power cycling. One second. That's it. Now recall the last time you installed the fresh version of Raspbian, Beaglebian, Debian, or whatever this stuff is called. No adjustments needed. Really so? It is truly impressive that the whole graphical operating system with a decent editor, compiler, system building tools, and a whole bunch of example programs, which was developed on the emulated board on a Mac, without regular tests on any real hardware, flawlessly booted and ran under an emulated board in Windows 10, and then on real hardware board the first time ever. It just did. Not only that. I was able to instantly recompile the entire operating system in situ, using the target hardware board, in less than a minute, with the soft CPU core running 100x slower than Intel i3 core of my laptop. Those who never developed embedded systems may shrug their shoulders. It ran.... so what? Why is it so remarkable? Those who do develop real electronics may want to compare this experience with our daily practice. I would use the words "miraculous" and "unbelievable". It is truly unbelievable that the entire operating system could be developed under an emulator on MacOS, boot under another emulator under Windows, and then boot on a hardware board which it never saw before, without first causing months and months of frustration. And then this OS could recompile itself with one click on the very same target board. And it did so in less than a minute. We in this community do not fully appreciate the magnitude of this achievement by Niklaus Wirth, Paul Reed, Magnus Karlsson, Peter de Wachter, Michael Schierl, and Andreas Pirklbauer. And many others. But I do. I know the amount of suffering we are spending on this other embedded software. Thank you, Wojtek

2 1

Re: [Oberon] Discussion about A2.
by Chris Burrows 22 Apr '24

22 Apr '24

On Mon, Apr 22, 2024 at 12:31 AM <peter(a)easthope.ca> wrote: > Hi, > > When A2 was maintained in SVN, there was a page listing "issues". > Progress was reportable. > > Anything similar with the present Git repository? Visible only after > authenitication? > > > You can view the issues from Project > Plan > Issues: https://gitlab.inf.ethz.ch/felixf/oberon/-/issues You need to login with a username and password to create a new issue -- Chris Burrows CFB Software https://www.astrobe.com

1 0

Discussion about A2.
by peter＠easthope.ca 21 Apr '24

21 Apr '24

Hi, When A2 was maintained in SVN, there was a page listing "issues". Progress was reportable. Anything similar with the present Git repository? Visible only after authenitication? Thanks, ... P. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Why Oberon is my favourite programming language
by Chris Burrows 10 Apr '24

10 Apr '24

Why Oberon is my favourite programming language (for embedded systems at least): I find myself experiencing an intense feeling of schadenfreude whenever I read posts such as this 😉 https://www.eevblog.com/forum/programming/memcpy()-and-volatile/ -- Regards, Chris Burrows CFB Software https://www.cfbsoftware.com

2 1

Re (2): Call error: Oberon-Test. not found
by peter＠easthope.ca 01 Apr '24

01 Apr '24

From: Michael Schierl <schierlm(a)gmx.de> Date: Mon, 1 Apr 2024 22:16:33 +0200 > There is no PROCEDURE with an empty name "" in Module "Oberon-Test". Thanks. My brain was stuck in a misconception. ... P.L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

(no subject)
by Robert Lewis 01 Apr '24

01 Apr '24

i have installed Aos oberon with the realtek 8169 nic and installed the driver using Aos command but using the pet module for network, i am not seeing the card details. i tried to place the ip addr, dns addr, netmask, manually using configuration.XML but web browser fails to connect ..please detail how to do networking connectivity.

2 1