March 2014 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] PNG Encoder codec
by F. Necati Ecevit 26 Mar '14

26 Mar '14

FreeImage (V3.15.4) wrapper library for WinAos and LinuxAos is now available at; https://www.ocp.inf.ethz.ch/svn/ocp/trunk Happy Christmas and new Year. - Necati.

3 2

Re: [Oberon] RISC emulator
by Jörg Straube 22 Mar '14

22 Mar '14

Hi The German characters (ASCII character codes above 7F) do not only impact the keyboard driver (Input.Mod) but also the fonts (Fonts.Mod) and Files.Mod if you want to allow filenames with German letters. The current Fonts.Mod used in the RISC implementation restricts the character pattern to <80H. Br, Jörg > Am 17.03.2014 um 00:04 schrieb Peter De Wachter <pdewacht(a)gmail.com>: > >> On 16-03-14 22:22, Peter Matthias wrote: >> Hi Peter, >> >> thanks for the emulator. It made me get interested in Oberon-risc. >> >> It compiles and runs well on Ubuntu/X64, however, German keyboard layout >> is not recognized. >> >> Two questions: >> - How do I copy files to/from the disk image? >> - What are *.smb files? > > I don't have a way yet to transfer files to Oberon. The system supports > file transfer over RS-232 or wireless but those interfaces aren't > emulated yet. I think it might be possible to mount the disk image with > one of the "big" Oberon implementations and transfer files that way, but > I haven't tried that yet. > > To get a German keyboard layout, you'll have to edit the keymap table in > Input.Mod. The emulator only deals with scancodes, translating those to > characters is Oberon's job. > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon

6 14

Re: [Oberon] WITH removal in Oberon-07
by Paul Reed 13 Mar '14

13 Mar '14

> Date: Thu, 21 Feb 2013 22:52:05 +0100 > From: "Frans-Pieter Vonck" <fp(a)vonck.nl> > Subject: Re: [Oberon] WITH removal in Oberon-07 Hi Frans-Pieter, > i watched your presentation at MEDIA OberonDay2011. > Am I right that you made an ARM emulator first. No. The virtual machine is RISC, as in Prof. Wirth's Compiler Construction book (published in English in 1996 and updated on his home page http://www.inf.ethz.ch/personal/wirth/) > And did you use this emulator to ran Oberon System07 on top of it? It's not called System07, but it's basically the original system in the Project Oberon book, modified to compile under Oberon-07, run inside a RISC virtual machine executing on a bare-metal PC. > You showed a Spartan FPGA. I scanned through the Verilog ARM code. But > that seems a to big leap to me. I don't know what Verilog code you are referring to here. The Spartan-3 board only has 500K gates and 1MB of external static RAM, so it's much smaller and simpler than a typical ARM system. But ideal for Oberon. > Do you think it is possible to run [The Oberon System, compiled in Oberon-07] on an of the shelf > board with a Cortex M3 processor? I don't see why not, but most small ARM boards don't have a video framebuffer. The Raspberry Pi does, but it's a complicated board, as I've said before. The Oberon inner core (Kernel, FileDir, Files, Modules) and even the text system do not actually require a framebuffer display, so you could build a hybrid system. Using a simple FPGA board allows us to avoid the vast and irrelevant complexity inherent with most ARM System-on-Chip (SoC) systems; but since field-programmable gate arrays are so flexible, they will never be as cheap or as fast as a dedicated ARM. That's life. :) HTH Paul

4 5

RISC ProjectOberon 2013 Q & A with Niklaus Wirth
by Chris Burrows 07 Mar '14

07 Mar '14

Videos and slides from the recent Niklaus Wirth Birthday Symposium can now be seen at: http://www.multimedia.ethz.ch/conferences/2014/wirth/ At the end of his talk Wirth provides his answers to many similar questions to those that have appeared here recently regarding his RISC Project Oberon system, Regards, Chris Chris Burrows CFB Software http://www.astrobe.com

1 0

Re: [Oberon] FPGA Oberon some news and a reply to F.P.
by Jan Verhoeven 05 Mar '14

05 Mar '14

