MEGA ST2 - "random" characters on the screen

[DominoTree]

Yeah I think I’ll go down those roads next - I do have a 134-channel logic analyzer here that I’ve been avoiding wiring up but maybe I should bite the bullet lol, starting with the keyboard and working back

[DominoTree]

On my STF I got fed up a while back and removed and resoldered every component on the board... it was a pain and probably a waste of effort overall but it did resolve several weird issues

[DominoTree]

I threatened it earlier and I’m starting now, found a couple questionable connections so I’m depopulating the board and inspecting everything and doing a full continuity test

This is gonna be a fun weekend...

95687912-F36F-430B-9A71-0FDA2F20C631.jpeg (1008.4 KiB) Viewed 3195 times

[DominoTree]

MMU done, found a second bad trace - was only aware of one before
GLUE is all good

More to come...

[mfro]

If your problem are the apparently "misplaced, random" characters (the "J", "q", "p" and "E") on the photo in your initial post, I'm afraid you are on the wrong track with your repair attempts. Better stop and reconsider. You are probably trying to repair something that isn't broken.

I'm sure these characters aren't random (or misplaced) at all.

If you look closer, all these characters are from the VT52 terminal control command set (ESC-J for "clear to end of screen", ESC-q "reverse video", ESC-p "normal video" and ESC-E "clear screen") and appear at screen positions where they definitively make sense. To me, it appears it's just that the VT52 Emulation on your ST is not correctly interpreting the ESC at the beginning of the sequence or (probably more likely) your terminal is somehow set to raw mode.

As I can hardly think of a failing hardware component that would cause this, I would strongly recommend to revisit the software first.

[rubber_jonnie]

I have some experience repairing Megas and I honestly wouldn't recommend depopulating as a means of troubleshooting, you could easily cause more damage to the board, introduce new problems, and it won't necessarily get you to the root of your problem.

If your machine is modded, then documenting the mods and removing them so you have a base machine is certainly ok to do, because it immediately rules out the mods, and I've done this a few times myself.

Removing components one at a time and socketing is also a valid method if your troubleshooting leads you to that component.

You don't need to have components removed to do continuity checks, and you'd be better off trying to use a scope, logic probe or analyser and multi-meter to check the hardware side of things in conjunction with a diag cart where you can repeat tests reliably and consistently.

Troubleshooting with the components on board might take a long time, as I know only too well, but certainly no longer than a strip down of the board and reinstallation of all components, and it carries far less risk.

I'm also inclined to think this is a software problem as suggested by @mfro

[PaulJ]

I believe you should rethink your strategy. This strategy you are following falls under shotgunning and rarely if ever delivers good results. Your chances of causing additional damage to the board is much higher than stumbling on a fix. This is why people don't want to work on a computer that has been worked on by it owner and obvious shot gunning is evident. You need to set down your soldering iron and come up a logical reason why your experiencing the issue you have and then test and verify. Then when your confident you have identified the faulty component replace or patch it. Your not even experincing a worst case scenario where the issue is random. Good luck.

[DominoTree]

I definitely understand that this isn't the best approach and it's certainly not what I want to spend my Saturday on, but it's yielding results, and it needed to be done anyways due to some minor corrosion issues, and testing continuity is way easier with an empty board, particularly with the PLCCs.

As to the original problem, the same UltraSatan produces normal output on my three other STs, and I've tried multiple versions of TOS as well. From previous troubleshooting, I'm experiencing a number of behaviors that make me think something's going on with the keyboard ACIA or its supporting circuitry, and interestingly, the behavior changes based on the added capacitance of resting my finger on the keyboard port. I can't see this being software.

[mfro]

Again, the only obvious failure is with your VT52 emulation (or are there others you didn't tell us?). And that is just software in any ST. Changed behavior with a finger on something is not necessarily a failure (STs probably haven't been designed explicitly to ignore that).

Of course one can't rule out hardware completely, but the very first thing to try is always without any auto-started programs anyway.
How does it behave then?

[DominoTree]

Again, the only obvious failure is with your VT52 emulation (or are there others you didn't tell us?). And that is just software in any ST. Changed behavior with a finger on something is not necessarily a failure (STs probably haven't been designed explicitly to ignore that).

Of course one can't rule out hardware completely, but the very first thing to try is always without any auto-started programs anyway.
How does it behave then?

Any non-GEM app that outputs text does the same thing unless I do something like hold my finger over the keyboard connector, and then it just behaves normally. Everything else seems fine. Sometimes putting my finger there is required for the keyboard to even work in the first place.

A YAART ROM on the cartridge port also behaves the same way when it puts text on the screen.

At this point I think that's the only thing going on.