Hedghog L Standards Converter

[`FRANK.C]

I thought it was time to start a new thread as the previous one was about exploring the possibility of using the iCE40HX1K in a converter. This thread is about the converter.
I will call it "Hedghog L" as it uses a Lattice FPGA.
I done up a circuit for the complete converter and got a PCB made for it.
I have kept the rotary encoders and LCD display. Among other things keeping them will allow the modulators to be fully utilised.

I am using a PIC16F18856 microcontroller. There appears to be a decent amount of them in stock. One feature it has is a reference clock output module. The module has a selectable clock source. Which in this case will be a crystal controlled oscillator. It has a programmable clock divider and selectable duty cycle. This module will be used to provide the clock for the modulators. On all previous Hedghogs that clock was provided by the FPGA.

The microcontroller operates from 5V but it has to communicate with both 5V and 3.3V devices. I will be using open drain outputs on the microcontroller with pull up resistors to +V of the devices.
The inputs of the microcontroller can be configured as TTL. When configured as TTL any voltage of 2V or over is considered as logic 1.
The combination of open drain output and TTL input will allow bidirectional communication between the microcontroller and any of the devices.

One thing that I ran short of was pins on the microcontroller. The modulator chips MBS373 came to the rescue. Each modulator has one pin which is a logical output port that is controlled via I2C.
The port of each modulator is used to control one of the two analogue switches.

I have just done some basic tests on the microcontroller . I thought that I may be able to alter the microcontroller program from the PSC to suit. But after looking at it I think it will probably be easier to start from scratch.

I had hoped that this PCB would be a final one but that is not the case. There is a problem with it.
After populating it with components and powering up I discovered that there was a short on one of the 5V rails. It was eventually traced to the track being connected to ground at one point close to a via.
I cut the short away with a scalpel and every thing else worked fine. The PCB was designed on DesignSpark PCB. I checked the PCB again on DesignSpark using the design rule checker and no fault showed up.
But looking at the area on DesignSpark a short could be seen between the 5V track and the ground plane. At some stage I moved the via to make room for some tracks. Instead of the track that was connect to the via been shortened it doubled back on itself creating a tail. This in itself isn't a problem other than not being neat. One of the last things I do is a copper pour for the ground plane. It fills any part of the board that hasn't tracks with copper and connects it to ground where possible. It should keep an equal distance away from all tracks that aren't connected to ground. The copper pour should have avoided that tail but for some reason it didn't recognise it as a track. I guess for the same reason it didn't show up on the design rule check. I have been using DesignSpark for years and have used the same method many many times without incident. I guess sometimes %@!? happens. Could have been worse at least it was easily corrected. The area can be seen on the photo of the top of the PCB. It is the via just above where "LCD CONTRAST" is printed.

Frank

[pamphonica]

Hi Frank,
I am as ever in awe of your capabilities in this area. My Hedghog 1 gets regular use.
This one looks awesome, and an LCD display will allow much simpler (and possibly more comprehensive) changing of features.
More power to your (very fine) soldering iron.
See you at Retrotech if not before.
all best
Jeremy

[ppppenguin]

Well done again. The old problem of finding enough pins on a FPGA or microcontroller Darryl had similar problems with the Aurora.

[Freya]

Great work as always, the PCB layout looks very similar to the PSC, did you modify it to suit the new components or start from scratch ?The LCD is a great addition .
What are its features in comparison to previous versions.

Stephen

[`FRANK.C]

Thanks for all of your encouraging comments

Jeremy
The soldering iron is willing. The eyes not so much so.

Jeffrey
I haven't been this tight on pins before. Still I have one spare yet. As the TVP5150 has one that can be used as a logic port. The ones on the modulators were more convenient to use.

Stephen
Yes, I used as much of the PSC PCB as I could. No point reinventing the wheel . I removed the FPGA, Frame store, Flash memory, PIC,  JTAG connector and the 2.5V regulator from the PSC PCB.
The 2.5V regulator isn't need with the lattice FPGA. There is one pin on the iCE40HX1K that needs 2.5V. I have used a Schottky diode from the 3.3V rail to supply it. I have used the diode because any circuits that I have seen the iCE40HX1K used in, this is the way it has been done including Lattice own development boards.
That pin supplies a nonvolatile one time programmable configuration memory. It can be used instead of external flash memory when the firmware is finalised. It is of no use in this project as more than one programme image will be use.

The features this converter will have has not been finalised yet. I am still working the firmware for the FPGA and have not really started the programme for the PIC yet.
But I see them something along these lines.

The converter is a 2 line, very cut down version of what was in the earlier Hedghogs. So technically not to the same standard but still gives a good conversion.
Selectable equalising pulses
Selectable 4:3 => 4:3, 4:3 => 5:4, 16:9 => 4:3 and 16:9 => 5:4 aspect ratio conversion.
All that wont fit into a single image but from the tests I have done I should be able to spread it across 2 images.
The third image will be a 405 line test card.

This leaves the fourth image going spare.
Into this I am going to try and fit a basic 625 to 819 line converter.

Frank

[Freya]

Those options sound very usable, would it not be easier to have a totally separate firmware just for the 819 line. This would allow an extra 405 line image for something ?
Obviously i don't know is this workable.

Stephen

[`FRANK.C]

Hi Stephen
The thing is that I have exhausted all that can be done 405 line wise with the iCE40HX1K.
Each image is actually separate firmware and is stand alone.

An example is the image that does the test card. In previous Hedghogs the test card was a just a component and it sort of piggybacked on the converter. It used the convertors sync pulse generator as well as other parts need to produce the video.
In the Hedghog L the image that is used for the test card has the test card but also has the sync pulse generator and all the other parts needed to enable it to produce the video. So it is completely stand alone.

Each image is wrote and tested separately in the FPGA.
It is only when all of them are completed that they are combined together with a bootloader into a single piece of firmware.

Unlike previous Hedghogs JTAG isn't used. Instead the firmware is programmed directly into Flash memory chip using SPI.

Frank

[Freya]

That explains it very well, thanks

[Murphyv310]

I've always wondered if it's possible to do NTSC 405 Frank? I had two NTSC Aurora's for 405 lines but in my dark days they went, I didn't even check the ones I parted with nor to whom they went to...... A rather deep regret on my part.
Would it be possible with the Hedghog project?

PS would a NTSC 405 line encoder be a possibility with it being fed from the PC with 405 line RGB?

[ppppenguin]

I encouraged Darryl to do the 405 NTSC version of Aurora. The design isn't difficult, but it does use a lot more FPGA resources. Darryl had to use a bigger FPGA that fitted on the same footprint as the original. Roughly speaking, it needs twice as much memory (to store chroma as well as luma), several multipliers to do the coding and some other logic such as a subcarrier generator, adders etc. Not a hope with the Lattice version of Hedghog which is already pushing the limits of the device.

Coding NTSC from 405 RGB is easier to do in analogue. A couple of 1496 balanced modulators, the right frequency crystal (4xfsc for NTSC 405), handful of video opamps. The problem with doing it in an FPGA is you have to digitise the RGB separately. The standard PAL/NTSC decoders don't do this.

Block diagram and schematics of an analogue PAL coder I designed for G2 Systems in 1986/7. My first proper project when I went freelance. Desinged to code the output of a BBC micro. It predates low cost video opamps. Easily modified for NTSC (I've done NTSC 525). I still have the handwired prototype and it still works. A production version is coding the RGB output of the COW rotating BBC globe at the Dulwich museum.