Golborne Vintage Radio

Having the framestore in the FPGA makes it all amazingly easy. Outboard SRAM is good, a bit less complex than DRAM for doing multiport access. 512K is enough for a frame but there isn't much space to waste. For example you can't simplify addressing by allowing 1K pixels per line.

That is a nice board for incorporating into a project.
If it had enough memory in the FPGA I would be tempted to switch to Xilinx.

Frank

Thinking about using external SRAM for a framestore, if some ports are mutually synchronous (for example reading from 4 successive lines) then there is no absolute need for overhead for port switching., just like with internal FPGA RAM. However this requires that the SRAM clock is synchronous to those ports. For example if you're reading 4 ports at 13.5MHz then clocking the SRAM at 108MHz would make sense. You can read the 4 ports on succesive cycles of 108MHz leaving adequate time to switch to a write port that isn't synchronous.

For the user interface I am using a 18LF24K22 microcontroller a 16 X 2 LCD display and two rotary encoders with push switches.
I will use separate push switches if I find I need them and will increase the size of display to a 20 x 4 if needed.

I had the 18LF24K22 left over from a water meter/leak detector project. It's a 28 pin device. If I find that it has not enough memory I can change to the 18LF26K22 which is the same microcontroller but with four times the memory. I am running it off it's internal oscillator as frequency stability is not important.

I have the microcontroller talking to the FPGA
I could have done it with 2 wires but I have gone for 3 clock, data and start.
The third wire makes the logic at the receive end very simple but most of all it is convenient for triggering an oscilloscope to check what is being sent as I debug.
I have it setup to send  24 bytes but that can be increased if needed.

The write frequency to the frame store will be constant at 13.5 MHz. Read frequency will vary quite a bit.

The microcontroller calculates the output clock as follows
(front porch + sync + back porch + active line) * no. of lines * frame rate = frequency in Hz
Front porch, sync, back porch and active line are all in cycles(or pixels).
Active line and frame rate are constants.
All others are variables and eventually will be able to be set between preset values via a menu.

The output clock frequency is sent to the FPGA where it is multiplied with a coefficient the result is the coefficient for the output clock DTO.

if covering a range for example of 100 to 820 lines the output clock will vary from approximately 2 MHz to 18 MHz.

A couple of photos.
The first is the user interface built on a couple of scraps of stripboard.
Its hard to see the display but the front porch is set to a crazy value of 600 (would be normally around 73) and the active lines is set to 354.
The second photo shows the result displayed on the monitor. At these settings the output clock is operating at over 21 MHz.

Frank

Just a bit of an update on this project.
I have been doing some work on the PCB. I like to work on all aspects of a project like this at the same time as a small component change can make the software easier/better or a change to the software can make the PCB layout easier etc.

I was hoping that I would be able to fit this project onto the same size PCB as Hedghog II and into the same case.

I started off with the Hedghog II PCB and removed the toggle and DIL switches as they will not be needed. I changed the location of the R2R DAC and juggled around the connections to some pins on the FPGA. With all this done there will be enough room for the frame store, microcontroller, 2 rotary encoders and a display.

The biggest obstacle to fitting it into the same case was the display. The display that I was using was a common 16 X 2 LCD display and it simply would not fit.
I decided to try a 128 X 32 pixel OLED display. They are tiny compared to the LCD display that I was using and would fit in the case. I thought the text on them may be too small to read. But to my surprise even when displaying 4 lines of text they are still easy enough to read. They come with two types of communication SPI or I2c. SPI is the fastest but the I2c type is easier to fit on the PCB. I use software I2c for programming the modulator chips because it is easy in software to create a SDA line for each modulator chip. Software I2c I found was too slow for the OLED display. It took too long to refresh. So I have it running from hardware I2c which gives acceptable results.

I have decided to stick with the AL422 frame store. I have made a lot of changes to the PCB and I felt changing the framestore as well might just be too much at once.

Picture of the OLED display with the 16 X 2 LCD alongside for comparison.

Frank

Cute display, even I can read it without glasses, will look good in the case.

Slight heads-up and apologies if you already are aware of this, but oled displays have a significantly shorter lifespan than LCDs and they are highly susceptible to failure if there is any ingress of oxygen or moisture. They can also slowly degrade, with visibility falling off with prolonged use.

I only really became aware of this as I have some expensive Keysight test equipment with oled displays, and one failed after only 3 years. I had many discussions with Keysight customer support (who were excellent) who admitted this was a known issue generally with oleds, but in the end the unit had to be returned to them in the UK, shipped to Malaysia for factory repair, then back to the UK then out to me in the gulf!

Hi Nick
Thanks for the heads up on the displays. Good to hear from someone with experience of it.
I had heard that they have a relatively short life before they start to dim. The display will be only used for entering the various values. I intend writing a routine that after a delay the display will be cleared and put into sleep mode. As it will only be on for short periods of time it might work out OK. They are cheap at around a £ each.

That Keysight equipment of yours has a lot more air miles put up than I and I suspect the display cost much more than a £.

Frank

Frank, I think that OLED displays can simply go bad with time, regardless of whether they are being used.

Best bet is to write your software so it can easily be switched between OLED and LCD displays.

Is there any reason to minimise the size of this converter? Cost matters if it's a commercial or semi-commercial product but it wouldn't matter if this design was bigger all round. Then if you come up with some idea in the future it stands a chance of fitting in the box.

This is a good point. You can get HD44780/1602A interfaces for OLED displays... Perhaps just write for the HD44780 or 1602A over i2c then folk can use whatever they want?