Undocumented Z80 instructions

[ladislau szilagyi]

Hi,

while writing a Z80 assembler program, I'm confronted frequently with a annoying issue: I would need one more register to store a byte, but unfortunately, I must use the existing ones: A, A', B, C, B', C', D, E, D', E', H, L, H', L', ...

Or, perhaps, there are more registers available?

Here, the 'undocumented' Z80 instructions might help... they show how to use the low/high part of IX/IY.

For example:

LD    A,IXL

LD    IYL,C

ADD   IYH

INC   IXH

where:

IXL = low part of IX

IYL = low part of IX

IXH = high part of IY

IYH = high part of IY

A very good document describing the Z80 undocumented instructions may be found here: http://www.z80.info/zip/z80-documented.pdf

And Z80AS (and perhaps other assemblers too...) accepts these 'undocumented' Z80 instructions ( see the full list of Z80 instructions accepted by Z80AS here: https://github.com/Laci1953/Z80AS/blob/main/tests/z80instr.as )

These 'extra' instructions are really working... with the disadvantage of being larger (and slower) compared to the "official" Z80 instructions.

But, in many situations, I used them as the required solution...

 

regards,

Ladislau

[Alan Cox]

> These 'extra' instructions are really working... with the disadvantage of being larger (and slower) compared to the "official" Z80 instructions.

And the fact they cause a jump to address 0 on Z180, and in some cases
do different things on Z280.

Alan

[ladislau szilagyi]

Ok,

my message concerns ONLY the Z80 processor. Not Z180, not Z280, not e-Z80, not Z8000.

Now, any comments about using 'undocumented' Z80 instructions on Z80?

Ladislau

[Alan Cox]

On Thu, 8 Jun 2023 at 12:08, ladislau szilagyi
<ladislau...@euroqst.ro> wrote:
>
> Ok,
>
> my message concerns ONLY the Z80 processor. Not Z180, not Z280, not e-Z80, not Z8000.

You forgot to put that in your message.

> Now, any comments about using 'undocumented' Z80 instructions on Z80?

It means your code won't run on the others so you are digging yourself
a large hole to fall down. If you are absolutely sure you only have a
Z80 use case and nobody will ever want to move your code to any other
variant then yes they can be useful. This is especially true for more
novice Z80 programmers who struggle with register assignment - which
on Z80 is hard to do well. We did it for some games in the 1980s and
we were in retrospect very lucky that 68000 killed 8bit Z80 home
computers before they went HD64180/Z180. The Apple folks who used
undocumented NMOS 6502 instructions got horribly burned by the Apple
IIe however. MSX was forced to put both a Z80 and an R800 in the same
machine for Turbo-R because of this sort of stuff - and it's one of
the complexities that contributed to its death.

Of course 95% or more of the time the actual thing to do to fix size
and speed is to use a better algorithm in the first place - regardless
of CPU.

It's usually faster and cleaner to restructure the code so you
allocate registers sensibly instead. There are odd exceptions that are
hard to do other ways (notably the shift and load DD CB stuff) but
IX/IY prefixes are expensive and IX+n incredibly so. One thing
programming for other processors teaches you is that you don't
actually need a lot of registers with sensible algorithms.

That way you don't get to have to clean up surprises like

https://github.com/z88dk/z88dk/issues/729

Alan

[ladislau szilagyi]

Hi Alan,

a long time ago, I started my journey in the world of microprocessors, with SIGNETICS 2650.

Then I programmed the Intel 8008, 8080, then Zilog Z80, and the list is very, very long.

There is one important thing I learned (the hard way...) : each processor must be approached using its full set of instructions.

So, when you want to write code for Z180, use the Z180 set of instructions, not its Z80 sub-set. 

Of course, there is the temptation to use Z80 programs on Z180 or Z280, but in my opinion, that's wrong. 

You are practically constraining a more powerful processor to execute only a subset of its possible set of instructions.

What a waste of resources...

About the issue of porting CP/M apps to Z180/Z280, I completely agree with you. You must use ONLY Z80 'official' instructions.

But, if you read carefully the title of this thread, it says 'Undocumented Z80 instructions'. Z80. For Z80. Nothing more.

Ladislau

[Alan Cox]

> Of course, there is the temptation to use Z80 programs on Z180 or Z280, but in my opinion, that's wrong.
> You are practically constraining a more powerful processor to execute only a subset of its possible set of instructions.
> What a waste of resources...

There are two different conflicting things i think here

1. The desire to get absolute best performance out of a given device.
Sometimes (as with games programming on the Commodore 64) there's
really not much choice. Often if you can localize it a specific device
it's also not so bad (eg the Nascom Fuzix floppy driver has to use in
f,(c) to make the high density disk timings) because it's isolated
from anything that affects other systems.
2. The need to maintain multiple versions of software and to be able
to cope with all your customers being very angry people when their old
stuff breaks on the new system.

In the real world #2 has caused people huge amounts of pain, from all
the Apple II people burned by ignoring Apple warnings about illegal
instructions, through the TRS80 people buirned by XLR8R cards (not so
many most TRS80 code was well behaved), the Macintosh people burned by
ignoring "don't put other crap in the top of the address registers as
it's not safe for the future", the Amiga and ST people who ignored all
the warnings about future products and 68010+ processors and so on.

> About the issue of porting CP/M apps to Z180/Z280, I completely agree with you. You must use ONLY Z80 'official' instructions.

Most CP/M programs are pure 8080, or 8080 with LDIR. Whilst there is
very little retro 8080/8085 there was a fairly large 8080 base in the
past, significantly extended by the fact most older CP/M emulations
and hardware emulations like V.20 8080 support were 8080 not Z80 or
8085.

> But, if you read carefully the title of this thread, it says 'Undocumented Z80 instructions'. Z80. For Z80. Nothing more.

"Undocumented Z80 instructions". As a first language speaker '"For Z80
nothing more" isn't implied by the title so I thought it was important
that people consider the consequences of the decision. There are times
it is great - you kind of know that nobody will release a new Amstrad
CPC 64 or Apple IIc at this point, and if you are writing stuff solely
for your own board you get to make the rules.

Alan

[Dylan Hall]

Thanks Alan and ladislau, this is an interesting topic.

I was wondering, are the undocumented instructions available on all variants of the Z80? For example NMOS vs CMOS, or something more exotic like a ZX Spectrum Next which I think implements the Z80 in an FPGA.

Dylan

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAK9X0%2BuCaFXPdo5d%3D-h8j3B054WgC4a0udT37v-RdNeHda7QVA%40mail.gmail.com.

[Alan Cox]

On Thu, 8 Jun 2023 at 21:07, Dylan Hall <dy...@deedums.com> wrote:
>
> Thanks Alan and ladislau, this is an interesting topic.
>
> I was wondering, are the undocumented instructions available on all variants of the Z80? For example NMOS vs CMOS, or something more exotic like a ZX Spectrum Next which I think implements the Z80 in an FPGA.

The CMOS Z80 and NMOS Z80 differ meaningfully in only one undocumented
instruction. The nonsense out (c) decode produces 0xFF on one and 0x00
on the other. Apart from one game I've never seen it matter if you put
a CMOS CPU in a ZX Spectrum. (Electrical compatibility is a whole
different saga and in general CMOS parts into NMOS sockets requires
detailed analysis).

The interrupt bug in the NMOS Z80 actually matters more than any
undocumented instruction misbehaviour.

The ZX Spectrum Next is a T80 core with some fixes. It's almost
equivalent to a Z80 but it differs in some undocumented behaviour last
time I checked because the T80 does not correctly set the Z flag on LD
A,I or LD A,R and I think maybe some other oddments. However it was
designed to execute all the undocumented instructions as the Zilog
part and they also took care to add the ZX Next extra instructions as
ED operations that were useless nops that didn't appear in any
Spectrum code known.

There are subtle flag differences between the soviet clones and the
real Z80, and if you are willing to poke into very odd places between
NEC and Zilog parts. None of these are likely to be hit in the real
world and their only use in general is writing CPU type detection
code.


Alan

[Tadeusz Pycio]

There is another problem, CMOS processors from NEC and Toshiba do not pass the ZEXALL test correctly.

[Alan Cox]

On Thu, 8 Jun 2023 at 22:23, Tadeusz Pycio <ta...@wp.pl> wrote:
>
> There is another problem, CMOS processors from NEC and Toshiba do not pass the ZEXALL test correctly.

The weird and/or flag bit behaviour for unused flag bits is
fortunately not something that will break anyone (and it even differs
on some licensed Z80 parts). The later upd9002 also only implements
the documented Z80 instructions and is a weird beastie as it can run
both 8086 and Z80 code.

Alan

[ladislau szilagyi]

Hi,

about the pitfalls of reusing old 8080 code on Z80 based computers, here are two examples, taken from the RC2014's BIOS, my version:

