Answering in line below.
Thanks for your help. Jeff From: M100 <[email protected]> On Behalf Of Fugu ME100 Sent: Friday, May 4, 2018 8:38 AM To: [email protected] Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100 >>Are the RD*, WR* and IO/M* signals OK? They go through a buffer M20 before being used. The ROM CS- only relies on A15, STROM- & IO/M-, if IO/M- is stuck at 0, then CS would work, but the I/O ports would not be accessed. Holding the 80C85 is reset should allow the outputs of M20 to go high, the inputs have pull-ups. The RD*, WR* and IO/M* all change states. But, IO/M only toggles states at reset. I do believe it is stuck low. >>If the '245 M2 data bus buffer direction is not changed by RD* then the processor might be reading garbage from the data bus. All of the Address Decoding is done on the upper 8 Address bits so the chip selects do not depend on AD0-AD7 buffers. I know that the /RD* signal is getting to M2. I was seeing a bit of the same 'oddness' which corresponded with the /ALE so I'm guessing that is normal. I'm going to have to think some about how to determine of the direction is being correctly changed. I'm guessing that I would be seeing much more 'oddness' if it were not. Maybe looking at the /RD* and AD0 (on both sides) would work. I'm guessing that if I don't see the same signal on both sides of one A/D line that would indicate bus contention? >>On boot there is a 10,000 cycle loop (approx 100ms delay) before there is I/O activity setting up the 81C55. This might be the 'The ROM /CS is also toggling for a while after reset' state you are observing, any idea how long the activity lasts? After that the IO/M- line should start to toggle as the 81C55 is set up and the keyboard read. I'll attempt to determine how long the activity lasts. On random occasions it will 'run' after reset but the IO/M never toggles. It seems off that even if it is running garbage code that the IO/M would never toggle. It does change states on reset so it is not shorted low. >>The first RAM access occurs after all the I/O is configured and the keyboard scanned. If you see no IO/M* activity after the short delay then the processor could be reading invalid data and just not executing any IN/OUT operations. There could be a few reasons for this: faulty buffer M20, faulty M2, address conflict another CS/CE line could be low at the same time, bad ROM socket or failing ROM. Check that all the CE- lines (M4 only one RAM module present) are high and none are low, also check that none of the I/O port enables (M16) are low during the ROM CS-. Might want to make sure these chips also have VDD present. >>I would read the ROM in situ. If you can clip onto M2 it should be possible to check that the 80C85 is really getting the data from the ROM. I was checking the A/D line (well all line) on the ROM by touching the tops of the pins. It seems all signals are getting through. I will check 16 w.r.t. the ROM CS as well happened to find my old 'DIP clip' the other day. I think there is enough room to get it clipped on M2. That SIP resistor is pretty close though. >>It should be possible to get this down to a single failed IC or track without pulling chips :-D That is my goal! It is fun to learn a bit about the architecture while troubleshooting. Thanks again for your help.
