Looks like I'll be getting a Mega ST4 soon

[rubber_jonnie]

So, troubleshooting this bugger again,here's what I've checked so far against the troubleshooting guide for the H4. Currently booting to a white screen.

1. Reset - works as expected.
2. Pull ups - measure as expected.
3. Bus shorts - none found.
4. First power up voltage test - need to do this again, as some of the data pins seem to have low voltages. Everything else as expected.
5. Clock checks - All clocks are present and correct.
6. First bus cycle - as per the picture below, /AS and the address lines all go low:

IMG_20200208_161544.jpg

Of course this only shows one address pin, but they all look like this when tested. Yellow is /AS and blue is the address line.

/DTACK, /LDS & /UDS all go low after reset, looking similar to the above when compared to /AS.

However, when I check the CE lines of the ROMs (6 ROM set), only LO0 and HI0 have the CE lines go low. @exxos for a 6 chip set, should I see all the CE lines go low on all the ROMS?

If you can't say I will check on a known good machine with 6 roms.

I am beginning to suspect GLUE problems here, and certainly when the machine was working, and had a moment, a pull of the GLUE and refit did tend to bring it back to life.

I need to do a complete check of the signals at the GLUE next I think.

[exxos]

GLUE has 3 ROM LINES, ROM0,ROM1,ROM2.. They were to drive 1 out of 3 ROM's (high and low driven together) its why there is a AND gate there, because if any ROMx lines goes low, the output is low, so you can drive the 2 ROM chips or single 16bit PLCC ROM that way. So its best to check on the LS11 output rather than the GLUE itself.

[rubber_jonnie]

GLUE has 3 ROM LINES, ROM0,ROM1,ROM2.. They were to drive 1 out of 3 ROM's (high and low driven together) its why there is a AND gate there, because if any ROMx lines goes low, the output is low, so you can drive the 2 ROM chips or single 16bit PLCC ROM that way. So its best to check on the LS11 output rather than the GLUE itself.

@exxos And this should be the same on the Mega4?

[PhilC]

@rubber_jonnie just think of the Mega as an STFM for fault finding purposes.

[rubber_jonnie]

@rubber_jonnie just think of the Mega as an STFM for fault finding purposes.

@PhilC Thanks, I'd kind of decided that that was the direction I was going to go as I have an old big button STF with 6 ROM TOS that should closely approximate the Mega. It'll do me a favour pulling it apart anyway since it needs an upgrade to TOS 1.04 anyway.

That will give me the opportunity to look at the signals for a working set of 6 ROMs, and compare the rest of the signals on the CPU for a working machine.

The scope has been brilliant for measuring I must say, very happy.

[rubber_jonnie]

I've been looking at this again today, but from the perspective of what a known good STFM does. If I hold down reset with power on, I see the following on the pins of a 68K on a good working machine:

On_Reset.png

When the machine is running I see pulses/strobing on the /AS line, lds, uds data and address lines etc, just as you'd expect. I need to do another diagram that shows what the pins are doing during normal operation too, then I have something easy for comparison.

So the broken Mega 4 has something fundamentally wrong, because nearly every pin (I need to do another diagram like above, but for the broken machine) is high,regardless of the state of reset. Reset held in or reset out, nearly every single pin is high. 8Mhz clock is fine as it goes, that never changes and measures consistently. So we have clock :)

Pressing reset does cause the reset pin to go low briefly though as you'd expect, and /AS briefly pulses for a few clock cycles like the good machine, but then goes high and stays high, no pulses/strobing. /AS at GLUE also stays high, though I've yet to check the /AS line at the MMU again. The rest of the pins never change.

I also managed to check a good 6 ROM STF to see what /CE was doing and during boot, LO0 and HI0 ROMS get a change in /CE, and the remainder of the ROMS don't see a signal change until the desktop arrives on screen.

Bad machine just sees LO0 and HI0 ROMS get a change in /CE, and the remainder never change.

I'm also finding the CPU is getting hot, which is a worry too.

I guess the question is, what can make all the CPU pins go high at the same time?

[exxos]

The CPU will not access the bus while /AS is high... Likely the CPU is trying to read ROM, but its not getting very far reading ROM and crashing.. normally you will see BERR going low.. assuming there is a address error of some kind. The CPU will "stall" on RESET or HALT or BERR.

Though I would check the CPU to GLUE and CPU to MMU and CPU address/databus to all the ROM sockets... I had a bad via on one of my MEGA ST on /AS to the MMU which gave odd faults. It might be easier to add the LS11 in place and use 2 ROMs as well rather than 6.

When ROM is accessed, DTACK on the CPU should also go low about the same time as /AS goes low... When the CPU sets /AS low its accessing the bus.. it gets data from whatever the address is on the bus (should be all ROM addresses which are decoded by GLUE) .. When CPU gets DTACK it finishes that cycle... the address on the bus should change as the CPU requests the next address to get data from...

Edit: I would also assume the address bus would be all 5v on reset not 1.6v...

[rubber_jonnie]

The CPU will not access the bus while /AS is high... Likely the CPU is trying to read ROM, but its not getting very far reading ROM and crashing.. normally you will see BERR going low.. assuming there is a address error of some kind. The CPU will "stall" on RESET or HALT or BERR.

Though I would check the CPU to GLUE and CPU to MMU and CPU address/databus to all the ROM sockets... I had a bad via on one of my MEGA ST on /AS to the MMU which gave odd faults. It might be easier to add the LS11 in place and use 2 ROMs as well rather than 6.

When ROM is accessed, DTACK on the CPU should also go low about the same time as /AS goes low... When the CPU sets /AS low its accessing the bus.. it gets data from whatever the address is on the bus (should be all ROM addresses which are decoded by GLUE) .. When CPU gets DTACK it finishes that cycle... the address on the bus should change as the CPU requests the next address to get data from...

Yep, I am going to check all the GLUE, MMU and CPU lines like /AS etc across all sockets. I did check the GLUE for /AS and it just stays high with a brief pulse of a few clock cycles on reset before going high again. I 'think' BERR stays high, but I will double check.

None of what you've described about ROM accesses seems to be happening at all on the bad machine. On the good machine it certainly does.

I think because /AS is staying high, it's suggesting that there is no valid address on the bus, based on the 68K datasheet, and the fact that on the good machine, after reset you see strobing, but on the bad machine it stays high and doesn't strobe.

Better go to bed I guess. I need to put the good vs bad into diagrams like above,and do the MMU, GLUE and CPU. If I can compare good to bad it may well flag something up. Time for sleeps now....

[exxos]

What you could try ( which should work but I haven't tried it myself) is remove the cpu and hardwire all the address lines to 0v along with AS,UDS,LDS then GLUE should decode that address and set the ROMS CE low, or at least the glue should set one of the ROMx lines low. glue should also pull DTACK low after decoding the address..

Then you can verify those 0v lines on the glue ... If you haven't got whats expected, then the address is wrong, or the glue or socket is faulty.

[rubber_jonnie]

@exxos Sounds like it's worth a shot, I will check all the MMU, GLUE & CPU lines before I get to desoldering the CPU though.

/AS at the GLUE i did check, and that just remains high. I read in the ST internals book that /AS comes from the MMU so I definitely need to check what that's doing.

I have some spare sockets from a donor board so at least I can look at replacing them if required.