• Please review our updated Terms and Rules here

Question About Parity Check 1 Error

> Both 8237's on the 2 different boards behaved the same (Logic Probe on TTL setting):

Is this with the bad board heated up enough to show the error?

Yes... I allowed the bad board to cycle with the supersoft and it was giving errors every pass after it heated up. I only tested the pins that you listed. Perhaps other pins could trigger this?
 
It could be other pins, those of the bus. But I think a logic probe is not the best tool to check those, only on a 'more dead' board it would be. An oscilloscope may give some insight.

What are the signals

-AEN (U98 Pin 3)
AEN_BRD (U98 Pin 2)

doing?

Can you try to piggy-back U18?
You don't happen to have a memory expansion that is based on SRAM? :)

Is any of U7, U9, U10 getting more hot then the reference board?
 
It could be other pins, those of the bus. But I think a logic probe is not the best tool to check those, only on a 'more dead' board it would be. An oscilloscope may give some insight.

What are the signals

-AEN (U98 Pin 3)
AEN_BRD (U98 Pin 2)

doing?

Can you try to piggy-back U18?
You don't happen to have a memory expansion that is based on SRAM? :)

Is any of U7, U9, U10 getting more hot then the reference board?

I really appreciate the help and advice. No oscilloscope here unfortunately... wouldn't know how to use it anyway, but willing to learn of course! Might check FeeBay for one.

Signals: U98 pin 3: high pulse
U98 pin 2: low during most supersoft tests, the both high and low are lit while pulsing during RAM tests

Piggy backing U18 makes no difference

after 5 minutes:
U97 - 97F
U98 - 103F
U99 - 104F

instead of switching back and forth between good and bad boards, I am going to dig out another monitor and supersoft ROM and fire up both systems side by side. It will be easier for me to compare this way.
 
Hmm, U98 (74LS175) pins 2 and 3 should be the exact opposite, i.e. I'd expect while pin 3 shows high and pulse pin 2 should be low and pulse. When one of them is low the other should be high and vice versa.
Pin 9 must always be pulsing. When Pin 4 is pulsing, 2 and 3 should also pulse.

When -DACK0 (8237 Pin 25) has pulses there should also be pulses on both U98 Pin 2 and 3.

Maybe verify on the good board during which periods the Supersoft ROM enables refresh (pulsing).
 
No oscilloscope here unfortunately... wouldn't know how to use it anyway, but willing to learn of course! Might check FeeBay for one.
Just note that an oscilloscope has limited application in digital electronics. Good for repetitive signals (clocks, vertical/horizontal sync pulses, etc.) and certain aspects (voltage levels, slope, ringing, etc.) and whether a signal is present at all, but poor for other things.
For example, if you monitored bit 5 on the address bus, took a snapshot of the ever-changing signal there, and asked us whether or not the snapshot showed that bit 5 of the address bus is correct, we could not answer with certainty. A snapshot will not, for example, reveal that some of the zeroes should be ones. This is where logic state analysers come into play.

Of course, both tools (oscilloscope and logic state analyser) take time to learn to use. But more importantly, you need to understand how the motherboard works - what points to probe, and what you expect to see there.
 
I have the good and bad boards side by side and have them running superSoft. The thing that jumps out at me the most right now is that the pulses on the bad board seem considerably faster than the pulses on the good board. On pins where the good board has rapid pulses, the bad board has crazy fast pulses. A good example is pin 21. The good board is rhythmic and predicable as it runs through the different tests. On the bad board, pin 21 sounds like someone is randomly sending morse code bursts at times.
 
I just verified the U98 readings listed earlier as correct for the bad board. It has occurred to me that my good board and bad board might behave slightly differently due to revisions. My good board is 8126... my bad board has no date code, but it is mid 1982 (both 16k-64k). One big difference between the two is the U98 pin 2 does not pulse during the 16k critical memory test on the good board, while it does pulse during this same test on the bad board. 8237 pin 25 pulses the same on both boards, except the pulse is faster on the bad board. 8237 pin 25 and U98 pin 2 definitely are not tied together on the good board as 8237 pin 25 will be pulsing while there is no pulses on the U98 pin 2.
 
Hmm, U98 (74LS175) pins 2 and 3 should be the exact opposite, i.e. I'd expect while pin 3 shows high and pulse pin 2 should be low and pulse. When one of them is low the other should be high and vice versa.
Pin 9 must always be pulsing. When Pin 4 is pulsing, 2 and 3 should also pulse.

When -DACK0 (8237 Pin 25) has pulses there should also be pulses on both U98 Pin 2 and 3.

Maybe verify on the good board during which periods the Supersoft ROM enables refresh (pulsing).
I just verified the U98 readings listed earlier as correct for the bad board. It has occurred to me that my good board and bad board might behave slightly differently due to revisions. My good board is 8126... my bad board has no date code, but it is mid 1982 (both 16k-64k). One big difference between the two is the U98 pin 2 does not pulse during the 16k critical memory test on the good board, while it does pulse during this same test on the bad board. 8237 pin 25 pulses the same on both boards, except the pulse is faster on the bad board. 8237 pin 25 and U98 pin 2 definitely are not tied together on the good board as 8237 pin 25 will be pulsing while there is no pulses on the U98 pin 2.
 
Of course, both tools (oscilloscope and logic state analyser) take time to learn to use. But more importantly, you need to understand how the motherboard works - what points to probe, and what you expect to see there.

You are exactly right... I have a limited understanding of how these motherboards actually work. I can follow the traces in the schematics and look up the function of individual chips, but that doesnt tell me why each function does what it does. I suppose i should put the logic probe down and start reading.
 
You mentioned about the LS245, but I don't recall seeing anywhere where you changed it. They are cheap and readily available, so if I were you I'd whip it out, throw in a decent (machined pin) socket and put a new one in - after all, you said it stopped working as soon as you hit it with freezer.
Note that many of the 82 series chips get hot, that's not unusual. Also, if a chip fails when you hit it with Freezer, it's not necessarily faulty, thermal shock and low temps can do that, though it will usually come good.
 
What about this part?

pins 2 and 3 should be the exact opposite

Wonder what this logic probe does, what's the meaning of "pulsing faster"?
The most meaningful time to take signals related to refresh is the 10 seconds when the Supersoft ROM does the refresh test.

Pin 21 of the 8237? It's data. You still have parity errors, right? These may have an effect on the execution of the Supersoft ROM.

We can check where the parity errors come from:
- in case the disconnected internal memory generates false parity: single pulses on U96 pins 5 (normally low) and 6 (normally high)
- from the ISA bus:U52 (LS00) pin 13: usually high, pulses low when error occurs

May be worth to try to change the LS245 - however with the internal RAM disabled it's not actively in use, and doesn't fit the different behaviour with the cooled 8237.

If I had to fix this thing my next steps would be:
- build an SRAM expansion card - not very complicated - a 62256 and LS138 will do, and some board to plug in the ISA slot.
This may give an insight wether only the refresh is affected or more stuff is broken. The Supersoft ROM may continue with the tests as it finds 32k of good memory.

- write a short ROM to only activate the refresh and then HLT the CPU. This allows for analysis of logic levels and pulses that are refresh-related.
 
Hmm, U98 (74LS175) pins 2 and 3 should be the exact opposite,

As stated in #27, I have verified my earlier results... apparently opposite of what they should be. I also noted that 8237 pin 25 is not necessarily linked to U98 on my good board which is a much earlier version that the bad board also noted in #27 of this thread.
 
Wonder what this logic probe does, what's the meaning of "pulsing faster"?

If I had to fix this thing my next steps would be:
- build an SRAM expansion card - not very complicated - a 62256 and LS138 will do, and some board to plug in the ISA slot.
This may give an insight wether only the refresh is affected or more stuff is broken. The Supersoft ROM may continue with the tests as it finds 32k of good memory.

- write a short ROM to only activate the refresh and then HLT the CPU. This allows for analysis of logic levels and pulses that are refresh-related.

