Can an x86 CPU running in real mode be considered to be basically an 8086 CPU?The start of x86: Intel 8080 vs...
dbcc cleantable batch size explanation
What defenses are there against being summoned by the Gate spell?
Decision tree nodes overlapping with Tikz
How to determine what difficulty is right for the game?
What doth I be?
Mortgage Pre-approval / Loan - Apply Alone or with Fiancée?
High voltage LED indicator 40-1000 VDC without additional power supply
Why doesn't a class having private constructor prevent inheriting from this class? How to control which classes can inherit from a certain base?
Horror movie about a virus at the prom; beginning and end are stylized as a cartoon
Approximately how much travel time was saved by the opening of the Suez Canal in 1869?
How can I prevent hyper evolved versions of regular creatures from wiping out their cousins?
Watching something be written to a file live with tail
Rock identification in KY
Can a vampire attack twice with their claws using Multiattack?
Revoked SSL certificate
Was any UN Security Council vote triple-vetoed?
DC-DC converter from low voltage at high current, to high voltage at low current
Why is 150k or 200k jobs considered good when there's 300k+ births a month?
Important Resources for Dark Age Civilizations?
Today is the Center
Do infinite dimensional systems make sense?
Is it legal for company to use my work email to pretend I still work there?
Two films in a tank, only one comes out with a development error – why?
Convert two switches to a dual stack, and add outlet - possible here?
Can an x86 CPU running in real mode be considered to be basically an 8086 CPU?
The start of x86: Intel 8080 vs Intel 8086?How do you put a 286 in Protected Mode?How do accelerators and CPU cards work on the Apple II?How to use the “darker” CGA palette using x86 Assembly?Examples of operating systems using hardware task switching of x86 CPUsDid the 286 go out of its way to follow the 8088 bus protocol?How did people program for Consoles with multiple CPUs?
When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)? Or are there differences between the two?
cpu x86
New contributor
add a comment |
When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)? Or are there differences between the two?
cpu x86
New contributor
add a comment |
When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)? Or are there differences between the two?
cpu x86
New contributor
When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)? Or are there differences between the two?
cpu x86
cpu x86
New contributor
New contributor
edited 1 hour ago
Stephen Kitt
39.3k8160171
39.3k8160171
New contributor
asked 1 hour ago
user12245user12245
61
61
New contributor
New contributor
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
An x86 CPU running in real mode is intended to be backwards-compatible with an 8086 or 8088, but there do end up being a number of differences, for example:
- newer CPUs run faster (in general);
- newer CPUs add new instructions (and, with the 386, new registers, since the 32-bit registers can be used in real mode);
- instruction timing — the speed of individual CPU instructions — varies from one family to another; some instructions run more slowly on newer CPUs;
- implementation details vary, and in some cases, can affect run-time behaviour — for example, varying prefetch queue lengths mean that self-modifying code may not work on CPUs other than the model it was written for;
- some instructions behave differently — for example,
PUSH SP
on an 8086 incrementsSP
after pushing it, whereas on a 286 it incrementsSP
before pushing it, so the value on the stack is different; - bus interactions (
LOCK
prefixes) behave differently on the 8086/8088 compared to all later CPUs; - illegal opcodes which run without error on the 8086 produce exceptions on later CPUs;
- the 8086 has no instruction length limit, whereas instructions which are too long will produce exceptions on later CPUs;
- segment wraparounds inside an instruction or word access work on the 8086 but trap on later CPUs;
- stack wraparounds work on the 8086 but will shut down a 286 or later;
- divide errors behave differently on the 8086/8088 compared to all later CPUs.
The 8086 also has a few bugs which were fixed in later CPUs, but that generally doesn’t matter — all it means is that the workarounds which were needed on 8086/8088 are no longer necessary on later CPUs. (One example is the handling of interrupted instructions with multiple prefixes.)
Software which is actually affected by differences other than speed is very rare indeed, and you can count on the vast majority of software still technically working on a modern x86 CPU in real mode. Speed is another matter; famously, programs written using Turbo Pascal fail with an “Error 200” on CPUs faster than a 200MHz Pentium, and many games don’t cope well with faster CPUs (but some CPUs can be slowed down in creative ways).
Great write up, except speed issues are not really due a changed/extended ISA - they would occure as well back then when speed up occured - after all, having a 10 MHz 8086 was already in the early 1980s a way to screw programs made for a 4.77 MHz 8088
– Raffzahn
1 hour ago
The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).
– Stephen Kitt
1 hour ago
True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))
– Raffzahn
1 hour ago
add a comment |
When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)?
As so often it depends on your value of 'basically' (and there is no user visible difference between 8086 and 8088 beside speed).
Or are there differences between the two?
Well, it's so far the same, as every (modern) x86 operating in real mode will execute pure 8086 programs¹ adhering to what were legal² instructions³ on the 8086.
At the same time they are able to execute later extensions as well while in real mode. So it is possible to write 32-bit real mode programs, or use additional registers and instructions in real mode.
So a x86 isn't the same but for most parts (and depending on the CPU used) a compatible superset of an 8086.
¹ Lets ignore 'external' hardware differences for this.
² There are a few instructions that changed over time, including basic 8086 ones. They may cause incompatibilities in rare circumstances.
³ There are some non-instruction combinations (i.e. prefixes) that were ignored on 8086 but will throw interrupts on later CPUs or result in addressing errors. This is a classic case of later restrictions on less well defined behaviour (like double segment prefix and the like).
As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?
– Raffzahn
1 hour ago
Have an upvote to balance things out ;-).
– Stephen Kitt
19 mins ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
user12245 is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9588%2fcan-an-x86-cpu-running-in-real-mode-be-considered-to-be-basically-an-8086-cpu%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
An x86 CPU running in real mode is intended to be backwards-compatible with an 8086 or 8088, but there do end up being a number of differences, for example:
- newer CPUs run faster (in general);
- newer CPUs add new instructions (and, with the 386, new registers, since the 32-bit registers can be used in real mode);
- instruction timing — the speed of individual CPU instructions — varies from one family to another; some instructions run more slowly on newer CPUs;
- implementation details vary, and in some cases, can affect run-time behaviour — for example, varying prefetch queue lengths mean that self-modifying code may not work on CPUs other than the model it was written for;
- some instructions behave differently — for example,
PUSH SP
on an 8086 incrementsSP
after pushing it, whereas on a 286 it incrementsSP
before pushing it, so the value on the stack is different; - bus interactions (
LOCK
prefixes) behave differently on the 8086/8088 compared to all later CPUs; - illegal opcodes which run without error on the 8086 produce exceptions on later CPUs;
- the 8086 has no instruction length limit, whereas instructions which are too long will produce exceptions on later CPUs;
- segment wraparounds inside an instruction or word access work on the 8086 but trap on later CPUs;
- stack wraparounds work on the 8086 but will shut down a 286 or later;
- divide errors behave differently on the 8086/8088 compared to all later CPUs.
The 8086 also has a few bugs which were fixed in later CPUs, but that generally doesn’t matter — all it means is that the workarounds which were needed on 8086/8088 are no longer necessary on later CPUs. (One example is the handling of interrupted instructions with multiple prefixes.)
Software which is actually affected by differences other than speed is very rare indeed, and you can count on the vast majority of software still technically working on a modern x86 CPU in real mode. Speed is another matter; famously, programs written using Turbo Pascal fail with an “Error 200” on CPUs faster than a 200MHz Pentium, and many games don’t cope well with faster CPUs (but some CPUs can be slowed down in creative ways).
Great write up, except speed issues are not really due a changed/extended ISA - they would occure as well back then when speed up occured - after all, having a 10 MHz 8086 was already in the early 1980s a way to screw programs made for a 4.77 MHz 8088
– Raffzahn
1 hour ago
The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).
– Stephen Kitt
1 hour ago
True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))
– Raffzahn
1 hour ago
add a comment |
An x86 CPU running in real mode is intended to be backwards-compatible with an 8086 or 8088, but there do end up being a number of differences, for example:
- newer CPUs run faster (in general);
- newer CPUs add new instructions (and, with the 386, new registers, since the 32-bit registers can be used in real mode);
- instruction timing — the speed of individual CPU instructions — varies from one family to another; some instructions run more slowly on newer CPUs;
- implementation details vary, and in some cases, can affect run-time behaviour — for example, varying prefetch queue lengths mean that self-modifying code may not work on CPUs other than the model it was written for;
- some instructions behave differently — for example,
PUSH SP
on an 8086 incrementsSP
after pushing it, whereas on a 286 it incrementsSP
before pushing it, so the value on the stack is different; - bus interactions (
LOCK
prefixes) behave differently on the 8086/8088 compared to all later CPUs; - illegal opcodes which run without error on the 8086 produce exceptions on later CPUs;
- the 8086 has no instruction length limit, whereas instructions which are too long will produce exceptions on later CPUs;
- segment wraparounds inside an instruction or word access work on the 8086 but trap on later CPUs;
- stack wraparounds work on the 8086 but will shut down a 286 or later;
- divide errors behave differently on the 8086/8088 compared to all later CPUs.
The 8086 also has a few bugs which were fixed in later CPUs, but that generally doesn’t matter — all it means is that the workarounds which were needed on 8086/8088 are no longer necessary on later CPUs. (One example is the handling of interrupted instructions with multiple prefixes.)
Software which is actually affected by differences other than speed is very rare indeed, and you can count on the vast majority of software still technically working on a modern x86 CPU in real mode. Speed is another matter; famously, programs written using Turbo Pascal fail with an “Error 200” on CPUs faster than a 200MHz Pentium, and many games don’t cope well with faster CPUs (but some CPUs can be slowed down in creative ways).
Great write up, except speed issues are not really due a changed/extended ISA - they would occure as well back then when speed up occured - after all, having a 10 MHz 8086 was already in the early 1980s a way to screw programs made for a 4.77 MHz 8088
– Raffzahn
1 hour ago
The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).
– Stephen Kitt
1 hour ago
True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))
– Raffzahn
1 hour ago
add a comment |
An x86 CPU running in real mode is intended to be backwards-compatible with an 8086 or 8088, but there do end up being a number of differences, for example:
- newer CPUs run faster (in general);
- newer CPUs add new instructions (and, with the 386, new registers, since the 32-bit registers can be used in real mode);
- instruction timing — the speed of individual CPU instructions — varies from one family to another; some instructions run more slowly on newer CPUs;
- implementation details vary, and in some cases, can affect run-time behaviour — for example, varying prefetch queue lengths mean that self-modifying code may not work on CPUs other than the model it was written for;
- some instructions behave differently — for example,
PUSH SP
on an 8086 incrementsSP
after pushing it, whereas on a 286 it incrementsSP
before pushing it, so the value on the stack is different; - bus interactions (
LOCK
prefixes) behave differently on the 8086/8088 compared to all later CPUs; - illegal opcodes which run without error on the 8086 produce exceptions on later CPUs;
- the 8086 has no instruction length limit, whereas instructions which are too long will produce exceptions on later CPUs;
- segment wraparounds inside an instruction or word access work on the 8086 but trap on later CPUs;
- stack wraparounds work on the 8086 but will shut down a 286 or later;
- divide errors behave differently on the 8086/8088 compared to all later CPUs.
The 8086 also has a few bugs which were fixed in later CPUs, but that generally doesn’t matter — all it means is that the workarounds which were needed on 8086/8088 are no longer necessary on later CPUs. (One example is the handling of interrupted instructions with multiple prefixes.)
Software which is actually affected by differences other than speed is very rare indeed, and you can count on the vast majority of software still technically working on a modern x86 CPU in real mode. Speed is another matter; famously, programs written using Turbo Pascal fail with an “Error 200” on CPUs faster than a 200MHz Pentium, and many games don’t cope well with faster CPUs (but some CPUs can be slowed down in creative ways).
An x86 CPU running in real mode is intended to be backwards-compatible with an 8086 or 8088, but there do end up being a number of differences, for example:
- newer CPUs run faster (in general);
- newer CPUs add new instructions (and, with the 386, new registers, since the 32-bit registers can be used in real mode);
- instruction timing — the speed of individual CPU instructions — varies from one family to another; some instructions run more slowly on newer CPUs;
- implementation details vary, and in some cases, can affect run-time behaviour — for example, varying prefetch queue lengths mean that self-modifying code may not work on CPUs other than the model it was written for;
- some instructions behave differently — for example,
PUSH SP
on an 8086 incrementsSP
after pushing it, whereas on a 286 it incrementsSP
before pushing it, so the value on the stack is different; - bus interactions (
LOCK
prefixes) behave differently on the 8086/8088 compared to all later CPUs; - illegal opcodes which run without error on the 8086 produce exceptions on later CPUs;
- the 8086 has no instruction length limit, whereas instructions which are too long will produce exceptions on later CPUs;
- segment wraparounds inside an instruction or word access work on the 8086 but trap on later CPUs;
- stack wraparounds work on the 8086 but will shut down a 286 or later;
- divide errors behave differently on the 8086/8088 compared to all later CPUs.
The 8086 also has a few bugs which were fixed in later CPUs, but that generally doesn’t matter — all it means is that the workarounds which were needed on 8086/8088 are no longer necessary on later CPUs. (One example is the handling of interrupted instructions with multiple prefixes.)
Software which is actually affected by differences other than speed is very rare indeed, and you can count on the vast majority of software still technically working on a modern x86 CPU in real mode. Speed is another matter; famously, programs written using Turbo Pascal fail with an “Error 200” on CPUs faster than a 200MHz Pentium, and many games don’t cope well with faster CPUs (but some CPUs can be slowed down in creative ways).
edited 1 hour ago
answered 1 hour ago
Stephen KittStephen Kitt
39.3k8160171
39.3k8160171
Great write up, except speed issues are not really due a changed/extended ISA - they would occure as well back then when speed up occured - after all, having a 10 MHz 8086 was already in the early 1980s a way to screw programs made for a 4.77 MHz 8088
– Raffzahn
1 hour ago
The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).
– Stephen Kitt
1 hour ago
True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))
– Raffzahn
1 hour ago
add a comment |
Great write up, except speed issues are not really due a changed/extended ISA - they would occure as well back then when speed up occured - after all, having a 10 MHz 8086 was already in the early 1980s a way to screw programs made for a 4.77 MHz 8088
– Raffzahn
1 hour ago
The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).
– Stephen Kitt
1 hour ago
True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))
– Raffzahn
1 hour ago
Great write up, except speed issues are not really due a changed/extended ISA - they would occure as well back then when speed up occured - after all, having a 10 MHz 8086 was already in the early 1980s a way to screw programs made for a 4.77 MHz 8088
– Raffzahn
1 hour ago
Great write up, except speed issues are not really due a changed/extended ISA - they would occure as well back then when speed up occured - after all, having a 10 MHz 8086 was already in the early 1980s a way to screw programs made for a 4.77 MHz 8088
– Raffzahn
1 hour ago
The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).
– Stephen Kitt
1 hour ago
The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).
– Stephen Kitt
1 hour ago
True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))
– Raffzahn
1 hour ago
True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))
– Raffzahn
1 hour ago
add a comment |
When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)?
As so often it depends on your value of 'basically' (and there is no user visible difference between 8086 and 8088 beside speed).
Or are there differences between the two?
Well, it's so far the same, as every (modern) x86 operating in real mode will execute pure 8086 programs¹ adhering to what were legal² instructions³ on the 8086.
At the same time they are able to execute later extensions as well while in real mode. So it is possible to write 32-bit real mode programs, or use additional registers and instructions in real mode.
So a x86 isn't the same but for most parts (and depending on the CPU used) a compatible superset of an 8086.
¹ Lets ignore 'external' hardware differences for this.
² There are a few instructions that changed over time, including basic 8086 ones. They may cause incompatibilities in rare circumstances.
³ There are some non-instruction combinations (i.e. prefixes) that were ignored on 8086 but will throw interrupts on later CPUs or result in addressing errors. This is a classic case of later restrictions on less well defined behaviour (like double segment prefix and the like).
As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?
– Raffzahn
1 hour ago
Have an upvote to balance things out ;-).
– Stephen Kitt
19 mins ago
add a comment |
When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)?
As so often it depends on your value of 'basically' (and there is no user visible difference between 8086 and 8088 beside speed).
Or are there differences between the two?
Well, it's so far the same, as every (modern) x86 operating in real mode will execute pure 8086 programs¹ adhering to what were legal² instructions³ on the 8086.
At the same time they are able to execute later extensions as well while in real mode. So it is possible to write 32-bit real mode programs, or use additional registers and instructions in real mode.
So a x86 isn't the same but for most parts (and depending on the CPU used) a compatible superset of an 8086.
¹ Lets ignore 'external' hardware differences for this.
² There are a few instructions that changed over time, including basic 8086 ones. They may cause incompatibilities in rare circumstances.
³ There are some non-instruction combinations (i.e. prefixes) that were ignored on 8086 but will throw interrupts on later CPUs or result in addressing errors. This is a classic case of later restrictions on less well defined behaviour (like double segment prefix and the like).
As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?
– Raffzahn
1 hour ago
Have an upvote to balance things out ;-).
– Stephen Kitt
19 mins ago
add a comment |
When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)?
As so often it depends on your value of 'basically' (and there is no user visible difference between 8086 and 8088 beside speed).
Or are there differences between the two?
Well, it's so far the same, as every (modern) x86 operating in real mode will execute pure 8086 programs¹ adhering to what were legal² instructions³ on the 8086.
At the same time they are able to execute later extensions as well while in real mode. So it is possible to write 32-bit real mode programs, or use additional registers and instructions in real mode.
So a x86 isn't the same but for most parts (and depending on the CPU used) a compatible superset of an 8086.
¹ Lets ignore 'external' hardware differences for this.
² There are a few instructions that changed over time, including basic 8086 ones. They may cause incompatibilities in rare circumstances.
³ There are some non-instruction combinations (i.e. prefixes) that were ignored on 8086 but will throw interrupts on later CPUs or result in addressing errors. This is a classic case of later restrictions on less well defined behaviour (like double segment prefix and the like).
When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)?
As so often it depends on your value of 'basically' (and there is no user visible difference between 8086 and 8088 beside speed).
Or are there differences between the two?
Well, it's so far the same, as every (modern) x86 operating in real mode will execute pure 8086 programs¹ adhering to what were legal² instructions³ on the 8086.
At the same time they are able to execute later extensions as well while in real mode. So it is possible to write 32-bit real mode programs, or use additional registers and instructions in real mode.
So a x86 isn't the same but for most parts (and depending on the CPU used) a compatible superset of an 8086.
¹ Lets ignore 'external' hardware differences for this.
² There are a few instructions that changed over time, including basic 8086 ones. They may cause incompatibilities in rare circumstances.
³ There are some non-instruction combinations (i.e. prefixes) that were ignored on 8086 but will throw interrupts on later CPUs or result in addressing errors. This is a classic case of later restrictions on less well defined behaviour (like double segment prefix and the like).
edited 15 mins ago
Stephen Kitt
39.3k8160171
39.3k8160171
answered 1 hour ago
RaffzahnRaffzahn
55.3k6136224
55.3k6136224
As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?
– Raffzahn
1 hour ago
Have an upvote to balance things out ;-).
– Stephen Kitt
19 mins ago
add a comment |
As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?
– Raffzahn
1 hour ago
Have an upvote to balance things out ;-).
– Stephen Kitt
19 mins ago
As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?
– Raffzahn
1 hour ago
As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?
– Raffzahn
1 hour ago
Have an upvote to balance things out ;-).
– Stephen Kitt
19 mins ago
Have an upvote to balance things out ;-).
– Stephen Kitt
19 mins ago
add a comment |
user12245 is a new contributor. Be nice, and check out our Code of Conduct.
user12245 is a new contributor. Be nice, and check out our Code of Conduct.
user12245 is a new contributor. Be nice, and check out our Code of Conduct.
user12245 is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9588%2fcan-an-x86-cpu-running-in-real-mode-be-considered-to-be-basically-an-8086-cpu%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown