March 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

Re: [Oberon] [ANN] GigaDraw - The Ultimate Drawing App for Oberon V5 (well, almost ; ))
by Till Oliver Knoll 25 Mar '19

25 Mar '19

> Am 25.03.2019 um 11:03 schrieb Dieter <d.gloetzel(a)web.de>: > > Sounds interesting! Is there a version for ETHOberon on Windows 10 available? I added some further references to the README: https://github.com/till213/GigaDraw/blob/master/README.md To my understanding the „Oberon Core“ application available (for free) in the Mac App Store is based on the „Oberon RISC Emulator“ code here: https://github.com/pdewacht/oberon-risc-emu There are build instructions for various platforms, including Windows. Apparently there are also binaries for Windows. For a quick glimpse you may also head over to „Oberon in the browser“, here: https://schierlm.github.io/OberonEmulator/ There you can even choose from a range of „disk images“ to quickly try out, including „Experimental Oberon“, which offers smooth scrolling ;) Cheers, Oliver

1 1

[ANN] GigaDraw - The Ultimate Drawing App for Oberon V5 (well, almost ; ))
by Till Oliver Knoll 24 Mar '19

24 Mar '19

Dear all, As threatened in a previous post of mine I have published the code of our "GigaDraw" on Github: https://github.com/till213/GigaDraw It was originally developed as a student's exercise during the last "Systemsoftware" lectures given by professor Niklaus Wirth, winter semester 1998/99. Originally it compiled and ran on Oberon V4 on a Ceres 3 computer (and on various Oberon ports for Windows etc. at the time). The "v1.0.0" tag contains the original sources as backed up with the fine "Oberon2DOS" (?) tool at the time (1999). The current "v1.0.1" tag contains the quickly adapted sources, such that they compile on "Oberon Core", an implementation in the Mac App Store of Oberon-2013 (Oberon V5). I deliberately kept that initial port as close as possible to the original sources, without putting much work into it (even though some parts are really cringeworthy nowadays). There are still many quirks, rendering artifacts (no clipping yet, as the "Display.Mod" in V5 dropped all "clipped" drawing operations) and even TRAPS during the "PackMan Attack". Yes, you read that right: our GigaDraw features an arrow keys controllable PackMan which eats your drawings! That's a unique and genuinely useful feature that really makes your GigaDraw unique, even today ;) (Uh... and yes: the corresponding "PacCmd.Start" respective "PacCmd.PacAttack" commands totally turn your Oberon system into a single task OS, by running their own "event loop" - escape with ESC ;)). So have fun, have a laugh, marvel at the code of two students. As time permits I'll try to fix this and that... but don't hold your breath. The README contains no "install" instructions yet, but basically you open the "GigaDraw.Tool" which contains compilation and application commands. Cheers, Oliver

1 0

SystemV - Random Number
by Tomas Kral 24 Mar '19

24 Mar '19

Hi, How can we do a random number, with a seed? -- Tomas Kral <thomas.kral(a)email.cz>

8 11

SystemV - Viewer Scroll
by Andreas Pirklbauer 23 Mar '19

23 Mar '19

> As you demonstrated guessing and forward reading is faster than backward reading. Another side comment: The method of “guessing and forward reading" is faster than "backward reading” even in the case where CopyBlock is used optimally. If one wanted to make "backward reading" fast enough, it would need to be incorporated directly in the base modules Files and Texts (where one can optimize things like file buffer allocation and piece list management). But that ain't gonna happen any time soon (even though the code to achieve that is not all that complex).

1 0

SystemV - Viewer Scroll
by Andreas Pirklbauer 23 Mar '19

23 Mar '19

> No I don‘t. I‘m happy with the scroll speed we got. Tomas just asked > why the scroll code is asymmetric, and the main reason is: Using standard > Texts API it’s easier to find the end of a line than to find the start of a line. > > As you demonstrated guessing and forward reading is faster than backward reading. > > br > Jörg Yes. The question on why there is asymmetric code is answered now. For click-by-click scrolling, the existing code in the Original Oberon system (and in FPGA Oberon) - which just redraws all lines - is entirely adequate. It’s only in the case of continuous scrolling that it is too slow. PS: This is, in fact, a good example of “making it as simple as possible”. By choosing not to implement continuous scrolling, the code in Original Oberon (which is taken over 1:1 in FPGA Oberon) became super simple (only 3 lines for backward scrolling in TextFrames.Show). It also does not have to deal with potential memory leak issues, when continuously allocating new lines in the heap (which however is easy to address). Case closed.

1 0

SystemV - Viewer Scroll
by Andreas Pirklbauer 23 Mar '19

23 Mar '19

