info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
CMOS errors on Model 70
103 views
Skip to first unread message
Nick Silvestro
Dec 21, 2021, 12:23:39 AM12/21/21
to
Trying to get a PS/2 Model 70 up and running but constantly getting 162/163 errors in a boot loop.
Was originally getting 161/163, so I replaced the battery and ran automatic configuration. Upon reboot after that, I got the 162/163 errors. Going into the reference disk setup program again and it shows the error stating that there was an error in the battery powered configuration data.
Attempting to restore the config and the machine just rebooted and kept going around in this loop. If I leave the battery out for a while and try again, it goes back to 161, but then repeats the same thing above. It also does seem to remember RTC settings, as a hard reboot in DOS keeps the time and date set.
I've been able to drop into the ref disk checkout and run tests, and the system board check notes an error of 00010300 and tells me to replace the system board. All other tests come back fine.
I've verified that the RTC and SRAM ICs are getting standby and runtime power correctly. I've now also gone as far as replacing both of them with replacement parts but still showing the same issues. The whole planar is in excellent condition with no corrosion or trace damage that I can find with a visual inspection.
I'm pretty much out of ideas at this point. Anyone have any ideas to help with this?
Thanks in advance!
Photos with screenshots of errors described above https://photos.app.goo.gl/ULvkgJ5CxLZoeNk7A
Was originally getting 161/163, so I replaced the battery and ran automatic configuration. Upon reboot after that, I got the 162/163 errors. Going into the reference disk setup program again and it shows the error stating that there was an error in the battery powered configuration data.
Attempting to restore the config and the machine just rebooted and kept going around in this loop. If I leave the battery out for a while and try again, it goes back to 161, but then repeats the same thing above. It also does seem to remember RTC settings, as a hard reboot in DOS keeps the time and date set.
I've been able to drop into the ref disk checkout and run tests, and the system board check notes an error of 00010300 and tells me to replace the system board. All other tests come back fine.
I've verified that the RTC and SRAM ICs are getting standby and runtime power correctly. I've now also gone as far as replacing both of them with replacement parts but still showing the same issues. The whole planar is in excellent condition with no corrosion or trace damage that I can find with a visual inspection.
I'm pretty much out of ideas at this point. Anyone have any ideas to help with this?
Thanks in advance!
Photos with screenshots of errors described above https://photos.app.goo.gl/ULvkgJ5CxLZoeNk7A
Louis Ohland
Dec 21, 2021, 1:23:38 AM12/21/21
to
Nick Silvestro
Dec 21, 2021, 1:57:39 AM12/21/21
to
The battery assembly is intact and works fine. Has nice continuity between the battery terminals and the pin header on the board.
Louis Ohland
Dec 21, 2021, 10:01:02 AM12/21/21
to
Did you clear the CMOS?
Louis Ohland
Dec 21, 2021, 10:11:18 AM12/21/21
to
Tomas Slavotinek
Dec 21, 2021, 11:44:00 AM12/21/21
to
Hey Nick,
Since you have already replaced both chips (with compatible and
known-good parts, I assume) and verified that they are getting voltage
in both modes, we can move to the other signals.
First, I'd check the Clear POP line (active low) that goes from the
speaker/battery assembly (there's no jumper there, right?) to the
non-volatile circuitry. It should lead to the -PS input of the MC146818
CMOS/RTC chip, possibly through some glue logic.
https://ardent-tool.com/misc/Battery_Speaker_Assembly.html
I'm not sure if the Model 70 POST performs the CMOS and NVRAM rolling
bit tests known from the later systems. I'll have to check. If it does,
then we can eliminate all the data, address, and control lines from the
equation. If not, then these should be checked as well. Either from the
software side or with a logic analyzer.
A simple write/read test to both chips may be a good idea no matter what...
I'm not sure if the 103 diag error is related to any of this, but it
very well could. Unfortunately, it's a rather generic code triggered
from multiple different places/tests. The system doesn't throw the same
error during the POST, right? I find that interesting because I know for
a fact that there are multiple POST checks associated with that
particular code. If we can't figure this out by any other means, I'll
compare the POST code with the refdisk diags to see what extra checks
are performed there. That could give us some clue about the fault.
Happy hunting!
Btw, which planar do you have?
(https://ardent-tool.com/50_70/)
Since you have already replaced both chips (with compatible and
known-good parts, I assume) and verified that they are getting voltage
in both modes, we can move to the other signals.
First, I'd check the Clear POP line (active low) that goes from the
speaker/battery assembly (there's no jumper there, right?) to the
non-volatile circuitry. It should lead to the -PS input of the MC146818
CMOS/RTC chip, possibly through some glue logic.
https://ardent-tool.com/misc/Battery_Speaker_Assembly.html
I'm not sure if the Model 70 POST performs the CMOS and NVRAM rolling
bit tests known from the later systems. I'll have to check. If it does,
then we can eliminate all the data, address, and control lines from the
equation. If not, then these should be checked as well. Either from the
software side or with a logic analyzer.
A simple write/read test to both chips may be a good idea no matter what...
I'm not sure if the 103 diag error is related to any of this, but it
very well could. Unfortunately, it's a rather generic code triggered
from multiple different places/tests. The system doesn't throw the same
error during the POST, right? I find that interesting because I know for
a fact that there are multiple POST checks associated with that
particular code. If we can't figure this out by any other means, I'll
compare the POST code with the refdisk diags to see what extra checks
are performed there. That could give us some clue about the fault.
Happy hunting!
Btw, which planar do you have?
(https://ardent-tool.com/50_70/)
Nick Silvestro
Dec 21, 2021, 6:10:18 PM12/21/21
to
Tomas, thanks for the in-depth response!
I set the POP jumper as one of my first checks - left it in overnight to no avail, and have since removed. That was well before I went down the route of replacing chips and checking continuities etc. I haven't fully checked if the jumper is actually getting to the ~PS or if the ~PS line is actually active low at the RTC side though, so I'll check that shortly.
I don't have a logic analyser, nor the skills to operate, so I'm a bit out of luck there. The best I can probably do is probe the address lines on my scope and see if they seem healthy, so I guess I'll try that next too. I can F1 to bypass the POST errors and boot into DOS via floppy, so if there's a software method to test them that'd be ideal.
The only POST errors showing are either a combo of 161/163 (if the CMOS has been reset) or 162/163 (after automatic config has been run). I do notice that the 161 error comes up immediately when CMOS is empty, but the 162 error takes around ~6-8 seconds to show after the memory test - not sure if that's significant.
This system is the 8570 Type 1 planar. I've dumped and verified both ROM ICs as well, and they're healthy, and I've also changed CPU to a known working 386SX 16mhz and tried a 386DX 20 too, both showing the same problem.
Cheers,
Nick
I set the POP jumper as one of my first checks - left it in overnight to no avail, and have since removed. That was well before I went down the route of replacing chips and checking continuities etc. I haven't fully checked if the jumper is actually getting to the ~PS or if the ~PS line is actually active low at the RTC side though, so I'll check that shortly.
I don't have a logic analyser, nor the skills to operate, so I'm a bit out of luck there. The best I can probably do is probe the address lines on my scope and see if they seem healthy, so I guess I'll try that next too. I can F1 to bypass the POST errors and boot into DOS via floppy, so if there's a software method to test them that'd be ideal.
The only POST errors showing are either a combo of 161/163 (if the CMOS has been reset) or 162/163 (after automatic config has been run). I do notice that the 161 error comes up immediately when CMOS is empty, but the 162 error takes around ~6-8 seconds to show after the memory test - not sure if that's significant.
This system is the 8570 Type 1 planar. I've dumped and verified both ROM ICs as well, and they're healthy, and I've also changed CPU to a known working 386SX 16mhz and tried a 386DX 20 too, both showing the same problem.
Cheers,
Nick
Tomas Slavotinek
Dec 21, 2021, 7:33:47 PM12/21/21
to
Scope will do, just check the data/address one by one if you see some
reasonably looking activity. Control signals like Chip Select and Output
Enable will only toggle when you do an actual CMOS/NVRAM operation.
And yes it's relatively easy to test both chips from software.
The RTC registers and CMOS memory can be accessed through I/O ports 70h
(index) and 71h (data). The MC146818A RTC/CMOS chip in Model 70 has 10
RTC registers (index 0-9h), 4 control registers (A-Dh) and 50
general-purpose CMOS locations (0E-3Fh). More about the chip and its
registers here:
https://ardent-tool.com/datasheets/Motorola_MC146818A.pdf
You can do a simple r/w test on a selected location of the RTC CMOS
memory using the DOS DEBUG utility. Something like this should work:
("-" is the DEBUG prompt, ";" and everything behind are comments)
-o 70 11 ; select CMOS index 11h
-o 71 55 ; write 55h (all even bits 1) to index 11h
-i 71 ; read back value at index 11h, you should get your 55h back
-o 71 AA ; write AAh (all odd bits 1) to the same index
-i 71 ; you should get AAh back
The extended NVRAM is accessed via ports 74h (index MSB), 75h (index
LSB) and 76h (data). These older systems have only 2K of NVRAM (index
0-7FFh).
And similarly to the CMOS memory, you can do something like this to test
the NVRAM:
-o 75 05 ; set high index byte to 05h
-o 74 55 ; set low index byte to 55h, we have NVRAM index 555h selected now
-o 76 55 ; write 55h (even bits set) to index 555h
-i 76 ; read back index 555h, you should get 55h back
-o 76 AA ; write AAh to the same index
-i 76 ; and expect to get AAh back
And to exit debug:
-q
You can retry these tests on multiple different locations to test the
not only the memory locations but also address lines. Or even better put
it into a loop...
This will of course trash the contents of the touched memory locations
(unless you check the original value first and then put it back when you
are done), and effectively of the entire chip, because the checksum will
be wrong. But that's not a concern here I don't think :). If you are
gonna test the RTC and control regs as well, check the datasheet for
their description first. There are some limitations to what you can do
and when. Some control register changes may crash the system or have
other strange effects.
Also, please note that there are some timing and interrupt masking
requirements when accessing the RTC/CMOS and NVRAM devices. If you do
these tests instruction by instruction from DEBUG running under pure DOS
with no device and extended memory drivers or device drivers loaded, you
should be fine and can ignore the stuff below. But if you are gonna
execute a sequence of instructions at once (assembly or compiled
higher-level program) or with some drivers/TSRs active you may run into
problems very quickly... Generally, these older systems should be happy
with a dummy jump instruction between the I/O instructions. Newer
systems require an I/O op to dummy reg. 4Fh. So instead of:
out 70h, al
in al, 71h
you would do:
out 70h, al
out 4Fh, al ; dummy write to force I/O cycle and delay things
; the written value doesn't matter,
; reuse whatever you have stored already)
in al, 71h
I'll not go into the interrupt stuff here.
I hope I got this right, I'm writing this from the top of my head. Let
me know if you run into any problems.
reasonably looking activity. Control signals like Chip Select and Output
Enable will only toggle when you do an actual CMOS/NVRAM operation.
And yes it's relatively easy to test both chips from software.
The RTC registers and CMOS memory can be accessed through I/O ports 70h
(index) and 71h (data). The MC146818A RTC/CMOS chip in Model 70 has 10
RTC registers (index 0-9h), 4 control registers (A-Dh) and 50
general-purpose CMOS locations (0E-3Fh). More about the chip and its
registers here:
https://ardent-tool.com/datasheets/Motorola_MC146818A.pdf
You can do a simple r/w test on a selected location of the RTC CMOS
memory using the DOS DEBUG utility. Something like this should work:
("-" is the DEBUG prompt, ";" and everything behind are comments)
-o 70 11 ; select CMOS index 11h
-o 71 55 ; write 55h (all even bits 1) to index 11h
-i 71 ; read back value at index 11h, you should get your 55h back
-o 71 AA ; write AAh (all odd bits 1) to the same index
-i 71 ; you should get AAh back
The extended NVRAM is accessed via ports 74h (index MSB), 75h (index
LSB) and 76h (data). These older systems have only 2K of NVRAM (index
0-7FFh).
And similarly to the CMOS memory, you can do something like this to test
the NVRAM:
-o 75 05 ; set high index byte to 05h
-o 74 55 ; set low index byte to 55h, we have NVRAM index 555h selected now
-o 76 55 ; write 55h (even bits set) to index 555h
-i 76 ; read back index 555h, you should get 55h back
-o 76 AA ; write AAh to the same index
-i 76 ; and expect to get AAh back
And to exit debug:
-q
You can retry these tests on multiple different locations to test the
not only the memory locations but also address lines. Or even better put
it into a loop...
This will of course trash the contents of the touched memory locations
(unless you check the original value first and then put it back when you
are done), and effectively of the entire chip, because the checksum will
be wrong. But that's not a concern here I don't think :). If you are
gonna test the RTC and control regs as well, check the datasheet for
their description first. There are some limitations to what you can do
and when. Some control register changes may crash the system or have
other strange effects.
Also, please note that there are some timing and interrupt masking
requirements when accessing the RTC/CMOS and NVRAM devices. If you do
these tests instruction by instruction from DEBUG running under pure DOS
with no device and extended memory drivers or device drivers loaded, you
should be fine and can ignore the stuff below. But if you are gonna
execute a sequence of instructions at once (assembly or compiled
higher-level program) or with some drivers/TSRs active you may run into
problems very quickly... Generally, these older systems should be happy
with a dummy jump instruction between the I/O instructions. Newer
systems require an I/O op to dummy reg. 4Fh. So instead of:
out 70h, al
in al, 71h
you would do:
out 70h, al
out 4Fh, al ; dummy write to force I/O cycle and delay things
; the written value doesn't matter,
; reuse whatever you have stored already)
in al, 71h
I'll not go into the interrupt stuff here.
I hope I got this right, I'm writing this from the top of my head. Let
me know if you run into any problems.
Tomas Slavotinek
Dec 21, 2021, 7:56:56 PM12/21/21
to
Correction: ports 74h (index LSB), 75h (index MSB)
The DEBUG example is ok.
The DEBUG example is ok.
Nick Silvestro
Dec 22, 2021, 1:02:22 AM12/22/21
to
Thanks again, Tomas. This is down the right track now. I was able to probe the ports via DEBUG programs and get data back for the RTC but not the NVRAM.
I then scoped both ICs and as expected the RTC looks fine with good activity on all address lines, and everything else either high or low as expected except PS is held high as long as either power is on or the battery is connected, regardless of jumper status. Either way, it's high so nothing is being lost there.
The NVRAM is not so good though - the ~CS line is permanently held high, and looks to be tied to Vcc as it's showing either battery power or 5v from the PSU, same as the Vcc pin. Additionally, both ~OE and ~WE are sitting solidly at around 3.9v, which seems odd.
Ideas? If I had a schematic here I'd be able to see where those pins lead to but... yeah. Maybe one of those glue logic ICs to blame?
I then scoped both ICs and as expected the RTC looks fine with good activity on all address lines, and everything else either high or low as expected except PS is held high as long as either power is on or the battery is connected, regardless of jumper status. Either way, it's high so nothing is being lost there.
The NVRAM is not so good though - the ~CS line is permanently held high, and looks to be tied to Vcc as it's showing either battery power or 5v from the PSU, same as the Vcc pin. Additionally, both ~OE and ~WE are sitting solidly at around 3.9v, which seems odd.
Ideas? If I had a schematic here I'd be able to see where those pins lead to but... yeah. Maybe one of those glue logic ICs to blame?
Nick Silvestro
Dec 22, 2021, 3:16:00 AM12/22/21
to
I did some poking around and - after a lot of continuity testing - was able to find the ~CS pin on the NVRAM IC is connected to OUT6 on U158, which is a MC14069U hex inverter (which also explains why it's looking like Vcc).
Probing IN6 shows low when powered off, and pulled high when powered on during POST, however OUT6 does not change. I think this hex inverter could be faulty, perhaps?
Doing a quick bodge and just holding OUT6/~CS down to ground constantly with a jumper wire and the 162 error is gone! It just gives 163 which is normal after auto config, and then going in and setting the time and date works fine. Checkout test on the system board is now completing successfully also. Obviously not a long term fix, but this is clearly the root cause!
I've also noticed that it's counting more RAM during POST than before... with just a single 2mb stick in it was showing 1664kb but now it's showing 1920kb, so that's something.
Probing IN6 shows low when powered off, and pulled high when powered on during POST, however OUT6 does not change. I think this hex inverter could be faulty, perhaps?
Doing a quick bodge and just holding OUT6/~CS down to ground constantly with a jumper wire and the 162 error is gone! It just gives 163 which is normal after auto config, and then going in and setting the time and date works fine. Checkout test on the system board is now completing successfully also. Obviously not a long term fix, but this is clearly the root cause!
I've also noticed that it's counting more RAM during POST than before... with just a single 2mb stick in it was showing 1664kb but now it's showing 1920kb, so that's something.
Tomas Slavotinek
Dec 22, 2021, 4:53:44 AM12/22/21
to
Great work, Nick!
From your description, it seems that the inverter is indeed dead. You
are right about the SRAM -CS line too, it's always low during normal
operation and only goes high when in standby. We don't have the Model 70
T1 schematics, but we have the Model 80 T2 ones, and that machine uses
the same non-volatile setup, as far as I can tell:
https://ardent-tool.com/docs/pdf/schematics/m80_sch.pdf#page=11
(physical page 11)
Your workaround should be good too. It may cause the battery to drain a
bit faster or maybe an occasional glitch on power-on, but that should be
about it. If there are any unused inverters in the IC, you could jump
the input and output to one of them (and maybe lift the original output
pin if necessary). But it's probably easier and definitely prettier to
replace the entire IC.
Glad we could save her...
From your description, it seems that the inverter is indeed dead. You
are right about the SRAM -CS line too, it's always low during normal
operation and only goes high when in standby. We don't have the Model 70
T1 schematics, but we have the Model 80 T2 ones, and that machine uses
the same non-volatile setup, as far as I can tell:
https://ardent-tool.com/docs/pdf/schematics/m80_sch.pdf#page=11
(physical page 11)
Your workaround should be good too. It may cause the battery to drain a
bit faster or maybe an occasional glitch on power-on, but that should be
about it. If there are any unused inverters in the IC, you could jump
the input and output to one of them (and maybe lift the original output
pin if necessary). But it's probably easier and definitely prettier to
replace the entire IC.
Glad we could save her...
Louis Ohland
Dec 22, 2021, 9:30:21 AM12/22/21
to
MAJ Tom, this error combination for 50/60/65/70/80 might be worth
refining and placing on the Tool.
Glorious Tractor Factory 57 might even give you a blue banner....
On 12/20/2021 23:23, Nick Silvestro wrote:
refining and placing on the Tool.
Glorious Tractor Factory 57 might even give you a blue banner....
On 12/20/2021 23:23, Nick Silvestro wrote:
Tomas Slavotinek
Dec 22, 2021, 3:10:32 PM12/22/21
to
Hmm, yep.
I also want to check the POST and diag code to see whether it does any
CMOS/NVRAM tests at all (aside from checking the "valid" flag and the
checksum.
I also want to check the POST and diag code to see whether it does any
CMOS/NVRAM tests at all (aside from checking the "valid" flag and the
checksum.
Nick Silvestro
Dec 22, 2021, 5:42:09 PM12/22/21
to
It will be a while before I'll get a replacement hex inverter and tidy it all up, so happy to "break" my system again and get any debugging data you may want
Tomas Slavotinek
Dec 23, 2021, 6:37:55 PM12/23/21
to
Thanks, I'll keep that in mind. I should be able to figure it out by
reversing the binaries. I'm well familiar with IBM's POST code, but I've
never done any serious work on the DGS modules. But it seems to be
relatively straightforward. Curiously, I didn't see any error strings
when I peeked inside. Maybe they are stored as integer values and only
built into a string later on (by the main diag. executable or one of its
friends?)
reversing the binaries. I'm well familiar with IBM's POST code, but I've
never done any serious work on the DGS modules. But it seems to be
relatively straightforward. Curiously, I didn't see any error strings
when I peeked inside. Maybe they are stored as integer values and only
built into a string later on (by the main diag. executable or one of its
friends?)
Nick Silvestro
Jan 8, 2022, 3:55:15 AM1/8/22
to
Just as a final update to this, I found the final root cause and the machine is fully working now. Unfortunately, it was my own doing!
I replaced that hex inverter IC to the same issue, so I traced further and found that the input to the inverter was 2.25v which just seemed odd. The Model 80 schematic was useless beyond here as it differed too much, so out came the continuity tester and I was able to trace the IN pin for that signal on the inverter to the P_GOOD pin on the PSU connector. Lo and behold, the P_GOOD pin was actually outputting 2.25v. I'm honestly surprised there didn't seem to be any other systemic issues!
The original PSU had failed, so I was using a board of my own design that converts an ATX PSU into the IBM pinout, but for some reason I had decided to use the PWR_OK/P_GOOD pin on the ATX PSU to drive the green power LED on the PSU - sadly that 5v line can't drive enough current for an 20mA LED draw, and the voltage then dropped to the 2.25v and caused all this issue. I've changed the PSU to now drive the power LED with regular 5v rail, leaving the P_GOOD signal healthy and 5v, and everything is working as intended.
Thanks again for all the help on this one!
I replaced that hex inverter IC to the same issue, so I traced further and found that the input to the inverter was 2.25v which just seemed odd. The Model 80 schematic was useless beyond here as it differed too much, so out came the continuity tester and I was able to trace the IN pin for that signal on the inverter to the P_GOOD pin on the PSU connector. Lo and behold, the P_GOOD pin was actually outputting 2.25v. I'm honestly surprised there didn't seem to be any other systemic issues!
The original PSU had failed, so I was using a board of my own design that converts an ATX PSU into the IBM pinout, but for some reason I had decided to use the PWR_OK/P_GOOD pin on the ATX PSU to drive the green power LED on the PSU - sadly that 5v line can't drive enough current for an 20mA LED draw, and the voltage then dropped to the 2.25v and caused all this issue. I've changed the PSU to now drive the power LED with regular 5v rail, leaving the P_GOOD signal healthy and 5v, and everything is working as intended.
Thanks again for all the help on this one!
Louis Ohland
Jan 8, 2022, 10:01:49 AM1/8/22
to
And you haven't foundt the time to take any pictures or write up your
struggles?
What is up with this new generation? Usually, I keep an eye on the quiet
ones with problems that they can't talk about.
You're OK, right?
struggles?
What is up with this new generation? Usually, I keep an eye on the quiet
ones with problems that they can't talk about.
You're OK, right?
Tomas Slavotinek
Jan 8, 2022, 12:16:53 PM1/8/22
to
Oh, that's an unexpected turn of events! Were you using this PSU
replacement at the time of your original post, or have you switched to
it later on? And was the Power Good line the only problem in the end?
Anyway, thanks for letting us know what the actual problem was. And yeah
I have a similar experience with the Power Good signal, it's... finicky
af. If you load it down or wanna repurpose it to implement HW reset, you
will run into all kinds of strange behavior (be it a standard ATX or a
proprietary PS/2 PSU).
replacement at the time of your original post, or have you switched to
it later on? And was the Power Good line the only problem in the end?
Anyway, thanks for letting us know what the actual problem was. And yeah
I have a similar experience with the Power Good signal, it's... finicky
af. If you load it down or wanna repurpose it to implement HW reset, you
will run into all kinds of strange behavior (be it a standard ATX or a
proprietary PS/2 PSU).
Tomas Slavotinek
Jan 8, 2022, 12:21:25 PM1/8/22
to
Now that we have a conclusion I'm gonna compress all this info and put
it somewhere on the Tool.
it somewhere on the Tool.
Nick Silvestro
Jan 8, 2022, 6:56:51 PM1/8/22
to
I was using this PSU all along, my original PS/2 one had failed and I wasn't able to repair it unfortunately.
I've now checked every single pin out on there, both in circuit and idle and they're all correct spec.
I've been looking at the whole circuit in general a bit closer now, and from all I can see (though I'm probably missing something) it kinda only seems to be used by the RTC part of the planar. I haven't been able to find the PGOOD going off anywhere else on the board. Oddly, it's directly run into the /STBY pin on the RTC IC, so it's a wonder that ever worked at all either. In any case, glad it was a relatively simple fault that was just an oversight and nothing horrendous!
I've now checked every single pin out on there, both in circuit and idle and they're all correct spec.
I've been looking at the whole circuit in general a bit closer now, and from all I can see (though I'm probably missing something) it kinda only seems to be used by the RTC part of the planar. I haven't been able to find the PGOOD going off anywhere else on the board. Oddly, it's directly run into the /STBY pin on the RTC IC, so it's a wonder that ever worked at all either. In any case, glad it was a relatively simple fault that was just an oversight and nothing horrendous!
0 new messages