or: How to connect my Atari ST to a modern Monitor and other fun activities

We all know that situation: your new(ish), shiny(ish) Atari ST just arrived - but apparently there‘s no way to get this thing to display a picture anywhere. No HDMI port, no DVI port, no VGA - heck, what where those Atari guys even thinking?

And even if you manage to get a picture by some voodoo contraption of cables and adapters, there‘s always that one neighbor sneering at you, because „that ain‘t right“ and „nobody connects it that way, sheesh“ - but of course he/she hastily (although at the same time relaxed and whistling) wanders away before you can approach him/her with any questions about your wrong-doing.

So just let me start this with a confession: I was such a neighbor. I told people to better use this or that, I could sneak away in exactly that pace that avoids the hard questions. Until now.

Until ggn nailed me down, to be precise. We were just talking about how fragile CRTs have become, how hard it is to find a TV technician that doesn‘t hang up right away, laughing, as soon as CRTs are mentioned. And how bad many of the modern display solutions are.

„Had I known all I know now, I would‘ve bought the OSSC right away instead of piling up that junk“ I said, waving in the direction of a huge pile of cables, converters and broken promises occupying a large part of the room.

„Hm“ he said. I quickly revisited what I said just now - and a sinking feeling began to set in.

„I could order one.“ he said, his mouse finger hovering over the „Buy Now“ button.

“You probably could walk me through it if I have any questions.“ he said.

Click.

About this article

This little article series won‘t touch all the specific ins and outs of getting an Atari ST into the modern display world. It’s just about the things I had first-hand practical experience during my quest for moving pictures in the, let‘s say, last 10 years. Although this is mainly about the Atari ST, I might mention the Falcon 030 specifically if appropriate.

This article series will try to cover and explain things along these goals:

• using an original machine
• getting a clean colour picture
• getting a stutter-free picture at original frame rates
• using solderless solutions
• using modern TFT monitors
• capturing colour video recordings from an Atari ST

You might have guessed that this is not going to be a monochrome/ST high/SM124-centric series. Monochrome specific information might be scattered around some articles, though.

There will be some parts marked as „In-Depth“ that might be a little daunting for non-technical readers. I suggest to read them anyway, but let’s be honest: they are marked that way so you can skip them much easier. But don‘t.

The products I mention aren‘t necessarily „the best“ or „the cheapest“ nor am I affiliated with any of them. I might even add some products that are crap as a warning and for good measure.

Chasing the clean picture

What exactly does a clean picture mean anyways? That’s easy: the picture should appear like it was meant to be back in the day. “But I saw people using STs on b/w televisions and it was all horrible and snowy and… horrible” - yes, OK, people did that, but that’s not what a clean ST picture is meant to be like. We want the picture to be just like we saw it on all those fair booths, where we drooled about the next big thing just around the corner. Like the developers at ATARI imagined we should see it.

A clean picture should have the following attributes:

• good image size reproduction - a circle is a circle, not an egg and a square is a square, not a rectangle

A correct-ish looking screen - Icons are square. Followed by a squashed image due to a 16:9 monitor and/or its user not knowing about our Atari STs picture ratio

• good color reproduction - white being white, not grey, black being black not, grey and a clear segregation of colours like red being cleanly red etc.
• more or less clean same-colour areas; a white are (like the borders above) should be free of grey waves or stripes or dots - same for other colors of course, black shouldn’t have grey waves or stripes
• not too washed out and not too sharp - pixels aren’t clean squares (I’ll explain later why) nor are they round cricly-blobs; they are somewhere in the middle
• pixels should be evenly distributed - the display should not skip pixels or display pixels with different sizes. Esp. 640x200 is a good test for this.

Evenly distributed pixels vs pixels that should be all the same size, but aren’t due to the monitor hating you

• the display should be propagated correctly in time - meaning: it should always take the same time for an image to travel from the ST to your retina for every frame. If it doesn’t, things stutter.

RGB or “Your ST’s clearest video voice”

Now that we have a faint idea what kind of picture we’re looking for, let’s see what the ST thinks a picture actually is.

The ST does in fact have a very strict and very detailed idea about a picture. It knows the exact colour of every pixel of any image it is sending to your display. Although there aren’t that many pixels in an ST picture compared to, let’s say, your HD TV (the ST has 32 times less pixels in its 16 colour mode), it still is enough to convey some pretty nice imagery. Basicly an ST knows about pixels and pixel rows; an image is just 200 rows of pixel with 320 pixels each:

Pixels. Yes, I know that you know. But these are explanatory ones, so: “Wheee!” ¹

Now, how does the ST tell your display device about these pixels and where they are? In fact, it does speak multiple languages to do so: “RGB” (every ST is fluent in this) and “Broadcast TV Signal” (like in “antenna” - only available in STfm models). Just remember old snowy, grainy antenna based TV and you know why we focus on RGB here:

Err… no. ²

Let’s just say the “Broadcast TV Signal” signal has to cramp just too much information into just one transfer connection to be anything near “clean picture”.

RGB, on the other hand, uses three connections to transfer its colour information - not only one. The ST can be “heard” better and clearer on those luxurious three channels it can speak through.

And to not disturb the channels that are used to “seriously talk colours”, (up to) two additional channels are used to transfer “Bookkeeping information”.

So let’s focus on RGB which gives your ST the most headroom to talk to your display device.

💡In Depth💡: RGB

RGB transfers each colour information of a pixel split into three colour values: Red, Green and Blue. These are later used by the display device to generate one colour for the pixel at hand.

Pixels aren’t transferred explicitly but are transferred based on strict timing - e.g. in an image’s signal a pixel is transferred a fixed amount of time. Thus the display device does not “know” when a pixel starts or ends, because it isn’t told about that. It just “looks” at the incoming data in specific and equally-spaced points time to gather the colour information.

But let me break this to you: your ST isn’t living in a perfect world. No, really: in a perfect world, your display device and your ST would have the same notion of time and thus this time-sliced pixel information would suffice to transfer a single image or even multiple images (aka cat movies). But for various reasons (let’s call them “production variance”, “component yield”, “mischief” and “ooops”) your ST and your display device very very likely disagree regarding time; only in slight variances, mind you, but that’s enough to get both devices out of sync. Imagine: there are roughly about 160.000 pixels in STs 16 colour picture to be transferred to your display device (we’ll see later why this does not equal 320x200=64.000). That’s a lot of time slices. A. Lot.

To help both devices to be more agreeable about which pixel should be where (well, “when” to be more precise) there are two “metronomes” in our ST. These help the display device to resync several times during the transfer of an image: one ticks every transferred image (“Vertical Sync” aka frame start) and one ticks for every line in an image (“Horizontal Sync”).

This way the display device can wait until the ST says “Hey, display device! Here’s the next line you are waiting for!” and then the display device starts “looking” at the values the ST is sending for a line in its own time slices (which aren’t that far off anyways) and in most cases this is enough to get a pretty stable image transfer.

Remember: all of this information are cramped into just one wire on the STFM’s TV modulator output - as opposed to the 4-5 distinct wires the RGB(+HV) signal has at its fingertips.

Monitors

The choice of display device not only determines the picture quality, but all of them come with their own little annoyances, too. Let’s have a look at them.

CRT

Ah, a CRT device. Cathodes. Rays. Even effing Tubes. ³

Let it be said: a good CRT (I’m looking at you, SC1224, SC1435, pro broadcasting CRTs and the likes) has yet to be matched by non CRT-solutions in terms of image reproduction when combined with a good signal source.

Luckily our beloved ST has such a source - almost like it was meant to be used with CRTs.

There are Pros:

• good colour reproduction
• in most cases no calibration necessary, just some finetuning like brightness etc.
• stutter free image (we’ll learn why)
• slight smoothing of the image

but also, of course, Cons:

• big
• heavy
• hard to repair / getting it repaired

Apparently a CRT meets all the goals we sat above. It’s just unwieldy. And can kill you when trying to repair it. But that’s true for most fun things, so relax.

TFT

TFTs weren’t around when the ST hit the market (at least not in consumers’ hands), thus we are kinda lucky that they even work with such an old machine.

But do they?

When we’re talking good old demowatching / gaming colour mode the answer is “depends”. Modern monitors are (in most cases) not used to the low resolution and low numbers of pictures per second (frame rate) our ST delivers. As a rule of thumb: the b/w mode works with most TFT monitors, the colours modes don’t. There are exceptions, we will cover those later.

TFT TVs on the other hand most often work with STs - but since those are made to watch movies, the frame rate of our ST might even be too high for them to display all of them.

Pros:

• good colour reproduction (if calibrated)
• small
• lightweight (in comparison)
• already in most homes

Cons:

• movement has heavy ghosting artifacts (see some scrollers on a TFT and you immediately see what I mean - or just watch this)⁴
• I mean, heavy ghosting artifacts (even on very good TFTs)
• picture is either really sharp… (yes, it’s a con, we’ll see why)
• …or too blurry ⁵
• uneven distribution of our STs pixels
• most TFT monitors won’t work with an ST without converters
• those who work are not easy to find

Apparently a TFT misses most of the goals we set above. So why bother? To be frank: because we are lazy and TFTs are everywhere. Although you’d get “wtf?”-points if you’re reading this on a CRT; CRTs realy shine with animated effects like in demos or games, but for reading? TFTs are clearly better suited for that.

💡In Depth💡-ish: “Sharpness killed the dithering star”

While we’re talking about TFTs - let me show you a quick example why being too sharp is bad for displaying images and animations (at least iwhen we’re talking Atari ST colour modes):

Using dithering on a CRT to produce additonal colours vs a stripe-y mess on a TFT

These are (albeit extremely zoomed in) pictures of the same area of an image on a CRT (left) and a TFT (right). The unknown artist created those big pixels we’re looking at using alternatingly coloured stripes of neighboring pixels (called dithering) to produce new colours - here he did that using a 640x200 resolution (of which approx. 70x70px are shown). Just ignore the horizontal stripes for now - those are “scanlines” as you probably already guessed.

But the neighboring vertical stripes blend into each other when looked at through a CRT (an SC1224 to be precise), producing a newly coloured area, showing a colour not present in this pixture at all. Here he produced 4 colours (see left CRT image) by only using 3 colours (see right image). The TFT on the other hand just shows us… ugly stripes. The original intention and look of the creation is lost on a TFT. We dig a bit deeper into this in part II of the series.

Framerate or “Why you should say ‘no’ to stutter”

Before we get deeper into some specific setups, let’s venture a bit into something that I, up until now, hoped could be left unexplained - we talked about pixels, we talked about the basic anatomy of an image, but we did not talk about movement of pixels and how the ST represents this.

The ST wouldn’t be so exciting if it only ever generated one image after powering on, would it? To represent the changing contents of the current image the ST has in its memory (think, like, mouse movement, window opening, enemies in a game moving etc.) it just generates a new one. And since display devices are made for moving images and they usually know all about them, the St generates images in a way those devices demand: “just generate exactly n images per second”. To make things complicated there are different devices in different parts of the world, thinking in different values of n unfortunately - namely PAL (Europe et al with 50 pictures per second) and NTSC (mainly America and 60 pictures per second) refresh rates.

We’re concentrating on PAL here, but most concepts are easily transferable to NTSC anyways, just think of it as “more images in one second”.

Most demos and games are tuned to a display giving your retina a fresh image every 1/50th of a second (thus the term “refresh rate”) - like PAL CRTs; and it is of uttermost importance every image is ready in that same timespan. Else the animation would appear much worse (at least in terms of motion smoothness) than originally intended by the creators (and your ST!).

Let’s make a little experiment: go and watch this for a few seconds; now go to that video’s quality setting and switch it to 480p (or, if it happened to have that setting already, switch to 720p50). See the difference in the scrollers’ movement to the left? One setting has a clearly smoother movement than the other. Although this is not a perfect example for various reasons, it gets the point across.

Why is that so? And why should it bother you, dear reader?

First of all: your eye is more comfortable with higher refresh rates - there are rumours (some call it “science”) that our brain processes motion best between 30 and 60Hz, but can differentiate between frame rates (note: not distinct frames) until up to 150Hz. Additionally there’s word on the street that the high-contrast nature of artificial computer imagery and -movement (as in… well, “contrast” to nature settings) does strain the eye a lot less at Hz rates above 30Hz. Meaning: our beloved ST isn’t that far from optimal when serving us 50Hz (or 60Hz in NTSC-land). Not bad for 1984-ish tech.

Second of all: it’s not the resolution playing tricks on you - although “480p” in YouTube lingo means “every image in this video consisting of 480 rows of pixels” and 720p means “720 rows of pixels” this is not the culprit - we just chose 720p50 (an image consisting of 720 pixel rows 50 times in a second) because YT does not allow 50 images per second on lower resolution videos like 480p (a random arbitrary technical constraint you can forget about if you don’t plan to capture ST video for YT).