> My quick hack was only applicable to Files. > Assuming you have a frame, initialized a Reader "R" already > and want to set this Reader back by one position. > > Texts.OpenReader(R, f.text, Texts.Pos(R)-1); > Texts.Read(R, ch) > > Jörg Hi Jörg, just in case ... you are thinking of actually implementing this kind of “read backwards” operation, you’ll notice that the resulting code for text scrolling will be fast enough (i.e. avoids flickering) *only* if you implement it directly *within* modules Files and Texts (been there, done that..). But if you implement it outside Files and Texts, i.e. write something along the lines of: PROCEDURE ReadBack (T: Texts.Text; VAR R: Texts.Reader; VAR ch: CHAR; VAR bof: BOOLEAN); VAR pos: INTEGER; BEGIN pos := Texts.Pos(R); IF pos > 0 THEN bof := FALSE; Texts.OpenReader(R, T, pos-1); Texts.Read(R, ch); Texts.OpenReader(R, T, pos-1) ELSE ch := 0X; bof := TRUE END END ReadBack; then text scrolling will simply be too slow, when e.g. used as in: PROCEDURE Scroll* (F: Frame; dY: INTEGER); (*scroll displayed text dY pixels up or down*) VAR R: Texts.Reader; L, L0: Line; bof: BOOLEAN; org: LONGINT; dy: INTEGER; BEGIN (*dY # 0*) IF F.trailer.next # F.trailer THEN IF dY < 0 THEN (*move backwards*) dY := -dY; org := F.org; Validate(F.text, org); IF org > 0 THEN NewLine(F, L); dy := 0; REPEAT Texts.OpenReader(R, F.text, org-1); ReadBack(F.text, R, nextCh, bof); ReadLineBack(L, F.text, R, bof); dy := dy + L.lsp; org := org - L.len; (*...code that sets up line list to be inserted ...*) UNTIL bof OR (dy + F.voff >= dY); ScrollDown(F, org, F.voff + dy - dY, dY) END END ELSIF dY > 0 THEN (*move forward*) ... END END END Scroll; where: PROCEDURE ReadLineBack (L: Line; T: Texts.Text; VAR R: Texts.Reader; VAR bof: BOOLEAN); (*pass 1*) VAR maxY, minY, len: INTEGER; BEGIN maxY := asr; minY := -dsr; len := 0; WHILE ~bof & (nextCh # CR) DO IF R.fnt.maxY > maxY THEN maxY := R.fnt.maxY END; IF R.fnt.minY < minY THEN minY := R.fnt.minY END; INC(len); ReadBack(T, R, nextCh, bof) END; L.len := len + 1; L.asr := maxY; L.dsr := -minY; L.lsp := maxY - minY; L.eot := FALSE END ReadLineBack; So if you want fast enough code for *completely smooth* and flicker-free text scrolling, there are two options: Option #1. Modify Files and Texts to add Files.ReadBack and Texts.ReadBack Option #2. Find a faster solution than the “natural” code outlined above. I have done both. In the end I decided to use option #2, as I wanted to leave modules Files and Texts untouched. HOWEVER - and unfortunately - I admit that I found no better solution than to simply “guess” the right position N times until it is “right” (if a good heuristic is chosen, N = 1 or 2 in most cases though) and then just read *forward* from there. This makes the code more complex, but also faster (at least it eliminates flickering): PROCEDURE Scroll (F: Frame; dY: INTEGER); (*scroll displayed text dY pixels up or down*) CONST P = 100; len = 75; (*assumed average line length*) VAR R: Texts.Reader; L, L0: Line; done: BOOLEAN; org, q: LONGINT; dy, k: INTEGER; p: ARRAY P OF LONGINT; d: ARRAY P OF INTEGER; BEGIN (*dY # 0*) IF F.trailer.next # F.trailer THEN IF dY < 0 THEN dY := -dY; IF dY <= F.voff THEN ScrollDown(F, F.org, F.voff - dY, dY) ELSE NewLine(F, L); done := FALSE; q := Max(F.org - len*((dY + lsp - F.voff - 1) DIV lsp), 0); (*first guess*) REPEAT org := q; Validate(F.text, org); k := 0; dy := 0; Texts.OpenReader(R, F.text, org); Texts.Read(R, nextCh); WHILE (org < F.org) & (k < P) DO PrepareLine(L, R); dy := dy + L.lsp; p[k] := org; d[k] := L.lsp; org := org + L.len; INC(k) END; IF org < F.org THEN q := p[1] (*next guess forward*) ELSIF q = 0 THEN (*reached beginning of text*) done := TRUE; IF dy + F.voff > 0 THEN ScrollDown(F, 0, 0, dy + F.voff) END ELSIF (k = 0) OR (dy + F.voff < dY) THEN q := Max(q - len, 0) (*next guess backward*) ELSE (*found, now scroll*) k := 0; done := TRUE; WHILE dy - d[k] + F.voff >= dY DO dy := dy - d[k]; INC(k) END; ScrollDown(F, p[k], F.voff + dy - dY, dY) END UNTIL done END ELSIF dY > 0 THEN ... END END END Scroll; If someone has a more elegant (and equally fast or even faster) solution I am a happy taker. PS: When it is done inside Files and Texts, scrolling is only marginally faster than the above code... -ap

2 1

Re: [Oberon] LolaCreator: a Lola-2 IDE based on Qt Creator
by rochus.keller＠bluewin.ch 22 Mar '19

22 Mar '19

@ Paul Reed > The tools are complex in their behaviour. Sure they are; also the Lola-2 code of the Risc5 processor by Prof. Wirth is complex. Complexity per se does not hinder predictability; this is rather in the eye of the beholder. It also depends on the definition of "predictability". A simulated annealing based algorithm is per definition unpredictable because it includes random parts; in contrast technology mapping and logic minimization are (mostly) deterministic algorithms even accessible to formal verification methods. But that's exactly something I want to find out with my implementation: does Lola-2 really support a simpler, more deterministic and less error prone workflow than Verilog. Best R.

1 0