April 2017 - Oberon - mailman3.inf.ethz.ch

FPGA - Save / Restore OBERON.FS
by Tomas Kral 14 Apr '17

14 Apr '17

Hi Christopher, EDIT, need $((256*1024+1)), as it is 262144+1 where OBERON.FS starts and 1st block is not used, modulo 29. I have in the end resorted to: $ dd if=/dev/sdc of=OBERON1.FS bs=1K skip=$((256*1024+1)) count=65K `System.Watch' reports 921 sectors used, so I tempted to try $ dd if=/dev/sdc of=OBERON1.FS bs=1K skip=$((256*1024+1)) count=921, instead. Which goes very fast on RPI here. Tomas

2 1

Fw: FPGA - Garbage Collector - GC
by Tomas Kral 14 Apr '17

14 Apr '17

Hi, EDIT, now GC works, I must have done something wrong when shuffling OBERON.FS around with dd here. Tomas Begin forwarded message: Date: Fri, 14 Apr 2017 09:09:02 +0200 From: Tomas Kral <thomas.kral(a)email.cz> To: "Oberon@" <lists.inf.ethz.ch Oberon(a)lists.inf.ethz.ch> Subject: [Oberon] FPGA - Garbage Collector - GC Hi, I have an interesting observation. `GC' does not seem to clean my heap any longer, after updating my system. `System.Collect' does no lit the LED(5), heap does not shrink. Anything I may have done wrong? Tomas P.S. I keep revisions in distinct directories, so I can learn from changes easily. pi@raspberrypi /usr/src/oberon $ grep MODULE.*2017 PO.V5.2/*.txt PO.V5.2/ORB.Mod.txt:MODULE ORB; (*NW 25.6.2014 / 4.4.2017 in Oberon-07*) PO.V5.2/ORG.Mod.txt:MODULE ORG; (* NW 18.4.2016 / 4.4.2017 code generator in Oberon-07 for RISC*) PO.V5.2/ORP.Mod.txt:MODULE ORP; (*N. Wirth 1.7.97 / 4.4.2017 Oberon compiler for RISC in Oberon-07*) PO.V5.2/ORS.Mod.txt:MODULE ORS; (* NW 19.9.93 / 20.3.2017 Scanner in Oberon-07*) -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

FPGA - Garbage Collector - GC
by Tomas Kral 14 Apr '17

14 Apr '17

Hi, I have an interesting observation. `GC' does not seem to clean my heap any longer, after updating my system. `System.Collect' does no lit the LED(5), heap does not shrink. Anything I may have done wrong? Tomas P.S. I keep revisions in distinct directories, so I can learn from changes easily. pi@raspberrypi /usr/src/oberon $ grep MODULE.*2017 PO.V5.2/*.txt PO.V5.2/ORB.Mod.txt:MODULE ORB; (*NW 25.6.2014 / 4.4.2017 in Oberon-07*) PO.V5.2/ORG.Mod.txt:MODULE ORG; (* NW 18.4.2016 / 4.4.2017 code generator in Oberon-07 for RISC*) PO.V5.2/ORP.Mod.txt:MODULE ORP; (*N. Wirth 1.7.97 / 4.4.2017 Oberon compiler for RISC in Oberon-07*) PO.V5.2/ORS.Mod.txt:MODULE ORS; (* NW 19.9.93 / 20.3.2017 Scanner in Oberon-07*)

1 0

FPGA - Save / Restore OBERON.FS
by Tomas Kral 13 Apr '17

13 Apr '17

Hi, Reading some earlier post by Paul Read, I look for `dd' syntax to save and restore my work on uSD card. Providing uSD card is formatted as 256MB FAT + 65MB OBERON. Restore my work indexed as `1' may work like this, $ dd if=OBERON1.FS of=/dev/sdc bs=1024 seek=262145 By how about saving the work first, $ dd if=/dev/sdc of=OBERON1.FS bs=1024 skip=262145 count=??? What count should I use? `System.Watch' may give a clue, but does not seem exact. I could also use a fixed value of the whole 65MB Oberon partition, but not sure if below is correct $ dd if=/dev/sdc of=OBERON1.FS bs=1024 skip=262145 count=$((65*1024*1024)) Many thanks. Tomas

2 1

Re: [Oberon] [Fwd: Re: Fw: FPGA - Bitmaps.Mod]
by Tomas Kral 13 Apr '17

13 Apr '17

Hi Joerg, Andreas, Thank you this looks all very neat. I am rereading the chapters on heap management as I do something wrong, as my bitmaps are not seen by GC when `System.Collect' is clicked. Tomas > -------- Forwarded Message -------- > > From: Jörg Straube <joerg.straube(a)iaeth.ch> > > Reply-to: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > > To: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com>, ETH Oberon > > and related systems <oberon(a)lists.inf.ethz.ch> > > Subject: Re: [Oberon] Fw: FPGA - Bitmaps.Mod > > Date: Wed, 12 Apr 2017 08:05:50 +0200 > > > > Hi Tomas > > > > > > I refined the module "Bitmaps" a little bit. This code allocates > > variably sized bitmaps and makes sure the garbage collector collects > > them if no longer referenced. As Andreas pointed out: it is the > > responsibility of the module using "Bitmaps" to make the bitmaps > > globally reachable. If not, the allocated memory gets freed up more > > or less immediately... > > > > > > I compiled the code with the emulator on a Mac > > > > > > MODULE Bitmaps; (* jr/11apr17 *) > > > > > > IMPORT SYSTEM, Kernel := KernelOSX; > > > > > > TYPE > > TypeTag = RECORD size, ext1, ext2, ext3, offset: INTEGER END; (* see > > Project Oberon, figure 8.8 *) > > Address = POINTER TO RECORD END; (* this pointer will be redefined > > by TypeTag *) > > Bitmap* = POINTER TO RECORD > > width, height: INTEGER; > > tag: TypeTag; (* type descriptor of the pointer "base" *) > > base: Address > > END; > > > > > > > > > > PROCEDURE New*(w, h: INTEGER): Bitmap; > > VAR b: Bitmap; > > BEGIN > > NEW(b); > > IF b # NIL THEN > > b.width := w; b.height := h; > > > > > > (* the following code defines a type tag corresponding to ARRAY size > > OF BYTE *) > > > > > > b.tag.size := (w+7) DIV 8 * h; (* size of the bitmap in BYTEs *) > > b.tag.offset := -1; (* type has no pointers, important for GC *) > > (* allocate memory and define its type *) > > Kernel.New(SYSTEM.VAL(INTEGER, b.base), SYSTEM.ADR(b.tag)); > > > > > > IF b.base = NIL THEN b := NIL END > > END > > RETURN b > > END New; > > > > > > END Bitmaps. > > > > > > System.Free Bitmaps ~ > > ORP.Compile Bitmaps.Mod ~ > > > > > > > > 2017-04-07 17:41 GMT+02:00 Andreas Pirklbauer > > <andreas_pirklbauer(a)yahoo.com>: > > To be precise: > > > > > > If you don't make dynamically allocated objects reachable > > via at least one global pointer variable, they simply won't be > > marked during the mark phase of the garbage collector, which > > means that they *will* be collected during the subsequent > > scan phase. That's the whole point of garbage collection... > > > > > > > > > > > > > > ______________________________________________________________ > > From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> > > To: ETH Oberon and Related Systems > > <oberon(a)lists.inf.ethz.ch> Cc: Andreas Pirklbauer > > <andreas_pirklbauer(a)yahoo.com> Sent: Friday, April 7, 2017 5:35 PM > > Subject: [Oberon] Fw: FPGA - Bitmaps.Mod > > > > > > ... > > > > > > 4. If you want your objects to be automatically collected by > > the Oberon garbage collector, you must make it globally > > reachable via a global pointer. Then they will appear in > > mod.ptr in the module block which are used as roots for the > > garbage collector. (Oberon uses all named pointer variables > > in existence as roots for the mark phase of the garbage > > collector. See Oberon.GC for the details. It simply calls > > Kernel.Mark(mod.ptr) for each loaded module mod. > > > > > > > > > > > > > > > > > > > > > > -- > > 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 >

1 0

Fw: FPGA - Bitmaps.Mod
by Tomas Kral 07 Apr '17

07 Apr '17

Hi, I am not getting much response re below forward. I try now to formulate my question better. [a] I realised I cannot use this construct under V07 SYSTEM.NEW(addr, size); Correct? [b] I tried to typecast it with SYSTEM.VAL NEW(SYSTEM.VAL(addr, size)); But type cast is not allowed, possible reason as this would get difficult job for the garbage collector? Perhaps it is right ater all, I can use fix bitmap size flavours, 1/1 or 1/2 or 1/4 size of the left display viewer. As the purpose of a bitmap is to show it in the viewer in the end anyway, clipped to a visible area. [c] That brings another question of SYSTEM function procedure SYSTEM.VAL. Is it a type cast similar to Pascal ^((type) (variable))? Need to understand better. Many thanks Tomas Begin forwarded message: Date: Wed, 5 Apr 2017 17:59:27 +0200 From: Tomas Kral <thomas.kral(a)email.cz> To: <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] FPGA - Bitmaps.Mod Hi Wojciech, Yes, I agree. But, I do not know, how to allocate dynamic structures on Oberon V07. As an example I am looking into the `Pictures.Mod' code, taken from ETH Oberon. This dynamic allocation. ... TYPE Addr = POINTER TO RECORD END; refr : Addr; VAR size: LONGINT; ... size := P.wth * P.height; SYSTEM.NEW(P.refr, size+10); P.address := SYSTEM.VAL(ADDRESS,P.refr); NEW(P.bitmap); Bitmaps.Define(P.bitmap,P.width,P.height,P.depth,P.address); ... How I could allocate dynamically in Oberon07, NEW(v) allows for v as variable? Tomas On Wed, 5 Apr 2017 12:16:29 +0000 "Skulski, Wojciech" <skulski(a)pas.rochester.edu> wrote: > > I am looking for a better way, as I believe the size needed can be > > calculated from Width, Height of the bitmap. > > Yes. The size of the display should not be fixed with inline numbers. > I am thinking that a usable System can be deployed with 800x600 > display. In general, the size of the display can/ should be changed > either on the fly or during compilation, which probably is not very > difficult to implement in a simple design which the FPGA Oberon > really is. > > W. > ________________________________________ > From: Oberon [oberon-bounces(a)lists.inf.ethz.ch] on behalf of Tomas > Kral [thomas.kral(a)email.cz] Sent: Wednesday, April 5, 2017 5:26 AM > To: Oberon(a)lists.inf.ethz.ch > Subject: [Oberon] FPGA - Bitmaps.Mod > > Hi, > > As part of my exercise I have converted ETH `Bitmaps.Mod' to V07. It > should be the basis for a bit map editor - `Paint.Mod' - next exercise > of mine. > > It is far from perfect, just made it to compile under V07, without > much thoughts. > > Few notes>>> > > [a] Bitmaps.DisplayBlock* is just copied from Display.CopyBlock* > with source and destination addresses modified as thus: > > sa := B.address + u0*4 + sy*128; da := Display.Base + v0*4 + dy*128; > > I am looking for a better idea, as I believe bitmap needs to be > clipped to fit into a visible area of a target frame. > > [b] New bitmap is allocated as a constant buffer > CONST > BufSize = 10000H; > ... > BEGIN > NEW(buffer) > END Bitmaps. > > I am looking for a better way, as I believe the size needed can be > calculated from Width, Height of the bitmap. > > TYPE > Bitmap* = POINTER TO BitmapDesc; > BitmapDesc* = RECORD (* cf. Display.DisplayBlock *) > width*, height*, depth*: INTEGER; (* offset 0, 2, 4 *) > wth*, address*: LONGINT; (* offset 8, 12 *) > size: LONGINT > END; > > [c] Bitmaps are allocated as an array of CHAR's. Is it a good idea to > use BYTE's instead? > > P.S. I could enclose the whole module, but I am not sure if it is > allowed by the list server. > > Many thanks > Tomas > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related > systems > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mail… > -- 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 10

FPGA - Bitmaps.Mod
by Andreas Pirklbauer 07 Apr '17

07 Apr '17

Alternatively, you can implement an allocation procedure that accepts a 'size' argument as follows: PROCEDURE New*(VAR ptr: LONGINT; size: LONGINT); 1. Create a type descriptor 'td', persist and initialize it (e.g., td.size := size..) 2. Set tag := ADR(td) 3. Call Kernel.New(ptr, tag) - - - - - - - - - - - - - - - - - - - - - - - - Tomas Kral thomas.kral at email.cz Fri Apr 7 19:00:23 CEST 2017Hi Joerg, Andreas, All, Yes I made a mistake, corrected a while ago. But, how about implementing Bitmaps -> Bitmaps/PictureFrames trough FileRiders, so the allocation will occur in chunks of 1024 disk sectors. This will be on analogy with Texts/Frames and Files. May be also an ultimate answer to `how to edit a file' (text / bitmap) that is bigger than the system memory. But again not sure I am not being silly Tomas On Fri, 7 Apr 2017 18:43:55 +0200 Jörg <joerg.straube at iaeth.ch> wrote: > Hi Tomas > > Kernel.New is really a low level procedure and should not be used. > The place where you found it is another low level procedure when a > trap is generated. > > A challenge with pointer hacking and SYSTEM procedures is that you > should know what you are doing. e.g that your code compiled is a nice > example to show that pointer hacking is dangerous. You didn’t use > SYSTEM.ADR(b.size), so your code will not work although it compiled. > > If you want to take the „Dpt“ parameter into account, you should > adopt the size calculation. > > Jörg > > > Am 07.04.2017 um 16:01 schrieb Tomas Kral <thomas.kral at email.cz>: > > > > Hi Joerg, > > > > Having also another thought of Bitmaps implementation. > > Since a bitmap might have some file disk representation in the end, > > I am thinking to have it implemented similarly as Texts(Viewers), > > where 1024 byte disk sectors `Files.Mod' are mapped through linked > > list text descriptors. So in theory only one sector can be > > displayed through a viewer at a time. > > > > When I quickly look at PO.V5 source, Kernel.New is used exactly > > once. > > > > pi at raspberrypi /usr/src/oberon/PO.V5.1 $ grep Kernel.New *.Mod.txt > > System.Mod.txt: IF w = 0 THEN Kernel.New(a, b) > > > > So I do not feel easy breaking this rule, making it a precedence for > > more frequent use. > > > > On the analogy, I could have Bitmaps -> BitmapDescr(PictureDescr) -> > > PictureFrames > > > > I am not at all sure if it is a good idea? > > > > Tomas > > > > On Fri, 7 Apr 2017 14:10:31 +0200 > > Jörg <joerg.straube at iaeth.ch> wrote: > > > >> No. > >> > >> The first parameter is declared VAR, so the address of "b.base" is > >> handed over. The second parameter shall be a pointer to a type tag. > >> The size of a type is stored at offset 0 of the type tag. > >> > >> Kernel.New expects the parameter "tag" to be a pointer to type tag. > >> SYSTEM.ADR(b.size) is interpreted as a pointer to a type tag. > >> > >> The code I was providing is not something a beginner in Oberon > >> should use! 1) It's dirty pointer hacking, something that normally > >> C is famous for :-) 2) it's very low level, as it bases on > >> internals of the implementation of the Oberon memory management. > >> > >> But there are typos in my code > >> - Firstly, you have to IMPORT SYSTEM as well. > >> - Secondly, we have to compare "b.base" to 0 iso NIL, as "b.base" > >> is not a pointer. > >> > >> br > >> Jörg > >> > >> -----Original Message----- > >> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of > >> Tomas Kral Sent: Freitag, 7. April 2017 12:55 > >> To: oberon at lists.inf.ethz.ch > >> Subject: Re: [Oberon] Fw: FPGA - Bitmaps.Mod > >> > >> Hi Joerg, > >> > >> Should it not be coded rather like this? > >> Kernel.New(SYSTEM.ADR(b.base), b.size); > >> > >> On Fri, 7 Apr 2017 11:43:45 +0200 > >> Jörg <joerg.straube at iaeth.ch> wrote:

1 0

FPGA - Bitmaps.Mod
by Tomas Kral 05 Apr '17

05 Apr '17

Hi, As part of my exercise I have converted ETH `Bitmaps.Mod' to V07. It should be the basis for a bit map editor - `Paint.Mod' - next exercise of mine. It is far from perfect, just made it to compile under V07, without much thoughts. Few notes>>> [a] Bitmaps.DisplayBlock* is just copied from Display.CopyBlock* with source and destination addresses modified as thus: sa := B.address + u0*4 + sy*128; da := Display.Base + v0*4 + dy*128; I am looking for a better idea, as I believe bitmap needs to be clipped to fit into a visible area of a target frame. [b] New bitmap is allocated as a constant buffer CONST BufSize = 10000H; ... BEGIN NEW(buffer) END Bitmaps. I am looking for a better way, as I believe the size needed can be calculated from Width, Height of the bitmap. TYPE Bitmap* = POINTER TO BitmapDesc; BitmapDesc* = RECORD (* cf. Display.DisplayBlock *) width*, height*, depth*: INTEGER; (* offset 0, 2, 4 *) wth*, address*: LONGINT; (* offset 8, 12 *) size: LONGINT END; [c] Bitmaps are allocated as an array of CHAR's. Is it a good idea to use BYTE's instead? P.S. I could enclose the whole module, but I am not sure if it is allowed by the list server. Many thanks Tomas

3 5

Re: [Oberon] Ceres and Lilith
by Chris Burrows 03 Apr '17

03 Apr '17

Here's some Ceres / ETH related info with some good photos and a link to the video from Oberon Day in 2011 where Prof Wirth demonstrated on one: http://cpu-ns32k.net/Ceres.html Jos Dreesen who wrote the amazing Lilith emulator, EmuLith, has a working Lilith. You can view a number of photos and download his emulator from here: ftp://ftp.dreesen.ch/Emulith Regards, Chris Burrows CFB Software http://www.cfbsoftware.com/modula2 > > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > thomas.kral(a)email.cz > Sent: Thursday, 23 March 2017 8:27 PM > To: ETH Oberon and related systems > Subject: Re: [Oberon] FPGA Oberon - Reset Button > > Hi Magnus, Hi Paul, > > Yes, now I see, I am sorry for asking when it should be obvious from > the verilog source. > I am studying the code, while trying to get myself on a free verilog > course for beginners. > > BTW, are there some of the original machines, Lilith, Ceres still > preserved at ETH? > > Tomas > >

5 8

FPGA Oberon - Reset Button
by thomas.kral＠email.cz 01 Apr '17

01 Apr '17

Hi, I wish to install reset switch, which pin header / button is the reset? Perhaps, I should be somehow able to read from Verilog source, but I cannot so far. My board has these also mapped to Oberon. Connector J8 5V GND GPIO0 GPIO1 GPIO2 GPIO3 GPIO4 GPIO5 GPIO6 GPIO7 3.3V GND BTN0 BTN1 BTN2 BTN3 N/C N/C N/C N/C Tomas

4 8