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

PARC for Android?
by eas lab 15 May '18

15 May '18

Aubrey McIntosh wrote:----- ]I bought a Logitech MX Ergo Plus trackball mouse at Fry's. ]This connect via WiFi or Bluetooth. ] ]... and with this mouse I connected to my Android phone, ] and a mouse cursor appears, ] and all 3 buttons appear to operate. ] ]I don't know how deeply, or what flavor of Unix Android is, ] I have never been able to get Hello World up and running. ] ]Nonetheless, I think the next step is to see if a bluetooth keyboard ]will also connect to the phone, ] and then to raise the question of moving S4 to the Android. Yes but, you mean V4 ? Peter Matthias wrote:----- ]Android uses Linux Kernel. ]OLR/ARM Linux runs, but is not compatible with Android runtime system. ]E.g. Android updates the framebuffer frequently so that OLR output on ]the framebuffer is overwritten. But if the display is incompatible with ETHO, are general Xorg programs not runable? BTW LNO is the only 32bit ETHO I can run on this 64bit Linux. For me: the 3 button mouse is essential. Testing the minature rPi with a HDMI-cable to the <public TV>; I tuned <ETHO> to work without transporting the bulky keybrd. It was completely viable with a pre-chosen token selection: menu. I'm surprised that no one here seems to have discovered `wily`: like ETHO also based on PARC, more extremely 3-buttoned that ETHO! Only when I need colors, for that extra dimension of comprehension do I use ETHO. BTW I've got the minimal-patch for the C-source, to restore wily's Left/Right -mouse scroll direction to our ETHO's. I'm writing this with wily now:- which wily == /usr/local/bin/wily ls -l /usr/local/bin/wily == ..507287 Oct 29 2017 .. Or did you read my post about functional/piping? ls -l `which wily` ==.. 507287 Oct 29 2017 .. --------------- Since some readers here, work down at the hex: bit / byte, and not just sales-clerk level, I'm looking for an explanation of how to get android <root access>. A 10inch REbranded tablet is given away here for 1K/12.5 = 1K/(100/8)=8K/100=US$80 ! Some of the blurb implied that it uses a multicore atom; Ie, X86. But I'm wondering how the several apps that I downloaded knew what architecture was needed. Or did I select. DL-ed gforth and busybox fail to run because of no <root-access>. With `ghostCommander` which tries to imitate the classical NortonCommander: I tried to locate the downloaded `busybox` and copy it to the SDcard, which when removed could set the permissions to be runnable from the SDcard -- hopefully. If busybox allowed me to: cd, ls, cp, chmod, ... maybe I could fly ? Also: cat `which wily` | head -1 | hexdump | head -2 == 0000000 457f 464c 0101 0001 0000 0000 0000 0000 0000010 0002 0003 0001 0000 a6b0 0804 0034 0000 Are these bytes X86 or ARM ? cat `which wily` | head -1 == .ELF ..../lib/ld-linux.so.2... Well of course this laptop is <WinTel>. BTW LinuxETH-Oberon is superior to wily, since it also runs *nix commands, giving you <literate programming> and it hasn't got the few bugs of wily. But G.F. the author has abandoned it -- LEO doesn't run on 64Bit. == crg PS. when I ask if the <bytes are ARM or X86>, I mean eg. at the MBR-start, where the raw-CPU executes, by fetching and executing words; not as packaged for the OS.

1 0

TextDesc. Another clarification.
by peter＠easthope.ca 13 May '18

13 May '18

