10

It is tempting to say - and I have said - that Intel made a mistake in the design of the 8086 and 8088, in going from 16 bit addresses to only 20 bits; if they had even shifted the segment registers by 8 bits instead of 4, we could have had 24 bit addressing, which in the eighties would have been a dramatic improvement on the actual state of affairs.

The reasons for this have been discussed - Why was segment register value scaled by such a small factor of 16 on i8086? - the important and nonobvious point being that many more address bits would have required more pins on the CPU, therefore a larger package, which would have cost more. Indeed if we look at the pinout - http://www.datasheetcafe.com/8088-datasheet-8-bit-hmos-microprocessor-intel/ - we see that it is already pretty tight, with some address pins already being multiplexed with other things.

Would there have been a substantial jump in cost associated with going even slightly beyond 40 pins? If so, was there any reasonable way to add even one or two extra bits of address?

14
  • 3
    Intriguingly there was a 44-pin PLCC variant of the 8088... At the time though, 40-pin DIP was used for many CPUs, so there might have been larger economic factors (socket pricing, picking and placing machines...). Jun 22, 2018 at 19:19
  • 3
    It saw the light of day exactly 4 years later - And was what the 8086 should have been (plus protected mode), had it not been brought to market in an extreme hurry. Remember the Motorola 68000 appeared only shortly after the 8086, in a 64-Pin DIL package with 24 address lines, so all you're asking for. Or the Zilog Z8000, 1979, 16+7 address lines, 8M addressing range (but a bug-ridden flop)
    – tofro
    Jun 22, 2018 at 19:32
  • 1
    Maybe an expert could comment on how common it was for chips to be anything larger than 40-pin DIPs in 1978? Re: 'if so', I don't have a non-opinion-based answer but I think yes, there are two GND pins so an extra address pin would in theory fit on the same package. Also one could just have done what the 68000 did: define a larger addressing space than is exported by the packaging, assuming it can be provided in full later if the architecture is a hit.
    – Tommy
    Jun 22, 2018 at 20:12
  • 2
    @StephenKitt I did unserstand it. My comment was ment to tell that I think using these 4 additional pins for address would have been nice - at least in a world where programmers try to write clean code .. so not ours :(
    – Raffzahn
    Jun 22, 2018 at 21:33
  • 2
    Packaging a 44 pin design (that has 4 non-essential pins) in a 40 pin package would mean you end up with 4 unconnected pins which you have to either connect inside the 40 pin package, or electrically make "unconnected-proof". Jul 9, 2018 at 15:04

2 Answers 2

9

TLDR:

Yes, it would have been possible to extend it up to 22 bit with minimal changes, 21 or 23 bit by moving two 8086 specific signals and 24 with breaking 8086/88 hardware compatibility.


The Long Read

As usual with What If questions, there is a huge area of possible answers. Same here. But I think we can concentrate on two issues: Changed packaging and signal multiplexing.

a) Different Packaging

DIP64

Of course Intel could have gone with a different housing. For example like Motorola with 64 pin .9" DIP64. But like Motorola this would require Intel to invest into new packaging machines to handle DIP64 (in large numbers), while DIP40 was plenty available (*1), thus increasing first time cost.

Similar on the customer side it would increase cost by the need for increased PCB space (*21) plus more expensive sockets (if socketed) (*3). Not exactly a great sales pitch - especially when intending to get the 8088 out as a low cost (*4) replacement for 8085 designs that need more power.

Last but not least DIP64 has longer leads (connections from pin to chip) thus more inductivity, resulting in lower maximum speeds (or more problems).

DIP48

Another way would have been the use of a .6" DIP48, which was used for some custom chips. While avoiding most of the PCB cost and inductivity problems, all other factors would be the same as for DIP64.

QIP

What's most interesting about your question is that Intel did, right at the time the 8086 was introduced, think about using QIP packages for their iAPX432 systems (*5). QIP (or QIL) is a format introduced by Rockwell around 1970 - even before their first CPU (PPS-4,*6) - to waste less space on complex packaging and get shorter connections (*7).

QIP orders pins in an alternating fashion in two rows on each side, using a 50 mil pitch (*8) between pins and 100 mil between rows thus keeping the through-holes as far apart as with standard DIL, but halving the lenth of a package while adding 'just' .2 inch to their width.

In 1978 Intel joined with packaging manufacturer 3M to design a leadless QIP version called QUIP. The drawbacks of new tooling, more expensive production and a higher cost product wasn't a big concern for the iAPX432 line, as they where intended to be top of the line anyway.

So Intel might have as well selected QUIP for the 8086 - but with it's target to fast fill a short time niche with great cost pressure, such a packaging would have been quite unwise.

Other Packagings

There have been other attempts to come up with more compact DIL. Most notable Japanese manufacturers with 2 millimeter DIP. Here a 64 pin DIP would take up the same PCB space as a conventional (2.54 mm) DIP40. Even retooling would be less expensive as most parts of existing packaging lines just need minor reconfiguration. Still, it never caught on.

