Mega ST4 - no video output at all

[stephen_usher]

So, now you have activity on the RAS and CAS lines after reset follow them to the U59(?) and test them both sides of that chip.

At this point don’t focus on the RAM as it could well not be that. Let’s first check all the parts of the system which give access to the RAM and check the signals are going where they should.

If lifting the /HALT pin changes things then the system is halting the processor and hence will probably stop everything else, including RAS and CAS.

[asapreta]

So, now you have activity on the RAS and CAS lines after reset follow them to the U59(?) and test them both sides of that chip.

At this point don’t focus on the RAM as it could well not be that. Let’s first check all the parts of the system which give access to the RAM and check the signals are going where they should.

If lifting the /HALT pin changes things then the system is halting the processor and hence will probably stop everything else, including RAS and CAS.

Hi, I still don't have CAS, when I tied the lifted PIN 17 (HALT) to RESET. I thought I had activity in Data and Address lines in CPU but there was a catch, see below.

What I do have is activity in Address lines in RAM chips, with no significant difference between them, só I guess the problem may not be RAM. But no CAS, only high level reading.

I did further inspection to this signal (HALT - PIN Lifted to RESET) and got this:

IMG_20241020_110533136.jpg

The Lifted PIN 17 (HALT) is making the RESET sinal to pulse, It is not good.
So I decided to connect this PIN 17, to 5V through a 4.7K resistor.

And for my surprise, again white border with black square screen.

Is HALT a bidirecional signal? Why? On the resistor, I am reading 0.8v in PIN 17 side. 4.9V in Vcc one.

Edit: just saw it is:

Screenshot_20-10-2024_113549_www.google.com.jpeg

