Page 1 of 2
display problem with GEM
Posted: 29 Nov 2021 22:39
by Shaoth
Since Sunday, back from a convention, my Mega STE is having display problems.
IMG_20211129_152409.jpg
This happens when my ACSI2STM is connected.
If it is not plugged in, everything works fine.
IMG_20211129_152153.jpg
The machine is equipped with 4MB of memory and a TOS 2.04
The problem appears when I get to the desktop, not before during the memory test.
The mouse is active and I can open programs.
I was able to launch Arkanoid and play it, the display problems disappeared as soon as I launched the game.
IMG_20211129_161016.jpg
I was also able to launch GFA BASIC, but the problem came back with the file selection window.
IMG_20211129_161320.jpg
The power supply capacitors were changed a few months ago with a kit bought on Exxos.
I changed the TOS chips and tested with the RAM strips.
This is the machine I code on and I would really like to be able to continue using it.
Thanks for the help.
Re: display problem with GEM
Posted: 29 Nov 2021 23:05
by rubber_jonnie
That kind of looks like a RAM issue to me.
I see you say you have tested the RAM, but have you removed it and cleaned the RAM connectors and sprayed with contact cleaner?
You could also try and run with just two SIMMs and see if the problem goes, and swap the SIMMS around and see if the symptoms change.
Do you have a diag cart you can run the RAM test from? BTW in my experience if you test with YAART, you need to have a clean boot.
I'm assuming you load drivers for the ACSI2STM? Have you tried with it connected bu stopping the drivers from loading?
Re: display problem with GEM
Posted: 30 Nov 2021 07:32
by Shaoth
I have tried with 2 simms alternating them
I even tried with 256MB SIMMs different from the ones I use.
Always the same result...
And this morning I turn it on again and everything works fine!
I don't understand anything!
The connectors will be cleaned this afternoon with isopropanol
IMG_20211130_080012.jpg
Re: display problem with GEM
Posted: 30 Nov 2021 09:19
by rubber_jonnie
Glad to see it working, but disappointing to see that it just fixed itself!!
I'd give the contacts a clean with IPA like you said you would, and see how it goes.
Re: display problem with GEM
Posted: 30 Nov 2021 10:18
by Shaoth
I will keep you informed of developments in his condition.
I hope this will not happen again, although I have my doubts...
Thank you for your help.
Re: display problem with GEM
Posted: 30 Nov 2021 10:19
by rubber_jonnie
Shaoth wrote: 30 Nov 2021 10:18
I will keep you informed of developments in his condition.
I hope this will not happen again, although I have my doubts...
Thank you for your help.
You're welcome, we aim to help here :)
Re: display problem with GEM
Posted: 30 Nov 2021 10:59
by mst
Easily reproduced in a TOS 1.06 STE machine (one with good DMA, it's not from the first batches, manufactured in late 1990)
With a desktop resolution of medium, if you execute repeated times (enter into the game, and quickly exit to medium resolution desktop), a low res program such a game; it can fall into a vertical bars display. Vertical bars display only the background colour.
However, when you return to desktop, you can change resolution (from medium to low, and return to medium) various times, and it will be solved by itself.
It appears to be a mismatch configuration between Shifter and Glue logic, one remains in medium res while the other remains in low res; or something similar.
IMG_20211129_205501651.jpg
When you return to desktop, if you are lucky, the STE will display stereoscopic image... xD Obviously, the bit planes information are badly interpreted here. ¡And the red component bit plane is magically scrolled by 16 pixels to the right!
IMG_20211129_205702207.jpg
I can´t reproduce it in a TOS 1.62 STE manufactured in 1991
Re: display problem with GEM
Posted: 30 Nov 2021 11:29
by exxos
If you plug in a hard drive and it screws up, then change ROMs chips, you are again changing hardware. So it may not be anything to do with TOS itself.
I've seen this issue on STFMs where the GLUE gets a bad clock and not perfectly in sync with other chips. But that's getting into some serious diagnostics. You should probably start with a scope on the GLUE clock and see if it makes the problem better or worse and see how the clock looks on the scope.
But maybe someone else may know more about this as I never worked on faults on the MSTE.
Re: display problem with GEM
Posted: 30 Nov 2021 11:53
by Badwolf
The display looks like the high byte of the memory is being blanked.
The ACSI port is one byte wide.
What's the plug on your ASCI2STM like? Is it a sawn-off DB25 or a pin-only-no-shroud design?
It could be conincidence, but I wonder if something like this is possible if you accidentally plugged in the ACSI2STM offset by one pin.
BW
Re: display problem with GEM
Posted: 30 Nov 2021 12:46
by mst
Badwolf wrote: 30 Nov 2021 11:53
The display looks like the high byte of the memory is being blanked.
The ACSI port is one byte wide.
What's the plug on your ACSI2STM like? Is it a sawn-off DB25 or a pin-only-no-shroud design?
It could be conincidence, but I wonder if something like this is possible if you accidentally plugged in the ACSI2STM offset by one pin.
BW
If memory was really high byte blanked, the execution of any program will be ruined or crashed immediately,
When this rare situation happens (I only can reproduce it when you quickly change from medium to low res, to low res to medium... for many times)
the machine still executes the program code well and sounds ok.
Also, we can notice that the colour scheme changes; as a short of different interpretation of the colour bit planes; the image of the game with black bars, is mainly black and red; when the rare situation is switched, the red colouring turns into blue; as well the playable character is not located in a single place, there is a displacement of 16 pixels; you can view two character profiles moving around... xD
As well, if you manually code the shifter to medium res, and the glue to low res; you can view similar behaviour like these.
An accidentally bad plugged hard disk will not be operative, due to all control signals will be shifted as well,
I am curious regarding the situation in Shaoth case, I exposed a way to reproduce the situation; probably due to a uncommon triggered bug in the TOS, or hardware manufacturing version. But none ensures that Shaoth case is different, or not.