September 2018 - 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

FPGA - Screen.Mod
by Tomas Kral 26 Oct '18

26 Oct '18

Hi, EDIT (1) I am looking for `Screen.Mod' module (mainly its `Screen.Grub' command) hinted in PO2013 pictures. I have completed early version of `Bitmaps.Mod' supporting basic set of raster operations. I wish to share pictures and code. As we may not post attachments to the forum, I could expose to GitHub, there is also `WikiBook' run by Lyall E. Please advise. Many thanks. -- Tomas Kral <thomas.kral(a)email.cz>

4 15

FPGA Oberon - Definition Module Tool
by thomas.kral＠email.cz 08 Oct '18

08 Oct '18

Hi, I am thinking of a simple tool that could extract definition info from *.Mod and produce respective *.Def file. Definition files can be quickly looked at, to remind a programmer of the interface *.Mod modules export. While on Linux one could use grep $ grep PROCEDURE\ * *.Mod.txt to obtain info at least about procedures, but how about exported types and variables? I am looking for a recommended way how to simply code such a tool, is it a good idea to use `ORP' parser somehow for the task? I prefer to code it simple, does not have to be perfect, but should carry the idea. Tomas

5 11

FPGA - Files.ReadBytes(), Files.WriteBytes()
by Tomas Kral 07 Oct '18

07 Oct '18

Hi, Files.Mod has procedures for reading/writing a block of bytes, bytewise. PROCEDURE ReadBytes*(VAR r: Rider; VAR x: ARRAY OF BYTE; n: INTEGER); VAR i: INTEGER; BEGIN i := 0; (*this implementation is to be improved*) WHILE i < n DO ReadByte(r, x[i]); INC(i) END END ReadBytes; PROCEDURE WriteBytes*(VAR r: Rider; x: ARRAY OF BYTE; n: INTEGER); VAR i: INTEGER; BEGIN i := 0; (*this implementation is to be improed*) WHILE i < n DO WriteByte(r, x[i]); INC(i) END END WriteBytes; The comment suggests improving the code further. Any hints to improve the code? Thanks -- Tomas Kral <thomas.kral(a)email.cz>

3 9

FPGA - Display.Mod 4-bit colour
by Tomas Kral 02 Oct '18

02 Oct '18

Hi, I wish to modify `Display.Mod' to accept 4-bit colour. Standard interface currently supports 1-bit colour only. PROCEDURE Dot*(col, x, y, mode: INTEGER); PROCEDURE ReplConst*(col, x, y, w, h, mode: INTEGER); PROCEDURE CopyPattern*(col, patadr, x, y, mode: INTEGER); PROCEDURE CopyBlock*(sx, sy, w, h, dx, dy, mode: INTEGER); PROCEDURE ReplPattern*(col, patadr, x, y, w, h, mode: INTEGER); I have a version of VID.v with 4-bit pixels and a 16 entry colour lookup table. So `col' parameter in the range {0..15} defines index into that table. Looking at the code, I realise each display line takes 128 bytes 1-bit. 4-bit it must be 4*128. While single word sets 1-bit colour of 32 pixels, and only 8 pixels of 4-bit colour, correct? I am generally seeking advice for the good starting point, also hwoto set up a test environment for quick tests turnaround? My idea was to make a standalone boot program accepting draw commands over serial. I may start with `ReplConst' (font rendering), and `ReplConst' (line drawing). I wonder how much of the original code I could reuse, just extending the loop count, and some 4-bit manipulation? Many thanks in advance. -- Tomas Kral <thomas.kral(a)email.cz>

3 9

Re: [Oberon] FPGA - Display.CopyBlock()
by Chris Burrows 28 Sep '18

28 Sep '18

> > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Claudio Nieder > Sent: Thursday, 27 September 2018 10:54 PM > To: ETH Oberon and related systems > Subject: Re: [Oberon] FPGA - Display.CopyBlock() > > Hi, > > this is by the way something Wirth had done in the past when he > designed the Lilith. The Lilith had a self made (out of bit slice > processor 2901) processor and its instruction set called M-Code > featured also instructions like "Display Dot", "Replicate Pattern", > "Bit block transfer" and "Display character". They are mentioned on > page 63 of ETH Report Nr 40 - The Personal Computer Lilith. Apr 1981. > N. Wirth which you can find at https://www.research- > collection.ethz.ch/bitstream/handle/20.500.11850/69801/eth-3139- > 01.pdf?sequence=1&isAllowed=y > > "Bit block transfer" is what probably was used to scroll with > "hardware support". > > claudio > For more details see Chapter 10.2 Screen of the 'Lilith Handbook - A Guide for Lilith Users and Programmers' and the microcode source of the M-Code instructions for the Display Handling Procedures both of which can be download from the documentation section of the Lilith Emulator (EmuLith) ftp site: ftp://ftp.dreesen.ch/Emulith/Docu/ Chris Burrows CFB Software http://www.astrobe.com/RISC5

1 0

FPGA - Display.CopyBlock()
by Tomas Kral 27 Sep '18

27 Sep '18

Hi, `Display.CopyBlock()' is primarilly used to scroll viewer text up/down. I learnt the code is more general however, capable of skewing horizontally, even diagonally. For diagonal moves, I sometime observe areas left blank, not copied from the source rectangle. It only happens in the last word shifted either left or right. PROCEDURE Test*; CONST X = 50; Y = 50; W = 50; H = 50; DX = 40; DY = 40; BEGIN Display.ReplConst(Display.white, X, Y, W, H, Display.replace); (*fill*) Display.CopyBlock(X, Y, W, H, DX, DY, Display.invert); (*shift down left*) Display.CopyBlock(X, Y, W, H, DX+20, DY+20, Display.invert) (*shift up right*) END Test; I do not understand code fully yet, by tinkering with it, I possibly pinned down the lines where some improvement may happen. PROCEDURE CopyBlock*(); ... IF n >= 0 THEN (*shift right*) ... FOR ... END; SYSTEM.GET(sa0, src); src := ROR(src, n); (*ASR used instead?*) SYSTEM.GET(sa0+d, dst); SYSTEM.PUT(sa0+d, (src * m0) + (dst - m0)) ... ELSE (*shift left*) ... FOR ... END; SYSTEM.GET(sa0+len, src); src := ROR(src, n); (*ASR used instead?*) SYSTEM.GET(sa0+len+d, dst); SYSTEM.PUT(sa0+len+d, (src - m2) + (dst * m2)) END ; -- Tomas Kral <thomas.kral(a)email.cz>

