October 2017 - Oberon - mailman3.inf.ethz.ch

System.Directory options
by Andreas Pirklbauer 23 Oct '17

23 Oct '17

> > WHILE ch > "!" DO pat[i] := ch; INC(i); Texts.Read(R, ch) END; > pat[i] := 0X; > IF ch = "!" THEN pat[i+1] := “!" ELSE pat[i+1]:= 0X END ; (*directory option*) > Even better (and shorter). So that’s the fix.

3 2

System.Directory options
by Andreas Pirklbauer 23 Oct '17

23 Oct '17

See inline comments. > If ch is "!" then we want to put it in pat[i+1], if not then > since PROCEDURE List only compares with that value, any other one > will do. So that's why I suggested putting ch in in both cases. You are of course right, but only for this particular implementation of PROCEDURE System.List (which checks only that one value). My original implementation (which clears the rest of the *full* pattern array of 32 chars to 0X in order to *always* guarantee that a “clean” pattern array is presented to System.List) ... WHILE ch > "!" DO pat[i] := ch; INC(i); Texts.Read(R, ch) END; pat[i] := 0X; INC(i); IF ch = "!" THEN pat[i] := "!"; INC(i) END ; (*directory option*) WHILE i < LEN(pat) DO pat[i] := 0X; INC(i) END ; ... would work with ANY implementation of System.List - including one that accepts other (or even multiple) options. See your next point. > FWIW, I was also concerned about what would have to change if > another option was added. I have always lamented about the fact some Oberon commands use a “non-standard” way (whatever that means in Oberon) of parsing arguments - such as in System.Directory, where the “!” option must come *immediately* after the pattern, i.e. with *no* space allowed. This choice may have been motivated by the fact that the parameter “!" is passed on to System.List *as part of the pattern itself*. But it didn’t have to. Since List already uses a global variable for the pattern, it could equally well have used yet another global variable ‘patOptions' to hold the options (patOptions could be a SET for example). This would have kept the pattern itself clean and separate from the options, and also have made the handling of multiple options a trivial exercise. But ok, if we accept the current status quo, the only way to have multiple (single char) options would be to handle them explicitly: e.g. in System.Directory: i := 0; WHILE (ch >= "A") & (ch <= "Z") OR (ch >= "a") & (ch <= "z”) OR (ch = “.”) OR (ch = “*”) DO pat[i] := ch; INC(i); Texts.Read(R, ch) END; pat[i] := 0X; INC(i); WHILE ch > “ “ DO pat[i] := ch; INC(i); Texts.Read(R, ch) END ; (*directory options*) pat[i] := 0X; e.g. in System.List: INC(j0); ch := pat[j0] WHILE ch # 0X DO (*options*) IF ch = "!" THEN (*option 1*) Kernel.GetSector(adr, hp); Texts.Write(W, 9X); Texts.WriteClock(W, hp.date); Texts.WriteInt(W, hp.aleng*FileDir.SectorSize + hp.bleng - FileDir.HeaderSize, 8) (*length*) (*Texts.WriteHex(W, adr)*) ELSIF ch = “+” THEN ... (*option 2*) ELSIF ch = “?” THEN ... (*option 3*) ELSIF ... END ; INC(j0) END This is not recommended. It “fills" the pattern with the options which then need to be handled separately in List. It is easier and cleaner use a global variable for the options. e.g. in System.Directory: INCL(patOptions, option) e.g. in System.List: IF 1 IN patOptions THEN... My two Groschen.. -AP

1 0

FPGA - Oberon-0 program
by Andreas Pirklbauer 22 Oct '17

22 Oct '17

> On Sun Oct 22 10:43:29 CEST 2017 Tomas Kral wrote: > > Yes, building `IO.Mod' resolved that. Actually, the error > reported really was "Call error: TestOberon0 module not > found", that confused me. > This is because there is a bug in procedure Modules.Load. The global variable “Modules.importing" is not set correctly in some case cases. For example if one attempts to activate a non-existing command of an already loaded module, e.g. if you click on the text “Oberon.None”, it will display the error message “Call error: System command not found”. This bug can be fixed by inserting a single line as the (new) 4th last line of Modules.Load, as shown below: PROCEDURE Load*(name: ARRAY OF CHAR; VAR newmod: Module); ... BEGIN ... body (*initialize module*) END ELSE error(0, name) (*<---inserted*) END ; newmod := mod END Load; There are a few additional issues with Modules.Load that I have fixed some time ago. But they have not yet been published on the Oberon web page. If interested, I can provide/publish the modified version of “Modules" that fixes them all. -AP

3 3

System.Directory options
by Andreas Pirklbauer 22 Oct '17

22 Oct '17

>> If you do "System.Directory *.mod!" and after that without "!" than you > get details on both outputs. "!" toggles the details for output without "!". The issue is that System.Directory modifies a global variable ‘pat’, which may contain some “leftover” characters from a previous call to System.Directory. The following code makes sure it is always “clean”. In System.Directory change this code: WHILE ch > "!" DO pat[i] := ch; INC(i); Texts.Read(R, ch) END; pat[i] := 0X; IF ch = "!" THEN pat[i+1] := "!" END ; (*directory option*) to the following: WHILE ch > "!" DO pat[i] := ch; INC(i); Texts.Read(R, ch) END; pat[i] := 0X; INC(i); IF ch = "!" THEN pat[i] := "!"; INC(i) END ; (*directory option*) WHILE i < LEN(pat) DO pat[i] := 0X; INC(i) END ; -AP

1 0

FPGA - Oberon-0 program
by Tomas Kral 22 Oct '17

22 Oct '17

Hi, I have compiled late version of `Oberon-0' on FPGA system, needed just to replace COPY with := assignment for array in `OSS.Mod'. Unlike the earlier version (depositing code into memory), this one assembles `rsc' executable in the regular format of OberonLoader. Running `Oberon-0' compiler on `TestOberon0.Mod' is fine, trying to execute TestOberon0.Permutations 2 3 4~ example gives "module not found". I guess this is because corresponding symbol `smb' file does not exist, correct? -- Tomas Kral <thomas.kral(a)email.cz>

2 5

Re: [Oberon] FPGA - Boot over serial line
by Jörg 20 Oct '17

20 Oct '17

I mean OSG.Decode ( Jörg Am 13.10.17, 16:36 schrieb "Jörg" <joerg.straube(a)iaeth.ch>: ORG.Decode is the same as ORTool.DecObj in ProjectOberon Jörg Am 13.10.17, 16:09 schrieb "Oberon im Auftrag von Tomas Kral" <oberon-bounces(a)lists.inf.ethz.ch im Auftrag von thomas.kral(a)email.cz>: On Thu, 12 Oct 2017 17:42:34 +0200 Tomas Kral <thomas.kral(a)email.cz> wrote: > ORP.Compile @ ORG.Decode ORX.WriteFile BootLoad.rsc "prom.mem" So is `OSG.Decode' provided by Oberon-0 compiler. I have coded simplified `ORX.WriteFile' in shell for the host computer. It does not do all it should, but I hope carries the idea? #!/bin/sh # ORX.WriteFile # (c)tcat 13.10.2017 i=0; echo -n > prom.mem while read hex; do echo $hex >> prom.mem i=$((i+1)) done < prom0.mem j=$i; while [ $j -lt 512 ]; do echo 00000000 >> prom.mem j=$((j+1)) done # eof -- Tomas Kral <thomas.kral(a)email.cz> -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

5 25

FPGA - Boot over serial line
by Andreas Pirklbauer 20 Oct '17

20 Oct '17

> Again, it is easy to see how to use the code in > ORTool.DecObj to write a command to output a bootfile > in the format accepted by BootLoad.LoadFromLine. This is now done as command Builder.WriteStream in module Builder MODULE Builder; (* * Builder.Load M ~ # load (pre-linked) boot file M.bin onto boot area of the local disk * Builder.WriteCode M.rsc M.code ~ # extract code section from object file and write it to output file * Builder.WriteXilinx M.rsc 512 prom.mem ~ # extract code section from object file and write it as a Xilinx PROM file * Builder.WriteStream M.code M.stream bs adr ~ # convert input file to stream format accepted by BootLoad.LoadFromLine *) ... END Builder. at https://github.com/andreaspirklbauer/Oberon-building-tools -AP

1 0

FPGA - Boot over serial line
by Andreas Pirklbauer 19 Oct '17

19 Oct '17

> > Why not just write a new command, e.g. in ORTool, which outputs the > > prom.mem format directly? > > Good idea, will do :-) I have added such a command. It can be found at https://github.com/andreaspirklbauer/Oberon-building-tools The command is Builder.WriteFile contained in the file https://github.com/andreaspirklbauer/Oberon-building-tools/blob/master/Sour… The command can be invoked as ORP.Compile BootLoad.Mod ~ Builder.WriteFile BootLoad.rsc 512 prom.mem ~ However, I have no way of testing it. So if someone tests it and makes adjustments, pls let me know. -AP

1 0

FPGA - Oberon-0 program
by Tomas Kral 18 Oct '17

18 Oct '17

Hi, EDIT I wish to experiment with Oberon-0 programing, on bare RISC machine. As this is possibly, how FPGA platform was put to life. Oberon-0 program is a selfcontained executable that cannot import symbols from other modules. But how do I communicate with underlying hardware registers and memory, I need PUT, GET etc? These are flagged as error by the Oberon-0 compiler. -- Tomas Kral <thomas.kral(a)email.cz>

2 2

FPGA - Colour Support
by Tomas Kral 17 Oct '17

17 Oct '17

Hi, I have coded an initial version of B&W bitmaps for `Pepino' (some further improvements pending to push to git), now working on pictures. I wish to also make some progress with colour support. I have got these two mods for `vid.d' kindly provided by Magnus. // 3-bit colour wire vid_R, vid_G, vid_B; assign RGB = {vid_B, vid_B, vid_G, vid_G, vid_G, vid_R, vid_R, vid_R}; // 4-bit with colour map input [23:0] col0, col1, col2, col3, input [23:0] col4, col5, col6, col7, input [23:0] col8, col9, col10, col11, input [23:0] col12, col13, col14, col15, assign RGB = {color[23:21], color[15:13], color[7:6]}; The above would require `Display.Mod' be completely rewritten. I was therefore thinking of an implementation as described in the PO2013 chapter on Display, where there are three distinct bit planes, one for B&W, and the other two for colour. `Display.Mod' will work as is, and adding colour means to write to other colour planes. What do you think? How difficult is it to implement? Can it be made as memory efficient as 4-bit colour maps above? Many thanks so far. -- Tomas Kral <thomas.kral(a)email.cz>

6 38