Hooking an STE up to a TV: Options?

[Awol]

I want to build a cable to hook my 1040 STE up to my TV, but I'm in America so I don't have SCART/RGB.

I know composite is an option, but it's only slightly better than RF.

 

1) Is there a way to wire an s-video cable out of the atari's monitor port?

2) Or anything else better than composite that is not SCART?

 

Thanks.

 

(P.S. I need it to be color, not monochrome.)

[+remowilliams]

Depends on what kind of TV you have and what you're willing to buy. If you have a TV that has component input, you can get an ST SCART cable and a SCART/component video converter. I'm doing that now and it looks fantastic. Just hooked my Amiga up the same way over the weekend.

[Awol]

Depends on what kind of TV you have and what you're willing to buy. If you have a TV that has component input, you can get an ST SCART cable and a SCART/component video converter. I'm doing that now and it looks fantastic. Just hooked my Amiga up the same way over the weekend.

My TV's got RF, composite, YPbPr (component), s-video, VGA, and HDMI. I think those converters are too expensive for me. I'd like to do this as cheaply as possible. I want to build a cable partly because it's cheaper, and partly because I just enjoy DIY.

 

I have got a color Atari monitor at home, but I don't have it with me where I am right now, so I have to put up with the TV.

Edited November 12, 2008 by Grey_and_Purple

[+remowilliams]

A SCART/component box will run you about $50. I believe someone did a s-video ST mod and it involved hacking up bits in the FM modulator section.

[Awol]

Yeah... I'm not too keen on that. I saw it. This page, right? It sounds too complicated for me. Plus, the page is down, and google didn't cache any of the tutorial's pictures. Anyway... is it just for adding a separate s-video jack in addition to the original monitor port? (I can't tell because all the pictures are down.) I was wondering if it was possible to get s-video out of the actual monitor port via a custom built cable. Or if not s-video, then anything else that is better than composite, but not SCART.

[+remowilliams]

I was wondering if it was possible to get s-video out of the actual monitor port via a custom built cable.

Yes, that looks familiar. And no, you will get only RGB or composite out of the monitor port.

[Awol]

And no, you will get only RGB or composite out of the monitor port.

Ah. Well that clears that up then. Thanks!

Looks like I'm stuck with composite.

Is there no way to get RGB into my non-SCART TV without a somewhat expensive converter?

[Christos]

And no, you will get only RGB or composite out of the monitor port.

Ah. Well that clears that up then. Thanks!

Looks like I'm stuck with composite.

Is there no way to get RGB into my non-SCART TV without a somewhat expensive converter?

 

No. Still, composite is very good and way better than RF. I'd go with that option.

[Awol]

Ok thanks! Guess I'll be building a composite cable.

[ppera]

No. Still, composite is very good and way better than RF. I'd go with that option.

 

I don't agree. Atari ST has pretty good RF modulator, so composite is only little better.

In any case it is a worth to make composite cable if have no way to use RGB out.

[+CyranoJ]

I don't agree.

 

What a shock.

[+poobah]

No. Still, composite is very good and way better than RF. I'd go with that option.

 

I don't agree. Atari ST has pretty good RF modulator, so composite is only little better.

In any case it is a worth to make composite cable if have no way to use RGB out.

 

Actually its a pretty cruddy RF modulator (at least the US ones).

The MC1377 isn't exactly an RF designers dream. It's selling point was price.

 

At any rate, I'm working on a small board to provide S-Video from any ST (even without an RF Mod).

Probably won't be ready before the holidays. I'd prefer VGA (see below), but S-Video is way easier.

 

Also been looking at using an AL250 to get VGA, easy enough to pick the digital RGB data off the shifter, HSync and VSync from elsewhere.

Haven't gotten any decent design docs (or samples) from AverLogic (and not for lack of asking!), so I have to go with just the datasheets, and buying a couple chips (qty 1 price is rough).

Haven't quite decided how to expose the i2c control for the AL250... It'd be nice to have a little .CPX to tweak the AL250 output.

The picture should be great, since there's only one D/A from the ST to the monitor.

[ppera]

Actually its a pretty cruddy RF modulator (at least the US ones).

The MC1377 isn't exactly an RF designers dream. It's selling point was price.

 

Well, I didn't examine US RF modulators, but don't see why it should be different.

On what TV channel in US it works (PAL versions RF modulators are on channel 3 (VHF low) ?

 

RF designer's dream ? RF is radio-frequency part, and has not much with PAL encoder.

20 years ago MC1377 was good choice. And I know about some cheaper encoding chips

used in other micros.

What PAL/NTSC encoder chip would be better for Ataris around 1987 ?

[+poobah]

Actually its a pretty cruddy RF modulator (at least the US ones).

The MC1377 isn't exactly an RF designers dream. It's selling point was price.

 

Well, I didn't examine US RF modulators, but don't see why it should be different.

On what TV channel in US it works (PAL versions RF modulators are on channel 3 (VHF low) ?

 

RF designer's dream ? RF is radio-frequency part, and has not much with PAL encoder.

20 years ago MC1377 was good choice. And I know about some cheaper encoding chips

used in other micros.

What PAL/NTSC encoder chip would be better for Ataris around 1987 ?

 

RF bit:

Come on. You cant do an RF modulator without an encoder- they are very much related.

1377 outputs baseband NTSC or PAL, I think that just *might* qualify as RF.

Only needs to be mixed up and modulated onto a carrier.

You can be pedantic and say baseband isn't RF, but you'd be wrong.

 

At any rate, Not going to argue with you.

It's a cruddy RF modulator setup in the ST.

[ppera]

RF bit:

Come on. You cant do an RF modulator without an encoder- they are very much related.

1377 outputs baseband NTSC or PAL, I think that just *might* qualify as RF.

Only needs to be mixed up and modulated onto a carrier.

You can be pedantic and say baseband isn't RF, but you'd be wrong.

 

At any rate, Not going to argue with you.

It's a cruddy RF modulator setup in the ST.

 

But you argued, instead answering couple simple questions...

Give me some examples of micros with better color encoder. If possible not from 2008

[+poobah]

RF bit:

Come on. You cant do an RF modulator without an encoder- they are very much related.

1377 outputs baseband NTSC or PAL, I think that just *might* qualify as RF.

Only needs to be mixed up and modulated onto a carrier.

You can be pedantic and say baseband isn't RF, but you'd be wrong.

 

At any rate, Not going to argue with you.

It's a cruddy RF modulator setup in the ST.

 

But you argued, instead answering couple simple questions...

Give me some examples of micros with better color encoder. If possible not from 2008

 

Nope, not worth the time to look up, and it doesn't change the quality of the ST output (which is what we are discussing)

It might have looked better if they used all the correct support pieces and the matching 1374, but they didn't.

Instead of discussing it with me, put up some color bars and look a the waveforms on a scope.

[ppera]

...

Nope, not worth the time to look up, and it doesn't change the quality of the ST output (which is what we are discussing)

It might have looked better if they used all the correct support pieces and the matching 1374, but they didn't.

Instead of discussing it with me, put up some color bars and look a the waveforms on a scope.

 

I'm sorry, but I don't have US ST(F)M, so can not check quality of them.

All what can say is that ST had best RF pic. quality among most popular micros in Europe in 80-es.

Why US people always mixes RF with color encoding ? "The MC1377 isn't exactly an RF designers dream. It's selling point was price." - you wrote it, while later went on RF modulator.

Edited November 14, 2008 by ppera

[+poobah]

Why US people always mixes RF with color encoding ?

 

Did you really just do that?

[ppera]

Why US people always mixes RF with color encoding ?

 

Did you really just do that?

 

Certainly not. From my reply to christos is clear that I claim that Atari ST (PAL versions) RF modulator is good quality. And I saw and run a lot of Ataris. As you did not reply me on questions and did not give arguments, I'm over this 'RF' ranting.

 

Let see another thing: how plan to do VGA color adapter's output ? What vertical freq ? What VGA resolution (mode) ?

Border ? Overscan support ?

[+poobah]

At any rate, I'm working on a small board to provide S-Video from any ST (even without an RF Mod).

Probably won't be ready before the holidays. I'd prefer VGA (see below), but S-Video is way easier.

 

Got the prototype S-Video board up and running on a 1040 STf- works fairly well.

Need to do a proper layout and have a few test boards made.

You can pick all the signals you need off the solder points where the RF modulator would have been installed, so its not too painful to install.

 

More news soon.

[+poobah]

Let see another thing: how plan to do VGA color adapter's output ? What vertical freq ? What VGA resolution (mode) ?

Border ? Overscan support ?

 

That's the not fun part... The ST has a strange video setup (16 Mhz pixel clock during the active line time), not sure the AL250 will be pleased with a non-standard clock, or it might look really bad. Going to have to layout a board to try it out (Can't 'dead bug' an AL250, too many pins)

 

Might try a CPLD with asynchronous dual port line buffers instead.

I think if the ST video is oversampled enough, the 16 MHz pixel clock won't mess up the VGA side of things.

Output would either be 640x480 or 800x600.

[ijor]

Might try a CPLD with asynchronous dual port line buffers instead.

I think if the ST video is oversampled enough, the 16 MHz pixel clock won't mess up the VGA side of things.

Output would either be 640x480 or 800x600.

 

A scan doubler like the AL250 is desgined for an analog encoded input (the digital input option is just a bonus). It is a good solution for an external plug-in adapter. But for an internal solution, a custom scan doubler would probably be better. A CPLD (or even a small FPGA) plus a DAC should work great.

 

Why oversampling, and why asynchronous at all? Grab the Shifter clock, and capture its output in the opposite edge.

 

I would also add the mono/32 MHz input. Mono doesn't require scan doubling, so it shouldn't add too much effort to the design.

[+poobah]

Might try a CPLD with asynchronous dual port line buffers instead.

I think if the ST video is oversampled enough, the 16 MHz pixel clock won't mess up the VGA side of things.

Output would either be 640x480 or 800x600.

 

A scan doubler like the AL250 is desgined for an analog encoded input (the digital input option is just a bonus). It is a good solution for an external plug-in adapter. But for an internal solution, a custom scan doubler would probably be better. A CPLD (or even a small FPGA) plus a DAC should work great.

 

Why oversampling, and why asynchronous at all? Grab the Shifter clock, and capture its output in the opposite edge.

 

I would also add the mono/32 MHz input. Mono doesn't require scan doubling, so it shouldn't add too much effort to the design.

Shifter clock (16 MHz) doesn't 'map' well to normal VGA pixel clocks (25.175 MHz), so you either go async, or you will have aliasing issues.

Its not just a line buffer, we have to fix the scan rate too. ST line time is ~63uS for 1000 pixels, VGA is ~31.8uS for 800

If we throw away some of the ST line, it can work as you suggest.

[ijor]

Shifter clock (16 MHz) doesn't 'map' well to normal VGA pixel clocks (25.175 MHz), so you either go async, or you will have aliasing issues.

Its not just a line buffer, we have to fix the scan rate too. ST line time is ~63uS for 1000 pixels, VGA is ~31.8uS for 800

If we throw away some of the ST line, it can work as you suggest.

 

There is no need whatsoever to "change" the clock or the scan rate. Furthermore, by doing that you'll introduce distorsion unless you implement motion compensation (and even then, it is never perfect).

 

All you have to do is to double the horizontal rate, transmitting each ST line twice. You can do that easily using Shifter mono clock (~32 MHz). About 99.99% of the monitors would gladly accept any pixel clock as long as it is within certain boundaries. The only reason that we need a scan doubler is because the ST color horizontal sync rate (not the pixel clock) is too low for a modern monitor (plus a minor difference in the voltage levels).

 

Many people use a modern monitor with ST mono output (which clock is exactly the same as the color one, just twice) without any need of clock adaption; I have yet to find a monitor that doesn't work. Furthermore, there are already scan doublers for the ST and the Amiga. They are just scan doublers, not frame buffers and they work with (almost) every monitor.

 

The only reason you might want to implement a full frame buffer, is for those monitors that don't accept a 50Hz vertical rate. Most do ( or many, at the very least) which makes this probably not worth. And if you do, it would be much better if you just double the rate to 100 Hz (ok, some LCD monitors won't get it either).

[+poobah]

Shifter clock (16 MHz) doesn't 'map' well to normal VGA pixel clocks (25.175 MHz), so you either go async, or you will have aliasing issues.

Its not just a line buffer, we have to fix the scan rate too. ST line time is ~63uS for 1000 pixels, VGA is ~31.8uS for 800

If we throw away some of the ST line, it can work as you suggest.

 

There is no need whatsoever to "change" the clock or the scan rate. Furthermore, by doing that you'll introduce distorsion unless you implement motion compensation (and even then, it is never perfect).

 

All you have to do is to double the horizontal rate, transmitting each ST line twice. You can do that easily using Shifter mono clock (~32 MHz). About 99.99% of the monitors would gladly accept any pixel clock as long as it is within certain boundaries. The only reason that we need a scan doubler is because the ST color horizontal sync rate (not the pixel clock) is too low for a modern monitor (plus a minor difference in the voltage levels).

 

Many people use a modern monitor with ST mono output (which clock is exactly the same as the color one, just twice) without any need of clock adaption; I have yet to find a monitor that doesn't work. Furthermore, there are already scan doublers for the ST and the Amiga. They are just scan doublers, not frame buffers and they work with (almost) every monitor.

 

The only reason you might want to implement a full frame buffer, is for those monitors that don't accept a 50Hz vertical rate. Most do ( or many, at the very least) which makes this probably not worth. And if you do, it would be much better if you just double the rate to 100 Hz (ok, some LCD monitors won't get it either).

Changing the clock and scan rate is absolutely necessary, even 'doubling' them is changing them. motion compensation isn't relevant or necessary, these are progressively scanned displays.

 

If you simply push pixels out at 32 MHz, you will definitely distort the image, Specifically, it will be compressed horizontally. (similar to a TT's VGA display, actually). I think your solution would be usable on an analog CRT with a sufficiently fine dot pitch and the picture stretched way out. However, when you feed that signal to an LCD display, the hardware scaler is going to completely trash it, it's expecting 800 pixels and getting 1000. My target display is an LCD, CRTs are going away.

 

On the mono thing: Quite aware of the mono adapter, I built a cable long time ago for my 15" bench VGA. Also need to remember that you aren't at 50/60 Hz anymore. (you may notice the display is compressed vertically with these mono adapters)

 

Yes, the crux of the problem is the 15 KHz scan rate, BUT the ST's 16 MHz pixel clock is not correct for that scan rate- that's why we have the DE signal and huge borders. That's why Amiga's have a 7.16 MHz cpu clock, so they can have a proper pixel clock at the 15 KHz scan rate.

 

I'm not satisfied duplicating that mess.

 

For reference, this isn't idle speculation. I have a 1040 STf ripped apart on my bench for various experiments. I've tried several approaches over the past couple years, I haven't been pleased with them. The AL250 is has a lot of 'knobs' to turn, the thought being that you could fine tune the output (possibly via .CPX)

 

This whole issue seems simple until you actually dig into it. I would suggest to you that is the precise reason why no one is selling an inexpensive ST VGA board today. ("A CPLD (or even a small FPGA) plus a DAC should work great."). You may not think so, but the ST video signal is very strange.

 

I do like the idea of using the shifter clock to gate in the pixels, that would save oversampling. That does leave the issue of the DE signal though. If we don't use it, there's ~360 pixels of junk to deal with, but if we do, you'll miss overscan stuff. - Maybe toss the first and last 100 pixels to get down to VGA res, on a normal pixel clock. A correct pixel clock for a given VGA res is a requirement if you are targeting an LCD.

 

I've got a couple Spartan kits here, I'll see if I can get something running in the next few weeks, though I'd really like to get it all working in something like a Altera Max II.

 

For what its worth, I do appreciate the input. Even if I don't agree with you, it does make me re-think my approaches, and consider options I may have missed.

Edited December 29, 2008 by poobah