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

Spartan 6 Kickstarter project
by Aubrey.McIntosh＠Alumni.UTexas.Net 12 Oct '14

12 Oct '14

There is a Kickstarter project to produce a Spartan 6 board. This reached its funding goal in 4 days and will run for about 3 more weeks. https://www.kickstarter.com/projects/1812459948/minispartan6-a-powerful-fpg… -- Aubrey McIntosh, Ph.D. 1502 Devon Circle Austin TX 78723-1814 (512)-348-7401

6 5

Nimrod is not Oberon
by Stefan Salewski 02 Oct '14

02 Oct '14

Yes, I am still subscribed to this list... And I noticed that "Oberon on FPGA" project, but have not read much about it. Recently, when I was looking about some news about Mozillas Rust language, I discovered Nimrod, a language which looks similar to Modula/Oberon, with some interesting new features. Nimrod is not very popular now, some people simple do not like the Wirthian style syntax. (And of course there are many other interesting new languages available now, Mozillas Rust with C syntax, Julia for numerical computing, Haskell -- not really new, but still modern...) But maybe someone of you may be interested in Nimrod. Of course it is no operating system, just a modern language. Keywords: Wirthian syntax, with Python indentation, system- and high-level programming, garbage-collector which still allows time critical applications, advanced generics, templates, high-level macros. Good support for parallel processing. Speed seems to be close to C. Currently Compiler generates C intermediate code. Currently there is no wikipedia entry (was rejected) so it is difficult to discover it. There was an article in DrDobbs Journal recently, and of course there is a homepage with a tutorial. http://nimrod-lang.org/ http://www.drdobbs.com/open-source/nimrod-a-new-systems-programming-languag… Not a high rank at http://langpop.corger.nl/ but Oberon is not listed at all ;-) Best regards Stefan Salewski

3 3

Large displays in Emulated RISC Oberon
by Charles Perkins 25 Jun '14

25 Jun '14

I wished to be able to use the full resolution of my laptop (1440x900) from within the emulated Oberon system, so I have created patches for Peter de Wachter's oberon-risc-emu program which will (after patches are applied) create a new frame buffer in higher memory. Smaller screens still work the way they did before and I think that Oberon looks awesome at full screen and high resolution on my MacBook Air! I have also modified Display.Mod and made a one-line change to Input.Mod to allow Oberon to use that new frame buffer when resolutions are greater than 1024 horizontal or 768 vertical. I have tested resolutions as high as 1920x1080 on an external monitor, it should work all the way up to 2048x2048. I have not tested on platforms other than the Mac. The changes can be found at: https://github.com/charlesap/io Chuck

8 20

Re: [Oberon] Spartan 6 Kickstarter project
by Ulrich Hoffmann 23 Jun '14

23 Jun '14

Hello Jörg, Paul, according to Jack Gasset, developer of the Papilio DUO, the 2MB RAM on the Deluxe board is organized by 8 :-( He wrote: > Unfortunately there are not enough free pins with the Spartan6 tqfp package used on the Papilio DUO to pull that off. The 2MB SRAM is an 8 bit part. Thanks Paul for pointing this out and explaining the simplicity philosophy. Regards, Ulrich Am 23.06.2014 um 15:43 schrieb Jörg: > Hi Paul > > Today's RISC5Top Verilog source splits the 20 bits address bus to > two SRAM chips with 18 bits address and 16 bit output. > +------+ > +-! 256K !-- 16 bit > ! +------+ > adr (20bit) --- SRadr (18bit) --+ > ! +------+ > +-! 256K !-- 16 bit > +------+ > > As the Papilio DUO page only points to ONE SRAM datasheet (IS61WV5128) > but offers TWO versions of the board (512K and 2M) I could imagine that > the 2M version has 4 of those chips in parallel. > > If this is the case, today's "RISC5Top" Verilog could be re-written to > +------+ > +-! 512K !-- 8 bit > ! +------+ > ! +------+ > +-! 512K !-- 8 bit > adr (20 bit) --- SRadr (18bit) -! +------+ > ! +------+ > +-! 512K !-- 8 bit > ! +------+ > ! +------+ > +-! 512K !-- 8 bit > +------+ > > The upper half of those SRAM chips would not be used... > > br > Jörg > > > -----Original Message----- > From: Paul Reed [mailto:paulreed@paddedcell.com] > Sent: Montag, 23. Juni 2014 13:45 > To: ETH Oberon and related systems > Subject: Re: [Oberon] Spartan 6 Kickstarter project > > Hi Ulrich, (bcc others) > >> the Papilo DUO kickstarter project [1] (4 days to go) has 2MB SRAM (not >> SDRAM) on board of its PAPILIO DUO DELUXE. >> >> With the Classic Computing Shield you also get VGA output, 2 x PS/2 and > a micro SD socket. >> >> Looks to me, that's what you need for RISC-Project-Oberon, right? > >> > https://www.kickstarter.com/projects/13588168/papilio-duo-drag-and-drop-fpga > -circuit-lab-for-mak > > Looks perfect, but the devil is in the detail, as always. I think their > SRAM is x8, so even though it's a good speed (10nS), the board seems to be > designed for retro 8-bit processors not 32-bit RISC. The Digilent > Spartan-3 board has two x16 10nS SRAMs set up in parallel, which is why > it's so neat. > > However, maybe things are changing - it's refreshing that the Papilio > project description says: "SRAM - Easy to use SRAM is a must. We've used > SDRAM in the past and it was a big mistake! The strict timing requirements > and interfacing caused fits for everyone. SRAM is asynchronous and dead > easy to use, you will greatly appreciate the simplicity of SRAM in your > projects." > > People privately email me questions along the lines of: "would it be > possible to port the RISC Oberon system to FPGA board X". I'm BCC'ing > some in, and suggest they perhaps follow the Oberon mailing list instead > to understand why it's currently a very difficult question to answer. > Whilst I would be absolutely delighted to see something viable, "possible" > is not the same as "easy" or even "sensible". > > The point of Project Oberon is not just to make something work, starting > from scratch, but to make it completely clear and understandable (and > convincing). The entire book is just that, and amply rewards a careful > read. I think it's only after you read the whole book through that you > can really start claiming to understand the philosophy. > > F V Tkachov (2014 J. Phys.: Conf. Ser. 523 012011) recently perhaps put it > even more starkly than Prof. Wirth: the natural tendency towards > unnecessary complexity creates vulnerability (The Kalashnikov Principle), > and should be avoided. > > Cheers, > Paul Reed > http://projectoberon.com > > > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon

2 1

Re: [Oberon] Spartan 6 Kickstarter project
by Jörg 23 Jun '14

23 Jun '14

Paul Okay, I looked at the pictures of the board. Most probably there is no space for 4 chips in parallel :-( br Jörg -----Original Message----- From: Jörg [mailto:joerg.straube@iaeth.ch] Sent: Montag, 23. Juni 2014 15:44 To: paulreed(a)paddedcell.com; 'ETH Oberon and related systems' Subject: Re: [Oberon] Spartan 6 Kickstarter project Hi Paul Today's RISC5Top Verilog source splits the 20 bits address bus to two SRAM chips with 18 bits address and 16 bit output. +------+ +-! 256K !-- 16 bit ! +------+ adr (20bit) --- SRadr (18bit) --+ ! +------+ +-! 256K !-- 16 bit +------+ As the Papilio DUO page only points to ONE SRAM datasheet (IS61WV5128) but offers TWO versions of the board (512K and 2M) I could imagine that the 2M version has 4 of those chips in parallel. If this is the case, today's "RISC5Top" Verilog could be re-written to +------+ +-! 512K !-- 8 bit ! +------+ ! +------+ +-! 512K !-- 8 bit adr (20 bit) --- SRadr (18bit) -! +------+ ! +------+ +-! 512K !-- 8 bit ! +------+ ! +------+ +-! 512K !-- 8 bit +------+ The upper half of those SRAM chips would not be used... br Jörg -----Original Message----- From: Paul Reed [mailto:paulreed@paddedcell.com] Sent: Montag, 23. Juni 2014 13:45 To: ETH Oberon and related systems Subject: Re: [Oberon] Spartan 6 Kickstarter project Hi Ulrich, (bcc others) > the Papilo DUO kickstarter project [1] (4 days to go) has 2MB SRAM (not > SDRAM) on board of its PAPILIO DUO DELUXE. > > With the Classic Computing Shield you also get VGA output, 2 x PS/2 and a micro SD socket. > > Looks to me, that's what you need for RISC-Project-Oberon, right? > https://www.kickstarter.com/projects/13588168/papilio-duo-drag-and-drop-fpga -circuit-lab-for-mak Looks perfect, but the devil is in the detail, as always. I think their SRAM is x8, so even though it's a good speed (10nS), the board seems to be designed for retro 8-bit processors not 32-bit RISC. The Digilent Spartan-3 board has two x16 10nS SRAMs set up in parallel, which is why it's so neat. However, maybe things are changing - it's refreshing that the Papilio project description says: "SRAM - Easy to use SRAM is a must. We've used SDRAM in the past and it was a big mistake! The strict timing requirements and interfacing caused fits for everyone. SRAM is asynchronous and dead easy to use, you will greatly appreciate the simplicity of SRAM in your projects." People privately email me questions along the lines of: "would it be possible to port the RISC Oberon system to FPGA board X". I'm BCC'ing some in, and suggest they perhaps follow the Oberon mailing list instead to understand why it's currently a very difficult question to answer. Whilst I would be absolutely delighted to see something viable, "possible" is not the same as "easy" or even "sensible". The point of Project Oberon is not just to make something work, starting from scratch, but to make it completely clear and understandable (and convincing). The entire book is just that, and amply rewards a careful read. I think it's only after you read the whole book through that you can really start claiming to understand the philosophy. F V Tkachov (2014 J. Phys.: Conf. Ser. 523 012011) recently perhaps put it even more starkly than Prof. Wirth: the natural tendency towards unnecessary complexity creates vulnerability (The Kalashnikov Principle), and should be avoided. Cheers, Paul Reed http://projectoberon.com -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Papilio DUO with SRAM from December 2014
by greim 23 Jun '14

23 Jun '14

Hi Andrế gave me the hint to this Kickstarter Project: <https://www.kickstarter.com/projects/13588168/papilio-duo-drag-and-drop-fpg…> Open FPGA hardware with SRAM etc. 48k$ from Kickstarter is a big shot. I did just the 25$ pledge... getting the PCB board in July they said.. Markus

1 0

RISC platform issue
by nyaaa＠nyaaa.de 23 Jun '14

23 Jun '14

Since Digilent's SPARTAN-3 board has reached its end of life and many newer development boards only come with SDRAM, I welcome the effort to add support for it. It would be nice, if cheap boards like Olimex's MOD-VGA-32M [1] could be used to run Oberon. Not being familiar with hardware description languages, I am unable to guess what makes supporting another RAM type than found on the Digilent board so much more difficult. Naive as I am, I would believe that you did not have to look any further than to Papilio DUO, whose production can currently be funded. [2] The $149 (plus shipping) deluxe bundle comes with 2 MB SRAM and a retro computing shield, is advertised as open source hardware and might be worth an investigation. According to the SRAM data sheet, to which the campaign page links (but which seems to refer to the non-deluxe versions 512K module), it is a 512K x 8 type RAM though, while the Digilent board's SRAM seems to comprise two 256K x 16 type RAM chips, which from my very limited understanding means, that the Digilent board allows 32-bit wide memory accesses per cycle while the the Papilio DUO board is limited to 8-bit wide accesses. I don't know how much that would complicate a port to that board. The cleanest solution for a successor to the Digilent board would probably be a custom design. Again, not being able to make an educated guess about how difficult such an endeavour would actually be, I imagine that Papilio DUO could be a starting point for a custom design. Improvements could be an SD card connector, a LiPo battery connector, possibly a larger FPGA and wider SRAM. SRAM modules seem to be significantly more expensive than SDRAM modules though, and for that reason I still believe that the effort to add support for the latter would not be wasted. The Atmel MCU on the Papilio DUO could also be replaced with a more powerful chip, perhaps a PIC32 or a Propeller. Speaking of which, Parallax is currently in the process of designing a successor to the Propeller. There seem to be plans to make a Verilog implementation of the Propeller 1 chip available at some point. A custom FPGA board for the purpose of developing and testing future Propeller chips has been announced. [3] Since Olimex has designed its Duinomite boards as an improved version of the Maximite in the past, they might be interested in producing an improved version of the Papilio DUO, if that would not mean much work for them. A recent blog post of theirs [4] is an interesting read about their perspective on the Duinomite story. Lest Oberon joins BASIC on its way into oblivion, interested developers should speak up. Olimex might be surprised to learn that Oberon is not as dead as they thought at the end of some older post of theirs [5] and that it has even been ported to an FPGA board. [1] https://www.olimex.com/Products/Modules/Video/MOD-VGA-32MB/open-source-hard… [2] https://www.kickstarter.com/projects/13588168/papilio-duo-drag-and-drop-fpg… [3] http://parallax.com/news/2014-02-24/propeller-2-schedule-update-february-20… [4] http://olimex.wordpress.com/2014/06/06/mpide-arduino-like-ide-for-pic32-pin… [5] http://olimex.wordpress.com/2013/03/20/mod-lcd3310-example-with-olimexino-3…

1 0

ETHO's disassembler?
by eas lab 22 Jun '14

22 Jun '14

Some years ago, I discovered ETHO's <Decoder.Decode FileName>, which amazingly, allowed disassembly of X86-code. At that time, nobody else on the mailing-list seemed to be interested in <looking down to byte level>. It seems that the same facility exists for ETHO:ARM, and I want to test it. Since it's designed to <decode> <ETHO>.Obj it expects the files to comply with the format of <ETHO>.Obj. However I was able to <decode> arbitrary X86 bytes by somehow patching the <arbitrary X86-code bytes> to a template <ETHO>.Obj. Obviously I made notes documenting my method. But now the main IDE of N-O partitions seems OOO! The other IDE of N-O partitions fails to mount the <NOdocumentation> partition under LNO. But fortunately, linux does: read the bytes of the partition <which won't mount under LNO> | removing non-ascii-bytes | wrapping the lines suitably | select only lines containing "ecode" | save it to a file. [PS. this is a further typical task where functional-composition is good] The file is interesting, but I can't see from the text fragments, exactly what is my-notes OR original ETHO-documentation; eg. I see:... * Decoder.Mod - More robust against incorrect references (prk). * Decoder.Mod - Accept new object file tag and show flags (prk). * OPA.Mod, OPAData.Mod, OPA.Data, Decoder.Mod - MMX instruction set * Decoder.Mod - Installable disassembler (be). * Decoder.Mod - Fixed MOVSX and MOVZX (prk). ... ARM.ARMCompiler.Mod, ARM.ARMDecoder.Mod, ARM.ARMBootLinker.Mod END DecodeThis; dest = POINTER TO TextDesc ! = in/out par. Examine some other 'small' : Decoder.Decode FileDir.Obj ~ == 3. call PROCEDURE DecodeThis A: Use the Decoder tool to disassemble Native Oberon or Linux Native Oberon object files. Syntax: Decoder.Decode some.Obj opens a text viewer "Decoder.Dec" presenting the disassembled --------------- end of file extract:- Annoyingly !! I've forgotten where to patch-in the arbitrary bytes, so that Decoder.Decode remains valid/syncronised. I suspect the template was ETHO-code with only a main-block. How would you try to do this ? == Chris Glur. PS. After writing this, to force myself to THINK, it seems that you could decode : ... BEGIN (* main*) a := 3 + 2 END.TstDisam. ... BEGIN (* main*) a := 3 - 2 END.TstDisam. Which brackets a range with no <relative> branches, for you to put your bytes in to?

1 0

ALO: ArmLinuxOberon does the job!
by eas lab 22 Jun '14

22 Jun '14

I was wrong again: the special shading of the MenuFrame of the TextFrame, which does reverse-video for selected text, and has a darker background, to emphasise the Frame's top boundry, fails to show this special appearance, in LNO, not because of ETHO code; but because of complex/too-smart modern hardware. It's fine with the old CRT. The newDisplayHardware has a menu-tree with ca. 30 leaves; so that the blame can always be "you don't know how to operate it". You won't be happy after spending much effort to tune for your present favoured hardware, when that effort is lost for future hardware. I've become curious and want to "look into FrameBuffers". ARM linux shows the following [but I couldn't find its calculator, so ALO's Calculator.Panel did the job. And this is all written in ALO. An acrobatic achievement of ALO, is the remapping of the all importent "*" char [from the inconvenient <shift 8> to <F12> <insert>] via ETHO's powerful EditKeys.Tool . My numKeyPad is dead for ALO. ============== -> fbset -i == mode "960x540" <-- my /boot/config.txt setting geometry 960 540 960 540 16 timings 0 0 0 0 0 0 0 rgba 5/11,6/5,5/0,0/16 endmode Frame buffer device information: Name : BCM2708 FB Address : 0x5d385000 Size : 1036800 <- / 960==1080 / 540 == 2 Type : PACKED PIXELS Visual : TRUECOLOR XPanStep : 0 YPanStep : 0 YWrapStep : 0 LineLength : 1920 Accelerator : No ===> Can ALO inspect this File ? == YES!! *alc* = Calculator.Panel == See good calculation results above. How can ALO see into AbsAdrs-ed memory: 0x5d385000 ?! Ask on rPi-forum ? Again: need set of VM instructions, for low-level access, like: (AbsAdr) -> RegN RegN -> (AbsAdr) ...etc.

2 1

RISC / PC File transfers
by Chris Burrows 21 Jun '14

21 Jun '14

> -----Original Message----- > From: greim [mailto:greim@schleibinger.com] > Sent: Thursday, 19 June 2014 8:06 PM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Large Displays / 64 bit... > > Also a tool writing the Oberon File system directly to a SD- > Card and a real PC-Link using the RS232 RISC<->PC would be nice to have, as a > stable, easy to use infrastructure. > I use slightly modified versions of ORC.Mod and PCLink1.Mod which are both included with Project Oberon to send files from the PC to the Spartan-3 FPGA board. I have ORC running on 'ETH PlugIn Oberon for Windows 2.5' on the PC and PCLink1 running on RISC Oberon. I have also started working on a Gardens Point Component Pascal Windows program to read / write to the Oberon filesystem on an SD card. So far it is just reading raw sectors. It has had to wait as preparation of the release of Astrobe for Cortex-M4 with hardware floating point support has been keeping me busy. However, I hope to be able to return to the SD card project soon, Regards, Chris -- Chris Burrows CFB Software http://www.astrobe.com

2 3