So if one setting is in fact 50 pictures a second, how many pictures does YT throw at you in that other exemplary setting? 25. That’s half. That means that you’re missing half of the goodness you are supposed to see! That YT video acts like a display device with an refresh rate of 25 pictures a second, aka 25Hz.

So we only getting to see 25 pictures per second if we’re not careful and check the setting in our YouTube player.

Of course we’re not just mentioning this to brace you for using YouTube - this article series is about real hardware after all.

Unfortunately there are display converters and TFT TVs/monitors out there, that just display 25 pictures per second out of the glorious 50 your ST produces. And just like YT they often just assume what’s best for you. And we all know what “assume” means⁶.

Those display devices just assume you’re watching a VHS or DVD (which use 25 pictures per second in Europe) because that’s what most people do. Apparently there are vastly more people out there that watched TV or VHS or DVD than live computer generated 50 pictures per second. So they just assume that’s the “normal use case”. Pfft.

Fortunately there is a nifty little tool by Evil/DHS that shows if your current setup delivers stutter free 50 different images per second into your eyes or not. Just start that PRG with your colour display solution connected, and if your seeing a flickering grey(-ish) image, all is well; if you’re seeing a green or a purple image - then your display just “eats” half of the information you are supposed to see. Also beware if you want to try this on an emulator - emulators can only display through your PCs display and if that does not display a non-fraction multiple of 50 pictures per second (like 50*2=100Hz, 50*3=150Hz etc.) it will fail that test.

Again, what does that mean - if you’re not into the business of staring at grey flickering areas all day?

Especially for gaming (and slow demos) this means a lot.

Deciding what exactly to display to your eyes takes your ST some time (drawing all the sprites, scroll the background etc.). It may not be ready doing that after 1/50th of a second. Thus it sends the same image to your display again - let’s say, three times in this example, then it shows the next image it calculated three times etc. A lot of games do that, there aren’t that many that actually send 50 different images per second. Displaying the same image three times buys those games 3 times more time to draw all that action. This lowers the so called framerate - meaning: how often a second does the game show you a newly generated image instead of an old one? Think Starglider II - all those objects in that world take time to draw, thus the framerate of that game is lower than 50 images per second, while your display refreshes 50 times a second (well at least the ST hopes so).

Now, with a proper 50 pictures per second display solution, you’ll see one different image every three pictures in that imaginary example game. That’s not great, but it is what it is at least - and what it was produced originally by the games’ authors.

With a display solution that only shows you 25 pictures per second this changes. Remember: your ST still sends 50 pictures per second due to its 50Hz PAL refresh rate - three identical images until the game produced a new one, followed two identical until it produced a new one, followed by… etc. Now it’s just the display or converter that throws away every second image and shows you the one it’s not throwing away twice. That’s not nice, I mean, the ST worked hard for those images, and the display device is just throwing half of them away?

So what do we actually see? Let’s number all our images and underline when we’re going to see a changed image in that scenario (top line 50 pictures per second, bottom line 25):

ST-generated frames with annotations which ones we see and when wee see them - top: 50Hz display device, bottom: 25Hz display device

The bottom line has every second image greyed out, we never see those on a 25 pictures per second display device. Remember: a 25 pictures per second display solution basically doubles images “for us” (whee, thanks!), so one image is there twice as long as intended. Red images are lately displayed content changes due to the display device - we should’ve seen this images’ content one frame earlier.

This means: when we should see image #4, which is the first with new content after three successive identical images (because the game needed that time to draw things) we still see image three (which in essence is still image #1). So instead of three consequent identical images, we get four. Then we get new content at image #5, an identical image at #6, and a new image at #7. The next new image will only be shown to us when we reach image #11! So we see four images of content, then 2 of different content, then again 4 images of the next different, content - that’s stuttering. There is no way that any movement conveyed by this image sequence is smooth. Different content every three images #1,#4,#7,#10 etc. is even spaced and at least somewhat smooth. But seeing newly drawn content only at images #1,#5,#7,#11 is not smooth at all.

Another example - this time a game or demo that doesn’t quite manage to send images every 1/50s; it sends two identical ones, one new, two identical, one new etc. (actually not that uncommon than it sounds):

ST-generated frames with annotations which ones we see and when wee see them - top: 50Hz display device, bottom: 25Hz display device

Looking at the non-greyed out underlined or red images we see that our display solution effectively shows us the goods as if it were generated with always sending two identical images; i.e. we are missing a lot of those new images. Due to the red (late) images this will stutter.

And a demo or game that produces different images every frame (a frame being ¹⁄₅₀ of a second) will be cut into half, since we miss every second image.

So, obviously we need a display solution that is as close to the original “50 pictures per second” aka “50Hz display refresh rate” an ST produces as possible to not lose any of that gorgeous motion.

And let me say this again: your common emulator does not show you proper, stutter free 50 pictures per second; all that was said about 25Hz refresh rate display solutions is basically true for normal Laptop/PC displays, too - the numbers change a bit, but the result is the same: stuttering and dropped frames.

One last example: this is a nice, stuttery non-50 pictures per second recording of a game which should’ve been recorded in 50, like this one. The difference is appaling: the first one stutters to a point where you think it will just stop scrolling - the second one is clean and smooth. And remember: this is affecting live gameplay/watching demos on the ST, too, not just recordings.

💡In Depth💡: Frame rate

Before we dive into the fact why exactly some display solutions assume 25Hz and butcher our STs display signal, just a few quick notes:

All of the above gets even more complex when we factor in things like YouTube or emulators. Almost all PC displays run >60Hz. So even with a 1080p50 YT video it’s pretty hard nowadays to watch that with proper 1:1 frame rate. Even the YT app on smart TVs often does not bother to switch to 50Hz on 50Hz content. A 50Hz video watched on a, say, 60Hz display stutters. A 50Hz ST signal recorded with 60Hz and watched on a 60Hz display stutters.

Same with emulators. As mentioned above you might get away with a refresh rate that is a multiple of 50, but that’s not too common either. So we’re basically forced to use native machines to get a proper, stutter free experience. Basically it’s a lose-lose situation with PCs in that regard.

The tale of the two fields

The ST is of course built to use the display devices of its time. And those display devices were meant to display the content of its time. Which was encoded (at least as far as our interest goes) in PAL and NTSC. Again, I am focusing on PAL here.

Also TVs and their standards were not built with static content in mind. They’re meant to display moving images. Like TV series, TV shows. And such content is recorded with 25 frames per second - but displayed on 50Hz devices - “Why?”, you say? Well, first of all the power line frequency basically decided the picture frequency of your TV (50Hz in Europe, 60hz in America). To get a higher resolution than the first TVs could actually produce, it was decided to use interlace.

Let’s throw around some numbers: one TV frame consists of 625 lines of colour information - note that the width is not defined in pixels, because, frankly, there were no pixels back then. Instead, they defined the timing, e.g. how many microseconds a line lasts (64 to be exact). “But wait”, you say - “50Hz*625 lines*64 microseconds=2.000.000=2s”. “Shouldn’t that be 1s? As in ‘50 frames per second’?” And you are of course right. (Also: do not fact-check what I write, please? Thankyou)

However, that’s where the interlace and the two fields come into play. Instead of sending 625 lines worth of 64 microseconds of colour blasts each the image is split into two fields; first one with lines 1,3,5,7,9 etc. and second one with lines 2,4,6,8,10 etc. Now your TV displays field 1 in one frame and then displays field 2 as the next frame: et voilà: one full 625 line image via interlacing!

Of course this flickers as hell, but people did not notice back then, they were too amazed by those moving images they suddenly got right in their own home. Well, that and the fact that natural scenes (and back then all they had to film was nature, right?) don’t flicker that much due to low contrast between lines. Other than, let’s say, a credits scroller (credits were invented after interlaced, I presume).

So, this is what many displaying devices or converters think when tasked with converting a PAL signal:

“This looks like a PAL signal. Hmmm…. interlaced if I remember correctly. Probably best to get the next two frames and interleave the lines from the second frame into the first one. Yeah, that’d be nice. But, wait! Has my built-in-obsolescence-kill-me counter triggered yet? Ah, no. Sigh Okay, Let’s get to work. Wait… I could just display the first field and spare me the work of interweaving the second one. Yes, I could, he’ll probably never notice anyway!”

That’s wouldn’t be wrong per se - well it probably shouldn’t skip the second field, but many cheap converters do that instead of a proper deinterlace - if, yes, if the PAL signal wasn’t used for non-interlaced systems like our ST happens to be.

