PDA

View Full Version : picked up a cheap 8086!



Mike Chambers
October 16th, 2006, 09:27 PM
theres this cool store about 20 minutes from here called Gateway Electronics... i haven't been there in years so i decided to go down and see if i could find anything cool.

sure enough, i saw a complete 8086 motherboard priced at $2.50... i HAD to pick it up. 8086's are more rare than 8088's, and the 16-bit bus is nice. haven't turned it on yet, but i'll dig up a power supply for it in the morning and see how (if at all) it works.

this thing is freakin' huge, too :eek:

here's hoping it works! that'd be fun to mess around with. there's no identifiers for a model or brand that i've found yet, but it says it was made in taiwan.

CPU is a geniune Intel, btw.

IBMMuseum
October 17th, 2006, 08:15 AM
...8086's are more rare than 8088's, and the 16-bit bus is nice...
Since it is less economical to use an 8086 in a project they tend to be lower priced from electronic suppliers (Jameco, etc.) too. It is said that one reason IBM went with an 8088 CPU in the PC was because they had used an 8086 in the DisplayWriter systems & that software would then be easy to port. On the 5251 terminals (notice the similiarity in numbering these System/3x terminals to the PC model numbers) and later 3180 terminals had 8085 CPUs.

...CPU is a geniune Intel, btw.Strangely the 8086 didn't have one particular bug that was present on the early 8088s. If there is only the 1978 copyright date (not 1981, where it was fixed) the 8088 has the bug. Other manufacturers and higher than the 5MHz speed (but those are also marked with the later copyright date) from Intel are not affected.

Speculation that the 8087 & 8088 had to be "matched" happened when IBM would commonly send an 8088 replacement with the ordered 8087 when the customer added the NPU option. It was just an easier method to replace what may have been a faulty CPU in some situations. I've got a couple of these early 8088 & they are far less common to find.

Chris2005
October 17th, 2006, 08:41 AM
what bug are we talking about?

Mike...howz about a picture? :)

Mike Chambers
October 17th, 2006, 07:48 PM
Since it is less economical to use an 8086 in a project they tend to be lower priced from electronic suppliers (Jameco, etc.) too. It is said that one reason IBM went with an 8088 CPU in the PC was because they had used an 8086 in the DisplayWriter systems & that software would then be easy to port. On the 5251 terminals (notice the similiarity in numbering these System/3x terminals to the PC model numbers) and later 3180 terminals had 8085 CPUs.
Strangely the 8086 didn't have one particular bug that was present on the early 8088s. If there is only the 1978 copyright date (not 1981, where it was fixed) the 8088 has the bug. Other manufacturers and higher than the 5MHz speed (but those are also marked with the later copyright date) from Intel are not affected.

Speculation that the 8087 & 8088 had to be "matched" happened when IBM would commonly send an 8088 replacement with the ordered 8087 when the customer added the NPU option. It was just an easier method to replace what may have been a faulty CPU in some situations. I've got a couple of these early 8088 & they are far less common to find.

yeah what bug are you talking about? i didn't know about this. i have an 8088 too, and its a fujitsu clone CPU. says (c) fujitsu '81 under the (c) intel '78

oh speaking of my 8088, thanks to the ultra-leet Terry Yager from this board i should probably be receiving an 8-bit floppy controller for it in the mail tomorrow :)

then i can *FINALLY* use it.

Mike Chambers
October 17th, 2006, 07:49 PM
what bug are we talking about?

Mike...howz about a picture? :)

ok, yz i'll take one... i'll post it in a bit. i'll get my digital cam and get a shot of it.

btw, i dug up a an old power supply this afternoon and hooked it up... it turned right on! :)

Terry Yager
October 17th, 2006, 08:24 PM
thanks to the ultra-leet Terry Yager

Aww, cut it out...you're embarassing me. Actually, I had an extra one because I'm replacing it with an UltraSuperMega-leet CompatiCard II (as soon as I get around to building my 5155 back up again).

--T

Mike Chambers
October 17th, 2006, 09:23 PM
Aww, cut it out...you're embarassing me. Actually, I had an extra one because I'm replacing it with an UltraSuperMega-leet CompatiCard II (as soon as I get around to building my 5155 back up again).

--T

cool. that will be very nice.