(old 8080-like code is commented-out)

-----------------------------------------

;            LD  C,4
;rd4secs512:
;            LD  B,128
;rdByte512:
;            in  A,(CF_DATA)
;            LD  (HL),A
;            iNC  HL
;            dec  B
;            JR  NZ, rdByte512
;            dec  C
;            JR  NZ,rd4secs512

    ld bc,CF_DATA
    inir
    inir

-----------------------------------------

match:
            ;copy data to or from buffer
            ld a,(seksec)       ;mask buffer number
            and secmsk          ;least signif bits
;
;            ld l,a              ;ready to shift
;            ld h,0              ;double count
;            add hl,hl
;            add hl,hl
;            add hl,hl
;            add hl,hl
;            add hl,hl
;            add hl,hl
;            add hl,hl
;
    ld h,a
    ld l,0
    srl h
    rr l
;
;                               HL has relative host buffer address

-----------------------------------------

But, of course, the old 8080-like code works too.

Ladislau

[Sławomir Zegarliński]

Hi.

 I don't think anyone will be building an i8080 system, but the use of Z80 code on Z180 systems is likely. There is a solution to this problem: just write an TRAP Interrupt handler  that will execute the "unofficial" command in a different way.   

Kind regards, Zegar.

[ladislau szilagyi]

Hi Zegar,

I do not have a Z180 - based computer, nor a Z280 one ... sorry.

But I have several Z80-based machines... so I'm focused only on developing software for these computers.

Ladislau

[Alan Cox]

On Fri, 9 Jun 2023 at 09:37, Sławomir Zegarliński <zegar...@op.pl> wrote:
>
> Hi.
> I don't think anyone will be building an i8080 system, but the use of Z80 code on Z180 systems is likely. There is a solution to this problem: just write an TRAP Interrupt handler that will execute the "unofficial" command in a different way.

"just"

It's actually really complicated to get the flags right and actually
impossible to make 100% compatible. It's a very useful tool for
printing up "Sorry this code sucks and won't work on your machine"
messages but the emulation is really tricky, really slow and for code
that has exactly counted the stack size needed, is actually
impossible.

Alan

[Kevin Boone]

Do these unofficial Z80 instructions generally work on Z80 emulators? I don't think I'd be inclined to use them myself, because I'm not a sufficiently competent assembly-language programmer to get much benefit from them. But if they don't work on my emulator, I think that would be a show-stopper in any case.

Just my $0.02, of course.

Best wishes

Kevin

[Alan Cox]

On Fri, 9 Jun 2023 at 21:40, 'Kevin Boone' via RC2014-Z80
<rc201...@googlegroups.com> wrote:
>
> Do these unofficial Z80 instructions generally work on Z80 emulators? I don't think I'd be inclined to use them myself, because I'm not a sufficiently competent assembly-language programmer to get much benefit from them. But if they don't work on my emulator, I think that would be a show-stopper in any case.

It tends to depend on the emulator. Z80Pack pointedly did not support
them and I think still doesn't support most of them as it's designed
to be fast and run on small devices. Fuse on the other hand is
designed to run ZX Spectrum games so is pretty much a cycle perfect
replica of the original.

In the FPGA space the T80 core emulates the undocumented stuff very
well, but there are other cores that don't because they were designed
for speed or for minimal size.

It varies.

The EmulatorKit RC2014 and RCbus emulation uses libz80, and a modified
libz80 for the Z180 so should get the undocumented behaviour right in
both cases.

Alan

[Phillip Stevens]

On Saturday, 10 June 2023 Kevin Boone wrote:

Do these unofficial Z80 instructions generally work on Z80 emulators? I don't think I'd be inclined to use them myself, because I'm not a sufficiently competent assembly-language programmer to get much benefit from them. But if they don't work on my emulator, I think that would be a show-stopper in any case.

The z88dk-ticks tool emulation of the z80 undocumented instructions is complete and they’re counted accurately. But the actual use of undocumented instructions has been minimised because of the z180, ez80, and rabbit non-support. The only real exception is the genmath floating point library, which uses undocumented instructions extensively and therefore is not usable outside z80 machines.

OTOH, we’re bought in to the 8085 undocumented instructions entirely, as they’re “game changers” for efficient Intel code and there are no negative flow on effects from using them. The sccz80 compiler will generate them, and the peephole optimisation system is set up to replace z80 instructions with the much better 8085 alternatives whenever possible. I’ve summarised some of what we did here. 

Phillip