[Oberon] FPGA - Colour Support

Tue Oct 17 09:50:27 CEST 2017

Hi All,

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.

http://excamera.com/sphinx/gameduino2/

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.

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.

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.

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.

I produced a small pcb that has the FT812, XGA output via Sub D-15
connector and PS/2 sockets for keyboard  and mouse

http://sustburbia.blogspot.co.uk/2016/01/meet-evita.html

regards

Ken

On 16 October 2017 at 20:11, Skulski, Wojciech <skulski at pas.rochester.edu>
wrote:

> Paul:
>
>   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:
>
> 4.1.2 Serial Data Protocol
>
> The FT81x appears to the host MPU/MCU as a memory-mapped SPI device. The
> host communicates with
> the FT81x using reads and writes to a large (4 megabyte) address space.
> Within this address space are
> dedicated areas for graphics, audio and touch control. Refer to section 5
> for the detailed memory map.
> The host reads and writes the FT81x address space using SPI transactions.
> These transactions are
> memory read, memory write and command write. Serial data is sent by the
> most significant bit first.
> Each transaction starts with CS_N goes low, and ends when CS_N goes high.
> There’s no limit on data
> length within one transaction, as long as the memory address is continuous.
>
> 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.
>
> 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.
>
> 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.
>
> Just my three groshes, as usual.
>
> W
>
> ________________________________________
> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Skulski,
> Wojciech [skulski at pas.rochester.edu]
> Sent: Monday, October 16, 2017 2:10 PM
> To: paulreed at paddedcell.com; ETH Oberon and related systems
> Subject: Re: [Oberon] FPGA - Colour Support
>
> Paul:
>
>   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.
>
> 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=Pc3NgDhR44AAaUb4cTFjdhk0A3M2lS
> t1ZTyoJsp4SfE&s=7Koe6flmQehmKPxwgsX8sLOhWYq_unsCxbA24mGpviU&e=
>
> FT812 FT81x IC with 24-bit RGB, resistive touch control, 56 Pin VQFN
> FT813 FT81x IC with 24-bit RGB, capacitive touch control, 56 Pin VQFN
>
> 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.
>
> This chip was put on an eval board, of course:
> 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=Pc3NgDhR44AAaUb4cTFjdhk0A3M2lS
> t1ZTyoJsp4SfE&s=QlCY3XhUJo1Djh4hMEf_nlBvdfJWw-HtWOOOhXXeJT4&e=
>
> Going in this direction could possibly lead to product development based
> on FPGA Oberon, or ARM Oberon, or Astrobe Oberon for that matter.
>
> W.
> ________________________________________
> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Paul Reed [
> paulreed at paddedcell.com]
> Sent: Monday, October 16, 2017 12:38 PM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] FPGA - Colour Support
>
> > BTW: The nice thing with 800x600, we could use a pixel clock of 50 MHz
> :-)
>
> Tell me about it - that would have been so much easier!! :)
>
> Cheers,
> Paul
>
>
> --
> 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=DwICAg&c=
> kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_
> BM9w1wVOuyqPwHi3XzJRa-ybV0&m=Pc3NgDhR44AAaUb4cTFjdhk0A3M2lS
> t1ZTyoJsp4SfE&s=MHuUpnOvYP1nLs8U-lScXSoPsrC8zQ0nnkz5WYykfKA&e=
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171017/02b84bd8/attachment.html>