I am Searching for a method to spend my PS/2 (Model above) a Reset-Switch. I
Think the best way is to solder two wires on an small card an plug it in an
empty slot, because i don't want to modify the mainboard itself.
In the Past i had to Toggle the power-switch too often and i believe that this
is the reason the PSU died. Now i got a Working One and looking for an was to
protect it.
Can anyone help?
Bye/
/Kay
--
from Germany.
Louis Ohland schrieb:
> Sounds like your method is to ground out a line on the MCA bus. Isn't
> there a reset pin on the CPU?
Of course there must be a reset-pin. But i don't know if i can short it simply
with a button-switch or if this could damage the machine.
For a few days i speak with (Don) Peter and he described that there is a special
Reset-Logic on the PS/2 but no details are known. Sorry, i should say it at first.
As i read in a Hardware-Book from Peter H. Messmer (Addison-Wesley,
'PC-Hardwarebuch') the Adapter-identification can Reset a single card. I believe
that pulling a reset-line down may intefere with it.
I don't want to go the "easy" way, i will go the "correct" way - if there is a way!
Bye/
/Kay
--
from germany
True, the system can bring a card down, but the system must be in the
setup state, and I'll guess that you are trying to do this with the
system running.
Good luck,
Christian
K. Martinen schrieb:
Peter?
> Well hell, can you coble together a momentary switch off the PSU 5v
> sense voltage? IIRC, that's what the toggle switch does as well.
>
> Peter?
Hmmmpf ?
Sorry. I was asleep.
The Mod. 80 does not use a sense voltage. The power switch is a real
"Power Switch" for mains-AC.
Tie down sense voltage on "later" PSUs is ... well ... useless, since it
*is* tied to GND when the system is running. You need to pull it off GND
(with a breaker switch), but that turns down the main PSU within the PSU
... and that is what a reset switch usually bypasses. Its purpose is to
reset the machine *without* turning the PSU off and back on again.
However: a healthy PSU will surely not complain on it - given you leave
it some time to really come down before you power it back on.
But a Reset switch will also prevent the HDs from coming down ...
> Christian Holzapfel wrote:
>> I have an old book about PS/2's hardware too, it (generally) suggests
>> to connect a switch from GND to the "Power Good" line of the PSU,
>> which is also wired down to the PSU connector on the planar. I tried
>> and used this with my model 8530-486 (slc2 upgrade :-)) a few years
>> ago. I tied one end of the wire 'round a screw (=GND), the other end
>> was stuffed into the PSU connector before connecting it to the planar;
>> so everything could be removed easily, all done without soldering. If
>> it works with a 80's power supply, you might find out...
Can only speak for a Mod. 60, where I did exactly that: wiring Power
Good to GND.
In brief: it did not work as supposed.
The board largely resetted, the HDs kept on running, but after the
reboot mouse and keyboard failed to respond.
Haven't tried that on a Mod. 80 (or any other) so far.
On the power plug it is the pin #12 - marked with "X" when looked into
the connector from the pin-side. Pin #11 is one of the GND wires.
9
3 D O O X O 15
2 O O O O D 14
1 D O O O O 13
7
When using the power good signal one should take in account that pulling
down the signal *may* also cause a power supply restart - where it takes
down the DC outputs and you are basically back on the off-on-cycle and
even worse, since the recover time is fairly short. Don't know if the
HDs would like that.
I would opt to break the power good line with a toggle switch.
NC is tied to the line *from* the PSU, NO is connected to GND, COM goes
to the board.
NC NO
PSU >----o\ o----+
\ |
COM o -+- 0V / GND
|
Board <----+
What happens ?
The PG signal gets taken off the board, the signal itself is not forced
to anything, so the PSU-internal logic doesn't care. The board pin is
tied to GND and signals a missing PG to the reset logic, which then
-consequently- resets, while all supply voltages are still present.
Discussable idea ? Any volunteers ?
--
Peter from Germany
http://www.mcamafia.de
Hi Peter,
If a model 60 is 286 based and behaving like an AT, you could have saved
yourself the physical labour.
A 80826 CPU can't go from protected mode to real mode (no-one at Intel
thought of Microsoft). But since it was needed, ATs got a few add-ons to
fix:
1) one location in the RTC RAM holds a PC status value:
PC was shut down -> cold boot
PC reboot -> warm boot, used to leave protected mode (no HW init)
PC running -> you did not shut down the PC
2) some bit allowed resetting the CPU
The combination of 1 & 2 allowed to switch back to real mode on the AT. Now,
if you write a tiny prog that writes the proper values to the RTC and
hardware register, you can force a cold boot to happen from the PC's point
of view.
This does not garantee that some components will remain locked up, but thats
bad design :-)
True, the power sense signal should generate a reset signal to all
components, but RAM contents of the RTC won't be clean.
Now, I don't know the locations and values from the head, so if you need
them, you'll need a little patience.
I see that tripple faults were used as a faster alternative (yuck).
Regards,
Alvin.
A quick search turned op the following on
http://www.rcollins.org/articles/pmbasics/tspec_a1_doc.html
ENTERING PROTECTED MODE
Our goal is to enter protected mode, and leave protected mode and return to
DOS. The '286 has no internal mechanism to exit protected mode: once you are
in protected mode, you are there to stay. IBM recognized this, and
implemented a hardware solution that would take the '286 out of protected
mode by resetting the CPU. Since the power-on state of the '286 is real
mode, simply resetting the CPU will return to real mode. But this introduces
a slight problem, as the CPU won't continue executing where it left off. At
reset, the CPU starts executing at the top of memory, in the BIOS. Without a
protocol to tell the BIOS that we reset the CPU for the purpose of exiting
protected mode, the BIOS would have no way to return control back to the
user program. IBM implemented a very simple protocol by writing a code to
CMOS RAM (CMOS) where the BIOS can check this code and decide what to do.
Immediately after the BIOS starts executing from the reset vector, it checks
this code in CMOS to determine if the CPU was reset for the purpose of
exiting protected mode. Depending on the code in CMOS, the BIOS can return
control back to the user program and continue executing.
Resetting the CPU isn't without its ramifications; all the CPU registers are
destroyed, and the interrupt mask in the Programmable Interrupt Controller
(PIC) is sometimes re-programmed by the BIOS (depending on the shutdown
type). Therefore, it is the program's responsibility to save the PIC mask,
stack pointer, and return address before entering protected mode. The PIC
mask and stack pointer must be stored in the user's data segment, but the
return address must be stored at a fixed location defined in the BIOS data
segment -- at 40:67h.
Next, we set the code in CMOS that tells BIOS we will exit protected mode
and return to the user's program. This is simply done by writing a value to
the two CMOS I/O ports. After the CPU gets reset, and BIOS checks the CMOS
code, BIOS will clear the CMOS code, so subsequent resets won't cause
unexpected results. After setting the code in CMOS, the program must build
the GDT. (See the appropriate Intel programmer's reference manual for a
description of the GDT.) The limit, and access rights may be filled in by
the compiler, as these values are static. But the base addresses of each
segment aren't known until run-time; therefore the program must fill them in
the GDT. Our program will build a GDT containing the code, data, and stack
segments addressed by our program. One last GDT entry will point to 1M for
illustrative purposes.
Accessing memory at 1M isn't as simple as creating a GDT entry and using it.
The 8086 has the potential to address 64k (minus 16 bytes) beyond the
maximum addressability of 1M -- all it lacks is a 21st address line. The
8086 only has 20 address lines (A00..A19), and any attempt to address beyond
1M will wrap around to 0 because of the absence of A20. The '286 has 24 bits
of addressability (A00..A23) and doesn't behave like the 8086 in this
respect. Any attempt to address beyond 1M (FFFF:0010 - FFFF:FFFF) will
happily assert A20, and not wrap back to 0. Any program that relies on the
memory wrapping "feature" of the 8086, will fail to run properly. As a
solution to this compatibility problem, IBM decided to AND the A20 output of
the CPU with a programmable output pin on some chip in the computer. The
output of the AND gate is connected to the address bus, thus propogating or
not, A20. Based on the input from the CPU A20, ANDed with an externally
programmable source, address bus A20 gets asserted. The keyboard controller
was chosen as this programmable source because it contained some available
pins that can be held high, low, or toggled under program control. When the
output of this pin is programmed to be high, the output of the AND gate is
high when the CPU asserts A20. When the output is low,A20 is always low on
the address bus -- regardless of the state of the CPU A20. Thus by
inhibiting A20 from being asserted on the address bus, '286- class machines
can emulate the memory wrapping attributes of their 8086 predecessors.
Notice that only A20 is gated to the address bus. Therefore, without
enabling the input to the A20 gate, the CPU can address every even megabyte
of memory as follows: 0-1M, 2-3M, 4-5M, etc. In fact, duplicates of these
memory blocks appear at 1-2M, 3-4M, 5-6M, etc. as a result of holding A20
low on the address bus. To enable the full 24-bits of addressability, a
command must be sent to the keyboard controller (KBC). The KBC will enable
the output on its pin to high, as input to the A20 gate. Once this is done,
memory will no longer wrap, and we can address the full 16M of memory on the
'286, or all 4G on 80386-class machines. All that remains in order to enter
protected mode is changing the CPU state to protected mode and jumping to
clear the prefetch queue (not necessary on the Pentium).
The following table summarizes the steps required to enter (with the
intention of leaving) protected mode on the '286:
1.. Save the 8259 PIC mask in the program data segment
2.. Save SS:SP in the program data segment
3.. Save the return address from protected mode at 40:67
4.. Set the shutdown code in CMOS to tell BIOS that upon reset we will be
returning to our program
5.. Build the GDT
6.. Enable A20 on the address bus
7.. Enable protected mode in the CPU machine status word (MSW)
8.. JUMP to clear the prefetch queue
Steps 1-6 can be done in any order.
The minimum number of steps required to enter protected mode on the '386 and
'486 are far fewer, as the '386 can exit protected mode without resetting
the CPU. For compatibility purposes, all '386 BIOS's will recognize the CPU
shutdown protocol defined on '286-class machines, but following this
protocol isn't necessary. To exit protected mode on a '386, the program
simply clears a bit in a CPU control register. There is no need to save the
PIC mask, SS:SP, a return address, or set a CMOS code. The requisite steps
for entering protected mode on a '386 simply become:
1.. Build the GDT
2.. Enable A20 on the address bus
3.. Enable protected mode in the CPU control register (CR0, or MSW)
4.. JUMP to clear the prefetch queue
Of these requisite steps, building the GDT is the only step that may differ.
In the '386 the base address is expanded to 32-bits, the limit is expanded
to 20-bits, and two more control attribute bits are present. Listing 1 lists
all the auxiliary subroutines to enter protected mode.
EXITING PROTECTED MODE
Like entering protected mode, exiting it differs from the '286 to
80386-class machines. The '386 simply clears a bit in the CPU control
register CR0, while the '286 must reset the CPU. Resetting the CPU isn't
without its costs, as many hundred -- if not thousands -- of clock cycles
pass in the time it takes to reset the CPU and return control back to the
use program. The original method employed by IBM used the keyboard
controller by connecting another output pin to the CPU RESET line. By
issuing the proper command, the KBC would toggle the RESET line on the CPU.
This method works, but it is very slow. Many new generation '286 chip sets
have a "FAST RESET" feature. These chip sets toggle the RESET line by simply
writing to an I/O port. When available, FAST RESET is the preferred method.
But there is a third, obscure, but efficient method for resetting the CPU
without using the KBC or FAST RESET. This method is elegant, faster than
using the KBC, and works on the '386 WITHOUT resetting the CPU! It is truly
the most elegant, comprehensive way to exit protected mode, since it works
on both the '286, and '386 -- in the most efficient way possible for each
CPU. Listing 2 provides the code necessary to use the KBC and this elegant
technique.
Using the KBC to reset the CPU is a straightforward technique, but in order
to understand the elegant technique, some explanation is required. Recall
that in our discussion of interrupts, the CPU checks the interrupt number
(x8) against the limit field in the interrupt descriptor cache register
(IDTR). If this test passes, then the next phase of interrupt processing
begins. But if the test fails, then the CPU generates a DOUBLE FAULT
(INT08). For example, let us suppose the limit field in the IDTR=80h: our
IDT will service 16 interrupts, 00-15. If interrupt 16 or above was
generated, the CPU would DOUBLE FAULT because a fault was generated at the
inception of the interrupt calling sequence. Now, suppose the limit field in
the IDTR=0, thus inhibiting all interrupts from being serviced. Any
interrupt generation would cause the DOUBLE FAULT. But the DOUBLE FAULT
itself would cause a fault, due to the limit being less than 40h. This
ultimately would cause a TRIPLE FAULT, and the CPU would enter a shutdown
cycle. The shutdown cycle doesn't reset the CPU, as a shutdown cycle is
considered a BUS cycle. External hardware is attached to the CPU to
recognize the shutdown cycle. When a shutdown cycle is observed, the
external hardware toggles the RESET input of the CPU. Therefore, all we need
to do to cause the RESET is set the IDTR.LIMIT=0, then generate an
interrupt. For elegance, we don't just INT the CPU, we generate an invalid
opcode. Our opcode is a carefully chosen opcode that doesn't exist on the
'286, but does exist on the '386. The elegance in the algorithm is in the
opcode chosen for this purpose: MOV CR0,EAX. This will generate the desired
invalid opcode exception on the '286, but is the first instruction in a
sequence to exit protected mode on the '386. Thus the '286 gets RESET, and
the '386 falls through and exits protected mode gracefully.
Exiting protected mode on the '286, and '386 closely resemble reversing the
steps for entering protected mode. On the '286, you must:
1.. Reset the CPU to get into real mode
2.. Load the segment registers with real mode compatible values
3.. Restore SS:SP
4.. Inhibit A20 from the address bus (gate A20 off)
5.. Restore the PIC masks
And on the '386, the steps are simply:
1.. Load the segment registers with real-mode compatible values
2.. Reset the Protection Enable (PE) bit in CR0
3.. Load the segment registers with real mode values
4.. Inhibit A20 from the address bus (gate A20 off)
(Listing 3 includes the subroutines needed to restore the machine state
after exiting protected mode).
Notice that exiting protected mode on the '386 requires loading the segment
registers twice. The segment registers are loaded the first time to assure
that real-mode compatible values are stored in the hidden descriptor cache
registers -- as the descriptor cache registers "honor" the access
attributes, and segment size limit, from protected mode, even when loaded in
real mode. The segment registers are loaded the second time to define them
with real-mode segment values.
Now that we have all the tools and theory necessary to enter and exit
protected mode, we can apply this knowledge to write a program that enters
protected mode, moves a block of data from extended memory, and exits
protected mode -- returning to DOS. Listing 4 shows a program that consists
of these basic steps and can be used to move a 1k block of data from 1M to
our program's data segment.
>> Can only speak for a Mod. 60, where I did exactly that: wiring Power
>> Good to GND.
>> In brief: it did not work as supposed.
>> The board largely resetted, the HDs kept on running, but after the
>> reboot mouse and keyboard failed to respond.
>>
>
> Hi Peter,
>
> If a model 60 is 286 based and behaving like an AT, you could have saved
> yourself the physical labour.
>
> A 80826 CPU can't go from protected mode to real mode (no-one at Intel
> thought of Microsoft). But since it was needed, ATs got a few add-ons to
> fix:
Ok - I know that, but that isn't the problem.
The topic is: how to carry out a machine *hardware* reset without using
the "Master Reset" (= power cycle), to avoid a) PSU cycle and b) HDs
spinning down and up again.
If you still have OS control a reset isn't a major problem.
On most machines a JMP F000:FFF0 works fine, which picks the cold reset
vector and that was it. Easy to program as e.g. RESET.COM with DEBUG.
But once the machine hangs in an OS or during installation for instance
the PS/2s don't have a reset button to get it down a softer way than
with a power cycle.
On old AT-style computers you had the 82-something clock generator,
which had a reset logic, to which - on most clone boards - they wired a
reset button. Not on PS/2 - apart from the fact that they used a
different clock generator, resp. some of them to separate CPU and bus /
DMA clock. So far I haven't found a way where to start. The MCA boards
don't even have an AT-style NMI, which was also present on the ISA bus
AFAIR. That was an easy game. Pull the NMI and the system resets.
Things were easier on ATs and XTs and their clones. Sometimes I think of
a switch using the CPU -RESET pin, but I doubt that it will bring the
machine down that way a true (cold) reset would do. Most likely it got
hooked somewhere in nowhere and you have to flip the switch anyway.
I would suggest using a TSR to use BIOS calls to enable and monitor
the Watchdog Timer and then issue a soft reset via BIOS call. That
alone might automatically resolve system lockups, if that why you want
to power-off and on again. Beyond that, perhaps tapping into the
interrupt output from Timer 3 to System Control port A to signal a
false watchdog timeout that can be monitored by the TSR (interrupt but
no valid WDT status) would work?
Cheers,
Tim (a.k.a. WBST)
> I would suggest using a TSR to use BIOS calls to enable and monitor
> the Watchdog Timer and then issue a soft reset via BIOS call. That
> alone might automatically resolve system lockups, if that why you want
> to power-off and on again. Beyond that, perhaps tapping into the
> interrupt output from Timer 3 to System Control port A to signal a
> false watchdog timeout that can be monitored by the TSR (interrupt but
> no valid WDT status) would work?
That again does not solve a problem when you got thrown out of a working
OS or have HW-related problems with the machine. On PS/2 you *always*
have to use the "Master Reset" to get it out of there - cheapo clone-PCs
have a reset button.
(Had. The last one I saw was on early Pentiums)
As far as my research goes there is no way to achieve a HW-reset without
soldering. Pulling the Power Good on the power supply often leaves the
machine in a raher undefined status. As with my Mod. 60 I had as a
workshop machine back then: it resets, but mouse and keyboard were
non-operational afterwards.
http://www.ibmmuseum.com/OhlandL/config/watchdog_timer.html
Timer 3 sends an NMI to the CPU. It might require soldering on the
output of Timer 3, but if a Watchdog won't do, an NMI should.
Comments?