Undocumented 8080 opcodes
stefano...@inwind.it
I've been told that Intel 8080 CPU supports these undocumented opcodes - is it true?
08h, 10h, 18h, 20h, 28h, 30h, 38h - NOP
0CBh - JMP
0D9h - RET
0DDh, 0EDh, 0FDh - CALL
Thanks
--
Stefano Priore | SuSE Linux 7.1 kernel 2.4.18
--------------------------------+--------------------------------
"Video meliora proboque, | Linux Registered User #210152
autem deteriora sequor..." | Linux Registered Machine #97752
Bill Marcum
stefano...@inwind.it <stefano...@inwind.it> wrote:
>Can anyone confirm this rumor:
>
>I've been told that Intel 8080 CPU supports these undocumented opcodes - is it true?
>
>08h, 10h, 18h, 20h, 28h, 30h, 38h - NOP
>0CBh - JMP
>0D9h - RET
>0DDh, 0EDh, 0FDh - CALL
>
>Thanks
It might be true, but any software that used those opcodes would not work
on a Z80 or 8085.
dwight elvey
> Can anyone confirm this rumor:
>
> I've been told that Intel 8080 CPU supports these undocumented opcodes - is it true?
>
> 08h, 10h, 18h, 20h, 28h, 30h, 38h - NOP
> 0CBh - JMP
> 0D9h - RET
> 0DDh, 0EDh, 0FDh - CALL
>
> Thanks
Hi
There was some undocumented codes in the NEC 8080 that
did some block operations ( as I recall ). I wish I'd
written them down someplace but that was years ago.
The Intel 8085 has a few undocumented block operations
as well but, again I've lost what they were.
Dwight
John Mills
On Tue, 14 May 2002 stefano...@inwind.it wrote:
> Can anyone confirm this rumor:
Well, not I.
> I've been told that Intel 8080 CPU supports these undocumented opcodes - is it true?
> 08h, 10h, 18h, 20h, 28h, 30h, 38h - NOP
> 0CBh - JMP
> 0D9h - RET
> 0DDh, 0EDh, 0FDh - CALL
Right or wrong, none of these codes seems to do anything a _documented_
(and presumably guaranteed) code does not already do. Why would you want
to use a non-guaranteed code which would only do (at best) what some
other, well-known code would do anyway?
Am I missing something here?
- John Mills
Barry Watzman
that were useful. I don't remember what they were, but they were covered in articles in
early issues of some of the publications of the time (Dr. Dobbs Journal, Byte Magazine
and others).
jim korman
Well I'm not sure about the OP, but I ran into this problem when I was
writing an emulator for the z80. What should be the "PROPER" behavior
of the "processor" when presented an illegal (undocumented) opcode!
Intel and Zilog never address this issue in their documents.
Jim
Richard Steven Walz
Barry Watzman <Wat...@neo.rr.com> wrote:
>Not sure about the 8080, but the 8085 had some undocumented opcodes that
>did work and
>that were useful. I don't remember what they were, but they were
>covered in articles in
>early issues of some of the publications of the time (Dr. Dobbs Journal,
>Byte Magazine
>and others).
Here's what *I* have about 8085 and Z80:
-------------------------------------------------------begin
From: h...@kbbs.org (Holger Petersen)
Subject: Re: Looking for *undocumented* 8085 op-codes
Date: Fri, 11 Oct 1996 15:38:41 GMT
My list says the following:
Hex 8085 Meaning
---------------------
08 SUB HL-BC
10 Shift right HL
18 Rotate right DE
20 RIM Read Interrupt Mask [legal 8085, but new from 8080]
28 Add HL and Immidiate nnnn into DE
30 SIM Set Interrupt Mask [legal 8085, but new from 8080]
38 Add SP and Immidiate nnnn into DE
CB ReSTart on Overflow to 0040h
D9 Load [DE] from HL
DD Jump on 'Not X5'
ED Load Hl from [DE]
FD Jump on 'X5'
greetings, Holger
-----------------------------------------------------end
----------------------------------------------------------begin
From: mg...@cus.cam.ac.uk (M.G. Rison)
Subject: Z80 F effects
Date: 19 Feb 1996 20:07:21 GMT
Organization: University of Cambridge, England
There are three classes of undocumented Z80 instructions, corresponding
to 'holes' in the opcodes. These are:
- undocumented index operations
- undocumented shift operations
- undocumented EDxx operations
1) Undocumented index operations
================================
[In this section, IX operations will be described. IY operations,
obtained by replacing DDs with FDs, behave identically.]
A DD preceding an instruction causes, in general, the following
('main') instruction to be processed as normal, except that:
- any access to (HL) gets treated as an access to (IX+d), where d is
the (signed) displacement byte after the main instruction opcode
- any access to HL gets treated as an access to IX
- any access to H gets treated as an access to IXh
- any access to L gets treated as an access to IXl
If the main instruction does not access any of (HL), HL, H and L, then
the DD effectively acts as a NOP. (In addition, a series of DDs and
FDs acts as a series of NOPs with the DD/FD actually obeyed being the
last one in the series.)
There are exceptions to the general rule, however. These are:
Main instruction Effect of preceding DD
---------------- ----------------------
LD H,(HL) Causes LD H,(IX+d)
LD (HL),H Causes LD (IX+d),H
LD L,(HL) Causes LD L,(IX+d)
LD (HL),L Causes LD (IX+d),L
EX DE,HL None (left as EX DE,HL)
EXX None (left as EXX)
EDxx None (left as EDxx)
CBxx See below
DDCB sequences always cause the byte following the CB to be taken
as a displacement, and always cause an access to (IX+d). If
the sequence produces output other than in the flags (i.e. all
except BIT), then the result gets placed both into (IX+d) and the
register one would normally expect to be altered.
For example, DDCB0100 causes RLC (IX+1) and copies the result into B.
DDCB02FF causes SET 7,(IX+2) and copies the result into A.
DDCB0373 causes BIT 6,(IX+3).
2) Undocumented shift operations
================================
Instructions in the range CB30 to CB37 cause the operand to
be shifted left, setting b0. The effect is therefore like SLA
except b0 is set instead of being reset.
3) Undocumented EDxx operations
===============================
Instructions in the range ED00 to ED3F have no effect.
Instructions in the range ED80 to EDBF, except those documented as
block loads, compares, ins or outs, have no effect.
Instructions in the range EDC0 to EDFF have no effect. !CPC uses
some of these for interaction with the host.
The holes in the range ED40 to ED7F typically duplicate documented
instructions:
- NEG at ED4C, ED54, ED5C, ED64, ED6C, ED74, ED7C
- NOP at ED77, ED7F
- RETN at ED55, ED65, ED75
- RETI at ED5D, ED6D, ED7D
- IM ? at ED4E, ED6E
- IM 0 at ED66
- IM 1 at ED76
- IM 2 at ED7E
- IN F,(C) at ED70
- OUT (C),0 at ED71
IM ? sets the interrupt mode flip-flops to an undefined state, which
seems to act like IM 0 or IM 1. These states are indistinguishable
on the CPC (!CPC chooses IM 0 to indicate an abnormal state).
IN F,(C) performs the input operation, setting the flags as normal,
but throws the input value away. OUT (C),0 outputs zero to the port.
(Note it would output 255 if the Z80 used in the CPC were the CMOS
variant rather than the NMOS variant.)
1996-02-28
----------------------------------------------------------end
But as for the 8080, it is so hard to use by comparison, WHO CARES!??
-Steve
--
-Steve Walz rst...@armory.com ftp://ftp.armory.com/pub/user/rstevew
Electronics Site!! 1000's of Files and Dirs!! With Schematics Galore!!
http://www.armory.com/~rstevew or http://www.armory.com/~rstevew/Public
ne...@nulli.us
When I wrote my z80a emulator, I ran tests on a real Z80A CPU and
collected the results for all instructions in the instruction space.
I then transferred the results to "flags tables" which the emulator
uses. Because of this, my emulator returns identical results to a
real hardware Z80A--even for the undocumented instructions and flags
bits. I did this mainly because I could not make heads or tails of
Zilog's documentation of the DAA instruction. I know what the
instruction does, I just could not decypher Zilog's explanation.
You may obtain a copy of my emulator on my ftp site:
Please copy only one of the compressed source files. Be forewarned:
the sources contain over 75,000 lines of C source code. On a 1GHz
Intel Pentium III, the emulator runs at about 150 MHz! There are
several versions there, but they are all identical. Also grab the
zex* files. These files were written by Frank Cringle and will run
an emulator validity test to determine whether the emulator is
executing Z80A code correctly.
My firewall DENYs major portions of the worldwide IP space as a
partial spam filter. Sorry, but until those people get their act
together, they are not allowed on my machine.
All email to my posting address goes directly to /dev/null. I will,
I think, however, receive email addressed to:
<[nemo]> (atty) [z80a] (dotty) [org]
--
Nobody wants to be a nobody Nemo esse vult nemo
and since I am nobody, et quoniam nemo sum ego,
I am exactly what I want to be! is ipse sum qui esse volo!
--Terry Groff --Nemo Nullius
Lee Hart
are undocumented, they are unsupported. :-)
The 8080 used a network of internal gates to decode its instructions.
Since chip real estate was so expensive back then, they minimized the
number of gates used. This meant that they didn't define every possible
opcode (there are unused opcodes), and that one instruction could have
more than one opcode (two opcodes could execute the same instruction).
These are only minor annoyances.
But there is a more serious problem. Some undefined opcodes only
partially implement an instruction. For example, it might load a
register with a value from the data bus, but not enable the data bus
receiver. Thus the register gets loaded with whatever data is "floating"
on the bus from the last operation. The action of the instruction is
thus application sensitive. If your data bus has pull-up resistors it
might load "FF"; if the bus is floating it might load whatever was on it
from the last read operation.
Different chip manufacturers did their own gate minimization, which
could result in different operations for the undocumented instructions.
Some would be deliberate enhancements, others just different accidental
bugs.
Finally, many newer CPUs have "secret" instructions that manufacturers
use for testing. If executed, they put the chip in strange modes, which
alter the execution of further instructions (like until the next Reset
or Power-Up). The 8080 is old enough that it doesn't have any, but many
newer chips do.
Thus it is best to avoid these instructions if you have any desire for
your software to work consistently on different computers.
--
Lee A. Hart Ring the bells that still can ring
814 8th Ave. N. Forget your perfect offering
Sartell, MN 56377 USA There is a crack in everything
leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen
John Mills
On Wed, 15 May 2002, jim korman wrote:
> John Mills wrote:
> > Right or wrong, none of these codes seems to do anything a _documented_
> > (and presumably guaranteed) code does not already do. Why would you want
> > to use a non-guaranteed code which would only do (at best) what some
> > other, well-known code would do anyway?
> Well I'm not sure about the OP, but I ran into this problem when I was
> writing an emulator for the z80. What should be the "PROPER" behavior
> of the "processor" when presented an illegal (undocumented) opcode!
> Intel and Zilog never address this issue in their documents.
Very good point. Thanks.
- John Mills
Tim Mann
> base10. But turns out if you stuff something besides 0Ah in there, say
> a 0Dh instead, it would do modulo13 conversions. Now you might
> think: a) that's pretty useless; and b) if it by chance IS useful,
> there oughta be another way to do it. It is, there is, but not as
> fast or easy. Just imagine doing variable mod as part of an encryption
> scheme, fer instance. the number base can be 'switched' every
> byte, if you've a mind. Think about a stream of 'random' numbers
> being used to vary the modulus. Decently secure and fast, for it's
> time. Undocumented, of course..
>
> Bill
>
The Z-80 doesn't have a modulus instruction. That would be a form of
division, which is way beyond what the Z-80 has on chip. It has only
addition and subtraction, not multiplication or division.
You must be thinking of the x86 AAM and AAD instructions. See
http://www.x86.org/secrets/opcodes.htm
--
Tim Mann use...@tim-mann.org http://www.tim-mann.org/
Richard Erlacher
you're a real device, you need to know what the real chip does when
it's confronted with a real undocumented opcode. With a static chip,
you can pretty easily stimulate the device with a few parallel ports
and record the response with 'em as well.
There are several opcodes that are undocumented for the 6502 that do
things that would take several other "documented" instructions to
accomplish, hence that could be useful. I don't know that anyone has
studied them extensively enough to verify this, but I guess it's a
mite late now.
Dick
On Thu, 16 May 2002 10:06:47 -0400, John Mills <jmm...@telocity.com>
wrote:
>Jim -
B'ichela
> There are several opcodes that are undocumented for the 6502 that do
> things that would take several other "documented" instructions to
> accomplish, hence that could be useful. I don't know that anyone has
> studied them extensively enough to verify this, but I guess it's a
> mite late now.
try them with my Commdore 64. Do they also work with a 6510? or only
the 6502? If the 6502 then my Vic-20 will have a little fun.
--
B'ichela
Ruud Baltissen
> Really? Where can I find these? I would like to see them
> and try them with my Commdore 64. Do they also work with
> a 6510? or only the 6502? If the 6502 then my Vic-20 will
> have a little fun.
The 6510-core is the same as the one of the 6502, thus including the illegal
opcodes.
For more info:
http://www.funet.fi/pub/cbm/documents/chipdata/6502-NMOS.extra.opcodes
I only wonder how this subject landed on this CP/M newsgroup.
And if anyone wonders what I'm doing here, I own a Bondwell 14. And don't
forget the C128 can run CP/M as well :)
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| http://Ruud.C64.org
Anders Carlsson
> Richard Erlacher wrote:
>> There are several opcodes that are undocumented for the 6502
> Really? Where can I find these? I would like to see them and
> try them with my Commdore 64. Do they also work with a 6510?
Here's two links I knew off-hand:
ftp://ftp.funet.fi/pub/cbm/documents/chipdata/6502-NMOS.extra.opcodes
ftp://ftp.funet.fi/pub/cbm/documents/chipdata/64doc
After doing some Internet search, you might be able to find yet more
references, practical examples etc.
--
Anders Carlsson