[Oberon] FPGA - Colour Support

Skulski, Wojciech skulski at pas.rochester.edu
Mon Oct 16 21:11:11 CEST 2017


  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.


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


  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.


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=Pc3NgDhR44AAaUb4cTFjdhk0A3M2lSt1ZTyoJsp4SfE&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.

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!! :)


Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems

More information about the Oberon mailing list