[Oberon] FPGA - Bitmaps.Mod

[Skulski, Wojciech]

Jorg:

in practice the arbitrary sizes are not supported.  There is a bunch of display configurations to choose from. These days there are quite a few of these, like wide screen, large rectangular screen, etc. The single hardwired screen size was probably driven by the particular hardware which NW/PR had on hand, which was OK for a demo. But such fixed choices are against Niklaus Wirth's own teaching.

W.. 
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Jörg [joerg.straube at iaeth.ch]
Sent: Wednesday, April 5, 2017 10:37 AM
To: 'ETH Oberon and related systems'
Subject: Re: [Oberon] FPGA - Bitmaps.Mod

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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=NE865Rd_w0WoPpqZkXE3Y90kyjOzOpY7WQBdTdAFLC4&s=gSfOdK5Xs89hFiqEUI-7t_gduGm5ESkKP6mJi2g7RhM&e=

--
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_mailman_listinfo_oberon&d=DwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=NE865Rd_w0WoPpqZkXE3Y90kyjOzOpY7WQBdTdAFLC4&s=gSfOdK5Xs89hFiqEUI-7t_gduGm5ESkKP6mJi2g7RhM&e=