LC III - Will it ever run?

[stephen_usher]

Actually, for this job I could do with an 128 channel logic analyser to capture both the 32 bit address bus and the 32 bit data bus along with the other signals.

With respect to the sample rate, it’s already trice the CPU clock and the 68030 doesn’t do anything within one clock cycle. Read cycles are multiple clock cycles long.

The /AS (address strobe) signal looks the same as on the oscilloscope.

[stephen_usher]

Hmm.. I wonder if the CPU is trying to do a burst read and the request line isn't working. Need to check tonight.

[stephen_usher]

OK, so no burst read is being requested but /STERM is being activated.

IMG_3638.jpeg (212.97 KiB) Viewed 4320 times

The /BERR happens after a timeout.

But /DSACK0 and /DSACK1 never go low!

I wish that I had a reference system to see if the start of this is normal.

[stephen_usher]

Well, looking at the beginning of the LC III ROM the data on the data bus doesn't match the top four bits of either ROM so something is definitely screwy.

[stephen_usher]

OK, reading what the ROM is sending/being asked to send looks good.

I see the first two words and then the address read from an address starting with the same lower nibble as the program counter address loaded from ROM. It then loads two instructions correctly and then does a read which never completes.

I think I now need a ROM disassembly to try to work out what hardware it's trying to read from which is not responding.

[stephen_usher]

Anyway, I think the next thing I'll do is replace the ROM sockets, but not until Sunday.

[Badwolf]

OK, so no burst read is being requested but /STERM is being activated.

The /BERR happens after a timeout.

But /DSACK0 and /DSACK1 never go low!

Sorry, I've not been following the thread in detail, but from your screen capture it looks like you've got an 030.

In which case: STERM and DSACKx are mutally exclusive ways to end the bus cycle, so that's normal for a synchronous 32 bit read or write.

Also for a single 32 bit wide read A0 and A1 will always be low. So that looks alright. In fact it looks good as, for example, the attempt to read the program counter returned 0xffffffff, you'd get a high A1.

First few reads will always be 0x0 to 0x7. If that's reading in 32 bit mode, that'll only be two cycles.

If the ROM's at 0x4xxxxxxx (how odd for an Atari man to see addresses up there!), then you should see A30 go high after the first couple (or so) of cycles.

Is the ROM chip select behaving as it ought? I'm quite impressed this implies 32 bit ROM.

BW

[stephen_usher]

The /OE on the ROMs looks to be following /AS at least for the first bunch of reads.

I'm wondering if the CPU isn't seeing all the data bits the ROMs are setting on the data bus. This would make the start address wrong and it would also load a corrupted instruction and maybe try to access something in the I/O area, which the hardware doesn't protect. Then, if there's no hardware at that address then it would never acknowledge the read and it would wait until it timed out. That's my theory anyway.

So as to rule out the sockets, the HI ROM socket has corroded wipers, I'm going to replace them both.

Yes, the machine has two 16 bit ROMs, so it's doing 32 bit transfers.

This would be why a > 64 channel logic analyser would be useful.

[Badwolf]

I'm wondering if the CPU isn't seeing all the data bits the ROMs are setting on the data bus. This would make the start address wrong and it would also load a corrupted instruction and maybe try to access something in the I/O area

...

So as to rule out the sockets, the HI ROM socket has corroded wipers, I'm going to replace them both.

High would make most sense in that scenario. A low word with dodgy reads would stand a very good chance of casting you off your longword-aligned pedestal and you'd see something on A1

BW

[stephen_usher]

Of course I don't know if it's the ROM getting an faulty address or the data from the ROM missing bits.