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

GUI programming in Oberon.
by Srinivas Nayak 29 Feb '16

29 Feb '16

Dear All, Do we have any framework for GUI programming in Oberon language? Obviously in Oberon OS it is possible by default, but I am looking for this in Linux OS or Windows OS. Something similar to wxWidgets etc... With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

6 8

Re: [Oberon] GUI programming in Oberon.
by David Egan Evans 28 Feb '16

28 Feb '16

I beg to differ. Blackbox is itself a Windows GUI program written in the CP Oberon variant. There are tie-ins to the Windows API. I have written cmd commands in Blackbox that are Windows .exe PE files without too much effort. Of course, this skips the rapid deployment benefits of programming in Blackbox itself. This goes first three PELinker of ETH Oberon and A2, but the cool thing is the look and feel deployment of the OS with Blackbox. Now if only OS X, and non-Debian systems, were supported, where Linux was not an after thought...

2 1

Re: [Oberon] Oberon with strings, Eberon
by jwr＠robrts.net 28 Feb '16

28 Feb '16

Short version: There are existing tools which will properly translate text files in Unicode UTF-8 to ASCII, assuming that most or all of the characters in those files can be represented properly in ASCII. Thinking of a text file as being infected by UTF-8 character viruses does not facilitate development of an effective solution: how does one inoculate a text file against viruses? What kind of anti-virus is best to apply? How can an infected file be cured? Thinking of it as a corrupted file could help, but isn't optimal. How does one detect and remove the corruption? How can you tell the difference between corrupted characters and ones that are correct but unusual? A useful approach might be to assume an existing file properly contains Unicode characters encoded in UTF-8, but what is desired is a text file containing only ASCII characters. Then the problem is how to translate a Unicode UTF-8 file into an ASCII file, with a minimum of problems. A further useful assumption is that the file is already composed primarily of Latin characters which have ASCII codes. (This approach is inappropriate for translating Chinese text to ASCII, for instance.) Given these assumptions, perhaps a tool is needed which reads in a UTF-8 file, properly translates each encoded Unicode character (not byte) to its character number, then for each outputs an appropriate ASCII character to a separate output file. It could map multiple kinds of single-quote characters to the ASCII apostrophe, multiple kinds of double-quote characters to the ASCII double-quote, etc. as desired. If I were writing this, I would have the tool keep track of the character value and text position of all Unicode characters which failed to map properly to ASCII, and dump diagnostic information to the output at the end following some kind of end-of-original-text marker (such as a line consisting of a dozen equals signs.) For diagnostics during testing I might also dump the character number and number of occurrences for each character which DID translate properly as well. The tool might terminate with a "success" result [here I'm thinking like a Unix programmer...] if all characters were translated properly, and with "failure" if some number (especially a majority) of characters failed to translate. The next step is to consider: why wouldn't someone else already have done this? A google search for "Unicode to ASCII" quickly results in several useful hits. The page https://docs.python.org/2/howto/unicode.html indicates Python already has a bunch of support for Unicode, so such a translator should be easy to implement, especially in a Linux environment. The pages http://stackoverflow.com/questions/2365411/python-convert-unicode-to-ascii-… and http://stackoverflow.com/questions/816285/where-is-pythons-best-ascii-for-t… lead to https://pypi.python.org/pypi/Unidecode which includes an already-developed mapping of Unicode-to-ASCII. These are not the only solutions, nor are they likely the best. With further searches I would expect to find even better solutions, programmed in a variety of languages. This is an Oberon forum, so a non-Oberon solution may not be optimal. Perhaps there is an existing Oberon solution. If not, we could write one, facilitated using the ideas and the examples above. But before going to that effort, what is the actual problem or true requirement? Maybe using a Python tool in a Linux environment, within a sequence of other processing (PDF to UTF-8 to ASCII to speech in MP3?), is a useful and acceptable approach for the problem at hand. -- John Roberts

2 1

Oberon to Arduino compiler
by Lars 28 Feb '16

28 Feb '16

As you know a oberon to C compiler exists, so I was thinking why not Oberon to Arduino? It would require modifying an existing oberon to c compiler and is likely easier said than done. The arduino is the cheapest version of a PC available. Would there be troubles compiling to Arduino language? Garbage collector or no garbage collector? I was reading some old posts about oberon and arduino and no one seemed to have a solution on how to use oberon for arduino, however I have not read the messages. There doesn't seem to be much online about intermediate compilers that take something like C and compile it to arduino (probably since there is no need, C is already close enough to arduino that no one needs an c to arduino compiler system). Then I thought some crank/crackpot would have written a Javascript to arduino compiler, but I didn't find much.

2 1

Why Oberon-2 and Component Pascal is more popular than Oberon-7?
by Srinivas Nayak 26 Feb '16

26 Feb '16

Dear All, Why Oberon-2 and Component Pascal is more popular than Oberon-7? I see many compilers are out there for Oberon-2 and Component Pascal but not a single one for Oberon-7... What are the features that make them popular? Is Oberon-7 lacking something, and that is why it is not useful for practical real world programming? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

5 5

Oberon-7 Compilers?
by chris＠cfbsoftware.com 26 Feb '16

26 Feb '16

> > -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On > Behalf Of Srinivas Nayak > Sent: Friday, 26 February 2016 2:12 PM > To: ETH Oberon and related systems > Subject: [Oberon] Why Oberon-2 and Component Pascal is more > popular thanOberon-7? > > I see many compilers are out there for Oberon-2 and Component > Pascal but not a single one for Oberon-7... > Try using a Google search for 'Oberon-07 compilers'. The first result I get is: http://oberon07.com/compilers.xhtml You will fild at least half-a-dozen Oberon-07 compilers listed there, Regards, Chris Burrows CFB Software http://www.astrobe.com

1 0

Model Helicopter reports
by jwr＠robrts.net 26 Feb '16

26 Feb '16

In trying to find the various original Oberon language reports, I discovered several of the reports regarding "A Computer System for Model Helicopter Flight Control", in particular "Technical Memo Nr." 1, 2, 3, and 6, and a bibliographic reference to 4. What was number 5? Is there one beyond 6? Is number 4 the same as eth-4357-01.pdf "Technical Report Nr 314"? Files I found include: "A computer system for model helicopter flight control, Technical memo Nr. 1: the hardware core", Niklaus Wirth, January 1998, 284, 15.12.97 https://e-collection.library.ethz.ch/eserv/eth:4326/eth-4326-01.pdf https://www.inf.ethz.ch/personal/wirth/Oberon/284.pdf "A computer system for model helicopter flight control, Technical memo Nr. 2: the programming language Oberon SA", Niklaus Wirth, January 1998, March 1999 Second Edition, 285, 21.12.97 / 15.1.99 https://e-collection.library.ethz.ch/eserv/eth:4327/eth-4327-01.pdf https://www.inf.ethz.ch/personal/wirth/Oberon/285.pdf "A computer system for model helicopter flight control, Technical memo Nr. 3: the software core", Marco A. A. Sanvido, April 1999, 317, https://e-collection.library.ethz.ch/eserv/eth:4358/eth-4358-01.pdf "A computer system for model helicopter flight control, Technical memo Nr. 6: the Oberon compiler for the strong-ARM processor", Niklaus Wirth, March 1999, 314, 7.3.99 https://e-collection.library.ethz.ch/eserv/eth:4355/eth-4355-01.pdf "Software for Model Helicopter Flight Control", Markus Kottmann, March 1999, Technical Report Nr 314 http://e-collection.library.ethz.ch/eserv/eth:4357/eth-4357-01.pdf Within Tech memo Nr 3 by Marco A. A. Sanvido, bibliographic reference number 5 is to: M. Kottmann, A computer system for model helicopter flight control, Technical Memo Nr. 4: The autopilot software, February 1998 Is that the same as the Markus Kottmann report above (eth-4357-01.pdf), or a different one? I think it is a different one. Where can one find copies of model helicopter reports 4, 5, and any beyond 6? Are there any other Oberon-related model helicopter reports which are named or numbered differently? -- John Roberts

3 2

Re: [Oberon] Oberon with strings, Eberon
by jwr＠robrts.net 25 Feb '16

25 Feb '16

