Re: 80286 Protected Mode Test

[Guy Sotomayor via cctalk]

On 3/15/21 7:23 AM, Noel Chiappa via cctalk wrote:

 > From: Guy Sotomayor

 > the LOADALL instructions including all of it's warts (and its inability
 > to switch back from protected mode)

Good to have that confirmed (for the 286; apparently it works in the 386).
The 386 loadall instruction was different (not really a surprise since 
the internal microarchitecture was different).  The 386 didn't need to 
do this "hack" because it had vm86 mode for tasks so that accomplished 
what everyone was really using LOADALL on the 286 for.


 > the other way to get back to real mode from protected mode is via a
 > triple-fault.

Any insight into why IBM didn't use that, but went with the (allegedly slow)
keyboard hack?
At this point I don't recall.  But I suspect it was allegedly simpler 
conceptually.


--
TTFN - Guy

Re: 80286 Protected Mode Test

[Noel Chiappa via cctalk]

> From: Guy Sotomayor

> the LOADALL instructions including all of it's warts (and its inability
> to switch back from protected mode)

Good to have that confirmed (for the 286; apparently it works in the 386).

> the other way to get back to real mode from protected mode is via a
> triple-fault.

Any insight into why IBM didn't use that, but went with the (allegedly slow)
keyboard hack?

Noel

Re: 80286 Protected Mode Test

[Liam Proven via cctalk]

On Sun, 14 Mar 2021 at 19:37, Guy Sotomayor via cctalk
 wrote:
>
> At the time I was fairly familiar with the LOADALL instruction.  I had
> modified PC/AT Xenix to use the LOADALL instruction to allow for running
> Xenix programs and multiple DOS programs simultaneously.

Incidentally, I believe that OS/2 1 was not the only 286 OS affected by this.

The development versions of DR's Concurrent DOS 286 could multitask
DOS apps in protect mode on pre-release 286s, but Intel "fixed" the
feature that permitted this in the first shipping version of the
80286, to DR's dismay and horror.

https://books.google.cz/books?id=2y4EMBAJ=PA17#v=onepage=false

AIUI the feature was later restored, but customer uncertainty,
together with suddenly-questionable compatibility with all the 286s
out there, killed CDOS 286.

I suspect this is instrumental in why DR took FlexOS and X/GEM down
the RTOS route instead... in which form it survived and a distant
descendant, formerly IBM 4690 OS, is still sold by Toshiba.

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: 80286 Protected Mode Test

[Maciej W. Rozycki via cctalk]

On Sun, 14 Mar 2021, Liam Proven via cctalk wrote:

> > I should also note, that the other way to get back to real mode from
> > protected mode is via a triple-fault.  What gets me (and I railed on
> > Intel when I worked there for a time) that it still existing in the
> > architecture even though they have a machine check architecture now
> > (which while at IBM pushed Intel to implement for the '386!).
> 
> (!)

 Well, software exists that relies on the triple-fault feature for reboots 
including current versions of Linux (you can trigger a triple-fault in the 
real mode too).  These days it is implemented by the southbridge catching 
the shutdown special cycle on PCI and asserting the reset pin to the CPU 
(the details might be slightly different for PCIe or HyperTransport).

 Back in the day I experimented with that stuff myself and all the weird 
ways to switch between modes with the x86, setting the IDTR in the real 
mode for interesting effects which would impress fellow students, etc.  I 
ended up writing this:  
as a result.  I wrote a simple resident VM86 monitor for DOS too, just to 
fiddle with processor features.

 Also resetting the CPU with the shutdown code of 0xa put at the location 
0xf of the RTC/NVRAM chip was the only way to get the family, model, and 
stepping ID in the EDX register for old processors that did not have the 
CPUID instruction (i.e. all 80386 and many 80486 implementations), unless 
the system BIOS clobbered it for no good reason in the short bypass code 
involved (sadly sometimes that did happen).  I just double-checked my old 
DOS assembly code to see if I got the details right!

 NB I didn't know LOADALL would not work for switching from the protected 
to the real mode and did not find out about the instruction until after I 
already lost access to any 80286 hardware, so I never experimented with it 
myself.

  Maciej

Re: 80286 Protected Mode Test

[Chuck Guzis via cctalk]

On 3/14/21 11:36 AM, Guy Sotomayor via cctalk wrote:
> 

> I can say with a fair amount of certainty, that we at IBM knew of the
> existence of the LOADALL instructions including all of it's warts (and
> its inability to switch back from protected mode) from the earliest days.
> 

ca. 1980, we were in search of a decent 16-bit processor for upward
migration.  Code base compatibility wasn't much of a concern--we were
resigned to the prospect that everything had to be recoded, so code
migration wasn't a concern.   We played a bit with the 8086, but
couldn't see a path forward in the immediate future.

So we in engineering decided that the best CPU was the Moto 68K and we
wrapped up a test board and started cutting some code for it.

Bill Davidow was on our BOD and when he got wind of our efforts, he
nearly went through the roof.  When we defended our decision by saying
that the 8086 was limited in possibilities, with the rumored iAPX432
nowhere near reality, so the 68K was the logical next step.  Zilog had
their Z800, but after looking at the cost of the MMU and the fact that
it, too was a segmented memory CPU and slower than the 68K, we never got
any farther than talking about it.  We did have an Onyx box for software
development in the lab, however.

Bill put us on the OEM pre-release steppings for both the 186 and the
286.  We got the 186 going long before the 286 (Intel, IIRC, had taken
on the job of writing the Xenix kernel for Microsoft).  Davidow's
stubbornness cost us months of product delay in getting a multi-user
system out the door.

We certainly were not advised about the LOADALL instruction at that
time.  Nor, I suspect would it have made much of a difference.  In our
system, the 186 did the I/O heavy lifting for the 286.

My impression was that the design for the 286 never envisioned the need
to switch back and forth between real and protected mode.  We never did.

--Chuck

Re: 80286 Protected Mode Test

[Fred Cisin via cctalk]

In contrast, Apple chose to abandon compatability with all previously 
existing software


On Sun, 14 Mar 2021, Al Kossow via cctalk wrote:

When they stopped selling Apple II's when Lisa was released.


Yes, exactly.
I was referring to the switch to 68000 (Lisa and then Mac), rather than 
trying to kludge more address onto a 6502.
I assume that their 68000 wasn't fast enough to get acceptable 
performance with a 6502 emulator.


To their credit, they did continue to keep some models of 6502 Apple2's 
available even while selling some 68000 machines.



--
Grumpy Ol' Fred ci...@xenosoft.com

Re: 80286 Protected Mode Test

[Al Kossow via cctalk]

On 3/14/21 1:42 PM, Fred Cisin via cctalk wrote:


In contrast, Apple chose to abandon compatability with all previously existing 
software


When they stopped selling Apple II's when Lisa was released.

Re: 80286 Protected Mode Test

[Fred Cisin via cctalk]

On Sun, 14 Mar 2021, Guy Sotomayor via cctalk wrote:
There were many heated discussions in various task forces (this was of course 
IBM) about the next generation OS (to become OS/2) about the '286.?? First 
and foremost was how to be able to run DOS programs on the '286. Over very 
vocal opposition, management decided to use "mode switching" rather than any 
of the other techniques.?? It should be noted, that a significant portion of 
us advocated abandoning the '286 in favor of the '386 to solve this 
problem.?? The argument that management made against that approach assumed 
that OS/2 would be ready in 9 months and that the '386 would be late ('386 at 
the time was about 12-18 months away).?? It turned out that OS/2 took well 
over 18 months to develop.


The 80286 was an important step.  Getting 24 bits of address, instead of 
20 was significant.  It is too bad that they weren't able to set it aside 
until they got the next couple of steps (ala 80386) to be able to make 
better use of those address bits.


HIMEM.SYS (enabling A20 and using it to "overflow" past 1MB by 65K-16) 
became a ubiquitus kludge.


Gordon Letwin (the Microsoft author of OS/2) said that mode switching on 
80286 was "like turning off the car to change gears."

Even Bill Gates said that the 80286 was "BRAIN DEAD".

Segment:Offset had been developed as a kludge to be able to expand from 16 
bit address (64K), while maintaining almost full compatability.


Yes, a flat memory model IS the way to go.  But, they couldn't see a way 
to abandon Segment:Offset without abandoning compatability with all 
previously existing software.  Programs, such as Wordstar were ported from 
CP/M to PC in significantly less time than it took to re-edit their 
documentation!



In contrast, Apple chose to abandon compatability with all previously 
existing software, and did have a period of time with nothing but 
Mac-Write, Mac-Paint, Wac-Write, and Mac-Paint.



--
Grumpy Ol' Fred ci...@xenosoft.com

Re: 80286 Protected Mode Test

[Liam Proven via cctalk]

On Sun, 14 Mar 2021 at 19:37, Guy Sotomayor via cctalk
 wrote:

> There were many heated discussions in various task forces (this was of
> course IBM) about the next generation OS (to become OS/2) about the
> '286.  First and foremost was how to be able to run DOS programs on the
> '286. Over very vocal opposition, management decided to use "mode
> switching" rather than any of the other techniques.  It should be noted,
> that a significant portion of us advocated abandoning the '286 in favor
> of the '386 to solve this problem.  The argument that management made
> against that approach assumed that OS/2 would be ready in 9 months and
> that the '386 would be late ('386 at the time was about 12-18 months
> away).  It turned out that OS/2 took well over 18 months to develop.

I will say this, Guy, your posts never cease to amaze me and provide
valuable insight!

I was on the sidelines at the time -- at university, reading about
this stuff in the UK computer mags. From outside too it was very
obvious that OS/2 should target the 386. When I started work, I was in
tech support in an IBM value-added reseller -- that's where I learned
about IBMCACHE.SYS, which we talked of a few years back -- and I can
confirm that most PS/2 owners were not at all interested in OS/2. A
handful ran 3Com 3+Share or Netware 2 on PS/2 boxes as the server, but
most 286 PS/2s were workstations. Only the 386 Model 80 sold almost
exclusively as servers. I still have one myself.

> At the time I was fairly familiar with the LOADALL instruction.  I had
> modified PC/AT Xenix to use the LOADALL instruction to allow for running
> Xenix programs and multiple DOS programs simultaneously.  I gave
> multiple demos to various folks in management but to no avail.  They had
> decided that mode switching as *the* way that OS/2 was going to work.

:'(

> I should also note, that the other way to get back to real mode from
> protected mode is via a triple-fault.  What gets me (and I railed on
> Intel when I worked there for a time) that it still existing in the
> architecture even though they have a machine check architecture now
> (which while at IBM pushed Intel to implement for the '386!).

(!)



-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: 80286 Protected Mode Test

[Guy Sotomayor via cctalk]

On 3/14/21 11:09 AM, Peter Corlett via cctalk wrote:

On Sun, Mar 14, 2021 at 04:32:20PM +0100, Maciej W. Rozycki via cctalk wrote:

On Sun, 7 Mar 2021, Noel Chiappa via cctalk wrote:

The 286 can exit protected mode with the LOADALL instruction.

[...]

The existence of LOADALL (used for in-circuit emulation, a predecessor
technique to modern JTAG debugging and the instruction the modern x86 RSM
instruction grew from) in the 80286 wasn't public information for a very
long time, and you won't find it in public Intel 80286 CPU documentation
even today. Even if IBM engineers knew of its existence at the time the
PC/AT was being designed, surely they have decided not to rely in their
design on something not guaranteed by the CPU manufacturer to exist.


I can say with a fair amount of certainty, that we at IBM knew of the 
existence of the LOADALL instructions including all of it's warts (and 
its inability to switch back from protected mode) from the earliest days.


There were many heated discussions in various task forces (this was of 
course IBM) about the next generation OS (to become OS/2) about the 
'286.  First and foremost was how to be able to run DOS programs on the 
'286. Over very vocal opposition, management decided to use "mode 
switching" rather than any of the other techniques.  It should be noted, 
that a significant portion of us advocated abandoning the '286 in favor 
of the '386 to solve this problem.  The argument that management made 
against that approach assumed that OS/2 would be ready in 9 months and 
that the '386 would be late ('386 at the time was about 12-18 months 
away).  It turned out that OS/2 took well over 18 months to develop.


At the time I was fairly familiar with the LOADALL instruction.  I had 
modified PC/AT Xenix to use the LOADALL instruction to allow for running 
Xenix programs and multiple DOS programs simultaneously.  I gave 
multiple demos to various folks in management but to no avail.  They had 
decided that mode switching as *the* way that OS/2 was going to work.


I should also note, that the other way to get back to real mode from 
protected mode is via a triple-fault.  What gets me (and I railed on 
Intel when I worked there for a time) that it still existing in the 
architecture even though they have a machine check architecture now 
(which while at IBM pushed Intel to implement for the '386!).



The Wikipedia page on LOADALL claims "The 80286 LOADALL instruction can not
be used to switch from protected back to real mode (it can't clear the PE
bit in the MSW). However, use of the LOADALL instruction can avoid the need
to switch to protected mode altogether."

I find that paragraph very persuasive. The author knows about LOADALL and
the desire to use it to avoid going into protected mode, and also explains
that there's a specific exception in its behaviour which prevents returning
to real mode. All of the other hacky uses of LOADALL would be unnecessary if
it could be used to switch modes at will. It just doesn't seem like
something that would be written if it was wrong.

Is Wikipedia incorrect and the 286 LOADALL *can* exit protected mode, and if
so, how?


--
TTFN - Guy

Re: 80286 Protected Mode Test

[Peter Corlett via cctalk]

On Sun, Mar 14, 2021 at 04:32:20PM +0100, Maciej W. Rozycki via cctalk wrote:
> On Sun, 7 Mar 2021, Noel Chiappa via cctalk wrote:
>>> The 286 can exit protected mode with the LOADALL instruction.
[...]
> The existence of LOADALL (used for in-circuit emulation, a predecessor
> technique to modern JTAG debugging and the instruction the modern x86 RSM
> instruction grew from) in the 80286 wasn't public information for a very
> long time, and you won't find it in public Intel 80286 CPU documentation
> even today. Even if IBM engineers knew of its existence at the time the
> PC/AT was being designed, surely they have decided not to rely in their
> design on something not guaranteed by the CPU manufacturer to exist.

The Wikipedia page on LOADALL claims "The 80286 LOADALL instruction can not
be used to switch from protected back to real mode (it can't clear the PE
bit in the MSW). However, use of the LOADALL instruction can avoid the need
to switch to protected mode altogether."

I find that paragraph very persuasive. The author knows about LOADALL and
the desire to use it to avoid going into protected mode, and also explains
that there's a specific exception in its behaviour which prevents returning
to real mode. All of the other hacky uses of LOADALL would be unnecessary if
it could be used to switch modes at will. It just doesn't seem like
something that would be written if it was wrong.

Is Wikipedia incorrect and the 286 LOADALL *can* exit protected mode, and if
so, how?

RE: 80286 Protected Mode Test

[Rob Jarratt via cctalk]

I should update people on this as I have made progress today. I found two
broken tracks from the 8742 peripheral controller to the ASICs. One of the
ASICs sends a RESET to the 286. When I repaired that track suddenly the
protected mode test started to pass. Now I have other errors which are
almost certainly other bad tracks, although these errors are more
intermittent so it could be a track that is partially damaged.

Regards

Rob

> -Original Message-
> From: Rob Jarratt 
> Sent: 06 March 2021 23:30
> To: 'Richard Pope' ; r...@jarratt.me.uk; 'General
> Discussion: On-Topic and Off-Topic Posts' 
> Subject: RE: 80286 Protected Mode Test
> 
> 
> > -Original Message-
> > From: Richard Pope 
> > Sent: 06 March 2021 23:20
> > To: r...@jarratt.me.uk; Rob Jarratt ;
> > General
> > Discussion: On-Topic and Off-Topic Posts 
> > Subject: Re: 80286 Protected Mode Test
> >
> > Rob,
> >  There is probably hidden damage to the motherboard. The acid will
> follow
> > the traces inside the board and consume them. There is no way to stop
> > this kind of damage. Sorry for the bad news.
> 
> I should have said that I have found a few bad tracks and I have fixed
them
> by adding wires. Previously it would not even POST, but it does now. The
> CPU is physically distant from the battery damage. I am trying to
understand
> if this particular test could fail due to external factors or not so that
I can then
> investigate if there are other tracks I need to fix.
> 
> Incidentally, my repair wires are done very badly, are there any tips on
how
> to do this well? I have ordered some wire wrap wire because I believe that
is
> what I should be using, but I haven't got the wire yet.
> 
> Thanks
> 
> Rob
> 
> > GOD Bless and Thanks,
> > rich!
> >
> > On 3/6/2021 4:59 PM, Rob Jarratt via cctalk wrote:
> > > I have a DECstation 220 (Olivetti M250E) which is failing POST on a
> > > "simple test of the 80286 protected mode". It says in a service
> > > manual I have that for this test the CPU is set in the protected
> > > mode, the machine status word is checked to see whether it indicates
> > > the protected mode and then exits protected mode. This test seems to
> > > be failing. Is there any possible explanation for this other than a
> > > failed 80286 CPU? Could there be any external reason? This board
> > > suffered some battery leak damage. Clearly the
> > > 80286 is working well enough to execute this diagnostic and send
> > > some text to the screen, so it basically works.
> > >
> > >
> > >
> > > Thanks
> > >
> > >
> > >
> > > Rob
> > >
> > >

Re: 80286 Protected Mode Test

[Maciej W. Rozycki via cctalk]

On Sun, 7 Mar 2021, Noel Chiappa via cctalk wrote:

> > The 286 can exit protected mode with the LOADALL instruction.
> 
> Really? So why all the hullabaloo about Triple Faults:
> 
>   http://www.rcollins.org/Productivity/TripleFault.html
> 
> back in the day; and why did IBM set up the keyboard controller so it could
> send a RESET signal (so people could get out of protected mode)? Or is it
> that LOADALL (which was also undocumented early on, so maybe that's why the
> IBM thing) could be used to cause a triple fault?

 The existence of LOADALL (used for in-circuit emulation, a predecessor 
technique to modern JTAG debugging and the instruction the modern x86 RSM 
instruction grew from) in the 80286 wasn't public information for a very 
long time, and you won't find it in public Intel 80286 CPU documentation 
even today.  Even if IBM engineers knew of its existence at the time the 
PC/AT was being designed, surely they have decided not to rely in their 
design on something not guaranteed by the CPU manufacturer to exist.

 As to why they choose to add the keyboard controller hack I think the 
article referred gives a hypothesis that is as good as you can get: they 
were not clever enough.  Back in the day this wasn't the only fault they 
made and it was a harmless one anyway, because you didn't have to use the 
hack in your software if you knew the proper way.

 Much worse was the mess around the incorrect wiring of the FPU exception 
line (to IRQ #13 via additional glue logic rather than its dedicated CPU 
input), which could have been easily avoided while retaining PC/XT 
compatibility in a manner similar to how it was implemented in the BIOS 
for IRQ #13.  Consequently functionality of the exception was lost (the 
exception was supposed to be precise unlike obviously the external IRQ) 
and also if you were not careful enough in handling it, the machine would 
lock up hard and you'd have to hit the reset button.

 The mess with the FPU exception was actually one of the two reasons to 