i want an IBM model 1337. i'm sure glad i have an 8-bit ISA network card laying around, so when i make a boot disk for that 8088 on a floppy i can put the MS net drivers for DOS on it and use some network drives for storage rather than swapping out floppies every 10 seconds. i hope CPU overhead for that isn't too much for a CPU that old. it can run at 8 MHz when turbo's on so i guess we'll see.

IBMMuseum
October 17th, 2006, 10:18 PM
yeah what bug are you talking about? i didn't know about this. i have an 8088 too, and its a fujitsu clone CPU. says (c) fujitsu '81 under the (c) intel '78...
Since you have a CPU second-sourced from Intel it is not supposed to have this particular bug. There is a test I will also list at the end of the description. The source is Mueller's "Upgrading and Repairing PCs, 2nd Edition" (page 422 for the copy I have):
"Early 8088s: A bug in some early 8088 microprocessors allowed interrupts to occur after a program changed the stack segment register. An interrupt usually is not allowed until the instruction after the one that changes the stack segment register. This subtle bug might cause problems in older systems. Most programmers have adopted coding procedures that work around the bug [I don't know how this is done], but you have no guarantee that these procedures are in all software. Another problem is that the bug might affect chip operation with an 8087 math coprocessor. Approxiamately 200,000 IBM PC units (early units sold during 1981 and 1982) were manufacturered with the defective chip..."

[comments on the 8088/8087 replacement program I paraphrased earlier]

[Section on visual detection, which is to see only the 1978 copyright date on an Intel 8088 CPU (and nothing faster than 5MHz). Text about the 8088 licensing program started after the bug had been found & fixed]

Test (also a reprint from the same source]:
Start DEBUG and run the following commands:

-A 100
MOV ES, AX
INC AX
NOP
-T
[All registers are displayed, where you want to look at the value in the AX register. If it is "0000" your 8088 CPU has the bug. AX = "0001" means your CPU passes the test & does not have the bug. To exit DEBUG type:]
-Q

He remarked at the time of printing (1992) there was a free replacement program offered by Intel. Call Intel and act shocked after they stop laughing. Ask if they will pay you the $10 or so to get it from Jameco, with the shipping.

michal
October 19th, 2006, 03:52 AM
Speculation that the 8087 & 8088 had to be "matched" happened when IBM would commonly send an 8088 replacement with the ordered 8087 when the customer added the NPU option. It was just an easier method to replace what may have been a faulty CPU in some situations. I've got a couple of these early 8088 & they are far less common to find.

Ooh, that would explain much... I've seen a "genuine IBM 8087 upgrade" on eBuy and it was indeed an IBM-stamped 8087 along with... an AMD 8088! And I thought - WTF ? Is the guy kidding or what ? So now the joke wasn't on the seller's part...

michal
October 19th, 2006, 04:24 AM
8086's are more rare than 8088's, and the 16-bit bus is nice.

Yeah, what's the difference, anyway? I mean, do you actually SEE the 16-bit bus on the board (that would mean 16-bit ISA instead of the usual 8-bit XT bus) ? I can't quite grasp the difference between the 8-bit/16-bit bus of the 8086/8. My 8086 board has XT bus slot only... Well the CPU pins are different but who cares... And the speed - can someone point at a table containing the cycles per instructions on both 8086 and 8088 ? I've a table that goes from 8088 up to pentium BUT skips 8086 (a yet less common 80186 is there)...


this thing is freakin' huge, too :eek:

And I got the most elegant 8086 board on this planet ;) It's compact, has an onboad video port, ps/2 keyboard+mouse ports, a HDD and FDD controller also. And it's a genuine IBM from a genuine IBM 8530, year 1987 :cool: .

mbbrutman
October 19th, 2006, 06:02 AM
On an XT class machine with an 8086 onboard you are probably not going to see any difference in the ISA slots. Maybe a specific manufacturer of 8086 based clones sold a card that went in a special slot, but to be compatible with the rest of the universe it still needs 8 bit PC bus slots.

The real benefit is in access to memory. If you look closely, memory on the motherboard should be on a 16 bit bus as opposed to a normal 8088 motherboard where memory is on an 8 bit bus. This theoretically makes the bandwidth to memory two times faster than for an 8088.

