February 2021 - Oberon - mailman3.inf.ethz.ch

Re (2): Re (2): Starting V4.
by peter＠easthope.ca 04 Feb '21

04 Feb '21

Joerg, From: =?utf-8?Q?J=C3=B6rg?= <joerg.straube(a)iaeth.ch> Date: Wed, 3 Feb 2021 22:14:40 +0100 > In PO, the file „System.Tool“ is opened in System.OpenViewers (this is hard coded) Thanks. > In V4, the file „System.Tool“ is opened in System.Init. If valid > commands exist in the file „System.InitCommands“, then these > command are executed instead. Here I have V4 1.7.02 in Debian Linux. http://olymp.idle.at/tanis/oberon.linux.html Neither System.Init nor System.InitCommands is present. Also no Oberon.Ini, although a copy from the Windows release was sent to me. Appears that some bolts were omitted when 1.7.02 was assembled for Linux. I'll aim to find, install and execute an earlier version. Might find more there. Ideally, I should make a complete release and put it on Sourceforge. The opportunity might be some time in the future. =8~/ Thanks for the help, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

2 3

Re (2): Starting V4.
by peter＠easthope.ca 03 Feb '21

03 Feb '21

As installed, Native ETH Oberon and the Oberon subsystem in A2 have command "System.Open System.Tool" in Oberon.Text > InitCommands. If Oberon.Ini in V4 is the analogue of Oberon.Text in ETH Oberon I expect to see "System.Open System.Tool" in Oberon.Ini. Not there. Nevertheless System.Tool is opened. Has anyone found "System.Open System.Tool" Thx, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

2 1

Re: [Oberon] SYSTEM.COPY (was: Compiler behaviour for a32 := a8)
by Chris Burrows 01 Feb '21

01 Feb '21

> -----Original Message----- > From: Hans Klaver [mailto:hklaver@dds.nl] > Sent: Tuesday, 2 February 2021 12:10 AM > To: Chris Burrows; ETH Oberon and related systems > Subject: Re: [Oberon] Compiler behaviour for a32 := a8 > > Chris wrote: > > > Note that SYSTEM.COPY is now provided to efficiently copy n words > from > > an array of one type to another of the same or different type. > > I would consider it an abuse of SYSTEM.COPY to use it for assignment > of one variable of an anonymous ARRAY len1 OF CHAR type to a variable > of another anonymous ARRAY len2 OF CHAR, and using it would be > unwieldy and unhelpful: > - unwieldy because it would involve several SYSTEM-dependend type > casts, > - unhelpful because it would not warn for string truncation. > I'm sorry - I should not have mentioned it as it only adds to the confusion. It might conceivably be useful if a character array being copied was being used to contain data that did not represent a null-terminated string. Whatever, SYSTEM.COPY should only ever be used with *great* care and only in cases of extreme need. No type casts are required as the definition is COPY(src, dst, n) where ALL of the parameters are INTEGER. Hence, arc and dst would need to be the addresses of the data (e.g. obtained using SYSTEM.ADR) and n would need to be specified as no greater than the number of words in the smaller of the two items to avoid any nasty problems. The only example of its use that I can find in Project Oberon is in SCC.SendPacket: SYSTEM.COPY(SYSTEM.ADR(head), SYSTEM.ADR(payload), HdrSize DIV 4); Regards, Chris Burrows CFB Software https://www.astrobe.com/RISC5

1 0

Re (2): Oberon V4 on the Raspberry Pi?
by peter＠easthope.ca 01 Feb '21

01 Feb '21

>From oberon at wildwein.de Mon Jan 11 16:58:16 2021 > Native Oberon was also called S3 (but never V3) and S3 was later renamed ro ETH-Oberon On Tue, 12 Jan 2021 06:38:22 +1030 "Chris Burrows" <chris(a)cfbsoftware.com> wrote: > "Native Oberon is one platform of what was originally called Oberon > System 3 (S3 - it was never called V3) and was later renamed to > ETH-Oberon. Sorry to stress detail but official documents don't hyphenate. Beta/alpha FAQ https://en.wikibooks.org/wiki/Oberon/ETH_Oberon/newfaq#numbering General questions, 2. '... we have renamed "Oberon System 3 " to "ETH Oberon ...' White Paper https://en.wikibooks.org/wiki/Oberon/ETH_Oberon/white "ETH Oberon" is in the title and throughout the document. Regards, ... P. L. -- Tel: +1 604 670 0140 Bcc: peter at easthope. ca