That’s the main thing Evil/DHS’ flicker.prg is testing for: displaying two different images in succession (green and purple) should transfer them independently as two different frames (which give a grey-ish image due to green and purple displayed in fast succession) and not as two interleaved fields (and thus be reconstructed in a single image). If it doesn’t handle the fields independently, it displays either one of the fields (aka plain green or a plain purple) or a strange deinterlaced representation (one line green, one line purple).

Basic Setups

The setups I‘ll cover are basically split along the target display solution available. Be prepared that that might change over time. You might start with A and switch over to B because your usage profile changed over time. Don‘t fret, that‘s normal. But brace your bank account, just in case.

CRT

This is where your ST feels at home of course. This were the monitors the developers developed for, the users back then used and frankly, the STs picture looks the most “true to its intention” on a CRT device.

Why? Well, remember the pixels we saw earlier? Those big, big blocks up there? Those were big because we zoomed them in, but that’s exactly what your TFT does with your STs image, too - let’s say we have a relatively small 4:3 monitor with a 40cm (ish) display width. That’s more than 1mm per pixel when using the STs 320x200 resolution!

Apart from that, on a CRT pixels aren’t entirely square and not entirely separated from each other; they blur into one another ever so slightly. That circumstance was even used by artists to add details that weren’t there and to create more visible colours than in fact were present, like we learned in the dithering In-Depth above.

I personally can vouch for a very good picture quality on the ATARI SC1224, ATARI SC1435 aka Philips CM CM8833 II.

Built-in cable

ATARI monitors have a built in cable - if you own one, just use that.

Modulator

Some STs (like the 1040 STFM or 520 STM) have a build in modulator. That modulator takes all the nice, separated RGB information and squashes them into basically one single signal in a thin cable to make them like the aerial TV signal (which is, in a way, only one cable, too). That signal is horrible, there were so many compromises to make - remember aerial TV? Or the VHS cassettes’ video quality, washed out colours and striping? Yeah. So, just don’t use it, ever. Your ST can do a lot better.

TV out on some STs. Most probably the source of CRTs bad reputation.

Scart

Yes. Or “SCART RGB” to be more exact - for some reason it is possible to build SCART using a single-signal-line thing called “Composite” (which we will ignore for the same quality reasons as we do the modulator) and there are (old) CRTs that only support “Composite” - those CRTs were build mainly with VHS players in mind.

We definitively want “SCART RGB”.

Unfortunately SCART is a standard not that present in some parts of the world (like the USA for example), but looking for a SCART capable CRT device should be the easiest way even in those countries.

Bottom line: CRT with SCART delivers pretty good and “true to its intention” image quality with full 50Hz/60Hz support and sound!

TFT and the old 15kHz vs 31kHz struggle

This is the display type that’s currently the most readily available. But, like mentioned above: quality wise it might look superior on still images, but as soon as motion is involved (especially 50Hz motion like a scroller in a demo) you will see significant blur² and ghosting¹ that makes it hard to recognize details in the scrolled content. That blur isn’t due to bad panel quality - very good and new monitors have that blur, too. Even pro gamers suffer from it. But that’s a story for another part of this series.

Also: almost all new TFTs don’t have the means to display our STs display signal. It starts with the connection: getting TFT TVs having a SCART connection is pretty rare nowadays. Let alone TFT monitors with an analog VGA connector (we’ll see soon why that’s important). Which leaves us with: DVI and HDMI in most cases.

And even if you have a TFT TV with SCART input, it’s not guaranteed that it does display 50Hz - some tend to just display every second frame resulting in 25Hz (see above “Framerate or why it should matter”).

So, be prepared - it is a lot harder to get a good TFT picture than getting a good CRT one.

SCART