Instruction timings once in the chip are exactly the same as for an 8088, which is why you don't see a separate table for the 8086. Memory and I/O for the 8086 should be faster. (I/O will not be faster if it has to use an 8 bit bus for compatibility.)

One thing that programmers have to be aware of when moving from an 8 to a 16 bit bus is word alignment. Almost every CPU ever made is more efficient when you align memory words correctly. In the case of the 8086, grabbing 16 bits unaligned is just as fast as doing it on an 8088 because it has to generate two memory references. An aligned transfer of 16 bits would do all 16 bits in one shot.

IBMMuseum
October 19th, 2006, 09:17 PM
...and it was indeed an IBM-stamped 8087...
That would go well with my IBM-stamped [Intel] 8088:

IBMMuseum
October 19th, 2006, 09:31 PM
Yeah, what's the difference, anyway? I mean, do you actually SEE the 16-bit bus on the board (that would mean 16-bit ISA instead of the usual 8-bit XT bus) ? I can't quite grasp the difference between the 8-bit/16-bit bus of the 8086/8. My 8086 board has XT bus slot only... Well the CPU pins are different but who cares... And the speed - can someone point at a table containing the cycles per instructions on both 8086 and 8088 ? I've a table that goes from 8088 up to pentium BUT skips 8086 (a yet less common 80186 is there)....
There is an RS/6000 XStation 130 (designed to RIPL over a network) that has an 8086 as the main CPU, with a single 16-bit microchannel slot that will only accept a few types of adapters...

And I got the most elegant 8086 board on this planet ;) It's compact, has an onboad video port, ps/2 keyboard+mouse ports, a HDD and FDD controller also. And it's a genuine IBM from a genuine IBM 8530, year 1987 :cool: .
I wouldn't call the Model 30 8086 planar "compact" compared to say the Model 25 8086 planar. Both are 8086 8MHz. And to answer your question above, are stated to be about 2.5 times faster than the 8088 4.77MHz in the PC & XT.

At almost double the clock rate is where most of the boost would come into play. The cycles per instruction are the same for the 8086 & 8088, but as said elsewhere in the thread it is a matter of memory access too. I have heard that the 8086 had a slightly larger pre-fetch queue than the 8088, but haven't been able to confirm that.

michal
October 20th, 2006, 09:43 AM
There is an RS/6000 XStation 130 (designed to RIPL over a network) that has an 8086 as the main CPU, with a single 16-bit microchannel slot that will only accept a few types of adapters...

Cool :D But besides, I know now why they only put XT bus on 8086 boards... Because 16-bit slots have 24 address lines. In other words, there's just no dedicated slot for the 8086. They could put the ISA (AT) slots in 8530 but then some cards would work and some not.


The cycles per instruction are the same for the 8086 & 8088, but as said elsewhere in the thread it is a matter of memory access too. I have heard that the 8086 had a slightly larger pre-fetch queue than the 8088, but haven't been able to confirm that.

