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

Mouse chording?
by eas lab 16 Feb '16

16 Feb '16

Previously I've mentioned wily: the public domain version of Plan9's copy of ETHOberon. Unfortunately wily's Left/Right mouse is reversed w.r.t. TextFrame:Up/Down. I've patched the C-code on my X86 version to be like ETHO. My rPi version, which I use less often is still <reversed>. Like ETHO, wily uses Middlekey to execute. My current mouse is especially problematic, since mouse:M is not atomic. Ie. it may be: M down, cursor move while down, M up. Vaguely I had the idea that ETHO captured M on the up-stroke, thus. eliminating this problem. Is this the case? Interestingly the rPi seldom has the problem. But that's for the same reason that old-Turbo-Pascal can't run on new hardware, which is too fast for the particular quirk, that relied on delay/s. It seems that wily is trying to be too smart: whereas ETHO knows <M on a token/P.M>, wily also knows M-down, wipe the string-of-tokens, M-up. I'd prefer to sacrifice the <wipe the string-of-tokens> facility, to get better reliability [fortunately, like ETHO: bad commands are immeditely indicated]; but I fear that there are complexities which I'm not aware of. Is the original mouse chording scheme/theory documented ? Is there any obvious problem in replacing the: M-down, wipe string, M-up, with LMR-down, wipe string, LMR-up ? == Chris Glur. .. ]The 2013 edition of Project Oberon, running on an FPGA board such as the ]OberonStation, is a working and available example of a system built ]entirely from scratch with the express objective of making it easily ]explainable and understandable in all aspects. ] ]And if you really want to understand something, you have to try changing it. == The ability to modify and observe the results, is the essence of SCIENCE. A football, a hoola-hoop, a diamond are not very modifiable/programable. Stuff that you buy is yesterday's [3rd world] story. Today's [1st world] story is health and knowledge. What do medical surgeons use to train on these days ?

1 0

Re: [Oberon] RISC.img format
by peter＠easthope.ca 16 Feb '16

16 Feb '16

>From chris at cfbsoftware.com Sun Feb 14 21:28:09 2016 > Download the three PDF files that make up the Project Oberon book > ('Book Chapters x-x') from: > > http://www.projectoberon.com/ > > The file system is described in Chapter 7. Right oh; ProjectOberon.System.pdf has been on my XO 1.5 for over a year. Read chapter 7 long ago. As luck would have it, reread most of chapter 7 shortly before posting my question. From: Paul Reed, paulreed at paddedcell.com, Sun, 14 Feb 2016 20:31:18 +0000 > What is a LONGINT in Oberon-88, is an INTEGER in Oberon-07 > (which is 32-bit). > ... > What is an INTEGER in Oberon-88 ... Thanks Paul. I returned to the 2013 preface, page 5, and reread this sentence. "1. The data types LONGINT, SHORTINT, and LONGREAL have been discarded, and with them the concept of type inclusion." I deduce that implementation of the Native Oberon AosFS in Oberon 2013 is entirely possible but would require juggling to handle 16 bit integers (required in AosFS) in a language which provides 32 bit, but not 16 bit, integers. >From chris at cfbsoftware.com > You do not have to decipher source code or try to read the minds > of the developers to find answers to questions like these. With absolute respect Chris, the answer to my question must be obvious to you. Whereas I simply don't have adequate familiarity with the details to immediately recognize that representation of integers has constrained the implementation of the FS. Even after reading Paul's reply, thinking was necessary. Definitely I admire your agility in the subject. Trivial observations from this discussion. * Independent standards have benefits. In this case, a specification of the 2013 FS, independent of the 2013 language or system, would facilitate implementation in another system. In Native Oberon for example. * Hypothetically, a solution to the "data transfer problem", mentioned by Wojtek, is an implementation of a FAT FS in Oberon 2013. Similar to FAT in Native Oberon. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Accessing Oberon RISC5 files on other computers
by skulski＠pas.rochester.edu 16 Feb '16

16 Feb '16

Chris and Joerg: I wrote: > I want to insert the Oberon-formatted SD card into the PC > and I want to see the directory. Chris answered (Joerg wrote something similar): > You can write software that will do that. Maybe I was not clear. I am thinking of instruments (oscilloscopes or digital cameras) which write something to a floppy, a USB drive, or an SD card. The user then takes the card, s/he inserts it into a Windows or a Mac, and a directory opens with the files. The user *can* write software, but the user does not *have to* write software to read the photographs from the camera. If writing software was a requirement then the user would return the camera to the store and the manufacturer would go bankrupt. So where do we stand with Oberon System, if it is to be used to develop some products (as opposed to being used to develop itself)? Well, in 1985 compatibility was not an issue. But now we live in 2016 and there are all these other computers around. These days a product should write to a well formatted drive which can be taken to Windows or Mac, inserted into a slot, and be usable without programming with the Garden Points compiler, a RISC5 emulator, or whatever. Does it make sense? Wojtek

3 2

Re: [Oberon] Accessing Oberon RISC5 files on other computers
by skulski＠pas.rochester.edu 16 Feb '16

16 Feb '16

>> The user >> *can* write software, but the user does not *have to* write software >> to read the photographs from the camera. >Sorry - my mistake :( I thought you were asking the question with yourself >as the product developer not an end user. Chris: I have to define my mission. It is "development of instruments for the nuclear science". I have to draw a line somewhere and define my "component base". Components are parts that I adopt to build my instruments. I cannot go as deep as developing my own transistors, compilers, or operating systems. I have to stop somewhere. To me, an ability to write data to SD and then to take this SD and see the data under Windows the usual Windowish way is a "component" which I need. Developing *this* is outside of my mission. If I do not define my mission in a sensible way then I will not get anywhere. Wojtek

1 0

Inexpensive Hardware: Cost vs Objectives
by jwr＠robrts.net 16 Feb '16

16 Feb '16

Summary Statement: The various hardware platforms supporting Oberon were designed with different objectives in mind, and differ in what purposes they support most effectively. Each of us must identify our own goals and objectives, and select the hardware platform(s) which meet our own objectives most cost-effectively. One person may favor minimal total cost, another may favor features which facilitate study of Project Oberon, yet another also wants to learn about hardware interfacing or FPGAs in general, and still others desire to use it for additional applications such as embedded control or Retrocomputing. There is no single "right" answer which applies to everyone: our various goals determine which particular hardware is most appropriate for each of us, and therefore provides the "best value" for what we wish to accomplish. This message is intended to draw together and respond to some of the ideas in the threads titled: Apples vs Oranges oberonstation vs. a [$5/]$9 computer oberonstation questions, ps/2? Train VS all terrain truck hardware cost In concluding his message at http://lists.inf.ethz.ch/pipermail/oberon/2016/008922.html, Paul Reed asks "Can we please talk about something else now? Thanks." Yes, we can and will. But with apologies to Paul, I believe that there remains some value in saying a bit more, to put the recent interactions in better perspective. I apologize to all that my response isn't more succinct. A central issue in much of the recent discussion involved the cost and complexity of various hardware configurations, and questions related to why not use less expensive or more modern hardware? In my view, the proper response was never stated fully: there are multiple different goals and objectives involved, and by design each of the hardware platforms satisfies those goals differently, at differing price-points. Each of the hardware platforms was intentionally designed to satisfy particular goals, and does not satisfy other goals (such as very low cost, or use of the most modern and flexible keyboard or mouse or SD-card formats) quite as well. So each of us must take our own goals and objectives into account, when choosing among the various hardware options available, and evaluating which one(s) provide the "best value" with respect to our own purposes. When Dr. Wirth and Paul Reed ported Project Oberon to an FPGA-based implementation, they had multiple objectives. Among these were to make details of both the hardware and software very clear and understandable, to keep the entire system as simple as practical, to enable highly effective educational use of the system to teach both software and hardware topics (at the university level), and to protect against future obsolescence using an FPGA-based RISC5 CPU implementation. They specifically chose NOT to use an inexpensive existing CPU (such as ARM) because they correctly recognized that in the near future, ANY particular CPU version they chose would become obsolete and unavailable. They chose a particular Digilent FPGA Starter Board using a Xilinx Spartan 3 FPGA as an appropriate platform for their initial implementation, based on the features it offered for what they needed to accomplish at the time. Digilent and Xilinx designed that board not to minimize cost, but rather to provide a wide range of capabilities to enable experimentation with and demonstration of the full range of capabilities of the Spartan 3 FPGA chip. It was not designed to run Oberon: it was designed to be a very flexible FPGA development board. It accomplished its key marketing purpose: providing a demonstration and development environment for persons implementing FPGA designs using that particular Spartan chip, to enable high-volume sales of that chip. The board has since been discontinued and replaced by development boards supporting newer and more complex Xilinx FPGAs. When that Digilent starter board was discontinued, Project Oberon was ported to other boards. Magnus Karlsson ported it to the Pipistrello with an Oberon Wing, and later implemented the customized Pepino. Both the Gadget Factory's Papilio and Saanlima's Pipistrello are designed for beginners to learn FPGA development, and for implementing certain types of applications including Logic analysis (ie Open Bench Logic Sniffer) and Retrocomputing. They are designed to an appropriate cost and feature set for those applications, not to minimize the cost of an Oberon implementation. Additional features (particularly fast static RAM, and PS/2 keyboard and mouse interfaces) had to be added at additional cost to support Oberon. Paul Reed and Victor Yurkovsky designed the OberonStation to provide a "minimal" Spartan 3 FPGA development board which contained all features needed to support a clean and complete port of the Project Oberon code from the Digilent Spartan 3 Starter board. It contained the 8 LEDs in a row, the static ram required, the keyboard and mouse interfaces, the microSD card interface, the RF network port, etc. which were formerly available using the Digilent board. I suspect that they also had other goals not yet realized, involving possible use of this hardware for Retrocomputing or other FPGA-based applications, due to the presence of pads for an as-yet-unpopulated expansion connector. Note here my understanding of the goals for the OberonStation: it is NOT intended to be a minimal-cost Oberon implementation, rather, it IS intended to be a "minimal" hardware implementation which supports all the important features for Project Oberon, which were supported on the discontinued Digilent board, at a lower cost than other FPGA development boards which support more than those necessary features. It ALSO supports more general use as an FPGA development platform for certain types of applications such as Retrocomputing. In the same timeframe, Chris Burrows ported AStrobe to target the RISC5 FPGA-based CPU, in both "workstation" mode such as on the Digilent Board or OberonStation or Pepino, and also using an "embedded" Oberon subset which does not necessarily require keyboard, mouse, display, nor as much memory. AStrobe already targets ARM Cortex-M3 and ARM Cortex-M4 based embedded microcontrollers. The RISC5 port allows use of less expensive FPGA development boards, which I will term "embedded FPGA-based microcontrollers", due to my lack of knowledge of that market segment. So AStrobe achieves multiple goals involving use of Oberon in applications of embedded controllers, as well as experimentation, tinkering, and product implementation involving interfacing hardware to embedded controllers with the software written in Oberon. Raspberry Pi, Orange PC, ODROID, the $9 C.H.I.P., and others are designed as fairly general-purpose computers, with major design goals to minimize cost to the end user, for purposes of "getting computers into kids hands", and enabling widespread learning and tinkering with both software and interface hardware for educational purposes. However, the cost goals drove use of complex ASICs to implement USB, HDMI, and other interfaces, and the goals related to hardware education are focused on how to interface to and control external hardware, not to fully understand the actual implementation of the onboard hardware. The various flavors of Native Oberon, and especially the Linux-related ones, are very appropriate for use on existing "PC" hardware to study and use Oberon. They do not include and fully enable study of the FPGA-based hardware components of the Project Oberon effort, but instead implement appropriate interfaces to "native" PC hardware. In addition to the ETH Native Oberon family, Peter Matthias' Oberon Linux Revival is a particularly easy-to-install version for use and study of the Oberon system on Linux platforms. Use of a Linux-based Oberon on Raspberry Pi, Orange PC, ODROID, C.H.I.P., or your already-purchased PC hardware is a very inexpensive way [perhaps even free] to use and study Oberon. Choosing "minimal cost" hardware depends on the purposes for which it will be used. If all you want to do is learn and use Oberon, download one of the Native Oberon or OLR implementations for the computer you already own. To experiment with it on a "tiny" platform, purchase your preferred platform (Raspberry Pi, Orange PC, BeagleBone, ODROID, C.H.I.P., etc.) and then download an appropriate Linux-based Oberon for it. To study and grasp Project Oberon 2013 in total, which includes the FPGA-based hardware aspects, either download and use a software-based emulator, or purchase an OberonStation or Pepino or Pipistrello with Oberon Shield, or another AStrobe RISC5 target (if any) which supports "workstation" mode. To experiment with using Oberon on embedded controllers, get an appropriate Cortex-M3, Cortex-M4, or FPGA board supported by AStrobe, and purchase or download the proper version of AStrobe. If you have additional purposes (Retrocomputing, learning how to program FPGAs, porting Project Oberon to other boards, etc.), then factor those requirements into your choice of hardware, and the costs involved to support those purposes. The price of the Digilent Spartan 3 Starter board, the OberonStation, the Pepino and Pipistrello, and most of the AStrobe-supported development targets, is significantly higher than that of the C.H.I.P. or the Raspberry Pi Zero. But the full scope of what they enable is significantly different, for which many people will gladly pay more to obtain the specific functionality and capabilities they desire. -- John Roberts

2 1

Re: [Oberon] oberonstation vs. a $9 computer (Lars)
by Hans Otten 15 Feb '16

15 Feb '16

Hi, First message from me after reading for a long time. So first a hello to all Oberon fans! I am Hans Otten, live in the Netherlands, now retired, and a long time fan of 'Wirth' languages and systems. Pascal has always been my language of choice as software engineer. As a hobby I write compilers for 'Wirth;' languages, since I was at the Vrije Universiteit where Andrew Tanenbaum initiated the VU Pascal compiler that later became the Amsterdam Compiler Kit.. Always wanted to have a Wirth Workstation since I saw the Lilith in the 80ties. OberonStation is indeed expensive compared to the Raspberry Pi and such. And since Project Oberon can run on the Pi, a very large price difference. Nowadays I dabble more with the Peter de Wachter Project Oberon emulator which I can run on any location, be It my Windows main machine or a Linux machine as the Raspberry Pi. It Is much more convenient than the isolated OberonStation with the SD card, the PS/2 mouse, the VGA monitor. About the 'moron' and 'go away' post against Lars, sorry to see a discussion come to strong words instead of arguments. Perhaps this discussion should be Oberonstation vs. a $5 computer! It's entirely possible to run Project Oberon on a $5 computer, the Raspberry Pi Zero cost is $5. I have several and am very happy with these, with USB keyboard, mouse and HDMI monitor instead of PS/2 and VGA and use them with Oberon, Freepascal, etc. and access to the rest of the world . my OberonStation is gathering dust. Now I assume there is no high profit in a $5 computer, but the Raspberry Pi Foundation is selling like mad these Raspberry Pi Zero's without loss. To teach and learn I would advise Raspberry Pi Zero's, you can buy a classroom full, for 20 students, for the same price as one OberonStation. Regards, Hans, http://pascal.hansotten.com

4 3

Re: [Oberon] RISC.img format
by peter＠easthope.ca 15 Feb '16

15 Feb '16

From: Paul Reed <paulreed(a)paddedcell.com>, Sat, 13 Feb 2016 11:24:46 +0000 > ... the filesystem is not exactly the same format as any that > have gone before, even the ETH PC-based Oberon filesystems. ETH PC Native Oberon has and FPGA Oberon has a b-tree as primary structure of the file system. Both FS are "flat". Both limit the length of a file name to 31 or 32 characters. They differ in upper limit on file size or on number of files? Better algorithms implement the newer FS? In principle I can find answers in the source code but the study will occupy days. Thanks, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

4 3

Re (2): oberonstation questions, ps/2?
by peter＠easthope.ca 15 Feb '16

15 Feb '16

From: Paul Reed <paulreed(a)paddedcell.com>, Tue, 2 Feb 2016 14:25:28 +0000, > I say again, use CAUTION with trying to do this, ... An illustration of the hazard is here. http://easthope.ca/PS2EncoderWheel.jpg It is the inside of a Compaq PS/2 mouse which I connected to a USB port via a cheap adapter. Within seconds the Y axis diode heated enough to melt three of the spokes in the encoder wheel. Risk of fire is imaginable. Attempting to convert PS/2 to USB or USB to PS/2 isn't worth the trouble or risk. Mice are available via eBay for a few dollars each, postage included. Don't risk burning your house or apartment, or worse, to save a few dollars on a mouse. The topic is also in the mailing list archive of 2015. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

10 15

Re: [Oberon] Windows GUI Development with Oberon
by Chris Burrows 15 Feb '16

15 Feb '16

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Lars > Sent: Monday, 15 February 2016 10:19 PM > To: ETH Oberon and related systems > Subject: Re: [Oberon] RISC.img format > > When I tried to search for how to do GUI tasks with Component Pascal > blackbox, I failed to find examples and howto's and information. I find GUI implementation is much simpler with Gardens Point Component Pascal. Some simple key examples are listed here: http://www.cfbsoftware.com/cpide/examples.aspx (CPIde is the ancestor of Astrobe. The GUI of both was developed using CPIde and GPCP.) Once you understand the basic building blocks and are familiar with C# and Winforms GUI development it doesn't take much imagination to develop more complex GUI applications. Although not quite as easy to write in the first place I find the resulting apps easier to maintain (and infinitely less buggy) than my Delphi code with its quirky forms system. Alternatively you can use Visual Studio's forms design to generate your GUI code in C# (VB even) using 'point and click'. You can the use GPCP when you want to port Oberon code to Windows as we did with the RISC5 compiler, the Project Oberon file system etc. C# and GPCP work wonderfully together. Regards, Chris Chris Burrows CFB Software http://www.astrobe.com

1 0

Re: [Oberon] RISC.img format
by skulski＠pas.rochester.edu 15 Feb '16

15 Feb '16

Joerg: after reading all the messages I am a bit unsure if I can take the Oberon RISC SD card and easily read/write its content under Windows, Linux, etc? Let me explain. We just released a product built around BeagleBone Black. It is shown on http://www.FemtoDAQ.com. It is a miniature data acquisition system. Users can acquire data files which then they process on a workstation of any kind. Users are able to conveniently transfer the data to their environments. They have lots of options for doing so. They can use a USB stick, or they can record an uSD card, or they can use Secure Copy and/or FileZilla over the net. The users can also connect the USB cable to the unit, which then behaves as it was a USB stick. (The directory pops up on the Windows screen.) Another option: The unit can also directly write to the host disks with NFS or samba. So the users have lots of possibilities. I was thinking of making a similar product running RISC Oberon. How can I get the data out of it? RISC Oberon does not support Internet. It does not support USB. So maybe I can use the SD card to transport the data. But is it convenient at all? I want to insert the Oberon-formatted SD card into the PC and I want to see the directory. A digital camera can create such an SD card. Can Oberon do the same? Neither I nor my customers want to use dd or something equally obscure. We want to drag-and-drop as usual. Is it possible? I am not sure. Could you explain? Thank you, Wojtek ________________________________________ From: Oberon [oberon-bounces(a)lists.inf.ethz.ch] on behalf of Jörg Straube [joerg.straube(a)iaeth.ch] Sent: Saturday, February 13, 2016 5:03 PM To: paulreed(a)paddedcell.com Cc: ETH Oberon and related systems Subject: Re: [Oberon] RISC.img format Thanx Paul for the clarification. I wrote an Oberon program to copy files from or to the RISC.img file. This might be useful for people running eg Linz Oberon (on Windows) or RP de Jong 's RISC emulator on Mac to copy Windows or Mac files "easily" to FPGA ProjectOberon. Please mail me if you're interested. br Jörg > Am 13.02.2016 um 12:24 schrieb Paul Reed <paulreed(a)paddedcell.com>: > > Dear Oberoners, > > I've been asked a couple of questions about the RISC.img SD-Card image > downloadable from http://projectoberon.com for the FPGA RISC5 Oberon > systems. (If you can, please post questions publically rather than > emailing me privately - otherwise I have to assume it's a private matter > which is more time-consuming to deal with - if I can ever get to it - and > doesn't benefit others.) > > The RISC Oberon system boots from an SD-Card and uses it as its file > system. This filesystem is much simpler than common contemporary > filesystems such as FAT, FAT32, NTFS, exFAT, EXT4 etc. and is not in any > way compatible. (On the original Ceres, the backup floppy disk format was > very close to the FAT12 format, but with an altered directory to cope with > long filenames, which were not in those days supported on FAT). > > It would have been easy to make the RISC5 Oberon filesystem (including its > reserved area for the bootfile) begin at offset 0 from the beginning of > the SD-Card. This would have dedicated the SD-Card to Oberon use, but > simplified the bootloader. > > Or alternatively, the Oberon filesystem could have perhaps been stored as > a file in the FAT filesystem on the SD-Card, making it much more > accessible to utilities running on other computers. But this convenience > would have come at a high cost: it would have made the bootloader much > more complicated, and given many more possibilities for distracting > problems in development. > > In the end, it was decided to place the Oberon filesystem at a fixed > offset from the beginning of the disk. This was a trivial change to the > bootloader, keeping it easily-understandable and within one block ram > (BRAM) of the FPGA. > > This meant that FAT-compatible data structures, and a reasonable-size and > perhaps useful (256MB) FAT partition could still exist at the beginning of > the disk. If this FAT partition has nothing in it, it compresses very > well and therefore does not significantly increase the RISC.img download > time. > > The MBR partition id for the Oberon filesystem was chosen as 0FFh, because > the ids are historically rather a free-for-all and the filesystem is not > exactly the same format as any that have gone before, even the ETH > PC-based Oberon filesystems. 0FFh is clearly an arbitrary value, and also > was only used by others for private data structures rather than for > filesystems which were interoperable amongst systems. > > Note that a lot of the motivation for this was defensive. For example it > makes it more difficult for the Oberon filesystem to be destroyed when the > SD-Card is inserted in a Windows system. > > When submitting some early additions to Peter de Wachter's RISC emulator > > https://github.com/pdewacht/oberon-risc-emu > > for emulated RS232 file transfer which he kindly incorporated, I also > included a quick check on startup which allows the use of a disk image > which only contains the Oberon file system (called .OBERON.FS in the > Windows binary distribution of the emulator which I put on > http://projectoberon.com) > > This check is for the magic number 9B1EA38DH (FileDir.DirMark) which is at > the beginning of the root directory sector. Oberon uses a "parity" scheme > for sector numbers, making all of them divisible by 29, so the first > usable Oberon sector, number 29, begins at SD-Card sector offset 80002H. > This slightly odd value comes from the fact that SD-Cards have 512-byte > sectors, but Oberon uses two of these (1K) for each Oberon sector, and > that sector 0 is not used. > > So if you are using a nice operating system and you know what you are > doing (because it allows dangerous commands such as dd) you can extract > the Oberon file system from the image with a command like (262145 = 40001H > = 80002H * 512 DIV 1024) > > dd if=RISC.img of=.OBERON.FS obs=1024 ibs=1024 skip=262145 > > and you can even (sudo) write it directly back to a real SD-Card with > something like > > dd if=.OBERON.FS of=/dev/disk1 obs=1024 ibs=1024 seek=262145 > > The name .OBERON.FS was chosen to make it look like a system file, which > would be totally destroyed if someone opened it and saved it with a text > editor, for example. > > Hope that's useful! > Cheers, > Paul > >

4 5