Z80 alternate opcodes

Z80 alternate opcodes

Post by Lee Har » Tue, 08 Mar 2005 17:08:15

I was working on a Z80 program tonight that requires precise timing, and
so was doing the usual juggling code around and T-state cycle counting.
I ran into something I hadn't encountered before.

At one point I was using the LD (nn),dd instruction. It writes the
2-byte contents of a register dd (which can be BC, DE, HL, or SP) to
memory location nn. It is defined as taking 20 T-states.

Initially, I used LD (nn),DE. But in debugging, I discovered it should
have been LD (nn),HL. I patched my program (changing ED 53 nn nn to ED
63 nn nn), tested it, and it ran correctly.

But when I changed the source and reassembled it, the timing was wrong.
Why? Because there are *two* ways to assemble the LD (nn),HL
instruction. One is the ED 63 nn nn I happened to use in ZSID; it
executes in 20 Tstates. The other is the old 8080 SHLD (nn) instruction,
which assembles as 22 nn nn and takes only 16 T-states.

I have 3 different Z80 assemblers (M80, MACRO80, and SLR180), and
couldn't find anything in them that lets you specify which code to
assemble when there are multiple ways to encode the same mnemonic.

But assemblers that used the "extended 8080" mnemonics for the Z80 *do*
discriminate between the two.

It looks like there are legal instructions that you can't assemble
(short of defining them as a string of DB... statements). Is this true?

In my case, it turned out not to be a roadblock; I could add a NOP which
added 4 T-states and made the execution time work out right again. But
it made me wonder if there may be cases in which you needed one of the
alternate codings for an instruction. If so, how do you deal with them?

Z80 alternate opcodes

Post by Bill Lear » Tue, 08 Mar 2005 20:37:46

The joys of discovery, eh?

I can't recall ever running into a case where we actually had to do this, but we
did talk about it over coffee a couple of times, usually each time one of the
new guys discovered it. One of the guys went off one night (we worked nights)
and came back the next day with some macros to generate the code. As you say,
he used DB statements to get the right codes. I don't recall from this vast
distance in time quite how, but it included an argument for whether he wanted
the long or short op-code. This was using the Zilog assembler.

- Bill


Z80 alternate opcodes

Post by nospa » Tue, 08 Mar 2005 23:39:15

On Mon, 07 Mar 2005 08:08:15 GMT, Lee Hart < XXXX@XXXXX.COM >

Extended 8080 assemblers get it right, the 4byte instruction you used
while present in all Z80s is not the nominal z80 instruction. The
result is some redundent mappings occur and the long case actually
takes longer by 4 states due to the no-op case it adds to the front.
The fact that the assembler derives an apparently workable opcode
does not make it a vaild assembly output. I have three older Z80
assemblers and the 3byte case is the result as expected. The
avocet z80/780 assembler I have does not even allow the unofficial
z80 opcodes. I've been one to use the z80 unofficial opcodes
sparingly and by hand due to redundent codings and in some cases
questionable results.


Z80 alternate opcodes

Post by nospa » Wed, 09 Mar 2005 01:16:40

On Mon, 07 Mar 2005 08:08:15 GMT, Lee Hart < XXXX@XXXXX.COM >

As an addendum to this Gaby's site and a few others has Sean Youngs
work on undocumented opcodes and I consider it the most reliable
as well as concise on the subject.

If there is interest/request I have the PDF [51 pages!] version I can
post or Email. Rather than do that I'd say, go to Gaby's site first!


Z80 alternate opcodes

Post by wild bil » Wed, 09 Mar 2005 02:01:00

On Mon, 07 Mar 2005 08:08:15 GMT, Lee Hart < XXXX@XXXXX.COM >

Yes. Anything where a modulus is defined in the instruction can
pretty much be hacked into virtually ANY other number base by
simply changing the given modulo to the one you want. You can't
assemble it that way, but you can always 'db' it in.

Try it in a de *** .... single-step over the modification to
see if it works ..... base-5? base-13? whatever. Defaults
tend to be 10(d) and 16(d), of course.(or, 0A(h) and 10(h))
I guess I could clarify - you're actually looking for the sort
of instructions that contain a 0A or a 10 (hex) to begin with.

But bear in mind that if you're gonna decimal adjust something
like a number 5 by base-3 it's maybe gonna come out a 12 or
whatever. Weirdnesses like that. Watch the paired register
for any overflow, depending on how they built the chip.

The possibilities for on-the-fly encryption/decryption are mind
boggling. Something to do with the key altering the modulus
could easily produce pretty tough to crack stuff at pretty good
speed compared to doing it in software. Depending on what
you do with the key.

Did anyone else out there ever get the decryption package
from that guy who was selling a stock data feeds thingy?
Damn handy de- X-OR tool in there - why do so many lazy
programmers somehow think simply X-OR'ring a stream
or block is secure? Because it was hard for them to code?


Z80 alternate opcodes

Post by nospa » Wed, 09 Mar 2005 04:01:57

On Mon, 07 Mar 2005 10:58:52 -0800, Charles Richmond

