May 2018 - Oberon - mailman3.inf.ethz.ch

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

Interfaces; was Texts
by peter＠easthope.ca 12 Jun '18

12 Jun '18

From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> Date: Tue, 1 May 2018 11:25:32 +0200 > So at least for that task, no more cheat sheet was needed. Good! Ideally a system is self-contained; minimally dependent upon external documentation. How often does a person using a smartphone or tablet consult a manual or sticky note? > But I havenâÄt found a satisfactory solution yet for some of the > other operations (e.g., copy-to-caret, copy-looks) other than adopting > Ctrl-C/Ctrl-V/Ctrl-X. Any implicit or invisible command is problematic. The best possibility I've imagined is a small floating viewer displaying core commands. Similar to the popup menu of ET but remaining open continually. Aspect ratio similar to the screen rather than tall and narrow. It would track the mouse as the arrow does in extant Oberons. It would have an arrow point and hotspot somewhere on the perimeter. This "command viewer" would be wide enough for the familiar commands "Insert Execute Select" corresponding to the three mouse buttons, left, middle, right. A click of a mouse button would activate the corresponding command. The left button would set insertion at the hotspot, the middle button would execute the command under the hotspot and the right button would select at the hotspot. Similar to the existing interface but with implicit commands legible in the moving command viewer. This command viewer would be scrollable to accomodate arbitrary text. The installed form would include core commands and text editing. On a desktop or laptop machine, two mice would allow movement of the command viewer independent of scrolling. Also achievable with one mouse and small complications in protocol. With a touchscreen, movement and scrolling would work more neatly. The text of the command viewer would be editable just as any other text. Any command could be added to the command viewer. A command in a track viewer would execute as in extant Oberons. This interface would allow some interesting simplifications. ScrollUp and ScrollDown commands could deprecate vertical scroll bars on track viewers. The menu bar would need only the name. Familiar commands "System.Close ... Edit.Store" could be in the command viewer rather than the menu bar. Character insertion and other text editing can also be performed via the command viewer. With the viewer tracking an insertion point, characters would be inserted from the command viewer by clicking mouse buttons. Hence the keyboard would be redundant. (A keyboard would continue to work but not be essential.) Again, two mice would be more efficient than one. A touchscreen even better. I can't imagine any simpler way of activating various commands on various data with all commands and data visible. The concepts allow integration of a touchscreen interface and the traditional Oberons. Nothing really original but combining established features in a new way. I've implemented a second mouse controlling a left pointer. Not the command viewer yet. The Wikibook has priority for now. Regards, ... Lyall E. -- This message was composed and transmitted by software designed to avoid the need, overhead and vulnerability of antivirus software. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

2 1

FPGA - nRF24L01 `RPI Net' server
by Tomas Kral 12 Jun '18

12 Jun '18

Hi, `NRF' now generally works between Oberon and RPI. RPI to Oberon transfers twice as fast to the opposite direction. I thought, perhaps in one direction packets are retransmitted, but has proved I sent each packet once in both directions. Could it be on account of different file subsystems speeds among platforms, then? This is an exercise I used, showing packet retries when ACK is missed, each packet forced to send twice. Net.ReceiveData() VAR ... cnt: INTEGER BEGIN ... cnt := 0; IF (head1.typ = seqno) & ODD(cnt) THEN ... ELSE END; INC(cnt); ... END ReceiveData; valid header 65 15 92 238 Test.Mod sending 16 0 92 238 512 17 0 92 238 512 17 0 92 238 128 18 0 92 238 128 640 -- Tomas Kral <thomas.kral(a)email.cz>

4 17

FPGA - nRF24L01 `RPI Net' server
by Tomas Kral 25 May '18

25 May '18

Hi, I have recoded Net.ReceiveHead() slightly. ... (*IF ~head1.valid & (Oberon.Time() >= time) THEN head1.typ := 0FFH*) END UNTIL head1.valid OR (Oberon.Time() >= time) (*head1.typ = 0FFH*) END ReceiveHead; Once the loop falls through on timeout, it keeps `0FFH' in buffer, making it return immediately before `time' lapses in all subsequent calls. Also `0FFH' message type is reserved for broadcast, correct? -- Tomas Kral <thomas.kral(a)email.cz>

2 7

Error handling in Oberon procedures/functions.
by Srinivas Nayak 24 May '18

24 May '18

Dear All, Which is the Oberon best practice of handling errors in procedures/functions? I think, this small and nice paper sets my context well. "Faults in functions, in ALGOL and FORTRAN" by I. D. Hill https://academic.oup.com/comjnl/article-pdf/14/3/315/1165251/140315.pdf With thanks and best regards, Yours sincerely, Srinivas Nayak https://srinivas-nayak.blogspot.com

2 1

FPGA - nRF24L01 `RPI Net' server
by Tomas Kral 22 May '18

22 May '18

Hi, I am now able to send and receive files with `RPI'. I needed to change `RF24::Write()' method that now hopefully does same as `SCC.SubSnd'. I do not get duplicates, while I get 100% ping. I still have a few question, though. `SCC.ResetRcv' SYSTEM.PUT(SYSTEM.ADR(rx), 0); Is the same meaning as rx.hd.valid := FALSE ??? `Net.'Sendfiles' S.nextCh = ":" THEN (*prefix*) What is the use of prefix? Also user/pswd is appended to the message, with no apparent purpose. Many thanks. -- Tomas Kral <thomas.kral(a)email.cz>

3 7

Small effort to add functional/piping ability ?
by eas lab 20 May '18

20 May '18

I've raised this point before, under the subject of functional-programming; since the method of getting an answer by passing the data through multiple stages is the essence of functional programming. ETHO already uses this extensively, except that it's not yet automated: the output/s go to ScreenFrames, which can be marked as the the input. to the next stage of the <pipe>. A somewhat contrived example is solving the intolerable situation that ETHO doesn't show you the most recent files of a directory. Imagine having a directory of 88 files, some of which are 2 years old, and you want to continue with the project that you last worked on. 3 days ago. Obviously you want immediate access to the most recent [say 6] files which you <left on top of the work pile>. System.Directory ^ Linux:*\d gives eg:... Linux:Browser.Mod 19.05.1970 01:02:17 38540 Linux:C.Tool 04.05.2017 09:31:44 4372 Linux:Clipboard.Obj 04.11.2012 11:13:15 6677 Linux:CmprFiles 24.08.2017 21:00:37 1289 ... Under linux I've found that the most convenient listing format is: FileSize : FileName 1454 : NeedPiping 49174 : oberon.log 1105 : NeedPiping.Bak 10485760 : oberon100321.dsk 1964988 : noname.eml 678 : oberon.cnf 48055 : HrOrderFuncts .... and I vaguelly remember using ETHO's existing *FUNCTIONS* to do: 1. put the 2nd field to the front. == 24.08.2017 Linux:CmprFiles 21:00:37 1289 2. rearange the date-strings. == 2017.08.24 3. sort the System.Directory lines using ETHO's existing function. == file listing in recentcy order 4. output only the Size & Name fields. == just show the size and FileName So that's a 4stage-pipe. The great advantage of functional/piping is the extreme modularity: at any/every stage:N you only need be concerned about the output of stage:N-1 and stage:N. Nothing else need be considered. Since ETHO already uses the manualy repeated 2 stage loop: 1. Put Output:N-1 to <F1 marked Frame> 2. Take <newly F1 marked Frame> as input to pipe-stage-N: why can't we modify/extend this to be able to have a syntax eg: <pipeSequenceCommand> <Argument> ? eg. Pipe.ListRecentcyOrderedFiles /sdc2/CRG/LNOspare/ Also our ET.Mod already can execute a sequence of M.P. Adding the ability to have the text of stageN be the input of stage(N+1) would give us functional/piping ability. == crg

4 4

FPGA - nRF24L01 `RPI Net' server
by Tomas Kral 18 May '18

18 May '18

Hi, I have made some progress. I am able to transmit packets of multiple payloads. The trick seems in adjusting time loop constants in various places, plus delays and retries. The setting slightly differs between `PI' and `Oberon', having no exact explanation, except that each platform runs at different speed. This may brake compatibility though with other `Oberon' station nodes, as I have only one `FPGA' board and one `PI' this may not be an issue. 4.7uF decoupling caps removed for now. I can try to add other functionality to `Net.cpp' server, as I hope for being able to transfer files in the end when proved possible. -- Tomas Kral <thomas.kral(a)email.cz>

5 21

FPGA - nRF24L01 `RPI Net' server
by Tomas Kral 15 May '18

15 May '18

Hi, I am now trying to process 'SND' message. I got as far as transmitting a test file that spans 512 bytes so two packets need be send. --- Header valid header 65 14 31 51 Test.Mod sending --- Payload (1) status 32 14 the above tells TX_DS(status 32) data sent ACK received, count down 15-1=14 --- Payload (2) status 16 status 16 status 32 12 This tells MAX_RT(status 16) max retries exceeded twice, flush TX_FIFO each time, count down 15-1-1-1=12 and retry until TX_DS (status 32) data sent ACK received Now comes an interesting part. The second payload did not pass twice CRC check at the receiver, no ACK received, the receiver should not store in the RX_FIFO. Only after third try. But the payload is read three times, twice with bad CRC, once with good one???? It seems auto-acknowledgement does not work exactly as documented. Bad CRC payloads should not be stored in RX_FIFO, but they are!!! Possible??? -- Tomas Kral <thomas.kral(a)email.cz>

1 0