exxos's Atari, Amiga & retro forum

asapreta wrote: 21 Oct 2024 01:35 RAS0, has this reading even, without the reset:

This is because of the Ram refresh.

CAS0L or CAS0H, are always high, except for the brief moment the reset is pressed ...
On pins 3 & 5 I can only see something if reset is pressed. (CAS1)

This is odd. You should get CAS pulses for the Video access even if the CPU is halted, and even without any RAM whatsoever. You seem to have the newer MMU chip, and I'm not so familiar with it as with the older one. But if I'm not mistaken, this should happen only if the MMU is wrongly configured. I'm not sure how this could happen. But check the MMU socket, see if one of the data bus pins has been damaged. Conceivable it could be other pins at the MMU socket.

Reparing a ST is completely new to me.
I am more a 8bit guy.

Today, if I survive the day at work, I'll continue to double check every pin connection of CPU, GLUE and MMU.

I still may be seeking the wrong simptom, but, in my opinon, as the CPU is in HALT, I should address this first.

The CPU is being halted by the chipset because something has gone wrong and it's not producing the CAS signal. It's part of the same problem.

A 16 bit system of this date isn't much different from an 8 bit one. Instead of the VIC-II and PLA from the C64 you have the GLUE, MMU and SHIFTER. Otherwise it's just a larger data and address bus width.

Check pin 5 of the MMU (CLK16). This is coming from the SHIFTER and I guess that if the MMU is not getting that clock it's not going to be doing much. Also check pin 39 on the SHIFTER for the same signal. The SHIFTER is generating it.

Also check on the ROMs to see if the /OE (output enable) pin is going low.

asapreta wrote: 21 Oct 2024 17:38 Today, if I survive the day at work, I'll continue to double check every pin connection of CPU, GLUE and MMU.

I would concentrate in the MMU socket. This seems to be the primary suspect from the symptoms you describe. May be post a good picture of the socket without the chip and people here with good experience on the matter might spot possible problems. Those sockets are quite fragile, it's not uncommon to damage them when removing the chips. Did you use a good PLCC extractor?

I still may be seeking the wrong simptom, but, in my opinon, as the CPU is in HALT, I should address this first.

As Stephen is saying, the CPU being halted is just a consequence of some hardware fault. You could trace what is causing it if you would have the right tools for this purpose, a logic analyzer, but I understand you don't.

With the scope it might be somewhat useful to measure the time from end of reset to halt, and also for how long CAS pulses are being generated after reset. May be also scope the AS signal to see how many bus cycles were performed, again after reset. This might give us some hints ... if we are lucky.

stephen_usher wrote: 21 Oct 2024 18:18 The CPU is being halted by the chipset because something has gone wrong and it's not producing the CAS signal. It's part of the same problem.

A 16 bit system of this date isn't much different from an 8 bit one. Instead of the VIC-II and PLA from the C64 you have the GLUE, MMU and SHIFTER. Otherwise it's just a larger data and address bus width.

Check pin 5 of the MMU (CLK16). This is coming from the SHIFTER and I guess that if the MMU is not getting that clock it's not going to be doing much. Also check pin 39 on the SHIFTER for the same signal. The SHIFTER is generating it.

Also check on the ROMs to see if the /OE (output enable) pin is going low.

Hi stephen_usher, again thank you very much for your support.
As soon as I arrive home, will do these checks and return with the results.

ijor wrote: 21 Oct 2024 19:04

asapreta wrote: 21 Oct 2024 17:38 Today, if I survive the day at work, I'll continue to double check every pin connection of CPU, GLUE and MMU.

I would concentrate in the MMU socket. This seems to be the primary suspect from the symptoms you describe. May be post a good picture of the socket without the chip and people here with good experience on the matter might spot possible problems. Those sockets are quite fragile, it's not uncommon to damage them when removing the chips. Did you use a good PLCC extractor?

I still may be seeking the wrong simptom, but, in my opinon, as the CPU is in HALT, I should address this first.

Sure I can post a picture of the PLCC socket.

As Stephen is saying, the CPU being halted is just a consequence of some hardware fault. You could trace what is causing it if you would have the right tools for this purpose, a logic analyzer, but I understand you don't.

With the scope it might be somewhat useful to measure the time from end of reset to halt, and also for how long CAS pulses are being generated after reset. May be also scope the AS signal to see how many bus cycles were performed, again after reset. This might give us some hints ... if we are lucky.

Unfortunately I don't have and even don't know how to use a logic analyser... :(

And my oscilloscope is limited to 20Mhz.
I intend do get a new digital one, 100Mhz, and am very prone to get it sooner than I wish.

Will do also this check of the AS signal you mentioned!

Thanks for the help!

asapreta wrote: 21 Oct 2024 19:26

ijor wrote: 21 Oct 2024 19:04 With the scope it might be somewhat useful to measure the time from end of reset to halt, and also for how long CAS pulses are being generated after reset. May be also scope the AS signal to see how many bus cycles were performed, again after reset. This might give us some hints ... if we are lucky.

And my oscilloscope is limited to 20Mhz.

That should be enough for this purpose.

stephen_usher wrote: 21 Oct 2024 18:18 The CPU is being halted by the chipset because something has gone wrong and it's not producing the CAS signal. It's part of the same problem.

A 16 bit system of this date isn't much different from an 8 bit one. Instead of the VIC-II and PLA from the C64 you have the GLUE, MMU and SHIFTER. Otherwise it's just a larger data and address bus width.

Check pin 5 of the MMU (CLK16). This is coming from the SHIFTER and I guess that if the MMU is not getting that clock it's not going to be doing much. Also check pin 39 on the SHIFTER for the same signal. The SHIFTER is generating it.

Also check on the ROMs to see if the /OE (output enable) pin is going low.

Clocks are ok and the same on both ICs
But /OE is not low on ROMs, both are HIGH.

This ST4 has two ROMs (TOS 1.2). I have already tested them in my ST540.
Jumpers W2 2-3, W3 2-3, W4 open.

Well, that means that MMU isn’t seeing the CPU ask for address zero and enabling the ROM.

When the CPU comes out of reset it does four 16 bit reads starting at address 0x00000000. The MMU should see this and set the ROM0 signal low.

What does the /AS line do at the MMU, on the chip “pin”, not the socket as we need to see what the chip is seeing. /AS (address select) should go low, the MMU should then enable /ROM0 and pull /DTACK (Data ACKnowledge) low to tell the CPU that the data is ready on the bus, then the CPU reads it and raises /AS the. MMU raises /DTACK. That’s what’s supposed to happen anyway.

asapreta wrote: 21 Oct 2024 22:36 But /OE is not low on ROMs, both are HIGH.

Never? Not even some pulses after reset? You have to test this after reset, and before the CPU is halted. Same as you did with the CAS signals. Once the CPU is halted ROM will not be accessed anymore.