<div dir="ltr">Hi All,<div><br></div><div>The FT81x is better known as being used in the GameDuino 2 gaming adaptor for Arduino. There is a Gameduino manual which illustrates some of the range of displays and graphical effects that are possible.</div><div><br></div><div><a href="http://excamera.com/sphinx/gameduino2/">http://excamera.com/sphinx/gameduino2/</a><br></div><div><br></div><div><br></div><div>It is really great for displaying animated sprites and the like - and well suited to 80's style games or generic GUI type applications - but it is not a general purpose graphics engine.</div><div><br></div><div>It's main limitation is that it is restricted to drawing 2048 items from a display list - and this includes text. So unless you keep your text screen down to 64x32 or 80x25 characters you will not be able to send a full screen of text.</div><div><br></div><div>That said - the FT81x is very flexible in it's display timing - and by fitting a 13MHz crystal rather than a 12MHz crystal - modest overclocking, - you can generate a 65MHz pixel clock - allowing a 1024x768 60Hz XGA screen resolution.</div><div><br></div><div>Whilst designed to drive the RGB inputs of LCD panels - the individual RGB data lines can feed resistor networks and using a similar method to VGA - can drive an external flat screen monitor.</div><div><br></div><div>I produced a small pcb that has the FT812, XGA output via Sub D-15 connector and PS/2 sockets for keyboard and mouse</div><div><br></div><div><a href="http://sustburbia.blogspot.co.uk/2016/01/meet-evita.html">http://sustburbia.blogspot.co.uk/2016/01/meet-evita.html</a><br></div><div><br></div><div><br></div><div>regards</div><div><br></div><div><br></div><div>Ken</div><div><br></div><div><br></div><div> </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 October 2017 at 20:11, Skulski, Wojciech <span dir="ltr"><<a href="mailto:skulski@pas.rochester.edu" target="_blank">skulski@pas.rochester.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Paul:<br>
<br>
a correction. I wrote " there is no memory mapped pixel map anymore". Actually, there might be such a map. The FTDI Data Sheet DS_FT81x.pdf says on page 15:<br>
<br>
4.1.2 Serial Data Protocol<br>
<br>
The FT81x appears to the host MPU/MCU as a memory-mapped SPI device. The host communicates with<br>
the FT81x using reads and writes to a large (4 megabyte) address space. Within this address space are<br>
dedicated areas for graphics, audio and touch control. Refer to section 5 for the detailed memory map.<br>
The host reads and writes the FT81x address space using SPI transactions. These transactions are<br>
memory read, memory write and command write. Serial data is sent by the most significant bit first.<br>
Each transaction starts with CS_N goes low, and ends when CS_N goes high. There’s no limit on data<br>
length within one transaction, as long as the memory address is continuous.<br>
<br>
Therefore, the changes to the Oberon System may be smaller than I initially thought. The memory-mapped pixel display may be still mapped to memory. It should be possible to write an HDL module which will automatically redirect the ASRAM-like memory access to the SPI interface. Therefore, the general idea of memory based display may be retained. On the other hand, some low-level bit raster operations are good candidates to get offloaded to the graphics engine itself. The graphics engine features are listed on page 22 of the Data Sheet.<br>
<br>
Since the Graphics Engine provides "buttons, clock, keys, gauges, text displays, progress bars, sliders, toggle switches, dials, gradients, etc.", quite a few applications could be developed in Oberon by calling these features rather than programming them via the raster operations. This would put an entirely different spin on application development. It would also shrink the memory requirements because lots of graphics functionality does not need to get programmed at all.<br>
<br>
The downside is that Oberon System would become dependent on the FTDI graphics. I am not sure if this is good or bad. Application development time would be reduced, but portability would be affected. It is a tradeoff worth considering.<br>
<br>
Just my three groshes, as usual.<br>
<br>
W<br>
<br>
______________________________<wbr>__________<br>
From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.<wbr>ethz.ch</a>] on behalf of Skulski, Wojciech [<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>]<br>
Sent: Monday, October 16, 2017 2:10 PM<br>
To: <a href="mailto:paulreed@paddedcell.com">paulreed@paddedcell.com</a>; ETH Oberon and related systems<br>
<span class="">Subject: Re: [Oberon] FPGA - Colour Support<br>
<br>
</span><span class="">Paul:<br>
<br>
here is something even easier. The entire graphics system is embedded inside the chip. All the timing, the memory, everything. You communicate with the chip over quad SPI, or even single wire SPI.<br>
<br>
</span><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ftdichip.com_Products_ICs_FT81X.html&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=Pc3NgDhR44AAaUb4cTFjdhk0A3M2lSt1ZTyoJsp4SfE&s=7Koe6flmQehmKPxwgsX8sLOhWYq_unsCxbA24mGpviU&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=http-3A__www.<wbr>ftdichip.com_Products_ICs_<wbr>FT81X.html&d=DwICAg&c=<wbr>kbmfwr1Yojg42sGEpaQh5ofMHBeTl9<wbr>EI2eaqQZhHbOU&r=uUiA_<wbr>zLpwaGJIlq-_<wbr>BM9w1wVOuyqPwHi3XzJRa-ybV0&m=<wbr>Pc3NgDhR44AAaUb4cTFjdhk0A3M2lS<wbr>t1ZTyoJsp4SfE&s=<wbr>7Koe6flmQehmKPxwgsX8sLOhWYq_<wbr>unsCxbA24mGpviU&e=</a><br>
<span class=""><br>
FT812 FT81x IC with 24-bit RGB, resistive touch control, 56 Pin VQFN<br>
FT813 FT81x IC with 24-bit RGB, capacitive touch control, 56 Pin VQFN<br>
<br>
In order to use this approach the core of the system needs be redesigned because there is no memory mapped pixel map anymore. Basically, think in terms of commands rather than raster operations. What you get in return is the complete freedom from any hardware discussions like we have had on this list. Just pure programming, and lots of it. You also get a touch screen, which can be of tremendous practical value.<br>
<br>
</span>This chip was put on an eval board, of course: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ftdichip.com_Products_Modules_EVE2Modules.html&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=Pc3NgDhR44AAaUb4cTFjdhk0A3M2lSt1ZTyoJsp4SfE&s=QlCY3XhUJo1Djh4hMEf_nlBvdfJWw-HtWOOOhXXeJT4&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=http-3A__www.<wbr>ftdichip.com_Products_Modules_<wbr>EVE2Modules.html&d=DwICAg&c=<wbr>kbmfwr1Yojg42sGEpaQh5ofMHBeTl9<wbr>EI2eaqQZhHbOU&r=uUiA_<wbr>zLpwaGJIlq-_<wbr>BM9w1wVOuyqPwHi3XzJRa-ybV0&m=<wbr>Pc3NgDhR44AAaUb4cTFjdhk0A3M2lS<wbr>t1ZTyoJsp4SfE&s=<wbr>QlCY3XhUJo1Djh4hMEf_nlBvdfJWw-<wbr>HtWOOOhXXeJT4&e=</a><br>
<span class=""><br>
Going in this direction could possibly lead to product development based on FPGA Oberon, or ARM Oberon, or Astrobe Oberon for that matter.<br>
<br>
W.<br>
______________________________<wbr>__________<br>
From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.<wbr>ethz.ch</a>] on behalf of Paul Reed [<a href="mailto:paulreed@paddedcell.com">paulreed@paddedcell.com</a>]<br>
Sent: Monday, October 16, 2017 12:38 PM<br>
To: ETH Oberon and related systems<br>
Subject: Re: [Oberon] FPGA - Colour Support<br>
<br>
> BTW: The nice thing with 800x600, we could use a pixel clock of 50 MHz :-)<br>
<br>
Tell me about it - that would have been so much easier!! :)<br>
<br>
Cheers,<br>
Paul<br>
<br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
</span><a href="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=Pc3NgDhR44AAaUb4cTFjdhk0A3M2lSt1ZTyoJsp4SfE&s=MHuUpnOvYP1nLs8U-lScXSoPsrC8zQ0nnkz5WYykfKA&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__lists.<wbr>inf.ethz.ch_mailman_listinfo_<wbr>oberon&d=DwICAg&c=<wbr>kbmfwr1Yojg42sGEpaQh5ofMHBeTl9<wbr>EI2eaqQZhHbOU&r=uUiA_<wbr>zLpwaGJIlq-_<wbr>BM9w1wVOuyqPwHi3XzJRa-ybV0&m=<wbr>Pc3NgDhR44AAaUb4cTFjdhk0A3M2lS<wbr>t1ZTyoJsp4SfE&s=<wbr>MHuUpnOvYP1nLs8U-<wbr>lScXSoPsrC8zQ0nnkz5WYykfKA&e=</a><br>
<div class="HOEnZb"><div class="h5">--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><br>
</div></div></blockquote></div><br></div>