Conclusion

While it would have been possible, any divergence from DIP40 would have made the product not only harder to sell but also require higher setup and manufacturing cost - not really worth for an in between design meant to bridge just a few years.

b) Signal Multiplexing


Caveat, I didn't go thru all timing diagrams and just used the manual to lookup the pinouts, so there might be hidden problems cancelling my findings.


So while a different packaging was out of scope, putting different signals onto the same pin might be possible - after all, that has been done with the 8080 and 8085 and the 8088 was meant to replace the later one anyway?

Again, there are multiple considerations.

Basic Considerations

While it is easy to say lets multiplex some more interface lines onto the address lines, multiplexing does also put restriction on this. Each signal has to be available at the right time. Right now only status signals are multiplexed with address lines. Most notably only such that are new to the 8086 and not present on an 8085.

To make room for more address lines we need to find some signals that are

  • lines that are not address/data lines
  • lines driven by the CPU (output)
  • not needed during address transfer
  • not already defined for 8085 peripherals (in minimal mode)

While the first seams obvious, it already takes away half of all, as 20 of the 40 pins carry ADxx lines. When taking away all inputs and 8085 compatible (minimum mode) signals, only three power supply lines and /RDis left. And using /RD as additional address pin would break 8085 compatibility.

Wait, that was Three Power Lines?

