[Oberon] FPGA - Bitmaps.Mod

[Tomas Kral]

Hi,

Sounds good, although most of it is currently beyond my capabilities.

Although, I have started with some Verilog examples, I am running a
fresh install of Xilinx WebPack synthesis tool on my x86 Linux machine,
while my `Pepino Oberon' system is connected to RPI.

I have two versions of VID.v modified for 4bit colour display by Magnus
(a father to Pepino), one w/ the other w/o simple colour map. These are
simple mods.

Would be nice to have also VID.v modified so that B&W is
displayed always and colours only if they are defined, like colour film
negative exposed on Black&White positive paper, or on Colour positive
paper = B&W / Coulour monitor switch.  

I think the idea is mentioned, the Project Oberon, chapter 4.5. raster
operations, figure 4.9.

"Each cell is vertically split into two congruent regions, where the
corresponding monitor is to select one of them. Cells for B&W
monitors are allocated to the left of Coulour monitors."  

I will learn in some time, if not before too long.

Tomas 

On Wed, 5 Apr 2017 16:37:39 +0200
Jörg <joerg.straube at iaeth.ch> wrote:

> Hi
> 
> In ProjectOberon, driving a display needs two components:
> a) The Oberon code (Display.Mod) and
> b) the Verilog code (VID.v)
> 
> Obviously, there is an interaction between those two parts
> - The Oberon code and the Verilog code need to agree on the memory
> layout (start address, W, H, color depth, color arrangement...)
> - The Oberon code writes to the memory
> - The Verilog code reads the memory and is responsible for the correct
> timing towards the monitor.
> 
> If you want to make the resolution more flexible, my proposal is to
> do it like this:
> - We should reserve a new IO address to control it.
> - The Oberon code sets a resolution nbr (1, 2, 3...) by writing to
> this new IO address
> - The Verilog code defines W, H, color per resolution nbr and adapts
> its timing accordingly.
> - The current values can be read by Oberon code by reading from the IO
> address.
> - Display.Mod has to be generalized for arbitrary W and H
> 
> This is the totally generic, flexible approach but complicates the
> code drastically.
> Perhaps a restriction to two (hard coded) resolutions is a little
> easier...
> 
> br
> Jörg
> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Skulski, Wojciech
> Sent: Mittwoch, 5. April 2017 14:16
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] FPGA - Bitmaps.Mod
> 
> > 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 at lists.inf.ethz.ch] on behalf of Tomas
> Kral [thomas.kral at email.cz]
> Sent: Wednesday, April 5, 2017 5:26 AM
> To: Oberon at 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 at 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_mailm
> an_listinfo_oberon&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=
> uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=DvMJJZHAOKHy3Hs2z-YZccHRjLN1IH
> NBtOGNQLn5RlM&s=F7FNN9bt9xLyOvUo8KvsencklngbrOcpcuN-9SYl_Gk&e= --
> 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