Regarding Unicode, it is important to distinguish between the character number and the encoding. See especially http://www.unicode.org/standard/principles.html#Encoding_Forms and http://unicode.org/standard/WhatIsUnicode.html and https://en.wikipedia.org/wiki/Unicode and http://www.unicode.org/standard/where/ "To keep character coding simple and efficient, the Unicode Standard assigns each character a unique numeric value and name." The way that number is encoded can differ. Three of the most common ways to encode it are UTF-8, UTF-16, and UTF-32. UTF-8 and UTF-16 are both variable-width encodings. UTF-32 is fixed width. "UTF-8 is popular for HTML and similar protocols. ... It has the advantages that the Unicode characters corresponding to the familiar ASCII set have the same byte values as ASCII, and that Unicode characters transformed into UTF-8 can be used with much existing software without extensive software rewrites." "[In UTF-16] all the heavily used characters fit into a single 16-bit code unit, while all other characters are accessible via pairs of 16-bit code units." "UTF-32 is useful where memory space is no concern, but fixed width, single code unit access to characters is desired. Each Unicode character is encoded in a single 32-bit code unit when using UTF-32." "All three encoding forms need at most 4 bytes (or 32-bits) of data for each character." Chris Glur said: "<single quote> which is *3 bytes*" That would be the case in a UTF-8 encoding of a single-quote character. UTF-8 could result in a 3-byte encoding, UTF-16 and UTF-32 could not. According to http://www.unicode.org/charts/PDF/U2000.pdf the character number could be 2018, 2019, 201A, or 201B. Or 0027 or 02BC or 275C. According to http://www.unicode.org/charts/PDF/U0000.pdf an ASCII apostrophe is 0027. That also says that 2019 is preferred for apostrophe. So PART of what we're dealing with may be that the apostrophe/single-quote is being encoded as one of the "single-quote" characters, probably the preferred 2019 character, rather than as an 0027 "apostrophe". I have never had to write code to deal with Unicode, but co-workers have. A brute-force technique they used when memory and time allowed was to detect and convert whatever input encoding was provided to UTF-32, then deal with the text as fixed-width 32-bit "characters", then convert back to whatever encoding was desired. That approach could work reasonably well when implementing a character-by-character parser.

1 0

Re: [Oberon] 8051 book with Fuzzy Logic chapter
by jwr＠robrts.net 24 Feb '16

24 Feb '16

As verified by the previous message from Wojtek Skulski, the book on the 8051 processor with a chapter on Fuzzy Logic is "The Final Word on the 8051" by Matthew Chapman, copyright 1984. It has 255 pages, the author and copyright notice is on the last page. The final chapter is "CHAPTER 11 - BUMPIN’ FUZZIES WITH THE 8051". The Keil web site does not seem to have a copy posted. http://www.keil.com/c51/ describes the compiler, and http://www.keil.com/books/8051books.asp recommends some books, but a google search of that site does not turn up the document in a location that I see. It is mentioned on pages http://www.keil.com/forum/1709/ and http://www.keil.com/forum/9444/. The entry at 1709 has some clues as to why it was removed, and some (old) locations at which it could be found. I did more searching to try to find a site which clearly (to me) has a legal copy, without full success. The page https://www.coursehero.com/file/6073184/8051a/ is the closest I have found. It shows a preview of the document which matches the file I found elsewhere, and also Wojtek's copy. The MD5 and SHA checksums of the file I found match those of Wojtek's copy. The md5sum of the FINALWD.PDF file is eb7bb4123afbb37508275a8d798e946e FINALWD.PDF The shasum of the FINALWD.PDF file is 83c9de47315172f0156b70d1dae631bb1dc9be8f FINALWD.PDF An "ls -l" on the file shows it is 1550491 bytes in length. The first paragraph of the text is: "This is a book about the Intel 8051 microcontroller and its large family of descendants. It is intended to give you, the reader, some new techniques for optimizing your 8051 projects and the development process you use for those projects. It is not the purpose of this book to provide various recipes for different types of embedded projects." I tried searching for phrases from that first paragraph, as well as the title, and obtained similar but not identical search results from google. -- John Roberts

3 2

Re: [Oberon] Fwd: Re: RISC5 implementation issues.
by Magnus Karlsson 24 Feb '16

24 Feb '16

