Project: HDMI/DVI out for STFM

[Smonson]

Hi all,

Here's my current project that's been keeping me up late for several months.

I'm creating a HDMI/DVI video out for my STFM by interfacing a Cyclone-II FPGA with the shifter socket. The lowest-spec Cyclone-II is cheap and can directly drive an HDMI/DVI video signal. It also has onboard SRAM which I will use to implement scanline doubling. The benefits of this as opposed to an external upscaler are:

• Perfect picture clarity - no analogue signal paths at any point
• No buffering delay (in mono - one scanline delay in colour)
• Can display 50Hz natively on any PAL TV, just like in the good old days
• Should work with normal videomodes as borderless 640x400, or in overscan modes, automatically switch to another video mode such as 720x480 (*in theory).

Right now I have it displaying a stable picture in monochrome mode:

20171015_200234.jpg (69 KiB) Viewed 16040 times

The FPGA is clocked at 32MHz and feeds a 16MHz clock into the Atari through the shifter's clock out pin.

The video frames are synchronised with the ST's DE signal (the first DE after a gap of greater than 2048 clocks equals the start of a new video frame).

Shifter data is loaded into the FPGA the same way as the original shifter (through 5-to-3.3v level converters) on the LOAD pulse and then shifted out into a scanline buffer in FPGA RAM. After a one-scanline delay, that data is then clocked out to the DVI connector. The purpose of the delay is to implement the scanline doubler for colour modes.

The reason why the desktop looks weird in that pic is that I have my stripboard prototype set up with only writeable shifter registers, it won't drive the bus to read them back. So the ST is confused about what resolution it's in.

The biggest obstacle that I'm dealing with right now is instability. In monochrome, the whole system is reasonably stable, but in colour (50Hz in my case) the length of the video frames are not steady - some are shorter, some are longer. I am working off the theory that this is because of noise in the clock. There is a lot of noise all over the whole circuit actually. Tomorrow I'll receive the first manufactured PCBs with a good ground plane underneath everything, and a buffer on the clock right before it goes into the shifter socket. I hope that will resolve the instability issue... I'll let you know how it goes.

[arf]

Here's my current project that's been keeping me up late for several months.

Fantastic project!

Out of curiosity – would it theoretically possible that this new shifter could handle the higher resolutions of running with 16 MHz, as described in parallel posts, with 1280px hor.?

[exxos]

I'm creating a HDMI/DVI video out for my STFM by interfacing a Cyclone-II FPGA with the shifter socket. The lowest-spec Cyclone-II is cheap and can directly drive an HDMI/DVI video signal. It also has onboard SRAM which I will use to implement scanline doubling. The benefits of this as opposed to an external upscaler are:

This sounds awesome. At our users have been crying out for HDMI video out for years.

I did look at the other range of chips, but I have not really considered the cyclone yet. But like you say, if it has everything on board for scaling, date is ideal for this. The stuff I am doing is more on gate level to me like the shifter, so I was looking more towards the MAX 2,5,10 series.

• Perfect picture clarity - no analogue signal paths at any point
• No buffering delay (in mono - one scanline delay in colour)
• Can display 50Hz natively on any PAL TV, just like in the good old days
• Should work with normal videomodes as borderless 640x400, or in overscan modes, automatically switch to another video mode such as 720x480 (*in theory).

This is of course the best method

As scan doublers at the moment are of course using the analog parts, like you say this basically sucks We need to interface directly to the RGB data, and work on the digital side of things, then there is no problems about signal degrading etc

Shifter data is loaded into the FPGA the same way as the original shifter (through 5-to-3.3v level converters) on the LOAD pulse and then shifted out into a scanline buffer in FPGA RAM.

It is something I have not totally figured out yet, of course there are what you eat level converters. The chips I was looking at would accept a 5 V input, but only via current limiting resistors on the input and. Which is diode clamped internally in the chip.

Well of course it is possible, it still involves some extra soldering, as either a logic level converter would have to be used, or the resistor diode clamping method, as yet I am undecided which want to go for.

After a one-scanline delay, that data is then clocked out to the DVI connector. The purpose of the delay is to implement the scanline doubler for colour modes.

The reason why the desktop looks weird in that pic is that I have my stripboard prototype set up with only writeable shifter registers, it won't drive the bus to read them back. So the ST is confused about what resolution it's in.

Well you have something workable, which is more than anyone else has done so far. Of course nobody can wake up one morning and create 100% compatible and working chip right from the start, Things off course need to be done one step at a time. But of course still good to know about this "issue" anyway

The biggest obstacle that I'm dealing with right now is instability..... I am working off the theory that this is because of noise in the clock. There is a lot of noise all over the whole circuit actually.

Welcome to my world Is normally design something in a day, and then spend the next six months trying to work out why things are glitching, which are now always noise on the motherboard somewhere.

The phrase 'let's play Atari' has a whole new meaning these days

I hope that will resolve the instability issue... I'll let you know how it goes.

Yes please let us know. It may be more beneficial if we both try and get your design working as we are both basically working on the same thing.

I am not going down the coding route though, I am doing things on a gate level. In short, it is easier for me to work with logic gates than try and learn a new programming language, and trying to work out if my coding is wrong, or my design for something. So basically got tired of all the coding aspects, and went for the Altera as I was more comfortable using the schematic editor in the software.

In any case, we could implement the new video modes I was talking about in my own thread, and make your video chip functional with my accelerator designs. Ultimately your chip could be used for my new motherboard remake is a standard video chip, which of course would be awesome

[Smonson]

Here's my current project that's been keeping me up late for several months.

Fantastic project!

Out of curiosity – would it theoretically possible that this new shifter could handle the higher resolutions of running with 16 MHz, as described in parallel posts, with 1280px hor.?

Thanks arf! And the answer to the question is yes, it should be fine.

[Smonson]

Update: got my boards from the fabricator.

20171101_001158.png.jpeg (534.45 KiB) Viewed 16040 times

I still have a bit of fiddling around to get video out of it (I've changed some pins) but it looks like the frame rate instability is still there in 50Hz mode, even though the signals are nice and square. I hypothesise that the reason for that could be that the Atari is unable to read back the shifter video mode register and it's doing something undefined in TOS that messes up the video frames.

[exxos]

Update: got my boards from the fabricator.

Nice stuff I assume the green boards are the ones you created, and the blue one is a off-the-shelf cyclone board? If so I should probably get myself one of these boards the development work..

I still have a bit of fiddling around to get video out of it (I've changed some pins) but it looks like the frame rate instability is still there in 50Hz mode, even though the signals are nice and square. I hypothesise that the reason for that could be that the Atari is unable to read back the shifter video mode register and it's doing something undefined in TOS that messes up the video frames.

Possible if you have had this issue with the colours already..

Maybe TOS writes the initial values on start-up, and later down the code somewhere it reads back the registers see what video mode it is supposed to be in. Maybe it is randomly switching between colour and mono modes causing the frame instability?

[troed]

TOS boot process can be seen in the disassembly in ST Internals, if not in the actual TOS source available. It writes to video mode registers of course, but I'm not sure it reads. Maybe some HBL interrupts etc could be affected.

In any case, booting from a diagnostic cartridge is often a good way to get a clean boot as early as possible with minimized interference from other stuff.

/Troed

[keli]

The biggest obstacle that I'm dealing with right now is instability. In monochrome, the whole system is reasonably stable, but in colour (50Hz in my case) the length of the video frames are not steady - some are shorter, some are longer. I am working off the theory that this is because of noise in the clock. There is a lot of noise all over the whole circuit actually. Tomorrow I'll receive the first manufactured PCBs with a good ground plane underneath everything, and a buffer on the clock right before it goes into the shifter socket. I hope that will resolve the instability issue... I'll let you know how it goes.

Since you mention 50Hz, I'm assuming you're dealing with PAL frequencies. A PAL frame supposedly consists of 625 scan lines (visible and invisible lines) transmitted as two 50Hz interlaced fields. The Atari image, being progressive basically treats each field as a separate frame, but note how the number of total scan lines is uneven. This means that every other frame would be slightly shorter than the first, if we assume the ST matches the PAL standard exactly. Is that what you are seeing? Are the frames alternatively 312 and 313 lines or is the frame length actually 312.5?

[exxos]

I asked Steven (steem guy) if he could shed any light on this.. he said..

The TOS does read shift mode at $ff8260.
On STF the non-significant bits are set, on the STE they are cleared, but TOS "ands" with 3 anyway.
If you boot in low resolution, it won't write to this register (shift mode bits are at zero).
If you boot in medium resolution (desktop.inf), it will write 1.
If you boot in high resolution (monochrome), it will write 2.
Shift mode is in the Shifter, with a shadow copy (2 bits) in the Glue.

Though not sure what the shadow copy is in glue ?

EDIT:

new reply..

The Glue needs to know the shift mode for the video timings (DE, SYNC, etc.)
Sync mode (50/60) is in the Glue too.

[Smonson]

Update: got my boards from the fabricator.

Nice stuff I assume the green boards are the ones you created, and the blue one is a off-the-shelf cyclone board? If so I should probably get myself one of these boards the development work..

That's right. They're known as "EP2C5 Mini-Boards" on ebay. They're pretty cool. Buying one of these boards is actually cheaper than getting a single EP2C5 IC from Mouser! About 30 AUD. Also I doubt my ability to solder a TFQN144, especially when my boards are cheap and the solder mask isn't fine enough to go between the pins.

The only modification I've done to the EP2C5 board is to replace the 50MHz oscillator with 32MHz, and replace the power socket with a 2-pin header.

...it looks like the frame rate instability is still there in 50Hz mode, even though the signals are nice and square. I hypothesise that the reason for that could be that the Atari is unable to read back the shifter video mode register and it's doing something undefined in TOS that messes up the video frames.

Possible if you have had this issue with the colours already..

Maybe TOS writes the initial values on start-up, and later down the code somewhere it reads back the registers see what video mode it is supposed to be in. Maybe it is randomly switching between colour and mono modes causing the frame instability?

I can see CS being pulsed once every frame or so, so something's going on there... I've still got some (verilog) work to do to to make read/write registers work before I can test any theories... I wish I had more time to spend on it every day

I asked Steven (steem guy) if he could shed any light on this.. he said..

The TOS does read shift mode at $ff8260.
On STF the non-significant bits are set, on the STE they are cleared, but TOS "ands" with 3 anyway.
If you boot in low resolution, it won't write to this register (shift mode bits are at zero).
If you boot in medium resolution (desktop.inf), it will write 1.
If you boot in high resolution (monochrome), it will write 2.
Shift mode is in the Shifter, with a shadow copy (2 bits) in the Glue.

Though not sure what the shadow copy is in glue ?

EDIT:

new reply..

The Glue needs to know the shift mode for the video timings (DE, SYNC, etc.)
Sync mode (50/60) is in the Glue too.

That's very interesting. I didn't consider that it would mask out the unused bits. You'll need to take that into account when you add your 256-colour video mode to the list!

But yeah... The behaviour I'm seeing does resemble what I imagine it would look like if the frame timing was being changed from one frame to the next. It's so hard to debug things like that when all you have to communicate with the outside world is 3 LEDs.