https://ardent-tool.com/misc/Battery_Speaker_Assembly.htmlthe battery powered configuration data.
On 12/20/2021 23:23, Nick Silvestro wrote:
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
settings, as a hard reboot in DOS keeps the time and date set.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
corrosion or trace damage that I can find with a visual inspection.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
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
Trying to get a PS/2 Model 70 up and running but constantly getting 162/163 errors in a boot loop.battery powered configuration data.
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
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 RTCsettings, 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.corrosion or trace damage that I can find with a visual inspection.
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
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
The battery assembly is intact and works fine. Has nice continuity between the battery terminals and the pin header on the board.the battery powered configuration data.
On Tuesday, December 21, 2021 at 5:23:38 PM UTC+11, Louis Ohland wrote:
https://ardent-tool.com/misc/Battery_Speaker_Assembly.html
On 12/20/2021 23:23, Nick Silvestro wrote:
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
settings, as a hard reboot in DOS keeps the time and date set.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
corrosion or trace damage that I can find with a visual inspection.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
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
Did you clear the CMOS?
On 12/21/2021 00:57, Nick Silvestro wrote:
The battery assembly is intact and works fine. Has nice continuity
between the battery terminals and the pin header on the board.
On Tuesday, December 21, 2021 at 5:23:38 PM UTC+11, Louis Ohland wrote:
https://ardent-tool.com/misc/Battery_Speaker_Assembly.html
On 12/20/2021 23:23, Nick Silvestro wrote:
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
Trying to get a PS/2 Model 70 up and running but constantly getting 162/163 errors in a boot loop.battery powered configuration data.
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
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 RTCsettings, 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.corrosion or trace damage that I can find with a visual inspection.
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
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
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/)
Tomas, thanks for the in-depth response!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 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
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 POSTerrors 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-8seconds 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
On Wednesday, December 22, 2021 at 3:44:00 AM UTC+11, Tomas Slavotinek wrote:
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/)
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.
On 22.12.2021 0:10, Nick Silvestro wrote:
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
On Wednesday, December 22, 2021 at 3:44:00 AM UTC+11, Tomas Slavotinek
wrote:
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/)
Correction: ports 74h (index LSB), 75h (index MSB)
The DEBUG example is ok.
On 22.12.2021 1:33, Tomas Slavotinek wrote:
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.
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).system board is now completing successfully also. Obviously not a long term fix, but this is clearly the root cause!
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
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.
Trying to get a PS/2 Model 70 up and running but constantly getting 162/163 errors in a boot loop.battery powered configuration data.
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
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 RTCsettings, 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.corrosion or trace damage that I can find with a visual inspection.
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
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
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:
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
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.
On 22.12.2021 15:28, Louis Ohland wrote:
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....
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
On Thursday, December 23, 2021 at 7:10:32 AM UTC+11, Tomas Slavotinek wrote:
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.
On 22.12.2021 15:28, Louis Ohland wrote:
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....
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...
I was using a board of my own design that converts an ATX PSU into the IBM pinout
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?
On 1/8/2022 02:55, Nick Silvestro wrote:
I was using a board of my own design that converts an ATX PSU into the
IBM pinout
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!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!
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
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 5vline 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
Thanks again for all the help on this one!
On Wednesday, December 22, 2021 at 8:53:44 PM UTC+11, Tomas Slavotinek wrote:
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...
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).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 407 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 13:35:08 |
| Calls: | 8,554 |
| Calls today: | 6 |
| Files: | 13,219 |
| Messages: | 5,925,563 |