MMU doesn't generate /CAS signals.

[susher]

After trying to install a soldered in 4MB RAM upgrade (which sits under the PSU), plus a blitter socket, the machine just white screens.

After reverting the machine to stock (other than the RAM is in sockets and I've left the Blitter socket in place) the machine is still non-functional.

All the address, data and control lines on the RAM buzz out correctly, when turned on there's plenty of activity on the address lines.

However, the MMU isn't generating the /CAS0H, /CAS0L, /CAS1H and /CAS0L signals. The MMU chip works in a second STFM so it's not that. All the clocks are fine.

What controls when the MMU generates the CAS signals? I know that if there's no memory in bank 1 it turns off the signals to that bank, but you would expect it to alway run bank 0's CAS lines.

Any ideas?

[frank.lukas]

/CAS is always high ?

[Arne]

Of course it needs CLK16 input. Check if it generates CLK8 and CLK4.

[czietz]

I suppose you ruled out obvious things such as 5 V supply and clock signals to the MMU?

You can see all kinds of strange behavior until TOS has initialized the MMU config register and the video base memory address to sensible values. I think your computer crashes before that happens. I would not focus on the CAS signals but instead try to figure out how far it gets during the boot process. Check BERR, RESET and HALT lines. See if there the TOS ROMs are even accessed by checking their "enable" pin.

I always end up diagnosing early boot failures with a logic analyzer.

[Arne]

I can confirm that MMU won't output /CAS0x if CPU or TOS ROMs are missing. So besides clocks I would check these connections as czietz already suggested.

[susher]

/CAS is always high ?

Yes.

[susher]

Of course it needs CLK16 input. Check if it generates CLK8 and CLK4.

Yes, they're all fine.

[susher]

I suppose you ruled out obvious things such as 5 V supply and clock signals to the MMU?

You can see all kinds of strange behavior until TOS has initialized the MMU config register and the video base memory address to sensible values. I think your computer crashes before that happens. I would not focus on the CAS signals but instead try to figure out how far it gets during the boot process. Check BERR, RESET and HALT lines. See if there the TOS ROMs are even accessed by checking their "enable" pin.

I always end up diagnosing early boot failures with a logic analyzer.

/RESET and /HALT are high, /BERR triggers after a few memory reads. The enable line is toggling.

Looks like I may have to solder pins on all the address lines to connect the LA. (I've a 16 channel one, but it's a pain to hook up.)

[czietz]

/RESET and /HALT are high, /BERR triggers after a few memory reads. The enable line is toggling.

Does it stop, or does it repeat endlessly? In any case you should observe something different: On a working ST, after boot, a few instructions are read from the ROM, then /RESET goes low for about 15 µs (because of the RESET instruction in TOS ROM). No /BERR happens that early.

[susher]

It repeats. /RESET never goes low.

This is what two of the data lines look like... this repeats endlessly.

IMG_2030.jpg

IMG_2031.jpg

[Arne]

Then it looks like TOS code is NOT executed. Does Glue assert /ROM2?

Edit:
/RESET should be asserted as seen here:


Reset circuit releases /RESET, then CPU executes TOS code. Second instruction in TOS is a RESET instruction. That performs a 125 CLK8 assertion of the /RESET line but CPU itself is (obviously) not reset.

[susher]

Well, I think it may be trying to run something, even if it's junk, as I have a dual TOS switcher ROM with 2.06 in one side and 1.04 on the other. This above is with the 1.04 image selected. There's no decoder for TOS 2.06 in the machine so the jump address will go nowhere and crash the machine if it's selected, which is is.

I'm wondering if there's either a data line or address line to the ROMs not working, caused by the man handling of the board during the work.

[susher]

I've manually decoded the only two reads of the ROM (using /CE as the trigger on the 'scope).

It's correctly reading the first two words of the ROM and then the /CE line doesn't get asserted any more and about a second later the machine reboots.

It's almost as if the GLUE is miscounting read cycles before it stops decoding the ROM at address zero.

[susher]

Success!

I removed the empty (Exxos) blitter socket and the machine strung to life. Weird!

Actually, the data lines look clean now. I think the empty socket was acting as an antenna and sending huge amounts of noise onto the buses and causing errors.

[czietz]

Maybe a data or address line was accidentally shorted by the socket? But still: Congratulations on reviving the machine!

[susher]

Maybe a data or address line was accidentally shorted by the socket? But still: Congratulations on reviving the machine!

No, I'd checked all of that, no shorts at all.

[czietz]

I think the empty socket was acting as an antenna and sending huge amounts of noise onto the buses and causing errors.

Imho, this is unlikely. A socket flush to the mainboard is not an effective antenna. I'd still guess that there's something wrong with the socket. If it was one of these Exxos's PLCC converter things, the issue could also be on its PCB, for example, two (not necessarily directly adjacent!) pins could be shorted. However, since it's fixed now, maybe it's not worth the effort to dig into it.

[tzok]

It could be a capacitive coupling, and not a direct short.

[susher]

Every single data line?

[tzok]

Coupling between any two lines would be enough. Maybe this foam tape you mentioned on another forum, was the culprit? I also have a BLiTTER socket in my STfm and it makes no problem.

[susher]

It wasn't anywhere near the pins.

I also made sure that all the flux was cleaned off too.

The large amount of constant sinusoidal noise was on all the data lines continuously at around 2V (or greater) almost as if it was picking up a clock signal.

[czietz]

What I see on your scope screenshot above is not noise picked up from external interference. It's the data line toggling between being driven (to low level aka ground) and being not actively driven - where it will slowly go high. It never reaches high, because before it does so it is again actively driven low. This repeats every 4 CPU cycles. Meaning: What you saw there was an effect of whatever issue there was and not the cause of it.