>> With this DCM configuration : clk = CLK0 = CLKIN = 50 MHZ No, I don't think so. I set CLKIN_DIVIDE_BY_2 to TRUE which will divide the input clock by 2 before it enters the DCM, and the monitor is syncing at 1024x768@70 Hz so pclk is definitely not 150 MHz. I fund the real problem though: what you call CLK25F90 is really clk shifted by 270 deg, not 90 deg! I changed the DCM code to reflect this: DCM #(.CLKFX_MULTIPLY(3), .CLKIN_DIVIDE_BY_2("TRUE"), .CLKIN_PERIOD(20.000)) dcm(.CLKIN(CLK50M), .CLKFB(clk), .RST(1'b0), .PSEN(1'b0), .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk), .CLK0(clk), .CLK270(clk270)); ODDR2 #(.INIT(1'b1)) oddr2(.Q(wr_enable), .C0(clk270), .C1(~clk270), .CE(1'b1), .D0(1'b1), .D1(~wr), .R(1'b0), .S(1'b0)); assign SRwe = wr_enable; And with that code change it now runs fine on the Pepino board. So I guess we have four alternatives that seems to run fine: * The original code where clk is generated by a flip-flop * The fully-synchronous version where everything is clocked by a 75 MHz clock generated by DCM * The version using DCM where the write-enable signal is generated by a 50 MHz clock * The version using DCM where the write-enable signal is generated using a DDR output buffer Just pick and choose ;) Cheers, Magnus On 2/24/2016 5:37 AM, Walter Gallegos wrote: > You are welcome ! > > With this DCM configuration : clk = CLK0 = CLKIN = 50 MHZ > > Here my simulation using Cypress SRAM VHDL simulation model with ALDEC > simulator. > > Label : "Potential Issue", If you read the SRAM and - in the next clk > cycle - try to write the same SRAM data bus we could wait some ns of > bus contention near this point. > If RISC5 can read then write in consecutive clk cycles the issue is > easy worked capturing de SRAM data with 90° clock and releasing oen soon. > > > > > About your solution is fully synchronous it's ok considering that both > clocks come from same DCM. > > Best regards, > Walter > > El 2016-02-23 a las 14:28, Magnus Karlsson escribió: >> Since the ETH Oberon mailing list seems to delay our posts by a few >> days I decided to send it directly to you as well. >> >> Magnus >> >> >> -------- Forwarded Message -------- >> Subject: Re: [Oberon] RISC5 implementation issues. >> Date: Tue, 23 Feb 2016 08:49:05 -0800 >> From: Magnus Karlsson <magnus(a)saanlima.com> >> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> >> >> >> >> Walter, >> >> I tried your proposed solution and couldn't make it work. It "almost" >> works in that it starts the boot process and reads from the SD-card, >> but then hangs with the LEDs showing 0x84. >> Maybe I didn't do it correct, I instantiated the ODDR2 buffer >> directly at the top module and modified the DCM instantiation to >> create the clk90 clock. >> >> Here is the code, can you look it over and see if this is what you >> had in mind or if something is wrong: >> >> DCM #(.CLKFX_MULTIPLY(3), .CLKIN_DIVIDE_BY_2("TRUE"), >> .CLKIN_PERIOD(20.000)) >> dcm(.CLKIN(CLK50M), .CLKFB(clk), .RST(1'b0), .PSEN(1'b0), >> .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk), >> .CLK0(clk), >> .CLK90(clk90)); >> >> ODDR2 #(.INIT(1'b1)) >> oddr2(.Q(wr_enable), .C0(clk90), .C1(~clk90), .CE(1'b1), .D0(1'b1), >> .D1(~wr), .R(1'b0), .S(1'b0)); >> >> assign SRwe = wr_enable; >> >> >> wr is the active-high write signal from the RISC5 CPU, and SRwe is >> the short active-low write-enable signal to the SRAM. >> >> Just to recap, this is the code I used to generate the short write >> pulse, using a 2x clk instead. This version seems to run fine: >> >> reg wr_enable; >> >> DCM #(.CLKFX_MULTIPLY(3), .CLKFX_DIVIDE(2), .CLKDV_DIVIDE(2), >> .CLKIN_PERIOD(20.000)) >> dcm(.CLKIN(CLK50M), .CLKFB(clk2x), .RST(1'b0), .PSEN(1'b0), >> .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk), >> .CLKDV(clk), .CLK0(clk2x)); >> >> always @(negedge clk2x) >> wr_enable <= wr & ~wr_enable; >> >> assign SRwe = ~wr_enable; >> >> >> Any idea what's wrong? >> Magnus >> >> >> On 2/19/2016 9:58 AM, Walter Gallegos wrote: >>> Let us concentrate in the problem... >>> >>> How to generate an output pulse shorter than clock period? >>> >>> You can make a pulse shorter with help of DCM and DDR ( dual data >>> rate output registers ) see the simulation capture >>> >>> >>> >>> clk25f90 is the DCM clock output with 90° phase shift. >>> >>> The VHDL code is : ( without DCM instantiation ) >>> >>> ENTITY PulseShaper IS >>> PORT (CLK25F90 : IN STD_LOGIC; >>> RESET : IN STD_LOGIC; >>> WE : IN STD_LOGIC; >>> WESRAM : OUT STD_LOGIC >>> ); >>> END PulseShaper; >>> >>> ARCHITECTURE RTL OF PulseShaper IS >>> >>> CONSTANT zero : STD_LOGIC := '0'; >>> CONSTANT one : STD_LOGIC := '1'; >>> >>> SIGNAL clk90n: STD_LOGIC; >>> >>> BEGIN >>> >>> clk90n <= NOT(CLK25F90); -- This is valid because the tool use >>> the clock inverter available in IOB >>> >>> Dly : ODDR2 >>> PORT MAP ( >>> Q => WESRAM, >>> C0 => CLK25F90, >>> C1 => clk90n, >>> CE => one, >>> D0 => one, >>> D1 => WE, >>> R => zero, >>> S => zero >>> ); >>> >>> END RTL; >>> >>> Someone know if exist a FPGA testbench for RISC5 ? >>> >>> Regards, >>> Walter

1 0