MC68000 ROM/RAM R/W issue

[gkmaia]

Not sure if that is an issue or not, but...

I got an EPS keyboard that runs on a MC68000 and does not work.

Seems data is flowing on the address and data bus. The processor tried to get some data moving for a second after boot and then go quiet.

The odd thing, I cannot really understand if that is an issue of just eh way the processor works but if you look at the printout attached you will see the processor enables a CS for both ROMs chips then enables a OE for both ROM chips. This means it is throwing at the A CYCLE the data from both ROMs in the data bus. Then it does the same with RAM, trying to write and read both RAM ICs at the same time.

I would think the CS, OE and WE would be enabled in such a way that it would only try to read or write one memory IC at a time.

Is it normal operation for the MC86000?

[Ian.M]

What else would you expect a 16 bit CPU to do for its 16 bit instruction fetches or 16 bit data access?  Its right there on the schematic - the 'Upper' memory handles D8-D15 while the 'Lower' memory handles D0-D7 at the same address.  The 68000 *can* do single byte access, that's why it has separate select lines for the upper and lower bytes of the data bus, but normally you'd only use that for I/O chips etc.

[gkmaia]

You are right... I missed it a big time.

I am looking to this for so long that I am already starting to get blind...

[gkmaia]

I did a bit more troubleshooting on the keyboard.

And I am getting really annoyed by these spikes on the data bus. They only happen at the data bus. If I look at address or control bus... no spikes. Clean signals.

First I thought they would be ghost signals, something wrong with my setup. But no, the spikes are actually there and they seem to be scrambling the data.

What is the best way to troubleshoot this type of issue? The data bus has no connection to ground or positive rail that I could blame for example a leaky cap. Instead it is basically driven by digital I/O of ICs. And as being the data bus, ALL logic ICs from ROM, RAM, MPU, 74logic is connected to it.

Not even sure from where to start to pin point what is causing these spikes.

[Ian.M]

Hmm.  Look for a TTL chip driving the bus with a bad connection to its active low /CS or /OE pin, or a CMOS chip with TTL logic driving its /OE or /CS pin and a bad connection in that logic.  It would float high, thus disabled, but capacitive coupling from a nearby falling edge transition could take it low enough for it to enable and produce a runt pulse glitch.

I'd start by looking for glitches on the /CS and /OE pins of all the memory and identifiable I/O chips.

[Renate]

Well, the address/control lines are being constantly driven in one direction from the 68000.
The data lines are all three state and bidirectional so they aren't going to look quite as textbook.

[james_s]

That's what I was thinking too, the lines on a tristate bus tend to be pretty messy looking. You should try looking at them at the same time as each OE line, the bus signals should look pretty solid whenever an OE is active and something is driving the bus.

[TK]

The spikes appear when there is a low to high transition on other lines... it could be crosstalk.

[gkmaia]

The spikes appear when there is a low to high transition on other lines... it could be crosstalk.

Do you mean cross talk in the DUT as a fault. For example an IC with shorted digital outputs?

Or cross talk on my digital probes? Not sure if it could be that as my probes are quality HP OEM stuff and the spikes also show on my analog probe.

Hmm.  Look for a TTL chip driving the bus with a bad connection to its active low /CS or /OE pin, or a CMOS chip with TTL logic driving its /OE or /CS pin and a bad connection in that logic.  It would float high, thus disabled, but capacitive coupling from a nearby falling edge transition could take it low enough for it to enable and produce a runt pulse glitch.

I'd start by looking for glitches on the /CS and /OE pins of all the memory and identifiable I/O chips.

Also re-soldered all CS/OE pins on te board and checked continuity for those. All fine.

I am attaching an image of the main driving bus. As per technical manual (also attached) all the lines that are supposed to be pulsing are pulsing. But only for a while as after a second DTACK goes high and gets stuck there.

Could it be a the ROM is corrupted? As it seems ICs are pulsing and trying to work. Or could be those spikes on the digital bus are messing with data/addresses and making te processor look for data that does not exist... etc...?

[james_s]

It's possible. Judging by past experience repairing digital hardware of that era the first thing I would suspect is a failed RAM, followed by a bad ROM. Can you find images of the data that is supposed to be on the ROMs to compare?

[gkmaia]

It's possible. Judging by past experience repairing digital hardware of that era the first thing I would suspect is a failed RAM, followed by a bad ROM. Can you find images of the data that is supposed to be on the ROMs to compare?

Thanks for feedback. I ordered a ROM writer device. May arrive in a couple weeks. And yes, I do have the ROM bins on my computer. As they arrive I can compare and re-flash if needed.

I will take the RAMs out and see if I can come up with a way to test them. Or just order a new batch. They seem cheap.

[james_s]

What kind of writer? Many of them like the popular TL866 can test SRAM chips, I haven't checked whether it supports the specific ones you have here though.

[dnwheeler]

The TL866 programmers can also test many 74- and 4000-series logic chips.

[gkmaia]

I got the TL866CS as I thought the 21v capability would be more useful than some of the extra functions the II does.

I was watching a video and it is pretty neat. Does test RAM, MPU and 74logic on top of writing ROM... for $35?!

That will be very handy to debug this keyboard when it arrives.