1 0

Re: [Oberon] SD Card File Exchange
by Chris Burrows 01 Feb '21

01 Feb '21

> -----Original Message----- > From: Skulski, Wojciech [mailto:skulski@pas.rochester.edu] > Sent: Monday, 1 February 2021 3:49 PM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Re: [Oberon] SD Card File Exchange (was: Why is RSC string > data word-aligned?) > > Chris: > > >"HCFiler - An efficient embedded SDHC FileSystem" > >https://www.astrobe.com/forum/viewtopic.php?f=4&t=534 > > I know. It is great! > > >Copying files from Windows using HCFiler has not been a high > priority > >for me as nobody apart from you has asked me for it to date. Is > there > >anybody else here who is interested? > > I would ask an opposite question. Why the RISC5 OS should not adopt > the HCFiler as an official file system? > There are many reasons why it is not suitable as the file system for RISC5 OS. For starters it is sequential access only - not random access. Think of it as like writing data to a tape drive. It is designed to be used to stream continuous data to / from the SD card, such as might be used in a data-logging application. Hence it is useful for transferring files from one system to another or for backing up a set of files, but could not be used, for example, with a text editor. Chris

2 1

Re: [Oberon] SD Card File Exchange (was: Why is RSC string data word-aligned?)
by Chris Burrows 01 Feb '21

01 Feb '21

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Skulski, Wojciech > Sent: Monday, 1 February 2021 7:00 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Why is RSC string data word-aligned? > > From my user perspective the file system speed optimizations are not > even secondary. I would rather want to see a convenient file exchange > between the RISC5 Oberon and Windows workstations. I would like to > plug the Oberon SD into an SD card reader and easily copy files under > Windows, from the V4 directory to the SD and vice versa, using the > usual Windows drag and drop. I would like to do the same between the > Oberon SD and the emulator. > As you are aware, our HCFiler (high-capacity) software allows you to plug the Oberon SD card into an SD card reader and copy files to Windows. For the benefit of others, the original announcement is here: "HCFiler - An efficient embedded SDHC FileSystem" https://www.astrobe.com/forum/viewtopic.php?f=4&t=534 The source code that is available to copy the files from the Project Oberon partition to the HCFiler partition (ALL of the SD card, no matter how big) is available. It would not be difficult to adapt this to copy files from Windows to the Project Oberon partition. I would recommend using Gardens Point Component Pascal as the compiler to do this: https://www.cfbsoftware.com/gpcp GPCP and CPIde is what I use daily for all of my Oberon development under Windows 10. > I would like to use the entire SD card rather than a small portion of > it. I do not mind "partitions", if partitions are visible and easily > used under the emulator, the Windows host, and the Oberon > workstation. > I would like to add Linux and Mac to the list of hosts, > though I am not using either. > I'll leave it to others to recommend solutions for emulators and Linux and Mac. > Present PC link is fine for small files or for the SW development. > But it is not great for massive file exchange between Oberon and > hosts, or Oberon and emulators. > Copying files from Windows using HCFiler has not been a high priority for me as nobody apart from you has asked me for it to date. Is there anybody else here who is interested? > Concerning the speed under the Oberon, a boost would be provided with > the QSPI interface rather than the present SPI interface. Point me to documentation on how to access SDHC cards using QSPI and I'll look into it. I was only aware of MMC as a faster access method. If anybody has any experience of using MMC with RISC5 I'd be very interested. Regards, Chris Burrows CFB Software https://www.astrobe.com/RISC5

2 1

List of extensions for Project Oberon compiler
by August Karlstrom 01 Feb '21

01 Feb '21

Does anyone know if the language extensions that the Project Oberon compiler provides in relation to the Oberon report (from 2016) is documented somewhere? I'm thinking of features such as dynamic arrays and structural equivalence of arrays used in assignments. -- August

5 9