drop 32-bit x86 Linux support for the original 80386 CPU several years ago 
(the other one was the lack of write protection in the kernel mode for 
user pages).  Support now starts from the 80486:

$ uname -mrsv
Linux 5.11.0+ #13 Mon Mar 8 00:14:59 CET 2021 i486
$ 

  Maciej

Re: 80286 Protected Mode Test

[Noel Chiappa via cctalk]

> From: Jim Stephens

> The 286 can exit protected mode with the LOADALL instruction.

Really? So why all the hullabaloo about Triple Faults:

  http://www.rcollins.org/Productivity/TripleFault.html

back in the day; and why did IBM set up the keyboard controller so it could
send a RESET signal (so people could get out of protected mode)? Or is it
that LOADALL (which was also undocumented early on, so maybe that's why the
IBM thing) could be used to cause a triple fault?

Noel

RE: 80286 Protected Mode Test

[Rob Jarratt via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Fred Cisin via
> cctalk
> Sent: 06 March 2021 23:17
> To: General Discussion: On-Topic and Off-Topic Posts
> 
> Subject: Re: 80286 Protected Mode Test
> 
> A stupid idea:
> Could the test require, and be failing, access to memory above 1M?
> 

I think that is unlikely because the board comes with 1M onboard and I
believe the system is designed to work with just that memory. I can try it
though if I can find compatible 30-pin simms (I do have some somewhere).
Curious why you think it might require access to memory above 1M though? I
am currently working to the hypothesis that it needs the non-volatile memory
to work to remember that the reset was part of the POST. The NVR is provided
by the RTC element of the 82C206 chip. I may have to get the logic analyser
out to see if that is happening or not, but at the moment I still have an
intermittent problem getting the board to start at all, I think due to my
poor work on the repair wires for the damaged tracks.

Regards

Rob

> 
> On Sat, 6 Mar 2021, Rob Jarratt via cctalk wrote:
> 
> > I have a DECstation 220 (Olivetti M250E) which is failing POST on a
> > "simple test of the 80286 protected mode". It says in a service manual
> > I have that for this test the CPU is set in the protected mode, the
> > machine status word is checked to see whether it indicates the
> > protected mode and then exits protected mode. This test seems to be
> > failing. Is there any possible explanation for this other than a
> > failed 80286 CPU? Could there be any external reason? This board
> > suffered some battery leak damage. Clearly the
> > 80286 is working well enough to execute this diagnostic and send some
> > text to the screen, so it basically works.
> >
> >
> >
> > Thanks
> >
> >
> >
> > Rob

RE: 80286 Protected Mode Test

[Rob Jarratt via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Chuck Guzis via
> cctalk
> Sent: 07 March 2021 00:08
> To: Sean Conner via cctalk 
> Subject: Re: 80286 Protected Mode Test
> 
> On 3/6/21 3:10 PM, Sean Conner via cctalk wrote:
> 
> >   There might be damage to the keyboard controller that could cause
> > the issue.  Once the 80286 is in protected mode, there is no way to
> > get out of protected mode except via the RESET signal.  If I remember
> > correctly, you could program the keyboard controller to send a RESET
> > signal to get out of protected mode.  Also, the keyboard controller
> > also managed the state of address line A20, which is another important
> factor on PCs.
> 
> I'll add that, at least in the PC AT world, the switch to real mode is
> accomplished by writing a value into a reserved cell in CMOS (configuration
> memory--I wish they'd lose that 4-letter appellation--what, in a modern PC
> *isn't* CMOS?).  Upon executing the
> reset code, the BIOS checks for the "reason for shutdown".   If it was a
> switch to real mode, then all of the various hardware tests are bypassed, the
> register file is restored and execution continues.
> 
> What this means that if your CMOS (ugh!) memory isn't functioning, the
> switch to real mode won't work.

I wondered if that might be how it works after reading that you can only switch 
to real mode with a reset. I will follow this line of inquiry. Thanks for the 
suggestion!

> 
> --Chuck

Re: 80286 Protected Mode Test

[jim stephens via cctalk]

On 3/6/2021 3:10 PM, Sean Conner via cctalk wrote:

  Once the 80286 is in protected mode, there is no way to get out of
protected mode except via the RESET signal.
The 286 can exit protected mode with the LOADALL instruction. 
Microsoft's extended memory driver pissed off the world (Intel) when 
someone noticed it was addressing +1mb memory with no hint of the 
reset.  The rest of the world used a driver and memory buffer algorithm 
which optimized accessing > 1mb because of the horrible latency involved 
in what you are describing.


Another client and some friends I had were caught with their s**t 
stinking because they'd used it in their bios (Micro5 systems).


I suspect there's some sort of failure involved like that, but not sure 
how it could live to print the message in the case of going into 
protected mode but not getting back out.


As far as a defective 80286 I can't imagine it passing a lot of the bios 
test code at all if it was internally damaged.


Any POST card (port 80) handy?  Maybe some hints there?
thanks
Jim

Re: 80286 Protected Mode Test

[Chuck Guzis via cctalk]

On 3/6/21 3:10 PM, Sean Conner via cctalk wrote:

>   There might be damage to the keyboard controller that could cause the
> issue.  Once the 80286 is in protected mode, there is no way to get out of
> protected mode except via the RESET signal.  If I remember correctly, you
> could program the keyboard controller to send a RESET signal to get out of
> protected mode.  Also, the keyboard controller also managed the state of
> address line A20, which is another important factor on PCs.

I'll add that, at least in the PC AT world, the switch to real mode is
accomplished by writing a value into a reserved cell in CMOS
(configuration memory--I wish they'd lose that 4-letter
appellation--what, in a modern PC *isn't* CMOS?).  Upon executing the
reset code, the BIOS checks for the "reason for shutdown".   If it was a
switch to real mode, then all of the various hardware tests are
bypassed, the register file is restored and execution continues.

What this means that if your CMOS (ugh!) memory isn't functioning, the
switch to real mode won't work.

--Chuck

RE: 80286 Protected Mode Test

[Rob Jarratt via cctalk]

> -Original Message-
> From: Richard Pope 
> Sent: 06 March 2021 23:20
> To: r...@jarratt.me.uk; Rob Jarratt ; General
> Discussion: On-Topic and Off-Topic Posts 
> Subject: Re: 80286 Protected Mode Test
> 
> Rob,
>  There is probably hidden damage to the motherboard. The acid will
follow
> the traces inside the board and consume them. There is no way to stop this
> kind of damage. Sorry for the bad news.

I should have said that I have found a few bad tracks and I have fixed them
by adding wires. Previously it would not even POST, but it does now. The CPU
is physically distant from the battery damage. I am trying to understand if
this particular test could fail due to external factors or not so that I can
then investigate if there are other tracks I need to fix.

Incidentally, my repair wires are done very badly, are there any tips on how
to do this well? I have ordered some wire wrap wire because I believe that
is what I should be using, but I haven't got the wire yet.

Thanks

Rob

> GOD Bless and Thanks,
> rich!
> 
> On 3/6/2021 4:59 PM, Rob Jarratt via cctalk wrote:
> > I have a DECstation 220 (Olivetti M250E) which is failing POST on a
> > "simple test of the 80286 protected mode". It says in a service manual
> > I have that for this test the CPU is set in the protected mode, the
> > machine status word is checked to see whether it indicates the
> > protected mode and then exits protected mode. This test seems to be
> > failing. Is there any possible explanation for this other than a
> > failed 80286 CPU? Could there be any external reason? This board
> > suffered some battery leak damage. Clearly the
> > 80286 is working well enough to execute this diagnostic and send some
> > text to the screen, so it basically works.
> >
> >
> >
> > Thanks
> >
> >
> >
> > Rob
> >
> >

Re: 80286 Protected Mode Test

[Richard Pope via cctalk]

Rob,
There is probably hidden damage to the motherboard. The acid will 
follow the traces inside the board and consume them. There is no way to 
stop this kind of damage. Sorry for the bad news.

GOD Bless and Thanks,
rich!

On 3/6/2021 4:59 PM, Rob Jarratt via cctalk wrote:

I have a DECstation 220 (Olivetti M250E) which is failing POST on a "simple
test of the 80286 protected mode". It says in a service manual I have that
for this test the CPU is set in the protected mode, the machine status word
is checked to see whether it indicates the protected mode and then exits
protected mode. This test seems to be failing. Is there any possible
explanation for this other than a failed 80286 CPU? Could there be any
external reason? This board suffered some battery leak damage. Clearly the
80286 is working well enough to execute this diagnostic and send some text
to the screen, so it basically works.

  


Thanks

  


Rob

Re: 80286 Protected Mode Test

[Fred Cisin via cctalk]

A stupid idea:
Could the test require, and be failing, access to memory above 1M?


On Sat, 6 Mar 2021, Rob Jarratt via cctalk wrote:


I have a DECstation 220 (Olivetti M250E) which is failing POST on a "simple
test of the 80286 protected mode". It says in a service manual I have that
for this test the CPU is set in the protected mode, the machine status word
is checked to see whether it indicates the protected mode and then exits
protected mode. This test seems to be failing. Is there any possible
explanation for this other than a failed 80286 CPU? Could there be any
external reason? This board suffered some battery leak damage. Clearly the
80286 is working well enough to execute this diagnostic and send some text
to the screen, so it basically works.



Thanks



Rob

Re: 80286 Protected Mode Test

[Sean Conner via cctalk]

It was thus said that the Great Rob Jarratt via cctalk once stated:
> I have a DECstation 220 (Olivetti M250E) which is failing POST on a "simple
> test of the 80286 protected mode". It says in a service manual I have that
> for this test the CPU is set in the protected mode, the machine status word
> is checked to see whether it indicates the protected mode and then exits
> protected mode. This test seems to be failing. Is there any possible
> explanation for this other than a failed 80286 CPU? Could there be any
> external reason? This board suffered some battery leak damage. Clearly the
> 80286 is working well enough to execute this diagnostic and send some text
> to the screen, so it basically works.

  There might be damage to the keyboard controller that could cause the
issue.  Once the 80286 is in protected mode, there is no way to get out of
protected mode except via the RESET signal.  If I remember correctly, you
could program the keyboard controller to send a RESET signal to get out of
protected mode.  Also, the keyboard controller also managed the state of
address line A20, which is another important factor on PCs.

  -spc

80286 Protected Mode Test

[Rob Jarratt via cctalk]

I have a DECstation 220 (Olivetti M250E) which is failing POST on a "simple
test of the 80286 protected mode". It says in a service manual I have that
for this test the CPU is set in the protected mode, the machine status word
is checked to see whether it indicates the protected mode and then exits
protected mode. This test seems to be failing. Is there any possible
explanation for this other than a failed 80286 CPU? Could there be any
external reason? This board suffered some battery leak damage. Clearly the
80286 is working well enough to execute this diagnostic and send some text
to the screen, so it basically works.

 

Thanks

 

Rob