January 2019 - Oberon - mailman3.inf.ethz.ch

Wanted: Oberon Syntax in TextMate, Sublime Text or Atom Grammar
by Treutwein Bernhard 01 Jan '22

01 Jan '22

Does somebody have grammars for Oberon / Oberon-2 / Component Pascal / Active Oberon as grammar for TextMate / Sublime Text / Atom Background: Github wrongly classifies Oberon / Oberon-2 / Component Pascal / Active Oberon as Modula-2. I opened quite some tiome ago an issue in the github/linguist project (https://github.com/github/linguist/issues/3888) and they don't accept EBNF grammars. -- Bernhard Treutwein

6 9

Debugging FPGA oberon via serial line?
by Michael Schierl 29 May '20

29 May '20

Hello, while I was adding UTF-8 support to Fonts and Texts (and almost rewriting Fonts so that a font can be loaded partially and not all glyphs at once), I noticed that debugging such a system can be cumbersome (as you cannot read the TRAP output any more, as well as you have to reset the system to a previous state to be able to fix your mistakes if the screen is too garbled to be useful, or if the system TRAPs during boot). By the way, here is Oberon running in the browser with UTF-8 support for Texts (and Tahoma font): http://schierlm.github.io/OberonEmulator/emu.html?image=UnicodeDiskImage >From other (older) systems, I know it is possible to debug them via serial line, so I was thinking how much the FPGA oberon system needs to be changed (hardware side/software side) to accommodate this. RS232 is supported, so you could use one FPGA system (or emulator) to debug the other one. And I was wondering if anybody already tried doing something like this. I know that Colby Russell worked on debug support in the emulator, but no idea about how far he got. A minimal feature set to be useful (in my opinion) would be - Read and write memory and disk via serial port while the system is running/idle (already possible today via ORC / PCLink) - Set and remove software breakpoints while the system is running/idle - When software breakpoint or trap is hit, save processor state and allow debugging via serial port (-> suspended) - Read and write registers and memory while the system is suspended - Set and remove software breakpoints while the system is suspended - Continue execution when the system is suspended More advanced features would be single stepping (can be emulated by having a look at the instruction and setting software breakpoints at all following locations), or memory breakpoints. Also to be able to enter the debugger by pressing a hardware button on the FPGA (similar to the current reset functionality, but not resetting). And of course symbolic debugging :) Software breakpoints should be easy, just replace instruction by BL to a fixed address. Restore the instruction before returning. For catching TRAPs, overwrite the TRAP address. Saving processor state might be tricky, especially SYSTEM.H and the flags, and maybe you have problems since you need at least one spare register to be able to save the registers to a fixed location in memory. You will also need to switch stack to a second stack before the stack is accessed by the code. Probably solvable by using a special compiler that leaves a register or two unused. Restoring SYSTEM.H and Flags is also not supported (except by searching for instructions that will result in the desired flags or results). Also the question is whether returning to the code will not destroy some flags again. And you need to make sure not to set breakpoints or break at points where a BL has happened but the link register has not been saved yet. So (similar to interrupt) probably some hardware support is needed for this. Entering the debugger by button also needs hardware support (since the current Reset button forgets the PC and some other state). Once in suspend mode, it might be hard to avoid allocating memory, since you cannot run the GC which might collect objects that are still used by the suspended program. But that should be feasible if the functions are basic enough to work with a fixed buffer (e.g. number of breakpoints is limited). I guess memory breakpoints are only possible with hardware support for them (I have no idea how to emulate them except emulating or setting breakpoints at all LOAD/STORE instructions). For symbolic debugging, the compiler would have to write some more debug symbols. For a start, <https://github.com/schierlm/OberonXref/blob/master/ORG.Mod.patch> annotates the code position for every instruction; I currently use it for creating combined source/assembly listings like <https://schierlm.github.io/OberonXref/ProjectOberon2013/ORP.html#both>. But you would probably also need some information about the stack layout (variable names and types) and register contents for every code locatoin, as well as information about module/global variables, and not-exported record types and record members. And you would also need some client to utilize all this information so that you can do something like "Debugger.Inspect F.vwr.dsc" :) So I guess for my own needs, that's too much work for the benefit (especially since I don't know if I will ever try to rewrite any of the core modules again). But perhaps I'm missing something? Any better ideas? Regards, Michael

1 1

PO2013 - Real time measurement
by Tomas Kral 23 Apr '19

23 Apr '19

Hi, I wish to do some real time input from basic sensors. This discipline is well established with so called home automation, developed through Arduino project, see MySensors lib, etc. [a] Arduino can do A/D conversions for Oberon while it can talk over WiFi, the same WiFi, PO2013 was designed with, more sensors can be linked in a HUB. [b] PIC processors can also do A/D conversion. PIC can possibly interconnect through GPIO, while I cannot see an easy way to add more devices to the hub (* multiplexing GPIO input???*). It also has some leverage in NW's PICL project. Both options require some more studying and understanding on my part. Generally what is your experience, recommendations to pursue [a], [b] for PO2013? Many thanks -- Tomas Kral <thomas.kral(a)email.cz>

9 52

FPGA - DIY Dialogs
by Tomas Kral 06 Feb '19

06 Feb '19

Hi, Trying to draw a selection rectangle, aka `marching ants'. I do this, it makes selection east-rightwards only. I am surprised I need to call `DrawBox' in three places, otherwise it trails visual marks. I wish to keep the code minimal. How to make it in all directions? PROCEDURE DrawBox(x, y, w, h: INTEGER); (*selection rectangle*) BEGIN Display.ReplPattern(8, Display1.grey2, x, y, w, 1, Display.invert); Display.ReplPattern(8, Display1.grey2, x, y+h-1, w, 1, Display.invert); Display.ReplPattern(8, Display1.grey2, x, y, 1, h, Display.invert); Display.ReplPattern(8, Display1.grey2, x+w-1, y, 1, h, Display.invert) END DrawBox; PROCEDURE TrackSelection(M: Oberon.InputMsg); (*eastwards*) VAR x, y: INTEGER; keys: SET; BEGIN x := M.X; y := M.Y; REPEAT DrawBox(M.X, M.Y, ABS(M.X-x), ABS(M.Y-y)); Input.Mouse(keys, x, y); Oberon.DrawMouse(Crosshair, x, y); DrawBox(M.X, M.Y, ABS(M.X-x), ABS(M.Y-y)) UNTIL keys = {}; DrawBox(M.X, M.Y, ABS(M.X-x), ABS(M.Y-y)) END TrackSelection; -- Tomas Kral <thomas.kral(a)email.cz>

5 23

Re (2): Re (2): Portability.
by peter＠easthope.ca 28 Jan '19

28 Jan '19

From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> Date: Fri, 25 Jan 2019 23:41:08 +0000 > (** *) meant "exported comments". A tool named Def would produce a > module interface file with these comments embedded in the file. So you > could write a self-documented code where the exported comments > provided the first level of documentation. From: Treutwein Bernhard <Bernhard.Treutwein(a)Verwaltung.Uni-Muenchen.DE> Date: Mon, 28 Jan 2019 11:43:28 +0000 > ... [(** portable *)] label was used to mark modules, where the > OMI/Slim Binary code was portable across platforms. Thanks. There's an entry in the glossary now. https://en.wikibooks.org/wiki/Oberon#Glossary Improvement or correction welcome. ... P. -- Message composed and transmitted by software designed to avoid the complication, overhead and vulnerability of antivirus software. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 +1 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

System-V - Invisible Viewer
by Tomas Kral 28 Jan '19

28 Jan '19

Hi, Is it possible to open invisible viewer, I just need to receive messages, but display output is in another module? My idea is to bind to a GUI piece of code, receive a bind id, and exchange messages with it. -- Tomas Kral <thomas.kral(a)email.cz>

2 1

Portability.
by peter＠easthope.ca 28 Jan '19

28 Jan '19

Many of the modules in S3 and A2 had the comment (** portable *) following the module name. The comment has been removed from some more recent sources. Examples: Out in S3 Out in LinuxA2 Generic, rev.8586 /usr/aos/source/Out.Mod https://trac.inf.ethz.ch/trac/lecturers/a2/browser/trunk/source/Oberon.Out.… (rev.8667) Portability is discussed in https://en.wikipedia.org/wiki/Software_portability . Should "(** portable *)" still appear in an Oberon source? Too ambiguous to be helpful? Thanks, ... Lyall E. -- Message composed and transmitted by software designed to avoid the complication, overhead and vulnerability of antivirus software. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 +1 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

3 2

Re: [Oberon] FPGA Oberon vs Ceres - mouse wraparound
by Chris Burrows 27 Jan '19

27 Jan '19

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Skulski, Wojciech > Sent: Monday, 28 January 2019 3:33 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] FPGA Oberon vs Ceres > > There are some little bugs as well. On our copy running on Pepino I > noticed that the mouse cursor wraps around the screen. It disappears > on the right and reappears on the left, or vice versa. Not sure if > this was the case with Ceres. > My understanding is "that is not a bug, it is a feature". The behaviour is documented in the 2005 edition of the Project Oberon book: "SetMouseLimits permits to determine the limiting coordinate values of the rectangle into which the mouse position is mapped and where the cursor is drawn. The position "wraps around" in both the horizontal and vertical directions." P.S. I wish that every designer of on-display keyboards controlled by a TV remote had considered this. E.g. it takes me 23 keypresses to spell out 'wojtek' without wraparound as opposed to 16 when wraparound is implemented. Regards, Chris Burrows CFB Software http://www.astrobe.com