No no, the 6502 was a second generation CISC CPU. The first RISC was probably the MIPS and perhaps the first ARM cpu used in the Archimedes. The MicroChip PIC was the first RISC processor to enter the market on a large scale in the early 90's. And of course the Atmel AVR. And more later. What I am disappointed about is the fact that Wirth fell back to undecipherable mnemonics for his newly defined CPU. The 6502 and 6800 were known for their BRA's. Intel 8080 was not much better with their DAD and LXI. The guys at Zilog used more letters and better acronyms: LD and RET. Zilog source code is one of the easiest to read back. Even after 30 years. The 8086 is good readable too, as long as you reverse the operands... Intel moves backwards. PIC uses CLR, SUBWF, INCF etc which has a very steep learning curve. The AVR is a bit like the 6xxx series but not too hard to learn. And then came RISC5 which gave us mnemonics that look like the predecessor of the 6800... And, worst of all, WHY would you want to fall back to mnemonics? Why do you need to use MOV 1, 2 (which looks stupid) when you can also use Load R1, 2 (which looks logical) or, even better: R1 := 2 (which leaves no doubt at all) Mnemonics were inevitable in times when RAM was priced per bit and cpu clocks were measured in kHz. Until now, the future started in Zurich. Mnemonics are a thing from the past. We don't need them anymore. We have fast processors with more RAM than my first HDD. I didn't see any jump, call and return instructions in the specification either. -- Groetjes Jan Verhoeven

3 2

Re: [Oberon] FPGA Oberon: how is it done...
by Frans-Pieter Vonck 03 Mar '14

03 Mar '14

Thanks for the link to the PO Computer document. I will go through the basics of Verilog first. Greets, F.P. > FP > >>Still; compare the readabilty of the code of the rs232 driver written in >>verilog with one written in vhdl >> >>verilog >>http://www.inf.ethz.ch/personal/wirth/ProjectOberon/SourcesVerilog/RS232R.v > > Please find the description of the RS232 algorithm here (chapter 17.2.5, > page 20) > http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Computer.pdf > > Perhaps the Verilog gets more obvious if you read the description (what > "midtick" does, what "run" is meant for...) > > Jörg > >

1 0

FPGA Obern WORKS !!!
by greim 03 Mar '14

03 Mar '14

Hi, at a small picture http://www.schleibinger.com/bilder/oberon.jpg ProjectOberon really works! The SD card is written with 1K block size. Its now running from the Verilog and SD image files. I was not able to compile the Verilog files yet, still problems with Prom.v. I will try further... But many thanks to Prof. Wirth and Paul Reed for their real great work!! Markus Greim

3 2

Oberon.RemoveMarks
by peter＠easthope.ca 01 Mar '14

01 Mar '14

In ETHO, quoting from Oberon.Mod, (** Fade the mouse and pointer cursors if located inside the screen area X, Y, W, H. This is required before drawing inside the area X, Y, W, H. *) PROCEDURE RemoveMarks* (X, Y, W, H: INTEGER); BEGIN IF (Mouse.X > X - 16) & (Mouse.X < X + W + 16) ... According to Display, the Arrow pattern is defined in a frame of pixels (0..15)x(0..15). Row 0 is at the bottom. Column 0 is at the left. The tip of the arrow, which is the "hot point", is the pixel at column 0, row 15. The tail of the arrow is 15 pixels to the right of the tip. Consider the arrow being in the vicinity of X, the left boundary of screen area X, Y, W, H. I understand (Mouse.X > X - 16), up to the secondary question of inclusion of the X boundary. Then consider the arrow in the vicinity of X + W, the right boundary of the area. If Mouse.X = X + W then the arrow tip and pixels on the left edge of the arrow head are on the left boundary of the area. All other arrow pixels are outside the area, to the right. If my reasoning is correct, the condition should be (Mouse.X < X + W) or (Mouse.X <= X + W) rather than (Mouse.X < X + W + 16). To my understanding the only harm is a small fraction of invocations of FadeCursor(Mouse) being unnecessary. For the boundary cases, Mouse.X = X and Mouse.X = X + W, I need to study details further. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://carnot.yi.org/ New address Bcc: peter at easthope. ca

1 0