exxos's Atari, Amiga & retro forum

Hi All,

I have an Atari 520STM running TOS 1.00. This system suffers really badly from "jailbars" - faint vertical lines across the whole screen. I embarked on a bit of a mission today to try to finally fix it, and here are the steps I've tried (unsuccessfully) so far:

• Building a converter to be able to use an ATX power supply - tried 2 different PSUs

• Removing the RF modulator and reinstating the composite sync circuit underneath

• Removing and testing electrolytic capacitors, and replacing one where it seemed too far out of tolerance for my liking

• Desoldering and socketing the RAM, and replacing with brand new Motorola chips

• Reflowing some dodgy looking solder joints

• Reseating the Shifter and DMA chips

All to no avail... I can't find any info out there at all on this particular issue with this particulat model, so surely it's not common? The picture is bad on an Atari SC1224 monitor (low res tested) and also on my video capture setup. I also use a Mega ST and STE with this monitor / capture setup and they don't suffer from this problem.
Attached is screen capture from my OSSC / USB3HDCAP for illustration, although to be honest it doesn't really do the issue justice as I think the compression has smoothed it out a bit.

Very grateful for any help you may be able to give!

I would suggest you try a STFM. Some early boards just inherently have that problem due to bad PCB layout.

EDIT:

It's also the reason on RGB to scart cables that composite sync was used instead of the V sync from the GLUE.

I've had experience with a few 520ST models and they have all had this issue, even after recapping them. Sorry I don't have any tips for you :(

One thought I've had though, I recently fitted an RGB bypass board to a Sega Mega drive recently, a device made by a guy called Voultar. I wonder if it would be compatible with the 520ST. This solves the jailbar issues on the Mega drive.
Link: https://voultar.com/index.php?route=pro ... duct_id=73

It just amplifies the rgb output directly from the chip, and uses composite sync.

Hey, that's fine, no problem at all if it's something inherent to these earlier machines. At least I know!

Yes, I'm familiar with Voultar's work. You might be onto something with the RGB bypass - or maybe something similar to the UAV mod for the 8-bit machines?

This has really got me thinking now... I'm sure it's a rabbit hole I don't need to be going down right now but if I can have some fun debugging it and learn something in the process I'm willing to keep tinkering.

Thanks again for the replies.

Rees are you saying you're going to create a board to go where the modulator was in STMs to get better output?

Put me down for 2 please. Never mind Neo Geo controller nonsense it's all about video output on the STs that nobody else has!

Velociraptor wrote: 17 Jul 2020 23:27 Rees are you saying you're going to create a board to go where the modulator was in STMs to get better output?

Put me down for 2 please. Never mind Neo Geo controller nonsense it's all about video output on the STs that nobody else has!

Haha, thanks for the motivation. I've been looking at the schematic and it doesn't seem like it would be a huge job to hook into the R, G, and B signals from the shifter as well as the sync signals from GLUE and build a new video output circuit from there, maybe based on a THS7314 SD video amp similar to the Megadrive bypass already mentioned. I supposethe crux of the matter would be where the interference is happening - if the output from the Shifter itself isn't "clean" then it's a much more complicated issue. I'm just clearing space for my oscilloscope and investigating as we speak so watch this space.

Exxos' reply seems to imply that maybe the sync signal from GLUE is the root of the issue, in which case I'm not really sure what could be done about it other than adding some rudimentary filtering.

I'm by no means an expert in this stuff but have had a lot of success with MSX and Famicom systems regarding this issue so I'm not a complete amateur. I do feel like this would have been solved already if it was as simple as I make out, however... :lol:

I think taking the signals directly from the shifter and glue, then amplifying them on their own PCB should solve the issue. I don't see how the signals from the chips themselves could be poor quality. Ground noise could also be an issue I guess, so perhaps having its own VRM might help also.

If your looking to buffer the shifter output then it won't work.. I'll try and find the post on it later..

Edit
Looks like this was the start https://www.atari-forum.com/viewtopic.php?t=27647

Then

https://www.atari-forum.com/viewtopic.p ... 09#p306409

The only way it may work is to put a DAC on top of the shifter and totally dismantle the RGB circuit and have the RGB connector on the DAC PCB. Oh and rip out the 32mhz gen and put a proper osc there instead.

@exxos
I thought I'd seen a thread on this somewhere in the course of my research... Turns out it was a thread by you! OK, I think that's saved me a lot of timewasting. Perhaps changing the transistors (as mentioned in the other thread) will be enough of an improvement for me. Thanks for your help.

Hi Guys,
I'm an owner of one of those 520ST's affected by jail bars in LOW/MED ST modes. The bars change sometimes depending on what CPU's doing, it seems, looks like it may have something to do with DRAM refreshing like in some XE series 8-bit Ataris.

Anyway, Exxos wrote following in his ST RGB VIDEO DAC UPGRADE article ( https://www.exxosforum.co.uk/atari/last/VIDEODAC/ ):

I tried simply buffering the RGB outputs with a Schmitt buffer to clean up the lines before they go into the transistor drivers. But it did not help much, if at all. I also have swapped out the 2N3904's with a generic BC548 transistor and this helped reduced the problem.

I already both set of BC548c transistors, but I'm wondering what degree of improvement can be expected from above against the jail-bars? Anything noticable would be worth it anyway :-)

@exxos, please ? :)