behavior of a 8086/88 encountering an illegal opcode
Ninho
hope that some (prolly many) old timers here will know the answer to
a question, which the "web" doesn't seem to be able to answer (or,
just I can't search properly...)
And the question is : how does an Intel 8086 or 8088 (not having
"exception 6") behave when fed an illegal instruction opcode, such as
hex "FF FF" ? I guess it would either stall, maybe outputting a
special cycle indication on the control bus, or else would it reset
itself, but can't do a quick check without access to one...
For completeness of one of my projects I need to sort this question
out if possible. Apologies if this Q was answered previously, a
pointer to a previous article would be appreciated then.
TIA
--
Ninho
Rod Pemberton
news:XnF9D75B203...@193.252.117.183...
I don't know the answer for sure.
My guess it that it executes something. What it executes is likely an alias
or an unknown sequence. I don't know about the 8086 specifically. Other
microprocessors of the era, like 6502, did not trap invalid opcodes.
Typically, all (8-bit) byte opcodes were directly decoded to set the
microprocessor's logic. If this resulted in a useless instruction, it was
undefined or unmentioned in the manuals. The 8086 uses byte opcodes. For
the most part, it's table is basically full.
These are known aliases:
82h alias for 80h
c0h/6 sal is alias for c0h/4 shl
c1h/6 sal is alias for c1h/4 shl
These instructions are listed as "reserved":
8Ch/6 reserved
8Ch/7 reserved
8Eh/6 reserved
8Eh/7 reserved
8Fh/1 to /7 reserved
C6h/1 to /7 reserved
C7h/1 to /7 reserved
FEh/2 to /7 reserved
FFh/7 reserved
These are not documented as instructions on 8086 and/or 80186:
83h/0 or not documented for 8086
83h/4 and not documented for 8086
83h/6 xor not documented for 8086
8Ch/4 mov es,fs not documented for 8086 or 80186 (no fs)
8Ch/5 mov es,gs not documented for 8086 or 80186 (no gs)
8Eh/4 mov fs,es not documented for 8086 or 80186 (no fs)
8Eh/5 not gs,es not documented for 8086 or 80186 (no gs)
From searching, I found:
"... If the instruction doesn't exist, an invalid-opcode exception is
generated. ... This will not work on the 8086/88 however, as
this microprocessor did not employ the invalid-opcode exception type." -
CPUID algorithm wars, Robert Collins
"CPUID algorithm Wars" by Robert R. Collins
http://www.rcollins.org/ddj/Nov96/Nov96.html
"Detecting Intel Processors" by Robert R. Collins
http://www.rcollins.org/ddj/Sep96/Sep96.html
A few clax posts where people tested invalid 8086 instructions:
http://groups.google.com/group/comp.lang.asm.x86/msg/e04d242e7ddb8898?hl=en
http://groups.google.com/group/comp.lang.asm.x86/msg/091638469b9aa16c?hl=en
http://groups.google.com/group/comp.lang.asm.x86/msg/f250f931efc27ae9?hl=en
Other 8086 tidbit:
http://groups.google.com/group/comp.arch.embedded/msg/f60463e5c5f2cb14?hl=en
HTH,
Rod Pemberton
s_dub...@nospicedham.yahoo.com
> Hi, Group ! Not a regular clax subscriber, I'm coming to you in the
> hope that some (prolly many) old timers here will know the answer to
> a question, which the "web" doesn't seem to be able to answer (or,
> just I can't search properly...)
>
> And the question is : how does an Intel 8086 or 8088 (not having
> "exception 6") behave when fed an illegal instruction opcode, such as
> hex "FF FF" ? I guess it would either stall, maybe outputting a
> special cycle indication on the control bus, or else would it reset
> itself, but can't do a quick check without access to one...
>
Reference". p3-38. Instruction Operation Differences, 8086,88 -
80186,188.
Undefined Opcodes
When opcodes 63h,64h,65h,66h,67h,F1h,FEh xx111xxxb and FFh xx111xxxb
are executed, the 80186,188 will execute an illegal instruction
exception (interrupt type 6). The 8086,88 will ignore these opcodes.
0Fh Opcode
When the opcode 0Fh is encountered, the 8086,88 will execute a POP CS;
the 80186,188 will execute an illegal instruction exeception.
( also says there is an operational difference in Word Write at offset
FFFFh. The 8086,88 writes a byte at FFFFh and the next at offset
0000h; the 80186,188 will write one byte at FFFFh and the other at
10000h, one byte beyond the end of the segment. -Also on the 186,188
a one byte segment underflow will occur if SP=0001h and a PUSH is
executed. )
there are other operational differences as well.
I don't know if that answers your question, you may be after the
signals generated, this manual doesn't have those.
You may still find some version of these manuals on Intels site under
'embedded' or their historical library.
Steve
Rod Pemberton
news:3fd87df2-137b-4cee...@e2g2000yqn.googlegroups.com...
On May 11, 10:29 am, Ninho <don't.u...@this.is.invalid> wrote:
> > And the question is : how does an Intel 8086 or 8088 (not having
> > "exception 6") behave when fed an illegal instruction opcode, such as
> > hex "FF FF" ?
>
> are executed, the 80186,188 will execute an illegal instruction
> exception (interrupt type 6). The 8086,88 will ignore these opcodes.
>
Good catch Steve. Sorry Ninho, I had that information, but overlooked it...
In addition to what Steve and I have listed, F1h and D6h may or may not be a
valid opcode on 8086. They are not listed in the modern 8086 datasheet. On
later processors, they are both valid opcodes, but still undocumented:
F1h INT1 undocumented
D6h SALC undocumented
If you're serious about your emulator, you might want to buy an 8086
machine, or find someone who can execute instruction sequences on a real
8086. It shouldn't be too much work for them to test the opcodes Steve and
I listed.
Rod Pemberton
Alexei A. Frounze
> <s_dubrov...@nospicedham.yahoo.com> wrote in message
There are 2 issues with this:
1. You don't know how many bytes of an invalid instruction the
8086/8088 will use
2. You don't know how it will change its register state and affect
memory
It's possible to find this out through testing, but these days it may
be pretty hard to find operational PCs with these old CPUs.
Alex
Ninho
> Ninho <don't.u...@this.is.invalid> wrote:
>>> And the question is : how does an Intel 8086 or 8088 (not
>>> having "exception 6") behave when fed an illegal instruction
>>> opcode, such as hex "FF FF" ?
Said by <s_dub...@nospicedham.yahoo.com> :
>> When opcodes 63h,64h,65h,66h,67h,F1h,FEh xx111xxxb and FFh
>> xx111xxxb are executed, the 80186,188 will execute an illegal
>> instruction exception (interrupt type 6). The 8086,88 will
>> ignore these opcodes.
> Good catch Steve. Sorry Ninho, I had that information, but
> overlooked it...
Intel manuals are not reliable and sometimes make outright false
statements where they discuss /backward/ (in)compatibility among the
various 80x86 incarnations :=(
I know this pretty well from extensive (and delicate) tests I
conducted on the 80286, then 80386, back in the old days.
> In addition to what Steve and I have listed, F1h and D6h may or
> may not be a valid opcode on 8086. They are not listed in the
> modern 8086 datasheet. On later processors, they are both valid
> opcodes, but still undocumented:
>
> F1h INT1 undocumented
> D6h SALC undocumented
SALC is known to have worked on all Intel (and many clones).
On the 286, F1 was an instruction /prefix/ - an alias of the LOCK
prefix (you'll find this little truth nowhere but by actual
testing!). A reasonable bet, but only a bet, is it was the same on
8086/80186.
Please note that my question is not 'bout /illegal/, /invalid/
opcodes, not /undocumented/ ones. There's more than a nuance... ;=)
> If you're serious about your emulator, you might want to buy an
> 8086 machine, or find someone who can execute instruction
> sequences on a real 8086. It shouldn't be too much work for them
> to test the opcodes Steve and I listed.
I hope some participants in these groups did or will do the testing.
Earlier CLAX posts which you referenced in your earlier reply
unfortunately aren't credible (one Phantom guy wrote his 8088 skipped
over a "SMSW" - not realising that his machine in fact executed a
"POP CS" followed by ... whatever; the other guy wrote his machine
"shutdown" on invalid opcodes I find more credible, but needs
confirmation - was there a special "shutdown" bus cycle on the 8086
(like on later x86s) or did he simply observe the processor
apparently stalling ?
Regards
--
Ninho
Ninho
>> Ninho <don't.u...@this.is.invalid> wrote:
>>>> And the question is : how does an Intel 8086 or 8088 (not
>>>> having "exception 6") behave when fed an illegal instruction
>>>> opcode, such as hex "FF FF" ?
> There are 2 issues with this:
> 1. You don't know how many bytes of an invalid instruction the
> 8086/8088 will use
> 2. You don't know how it will change its register state and affect
> memory
> It's possible to find this out through testing, but these days it
> may be pretty hard to find operational PCs with these old CPUs.
Duh, this is the reason I'm asking these groups. Else I'd have done
my own testing...
Cheers
--
Ninho
Ninho
Please note that my question is 'bout /illegal/, /invalid/
opcodes, not /undocumented/ ones.
Regards
--
Ninho
Stargazer
> "exception 6") behave when fed an illegal instruction opcode, such as
> hex "FF FF" ? I guess it would either stall, maybe outputting a
> special cycle indication on the control bus, or else would it reset
> itself, but can't do a quick check without access to one...
I actually tested this thing on a 8088 some time ago... (almost 20
years I guess). It treated undefined opcodes as 2-byte NOPs - IOW just
increased IP by 2 and kept executing. No other register or any
debugger-visible state changed.
Don't know if such an answer will help you much. I never saw a live
8086 or 8088 since then (not that I especially looked for), so I don't
know if all pre-186 CPUs treated UD ops that way or only particular
line 8088s. Also, there are companies that produce 8086 cores for
embedded controllers today and they may do something completely
different. "Undefined" means undefined.
Daniel
Ninho
>> And the question is : how does an Intel 8086 or 8088 (not having
>> "exception 6") behave when fed an illegal instruction opcode,
>> such as hex "FF FF" �?
> I actually tested this thing on a 8088 some time ago... (almost 20
> years I guess). It treated undefined opcodes as 2-byte NOPs - IOW
> just increased IP by 2 and kept executing. No other register or
> any debugger-visible state changed.
> Don't know if such an answer will help you much.
It does help, thank you! Actually the behavior you are reporting is
unexpected (to this old man) but others have said similar things and
since you actually /tested/, I have no doubt left.
> I never saw a
> live 8086 or 8088 since then (not that I especially looked for),
> so I don't know if all pre-186 CPUs treated UD ops that way or
> only particular line 8088s. Also, there are companies that produce
> 8086 cores for embedded controllers today and they may do
> something completely different. "Undefined" means undefined.
Wow! /New/ 8086s ? I was aware of long-lived embedded 286's - and even
those I believed no longer being made. The 8086s must sell under 1
penny a piece !
Like you I doubt a 2010-vintage 86 will be fully compatible to an nMOS
8086 of 1979.
--
Ninho
wolfgang kern
"Ninho" asked:
> And the question is : how does an Intel 8086 or 8088 (not
> having "exception 6") behave when fed an illegal instruction
> opcode, such as hex "FF FF" ?
I still owe these old Intel MC-books starting with 4000,8000(1975)
but none of them say anything about undefined opcodes.
Looks like programmers weren't expected to behave silly
in glorious good old times :)
Not sure after that many years, but I remember an Application-Note
(Intel-press) where undefined instructions were just marked with
'undefined behaviour', what a surprise :)
Another source (don't ask me where I once read) listed the effect
of several illegal opcodes as either ignored (may skip wrong size)
or causing the CPU to enter HALT or keeps it in 'passive'-state.
Mainboard Logic could read the three Status pins beside MEM/IO and
other pins, detect the uncommon and respond with INT/NMI/RESET
or just an error-LED.
Sorry, my 8088 evaluation-kit is long gone to the silicon-recycler.
__
wolfgang
Rod Pemberton
news:XnF9D75B203...@193.252.117.183...
>
> hex "FF FF"
>
I have no way to confirm the following. Supposedly, on early Intel cpu's
(not AMD's etc.), 0xFF 0xFF is a NOP. It will not double fault. It allows
IP to wrap to 0. The supposed reason was to allow BIOS to be placed at 0
for embedded environments. 0xFF 0xFF is supposedly the bus value read when
BIOS is not there. FYI, my source for this is flaky...
Rod Pemberton
Rod Pemberton
news:fa2aafea-8460-4676...@v12g2000prb.googlegroups.com...
On May 11, 10:17 pm, "Rod Pemberton" <do_not_h...@havenone.cmm> wrote:
> <s_dubrov...@nospicedham.yahoo.com> wrote in message
> news:3fd87df2-137b-4cee...@e2g2000yqn.googlegroups.com...
> On May 11, 10:29 am, Ninho <don't.u...@this.is.invalid> wrote:
>
> > > And the question is : how does an Intel 8086 or 8088 (not having
> > > "exception 6") behave when fed an illegal instruction opcode, such as
> > > hex "FF FF" ?
>
> > When opcodes 63h,64h,65h,66h,67h,F1h,FEh xx111xxxb and FFh xx111xxxb
> > are executed, the 80186,188 will execute an illegal instruction
> > exception (interrupt type 6). The 8086,88 will ignore these opcodes.
>
> Good catch Steve. Sorry Ninho, I had that information, but overlooked
it...
>
> In addition to what Steve and I have listed, F1h and D6h may or may not be
a
> valid opcode on 8086. They are not listed in the modern 8086 datasheet. On
> later processors, they are both valid opcodes, but still undocumented:
>
> F1h INT1 undocumented
> D6h SALC undocumented
>
> > If you're serious about your emulator, you might want to buy an 8086
> > machine, or find someone who can execute instruction sequences on a real
> > 8086. It shouldn't be too much work for them to test the opcodes Steve
and
> > I listed.
>
>
> 1. You don't know how many bytes of an invalid instruction the
> 8086/8088 will use
>
Even though there is no instruction length limit on 8086/8088, without any
instruction prefixes do you really think the cpu would consume more than the
10 bytes of a two-byte 286 style opcode? The 8086 is only a one-byte opcode
table with upto four bytes per instruction, yes? Without prefixes, can it
really consume more than four bytes for an undocumented opcode? That'd seem
unlikely to me...
> 2. You don't know how it will change its register state and affect
> memory
>
If the opcode isn't a branch, call, or jump type of instruction, changing
the IP, why would this be a problem?
He first wants to know if the instruction executes, resets, halts, or etc.
Then, he may want to know it's length. Then - if he's really pedantic -
what it does. From the history of what was done to determine 6502
undocumented opcodes, that last one is whole lot of work... Then, he has to
consider how many program's actually use undocumented instructions
inconjuction with how many of them will be run on his emulator. (likely,
none) Even the lowly AAA instruction's behavior is different for nearly all
generations of Pentiums. To correctly implement it, he has to know which
generation of cpu to emulate prior to emulating the code. Then, there's
those numerous x86 instruction "bugs" where the instructions operate
differently: F00F bug, fdiv bug, Cyrix 5/2 div bug, 386DX idiv bug, Cyrix
"comma" bug, 486 halt bug, 286 hang bug, 386CX popad bug, 386DX REP bug,
386DX STOSB bug, 386DX mul bug, 486 STOSB bug. (If you'd like a list, ask.
I'll post.) Some undocumented features are used in the routines to
determine cpu type. Then, there are changes in the instruction set from
generation to generation: POP CS, IBTS, XBTS. Then, different
manufacturer's instructions, e.g., Cyrix, NEC V20/V30.
Rod Pemberton
Alexei A. Frounze
> "Alexei A. Frounze" <alexfrun...@nospicedham.gmail.com> wrote in messagenews:fa2aafea-8460-4676...@v12g2000prb.googlegroups.com...
...
> > There are 2 issues with this:
>
> > 1. You don't know how many bytes of an invalid instruction the
> > 8086/8088 will use
>
> Even though there is no instruction length limit on 8086/8088, without any
> instruction prefixes do you really think the cpu would consume more than the
> 10 bytes of a two-byte 286 style opcode? The 8086 is only a one-byte opcode
> table with upto four bytes per instruction, yes? Without prefixes, can it
> really consume more than four bytes for an undocumented opcode? That'd seem
> unlikely to me...
The problem here is not the length itself, it's that you don't know
what the next CS:IP will be. And with variable-length instructions it
is pretty nasty to execute the following instruction anywhere but from
its very first byte. Of course, if that undefined/illegal instruction
doesn't transfer control anywhere, you can suffix that instruction
with a number of NOPs to be safe, but you'd need to do that everywhere
and what about the cases where there's no string of NOPs after it?
Anyway, I guess, we need to ask the OP about his intent as knowing it
would probably simplify the problem.
> > 2. You don't know how it will change its register state and affect
> > memory
>
> If the opcode isn't a branch, call, or jump type of instruction, changing
> the IP, why would this be a problem?
State corruption. Potentially undeterministic. You don't want that in
your software. But again, what's the intent behind this quest, Ninho?
Alex
Rod Pemberton
On May 12, 12:51 pm, "Rod Pemberton" <do_not_h...@havenone.cmm> wrote:
> "Alexei A. Frounze" <alexfrun...@nospicedham.gmail.com> wrote in message
news:fa2aafea-8460-4676...@v12g2000prb.googlegroups.com
> >
> > > 1. You don't know how many bytes of an invalid instruction the
> > > 8086/8088 will use
> >
> > Even though there is no instruction length limit on 8086/8088, without
> > any instruction prefixes do you really think the cpu would consume more
> > than the 10 bytes of a two-byte 286 style opcode? The 8086 is only a
> > one-byte opcode table with upto four bytes per instruction, yes? Without
> > prefixes, can it really consume more than four bytes for an undocumented
> > opcode? That'd seem unlikely to me...
>
> The problem here is not the length itself, it's that you don't know
> what the next CS:IP will be.
>
If this is really an issue, he enables the TF (trap flag) and installs an
Int 01h handler (not in that order...). He can then look at the on stack IP
when in Int 01h versus the prior on stack IP (saved) to determine the
instruction length. But, he doesn't need the TF, padding solves that for
his testing purposes.
> And with variable-length instructions it
> is pretty nasty to execute the following instruction anywhere but from
> its very first byte.
If a four byte pad fails to execute all the instructions he's testing, then
10. If that fails, then, 20... Is this that hard? If he doesn't want to
test all instructions together, then it's, what, twenty-five or so assembly
files? Once he's confirmed the instruction executes followed by some
placeholder 0 bytes, then he can proceed to test all possible byte
combinations upto at least 3 bytes following the opcode. He can do
this manually or with help from TF/Int 01h.
> Of course, if that undefined/illegal instruction
> doesn't transfer control anywhere, you can suffix that instruction
> with a number of NOPs to be safe,
Exactly.
> but you'd need to do that everywhere
> and what about the cases where there's no string of NOPs after it?
>
Where would that be? I think we're on different wavelengths...
AIUI, he's not using these instructions. He's attempting to determine what
they do in case he needs to emulate them in his emulator for some obscure
piece of software. It's possible some ancient software uses undocumented or
obsoleted instructions. Those author(s) may have determined some were
aliases or NOP's. If someone coded software that used undocumented opcodes,
they already discovered what they did, and so the CS:IP for the following
instruction will be correct, at least on the 8086. It's only for his
testing of these instructions that the next CS:IP isn't known. Once they've
been tested in full (i.e., followed by all possible byte combinations of at
least 3 bytes), he knows their length and format.
> > > 2. You don't know how it will change its register state and affect
> > > memory
> >
> > If the opcode isn't a branch, call, or jump type of instruction,
> > changing the IP, why would this be a problem?
>
> State corruption. Potentially undeterministic. You don't want that in
> your software.
>
True, but isn't that "putting the cart in front of the horse?" AIUI, he's
not using them. He's determining if he needs to emulate them. If he can't
locate a source providing this information, then he has to start somewhere,
e.g., by testing them. First, he needs to determine if they execute or not.
They could skip or hang or reset or possibly wrap around. Then, he needs
to determine instruction length and/or encoding. After which, he should
determine operation. If he's just beginning to test them, then state
corruption
and underministic operation is yet to come and will be determined later...
Rod Pemberton
Steph
If you could find that last source again it would of course be
interesting me - keeping in mind that even Intel's sources are often
unreliable or outright false (as Robert Collins and others taught us).
That point above about the processor stalling in a 'passive' state
reflected to the control pins, it's called "shtudown state" in intel
X86 speak. So you're saying your source mentionned the 8086 having it;
interesting indeed if your recollection is not, in fact, about later
processors.
> Sorry, my 8088 evaluation-kit is long gone to the silicon-recycler.
:=(
--
Ninho ... soon to go to the carbon recycler.
Ninho
If you could find that last source again it would of course be
interesting me - keeping in mind that even Intel's sources are often
unreliable or outright false (as Robert Collins and others taught us).
That point above about the processor stalling in a 'passive' state
reflected to the control pins, it's called "shtudown state" in intel
X86 speak. So you're saying your source mentionned the 8086 having it;
interesting indeed if your recollection is not, in fact, about later
processors.
> Sorry, my 8088 evaluation-kit is long gone to the silicon-recycler.
:=(
Ninho
>> hex "FF FF"
> I have no way to confirm the following. Supposedly, on early
> Intel cpu's (not AMD's etc.), 0xFF 0xFF is a NOP. It will not
> double fault.
Was there even 'double fault' logic on chip BTW ? One may doubt it...
> It allows IP to wrap to 0. The supposed reason was
> to allow BIOS to be placed at 0 for embedded environments. 0xFF
> 0xFF is supposedly the bus value read when BIOS is not there.
Correct. At least /if/ the bus is propoerly "terminated" (electrically,
by pull-up resistors. Which on cheap HW isn't always done...)
> FYI, my source for this is flaky...
But valuable nonetheless. Thank you Rod!
--
Ninho
Rod Pemberton
> "Rod Pemberton" wrote :
>
> > 0xFF is supposedly the bus value read when BIOS is not there.
>
> Correct. At least /if/ the bus is propoerly "terminated" (electrically,
> by pull-up resistors. Which on cheap HW isn't always done...)
>
I'll have to take your word for it. I know that was true a few decades ago.
But, I don't have any idea of what they do with logic today. Wolfgang Kern
on alt.os.development just stated that a modern bus will read FFh if no
memory is there.
RP
Ninho
>>> 0xFF is supposedly the bus value read when BIOS is not there.
>> Correct. At least /if/ the bus is propoerly "terminated"
...
> I'll have to take your word for it. I know that was true a few
> decades ago. But, I don't have any idea of what they do with logic
> today. Wolfgang Kern on alt.os.development just stated that a
> modern bus will read FFh if no memory is there.
He's right w/r to modern buses and integrated chipsets. My above
statement was meant in the context of this thread, regarding older
8086/80286/80386 clones. I saw both kinds, with and without proper bus
termination. In the latter case, "reading" from unexistant memory would
yield garbage, most often whatever was on the /address/ bus would come
back as faked /data/...
--
N.
wolfgang kern
Rod Pemberton mentioned:
>>> 0xFF is supposedly the bus value read when BIOS is not there.
>> Correct. At least /if/ the bus is propoerly "terminated" (electrically,
>> by pull-up resistors. Which on cheap HW isn't always done...)
> I'll have to take your word for it. I know that was true a few decades
> ago.
> But, I don't have any idea of what they do with logic today. Wolfgang
> Kern
> on alt.os.development just stated that a modern bus will read FFh if no
> memory is there.
Yes,
IF modern == higher Bus-frequency
THEN PullUp-resistors may become even more vital !
__
wolfgang
wolfgang kern
Ninho wrote:
[...]
>> Another source (don't ask me where I once read) listed the effect
>> of several illegal opcodes as either ignored (may skip wrong size)
>> or causing the CPU to enter HALT or keeps it in 'passive'-state.
>> Mainboard Logic could read the three Status pins beside MEM/IO and
>> other pins, detect the uncommon and respond with INT/NMI/RESET
>> or just an error-LED.
> If you could find that last source again it would of course be
> interesting me - keeping in mind that even Intel's sources are often
> unreliable or outright false (as Robert Collins and others taught us).
> That point above about the processor stalling in a 'passive' state
> reflected to the control pins, it's called "shutdown state" in intel
> X86 speak. So you're saying your source mentionned the 8086 having it;
> interesting indeed if your recollection is not, in fact, about later
> processors.
After a couple of beers I could dive as bit deeper into my memory,
and it sure was an article in one of this monthly 'electronic news'
for which I had several Abos then.
The discussion on the matter started with the 'undocumented Z80' list
(IIRC this happened ~1976/77) and were followed by 8000,8080,8085/86
reports on their behave right after this.
I now rember a few more details on it. While Z80 opcode-map were almost
fully defined, the Intels saved on some decoder-stages and so produced
undocumented aliases for many opcodes. And we still see some today.
Some of these made it hang because of impossible combinations.
It could be possible to use the opcode bit meaning to tell if
an undocumented/reserved code can work as alias or nop, but I
doubt it would tell which invalid variant make it hang.
>> Sorry, my 8088 evaluation-kit is long gone to the silicon-recycler.
> :=(
> --
> Ninho ... soon to go to the carbon recycler.
Whenever you got a chance to improve your environment, just take it :)
__
wolfgang
Robert Redelmeier
> Yes,
> IF modern == higher Bus-frequency
> THEN PullUp-resistors may become even more vital !
It is more than just that. Even 1 MHz needs to be treated
as a transmission line with termination at both ends
(and no forking, please!).
A bigger difference comes around 20 MHz (length dependant)
which generally has to be driven push-pull rather than
relying upon open drains. Double the driving transistors.
Personally, I prefer differential signalling (twisted
pair). In 1993 Ethernet was being run at 100 MHz over
100m of wild country when mobo designers had trouble
running 50 MHz over 20 cm of tightly controlled PCB.
But it does take double the pincount (ouch!).
-- Robert
Bob Masta
Note that PCI (the "modern" bus) uses no
conventional termination resistors. It actually
relies on the reflected wave for operation. The
driving wave only takes the line up half-way, and
the reflected wave takes it up the other half.
Google for "reflected wave switching".
Best regards,
Bob Masta
DAQARTA v5.10
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
DaqMusic - FREE MUSIC, Forever!
(Some assembly required)
Science (and fun!) with your sound card!
Robert Redelmeier
> On Sun, 16 May 2010 12:51:21 +0000 (UTC), Robert [wrote:]
>>Personally, I prefer differential signalling (twisted pair).
>>In 1993 Ethernet was being run at 100 MHz over 100m of wild
>>country when mobo designers had trouble running 50 MHz over
>>20 cm of tightly controlled PCB. But it does take double
>>the pincount (ouch!).
> Note that PCI (the "modern" bus) uses no conventional
> termination resistors. It actually relies on the reflected
> wave for operation. The driving wave only takes the line up
> half-way, and the reflected wave takes it up the other half.
> Google for "reflected wave switching".
Good point. But less workable when the line is long enough
to hold multiple signals :) FWIW, 100 MHz ethernet holds
~50 signals on a max length 100m run. OTOH PCI at 33 MHz
only needs 0.1 clocks to reflect back over 30 cm.
-- Robert