So some other(s|signal(s) are making the CPU to enter in HALT state

Just for checking, I swapped the CPU with one amiga500 I have handy here and It is working.

I don't know If I am chasing the correct problem, but It CPU is noy running, erverything else won't manter.

[frank.lukas]

Halt Signal is birectional so the CPU can put is Aktiv (Low) or the ST Chipset can it also put Aktiv and Low ...

-----------------
Halt (HALT)
An input to this bidirectional signal causes the processor to stop bus activity at the
completion of the current bus cycle. This operation places all control signals in the
inactive state and places all three-state lines in the high-impedance state (refer to Table
3-4).
When the processor has stopped executing instructions (in the case of a double bus
fault condition, for example), the HALT line is driven by the processor to indicate the
condition to external devices.
-----------------------------

[rubber_jonnie]

As Frank said, the /HALT line is bi-directional so the CPU could be halting, but the the signal could be from elsewhere on the board.

With the pin lifted, what are you seeing on the /HALT line at the socket?

[asapreta]

As Frank said, the /HALT line is bi-directional so the CPU could be halting, but the the signal could be from elsewhere on the board.

With the pin lifted, what are you seeing on the /HALT line at the socket?

Hi rubber_jonnie, I have high TTL. There and also on PIN 4 of 7407.
On the pin 17 itselft low TTL

@frank.lukas Thank you, I realized that...

[ijor]

Halt Signal is birectional so the CPU can put is Aktiv (Low) or the ST Chipset can it also put Aktiv and Low ...

As Frank said, the /HALT line is bi-directional so the CPU could be halting, but the the signal could be from elsewhere on the board.

Not exactly. HALT is indeed bidirectional and this was designed mainly for debugging purposes. HALT can be used to single step the CPU. But in the ST, HALT is not connected to anything except to the Reset logic. The chipset can't assert HALT (well, except for the Reset chip) and there is no chip or logic that reads the HALT signal.

It is the CPU that is asserting HALT because of a double fault. It doesn't mean too much. It could be for multiple reasons, but it could be very well something related to RAM. Ideally you would need a logic analyzer to see what exactly happens between Reset and the CPU halting.

If lifting the /HALT pin changes things then the system is halting the processor and hence will probably stop everything else, including RAS and CAS.

No. Ram refresh should continue unless something is very wrong and that should provoke RAS pulses. Even CAS pulses should normally continue for Video cycles. But it depends on the configuration state.

[asapreta]

Halt Signal is birectional so the CPU can put is Aktiv (Low) or the ST Chipset can it also put Aktiv and Low ...

As Frank said, the /HALT line is bi-directional so the CPU could be halting, but the the signal could be from elsewhere on the board.

Not exactly. HALT is indeed bidirectional and this was designed mainly for debugging purposes. HALT can be used to single step the CPU. But in the ST, HALT is not connected to anything except to the Reset logic. The chipset can't assert HALT (well, except for the Reset chip) and there is no chip or logic that reads the HALT signal.

It is the CPU that is asserting HALT because of a double fault. It doesn't mean too much. It could be for multiple reasons, but it could be very well something related to RAM. Ideally you would need a logic analyzer to see what exactly happens between Reset and the CPU halting.

If lifting the /HALT pin changes things then the system is halting the processor and hence will probably stop everything else, including RAS and CAS.

No. Ram refresh should continue unless something is very wrong and that should provoke RAS pulses. Even CAS pulses should normally continue for Video cycles. But it depends on the configuration state.

Thanks for the detailed explanation.
The white border with black square screen usually means bad RAM.

Should I focus finding the bad RAM?

[ijor]

Thanks for the detailed explanation.
The white border with black square screen usually means bad RAM.
Should I focus finding the bad RAM?

Honestly I'm not sure. That's something better answered by others, like @stephen_usher and @rubber_jonnie. They have much more experience than me. I can only speak from the theory, which is my area of expertise.

[stephen_usher]

If you are not getting a CAS signal then there's absolutely no point looking at the RAM, full stop. Forget the RAM!

Tests, with CPU in socket and /HALT not lifted:

Put oscilloscope probe on Pin 6 (CAS1L) of MMU socket and hit reset: Note if there's any signal.
Put oscilloscope probe on Pin 7 (CAS1H) of MMU socket and hit reset: Note if there's any signal.
Put oscilloscope probe on Pin 8 (RAS1) of MMU socket and hit reset: Note of there is any signal.

*IF* there are signals there then the MMU has a connection to the socket.

Go to chip U59.

Put scope probe on Pin 17 (CAS1L) and note if signal after reset.
Put scope probe on Pin 15 (CAS1H) and note if signal after reset.
Put scope probe on Pin 4 (RAS1) and note if signal after reset.

If the same signals appear on those pins as on the MMU sockets you have verified that the traces between the MMU and the buffer chip are correct.

Check the power and ground pint on U59. Check pins 1 and 19 are also grounded (0V).

Put scope probe on pin 5 (CAS1L output) and note if signal.
Put scope probe on pin 3 (CAS1H output) and note if signal.
Put scope probe on pin 16 (RAS1 output) and note if signal.

Because the 74LS244 is always enabled the outputs should always follow the inputs. If they don't then the 74LS244 is probably bad. You may be able to tast this with piggybacking a known good chip if the outputs are always high and the inputs are toggling.

If there's no signal then the lines should either drift high or float at some undefinted voltage. If they are low then something is pulling them down and you may have a short. If AND ONLY IF pins 3, 5 or 16 are low when the inputs are toggling then you could possibly have a bad RAM chip which has failed in a way I've NEVER ever seen before or a short between the line and ground.

While you're at it check for shorts between CAS1L/CAS1H and ground (and each other).

[asapreta]

If you are not getting a CAS signal then there's absolutely no point looking at the RAM, full stop. Forget the RAM!

OkaY!!

Tests, with CPU in socket and /HALT not lifted:

Put oscilloscope probe on Pin 6 (CAS1L) of MMU socket and hit reset: Note if there's any signal.
Put oscilloscope probe on Pin 7 (CAS1H) of MMU socket and hit reset: Note if there's any signal.
Put oscilloscope probe on Pin 8 (RAS1) of MMU socket and hit reset: Note of there is any signal.

*IF* there are signals there then the MMU has a connection to the socket.

CAS0L or CAS0H, are always high, except for the brief moment the reset is pressed, I get this reading below on both:

CASL0-reset.jpg

RAS0, has this reading even, without the reset:

WhatsApp Image 2024-10-20 at 21.24.21.jpeg

Go to chip U59.

Put scope probe on Pin 17 (CAS1L) and note if signal after reset.
Put scope probe on Pin 15 (CAS1H) and note if signal after reset.
Put scope probe on Pin 4 (RAS1) and note if signal after reset.

If the same signals appear on those pins as on the MMU sockets you have verified that the traces between the MMU and the buffer chip are correct.

Check the power and ground pint on U59. Check pins 1 and 19 are also grounded (0V).

Signals are the same as read on MMU for these pins on U59.
Also pins 1 and 19 are grounded.

Put scope probe on pin 5 (CAS1L output) and note if signal.
Put scope probe on pin 3 (CAS1H output) and note if signal.
Put scope probe on pin 16 (RAS1 output) and note if signal.

Because the 74LS244 is always enabled the outputs should always follow the inputs. If they don't then the 74LS244 is probably bad. You may be able to test this with piggybacking a known good chip if the outputs are always high and the inputs are toggling.

On pins 3 & 5 I can only see something if reset is pressed.
Pin 16, has the similar wave signal read from previous RAS readings

If there's no signal then the lines should either drift high or float at some undefinted voltage. If they are low then something is pulling them down and you may have a short. If AND ONLY IF pins 3, 5 or 16 are low when the inputs are toggling then you could possibly have a bad RAM chip which has failed in a way I've NEVER ever seen before or a short between the line and ground.

While you're at it check for shorts between CAS1L/CAS1H and ground (and each other).

The CAS0L or CAS0H are high.
No shorts to ground or between them

Thanks for the patience, and sharing your knowledge.