1 0

FPGA Oberon vs Ceres
by Andreas Pirklbauer 27 Jan '19

27 Jan '19

> The upper levels of the System may stayed, but the lower levels have probably changed a bit. > I think that low level drivers have changed, like for example the disk which is now SD card > served over SPI. The network is now wireless, so I am not sure if it is the same as the Ceres RS-422. You are of course right. I was referring mostly to the upper parts. In addition to the compiler, device drivers did indeed (have to) change as well, e.g., keyboard and mouse now use the PS-2 interface standard, the “disk” (well, an SD card in FPGA Oberon..) no longer uses SCSI, but the SPI interface, RS-485 is no longer used for the net, etc. It is, perhaps, also interesting to note that some (but not all) device drivers were written in assembly code back then, but are now written entirely in Oberon. An example is the display driver Display.Mod (a common student exercise at ETH was to implement CopyBlock in NS32032, MC68000.. assembly).

1 0

FPGA Oberon vs Ceres
by Andreas Pirklbauer 27 Jan '19

27 Jan '19

> There are some little bugs as well. On our copy running on Pepino I noticed that the > mouse cursor wraps around the screen. It disappears on the right and reappears on > the left, or vice versa. Not sure if this was the case with Ceres. Yes, it was also the case on Ceres. But I can’t remember whether it stayed like that forever. It may have been changed at one point on Ceres-3?

1 0