^^^^^^^^^^^^^^^^^^what did this say?^^^^^^^^^^^^^^^^^^^^^^^

Ah, reading problem? It is on Gaby's site and several others.
I only offered in the rare case someone just can't seem to find it.

There are no shortage of Z80 sites. Here are a few.




http://www.yqcomputer.com/ (this is Seans site)


Z80 alternate opcodes

Post by s_dubrovic » Wed, 09 Mar 2005 08:36:20

'stock data feeds thingy'
DTN? xor'ing the stream with 25h?

Z80 alternate opcodes

Post by Roger Ivi » Wed, 09 Mar 2005 11:37:58

Sounds to me like you're talking x86 rather than z80.

IIRC, there were some 3rd party x86 chips that ignored the modulus and
some people got in trouble because they relied upon them. I'm thinkin
NEC V20 here, but I might be wrong.
Roger Ivie
Version: 3.12
GCS/P d- s:+++ a+ C++ UB--(++++) !P L- !E W++ N++ o-- K w O- M+ V+++ PS+
PE++ Y+ PGP t+ 5+ X-- R tv++ b++ DI+++ D+ G e++ h--- r+++ z+++

Z80 alternate opcodes

Post by Lee Har » Thu, 10 Mar 2005 02:22:06

Yes, they work.

But this one *is* a legal "official" Z80 instruction, and is documented
in all the Zilog, Mostek etc. literature I have. I would expect an
assembler not to accept illegal opcodes; but I'd say it was a bug if it
did not allow all legal instructions. While the shorter/faster version
of an instruction is usually preferred, there may be special cases where
the long/slow version is the correct choice.

Anyway, it was an interesting discovery. I was just surprised that I
never encountered it before!
"The two most common elements in the universe
are hydrogen and stupidity." -- Harlan Ellison

Z80 alternate opcodes

Post by nospa » Thu, 10 Mar 2005 05:34:40

On Tue, 08 Mar 2005 17:22:06 GMT, Lee Hart < XXXX@XXXXX.COM >

The neumonic construction is legal but the ED prefix is bogus
only for that pair, reason 8080 is horribly asymetric:

SHLD addr [22 nn nn]
LHLD addr [2a nn nn]

Those are 8080 instructions and the Z80 executes 8080 instruction set
as native.

All of my Zilog docs (AND NEC for the 780 clone) have:
22 LD (nn),HL
The reverse is:
2a LD hl,(nn)

Now the 8080 lacks a both of other symetrical ops for other register
pairs and those require the Z80 prefix to differentiate them from the
base 8080 instructions. The base 8080 instruction set has only
10 instuction codes that are not mapped those being:

08, 10, 18, 20, 28, 30, 38, CB, D9, DD, ED, FD

The 8085 used 20 and 30 for RIM and SIM.

Those are always fun.


Z80 alternate opcodes

Post by wild bil » Thu, 10 Mar 2005 15:11:39

Not sure what that means.....

There was a guy selling a package - hardware (kit) and software
that you could use, if you were so inclined, to sort of 'look' at
data feeds of financial information like stock prices, etc. Or,
anything else you might happen across that just didn't
look 'plain' enough.

In the software was a really cool tool for shall we say
de-manipulating data at the binary level, as in, you could
shift left or right any number of bits in the serial data
stream. If you've ever tried it, you know what this might
look like. And among other things was the ability to
XOR just about anything anywhere, meaning if that
stream DID have XOR'd stuff it might just pop out if
you happened to sync somewhere along the line.

It had maybe a dozen manipulations, bit inversions,
shifting, XORing, that sort of thing. Capture or load in
a chunk of misc. bits and start teasing around on them.
Interactive, on screen (as much as you could display)

Let's say you had a 179x disk controller, and a really
mucked up track. You could go to the appropriate
address where, say, a single bit wasn't getting read,
and sort of insert one, and all of a sudden everything
down the line popped back to normal again.

Just can't remember what it was called. Maybe DataPro?

And, of course, you just might want to either a) load in any
old file with encrypted keys or user info/passwords and
sort of play around with it; or b) poke around in your own
machine's memory to see if any old program you just
happened to be running was stashing any odd bits of
info somewhere.....or maybe even, weren't running but
would like to, if you could just get past some sort of
'none shall pass' thingy ......


Z80 alternate opcodes

Post by s_dubrovic » Thu, 10 Mar 2005 23:15:23

wild bill wrote:
Oh, I thought you might be refering Data xmission Network, a
stock/commodities data service provider. At that time they offered a
satellite dish receiver/video monitor. It was a z80 based system. It
had a rs232 port, which passed thru the raw feed, which you could
connect to a PC. Their software development kit was hamstrung, you
didn't get the source for the data decode algorithm, you got a linkable
obj library which was limited in functionality. The 1st thing I
realized from studying dumps of the raw feed was that the bytes xor'ed
with 25h to mask ascii relationships. The packet header field decode
was another issue. But you are talking about something else, a
software tool. The 'easter egg' in cpm-86 uses abit more complicated
mask where the prior result is xor'ed with the next data byte. It is a
varing variable instead of a constant i.e. 25h.

Sounds like quite a handy package for data recovery.