If your TV has SCART, it’s easy, use a SCART RGB cable, hook it up to your ST, start Evil/DHS 50Hz checking tool there and check if you get 50Hz or not (see above regarding how to .

No, not that easy

Of course it’s not always that easy. SCART is not implemented by all manufacturers in quite the same way - there might be TVs that need some special treatment to display SCART, mostly cabling issues.

For example: some TVs need a special signal on one of the SCARTs pins to even turn the SCART input on.

Let’s just say for now: in most cases SCART just works - in cases in which it doesn’t, wait for PART II of this series.

15kHz VGA / DVI

If your TFT has a VGA/analogue DVI connector, you might be able to use your STs signal directly. But, to be fair, it’s a slim chance.

There are lists all over the Internet that try to gather information which TFT VGA/DVI monitors support the STs signal. In simple terms: the STs signal transfers information “slower” (15kHz) than on modern systems (31kHz and up). Thus the modern monitors don’t support the “slower” signal type in most cases, because it isn’t needed.

To find 15kHz monitors unfortunately is a tedious task - the manuals often blatantly lie about the technical specifications; there are monitors saying to support 15kHz, but don’t; but there are monitors which say to start at 31kHz, but support 15kHz. It’s basically all about testing it out.

Keep in mind that the information in those lists might be a bit off, so double check against forums etc. I personally can vouch for the NEC 1970NX - not the best monitor, but it works very good.

• Atari Forum Wiki list
• https://github.com/planeturban/15khz
• https://15khz.net/
• http://15khz.wikidot.com/

To actually connect a VGA cable to your ST, you can use adapters like this (scroll down to MCSWITCH, that one has RGB calibrating pots) or this. Beware that most “ATARI ST VGA cables” on sale on *bay and such are mostly monochrome resolution cables, that do not support colour modes!

HDMI

Here it’s starting to get expensive - but not that much more expensive than obtaining and maintaining a good CRT.

Converters

You need converters, because HDMI wasn’t around when your ST was in it’s prime; STs signal is analogue, HDMI is completely digital.

Do the smart thing and don’t do what others (me included) did: don’t buy “cheap” converters, buy a good converter to boot or you will end up paying more in cables and those three half-working converters you’ll end up with than paying for a good one.

I’ll only cover SCART/HDMI converters, because we won’t use the modulators’ or a composite signal for the reasons laid out above.

The bad and the ugly

A small part of my pile of broken promises.

There are a lot of SCART to HDMI (and other formats we better don’t mention) converters on the market - some of them cost only as much as a good burrito menu.

The bad thing with those converters is, that most of them are based on a ready-made chipset that was made to convert VHS signal (which is - I’m a bit oversimplifying - basically 25Hz) and no 50Hz signal like the ST produces. That’s the reason why they are so cheap.

Cheap converters (yes, *bay, I’m looking at you) were in all cases I tested (and I tested a lot of those) and in all cases people I talked to tested (and they tested even more) very, very, very bad. Most don’t do 50Hz, just 25. Others blur the image. Others have distortions, introduce frame lag (the ST sends an image and the converter things a few frames about it until it gets send to your display - makes games unplayable) and whatnot.

The good: OSSC

The OSSC. Hard to learn, not easy to master.

The OSSC is like a little computer that looks at your STs signal and converts it into HDMI. And it does that fairly fast - e.g. if you push the joystick “up” it doesn’t take a moment until your player sprite reacts. It can do a lot more with a lot more signals, but we’ll stick to the ST here.

Pros

• ready to use
• can be used to calibrate the colour signals (getting white to actually be white and black to be black and not some grey)
• updates regularly available

Cons

• price
• understanding all the available options might be a bit overwhelming

The good: RetroTink SCART

The RetroTink SCART. Works, when it works.

The RetroTink SCART is a lot simpler than the OSSC, and it shows. Not necessarily in it’s picture quality (which is OK), but in the lack of calibration.

Pros

• easy to use

Cons

• almost no options
• generates HDMI some older TVs won’t display

The good: RGBtoHDMI

Not for the faint-hearted: RGBtoHDMI Amiga Denise Adapter including Raspberry PI zero and some clamps to connect this contraption directly to the STs internal shifter - read: heart surgery

RGBtoHDMI is something that sounds almost magical: it puts an HDMI output right into your ST. It basically takes the digital (aka even better quality than RGB) colour values directly from your STs video chip and converts it into HDMI.

You only need a Raspberry PI zero, some PCB milling skills, soldering equipment, some… wait, what?

Well, at the time of writing there is no readily available solution that layman can use. I just add it here for completeness and will update this accordingly, as soon as the state of availability changes. For the brave: here and here

Pros

• good in theory
• emulator like-picture quality

Cons

• emulator like-picture quality
• not available unless you produce it yourself

What’s next?

In the part II of the series I’ll cover the adventures of “aspect” ratio, capturing ST video, fighting a TFTs blurry-ness, and do a dive into the deep problematic end of video cables (mostly SCART and VGA).

(Thanks to ggn for invaluable feedback and poof poop proof reading!)