Pulsing faster means that the LED which flashes indicating pulse (as well as the beep emitted)... the logic probe flashes/beeps much faster on the bad board when checking clocks etc... than on the good board.

As for expansion cards, I have several: SixPakPlus (and a few different varieties of AST cards), QuadRam Quadboard, RAM+, Persyst Time spectrum 384, etc...

I can't get back on this today, but will pick this back up tomorrow. Thanks for all the advice!
 
Your results were:

U98 pin 3: high pulse
U98 pin 2: low during most supersoft tests, the both high and low are lit while pulsing during RAM tests

Just to clarify, pin 3 is *always* pulsing, pin 2 only sometimes during certain tests? Is U98 a 74xx175 on this board? This makes U98 highly suspicious, or anything that's on its outputs.

Piggy-backing? What are the diode test results on these pins?
 
Pin 21 of the 8237? It's data. You still have parity errors, right? These may have an effect on the execution of the Supersoft ROM.

Pin 21 of 8237 is data. Yes... with the expansion RAM installed and the on-board RAM bypassed, I get no memory errors but do have parity errors.

We can check where the parity errors come from:
- in case the disconnected internal memory generates false parity: single pulses on U96 pins 5 (normally low) and 6 (normally high)
- from the ISA bus:U52 (LS00) pin 13: usually high, pulses low when error occurs


U96 pin 5 is low and pin 6 is high... no data blips ever picked up by the logic probe

U52 pin 13 (when the 8237 is hot):
during refresh - it pulses high
during memory test - high is brightly lit, low is very dimly lit and it pulses incredibly fast... makes the logic probe speaker sound like a modem

When I cool the 8237, the U52 pin 13 registers high only with no pulses
 
Your results were:

U98 pin 3: high pulse
U98 pin 2: low during most supersoft tests, the both high and low are lit while pulsing during RAM tests

Just to clarify, pin 3 is *always* pulsing, pin 2 only sometimes during certain tests? Is U98 a 74xx175 on this board? This makes U98 highly suspicious, or anything that's on its outputs.

Piggy-backing? What are the diode test results on these pins?

I carefully studied pins 1 and 2 on U98 through several cycles of the Supersoft and to clarify:
U98 pin 2:
Low without pulses during ROM tests
High/Low pulsing during 16K critical memory test
Low and pulses during "slow refresh"

U98 pin 3:
high without pulses during ROM tests
High brightly lit /Low very dimly lit and pulses during 16K critical memory test
high and pulses during "slow refresh"

U98 is indeed a 74LS175

diode between the 2 pins, or diode to +5 and ground?
 
The readings from U98 pin 2 and 3 look mostly correct. During ROM tests DMA is obviously disabled.
Parity errors occur when the 8237 has heated up.

Before going on, check that 8237 pin 12 (DCLK) has a continuously pulsing clock signal. And compare pin 6 to the good board.

My assumption: When cold, the 8237 is strong enough to win through a bus conflict and refresh the DRAMs. When heated up it loses strength and the RAMs lose their content.

The affected bus lines are control bus or address bus. The data bus is not needed to refresh the memory, and otherwise works well or you wouldn't get any output.

A bus conflict can be caused by one of the following:

- a bus driver is controlled incorrectly, thus driving the bus while the 8237 also does. U98, U97, U50, U67 and others control U14, U16. With the logic probe it's not possible to say the control signals are 100% correct. The error could be somewhere in the chain of logic. It would require a logic analyzer which may be a good investment if you have more such cases. Maybe not the cheapest model.

- a bus driver is defective, ignoring its enable input. U14, U16 are in question. There's a chance the broken driver is heating up more.

- a bus driver or receiver are defective at their bus interface. The drivers (U14, U16) or the receivers (many), on XA0-3, -XMEMR, -XMEMW are in question. In this case there's a chance an anomaly can be measured on these lines using diode test.
 
I won't have time to look at this for a couple of days. I will get back to it soon. Thanks for all your advice!
 
Back
Top