<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">>>What I cannot figure out so
      far, what modifications are need for VID.v, also where do I
      specify memory ranges, as with more colours, a longer memory
      display buffer is needed, as you explained already.<br>
      <br>
      The changes to VID.v are fairly trivial assuming 4 bits/pixel
      instead of 3 bits/pixel (i.e. 1 bit not used).  However, the video
      memory size will be 4x of today (i.e. about 40% of total memory)
      and the memory bandwidth used by video will also go up from about
      10% to about 40%.<br>
      <br>
      The memory ranges are specified in the bootloader, it will set
      MemLim and stackOrg.<br>
      The hardware video memory address is specified by the ORG
      parameter in VID.v<br>
      For software the video base address is set by the module Display.<br>
      <br>
      I will put together a modified VID.v for you to test.<br>
      <br>
      Magnus<br>
      <br>
      <br>
      <br>
      On 4/16/2016 11:35 PM, Tomas Kral wrote:<br>
    </div>
    <blockquote
      cite="mid:1460874957.3527.0.camel@lynx.localhost.localdomain"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="GENERATOR" content="GtkHTML/4.4.4">
      Dear Joerg,<br>
      <br>
      I am working on Bitmpas now, these seem an underlying abstraction
      for Paint.Mod.<br>
      Looking at Ceres-2 Display.Def, to support colours, if my
      understanding is right, I may need to set up a "colour map", an
      array assigning RGB triplets to col: INTEGER values.<br>
      <br>
      PROCEDURE SetColor*(col, red, green, blue: INTEGER);<br>
      PROCEDURE GetColor*(col: INTEGER; VAR red, green, blue: INTEGER);<br>
      <br>
      What I cannot figure out so far, what modifications are need for
      VID.v, also where do I specify memory ranges, as with more
      colours, a longer memory display buffer is needed, as you
      explained already.<br>
      <br>
      Many thanks.<br>
      <br>
      <table cellpadding="0" cellspacing="0" width="100%">
        <tbody>
          <tr>
            <td>
              -- <br>
              Tomas Kral <<a moz-do-not-send="true"
                href="mailto:thomas.kral@email.cz">thomas.kral@email.cz</a>><br>
              <br>
              <br>
            </td>
          </tr>
        </tbody>
      </table>
      On Mon, 2016-03-28 at 21:13 +0200, Jörg Straube wrote:
      <blockquote type="CITE">
        <pre>Tom
Having more than two colors needs at least the following
- adapt the Verilog code VID.v
- adapt Display.Mod

For 4 colours, you obviously need double the video memory than today (today= 98304 byte = 9.3% of total memory)

I think for a colour display it would be best to have more than 1 MB of memory.

Jörg



Gruss. Jörg
> Am 28.03.2016 um 20:45 schrieb Tomas Kral <<a moz-do-not-send="true" href="mailto:thomas.kral@email.cz">thomas.kral@email.cz</a>>:

> Hi,

> Thank you, I would like to try on Oberon FPGA Station. 

> I am also interested in the original pictures and Paint.Tool. Not sure
> if these are preserved somewhere?

> Grapes.Pict Eschew.Pict New.Pict Clown.Pict Clown16.Pict
> Paint.Tool

> I am led to believe FPGA is currently configured for two-colour Display
> buffer, it would be therefore interesting to experiment with more
> colours, if at all could be supported by the chip.

> Many thanks so far.


> -- 
> Tomas Kral <<a moz-do-not-send="true" href="mailto:thomas.kral@email.cz">thomas.kral@email.cz</a>>

>> On Fri, 2016-03-25 at 12:48 +0100, scrutinizer wrote:
>> paint.mod attached
>> let me know if you need some sample .pict files
>> 
>>> Date: Thu, 24 Mar 2016 21:26:47 +0100
>>> From: Tomas Kral <<a moz-do-not-send="true" href="mailto:thomas.kral@email.cz">thomas.kral@email.cz</a>>
>>> To: <a moz-do-not-send="true" href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>
>>> Subject: [Oberon] Oberon Paint.Mod
>>> 
>>> Hi,
>>> 
>>> I am curious about drawing programs for Oberon system as I am reading
>>> PO.Applications chapter, describing Draw.Tool implementation.
>>> 
>>> I have also seen a Clown picture at
>>> <a moz-do-not-send="true" href="https://en.wikipedia.org/wiki/Oberon_%28operating_system%29">https://en.wikipedia.org/wiki/Oberon_%28operating_system%29</a>
>>> 
>>> It shows Paint.Tool commands apparently coming from a Paint.Mod
>>> 
>>> Paint.Mod does not seem part of Oberon System, I am just curious where
>>> it originates?
>>> 
>>> Cheers Tom
>> 
>> --
>> <a moz-do-not-send="true" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
>> <a moz-do-not-send="true" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
> --
> <a moz-do-not-send="true" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
> <a moz-do-not-send="true" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>

--
<a moz-do-not-send="true" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
<a moz-do-not-send="true" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">--
<a class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
<a class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>