IBM PC expansion card latency
In the IBM PC and early successors and compatibles, it was commonplace for most of the computer's memory to be on cards in general expansion slots. (e.g. the original IBM PC could take 64K on the motherboard, but to get up to the 256K needed for Lotus 1-2-3, you had to use expansion cards of 64K each.) Even after this stopped being necessary thanks to higher density RAM chips, video memory would still be on an expansion card.
Was the latency for the CPU to access these memory banks, the same as it was for main memory on the motherboard? Or were there any models on which the CPU had to incur wait states accessing cards?
hardware ibm-pc memory
add a comment |
In the IBM PC and early successors and compatibles, it was commonplace for most of the computer's memory to be on cards in general expansion slots. (e.g. the original IBM PC could take 64K on the motherboard, but to get up to the 256K needed for Lotus 1-2-3, you had to use expansion cards of 64K each.) Even after this stopped being necessary thanks to higher density RAM chips, video memory would still be on an expansion card.
Was the latency for the CPU to access these memory banks, the same as it was for main memory on the motherboard? Or were there any models on which the CPU had to incur wait states accessing cards?
hardware ibm-pc memory
add a comment |
In the IBM PC and early successors and compatibles, it was commonplace for most of the computer's memory to be on cards in general expansion slots. (e.g. the original IBM PC could take 64K on the motherboard, but to get up to the 256K needed for Lotus 1-2-3, you had to use expansion cards of 64K each.) Even after this stopped being necessary thanks to higher density RAM chips, video memory would still be on an expansion card.
Was the latency for the CPU to access these memory banks, the same as it was for main memory on the motherboard? Or were there any models on which the CPU had to incur wait states accessing cards?
hardware ibm-pc memory
In the IBM PC and early successors and compatibles, it was commonplace for most of the computer's memory to be on cards in general expansion slots. (e.g. the original IBM PC could take 64K on the motherboard, but to get up to the 256K needed for Lotus 1-2-3, you had to use expansion cards of 64K each.) Even after this stopped being necessary thanks to higher density RAM chips, video memory would still be on an expansion card.
Was the latency for the CPU to access these memory banks, the same as it was for main memory on the motherboard? Or were there any models on which the CPU had to incur wait states accessing cards?
hardware ibm-pc memory
hardware ibm-pc memory
asked Jan 15 at 21:50
rwallacerwallace
8,748444125
8,748444125
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Same. At least for The PC.
Later machines were of course throttled accordingly to keep slot access speed within the original spec. What else should they have done?
But they tried, and from there on it gets complicated.
The PC-AT did run 1 wait state on each 16 bit access, IO or memory, internal or card. Thus allowing 'full speed'. But it inserted 4 wait states for any 8 bit card access - working as a slowdown to even a little less than PC speed, making sure 'old' 8 bit cards would comply.
This was done by the card pulling IO16 or M16 whenever it decoded an address as theirs and 'decided' to support 16 bit access - or better one should say fast access, as this of course also worked with any access, 8 or 16, as long as IO16/M16 was pulled during the initial clock cycle. A 'real' 16 bit access (reading or writing a word) would, without O16/M16 pulled, be split into two 8 bit accesses by the PC glue logic, each with its own 4 wait states.
This way a 16 bit memory expansion could work at full speed, while 8 bit I/O cards worked at a PC-like access timing.
To make things even more complicated, NOWS (NO Wait State) pulled during the middle of any access cycle would stop the wait state generation with that cycle (*1). Alternatively CHRDY (CHanel ReaDY) could be used to extend wait state generation as long as needed (*2,3).
And somewhat related, there were also what I would call 'virtual' 16 bit cards. Most notably here some of the first faster VGA clones. They were usually sold as 16 Bit VGA, but in reality they were 8 bit designs. After all, the original VGA is an 8 bit design, and so were (most) compatibles. The trick here was to implement the byte/word glue logic onto the card. A write access was always accepted with IO16/M16, just to be handed toward the controller as two 8 bit transfers - while the 80286 continued its duty. On a read the wait state was used to fetch both bytes from the card.
Of course there were also real 16 bit VGA cards later on. But those were newer controllers and designs.
Oh, and then there's the case of mixed display adaptors. As soon as there is one 8 bit display adaptor in a system all will be accessed as 8 bit. Thus mixing one of the nice 'virtual' 16 Bit VGA with an MDA will pull the VGA down to PC speed again - unless it also used NOWS that is, then it's only slowed to 8 bit speed.
*1 - So an 8 bit cycle could be cut short at the first, second or third cycle as well.
*2 - Both signals were already available with the PC.
*3 - Pulling both created an undefined state.
Good point - you can't just run a card faster than it was specified for. Though later when there are 16-bit cards, you could presumably at least assume these can handle 6 MHz (AT speed) rather than being limited to 4.77 MHz?
– rwallace
Jan 15 at 22:41
1
Well, yes ... and from there on it gets complicated :))
– Raffzahn
Jan 15 at 23:04
add a comment |
The number of wait states added for a memory cycle did not depend directly on whether the memory was on the system board or an expansion card, but it was possible for either or both to add a wait state.
The original IBM PC added 1 wait state for system board memory accesses but it was possible for a memory expansion card to run at 0 wait states by asserting the NOWS line during an access cycle. I don't know whether there were any memory expansion boards that actually did this or not.
Later, the XT 286 supported 0 wait states for its system board RAM which made it perform faster than the 1-wait-state AT at the same clock speed.
Eventually when the bus clock became separated from the CPU clock, it was then very common for expansion card memory to be significantly slower than system board memory, simply due to being limited to the bus speed (typically 8MHz) rather than the 'native' CPU speed. But for the PC, XT and AT the bus speed was the same as the CPU speed so this was not a factor.
add a comment |
The expansion bus on the the original IBM PC, which later became known as 8 bit ISA, is actually just the 8088 CPU bus with some buffering. That was a common technique for expansion cards at the time and through the 1980s.
As such RAM connected to the ISA bus has very similar properties to the RAM on the motherboard. The buffering does not introduce any additional timing requirements.
Later systems separated the ISA bus from the CPU bus, because the CPU was capable of running at much higher speeds than ISA cards could handle, but for the original 8088 machines there is no latency penalty at all.
Of course cheap RAM upgrades may have introduced extra wait states to compensate for using cheaper, slower RAM, but it wasn't a requirement.
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
});
}
});
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%2f8757%2fibm-pc-expansion-card-latency%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Same. At least for The PC.
Later machines were of course throttled accordingly to keep slot access speed within the original spec. What else should they have done?
But they tried, and from there on it gets complicated.
The PC-AT did run 1 wait state on each 16 bit access, IO or memory, internal or card. Thus allowing 'full speed'. But it inserted 4 wait states for any 8 bit card access - working as a slowdown to even a little less than PC speed, making sure 'old' 8 bit cards would comply.
This was done by the card pulling IO16 or M16 whenever it decoded an address as theirs and 'decided' to support 16 bit access - or better one should say fast access, as this of course also worked with any access, 8 or 16, as long as IO16/M16 was pulled during the initial clock cycle. A 'real' 16 bit access (reading or writing a word) would, without O16/M16 pulled, be split into two 8 bit accesses by the PC glue logic, each with its own 4 wait states.
This way a 16 bit memory expansion could work at full speed, while 8 bit I/O cards worked at a PC-like access timing.
To make things even more complicated, NOWS (NO Wait State) pulled during the middle of any access cycle would stop the wait state generation with that cycle (*1). Alternatively CHRDY (CHanel ReaDY) could be used to extend wait state generation as long as needed (*2,3).
And somewhat related, there were also what I would call 'virtual' 16 bit cards. Most notably here some of the first faster VGA clones. They were usually sold as 16 Bit VGA, but in reality they were 8 bit designs. After all, the original VGA is an 8 bit design, and so were (most) compatibles. The trick here was to implement the byte/word glue logic onto the card. A write access was always accepted with IO16/M16, just to be handed toward the controller as two 8 bit transfers - while the 80286 continued its duty. On a read the wait state was used to fetch both bytes from the card.
Of course there were also real 16 bit VGA cards later on. But those were newer controllers and designs.
Oh, and then there's the case of mixed display adaptors. As soon as there is one 8 bit display adaptor in a system all will be accessed as 8 bit. Thus mixing one of the nice 'virtual' 16 Bit VGA with an MDA will pull the VGA down to PC speed again - unless it also used NOWS that is, then it's only slowed to 8 bit speed.
*1 - So an 8 bit cycle could be cut short at the first, second or third cycle as well.
*2 - Both signals were already available with the PC.
*3 - Pulling both created an undefined state.
Good point - you can't just run a card faster than it was specified for. Though later when there are 16-bit cards, you could presumably at least assume these can handle 6 MHz (AT speed) rather than being limited to 4.77 MHz?
– rwallace
Jan 15 at 22:41
1
Well, yes ... and from there on it gets complicated :))
– Raffzahn
Jan 15 at 23:04
add a comment |
Same. At least for The PC.
Later machines were of course throttled accordingly to keep slot access speed within the original spec. What else should they have done?
But they tried, and from there on it gets complicated.
The PC-AT did run 1 wait state on each 16 bit access, IO or memory, internal or card. Thus allowing 'full speed'. But it inserted 4 wait states for any 8 bit card access - working as a slowdown to even a little less than PC speed, making sure 'old' 8 bit cards would comply.
This was done by the card pulling IO16 or M16 whenever it decoded an address as theirs and 'decided' to support 16 bit access - or better one should say fast access, as this of course also worked with any access, 8 or 16, as long as IO16/M16 was pulled during the initial clock cycle. A 'real' 16 bit access (reading or writing a word) would, without O16/M16 pulled, be split into two 8 bit accesses by the PC glue logic, each with its own 4 wait states.
This way a 16 bit memory expansion could work at full speed, while 8 bit I/O cards worked at a PC-like access timing.
To make things even more complicated, NOWS (NO Wait State) pulled during the middle of any access cycle would stop the wait state generation with that cycle (*1). Alternatively CHRDY (CHanel ReaDY) could be used to extend wait state generation as long as needed (*2,3).
And somewhat related, there were also what I would call 'virtual' 16 bit cards. Most notably here some of the first faster VGA clones. They were usually sold as 16 Bit VGA, but in reality they were 8 bit designs. After all, the original VGA is an 8 bit design, and so were (most) compatibles. The trick here was to implement the byte/word glue logic onto the card. A write access was always accepted with IO16/M16, just to be handed toward the controller as two 8 bit transfers - while the 80286 continued its duty. On a read the wait state was used to fetch both bytes from the card.
Of course there were also real 16 bit VGA cards later on. But those were newer controllers and designs.
Oh, and then there's the case of mixed display adaptors. As soon as there is one 8 bit display adaptor in a system all will be accessed as 8 bit. Thus mixing one of the nice 'virtual' 16 Bit VGA with an MDA will pull the VGA down to PC speed again - unless it also used NOWS that is, then it's only slowed to 8 bit speed.
*1 - So an 8 bit cycle could be cut short at the first, second or third cycle as well.
*2 - Both signals were already available with the PC.
*3 - Pulling both created an undefined state.
Good point - you can't just run a card faster than it was specified for. Though later when there are 16-bit cards, you could presumably at least assume these can handle 6 MHz (AT speed) rather than being limited to 4.77 MHz?
– rwallace
Jan 15 at 22:41
1
Well, yes ... and from there on it gets complicated :))
– Raffzahn
Jan 15 at 23:04
add a comment |
Same. At least for The PC.
Later machines were of course throttled accordingly to keep slot access speed within the original spec. What else should they have done?
But they tried, and from there on it gets complicated.
The PC-AT did run 1 wait state on each 16 bit access, IO or memory, internal or card. Thus allowing 'full speed'. But it inserted 4 wait states for any 8 bit card access - working as a slowdown to even a little less than PC speed, making sure 'old' 8 bit cards would comply.
This was done by the card pulling IO16 or M16 whenever it decoded an address as theirs and 'decided' to support 16 bit access - or better one should say fast access, as this of course also worked with any access, 8 or 16, as long as IO16/M16 was pulled during the initial clock cycle. A 'real' 16 bit access (reading or writing a word) would, without O16/M16 pulled, be split into two 8 bit accesses by the PC glue logic, each with its own 4 wait states.
This way a 16 bit memory expansion could work at full speed, while 8 bit I/O cards worked at a PC-like access timing.
To make things even more complicated, NOWS (NO Wait State) pulled during the middle of any access cycle would stop the wait state generation with that cycle (*1). Alternatively CHRDY (CHanel ReaDY) could be used to extend wait state generation as long as needed (*2,3).
And somewhat related, there were also what I would call 'virtual' 16 bit cards. Most notably here some of the first faster VGA clones. They were usually sold as 16 Bit VGA, but in reality they were 8 bit designs. After all, the original VGA is an 8 bit design, and so were (most) compatibles. The trick here was to implement the byte/word glue logic onto the card. A write access was always accepted with IO16/M16, just to be handed toward the controller as two 8 bit transfers - while the 80286 continued its duty. On a read the wait state was used to fetch both bytes from the card.
Of course there were also real 16 bit VGA cards later on. But those were newer controllers and designs.
Oh, and then there's the case of mixed display adaptors. As soon as there is one 8 bit display adaptor in a system all will be accessed as 8 bit. Thus mixing one of the nice 'virtual' 16 Bit VGA with an MDA will pull the VGA down to PC speed again - unless it also used NOWS that is, then it's only slowed to 8 bit speed.
*1 - So an 8 bit cycle could be cut short at the first, second or third cycle as well.
*2 - Both signals were already available with the PC.
*3 - Pulling both created an undefined state.
Same. At least for The PC.
Later machines were of course throttled accordingly to keep slot access speed within the original spec. What else should they have done?
But they tried, and from there on it gets complicated.
The PC-AT did run 1 wait state on each 16 bit access, IO or memory, internal or card. Thus allowing 'full speed'. But it inserted 4 wait states for any 8 bit card access - working as a slowdown to even a little less than PC speed, making sure 'old' 8 bit cards would comply.
This was done by the card pulling IO16 or M16 whenever it decoded an address as theirs and 'decided' to support 16 bit access - or better one should say fast access, as this of course also worked with any access, 8 or 16, as long as IO16/M16 was pulled during the initial clock cycle. A 'real' 16 bit access (reading or writing a word) would, without O16/M16 pulled, be split into two 8 bit accesses by the PC glue logic, each with its own 4 wait states.
This way a 16 bit memory expansion could work at full speed, while 8 bit I/O cards worked at a PC-like access timing.
To make things even more complicated, NOWS (NO Wait State) pulled during the middle of any access cycle would stop the wait state generation with that cycle (*1). Alternatively CHRDY (CHanel ReaDY) could be used to extend wait state generation as long as needed (*2,3).
And somewhat related, there were also what I would call 'virtual' 16 bit cards. Most notably here some of the first faster VGA clones. They were usually sold as 16 Bit VGA, but in reality they were 8 bit designs. After all, the original VGA is an 8 bit design, and so were (most) compatibles. The trick here was to implement the byte/word glue logic onto the card. A write access was always accepted with IO16/M16, just to be handed toward the controller as two 8 bit transfers - while the 80286 continued its duty. On a read the wait state was used to fetch both bytes from the card.
Of course there were also real 16 bit VGA cards later on. But those were newer controllers and designs.
Oh, and then there's the case of mixed display adaptors. As soon as there is one 8 bit display adaptor in a system all will be accessed as 8 bit. Thus mixing one of the nice 'virtual' 16 Bit VGA with an MDA will pull the VGA down to PC speed again - unless it also used NOWS that is, then it's only slowed to 8 bit speed.
*1 - So an 8 bit cycle could be cut short at the first, second or third cycle as well.
*2 - Both signals were already available with the PC.
*3 - Pulling both created an undefined state.
edited Jan 16 at 13:02
Community♦
1
1
answered Jan 15 at 22:32
RaffzahnRaffzahn
48.4k6109195
48.4k6109195
Good point - you can't just run a card faster than it was specified for. Though later when there are 16-bit cards, you could presumably at least assume these can handle 6 MHz (AT speed) rather than being limited to 4.77 MHz?
– rwallace
Jan 15 at 22:41
1
Well, yes ... and from there on it gets complicated :))
– Raffzahn
Jan 15 at 23:04
add a comment |
Good point - you can't just run a card faster than it was specified for. Though later when there are 16-bit cards, you could presumably at least assume these can handle 6 MHz (AT speed) rather than being limited to 4.77 MHz?
– rwallace
Jan 15 at 22:41
1
Well, yes ... and from there on it gets complicated :))
– Raffzahn
Jan 15 at 23:04
Good point - you can't just run a card faster than it was specified for. Though later when there are 16-bit cards, you could presumably at least assume these can handle 6 MHz (AT speed) rather than being limited to 4.77 MHz?
– rwallace
Jan 15 at 22:41
Good point - you can't just run a card faster than it was specified for. Though later when there are 16-bit cards, you could presumably at least assume these can handle 6 MHz (AT speed) rather than being limited to 4.77 MHz?
– rwallace
Jan 15 at 22:41
1
1
Well, yes ... and from there on it gets complicated :))
– Raffzahn
Jan 15 at 23:04
Well, yes ... and from there on it gets complicated :))
– Raffzahn
Jan 15 at 23:04
add a comment |
The number of wait states added for a memory cycle did not depend directly on whether the memory was on the system board or an expansion card, but it was possible for either or both to add a wait state.
The original IBM PC added 1 wait state for system board memory accesses but it was possible for a memory expansion card to run at 0 wait states by asserting the NOWS line during an access cycle. I don't know whether there were any memory expansion boards that actually did this or not.
Later, the XT 286 supported 0 wait states for its system board RAM which made it perform faster than the 1-wait-state AT at the same clock speed.
Eventually when the bus clock became separated from the CPU clock, it was then very common for expansion card memory to be significantly slower than system board memory, simply due to being limited to the bus speed (typically 8MHz) rather than the 'native' CPU speed. But for the PC, XT and AT the bus speed was the same as the CPU speed so this was not a factor.
add a comment |
The number of wait states added for a memory cycle did not depend directly on whether the memory was on the system board or an expansion card, but it was possible for either or both to add a wait state.
The original IBM PC added 1 wait state for system board memory accesses but it was possible for a memory expansion card to run at 0 wait states by asserting the NOWS line during an access cycle. I don't know whether there were any memory expansion boards that actually did this or not.
Later, the XT 286 supported 0 wait states for its system board RAM which made it perform faster than the 1-wait-state AT at the same clock speed.
Eventually when the bus clock became separated from the CPU clock, it was then very common for expansion card memory to be significantly slower than system board memory, simply due to being limited to the bus speed (typically 8MHz) rather than the 'native' CPU speed. But for the PC, XT and AT the bus speed was the same as the CPU speed so this was not a factor.
add a comment |
The number of wait states added for a memory cycle did not depend directly on whether the memory was on the system board or an expansion card, but it was possible for either or both to add a wait state.
The original IBM PC added 1 wait state for system board memory accesses but it was possible for a memory expansion card to run at 0 wait states by asserting the NOWS line during an access cycle. I don't know whether there were any memory expansion boards that actually did this or not.
Later, the XT 286 supported 0 wait states for its system board RAM which made it perform faster than the 1-wait-state AT at the same clock speed.
Eventually when the bus clock became separated from the CPU clock, it was then very common for expansion card memory to be significantly slower than system board memory, simply due to being limited to the bus speed (typically 8MHz) rather than the 'native' CPU speed. But for the PC, XT and AT the bus speed was the same as the CPU speed so this was not a factor.
The number of wait states added for a memory cycle did not depend directly on whether the memory was on the system board or an expansion card, but it was possible for either or both to add a wait state.
The original IBM PC added 1 wait state for system board memory accesses but it was possible for a memory expansion card to run at 0 wait states by asserting the NOWS line during an access cycle. I don't know whether there were any memory expansion boards that actually did this or not.
Later, the XT 286 supported 0 wait states for its system board RAM which made it perform faster than the 1-wait-state AT at the same clock speed.
Eventually when the bus clock became separated from the CPU clock, it was then very common for expansion card memory to be significantly slower than system board memory, simply due to being limited to the bus speed (typically 8MHz) rather than the 'native' CPU speed. But for the PC, XT and AT the bus speed was the same as the CPU speed so this was not a factor.
answered Jan 15 at 22:46
Ken GoberKen Gober
7,80712139
7,80712139
add a comment |
add a comment |
The expansion bus on the the original IBM PC, which later became known as 8 bit ISA, is actually just the 8088 CPU bus with some buffering. That was a common technique for expansion cards at the time and through the 1980s.
As such RAM connected to the ISA bus has very similar properties to the RAM on the motherboard. The buffering does not introduce any additional timing requirements.
Later systems separated the ISA bus from the CPU bus, because the CPU was capable of running at much higher speeds than ISA cards could handle, but for the original 8088 machines there is no latency penalty at all.
Of course cheap RAM upgrades may have introduced extra wait states to compensate for using cheaper, slower RAM, but it wasn't a requirement.
add a comment |
The expansion bus on the the original IBM PC, which later became known as 8 bit ISA, is actually just the 8088 CPU bus with some buffering. That was a common technique for expansion cards at the time and through the 1980s.
As such RAM connected to the ISA bus has very similar properties to the RAM on the motherboard. The buffering does not introduce any additional timing requirements.
Later systems separated the ISA bus from the CPU bus, because the CPU was capable of running at much higher speeds than ISA cards could handle, but for the original 8088 machines there is no latency penalty at all.
Of course cheap RAM upgrades may have introduced extra wait states to compensate for using cheaper, slower RAM, but it wasn't a requirement.
add a comment |
The expansion bus on the the original IBM PC, which later became known as 8 bit ISA, is actually just the 8088 CPU bus with some buffering. That was a common technique for expansion cards at the time and through the 1980s.
As such RAM connected to the ISA bus has very similar properties to the RAM on the motherboard. The buffering does not introduce any additional timing requirements.
Later systems separated the ISA bus from the CPU bus, because the CPU was capable of running at much higher speeds than ISA cards could handle, but for the original 8088 machines there is no latency penalty at all.
Of course cheap RAM upgrades may have introduced extra wait states to compensate for using cheaper, slower RAM, but it wasn't a requirement.
The expansion bus on the the original IBM PC, which later became known as 8 bit ISA, is actually just the 8088 CPU bus with some buffering. That was a common technique for expansion cards at the time and through the 1980s.
As such RAM connected to the ISA bus has very similar properties to the RAM on the motherboard. The buffering does not introduce any additional timing requirements.
Later systems separated the ISA bus from the CPU bus, because the CPU was capable of running at much higher speeds than ISA cards could handle, but for the original 8088 machines there is no latency penalty at all.
Of course cheap RAM upgrades may have introduced extra wait states to compensate for using cheaper, slower RAM, but it wasn't a requirement.
answered Jan 16 at 9:35
useruser
3,155615
3,155615
add a comment |
add a comment |
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%2f8757%2fibm-pc-expansion-card-latency%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