5 8

FJump and FixLink
by Andreas Pirklbauer 23 Sep '18

23 Sep '18

> In short, I would have coded the procedures as follows: > > PROCEDURE FixLink*(L: LONGINT); > VAR L1: LONGINT; > BEGIN > WHILE L # 0 DO L1 := code[L] MOD 2000H; FixOne(L); L := L1 END > END FixLink; > > PROCEDURE FixLinkWith(L0, dst: LONGINT); (* used for «UNTIL» *) > VAR L1: LONGINT; > BEGIN > WHILE L0 # 0 DO > L1 := code[L0] MOD 2000H; fix(L0, dst - L0 - 1); L0 := L1 > END > END FixLinkWith; > PS: Which, if I am not mistaken, could also be expressed as: PROCEDURE FixLinkWith(L, dst: LONGINT); VAR L1: LONGINT; BEGIN WHILE L # 0 DO L1 := code[L] MOD 2000H; fix(L, dst-L-1); L := L1 END END FixLinkWith; PROCEDURE FixLink*(L: LONGINT); BEGIN FixLinkWith(L, pc) END FixLink;

1 0

FJump and FixLink
by Andreas Pirklbauer 23 Sep '18

23 Sep '18

> Personally, I would use C22 in fix(). > And «MOD maxCode» in FixLinx..() > And try to make ORG.maxCode a power of two for efficiency reasons. > But feel free to take C22 everywhere. > > br > Jörg Ok, now that the issue is fully understood it’s matter of taste. I'll sleep over it before making a final decision. Thx for the clarification! PS: For ORG.fix, one advantage of sticking with C24 is that it makes it deterministic: for negative branch offsets, the leading bits #22 and #23 will *always* be set to 1, no matter what their values were before and which does no harm, as you have stated earlier, while for positive offsets bits #22 and #23 will be set to 0. This may have been one of the reasons why C24 has been used in the official Oberon-07 compiler, but I just don’t know. PS2: For ORG.FixLink, both MOD C22 or MOD maxCode if maxCode is a power of 2 are fine. Note that ORG.CheckRegs checks for pc >= maxCode anyway.. -ap

1 0

FJump and FixLink
by Andreas Pirklbauer 23 Sep '18

23 Sep '18

> The RISC5 processor has an addressbus of 24 bits («adr» in RISC5.v = 16 MB possible). > The PC and branch displacements are on word boundary, they have 22 bits («disp» in RISC5.v) > > In short, I would have coded the procedures as follows: > > PROCEDURE FixLink*(L: LONGINT); > VAR L1: LONGINT; > BEGIN > WHILE L # 0 DO L1 := code[L] MOD 2000H; FixOne(L); L := L1 END > END FixLink; > > PROCEDURE FixLinkWith(L0, dst: LONGINT); (* used for «UNTIL» *) > VAR L1: LONGINT; > BEGIN > WHILE L0 # 0 DO > L1 := code[L0] MOD 2000H; fix(L0, dst - L0 - 1); L0 := L1 > END > END FixLinkWith; > Ok. Got it. This makes more sense. But it works only for ORG.maxCode = 8000, since 2000H = 8196. In my compilers ORG.maxCode usually is 12000 or even 16000. So with the above approach, I’d end up having to use 4000H = 16’384, i.e. the next higher power of 2 (for efficiency) anyway.. How about using C22 = 400000H (with FIVE zeros, not four!) = 4’194’304 = 2^22 instead of 2000H? That way, one would be... a) correct (max displacement = 22 bits), and b) “safe” even for all potential values of ORG.maxCode up 4’194’304 = 4M words = 16MB RAM. once and for good? -ap

2 1