Yup, two ground (#1 and #20) and one 5V (#40). And yes, here is one easy pick. It might have been possible to drop GND from pin#1 and use this as additional address line - so 2 Mib ... Jippieeee :) Then again, while not very likeable, this may complicate the chip design. Who knows.

OK, but what about maximum mode

Maximum mode may be seen as the 8086' native mode. Here the CPU doesn't generate 8085 compatible memory control signals, but needs an 8288 bus controller to do so. This 'frees up' 8 pins which now carry different signals. While two are bidirectional for bus handling, the other 6 are output lines. Three of them (/S0, /S1, /S2) feed the 8288 and can not be used for multiplexing. Similar reassigning /LOCK is a bad idea.

This still leaves /QS0 and /QS1. They allow to peek into the queue operation of the BIU. It's a function meant for co-processors, mot notably the 8087. They signal opcode fetch and queue status so a coprocessor can synchronise it's interpretation of the 8086 instruction stream - here especially detecting and grabbing ESC instructions (binary opcodes 1101 1xxx).

While this signalling is essential for coprocessor integration, it should be possible to share this information with address lines.

So here are 2 more pins to be used - but only in maximum mode.

And what about the 8088

Funny question, after all, the 8088 pinout is exactly as the 8086, except for the fact that there is no data transfer on the A8..A15. Well, and thus no need for /BHE. Pin #34 carries on the 8088 an additional status signal (/SS0) allowing a better bus cycle decode during minimal - and nothing in maximum mode.

So here comes (in maximum mode) another usable pin.

That easy? No, not really, as there is a drawback. Pin #34 of a 8088 in maximum mode is always high. That's exactly the behaviour of a 8086 only accessing the lower byte. This behaviour was added to make them 100% compatible replacements - at least control wise. It is possible to make a one board that can hold a 8086 or a 8088 without any changes in board design. Just when populating it with a 8088 half of the RAM (and ROM) can be left out. The system will work exactly the same, right out of the box (in maximum mode that is) (*9).

Bottom line, we only get this bit if we break with this design advantage. Not cool.

So 24 Bit addressing would be possible?

Yes. But only in maximum mode and on a 8088. But let's add it up:

2 MiB (21 bit) address space for 8086 and 88 in all modes:

  • Pin #1 (GND) becomes A20

8 MiB (23 bit) address space for 8086 and 88 in maximum mode:

  • Pin #1 (GND) becomes A20
  • Pin #25 (QS0) becomes A21
  • Pin #24 (QS1) becomes A22

16 MiB (24 bit) address space for the 8088 in maximum mode:

(Accepting broken compatibility)

  • Pin #1 (GND) becomes A20
  • Pin #25 (QS0) becomes A21
  • Pin #24 (QS1) becomes A22
  • Pin #34 (BHE) becomes A23

Conclusion

While I wouldn't recommend the last variation, as it breaks compatibility and offers more RAM only for the slower design, 23 bit address would have been possible with acceptable modifications, at least for maximum mode. And still two MiB in minimum mode. A granularity of 8 bit would have worked nice. Even accepting a ... well ... noo, don't read this footnote (*10)


P.S. I really liked the question, as it made me think about something I didn't touch before: Is there still room within the 8086 pinout without breaking compatibility and reshuffling everything. Cool. Thank you Rwallace.


*1 - Tooling for chip packaging is also a reason why there are next to no chips outside the 24/28/32/40 pin range for .6" packages. It just doesn't pay. It's les costly to leave some pins NC (see 6502).

*2 - A DIP 40 is 15,2 mm by 53,4 mm covering an area of ~810mm^2 while a DIP64 is 22.9 mm by 83.9 mm or ~1920 mm^2 - that's almost 2.5 times the area.

*3 - The price of DIP sockets are (at equal quality) almost complete defined by volume. DIP 40 was already common while DIP64 was low quantity/high price.

*4 - That is for design, programming and production.

*5 - The iAPX432 was meant to be the great next generation 32 bit system, where Intel tried to leapfrog all 16 bit development. In fact, it was a great design, just the CPU world wasn't ready - much like 20 years later for Itanium :))

*6 - Rockwell continued to use it way into the 1990 for example for their 6511AQ controllers. Or NEC for Z80-alike µPD7810/11 controllers.

*7 - And in fact not even invented by Rockwell, as RCA and SIEMENS used a similar design already in the mid 1960s - back then even for ICs with just 20 pins. The design is an incremental step from their first chips using round pinouts.

*8 - standard pitch for DIL packages id 100 mil (1/100th inch)

*9 - OK, it might be useful to take this into account and have no word wide interfaces or interfaces on odd addresses and so on - then again, it is rather easy to connect the select and latch controls in a way, that a few jumpers can set this right. So again, a careful design can host both either CPUs on the same board, making it easy to switch to an 8086 when bloaty software slows it down. Or offer two systems from the same parts, saving a lot in manufacturing setup.

*10 - Of course, a theoretical address space of 16 MiB with only 8 MiB usable would for sure have resulted in way more crappy PC software using the address wrap - or worse, using the high bit for some data - like people have done on the 68k (and /370). Pure compatibility horror.

2
  • 1
    I think it would be possible to free up even more pins without too much difficulty in maximum mode (saying that systems wanting to use the full addressing range must use maximum mode hardly seems unreasonable). Since each memory access takes a minimum of four cycles, a bus controller could multiplex IRQ, NMI, READY, and TEST all onto one pin.
    – supercat
    Jun 22, 2018 at 21:55
  • 1
    @supercat At the cost of a bigger chip, as the 8288 is already a 300 mil DIP20 or another one which is the same. And a more complex design. Reusing input pins like IRY or NMI would require isolating buffers external to the CPU - even more cost. The question wasn't about what would be a fun CPU without constrains, but if it could have been done without much change and most important no change to the business case.
    – Raffzahn
    Jun 22, 2018 at 22:02
6

Total System Cost = RAM + CPU + Everything Else

When you are going for the mass market - as opposed to workstations or other high-end systems - the key is total system pricing. Three of the biggest pieces - then and now - are RAM, mass storage and CPU. Mass storage varied quite a bit - floppies, hard drives, etc. - and, particularly with floppies, the storage was expandable at low cost by simply swapping media. So the core (pun intended) costs come down to RAM and CPU. While I know there are systems easier/cheaper to build with one architecture vs. another, in the end the RAM and CPU are two of the biggest factors in most systems, at least in 1978 through the 1980s.

What does that really mean? RAM was a huge cost. If you only needed a little then the CPU architecture wasn't much of an issue. But if you needed a lot then the RAM pricing was more of an issue, except for the very high end, than CPU architecture.

At the time the 8086 was released in 1978, typical machines had 64k and many had far less than that. Using this Memory Price history site as a guide, in 1978 a 64k board cost > $1,000. You couldn't, typically, get 1 Meg. for under $1,000 until ~ 1984, by which time the 80286 was in use in the IBM AT. The 80386, which could make use of a LOT more RAM came out just a year after that, in 1985.

To put it another way, when the 8086 was introduced, jumping from 64k to 128k was expensive but possible - and provided a huge improvement over 8080/Z80 systems. But going to 1 Meg. was pie-in-the-sky for your typical system builder. A home computer - even a typical small business or departmental computer couldn't justify spending $10,000 on RAM.

The target market, except for "real programmers" also didn't care about architecture. If it worked - running applications they needed or languages they needed to write their own software - that was good enough. Could a CPU address 16 Meg. instead of 1 Meg.? That would be great - but totally irrelevant if you couldn't even afford 1/2 Meg. Kind of like buying a house with enough land to expand from 3 bedrooms to 30 bedrooms. If you can't afford it, it doesn't matter - just use the 3 bedroom house as best as you can.

So while Intel could have, perhaps at the expense of some other features or at a slightly higher chip cost, given the 8086 a wider address bus and larger memory space, the mass market would not have made use of it for several years. It was only with the incredible success of the IBM PC and its clones that we ended up with a single broad computing architecture that lasted for so many years in the microcomputer world. IBM with its mainframe 360, 370, etc. architecture was already well established, but micros varied quite a bit in the early days and I suspect many designers did not anticipate taking an architecture designed in 1982, and initially using a CPU designed in 1978, and using it to run the same applications in a Windows XP DOS box inside Windows 7 36 years later. And yes, that application is itself often still limited to 1 Meg. - or typically ~ 640k due to the original IBM PC memory structure. I still have, believe it or not, a few applications like that out there, and I know I'm not the only one.

1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Matt Lacey
    Jun 26, 2018 at 1:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.