- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
8086 Based Computer Design
- Thread starter sergey
- Start date
Chuck(G)
25k Member
I don't see how one can practically get beyond the need of an MCU for PS/2 keyboard interfacing.
If PC compatibility isn't important, why not an 80186/V50 with the peripheral interfacing already taken care of? Heck, the 186 even has programmable chip selects and is perfectly contemporaneous with the IBM 5150.
If PC compatibility isn't important, why not an 80186/V50 with the peripheral interfacing already taken care of? Heck, the 186 even has programmable chip selects and is perfectly contemporaneous with the IBM 5150.
glitch
Veteran Member
I'd vote for the 80186 as well, preferably in a PLCC package. You could still socket it and retain a through-hole design.
sergey
Veteran Member
GOLD CHIP,
You need to decide on and describe the goals of your project in more detail. If you're going pure 16-bit (non-IBM PC compatible) route, both hardware and software doesn't have to match the IBM PC implementation.
Some examples:
- Extension bus to be used. Some choices: ISA (be aware that not all cards will work with "pure 16-bit", even not all 16-bit cards), S-100, ECB...
- DMA in IBM PC is implemented in a very hackish fashion. The DMA chip itself (8237) was not intended to be used with 8086/8088 and doesn't support 20-bit address and can only generate 16-bit address. It also doesn't integrate well with 8086/8088 configured in maximum mode. The IBM PC uses "fake" wait states to grab the bus for DMA. First question here - do you need DMA at all? Some popular devices that use DMA are: Floppy disk controller, Sound cards (for digitized samples playback), some hard drive controllers. Floppy disk controllers can also work without DMA, and it is not very likely that you'll have an old XT hard drive controller than needs DMA. So only sound cards left... If you think you still need DMA, you might check for alternatives (although they can be difficult to find at this point of time).
- PIT in IBM PC one channel is used for memory refresh, you don't need it since you will be using SRAM. You can re-purpose it. (In Xi 8088 I connected the channel 0 to a FF. FF output toggles with every timer pulse, and its output that can be read through port 61h. This is very similar to what AT is doing, and it can used for timing purposes, e.g. delays)
- 8259 PICs are probably OK... the question is how many PICs do you want. One provides 8 interrupts, it is possible to cascade them and have up to 256 interrupts. AT cascades two PICs (and so Xi 8088 ), so it has 15 interrupts... (7 on master PIC and 8 on slave PIC).
- Keyboard is a relatively simple part. I have three options: 1) Use VT82C42 or any other AT or PS/2 compatible keyboard controller. 2) Use a Propeller chip with a corresponding firmware. It can also handle other things (VGA output, SD card interface) for example refer to this project. 3) Implement a simple serial interface (similar to the PC/XT one) in CPLD or using discrete logic, and use AT2XT converter to connect an AT or PS/2 keyboard. You can implement the AT2XT functionality on your board (it is just a simple PIC micro).
- On software side, regardless of the type of IBM-compatible BIOS your choose, it will need to be extensively modified to match the system hardware. (By the way what is the target OS?)
You need to decide on and describe the goals of your project in more detail. If you're going pure 16-bit (non-IBM PC compatible) route, both hardware and software doesn't have to match the IBM PC implementation.
Some examples:
- Extension bus to be used. Some choices: ISA (be aware that not all cards will work with "pure 16-bit", even not all 16-bit cards), S-100, ECB...
- DMA in IBM PC is implemented in a very hackish fashion. The DMA chip itself (8237) was not intended to be used with 8086/8088 and doesn't support 20-bit address and can only generate 16-bit address. It also doesn't integrate well with 8086/8088 configured in maximum mode. The IBM PC uses "fake" wait states to grab the bus for DMA. First question here - do you need DMA at all? Some popular devices that use DMA are: Floppy disk controller, Sound cards (for digitized samples playback), some hard drive controllers. Floppy disk controllers can also work without DMA, and it is not very likely that you'll have an old XT hard drive controller than needs DMA. So only sound cards left... If you think you still need DMA, you might check for alternatives (although they can be difficult to find at this point of time).
- PIT in IBM PC one channel is used for memory refresh, you don't need it since you will be using SRAM. You can re-purpose it. (In Xi 8088 I connected the channel 0 to a FF. FF output toggles with every timer pulse, and its output that can be read through port 61h. This is very similar to what AT is doing, and it can used for timing purposes, e.g. delays)
- 8259 PICs are probably OK... the question is how many PICs do you want. One provides 8 interrupts, it is possible to cascade them and have up to 256 interrupts. AT cascades two PICs (and so Xi 8088 ), so it has 15 interrupts... (7 on master PIC and 8 on slave PIC).
- Keyboard is a relatively simple part. I have three options: 1) Use VT82C42 or any other AT or PS/2 compatible keyboard controller. 2) Use a Propeller chip with a corresponding firmware. It can also handle other things (VGA output, SD card interface) for example refer to this project. 3) Implement a simple serial interface (similar to the PC/XT one) in CPLD or using discrete logic, and use AT2XT converter to connect an AT or PS/2 keyboard. You can implement the AT2XT functionality on your board (it is just a simple PIC micro).
- On software side, regardless of the type of IBM-compatible BIOS your choose, it will need to be extensively modified to match the system hardware. (By the way what is the target OS?)
Last edited:
I'm considering 80186, I've studied the datasheet of it in detail. BUt I'm inclined to using 8086 since I allready have 2 tube of them. Lemme think
Chuck(G)
25k Member
Be sure to check out all of the variations--the 186 isn't a single chip, but rather a family of them that comes in anything from a 68 pin PLCC to 144 pin QFP.
eeguru
Veteran Member
I don't understand this temptation. If you really mean FPGA as a traditionally larger part, the rabbit hole can get pretty deep as there are already numerous system level designs in soft-IP for everything from the DMA controller, clock chip, bus mux, keyboard controller, even VGA controller to the extreme of a soft 8086 CPU core itself. And you also have to deal with 3.3V interfacing. If you mean smaller CPLDs and SPLDs like using a +5V 22V10 or ATF1504 in places to cut the gross chip count down, a nifty little board could be built. But not as nifty as using a more integrated CPU if DOS/IBM compatibility isn't a design goal.
A 4-12 SMP 8086 with a significant bit of PLD glue to provide HW spin locks and shared memory mapping would be a thought tickling project however.
sergey
Veteran Member
There you go
Make it an 8086-based supercomputer, the way Intel originally meant it to be. Use 8289 bus arbiters, put some 8089 for I/O acceleration instead of DMA.
See this for a rough description of multiprocessor 8086 system: http://pimlico.phys.appstate.edu/phy4635/l18_09_multiple_processors.pdf
Chuck(G)
25k Member
Run iRMX on it too and use a Multibus backplane.
The 8086 was a "stopgap" product and probably persisted only because Intel couldn't make a go of the 432.
The 8086 was a "stopgap" product and probably persisted only because Intel couldn't make a go of the 432.
Run iRMX on it too and use a Multibus backplane.
The 8086 was a "stopgap" product and probably persisted only because Intel couldn't make a go of the 432.
I was thinking about using small RTOS which usually used in low_end mobile phone. I find the word "mobile phone" is attention grabber for student, instead of "computer architecture".
Could you tell me more about the "stopgap" and 432 stories?
There you go
Make it an 8086-based supercomputer, the way Intel originally meant it to be. Use 8289 bus arbiters, put some 8089 for I/O acceleration instead of DMA.
See this for a rough description of multiprocessor 8086 system: http://pimlico.phys.appstate.edu/phy4635/l18_09_multiple_processors.pdf
very interesting, have anyone ever built this. I'd like to have a video of it running in its full capacity.
BTW I've never read 8089 datasheet, so I have to attuned my brain to it.
definitely not 3.3V. I just want to have all the glue logic in one big chip, preferably DIP.
Crypticalcode0
Experienced Member
Err Glue logic also defines the term address decoding which traditionally used 74 logic components.
Let's say you want to have simple slabs of 128KB you could use a single 74138 to divide the address space in that manner which is rather wastefull IMHO.
Let's keep it simple and straight forward and use combinational logic to decode the address for chip select in addition to the formentioned 74138.
Chuck(G)
25k Member
I'm dead certain that Intel published a few reference designs for this. Wasn't iRMX supposedly multi-processor capable?
There's still plenty of 5V CPLD stuff around, so don't rule out programmable logic.
There's still plenty of 5V CPLD stuff around, so don't rule out programmable logic.
CPLD would be ATF2500C
BTW, could you explain how 8086 can address 2Mbyte of RAM. thanks
Chuck(G)
25k Member
How do you want to address it? If you decode the control signals, you'll note that the associated segment register is also present in the status bits for every memory reference. There's nothing in the world preventing CS, DS, ES and SS each addressing their own private megabyte of memory space (4MB), or even sharing only part of a memory space. Beyond that, there's the obvious bankswitching approach. There's no rule that your system has to be pure von Neumann or pure Harvard architecture.
There's plenty of documentation out there that the 432 was to be Intel's answer to the 32-bit CPU market. I was part of a company that dates back to 1976 who marketed a small business computer that used the MCBA business apps that were, up until then, hosted on a Data General mini. We managed to squeeze them onto an 8085 box and even perform them as multi-user, but the original vision was to track the state of the art and offer a substantial minicomputer-like system for small business that took advantage of the improvements in technology which were then moving pretty fast. To that end, we had a senior Intel VP on our board. If Intel did something, we found out about it pretty fast. I think we learned about the 432 project sometime around 1978 and it was promised as the "next big thing", the product of the 1980s, "micro mainframe" and other good stuff.
I had been pushing the 68K as being the closest to being really what we wanted. There were some drawbacks--uncertain delivery schedules, lack of true virtual memory capabilities (without a lot of special tricks), but all in all, a nice clean architecture. We got a sample and wire-wrapped up a prototype and it worked pretty much according to specs. When our Intel board member heard about it, he swore that no company he was associated with was ever going to use a competitor's CPU. He couldn't offer any step up from the stock product line, so he got us in on the barely-working early steppings of the 80186 and a promise to keep us in the 80286 loop. The 80186 was never intended to be a general-purpose CPU (more of a microcontroller), but we had no choice. The idea was that we could move to an 80286 if we just stuck an empty socket on our boards for it and then we could do another redesign for the Real Thing, the IAPX432.
The product shipped with the 80186; no fully-working 80286 chips existed yet. We ran CP/M-86 and MS-DOS 1.x, just like a bunch of other vendors. This, of course, put us into direct competition with the PC and it clones and the rest of the story is obvious. We did get Xenix onto the 286 eventually, but it was pretty expensive to customers and maintenance headache. I left in 1981 because I could see what was coming and by 1985, the firm was in chapter 7 bankruptcy. The 432 was very late, much slower than expected and cost a fortune. I believe that it would be fair to call it a failure for Intel.
To quote WikiP:
FWIW, I also really liked the NS32016 design, but it was clear that it was going to be very late also.
There's plenty of documentation out there that the 432 was to be Intel's answer to the 32-bit CPU market. I was part of a company that dates back to 1976 who marketed a small business computer that used the MCBA business apps that were, up until then, hosted on a Data General mini. We managed to squeeze them onto an 8085 box and even perform them as multi-user, but the original vision was to track the state of the art and offer a substantial minicomputer-like system for small business that took advantage of the improvements in technology which were then moving pretty fast. To that end, we had a senior Intel VP on our board. If Intel did something, we found out about it pretty fast. I think we learned about the 432 project sometime around 1978 and it was promised as the "next big thing", the product of the 1980s, "micro mainframe" and other good stuff.
I had been pushing the 68K as being the closest to being really what we wanted. There were some drawbacks--uncertain delivery schedules, lack of true virtual memory capabilities (without a lot of special tricks), but all in all, a nice clean architecture. We got a sample and wire-wrapped up a prototype and it worked pretty much according to specs. When our Intel board member heard about it, he swore that no company he was associated with was ever going to use a competitor's CPU. He couldn't offer any step up from the stock product line, so he got us in on the barely-working early steppings of the 80186 and a promise to keep us in the 80286 loop. The 80186 was never intended to be a general-purpose CPU (more of a microcontroller), but we had no choice. The idea was that we could move to an 80286 if we just stuck an empty socket on our boards for it and then we could do another redesign for the Real Thing, the IAPX432.
The product shipped with the 80186; no fully-working 80286 chips existed yet. We ran CP/M-86 and MS-DOS 1.x, just like a bunch of other vendors. This, of course, put us into direct competition with the PC and it clones and the rest of the story is obvious. We did get Xenix onto the 286 eventually, but it was pretty expensive to customers and maintenance headache. I left in 1981 because I could see what was coming and by 1985, the firm was in chapter 7 bankruptcy. The 432 was very late, much slower than expected and cost a fortune. I believe that it would be fair to call it a failure for Intel.
To quote WikiP:
FWIW, I also really liked the NS32016 design, but it was clear that it was going to be very late also.
That is awesome, 1MB dedicated for each segment. I would really like to try that. After this simple design, I will definitely do that.
Ok. change of direction again,
the current project would be very simplified, the start vector would be hand written and only do "Hello world" and blinking a few LED.
NobodyIsHere
Veteran Member
- Joined
- Dec 21, 2006
- Messages
- 2,403
Hi, sorry for the necroposting but this looks too interesting to pass up. Is anyone still interested in this subject?
It is a relief to see I am not the first person to have caught the 8086 16-bit "clean sheet design" bug. So I'd like to resurrect this thread from 2013 which is very similar to what I am attempting at RBC.
In short, a clean sheet 8086 design straight from the Intel datasheets and application notes. A processor section with 8086 CPU, 8087 numeric coprocessor, dual 8089 IO processors, master & slave 8259 PICs, 8254 PIT, 8284 clock generator, 8288 bus controller, and 8289 bus arbiter. A 16 bit wide memory partition with 1 MB SRAM and 1 MB Flash (2 512KB banks). Peripherals partition with DUART, RTC, IDE, FDC, & dedicated PIC slave.
Since the ISA bus itself it rather a kludge, use the Intel designed and recommended Multibus standard for interfaces. Start initial build as an integrated SBC (everything on one PCB) but divided into partitions. Once the design is verified as sound, break out the partitions into separate boards and use a passive backplane with Multibus signals. Really haven't figured out the details of the Multibus interface yet especially the physical connector and board size. The Multibus standard uses a large 86 pin connector (P1) and a 12"x6" board format which is really neat but rather massive leading to very expensive PCBs. Presently I am thinking maybe something a bit smaller and cheaper along the lines of PC104 but using Multibus instead.
The intention is to avoid PC backwards compatibility as it tends to drive the hardware requirements (ROMs permanently in memory map, memory mapped video, bizarre DMA, etc. )
Regarding software, I am thinking FreeDOS would be a good starting point because it is open source and can be modified. However since the hardware is quite different from the IBM PC standard it won't be really backward compatible with the IBM PC. Especially the expectation for ROMs permanently in memory and memory mapped video. There are other PC-like implementations which use the serial port for console (SBC-188 and JM's S-100 8086 CPU board at least).
The concept has advanced past the "concept" stage into initial schematic and PCB design. Actually I think we are not too far away from some prototype PCBs. So is there any residual interest is such a project?
It is a relief to see I am not the first person to have caught the 8086 16-bit "clean sheet design" bug. So I'd like to resurrect this thread from 2013 which is very similar to what I am attempting at RBC.
In short, a clean sheet 8086 design straight from the Intel datasheets and application notes. A processor section with 8086 CPU, 8087 numeric coprocessor, dual 8089 IO processors, master & slave 8259 PICs, 8254 PIT, 8284 clock generator, 8288 bus controller, and 8289 bus arbiter. A 16 bit wide memory partition with 1 MB SRAM and 1 MB Flash (2 512KB banks). Peripherals partition with DUART, RTC, IDE, FDC, & dedicated PIC slave.
Since the ISA bus itself it rather a kludge, use the Intel designed and recommended Multibus standard for interfaces. Start initial build as an integrated SBC (everything on one PCB) but divided into partitions. Once the design is verified as sound, break out the partitions into separate boards and use a passive backplane with Multibus signals. Really haven't figured out the details of the Multibus interface yet especially the physical connector and board size. The Multibus standard uses a large 86 pin connector (P1) and a 12"x6" board format which is really neat but rather massive leading to very expensive PCBs. Presently I am thinking maybe something a bit smaller and cheaper along the lines of PC104 but using Multibus instead.
The intention is to avoid PC backwards compatibility as it tends to drive the hardware requirements (ROMs permanently in memory map, memory mapped video, bizarre DMA, etc. )
Regarding software, I am thinking FreeDOS would be a good starting point because it is open source and can be modified. However since the hardware is quite different from the IBM PC standard it won't be really backward compatible with the IBM PC. Especially the expectation for ROMs permanently in memory and memory mapped video. There are other PC-like implementations which use the serial port for console (SBC-188 and JM's S-100 8086 CPU board at least).
The concept has advanced past the "concept" stage into initial schematic and PCB design. Actually I think we are not too far away from some prototype PCBs. So is there any residual interest is such a project?
NobodyIsHere
Veteran Member
- Joined
- Dec 21, 2006
- Messages
- 2,403
Chuck could you please explain this concept more fully regarding 8086 directly addressing 4MB memory space? It seems to me that there are only 20 address pins so how do you get to 22 address lines? Also BHE & AO work in tandem to allow 8 bit addressing which precludes (I think) a pure 16 bit word memory space. Would you please point me to the explanation in the datasheet or application note?