[Oberon] FPGA - Bitmaps.Mod

[Tomas Kral]

Hi 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:
> >> 
> >>> Kernel.New(b.base, SYSTEM.ADR(b.size));
> >> --
> >> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> >> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >> 
> >> --
> >> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> >> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
> > 
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> > systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon