Video output considerations

Open source STF clone project.
Petari
Posts: 363
Joined: Tue Nov 28, 2017 1:32 pm

Video output considerations

Post by Petari » Wed Dec 27, 2017 8:12 am

As we know, most of people currently do not have old analog TV or monitor, which can accept Atari ST's PAL or NTSC video (not 100% standard, but it is not relevant here) . Myself use TV capture card for ST(E), Falcon in PAL mode. There is old Samsung TV in basement, what worked when is replaced for digital TV couple years ago, but there is no place for it. And could kaputt any moment.
So, I think that ST remake project should support modern monitors - via VGA and maybe HDMI outputs. As standard part, so no need for some scan doubler - add it to project. And it can be much better and simpler if it is built in machine, instead connected to video out - RGB.

What is hardest case for displaying ST video on some LCD VGA monitor ? Indeed PAL, 50 Hz refresh rate mode. Usual LCD monitors support refresh rates of 60-70-75 Hz. Some can not 75. While it would be good via scan tripler. Because there is plenty of SW, what works properly only at 50 Hz refresh rate we need some more advanced way than scan doubler or tripler.
Actually, ST shifter has 9 digital outputs (STE 12), which are converted to analog via simple resistor grid in ratio 1:2:4 . So, the whole idea is to not convert it to analog, but to write those 9 (or 12) bits into 16 bit wide fast static RAM. Size is: 128KB for low res, 256KB for medium, while for high res no need - it can go straight to VGA. Then, just need to generate analog VGA from content of that SRAM - and that will be simpler than what shifter does, since no deal with color palette. RAM content goes out to similar resistor grid as it is after shifter, just that will go after amplifying to VGA output. And VGA can work at 60-70-75 or even more Hz. Basically, writing to SRAM and reading from it will be asyncron . Need fast SRAM, and they are usually that. Like 20nS - then can have pseudo dual port RAM in fact (what is something what ST RAM sharing between CPU bus and video is).
In case of 50 Hz mode of ST, and 60 Hz on VGA it would look like:
In low res. mode shifter output will be written to SRAM in intervals of 250nS (2x DRAM read rate) . 60 Hz VGA can have some hor. freq about 35 KHz , progressive scan, and will read every line 2-3x in row. Line time is much shorter than at 25Hz interlaced - so may calculate with SRAM read intervals of 80-120nS . Or even less, down to some 40nS in case of 20nS SRAM. Then just need to use similar latching solution as ST self uses, and thing is solved without more expensive dual port SRAM . Latching is to avoid conflict, if shifter and VGA output circuit try to access SRAM at once.
All it needs of course more accurate calculations, design of logic. But I think that can be done without big component costs. Will need fast logic chips for sure. GAL of 10nS may be slow. And medium res. needs 2x bigger datarate because higher res. That could be pretty tough task with usual LS, F, ALS chips. Some high speed CMOS, I guess. But I don't know what is currently available. Gate delays of max 5nS are necessary, I guess.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
IngoQ
Posts: 546
Joined: Tue Aug 22, 2017 8:38 am
Location: Germany

Re: Video output considerations

Post by IngoQ » Wed Dec 27, 2017 9:18 am

Indeed, the biggest problem is displaying 50Hz signals. Almost all LCD panels made today internally only operate at 60Hz. The controller logic will accept 50Hz signals, and do a more or less good job at converting. This is usually done with some kind of 3:2 pulldown or sometimes a 2:2:2:2:2:2:2:2:2:2:2:3 pulldown. In both cases you display PAL frames in differing amounts to fill up the "missing" frames, usually combined with a small speed up.

It has one side effect though: The so called telecine judder. It is typically not that appearant in movies, but very visible in horizontal scrolling games. It shows as a stuttering when scrolling sideways. High end converters like the framemeister do a nice job to minimize this, but nevertheless, horizontal scrolling is never smooth. Some modern TVs calculate intermediate images to fill up the gaps, but this usually reduces the sharpness and introduces motion blur, which is unwanted in gaming.

To my knowledge, up to now there is no perfect solution for this.

It does not make much sense to incorporate something like a framemeister in the board design, but it surely is a nice option if you already have one. Since these always work with a analog signal, I would suggest having multiple output modes selectable:

- Original PAL signals for an external upscaler
- line doubled VGA signals
- digital output with optional correct refresh rate (50Hz vs. 60Hz)

And I'd go for DVI outputs to avoid HDMI licensing...
Ingo :geek:

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupéry

Petari
Posts: 363
Joined: Tue Nov 28, 2017 1:32 pm

Re: Video output considerations

Post by Petari » Wed Dec 27, 2017 9:40 am

Hmm - PAL signal for external upscaler ? Why not much better RGB ?
Line doubled is indeed simplest solution, but will not work with every monitor.

For me better question is VGA or HDMI or both ? :D

It is not problem to leave there analog RGB signals (PAL, NTSC freq) . But leaving PAL encoder, or even RF modulator seems as waste of space.

Considering 50-60 Hz conversion - basically, it will duplicate some frames - every 5-th, actually. That indeed makes scrolling little bad, and not only horizontal. Telecine used in conversion of films to 30 fps NTSC uses interlace to make it less jumpy - combines added frames from 2 adjacent original frames.
Maybe that should be done in ST not based on 50 fps, but 25 fps (count of real 50 fps SW is very low). then it can be smoother - need to duplicate frames by scheme: 1,1,2,2,3,3,3,4,4,5,5,5 - so in 5 frame source seq. need to duplicate 3, and triplicate 2 frames. Will be better looking, I guess. And less SRAM access from shifter side. Perfect solution does not exist, indeed. Only if there is some LCD with true 50 fps panel.

DVI is not much used in newest monitors, TV-s. HDMI licensing ? WTF ? How can they prevent me to make own HDMI output design ?
I made lot of CF stuff - now it is closed doc. type - you need to pay something for CF Association docs - which were free some 8-10 years ago. But I don't need new docs. There is nothing what is relevant for retro computer usage. This planet just goes in wrong direction ...
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
IngoQ
Posts: 546
Joined: Tue Aug 22, 2017 8:38 am
Location: Germany

Re: Video output considerations

Post by IngoQ » Wed Dec 27, 2017 10:10 am

Petari wrote:
Wed Dec 27, 2017 9:40 am
Hmm - PAL signal for external upscaler ? Why not much better RGB ?
Yep, of course RGB, no one wants FBAS or SVideo anymore ;) But with PAL timings, so not VGA compatible. Most scalers don't input VGA signals, that's why I suggest the PAL signals instead.
Petari wrote:
Wed Dec 27, 2017 9:40 am
Line doubled is indeed simplest solution, but will not work with every monitor.
Yep, you would still have the 50Hz issue. But most displays should accept 50Hz, and surely all TVs will.
Petari wrote:
Wed Dec 27, 2017 9:40 am
For me better question is VGA or HDMI or both ? :D
I'd say no VGA, no HDMI, but DVI-I instead. This way you could have both signals on one interface, and use a simple passive adapter to go to VGA or HDMI. And for the analog output, something proprietary, since to my knowledge there is no real standard for RGB analog, besides of SCART. And you don't want to have a SCART interface on your board, since these are huge :)
Petari wrote:
Wed Dec 27, 2017 9:40 am
It is not problem to leave there analog RGB signals (PAL, NTSC freq) . But leaving PAL encoder, or even RF modulator seems as waste of space.
Since the encoder would only be needed to produce FBAS (composite) or S-Video, yeah, this would be indeed a waste of space.
Petari wrote:
Wed Dec 27, 2017 9:40 am
Maybe that should be done in ST not based on 50 fps, but 25 fps (count of real 50 fps SW is very low). then it can be smoother - need to duplicate frames by scheme: 1,1,2,2,3,3,3,4,4,5,5,5 - so in 5 frame source seq. need to duplicate 3, and triplicate 2 frames. Will be better looking, I guess.
Yep, what you describe is 3:2 pulldown. The only way to improve on stuttering is using motion compensation, and this is surely beyond the scope of this solution.
Petari wrote:
Wed Dec 27, 2017 9:40 am
Only if there is some LCD with true 50 fps panel.
If somebody knows one, please tell me... would love to find one and make a display out of it :)
Petari wrote:
Wed Dec 27, 2017 9:40 am
DVI is not much used in newest monitors, TV-s. HDMI licensing ? WTF ? How can they prevent me to make own HDMI output design ?
By law ;) HDMI needs to be licensed to the conditions stated here: https://www.hdmi.org/manufacturer/terms.aspx
In addition you are forced to incorporate HDCP and eventually license that as well. That's why I recommend DVI... no issues there, at least not to my knowledge. And DVI can be converted to HDMI with a simple passive adapter or cable, since it is signal compatible. These adapters are widely available and cheap.
Ingo :geek:

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupéry

Petari
Posts: 363
Joined: Tue Nov 28, 2017 1:32 pm

Re: Video output considerations

Post by Petari » Wed Dec 27, 2017 10:20 am

Well, I have DVI to HDMI converter, actually 2 of them - 1 with cable, other attachable. Worked not really well with 2 years old Samsung TV. Maybe some extra settings to get correct AR were needed, I did not go into it much. I'm OK with DVI, if it really can be converted properly. My 2 monitors have DVI, but they are little older now.

"Yep, what you describe is 3:2 pulldown." - not 100% the same - as said they use interlace to lower judder. And ratio 24:60 is not same as 25:60 .

I don't think that some low quantity production will be problem with HDMI , but maybe I'm wrong. Big Brother spreads his presence this days :lol:
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
IngoQ
Posts: 546
Joined: Tue Aug 22, 2017 8:38 am
Location: Germany

Re: Video output considerations

Post by IngoQ » Wed Dec 27, 2017 11:10 am

Petari wrote:
Wed Dec 27, 2017 10:20 am
Well, I have DVI to HDMI converter, actually 2 of them - 1 with cable, other attachable. Worked not really well with 2 years old Samsung TV. Maybe some extra settings to get correct AR were needed, I did not go into it much. I'm OK with DVI, if it really can be converted properly. My 2 monitors have DVI, but they are little older now.
The AR thing is most likely a different issue. Here is a diagram of one (random) adapter:
serveimage.jpg
serveimage.jpg (171.05 KiB) Viewed 481 times
As you can see, no active parts involved. There are differences of course, regarding some more advanced uses of HDMI. But this is of no concern here. We don't need multiple links for higher resolutions, etc...
Petari wrote:
Wed Dec 27, 2017 10:20 am
"Yep, what you describe is 3:2 pulldown." - not 100% the same - as said they use interlace to lower judder. And ratio 24:60 is not same as 25:60 .
Yep, you are right.
Petari wrote:
Wed Dec 27, 2017 10:20 am
I don't think that some low quantity production will be problem with HDMI , but maybe I'm wrong. Big Brother spreads his presence this days :lol:
Yep, better not take any risks... producing hardware and selling it is risky enough. And in addition you would not need any additional VGA-port, since it is already contained in DVI-I, see here:
DVI_pinout.svg.png
DVI_pinout.svg.png (72.99 KiB) Viewed 481 times
Ingo :geek:

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupéry

Petari
Posts: 363
Joined: Tue Nov 28, 2017 1:32 pm

Re: Video output considerations

Post by Petari » Wed Dec 27, 2017 11:41 am

Fine. I guess that some lines present at HDMI are not present at DVI. And because it automatic AR worked not (?) .
Of course, Scart conn. should be only on cable end (TV side) .

This all reminds me about similar problems from DivX, DVD watching on computer monitor, around 2002 . Most of those CRT VGA monitors worked not at 50 Hz refresh rate (and that's good in fact :D - since many people was not aware about on what refresh rate their video card/monitor works - first step in fixing PC was often setting some ergonomic refresh rate) .
Problems were with movie (24 fps progressive after inverse Telecine, or 25 fps progressive (although I seen screwed DVDs where all it was interlaced :lol: ) ) and PAL TV (25 fps interlaced) source videos - playing it on 60-70 refresh rate caused often so called tearing. Because of that some players had special measures against it - basically syncronisation with V-blank - and then there was less noticeable judder.

And because there are plans to have accelerated ST, that tearing may appear in some games too, if they are not patched. Like Flight Simulator 2 - I needed to add there extra V-sync waits for faster Ataris. Problem appears on any monitor. So, whole displaying issue is not simple - changing just one thing - like monitor type, CPU speed ... can cause not only problems with demos, but with pretty much regular SW too .
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
IngoQ
Posts: 546
Joined: Tue Aug 22, 2017 8:38 am
Location: Germany

Re: Video output considerations

Post by IngoQ » Wed Dec 27, 2017 11:58 am

I thought of tearing when I read about your approach with having an additional frame buffer in between. Wouldn't this mean, that V-Sync and H-Sync synchronization in games and demos would not work anymore, since they would basically sync to writing to the frame buffer and not outputting to the screen?

I'd rather go with some realtime signal conversion, to ensure compatibility. Maybe something like the Chrontel CH7301C could work? Found these mentioned when doing some research about display options for µCs.

In addition, there are variants with frame buffers as well, so this could be an idea for custom resolutions...
Ingo :geek:

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupéry

Petari
Posts: 363
Joined: Tue Nov 28, 2017 1:32 pm

Re: Video output considerations

Post by Petari » Wed Dec 27, 2017 12:44 pm

You don't get it. On Atari ST side until shifter outputs everything is totally same as when it is connected to some old monitor. We write in SRAM periodically RGB outputs (9 bits for ST, 12 for STE) - like every 250nS when DE is enabled. Then is is buffered in VGA buffer, to call it so. In that buffer we have no 16-color (so 4 bit), palette based screen data, but RGB based, actually 16 bits/pixel data (only that we use 9 of them in case of ST). That VGA buffer can be read at any freq. , any repeat count for any line, any complete frame . This is realtime conversion. And can properly display everything you see on old fashion monitor, because it works with RGB outputs of shifter - and better ones - digital ones. I don't think that there is some chip what is ideal for ST's video output. Price may be problem too. Doing this with some CPLD should be not big deal.
H-sync is not used in games, and no need for that. It is used in overscan and hi-color code.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

tuxie
Posts: 79
Joined: Thu Aug 24, 2017 11:51 am

Re: Video output considerations

Post by tuxie » Wed Dec 27, 2017 12:46 pm

May this could be interesting for you Chris
http://www.atari-forum.com/viewtopic.php?f=15&t=32445

Post Reply