modem7 thank you very much for your reply, it's helpful.
I read the experiment findings in the link you provided, that is very interesting information, I will remember this in my work later, it could prove useful.
In fact, as you pointed out, the symptoms I observed with the original IBM ROMs indeed gave similar findings as is described in this page when refreshing is manually turned off. Indeed after a variable amount of several seconds, the screen would also be blanked with a parity check error displayed.
Sometimes the period would last around 10-15 seconds, only just enough time to enter a 10 print "something"; 20 goto 10 program, run it and then the screen would blank and a parity check would appear at the top.
I should switch back to the IBM ROMs and probe the refresh logic from start to end to see if I can see something happen which corresponds with what happens on the screen. If I can't observe any refresh pulses or see the reset pulses being interrupted or erratic at any moment, it would be obvious to conclude that it's the refresh itself and not the parity checking mechanism. Thanks for pointing this out to me.
At the same time, I am still wondering, whatever the cause of the parity failures was before when only using the IBM BIOS, I did observe when using the generic MR BIOS that there was no problem using the mainboard for an extended period of time and no parity errors were happening at all during use of MS-DOS. Only when using a memory test in Checkit I was able to find some random parity errors in the test process reported by Checkit, and still no CPU stop event happened, the mainboard never halted the system at all. I could test the RAM for hours without any problems except to find occasional reporting of parity fails during the extended test sequences. The parity failures always would happen in a different memory area and then would keep occurring sequentially at that moment. I was getting the impression that this was not RAM area related but rather a random time moment where it would start to throw the parity errors and then keep doing that.
So the stability using the MR BIOS must have some reason for it. Perhaps there are checks in the code to verify the timer chip and reset it if needed, or something else happening in the background without any messages. Perhaps some sort of BIOS routine is acting similar as a refresh pulse on the RAMs, who knows...
Right now I am dealing with some urgent matters so I have cleared away the test setup and IBM mainboard. I restored all the original ICs as were present when I received it. As soon as I find a moment, maybe next weekend, I can resume testing and will do some probing with the scope. Having a properly matched schematic is really a huge advantage for me in this case.
Indeed, after your remarks and reading that page you linked, I feel it's better to start checking the refresh pulses through the whole circuit with a scope using the original IBM ROMs because they show parity faults much faster than when using the MR BIOS, just to observe if there is any interruption of refresh pulses happening.
The other test would be to disable parity checking entirely and then running an extended RAM test using checkit and MR BIOS. If the mainboard can run without errors for hours, that would be a clear indication that the memory control of the DRAM is not malfunctioning.
Thank you modem7, I really feel I want to make the determination whether something is failing in the refresh logic.
Also I should do more research on methods to try to remove the corroded outer layer of solder material the soldered pins in the affected areas.
I mean, resoldering is not so effective, and the corrosion seems to go into the component pins which makes them hard to solder after that anyway, so I expect that removing the solder and resoldering the ICs is not going to restore the solder joint quality to a proper state. Or maybe I can remove badly affected ICs and try to chemically treat them in some way, or polish the IC pins. The only other alternative would be to replace all the ICs. Some ICs are affected worse than others, even soldered vias have a corroded appearance in some areas. Later I will order a more delicate smooth tip for my desoldering iron which will not scratch the solder mask as easily as the standard shaped one.
I will do more testing as soon as I can find the time. I also want to first prepare a better quality ATX PSU and then exchange the wiring with AT wires and connectors. I just want to find a more precise 5V regulation and a more advanced PSU circuitry which will give me more confidence in the PSU. Perhaps I can put a series resistor between the POWER GOOD wire and the mainboard so I can short the POWER GOOD input at the mainboard side to ground for manual resetting of my test setup. I really do not like to need to power cycle these old PCBs so many times during testing when it's not really necessary.
Kind regards,
Rodney.
I read the experiment findings in the link you provided, that is very interesting information, I will remember this in my work later, it could prove useful.
In fact, as you pointed out, the symptoms I observed with the original IBM ROMs indeed gave similar findings as is described in this page when refreshing is manually turned off. Indeed after a variable amount of several seconds, the screen would also be blanked with a parity check error displayed.
Sometimes the period would last around 10-15 seconds, only just enough time to enter a 10 print "something"; 20 goto 10 program, run it and then the screen would blank and a parity check would appear at the top.
I should switch back to the IBM ROMs and probe the refresh logic from start to end to see if I can see something happen which corresponds with what happens on the screen. If I can't observe any refresh pulses or see the reset pulses being interrupted or erratic at any moment, it would be obvious to conclude that it's the refresh itself and not the parity checking mechanism. Thanks for pointing this out to me.
At the same time, I am still wondering, whatever the cause of the parity failures was before when only using the IBM BIOS, I did observe when using the generic MR BIOS that there was no problem using the mainboard for an extended period of time and no parity errors were happening at all during use of MS-DOS. Only when using a memory test in Checkit I was able to find some random parity errors in the test process reported by Checkit, and still no CPU stop event happened, the mainboard never halted the system at all. I could test the RAM for hours without any problems except to find occasional reporting of parity fails during the extended test sequences. The parity failures always would happen in a different memory area and then would keep occurring sequentially at that moment. I was getting the impression that this was not RAM area related but rather a random time moment where it would start to throw the parity errors and then keep doing that.
So the stability using the MR BIOS must have some reason for it. Perhaps there are checks in the code to verify the timer chip and reset it if needed, or something else happening in the background without any messages. Perhaps some sort of BIOS routine is acting similar as a refresh pulse on the RAMs, who knows...
Right now I am dealing with some urgent matters so I have cleared away the test setup and IBM mainboard. I restored all the original ICs as were present when I received it. As soon as I find a moment, maybe next weekend, I can resume testing and will do some probing with the scope. Having a properly matched schematic is really a huge advantage for me in this case.
Indeed, after your remarks and reading that page you linked, I feel it's better to start checking the refresh pulses through the whole circuit with a scope using the original IBM ROMs because they show parity faults much faster than when using the MR BIOS, just to observe if there is any interruption of refresh pulses happening.
The other test would be to disable parity checking entirely and then running an extended RAM test using checkit and MR BIOS. If the mainboard can run without errors for hours, that would be a clear indication that the memory control of the DRAM is not malfunctioning.
Thank you modem7, I really feel I want to make the determination whether something is failing in the refresh logic.
Also I should do more research on methods to try to remove the corroded outer layer of solder material the soldered pins in the affected areas.
I mean, resoldering is not so effective, and the corrosion seems to go into the component pins which makes them hard to solder after that anyway, so I expect that removing the solder and resoldering the ICs is not going to restore the solder joint quality to a proper state. Or maybe I can remove badly affected ICs and try to chemically treat them in some way, or polish the IC pins. The only other alternative would be to replace all the ICs. Some ICs are affected worse than others, even soldered vias have a corroded appearance in some areas. Later I will order a more delicate smooth tip for my desoldering iron which will not scratch the solder mask as easily as the standard shaped one.
I will do more testing as soon as I can find the time. I also want to first prepare a better quality ATX PSU and then exchange the wiring with AT wires and connectors. I just want to find a more precise 5V regulation and a more advanced PSU circuitry which will give me more confidence in the PSU. Perhaps I can put a series resistor between the POWER GOOD wire and the mainboard so I can short the POWER GOOD input at the mainboard side to ground for manual resetting of my test setup. I really do not like to need to power cycle these old PCBs so many times during testing when it's not really necessary.
Kind regards,
Rodney.
