[Oberon] FPGA - Bitmaps.Mod

[Jörg]

Tomas

Copying screen memory to off-screen memory is one thing; this is what Bitmaps should do.
Writing and reading a file to memory (be it displayed on screen or hidden) is a totally separate thing.

If you look at google maps and try to display a certain area over a slow Internet connection you will realise that Google maps splits the whole surface of the Earth in tiles of same size.
So Google maps has a huge file with thousends of tiles and the visible tiles will be loaded via the Internet and displayed on screen.
The main part of the application is a clever and fast way to decide which tiles are visibla and which are not visible, locate those in the huge file storage and bring them to screen.

Bitmaps is a means to copy off-screen memory to screen memory and vice versa. Fonts.Mod is another example where off-screen memory (the font) is copied to on-screen memory. The font allocation is not as dynamic as the Bitmap you intend to implement. There are only two static sizes: Fonts (~2KB) and LargeFonts (~5KB)

An application to scroll on a huge picture (larger than the screen) is a separate application where a working Bitmaps.Mod can help but is not necessary.
Bitmaps is of use e.g. if you want to display menus. You first have to store the screen-memory that will be covered by the menu to off-screen memory. You can then draw the menu and handle the mouse events. Afterwards you can restore the screen by copying the Bitmap you stored previously back to screen again.

br
Jörg

> Am 07.04.2017 um 19:00 schrieb Tomas Kral <thomas.kral at email.cz>:
> 
> 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
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon