yevrowl wrote on 2024-03-08, 01:48:

https://i.postimg.cc/8jPWnMfj/proc.png […]
Show full quote

Please tell which computers were produced with an 80188 processors.

https://www.cpu-world.com/CPUs/80188/index.html

Hi.

Not a very common CPU.
There is a list of systems using it on the wikipedia page. https://en.m.wikipedia.org/wiki/Intel_80186

I don't think I ever seen one (or maybe embedded on raid or SCSI cards...)

Anyone with half a brain cell designed with something more sane like NEC V.xx line.

SBC-188 ?

Back in the day, likely no one would have been chosen the 80188 for a DOS PC, though.

The reason is simple, really.
What made the 80186 attractive was a) the higher performance x86 core b) the integrated peripherals.

The 80186 thus was nice for embedded systems or fast DOS PCs.

The 16-Bit memory access was much more performant than that of an 808x, also, I believe.

If IBM compatibility wasn't so important, the 80186 could be used as-is.

If it was important, the internal peripherals were being bypassed and the 80186 was solely being used for its x86 processor core.

Computers which used the 80186 were (among others):
- BBC Master 512 (an upgrade for BBC Master 128)
- Tandy 2000
- Siemens PC-D

The 80188 by contrast isn't better than an 8088, besides having an 80186 instruction set.
It has same 8-bit bottlenecks as an average XT.
The newer CPU core might process certain instructions in fewer cycles, though.

All in all, the 8018x is like an 80286 which had traded its MMU and Protected-Mode for integrated peripherals.

One thing useful that it has, though, is the ability to handle NMIs, maybe.
An x87 emulator like EM87 or an 80386 emulator (-Real-Mode instructions only-) like EMU386 might technically run.

Edit: I assume that the 80186 went out of favor when the regular 80286 was being available for a fair price.

In embedded use, it was still nice to have, though.
The 8018x series could be used as on-board controllers on ISA cards, for example.
Say, for an HDD compression co-processor card. Or as the main controller of an IDE caching controller. Things like this. 🙂

acl wrote on 2024-03-08, 07:40:

Hi. […]
Show full quote

yevrowl wrote on 2024-03-08, 01:48:

https://i.postimg.cc/8jPWnMfj/proc.png […]
Show full quote

Please tell which computers were produced with an 80188 processors.

https://www.cpu-world.com/CPUs/80188/index.html

Hi.

Not a very common CPU.
There is a list of systems using it on the wikipedia page. https://en.m.wikipedia.org/wiki/Intel_80186

I don't think I ever seen one (or maybe embedded on raid or SCSI cards...)

Yes, there were a dozen and a half dozen not very common computers on the 80186 processor. But so far I have not found one on the 80188 processor.

rasz_pl wrote on 2024-03-08, 10:09:

Anyone with half a brain cell designed with something more sane like NEC V.xx line.

Are there any examples of such computers? The search didn't turn up anything...

Jo22 wrote on 2024-03-08, 10:30:

SBC-188 ?

Back in the day, likely no one would have been chosen the 80188 for a DOS PC, though.

Thanks for the detailed information. So realized that it was used mainly in embedded systems.

The 80188 series was generally intended for embedded systems, as microcontrollers with external memory. Therefore, to reduce the number of chips required, it included features such as clock generator, interrupt controller, timers, wait state generator, DMA channels, and external chip select lines.

The initial clock rate of the 80188 was 6 MHz, but due to more hardware available for the microcode to use, especially for address calculation, many individual instructions ran faster than on an 8086 at the same clock frequency. For instance, the common register+immediate addressing mode was significantly faster than on the 8086, especially when a memory location was both (one of the) operand(s) and the destination. Multiply and divide also showed great improvement being several times as fast as on the original 8086 and multi-bit shifts were done almost four times as quickly as in the 8086.

The 80188 is a version with an 8-bit external data bus, instead of 16-bit. This makes it less expensive to connect to peripherals. The 80188 is otherwise very similar to the 80186. It has a throughput of 1 million instructions per second.

This information from this source — https://wiki.edunitas.com/IT/en/114-10/80188_ … 7_eduNitas.html

yevrowl wrote on 2024-03-08, 21:16:

rasz_pl wrote on 2024-03-08, 10:09:

Anyone with half a brain cell designed with something more sane like NEC V.xx line.

Are there any examples of such computers? The search didn't turn up anything...

going by wiki, and I think one of these entries was entered by me 😀 (or maybe it was for NEC V51), V40 is an embedded V20 (8088 clone) with same peripherals as 80188, used in "Olivetti PC1, Digisystems Jetta \XD, Sharp PC-4500 and the Zenith Eazy PC".

yevrowl wrote on 2024-03-08, 21:16:

The 80188 series was generally intended for embedded systems, as microcontrollers with external memory. Therefore, to reduce the number of chips required, it included features such as clock generator, interrupt controller, timers, wait state generator, DMA channels, and external chip select lines.

and even there it was losing to NEC which landed big design wins like Akai S1000 & MPC3000.

I've secured an actual Radio Electronics RE Robot brain/controller. Not a pc, not pc compatible. Has FORTH and allegedly BASIC in rom. I haven't played with it yet. You need a serial terminal to interact with it.
It was an actual commercial product, the Veat Technologies OEM-188. Talking to an employee sometime revealed they may never have sold any, except to those wanting to incorporate it into a robot.

I'll post a few photos in a day or two.

Only place I've ever encountered a 186 is on the DEC TQK70, a QBus TK70 (DLT II) tape drive controller for MicroVAX systems:

Jo22 wrote on 2024-03-08, 10:30:

The 16-Bit memory access was much more performant than that of an 808x, also, I believe.

Not exactly. The 16-bit memory access of the 80186 is just as slow as the 16-bit memory access of the 8086. For accessing word-sized data, it's obviously still faster than the 8-bit access of the 8088, though.

That's also the key issue with the 80188 mentioned in the title of this thread: It is widely known that the 8088 in typical IBM PC software is oftentimes limited by the bus perfermance, because it can execute instructions faster than it can fetch the instructions using the 8-bit bus interface (that's what you get when you slap an 8-bit bus interface onto an execution unit that was designed with the twice as fast 16-bit bus interface unit in mind). The faster execution unit in the 80188 only provides minor performance improvements in most cases, because it will just be idling around longer waiting for the next instruction to be fetched. The 80188 only makes sense if you specifically make use of the new features it provides:

• Integrated interrupt controller, timer and device addressing decoder, but those integrated peripherals are not IBM PC compatible.
• The new "286 real mode" type instructions, that allow smaller code, so less time is "wasted" on fetching the code. Instructions that allow reducing the code size include the new ENTER/LEAVE instructions for procedure entry/exit code, the possibility to push a constant to the stack without loading it into a register before, shifting by multiple bits at once wihout loading the count into CL before or repeating the shift instruction.
• Perform burst I/O using the new repeated I/O-to-memory instructions like REP INSB/REP OUTSB (or the corresponding word instructions, although they make more sense on the 80186 than on the 80188). As the 8018x processors are still using the quite slow bus implementation of the 808x processors, REP INSx/REP OUTSx is likely outperformed by any kind of sensible DMA controller, though. As the 8018x does not include an integrated DMA controller, REP INSx/REP OUTSx might still be interesting for embedded applications in which the REP INSx/REP OUTSx is sufficient, because these instruction beat a loop containing IN/STOS still by a considerable length.

So you can clearly see some embedded applications in which the 80188 makes sense, but its use as general-purpose IBM PC comatible processor is limited. One application of the 80188 processor is the Tekram DC-600B caching IDE controller. The actual IDE hard drive data on that controller is moved using external logic, so the limited I/O performance of that processor is not relevant to that application.

Jo22 wrote on 2024-03-08, 10:30:

One thing useful that it has, though, is the ability to handle NMIs, maybe.
An x87 emulator like EM87 or an 80386 emulator (-Real-Mode instructions only-) like EMU386 might technically run.

The 808x already have NMI support. IBM used the NMI support on those processors to report coprocessor traps (Intel did not provide a standard way for coprocessor traps on the 808x), for memory parity error reporting. You are thinking about the "coprocessor not present" exception and the "invalid opcode" exception, not the NMI.

Jo22 wrote on 2024-03-08, 10:30:

The 8018x series could be used as on-board controllers on ISA cards, for example.
Say, for an HDD compression co-processor card. Or as the main controller of an IDE caching controller. Things like this. 🙂

Most of the Tekram DC-6x0 series are based on the 8018x processor. The later ones are based on the 80186, and only the earliest ones use the 80188. The newest generation (DC-680C, DC-680CD, DC-690) made the step up to the 80286. Also the Compaq IDA ("intelligent drive array") controller, an 8-drive IDE RAID controller, is controlled using an 8018x. Again, just as with the Tekram controllers, the 8018x processor does not touch the drive data, but only controls the logic that transfers the data at way higher speeds than the 8018x could handle. The "spiritual successor" of the Compaq IDA ist the Compaq SMART SCSI raid controller - and while that controller uses a 486SLC as core processor, it is mostly based on the same technology as the older IDA controller, and does not use a lot of functions of the 486SLC that exceed the capabilities of the 8018x processor.

mkarcher wrote on 2024-03-09, 11:50:

Jo22 wrote on 2024-03-08, 10:30:

The 16-Bit memory access was much more performant than that of an 808x, also, I believe.

Not exactly. The 16-bit memory access of the 80186 is just as slow as the 16-bit memory access of the 8086. For accessing word-sized data, it's obviously still faster than the 8-bit access of the 8088, though.

I didn't know that, just checked my old books because I found this topic interesting.

As far as I understand, the 8018x CPU cores were closer to 8088/8086 than 80286.
That's a bit disappointing, to be honest. I always assumed the 80186 was more like a cut-down 80286.

On the bright side, though, one book says that the 80186 did at least manage to do dedicated address calculation.

Because, that was one of the main shortcomings of the 8086 vs 80286. Or so I think.
The 8086 had to use its ALU for this task, if memory serves.

Though of course, this didn't fix the slow 8086 style BIU as such. Actual information exchange was still slower than on an 80286.

Another fine addition was the use of the "8086-2" instruction set, I think.
That's how intel apparently had called the new Real-Mode instructions found on 8018x and 80286 (or iAPX286, as some old manuals say).
NEC also supported them in the V processors.

Then there's also a minor difference in FiFo size, I read.
The 80186 has a 6 Byte FiFo, just like 8086.
The 80188 however, has a 4 Byte FiFo.

Why is that? Why was it changed and shouldn't a crippled CPU have a bigger FiFo, rather? 🤔
To compensate for the slow bus unit? 🤷‍♂️

Edited.

mkarcher wrote on 2024-03-09, 11:50:

The 808x already have NMI support. IBM used the NMI support on those processors to report coprocessor traps (Intel did not provide a standard way for coprocessor traps on the 808x), for memory parity error reporting. You are thinking about the "coprocessor not present" exception and the "invalid opcode" exception, not the NMI.

Yes, you're right, you got me. That's what I meant. 😅

The XT era was a bit before my time, I'm more used to the somewhat related, but also sometimes different Z80 platforms.

mkarcher wrote on 2024-03-09, 11:50:

Most of the Tekram DC-6x0 series are based on the 8018x processor. The later ones are based on the 80186, and only the earliest ones use the 80188. The newest generation (DC-680C, DC-680CD, DC-690) made the step up to the 80286. Also the Compaq IDA ("intelligent drive array") controller, an 8-drive IDE RAID controller, is controlled using an 8018x. Again, just as with the Tekram controllers, the 8018x processor does not touch the drive data, but only controls the logic that transfers the data at way higher speeds than the 8018x could handle. The "spiritual successor" of the Compaq IDA ist the Compaq SMART SCSI raid controller - and while that controller uses a 486SLC as core processor, it is mostly based on the same technology as the older IDA controller, and does not use a lot of functions of the 486SLC that exceed the capabilities of the 8018x processor.

Thanks, that's interesting.
The Tekrams were quite some interesting cards.

Btw, I wonder why IBM didn't build an upgraded PGC (Professional Graphics Controller) on a 80188 or NEC V20 basis.

Because, the original board was really fascinating from a technical point of view.
640x480 in 256c was neat, too. It was NTSC resolution and square pixel.

A modernized or cost-reduced version would have been interesting, thus.

Jo22 wrote on 2024-03-10, 11:21:

I didn't know that, just checked my old books because I found this topic interesting. […]
Show full quote

mkarcher wrote on 2024-03-09, 11:50:

Jo22 wrote on 2024-03-08, 10:30:

The 16-Bit memory access was much more performant than that of an 808x, also, I believe.

Not exactly. The 16-bit memory access of the 80186 is just as slow as the 16-bit memory access of the 8086. For accessing word-sized data, it's obviously still faster than the 8-bit access of the 8088, though.

I didn't know that, just checked my old books because I found this topic interesting.

As far as I understand, the 8018x CPU cores were closer to 8088/8086 than 80286.
That's a bit disappointing, to be honest. I always assumed the 80186 was more like a cut-down 80286.

Both is correct in a certain point of view. The 80186 combines an 80286-like execution unit with an 8086-like bus interface unit. Or, put it another way: Moving forward from the 8086 to the 80186 we got a new execution unit, and stepping up to the 80286, we also got a new bus interface unit.

Jo22 wrote on 2024-03-10, 11:21:

On the bright side, though, one book says that the 80186 did at least manage to do dedicated address calculation. […]
Show full quote

On the bright side, though, one book says that the 80186 did at least manage to do dedicated address calculation.

Because, that was one of the main shortcomings of the 8086 vs 80286. Or so I think.
The 8086 had to use its ALU for this task, if memory serves.

Though of course, this didn't fix the slow 8086 style BIU as such. Actual information exchange was still slower than on an 80286.