In the Project Oberon books, TextDesc is specified twice. At the beginning of section 5 the private fields are omitted. They appear only well into section 5.2. From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of peter at easthope.ca Sent: Friday, May 04, 2018 4:15 PM > Martin Reiser's _The Oberon System_, page 139 has this. > TYPE > Text = POINTER TO TextDesc; > TextDesc = RECORD > len: LONGINT; > notify: Notifier > END; Exactly the same in _Project Oberon_, (1992) Edition 2005, "5.1, Text as an abstract data type", page 79. Then in "5.2 Text Management", page 87, "We shall now illustrate the piece technique at the example of two important but basic operations: Insert and read. Let us start with an overview of the data types involved. Apart from some auxiliary private variables marked with an arrow, the types Text, Buffer, and Reader are already familiar to us from the previous Section. Type Piece is completely private. It is hidden from the clients. Text = POINTER TO TextDesc; Notifier = PROCEDURE (T: Text; op: INTEGER; beg, end: LONGINT); TextDesc = RECORD len: LONGINT; notify: Notifier; -> trailer: Piece; -> org: LONGINT; -> pce: Piece END;" _Project Oberon_, 2013, page 62. "Text = POINTER TO TextDesc; Notifier = PROCEDURE (T: Text; op, beg, end: INTEGER); TextDesc = RECORD len: INTEGER; notify: Notifier; -> trailer: Piece; -> org: INTEGER; -> pce: Piece END;" In S3 and the Oberon subsystem of A2, "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;" >From Peter de Wachter's emulator, "MODULE Texts; (*JG 21.11.90 / NW 11.7.90 / 24.12.95 / 22.11.10 / 18.11.2014*) ... TextDesc* = RECORD len*: LONGINT; changed*: BOOLEAN; notify*: Notifier; trailer: Piece; pce: Piece; (*cache*) org: LONGINT; (*cache*) END;" From: "Skulski, Wojciech" <skulski at pas.rochester.edu> Date: Fri, 4 May 2018 15:24:40 +0000 > One of the most confusing aspects of Oberon is the multitude of > Oberon languages, modules, and systems, all referred to by the same > names like Text. All of these Oberons have the private fields trailer, org and pce. Apparently omitted from the TextDesc at the beginning of section 5 as an instructional strategy. The biggest difference to understand here is TextDesc being an extension of ObjDesc in S3 and A2 Oberon, versus notifier usage in other Oberons? >From chris at cfbsoftware.com Wed May 9 15:43:27 2018 > I recommend that you use the latest sources of Project Oberon 2013 from Prof > Wirth's page as the starting point to build your version of the system. The jury has conclusively discarded Objects? 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 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

FPGA - System Crash
by Andreas Pirklbauer 13 May '18

13 May '18

> May I ask for the reason to use GitHub like that? > Hellwig Oh. No particular reason. I have a bunch of scripts that I haven’t had time to change yet.. maybe I followed the approach of projectoberon.com (which only has one version) at one point, but I simply can’t remember. would you prefer if I just used git add, followed by git push so the full history is preserved?

3 3

FPGA - Compiler revisions
by Tomas Kral 12 May '18

12 May '18

Hi, As part of my system recovery, I noticed I have newer versions of ORP and ORG to PO2013 web and git. MODULE ORP; (*N. Wirth 1.7.97 / 4.4.2017 MODULE ORS; (* NW 19.9.93 / 20.3.2017 MODULE ORB; (*NW 25.6.2014 / 19.4.2017 MODULE ORG; (* NW 18.4.2016 / 4.4.2017 I must have travelled in time? -- Tomas Kral <thomas.kral(a)email.cz>

2 1

Re: FPGA - System Crash
by peter＠easthope.ca 12 May '18

12 May '18

From: Tomas Kral thomas.kral at email.cz Date: Sat May 12 09:35:59 CEST 2018 > Also I was given a code some time ago to access ISO partition, it > probably comes from other Oberon system. Need to find that source > again. https://en.wikibooks.org/wiki/Oberon/Oberon#Sources_in_the_Oberon_subsystem… https://en.wikibooks.org/wiki/Oberon/Oberon.ISO9660Files.Mod https://en.wikibooks.org/wiki/Oberon/Oberon.ISO9660Volumes.Mod 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 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

FPGA - System Crash
by Andreas Pirklbauer 12 May '18

12 May '18

> Yes, this would help indeed. Ok. Will do so from now on for the various tools and also for Experimental Oberon. > I wrote a C version of ORC.Mod, in order to easily connect to either my own RISC5 > simulator (via pseudo-tty) or to the real FPGA board. Nice. Is THM-Oberon, i.e. the port of Oberon system to Terasic's DE2-155 FPGA development board for educational purposes? > So whenever I see a new "first" commit of your software on GitHub, I download it and do a "diff"... :-) In the future you can just do a git pull and git diff ;-) > Thanks again for putting so much work into Project Oberon. Hellwig I started some of it in 1988-90s at ETH. Most of the code was simply brought forward to (and adapted for) the 2013 edition, either from a Ceres implementation or an earlier Modula-2 version of it. Today it’s just a hobby.. -ap

2 1

FPGA - System Crash
by Andreas Pirklbauer 12 May '18

12 May '18

> And, much more importantly than me, Jurg Gutknecht. > But I thank you too, for your experiments, insights and support! > Cheers, > Paul I guess I was referring to the 2013 revival effort, where your efforts have been instrumental. But yes, Jürg Gutknecht is of course to be credited for programming the entire text, font and viewer complex in the original 1988 system, among other things (and he was a great teacher too.. I learned about text editors using Lara) -ap

1 0

FPGA - System Crash
by Andreas Pirklbauer 12 May '18

12 May '18

> > Thanks again for putting so much work into Project Oberon. Hellwig > > I started some of it in 1988-90s at ETH. Most of the code was simply brought > forward to (and adapted for) the 2013 edition, either from a Ceres > implementation or an earlier Modula-2 version of it. Today it’s just a hobby.. > -ap PS: Just to be clear.. and also to give credit where credit is due: Project Oberon (www.projectoberon.com) is NOT my work. It’s the work of Niklaus Wirth and Paul Reed. I only added bits and pieces to it that some may find useful. -ap

2 1

FPGA - System Crash
by Andreas Pirklbauer 12 May '18

12 May '18

> Could it also fail on blank card? > It does some init of the root directory. > > PROCEDURE Init*; (*initialize the file system if needed*) > VAR a: FileDir.DirPage; > BEGIN Kernel.GetSector(FileDir.DirRootAdr, a); > IF a.mark # FileDir.DirMark THEN > a.mark := FileDir.DirMark; a.m := 0; a.p0 := 0; > Kernel.PutSector(FileDir.DirRootAdr, a) > END > END Init; > Several comments: 1. You may want to get the latest version of the Oberon system building tools from: http://github.com/andreaspirklbauer/Oberon-building-tools 2. The above procedure ‘Oberon0.Init’ does what it is supposed to do, i.e. if the pre-linked binary file Oberon0.bin (containing the six modules Kernel, FileDir, Files, Modules, RS232, Oberon0) is downloaded over the serial line to the target system for the very first time (i.e. onto the bare metal after the target system has been rebooted over the serial line), the file system of the target system is initialized. 3. If it is downloaded again, the file system already exists and contains whatever previous builds have left behind. In that case, no action is taken. But one can always execute the command ORS.SR 101 ~ on the host system to clear the file system on the target system again. See the following tool text for the correct execution order: http://github.com/andreaspirklbauer/Oberon-building-tools/blob/master/Sourc… HTH -ap

2 1

FPGA - System Crash
by Andreas Pirklbauer 12 May '18

12 May '18

> Yes, true. This where the boot fails, also Oberon-0 never gets to > the command loop, as it fails on a corrupt file system. > > Could it also fail on blank card? > Well, if the file data itself has been corrupted, one can use the tools ‘DiskCheck' and ‘Scavenger’. But the Oberon-0 command interpreter should not fail to execute even if the disk is corrupt. I may add ‘DiskCheck' and ‘Scavenger' to the system building tools if there is demand for that. But I didn’t see the need for that because with SD cards is easy to make a backup of an entire SD card - so THAT is your recovery tool --> just make regular backups... PS: If you are familiar with the way B-trees work, you can build those tools yourself. It would make for a nice student exercise. They are just variations, or rather, extensions of Oberon-0: 1. DiskCheck essentially adds a "directory traversal” command which lists faulty directory sectors 2. Scavenger essentially adds a command to scan the entire disk and gradually builds up a new directory. This allows one to recover files that are no longer accessible from the directory. -ap

1 0