UK Vintage Radio Repair and Restoration Discussion Forum - View Single Post

TonyDuell · 9th Jan 2018, 7:43 pm

If you can get a dump of the EPROMs then there are a few 'sanity tests' that I apply by eye (by reading the hex dump)

1) Do all data bits appear both in the '0' and '1' state. That is, can you find bytes in the dump where bit 0 is a 0, some where it is a 1, then some where bit 1 is a 0 and others where it's a 1, etc. ROMs used for logic functons (such as address decoders) might fail this, but I have yet to see a firmware ROM for a microprocessor where one bit is always in the same state

2) Do all address inputs 'do something'. That is make sure the 2 halves of the ROM are not identical (meaning the highest address input has no effect), then for each half, make sure that the 2 halves of that are not identcal (meaning that the next highest address input has no effect) right down to odd and even bytes always being identical.

These 2 tests will obviously not find random bit errors. But they will pick up the (suprisingly common) faults of a failure of the address decoder or data circuits (or their bond-out wires to the package pins).

The problem with troubleshooting without a circuit diagram is that you can quickly get lost. For example, you find the processor is sitting in a tight loop of 4 or 5 instuctions. Disassembling that bit of code you see it is waiting for one bit of an I/O port to be set. But what is the I/O port? What does that bit mean? Is it that some device has not been initialised correctly due to problems elsewhere. Or a device has failed. Or something unrelated?

By the time you have figured that out you have probably spend as much time as it would take to reverse-engineer the circuit diagram. In general doing that becomes easier if there are many large-ish ICs (provided you know what they are!) like microprocessors, USARTs, etc. The reason is that such devices can only be used in one way and will enable you to find address and data buses, etc. Worse are machines built from boards of TTL (a NAND gate can be used in many ways!) and worse still are discrete transistor machines (a transistor could be used for _anything_). I've done the lot, so it is possible!

Since you have a logic probe and can get data sheets for the ICs (I assume), I would start by making sure all the following signals are pulsing -- that is not always high or low:

On the 8085 CPU:
ALE
AD0 -- AD7
A8 -- A15
RD/

It would be interesting to see if WR/ is also not always high (if it's always low you have a problem!) but it may not indicate a fault if it is.

On the EPROM(s)
All address pins
D0-D7
CS/ and OE/ If there are multiple firmware EPROMs then it's possible only one is selected so CS/ may be high all the time on some of them, but at least one should be being enabled.

9th Jan 2018, 7:43 pm	#46
TonyDuell Dekatron Join Date: Jun 2015 Location: Biggin Hill, London, UK. Posts: 5,208	Re: 8085 processor questions If you can get a dump of the EPROMs then there are a few 'sanity tests' that I apply by eye (by reading the hex dump) 1) Do all data bits appear both in the '0' and '1' state. That is, can you find bytes in the dump where bit 0 is a 0, some where it is a 1, then some where bit 1 is a 0 and others where it's a 1, etc. ROMs used for logic functons (such as address decoders) might fail this, but I have yet to see a firmware ROM for a microprocessor where one bit is always in the same state 2) Do all address inputs 'do something'. That is make sure the 2 halves of the ROM are not identical (meaning the highest address input has no effect), then for each half, make sure that the 2 halves of that are not identcal (meaning that the next highest address input has no effect) right down to odd and even bytes always being identical. These 2 tests will obviously not find random bit errors. But they will pick up the (suprisingly common) faults of a failure of the address decoder or data circuits (or their bond-out wires to the package pins). The problem with troubleshooting without a circuit diagram is that you can quickly get lost. For example, you find the processor is sitting in a tight loop of 4 or 5 instuctions. Disassembling that bit of code you see it is waiting for one bit of an I/O port to be set. But what is the I/O port? What does that bit mean? Is it that some device has not been initialised correctly due to problems elsewhere. Or a device has failed. Or something unrelated? By the time you have figured that out you have probably spend as much time as it would take to reverse-engineer the circuit diagram. In general doing that becomes easier if there are many large-ish ICs (provided you know what they are!) like microprocessors, USARTs, etc. The reason is that such devices can only be used in one way and will enable you to find address and data buses, etc. Worse are machines built from boards of TTL (a NAND gate can be used in many ways!) and worse still are discrete transistor machines (a transistor could be used for _anything_). I've done the lot, so it is possible! Since you have a logic probe and can get data sheets for the ICs (I assume), I would start by making sure all the following signals are pulsing -- that is not always high or low: On the 8085 CPU: ALE AD0 -- AD7 A8 -- A15 RD/ It would be interesting to see if WR/ is also not always high (if it's always low you have a problem!) but it may not indicate a fault if it is. On the EPROM(s) All address pins D0-D7 CS/ and OE/ If there are multiple firmware EPROMs then it's possible only one is selected so CS/ may be high all the time on some of them, but at least one should be being enabled.