The 16-bit offset is calculated inside the execution unit, the bus interface unit is responsible for adding the segment register contents to the offset provided by the execution unit. You are right: The 8086 execution unit used microcode and its single 16-bit ALU to do the address calculation, while the 80186/80286 execution engine got its own AGU ("address generation unit").

Furthermore, while the 8086 bus interface unit was slow, it was not terribly slow. The 8088 was the processor that suffered severly from the bus interface unit, because the execution unit executed instructions at the same pace as the 8086 did, but the bus interface unit only provided half the bandwidth to fetch those instructions, introducing a severe bottleneck. Combining the 8-bit BIU of the 8088 with the improved EU of the 8018x is a recipe for mediocre performance, though.

Regarding the fetching bottleneck, that one was so severe that Intel had to acknowledge it in the official data sheets!

8088 datasheet wrote:

The CPU is also limited by the speed of instruction fetches. This latter problem only occurs when a series of simple operations occur. When the more sophisticated instructions of the 8088 are being used, the queue has time to fill and the execution proceeds as fast as the execution unit will allow.

80186/80188 datasheet wrote:

The 80186 has sufficient bus performance to ensure that an adequate number of prefetched bytes will reside in the queue (6 bytes) most of the time. Therefore, actual program execution time will not be substantially greater than that derived from adding the instruction timings shown.

The 80188 is noticeably limited in its performance relative to the execution unit. A sufficient number of prefetched bytes may not reside in the prefetch queue (4 bytes) much of the time. Therefore, actual program execution time may be substantially greater than that derived from adding the instruction timings shown.

Note how the datasheet acknowledges that the 80188 may be stalled on instruction fetches much of the time. As vendor datasheets are typically making the chips appear in a good light (as you see in the 8088 datasheet, referring to the execution of complex instructions allowing to fill the queue), the statement about the 80188 shows that Intel completely gave up trying to paper over the insufficient memory bandwidth of that chip.

Jo22 wrote on 2024-03-10, 11:21:

Then there's also a minor difference in FiFo size, I read. The 80186 has a 6 Byte FiFo, just like 8086. The 80188 however, has […]
Show full quote

Then there's also a minor difference in FiFo size, I read.
The 80186 has a 6 Byte FiFo, just like 8086.
The 80188 however, has a 4 Byte FiFo.

Why is that? Why was it changed and shouldn't a crippled CPU have a bigger FiFo, rather? 🤔

First, you should understand that the prefetch queue of the 8086 is quoted as "6 Bytes" by nearly every source you can find, but as the 8086 has a 16-bit BIU, the actual organization of the queue is 3 words, whereas the 8088 has a queue of 4 bytes. So if you measure the queue length not in bytes, but in bus operations required to fill it, the 8088 already has a longer queue than the 8086. The 8088 datasheet explains that the queue length of 4 bytes is a deliberate design decision by Intel:

8088 datasheet wrote:

The queue length is 4 bytes in the 8088, whereas the 8086 queue contains 6 bytes, or three words. The queue was shortened to prevent overuse of the bus by the BIU when prefetching instructions. This was required because of the additional time necessary to fetch instructions 8 bits at a time.

Prefetching instructions into the prefetch queue is a speculative operation: The instruction might get executed, or might get flushed if the processor encounters an instruction changing IP (JMP, CALL, INT, RET, ...). Overusing the bus with speculative instruction fetches might kill the performance of tight loops that access memory (which might actually be quite common in processor benchmarks).

Jo22 wrote on 2024-03-10, 11:21:

Btw, I wonder why IBM didn't build an upgraded PGC (Professional Graphics Controller) on a 80188 or NEC V20 basis.

Probably the sales of the PGC were so underwhelming that IBM stopped spending any money on that card, and focussed on EGA instead.

Jo22 wrote on 2024-03-10, 11:21:

Because, the original board was really fascinating from a technical point of view.
640x480 in 256c was neat, too. It was NTSC resolution and square pixel.

A modernized or cost-reduced version would have been interesting, thus.

There are 3rd-party clones of the PGC, even with higher resolutions up to 1024x768. I actually saw a PGC-based machine in a scientific lab at a university, but too bad I didn't catch the moment when that experiment was taken out of order and the machine recycled. They used the 256-color PGC to display images acquired by a scanning tunnel microscope, and used a thermo transfer printer to print those images. When I saw that machine, it was no longer in productive use, but the experiment was demoted to be a student exercise experiment instead of an actual research experiment.

1 of the IBM PGC clones, the one made by Vermont Microsystems, has an 80188. I'm lucky enough to own both. It is a dual card w/o a cga daughtercard. Presumably that functionality is built imto 1 of the long cards.