The Intel 80186?

[ChildOfCv]

24 minutes ago, wierd_w said:

Aside from programs that wanted to talk directly to hardware (like games talking to video cards), the DOS interrupt vector table handler methodology should have allowed any random old bit of peripheral to be used just fine, as long as nothing was sitting in the spot used for the vector table, and as long as the 1mb memory space remained consistent.

 

That this did not happens suggests that the low 1mb memory area was not conserved.  I don't rightly know that, but I am open to correction.

The biggest issue is that the 8086 reserved the first 32 interrupt vectors for hardware interrupts, but it only defined the first 8.  IBM said "Cool.  We'll start with 8 then."  They put the hardware interrupt controller at 08-0F.  10-1F were then used by the IBM BIOS for hardware access.  When Intel added more hardware interrupts in the 286, it created the first major conflict with IBM's machine design.  Fortunately, the Intel Programmable Interrupt Controller did allow for remapping the external interrupts, so it was possible to differentiate a CPU exception from an external interrupt by assigning the external interrupts to a better range.

 

Now, about the actual addresses of the PIC and such.  IBM placed the interrupt controller at port address 20-27.  80186 begins with the interrupt controller at FF20-FF3E (and in fact, all peripherals are at FF00-FFFF), but the peripheral block can be remapped to anywhere in I/O or even memory space.  The 80186 interrupt controller is also smarter than the 8259 that IBM used.  It can prioritize interrupts, where the 8259 just gives sequential priority.  The 80186 interrupt controller does not allow external interrupts to be remapped.  The timer is interrupt 8 (which coincides with IBM), but pretty much nothing else matches.

 

Looks like the 80186 has 2 DMA channels, each capable of 20-bit addressing.  The 8237 used by IBM, though, only addresses 16 bits but has 4 channels (one used by IBM for memory refresh though).  IBM augmented it with a separate page register that supplies the upper 4 bits when the DMA does memory access.  This created an issue, though, where DMA access could not cross a 64K boundary.  Also, BIOS provided no generalized routines for programming DMA.  So DMA transfers also had to be done by direct programming.  I suppose this only matters when servicing external hardware though.

 

Anyway, the 1MB address space is not the issue.  Yes, as long as you stick to DOS calls and have a specially-written DOS that works with the 80186, you can run the same code.  Unfortunately, anything that needs to reach into BIOS calls is SOL, and anything that needs to program hardware directly is FUBAR, so no video mode changes, direct disk access, direct keyboard reads, etc.  In addition, any external hardware also needs a specialized BIOS that can talk to the 80186 and of course interfaces with whatever the new 80186-friendly BIOS does.  After all, expansion ROM used by plug-in devices is just data until the BIOS does a search specifically for it and runs its hook code.

[BigO]

9 hours ago, BigO said:

Earlier this evening I was working on cleaning out some stuff I never use. In amongst the reference books is an Intel "Microsystem Components Handbook: Volume I" ca. 1984. Many moons ago, I first heard of the '186 from that book. 

It's looking for a new home. PM me soon if you're interested in adopting it.

"1.   INTRODUCTION

 

As state of the art technology has increased the number of transistors possible on a single integrated circuit, these devices have attained new, higher levels of both performance and functionality. Riding this crest are the Intel 80186 and 80286 microprocessors. While the 80286 has added memory protection and management to the basic 8086 architecture, the 80186 has integrated six separate functional blocks into a single device." 

 

PM me if you want to read more of this riveting tale. ?

[zzip]

On 9/22/2020 at 5:29 PM, bluejay said:

Seriously? A multiuser minicomputer in 1982? I mean, I guess it kinda makes sense, but I'd have imagined by 1982 home computers were becoming more and more popular and minicomputers were becoming less and less popular.

Different market.

I was encountering terminal-based multi-user systems well into the 90s.   They are probably still in use out there.

[mr_me]

Dec vax minicomputers each serving dozens of terminals were common in the 1980s and in to the 1990s when they started to get replaced by personal computers.

 

The 80186 is looking more like a microcontroller than a general purpose cpu.

[tschak909]

The 80186 was explicitly designed for embedded applications, where minimizing chip count was important.

-Thom

[bluejay]

What are multiuser microcomputers even used for these days? Like something that requires some really heavy computing?

[zzip]

13 minutes ago, bluejay said:

What are multiuser microcomputers even used for these days? Like something that requires some really heavy computing?

Linux/BSD and other Unix derivatives are all multi-user OS's and are widely used,  however these days it's more common for them to be deployed for a single service, such as serving a web application (which is still serving many users simultaneously).  It's less common to find a bunch of users logged into them through a dumb terminal doing their individual tasks like the old days. 

 

However, I'm sure it still happens.   Remember how COBOL programmers became in-demand for Y2K?   Because some old systems live forever.   It would not surprise me if the local govt that I worked for in the 90s was still using VAXes and the apps they developed for them today.

[mr_me]

People have been connecting terminals (thin clients) to microsoft windows based servers since the 1990s.  It's more for users with light usage than heavy computing.

[+OLD CS1]

1 hour ago, bluejay said:

What are multiuser microcomputers even used for these days? Like something that requires some really heavy computing?

You would be surprised at the number of back-end systems which are run this way, even if in a virtual environment on a later machine.  Utility companies, school districts, law enforcement information systems, etc.  These systems Just Work^TM, and few web developers have ever been able to deliver on the promise of full web-based replacements.