I heard 3 versions:
1. 8086 and 8088 have 4 bytes PQ (while v20/v30 have six)
2. 8088 = 4b PQ, 8086 = 6b PQ
3. the other way round (http://heim.ifi.uio.no/~stanisls/helppc/cpu.html)

IBMMuseum
October 20th, 2006, 09:54 AM
Cool :D But besides, I know now why they only put XT bus on 8086 boards... Because 16-bit slots have 24 address lines. In other words, there's just no dedicated slot for the 8086. They could put the ISA (AT) slots in 8530 but then some cards would work and some not...
Actually most ISA motherboards & adapters were usually just decoded out to about 12 address lines. If you look through with an I/O viewer you can see the adapters repeating every so often. Microchannel & later busses typically stipulate that the address lines for the entire bus be decoded.

michal
October 24th, 2006, 09:06 AM
The definitive quote (in all it's un-cut glory) about the 8086/8 prefetch queue and difference et al, from an official intel 8088 specsheet:

"Internally, there are three differences between
the 8088 and the 8086. All changes are related to
the 8-bit bus interface.

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.
To further optimize the queue, the prefetching algorithm
was changed. The 8088 BIU will fetch a
new instruction to load into the queue each time
there is a 1 byte hole (space available) in the
queue. The 8086 waits until a 2-byte space is
available.
The internal execution time of the instruction set
is affected by the 8-bit interface. All 16-bit fetches
and writes from/to memory take an additional
four clock cycles. 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."

IBMMuseum
October 24th, 2006, 03:05 PM
The definitive quote (in all it's un-cut glory) about the 8086/8 prefetch queue and difference et al, from an official intel 8088 specsheet:

"Internally, there are three differences between
the 8088 and the 8086. All changes are related to
the 8-bit bus interface.

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.
To further optimize the queue, the prefetching algorithm
was changed. The 8088 BIU will fetch a
new instruction to load into the queue each time
there is a 1 byte hole (space available) in the
queue. The 8086 waits until a 2-byte space is
available.
The internal execution time of the instruction set
is affected by the 8-bit interface. All 16-bit fetches
and writes from/to memory take an additional
four clock cycles. 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."

This is exactly as I heard the 8086/8088 pre-fetch queues. I've seen at least one routine to check the depth of the pre-fetch (think self-modifying code), mainly to tell the difference (in software) between two CPUs of the same level that had different external (data) bus widths.

Mostly it would come into play on the 8086 vs. 8088 and 80186 vs. 80188. The 386SX could be told from the 386DX by the address bus width (24-bit compared to 32-bit) by seeing if the data above 16Mb matched that at the start of RAM (and with certain other systems there is an easier check, see below). All NEC CPUs (ie V20, V30, V40, V50) would be harder to tell from each other if the same pre-fetch queue size as their different counterpart (there is an easy way to tell from the Intel CPUs they replace).

If it were that all clone manufacturers had followed IBM's lead, encoding the BIOS model value as FAh for all 8086-based systems (which was just the base PS/2 Model 25 & Model 30 for IBM), with 8088-based units being FFh (PC), FEh or FBh (XT, or systems like the 3270 PC or Portable PC based on the XT motherboard), FDh (PCjr), or F9h (PC Convertible). Of course this is "8086 or a comparable replacement" (not knowing I have an NEC V30 in my Model 30, or for the 286/386 upgrade boards that could be in a PC or XT) with a hard-coded BIOS value. I see where I have to do an update (the registers that point at the data block), but the data is listed at http://www.IBMMuseum.com/Interrupts/INT15h/INT15hC0.html.

On (almost all of) the IBM 386SX & 386DX PS/2 models there was an ability to get a BIOS CPUID value (http://www.ibmmuseum.com/Interrupts/INT15h/INT15hC9.html). This would even report if the CPU had been upgraded. Very few other BIOS writers followed that lead before midway through the 486 production cycle Intel started making the CPUID available on the fly in CPU opcodes.

Chris2005
October 24th, 2006, 03:24 PM
o man Mike where's the picture???

IBMMuseum
October 24th, 2006, 04:08 PM
This is exactly as I heard the 8086/8088 pre-fetch queues...

Others I have heard of:

286: 8 bytes (but I thought I saw 12 in the Intel 286 manual)
386: 16 bytes (unknown if that is all versions of the 386 CPU)
486: 32 bytes

IBMMuseum
October 24th, 2006, 06:02 PM
...I see where I have to do an update (the registers that point at the data block), but the data is listed at http://www.IBMMuseum.com/Interrupts/INT15h/INT15hC0.html...

Update done...

Trixter
March 16th, 2007, 09:51 PM
Most programmers have adopted coding procedures that work around the bug [I don't know how this is done]


There were two bugs. The one you're referring to is that a MOV to SS (the stack segment) did NOT disable interrupts for the next instruction, meaning that you could get an interrupt in the middle. This is bad, because the interrupt will try to set up it's own stack (something you were trying to do with the MOV SS) and the stack is unlikely to recover, taking the machine with it. The workaround was this:


CLI
MOV SS,DX
MOV SP,AX
STI

ie. disable interrupts before you do the switch, then re-enable them when done. Which sucks, but is a good practice that most people were doing anyway because they didn't know that MOV SS,reg was a special case that was supposed to disable interrupts. Hell, I didn't even know that until I started researching the bug.

But not all was good in Intel land: If you didn't know the state of the interrupt going in, then you preserved it like this:


PUSHF
POP BX
CLI
MOV SP,word ptr [my_stack]
MOV SS,word ptr [my_stack+2]
PUSH BX
POPF

...except there was a second bug in the original 8088 in the POPF opcode which meant that, even if the state was still CLI after the POPF, interrupts would still be enabled for a single cycle! Try tracking THAT bug down in your program! So the workaround, which is just st00pid, is to fake POPF using IRET. BTW, the odds of this particular bug cropping up is somewhere in the neighborhood of 1 in 5 million, and only when you switch stacks, so it is such a longshot that I never bother in my own code.

But wait, there's more! There's a THIRD bug where, if you try to use a segment override on MOVS or LODS (ie. so you can attempt to use something other than DS as the source; I'm not sure that behavior is documented and I've never tried it) and an interrupt fires off during, say, a REP MOVSW, it stores the WRONG return address. This was fixed in the 80186, I think.



Test (also a reprint from the same source]:
Start DEBUG and run the following commands:

-A 100
MOV ES, AX
INC AX
NOP
-T
[All registers are displayed, where you want to look at the value in the AX register. If it is "0000" your 8088 CPU has the bug. AX = "0001" means your CPU passes the test & does not have the bug. To exit DEBUG type:]
-Q


That doesn't make any sense at all, unless the nature of the INT 3 opcode debug puts into the program flushes the bug out. Are you use the example didn't have MOV SS instead?

IBMMuseum
March 16th, 2007, 10:17 PM
...That doesn't make any sense at all, unless the nature of the INT 3 opcode debug puts into the program flushes the bug out. Are you use the example didn't have MOV SS instead?

Positive. And that code is tested between the 1978 and 1981 8088s I have. It works exactly as said.

Trixter
March 16th, 2007, 11:56 PM
Wow. That is really going to take some research on my part to figure out why that is working. Which means I'll probably run to Terje with my tail between my legs and beg for help :-)

Mike Chambers
March 17th, 2007, 11:50 AM
Wow. That is really going to take some research on my part to figure out why that is working. Which means I'll probably run to Terje with my tail between my legs and beg for help :-)

hey trixter, are you the same trixter that wrote 8088 corruption? that program is awesome! :D

Trixter
March 19th, 2007, 12:42 PM
Yes, I am, and thanks :-)

Trixter
March 19th, 2007, 12:43 PM
Wow. That is really going to take some research on my part to figure out why that is working. Which means I'll probably run to Terje with my tail between my legs and beg for help :-)

I figured it out. Details are at a recent blog post at trixter.wordpress.com but the short answer is: Interrupts are supposed to be disabled not only on a MOV SS but on a MOV to *ANY* segment register. I didn't know that, and easily explains why the code snippet works.

Mike Chambers
March 20th, 2007, 09:52 PM
Yes, I am, and thanks :-)

i am not exactly on your level, but i have done some programming on my XT clones. i wrote what i think is a pretty nifty IRC client for DOS if you're interested in that. (DCC file receive and all! also an integrated help system, drop down menus, and log scrolling)

there were zero good IRC clients for DOS machines out there, so i thought i'd have a go at it. maybe you'll find it useful.

http://www.rubbermallet.org/download/lirc11.zip <---- direct download of it including source

(note: you'll want at least a CGA card but it will "work" with a monochrome)

Trixter
March 21st, 2007, 12:48 PM
I've had rubbermallet open in my browser for 4 days now, I just haven't had time to give it a shot :)

Don't worry about being "at my level", I only recently got to this level. 20 years ago I coded like crap. You're the one with a working IRC program, not me :-)

Other than #vc, any other servers/nets/channels I should try with the program?

(It's been a decade since I was on IRC, how do I find a server?)

Mike Chambers
March 21st, 2007, 06:41 PM
I've had rubbermallet open in my browser for 4 days now, I just haven't had time to give it a shot :)

Don't worry about being "at my level", I only recently got to this level. 20 years ago I coded like crap. You're the one with a working IRC program, not me :-)

Other than #vc, any other servers/nets/channels I should try with the program?

(It's been a decade since I was on IRC, how do I find a server?)

20 years ago i was in diapers lol. (i'll be 23 in april)

efnet is a decent network. i dont really go to too many different servers. dalnet used to be good but now its like all spammers and idlers. there are a plenty of other networks out there though.

here's a good listing of servers: http://www.irchelp.org/irchelp/networks/

just so you know, the program gets kind of bogged down in a real busy channel if you're on an 8088-based computer. if you have a 286 or better sitting around it will be more than fast enough though.