Home » RBC Forums » General Discussion » 8086 maximum mode SBC
| 8086 maximum mode SBC [message #2578] |
Sun, 30 April 2017 11:03  |
lynchaj
Messages: 1079
Registered: June 2016
|
Senior Member |
|
|
Hi
I've been mulling over an 8086 maximum mode SBC based on the Intel datasheet. It is simple computer with just CPU, RAM, ROM, & DUART. No PIC, PIT, DMA, and no wait state generator. Take a look at the schematic and tell me what you think.
The PCB is fairly small & 2 layer 5.525" x 4.700" which I am guessing would be fairly inexpensive to build. All the parts a PTH so easy construction.
Note1: I noticed there was a problem with the memory decoder so I fixed it and updated the schematic. Also included the memory decode truth table and the PCB layout file.
Note2:Argh! I thought about the IO decoder some more and realized if I made some minor changes I could use left over gates and eliminate the second 74LS688 so I updated the schematic and PCB layout (again).
[Updated on: Sun, 30 April 2017 14:12] Report message to a moderator |
|
|
|
|
|
| Re: 8086 maximum mode SBC [message #2584 is a reply to message #2583] |
Mon, 01 May 2017 08:07  |
jcoffman
Messages: 332
Registered: October 2015
|
Senior Member |
|
|
Andrew,
Before the NS32202 was put on the MF/PIC board, I did a series of experiments with the NEC 8289A. Perhaps it is easy to interface it to 80x86 systems, but I was unable to get it to work with a Z80. Part of the problem was the 8289 data sheet -- clear as mud.
Note that the 8086, in taking an interrupt, must read the 8289 twice. This seems to me to be a very odd requirement, and may have been part of the reason I could not use the 8289 on a Z80.
I was looking at the 8289 because I felt it was easier to source than the NS32202 chip, and the latter worked fine on Z80, NS32000, and later on Motorola 68000's. By buying the '202 in bulk and providing it with the board, the chip sourcing problem was solved.
===============================================
BTW: if we can get the VGA3 board to work satisfactorily, I've considered a re-spin of the SBC-188, mainly to add full memory (2 x 512K chips). The board is known to run as it is at 25mhz, but needs to be slowed to 16mhz to access off-board 4MEM. A re-spin needs to address the wait-state problem with off-board accesses.
===============================================
RE: pure 8086 & software
The SBC-188 was intended to be a non-MSDOS computer entirely. However, the lesson learned is that one wants to run available s/w, and MSDOS is the most available. The earliest revision of the SBC-188 (timer fix), made it a little more like a PC. There are several other things to be done to make it even more like a PC, and these would be incorporated into any re-spin. However, the '188 will NEVER be a total PC-clone. An 8086 could be. Plan on running MSDOS.
============================================================ ===
For running Linux on a home-built PC, have you looked at Mark Williams' COHERENT. It will run on a 386, with relatively little memory. It is more a clone of System V, since it pre-dates Linux' wide acceptance. It is now open source.
--John
|
|
|
|
|
|
| Re: 8086 maximum mode SBC [message #2586 is a reply to message #2585] |
Mon, 01 May 2017 09:00 |
lynchaj
Messages: 1079
Registered: June 2016
|
Senior Member |
|
|
Hi John
Would you be interested in a re-design of the SBC-188 to incorporate an 8086, PIC, PIT, and DMA? It is probably too big to put on a 160x100mm Euro board but it might fit on a double stack board (like the uPD7220). If we were to go down that road though, I would like to implement the PIC (and the PIT) differently than the IBM PC did. I think the PIC could support 256 different interrupts with level detection vs. edge detection along with a different interrupt service routine. Also the PIT could have three separate interrupts (one for each timer channel). With 256 interrupts we could assign them with abandon rather than hoard them like you have to do with the current IBM PC/ISA architecture. Every device could have its own unique interrupt or even more than one if needed for separate modes, etc.
I am thinking the PIC would receive multiple interrupts at once, read them as levels, update its internal registers, and call the CPU via the INTR line. Then the CPU passes the INTA line back to the PIC and reads the internal PIC registers to assess which interrupt was called (status of IRR) then clears the PIC. The CPU would handle the rest via its interrupt service routine. Does that make sense? It's a theory I've held for a long time but never had a chance to experiment with.
Thanks, Andrew Lynch
PS, the 8259A datasheet says the PIC supports level detection and multiple interrupt requests. From the datasheet:
The events occur as follows in an 8086 system:
1. One or more of the INTERRUPT REQUEST lines (IR7±0) are raised high, setting the corresponding IRR bit(s).
2. The 8259A evaluates these requests, and sends an INT to the CPU, if appropriate.
3. The CPU acknowledges the INT and responds with an INTA pulse.
4. Upon receiving an INTA from the CPU group, the highest priority ISR bit is set and the corresponding IRR bit is reset. The 8259A does not drive the Data Bus during this cycle.
5. The 8086 will initiate a second INTA pulse. During this pulse, the 8259A releases an 8-bit pointer onto the Data Bus where it is read by the CPU.
6. This completes the interrupt cycle. In the AEOI mode the ISR bit is reset at the end of the second INTA pulse. Otherwise, the ISR bit remains set until an appropriate EOI command is issued at the end of the interrupt subroutine.
[Updated on: Mon, 01 May 2017 09:04] Report message to a moderator |
|
|
|
|
|
|
|
| Re: 8086 maximum mode SBC [message #2589 is a reply to message #2588] |
Mon, 01 May 2017 10:17 |
jcoffman
Messages: 332
Registered: October 2015
|
Senior Member |
|
|
lynchaj wrote on Mon, 01 May 2017 09:10
<snip> ...
Unfortunately the software written for the IBM PC had to be written "on the metal" as to extract out evs) areery last bit of performance. Why application software is dependent on ISR implementations is mind-boggling to me.
I think IBM wanted the BIOS to insulate applications from the underlying h/w, but seeking speed on a 4.77mhz 8088, vendors had to talk directly to the h/w. This IBM-intentded BIOS insulation extended to the WAIT and POST calls in the early PC/AT's. These calls were intended to support multi-programming / multi-tasking operating systems. Later BIOS's did not support these calls, because the OS's (Windows 3.1, OS/2, e.g.) all wanted to do the multi-tasking on their own.
In my opinion, it was subtle incompatibilities that doomed the IBM PS/2. About the only good thing to come out of it was the smaller keyboard and mouse connectors. :)
--John
[Updated on: Mon, 01 May 2017 12:41] by Moderator Report message to a moderator |
|
|
|
| Re: 8086 maximum mode SBC [message #2595 is a reply to message #2589] |
Mon, 01 May 2017 15:43 |
Sergey
Messages: 236
Registered: October 2015
Location: Portland, OR
|
Senior Member |
|
|
A "properly designed" 8086 board is an interesting idea. Here are some of my wishes/additions:
1. Integrate an 8087, and a couple of 8089's (otherwise what's the point of using the Maximum Mode?). Use the latter ones for DMA purposes...
2. Make it a multi-processor system (Multibus-style?!) using an 8289 bus arbiters?
3. Integrate an 8259A PIC and an 8254 PIT.
4. Think about some non-DOS OS to run on it. Some kind of UNIX-like system? Xenix? Minix?
[Updated on: Tue, 02 May 2017 02:51] by Moderator Report message to a moderator |
|
|
|
|
|
|
|
| Re: 8086 maximum mode SBC [message #2600 is a reply to message #2595] |
Tue, 02 May 2017 03:10 |
lynchaj
Messages: 1079
Registered: June 2016
|
Senior Member |
|
|
skiselev wrote on Mon, 01 May 2017 18:43A "properly designed" 8086 board is an interesting idea. Here are some of my wishes/additions:
1. Integrate an 8087, and a couple of 8089's (otherwise what's the point of using the Maximum Mode?). Use the latter ones for DMA purposes...
2. Make it a multi-processor system (Multibus-style?!) using an 8289 bus arbiters?
3. Integrate an 8259A PIC and an 8254 PIT.
4. Think about some non-DOS OS to run on it. Some kind of UNIX-like system? Xenix? Minix?
Now that's a good idea! Check out the datasheet for the 8289, it is right along these lines. Includes Multibus signal for multiprocessor applications.
Agree 100% on the 8087 and especially the 8089(s). What a difference those would make to offload the IO to its own processor.
Yes, not DOS although maybe FreeDOS would be a good intermediate point. Start with a monitor and work out all the issues with the hardware and then port an OS. Maybe Coherent? I don't know.
I looked over the 8086 maximum mode SBC design last night and added the 8259A PIC and 8254 PIT. After reading the datasheets they were fairly easy to add since they require almost no additional glue logic or anything other than a few pull-up/pull-down resistors. I'd like to build the core 8086 maximum mode CPU first and make sure that's working. Then integrate in the more sophisticated 8087, 8089, 8289, etc. I have some more to do tonight and will update the schematic & PCB layout.
[Updated on: Tue, 02 May 2017 03:10] Report message to a moderator |
|
|
|
| Re: 8086 maximum mode SBC [message #2601 is a reply to message #2600] |
Tue, 02 May 2017 04:26 |
lynchaj
Messages: 1079
Registered: June 2016
|
Senior Member |
|
|
Wow, where did you get those application notes? Very interesting. Much better than the datasheets alone. They answered a lot of questions.
I will add in the 8087, 8289, and 8089 chips tonight. It looks like those can be left as empty sockets and the chips added later as testing progresses.
It looks like with the 8289 and the 8089 installed it would support multiprocessing. A simple form of that would be to export the "system bus" to some pin headers and make it "stackable" so multiple SBCs could work in parallel. Very interesting.
What's even more interesting is the concept extends to the PIC as well since they can be "chained" in a master/slave configuration. Need to make some adjustments to my schematic though.
[Updated on: Tue, 02 May 2017 04:32] Report message to a moderator |
|
|
|
|
|
| Re: 8086 maximum mode SBC [message #2605 is a reply to message #2604] |
Tue, 02 May 2017 09:30 |
lynchaj
Messages: 1079
Registered: June 2016
|
Senior Member |
|
|
Thinking about this some more, I think what I'll do is move the PIT and PIC (master) and add a PIC (slave) to the CPU sheet. The CPU + IOP + numeric coprocessor + PIT use up at least six interrupts alone and are high priority. I think they warrant their own PIC (slave) connected to the PIC (master) IRQ0.
Then at a dedicated PIC (slave) just for IO peripherals. Start thinking about making that a separate board. Same with memory. They are already sub-schematics so that should be pretty easy.
Whatever future expansion bus would need to include the Multibus signals from the 8289 as well as the IRQs from the PIC (master) and the CAS lines. The insight is the PIC (master) and PIT are really part of the core CPU and not really peripherals in the usual sense.
This is a pretty big rework and it might take some time to get it all sorted out. I'll post an updated schematic when its ready.
[Updated on: Tue, 02 May 2017 09:35] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: 8086 maximum mode SBC [message #2626 is a reply to message #2619] |
Thu, 04 May 2017 05:12 |
lynchaj
Messages: 1079
Registered: June 2016
|
Senior Member |
|
|
jcoffman wrote on Wed, 03 May 2017 15:39lynchaj wrote on Wed, 03 May 2017 10:50If you want to go low cost, then we could use pin headers but we'd need a lot of them. At least 100 by my counts. I think card edge connectors suck. DIN 41612 much better. Euroboard (160x100 mm) is too small for this technology.
Consider the 160mm x 233.35mm Eurocard format used by VME.
With the 96-pin DIN 41612 on the right connector (landscape format), the ECB bus could be supported in the Siemens 6508 chassis.
Yes, VME is an excellent design and just about the right size too.
The thing is I think we'll need a lot of bus pins. Just the bare minimum, 6 VCC, 6 GND, 20 address (+BHE#), 16 data, 12 interrupt related, 12 DMA related, plus at least a couple dozen bus arbitration, controller, and CPU control signals. It fully loads a 96 pin connector and that's assuming I accounted for everything.
|
|
|
|
|
|
| Re: 8086 maximum mode SBC [message #2644 is a reply to message #2643] |
Fri, 05 May 2017 04:24 |
lynchaj
Messages: 1079
Registered: June 2016
|
Senior Member |
|
|
Hi
There are a couple of questions I have on the 8086 MM SBC design. Maybe someone can help me out?
1. The 8289 bus arbiter requires a LOCK# signal from the processor to tell it when to not give up the external bus. OK, that's fine. However both IOPs also have LOCK# signals. The 8086 processor and the IOPs all output LOCK#. Obviously I can't tie all three outputs together so do I just connect the processor LOCK# to the 8289? What happens to the IOP's LOCK# signals? The 8086 datasheet mentions LOCK# goes tristate when in "hold acknowledge". Does that mean it needs a pull-up resistor? KiCAD eeschema choked on tying all three outputs together so I installed option jumpers. The 8086, 8087, and both 8089s can be in control of the local bus at any given time not just the processor so this is confusing to me.
2. DMA on with the IOP is very different than the DMA on the IBM PC. The IBM PC has DRQ, DACK#, and TC on the ISA bus. ISA bus DMA peripherals generally expect all three and DRQ is an output, DACK# is an input, and TC is an input. However on the IOP, DRQ is an input (good), there is no DACK# nor is there a TC. The IOP does have an EXT signal which sounds a lot like a TC except it also is an input. WTF? How is DMA supposed to work if the DMA controller and the DMA peripheral are both sitting around waiting for someone to tell them when the transfer is complete or acknowledge the DMA request? I presume to implement DACK# like a chip select signal and maybe use a latch pin tied to both peripheral TC and IOP EXT to tell the both simultaneously to stop transferring? Whichever processor is in control at the time (CPU or IOP) will have to manually control DACK# and EXT/TC because it won't be automatic. I am going to add an FDC to the design just to see if we can possibly get DMA working. Frankly, it looks like a long shot. The interfaces just don't match up.
Thanks for any insights.
PS, my *theories* for #1 and #2 above are:
#1. CPU is master processor and IOPs are both slaves so only the CPU LOCK# is connected to the bus arbiter. If IOP is in control of the local bus it can't request a LOCK# on its own but must request the CPU to do it. So if an IOP needs exclusive control of the local bus, the CPU had better do it before turning over control to the IOP.
#2. The IOP executes its own little program using its instruction set to manually set up the whole DMA transfer including DACK# and EXT/TC.
[Updated on: Fri, 05 May 2017 04:39] Report message to a moderator |
|
|
|
| Re: 8086 maximum mode SBC [message #2649 is a reply to message #2644] |
Fri, 05 May 2017 11:53 |
lynchaj
Messages: 1079
Registered: June 2016
|
Senior Member |
|
|
Hi
Yesterday there was some discussion about a bus and/or expansion backplane for the 8086 MM SBC project. I was looking at AP-28, appendix A, and the signals on the Multibus P1 connector sure look like a good first try at an expansion bus pins 1-86. I think it would require some additional pins though like the DMA (DRQs, DACKs, TC, EXTs, etc.) and the cascading PICs (CASs). Plus there would be some utility pins like IO_CLK, ROM/RAM#, AEN, RESET#, GATEs, PCLK, CLK, etc. I don't feel its necessary to adopt the Multibus standard out-right especially since the form factor is large (12x6 = 72 square inches) per board and it uses a card edge connector for P1. I think we can do better with a standard DIN 41612 connector. My initial count for pins is 111 so a 128 pin connector would give some breathing room but not enough for say full 32 bit address and data busses.
[Updated on: Fri, 05 May 2017 12:05] Report message to a moderator |
|
|
|
| Re: 8086 maximum mode SBC [message #2654 is a reply to message #2649] |
Sat, 06 May 2017 06:19 |
lynchaj
Messages: 1079
Registered: June 2016
|
Senior Member |
|
|
Hi
The current design has a system bus and should support multiprocessing, however, it is serial multiprocessing. Only a single bus master CPU can be in control of the system bus at a time and since all processors share common resources (memory and IO) it is capable of multi-tasking but not parallel processing. At any given time only a single CPU is executing even if they are sharing the system bus and doing different things. If the 8086 had any sort of L1 cache it would be capable of some parallel processing.
If we want to go to a true parallel processing multiprocessor system, then each processor will need its own resident memory and IO so it can effectively detach from the system bus while the processor is executing its own task. Essentially the 8086 MM SBC as it is now would be modified to add an additional bus controller, address latches, and data buffers.
At this point though I think the best approach is to get the 8086 MM SBC working with its system bus and once all the problems resolved then think about converting the existing system bus into a resident bus and adding a separate system bus.
[Updated on: Mon, 08 May 2017 03:05] Report message to a moderator |
|
|
|
|
|
| Re: 8086 maximum mode SBC [message #2657 is a reply to message #2655] |
Sat, 06 May 2017 14:16 |
davetypeguy
Messages: 41
Registered: November 2015
Location: Chapin, SC
|
Member |
|
|
My time has been pretty tight lately, but I'd be willing to help build and test the design. I am not really experienced with early development testing, but I am trying to learn. I'd
be willing to build and test a board.
If the DIN 41612 96 position connector doesn't provide enough signal pins, the power and ground could be moved to a separate power plug using the 4-pin molex connector used on old IDE
hard drives. It could be run across the back edge opposite the DIN backplane, so you plug in the card, then plug in the power cable. That might also allow higher current to the board.
The 96 pin connectors have the advantage of being plentiful and much cheaper than the 128 pin connectors. The pricing on the 128 connectors would probably be $20+ per pair, so
it would get prohibitive quickly.
Another possibility would be to look at the pci-e x16 connector. It is an edge board connector, but is plentiful, can be found in the < $5 range, and has 164 positions in a narrow
connector. If we went that way, we could leave pins available for future expansion to a 32-bit bus design with support for existing peripheral boards.
|
|
|
|
|
|
| Re: 8086 maximum mode SBC [message #2672 is a reply to message #2670] |
Sun, 07 May 2017 09:24 |
lynchaj
Messages: 1079
Registered: June 2016
|
Senior Member |
|
|
I was thinking that if the 128 pin DIN 41612 pairs are too expensive then there is a cheaper yet method. Use two of the 62 pin card slots (aka 8 bit ISA) which would give 124 pins. That should be sufficient connections for at least Multibus I+. If expansion to 32 bits comes to pass, add another connector.
Multibus P1 connector pins 1-86 + DMA (4 DRQ, 4 DACK#, 4 EXT, TC) + PIC (3 CAS) + IO_CLK + AEN
~104 pins but there are probably more which will reveal themselves later. Full 32 bit requires another 16 data and 12 address
Thanks, Andrew Lynch
[Updated on: Sun, 07 May 2017 10:59] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
Current Time: Sun May 19 13:56:54 PDT 2024
Total time taken to generate the page: 0.00891 seconds
|
RetroBrew Computers Forum
Members
Search
Help
Login
Home
