Hi, I wish to modify `Display.Mod' to accept 4-bit colour. Standard interface currently supports 1-bit colour only. PROCEDURE Dot*(col, x, y, mode: INTEGER); PROCEDURE ReplConst*(col, x, y, w, h, mode: INTEGER); PROCEDURE CopyPattern*(col, patadr, x, y, mode: INTEGER); PROCEDURE CopyBlock*(sx, sy, w, h, dx, dy, mode: INTEGER); PROCEDURE ReplPattern*(col, patadr, x, y, w, h, mode: INTEGER); I have a version of VID.v with 4-bit pixels and a 16 entry colour lookup table. So `col' parameter in the range {0..15} defines index into that table. Looking at the code, I realise each display line takes 128 bytes 1-bit. 4-bit it must be 4*128. While single word sets 1-bit colour of 32 pixels, and only 8 pixels of 4-bit colour, correct? I am generally seeking advice for the good starting point, also hwoto set up a test environment for quick tests turnaround? My idea was to make a standalone boot program accepting draw commands over serial. I may start with `ReplConst' (font rendering), and `ReplConst' (line drawing). I wonder how much of the original code I could reuse, just extending the loop count, and some 4-bit manipulation? Many thanks in advance. -- Tomas Kral <thomas.kral@email.cz>
________________________________________ From: Oberon [oberon-bounces@lists.inf.ethz.ch] on behalf of Tomas Kral [thomas.kral@email.cz] Sent: Friday, August 10, 2018 7:38 AM To: Oberon@lists.inf.ethz.ch Subject: [Oberon] FPGA - Display.Mod 4-bit colour Hi, I wish to modify `Display.Mod' to accept 4-bit colour. Standard interface currently supports 1-bit colour only. PROCEDURE Dot*(col, x, y, mode: INTEGER); PROCEDURE ReplConst*(col, x, y, w, h, mode: INTEGER); PROCEDURE CopyPattern*(col, patadr, x, y, mode: INTEGER); PROCEDURE CopyBlock*(sx, sy, w, h, dx, dy, mode: INTEGER); PROCEDURE ReplPattern*(col, patadr, x, y, w, h, mode: INTEGER); I have a version of VID.v with 4-bit pixels and a 16 entry colour lookup table. So `col' parameter in the range {0..15} defines index into that table. Looking at the code, I realise each display line takes 128 bytes 1-bit. 4-bit it must be 4*128. While single word sets 1-bit colour of 32 pixels, and only 8 pixels of 4-bit colour, correct? I am generally seeking advice for the good starting point, also hwoto set up a test environment for quick tests turnaround? My idea was to make a standalone boot program accepting draw commands over serial. I may start with `ReplConst' (font rendering), and `ReplConst' (line drawing). I wonder how much of the original code I could reuse, just extending the loop count, and some 4-bit manipulation? Many thanks in advance. -- Tomas Kral <thomas.kral@email.cz> -- Oberon@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=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=rgc4UlGJzkV0C0pi7Xsmf4LQ8NvkToduvf4OWisbBlA&s=Ihyl9pTNMCya05s4QzVnlF4GNIGd0QCGHTpOWcd69Rc&e=
Magnus did this already on Pepino. W. Excuse me for teh previous empty message ________________________________________ Thomas wrote: I wish to modify `Display.Mod' to accept 4-bit colour. Standard interface currently supports 1-bit colour only.
Tomas Do you want it to do yourself from scratch to learn something or just use my code? Jörg
Am 10.08.2018 um 13:38 schrieb Tomas Kral <thomas.kral@email.cz>:
Hi,
I wish to modify `Display.Mod' to accept 4-bit colour. Standard interface currently supports 1-bit colour only.
PROCEDURE Dot*(col, x, y, mode: INTEGER); PROCEDURE ReplConst*(col, x, y, w, h, mode: INTEGER); PROCEDURE CopyPattern*(col, patadr, x, y, mode: INTEGER); PROCEDURE CopyBlock*(sx, sy, w, h, dx, dy, mode: INTEGER); PROCEDURE ReplPattern*(col, patadr, x, y, w, h, mode: INTEGER);
I have a version of VID.v with 4-bit pixels and a 16 entry colour lookup table. So `col' parameter in the range {0..15} defines index into that table.
Looking at the code, I realise each display line takes 128 bytes 1-bit. 4-bit it must be 4*128. While single word sets 1-bit colour of 32 pixels, and only 8 pixels of 4-bit colour, correct?
I am generally seeking advice for the good starting point, also hwoto set up a test environment for quick tests turnaround? My idea was to make a standalone boot program accepting draw commands over serial.
I may start with `ReplConst' (font rendering), and `ReplConst' (line drawing).
I wonder how much of the original code I could reuse, just extending the loop count, and some 4-bit manipulation?
Many thanks in advance.
-- Tomas Kral <thomas.kral@email.cz> -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
Hi, As advised and encouraged by Joerg this is my first try at Oberon IN {0..3} colour. Please do not laugh :-) as everything is in yellow, except Log viewer, (strange?), font render has problems, possibly some other flaws, I do not see yet. I set these constants to make a switch to 4-bit. I believe the white now truly is {0,1,2,3} = 15, rather than {0} = 1. But changing it, would invalidate clients, making a different import KEY. MODULE Display2; (*NW 5.11.2013 / 3.7.2016, TK 30.8.2018 4-bit colour*) IMPORT SYSTEM, O := Out; CONST black* = 0; white* = 1(*5*); (*black = background*) replace* = 0; paint* = 1; invert* = 2; (*modes*) base = 0E7F00H; (*adr of 1024 x 768 pixel, monocolor display frame*) (*base = 09FF00H;*) (*adr of 1024 x 768 pixel, 4-bit colour display frame*) ppw = 32(*8*); (*pixels per word*) bpl = (*4*)128; (*bytes per line*) -- Tomas Kral <thomas.kral@email.cz>
Tomas Great! If I look at your screenshot, seems that your CopyPattern() does work in most case but not in all. Perhaps something is wrong with your shifting or with your colors or with both... Try to draw the same character (in the below case "E") at different x positions. MODULE Test; IMPORT Fonts, Display; PROCEDURE Do*; VAR x, col, patE: INTEGER; BEGIN Fonts.GetPat(Fonts.Default, "E", x, x, x, x, x, patE); FOR x := 0 TO 7 DO FOR col := 0 TO 16 DO Display.CopyPattern(col, patE, 30+i+col*8, 20+i*11, Display.paint) END END END Do; END Test.Do Do the "E"s display correctly in all cases? br Jörg -----Original Message----- From: Oberon <oberon-bounces@lists.inf.ethz.ch> On Behalf Of Tomas Kral Sent: Monday, September 3, 2018 12:33 PM To: oberon@lists.inf.ethz.ch Subject: Re: [Oberon] FPGA - Display.Mod 4-bit colour Hi, As advised and encouraged by Joerg this is my first try at Oberon IN {0..3} colour. Please do not laugh :-) as everything is in yellow, except Log viewer, (strange?), font render has problems, possibly some other flaws, I do not see yet. I set these constants to make a switch to 4-bit. I believe the white now truly is {0,1,2,3} = 15, rather than {0} = 1. But changing it, would invalidate clients, making a different import KEY. MODULE Display2; (*NW 5.11.2013 / 3.7.2016, TK 30.8.2018 4-bit colour*) IMPORT SYSTEM, O := Out; CONST black* = 0; white* = 1(*5*); (*black = background*) replace* = 0; paint* = 1; invert* = 2; (*modes*) base = 0E7F00H; (*adr of 1024 x 768 pixel, monocolor display frame*) (*base = 09FF00H;*) (*adr of 1024 x 768 pixel, 4-bit colour display frame*) ppw = 32(*8*); (*pixels per word*) bpl = (*4*)128; (*bytes per line*) -- Tomas Kral <thomas.kral@email.cz>
I believe the white now truly is {0,1,2,3} = 15, rather than {0} = 1. But changing it, would invalidate clients, making a different import KEY.
Hi, Now I have two display modules, `Display.Mod' and `Display2.Mod' handling 1-bit and 4-bit colour respectively. While there could be a single driver `vid.v' selecting the mode by a switch e.g. swi[6], adjusting video base accordingly. Can the system somehow boot with either `Display' or `Display2' based on the swi[6]? `Display' is imported by other modules `Oberon',`Viewers',.. -- Tomas Kral <thomas.kral@email.cz>
Tomas No. The current Display subsystem in ProjectOberon is not prepared for different "video drivers". You would have to re-write the Display subsystem to be object oriented. With such an approach, all Display procedures Dot, CopyPattern... are procedure variables to be initialized with the correct procedures of the chosen "video driver". Basically, Display can then be seen as kind of dispatcher module for the underlying video driver. But most probably the easiest is to keep the interface of your two Display modules identical. If so, compile DisplayBW.Mod (implementing MODULE Display;) and rename Display.rsc to DisplayBW.rsc Then compile DisplayColor.Mod (also implementing MODULE Display;) and rename Display.rsc to DisplayColor.rsc Now, the two files DisplayBW.rsc and DisplayColor.rsc are different implementations of Display having identical keys. Before booting, you have to copy the correct DisplayXY.rsc to Display.rsc br Jörg Am 01.10.18, 21:41 schrieb "Oberon im Auftrag von Tomas Kral" <oberon-bounces@lists.inf.ethz.ch im Auftrag von thomas.kral@email.cz>: > I believe the white now truly is {0,1,2,3} = 15, rather than {0} = 1. > But changing it, would invalidate clients, making a different import > KEY. Hi, Now I have two display modules, `Display.Mod' and `Display2.Mod' handling 1-bit and 4-bit colour respectively. While there could be a single driver `vid.v' selecting the mode by a switch e.g. swi[6], adjusting video base accordingly. Can the system somehow boot with either `Display' or `Display2' based on the swi[6]? `Display' is imported by other modules `Oberon',`Viewers',.. -- Tomas Kral <thomas.kral@email.cz> -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
participants (3)
-
Jörg -
Skulski, Wojciech -
Tomas Kral