April 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

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

03 May '18

Hi, Toying with `RPI Net server'. I can so far `semi-reliably' exchange single payload packets, only. When I try to exchange packets of multiple payloads, this is where things get interesting, as I have to try many times to push the whole packet through. Often `RPI' receives packets of bogus length bigger than 512, this is guarded by if-else, if ( (rx.hd.len <= MAX_PAYLOAD) && ..) else /* discard packet */ But even when discarded, still some parts of packet (headers) remain in the FIFO, that seems confusing next packet retransmission, leaving incorrect data in payloads. Even if try FLUSH_TX/RX to clear the FIFO queue, still communication is not reliable, especially when I try to send different messages, single payload followed by multiple payload ones. I realised NRF makes use of a FIFO, it keeps on queue the last three payloads. My understanding is that when FIFO is full, no other payloads can be written to. So one end must wait a little until the other reads out data to empty FIFO. This is possibly the trick of using some timing loops in the code. I needed to adjust some from 50ms to 5ms, to catch the transmission on RPI at all. Also I am not sure what happens, when automatic `ACK' is not received after all retries exhausted, or worst is missed. Is the payload with bad `CRC' or otherwise uncertain data freed from FIFO? After reading some more of the NRF specs, reading the code, I am not at all sure my understanding is correct. Many thanks. -- Tomas Kral <thomas.kral(a)email.cz>

4 7

Re: [Oberon] Texts
by peter＠easthope.ca 01 May '18

01 May '18

From: Treutwein Bernhard <Bernhard.Treutwein(a)Verwaltung.Uni-Muenchen.DE> Date: Mon, 30 Apr 2018 08:53:35 +0000 > hmm, the original format is well documeted in Wirth's Project Oberon > both in the original 1992 Edition (which is available with some edits > here: https://www.inf.ethz.ch/personal/wirth/ProjectOberon1992.pdf) > and in the 2013 Edition. In both editions it is Chapter 5. Yes, I have it, thanks. That ProjectOberon1992.pdf is in reality a 2005 edition. The title page has "Edition 2005". Although the differences 1992 => 2005 probably don't have a large impact on this discussion. > Of course there were extensions later and I do not know, if and which > of these are documented in the original Project Oberon, ... You meant extensions of functionality? I meant extensions of records such as "TextDesc* = RECORD (Objects.ObjDesc)". Project Oberon, Edition 2005, page 79 has this. Text = POINTER TO TextDesc; TextDesc = RECORD len: LONGINT; notify: Notifier END; My original message referred to Text in S3 and the Oberon subsystem of A2. Text* = POINTER TO TextDesc; TextDesc* = RECORD (Objects.ObjDesc) len*: LONGINT; (** Text consists of characters 0 to T.len - 1. *) obs: Objects.Library; (* Library containing objects located in text. *) trailer: Piece; org: LONGINT; (*cache*) pce: Piece END; These definitions are similar to the extent that both define Text. Beyond that quite different. Pieter Muller might have explained the motivation for the Object based definition in his thesis. Tips welcome of course. When there is time I can add the "Word" example for the earlier definition of Text. I didn't intend to start another flame war. Rather I'm trying to make some documentation helpful to novice J. Doe. Also to improve my own understanding. Thanks, ... 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

4 3

Texts; was "Re (2): byte vs. octet."
by Andreas Pirklbauer 01 May '18

01 May '18

> Ironically, Bernhard's observation that it was easier to ask someone than > sit down with the documentation, is exactly the criticism in chapter 1 of > Project Oberon, of the systems Wirth was using while on sabbatical in > California. In the late 1980s we even had cheat sheets for the various interclick combinations pinned to the whiteboard in the Ceres computer room at ETH. That tells you everything! When even CS students needs such a cheat sheet (because they forget the various interclick combinations from one week to the next) or, worse, when even the basic task of scrolling through a text document presents a challenge for some, you know there is something is wrong with the UI ;-) -ap

2 1

Re (2): Texts
by peter＠easthope.ca 30 Apr '18

30 Apr '18

From: =?utf-8?Q?J=C3=B6rg_Straube?= <joerg.straube(a)iaeth.ch> Date: Mon, 30 Apr 2018 18:50:20 +0200 > âÄTextâÄ is one of the fundamental base types of the Oberon system, > and unfortunately this base type differs a lot between the different > implementations of the Oberon system. OK, thanks. Transferring between systems will be a question of data structure in a file rather than data structure in memory. In principle a standard file format should be possible. I'm still thinking of data in memory rather than file storage. Might get to the file problem later. Regards, ... P. -- 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

1 0

Texts; was "Re (2): byte vs. octet."
by peter＠easthope.ca 30 Apr '18

30 Apr '18

In the last year or two someone wrote to the effect: one of the reasons Oberon never caught widespread attention and use is the Text rather than simple ASCII text. [I've searched the archives and not found the statement. Might have been a personal message. Anyone remember?] >From joerg.straube at iaeth.ch Sun Sep 10 09:52:38 2017 > The Oberon type ?Texts.Text? is more than pure ASCII text; e.g. it > contains font information not available in pure ASCII text. My understanding is only to the extent that MediaWiki.Markup and WikiMedia do a decent job of representing Oberon sources. Text involves several modules and several records. Some of the records are extensions. The complexity is formidable. Enough to deter too many novices. From: Paul Reed <paulreed(a)paddedcell.com> Date: Fri, 27 Apr 2018 00:19:49 +0100 > Is there a specific concern related to Oberon or its documentation? > I'd be interested to know where octets might have crept in ;-) I've added this section to the book. https://en.wikibooks.org/wiki/Oberon#Oberon_Text In a difficult subject, concrete examples can help. The first is a trivial Text containing the characters "Word". Additions, corrections and tips welcome. In this description either byte or octet should convey the idea. I don't know which is better. Thanks, ... 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

5 4

Re (2): byte vs. octet.
by peter＠easthope.ca 27 Apr '18

27 Apr '18

From: Bob Walkden <bob(a)web-options.com> Date: Thu, 26 Apr 2018 18:08:28 +0000 > It may be a national thing. Octet is French for byte. Pronouncing byte > the French way gives you, in French, a rude word for a certain part of > a gentlemanâÄs trouser-related anatomy. Perhaps the Swiss and other > French-speaking nations are a little embarrassed about it. From: Liam Proven <lproven(a)gmail.com> Date: Thu, 26 Apr 2018 18:16:00 +0000 > [2] Bytes are not always 8 bits. So byte can be ambiguous to the number of bits and octet is anatomically offensive. I don't understand European cultures well enough to judge the seriousness of the anatomical offense. Bad enough that the term is avoided in a classroom? Tolerable on a page or screen? Thanks, ... 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

3 2

Re: [Oberon] byte vs. octet.
by John R. Strohm 27 Apr '18

27 Apr '18

--- peter(a)easthope.ca wrote: > From: <peter(a)easthope.ca> > To: <oberon(a)lists.inf.ethz.ch> > Subject: [Oberon] byte vs. octet. > Date: Thu, 26 Apr 2018 11:02:26 -0700 > > Various computing related documents, including some Oberon documents > use "octet" rather than "byte". Appears the terms are synonymous. > Use of octet in computing is newer than byte? Is either term better > or preferable? Back in the Dark Ages, "byte" did not mean "8 bits". It meant "the smallest uniquely-addressable unit of storage". 6 bits was not unusual. 12 bits was not unheard-of. 8 bits happened. The venerable DEC-10 had variable-length byte load and store instructions, which came in handy for dealing with 7-bit bytes packed in a 36-bit word. When the ARPAnet work started, BBN chose to do everything in 8-bit chunks, and they needed a word that specifically meant 8 bits. They chose "octet". I first saw the word in the original Internet Protocol Handbook, ca. 1977 or so. --John R. Strohm

1 0

byte vs. octet.
by peter＠easthope.ca 26 Apr '18

26 Apr '18

Various computing related documents, including some Oberon documents use "octet" rather than "byte". Appears the terms are synonymous. Use of octet in computing is newer than byte? Is either term better or preferable? Thanks, ... 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

3 2