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: