Undocumented commands
ZXNet echo conference «code.zx»
Hello, Vitamin
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.)
Hello, lvd
lvd> Well, sorry, inf was never undocumented, at least
lvd> least in branded/translated from branded docks!
A command is undocumented if there is no established mnemonics for it. Yes
Ivan Roshchin once said. I won’t say that this is a quote, because... I'm afraid of something
make a mistake :) But it seems like a sober thought.
Hello axor
not documented - only means that it is not documented in
official document. That's all. Currently all undocumented commands
well documented. Mnemonics are the tenth thing. I don't like mnemonics
specific asma - you can use your own through macro commands and define.
Hello Max Wood
Max> not documented - only means that it is not documented in
Max> official document.
That's why we call it that.
Max> At the moment, all undocumented commands are good
Max> are documented.
How can this be? Some kind of contradiction.
Hello, Vladimir Kladov
Vla> At the moment, all undocumented commands are good
Vla> are documented.
So help me find this documentation, please!!!!
Hello axor
Sean Young. The Undocumented Z80 Documented. That's what it's called. z80-documented.pdf.
It was on worldofspectr.org if you can’t find it by searching.
Hello, Vladimir Kladov
out (c),0 was used in the zxformat log, on some processors this
the command was not executed
Hello, goodboy
goo> out (c),0 used in zxformat journal, on some processors
goo> this command was not executed
Which ones exactly?
Hello Titus
Tit> Which ones exactly?
in the format itself (of some kind) it was written that on some processes that
then they set it to KAY, this command output to port #FF.. personally I had one like this
percent in the Pentagon, but I don’t remember how it was labeled..
and they had port #7FFD there (in 3rd format), so the intra did not work...
Hello, Vladimir Kladov
Vla> Accordingly, it’s easy to create a test and write it down according to some thread
Vla> code address
Vla>
Vla> type
Vla> ld c,#FE
Vla> out (c),0
Vla> ret
Vla>
Vla> and call from Vasik. If the border is not made black, then these are the
Vla> processors.
Even 10 years ago MacBuster (according to him) on this test a bunch of percentages
I tried it, the border was black everywhere :v2_rolley
Hello, psb
Accordingly, it’s easy to create a test, write down the codes at some address
type
ld c,#FE
out (c),0
ret
and call from Vasik. If the border is not made black, then these are the processors.
Hello Titus
I remember exactly that Oldman had a pro who misunderstood out (c),0
Hello, Vladimir Kladov
Vla> Sean Young. The Undocumented Z80 Documented. That's what it's called.
Vla> z80-documented.pdf. It was on worldofspectr.org, if you didn’t search
Vla> is found.
Thank you very much. You helped me a lot!!!
Hello Max Wood
It's nice to be thanked. But - pay attention: not everything needs to be believed, even in
this document. For example, an obvious mistake with the duration of the DJNZ team
suggests the possibility of some other typos. In general, I'm not very
I love the pdf format because you can edit it if there are typos
- at least for myself - seems to be a very difficult undertaking. I
tried exporting it to some text format to make
html, such miracles have begun... ALL the letters f in the text have disappeared somewhere,
for example. I gave up on this matter. If it were in HTML format, everything would be simpler, and
much.
Hello, Vladimir Kladov
On www.Z80.info I found version 0.6, 2003. There it was fixed about DJNZ. (There were also
other inaccuracies, but I remember this one). The question about 0.91 remains.
The document itself does not say where his “home” is. Wrong approach: if only
it indicated how to contact the author, or where the latest version is located
document, everything would be simpler.
Yeah, I'm downloading another one. It is reassuring that the source codes in
latex. Maybe this is the last one. That's right, it's her. The question has been removed.
Hello, boo_boo
Hmm, I have 10/13. Version 0.4 2001. Where did you get the new one? I like this document in
I downloaded it from WoS last year.
Hello, Vladimir Kladov
Vla> Hmm, I have 10/13. Version 0.4 2001. Where did you get the new one? I like this
Vla> I downloaded the document from WoS last year.
http://myquest.nl/z80undocumented/
Hello, Vladimir Kladov
Vla> an obvious mistake with the duration of the DJNZ team suggests an o
Vla> the possibility of any other typos. In general, I really don’t like the format
Vla> pdf, due to the fact that you can edit it in case of typos
what about DJNZ? 2 bytes, 8/13 clock cycles, everything seems to be in place (document version
-- 0.91). As for editing, you can download the latex source instead of the PDF, but
in an amicable way - write to the maintainer ;)
Hello MadCat!
The question arose - are there any undocumented commands other than working with
halves of index registers (in older processors Zilog recognized them
documented), in the command tables DD, FD, DD CB, FD CB?
And the second question is whether there are undocumented twins among the teams of the ED 80-ED section
BF (LDI, CPI, INI, OUTI...)?
Hello spensor
Third question.
The hierarchy of command codes is constructed in the following order:
- without prefix, one byte COP;
- commands with the prefix CB, ED, DD, FD, two bytes COP;
- commands with double prefixes DD CB, FD CB, three bytes COP;
It turns out that the prefix hierarchy looks like:
- without prefix;
- with the prefix CB and ED - additions to the main command table;
- with the prefix DD and FD - modification of commands by replacing the register pair HL with IX
and IY. In this case, the modification is performed with a code page without prefixes
(DD(FD) + KOP) and with code page CB (DD(FD) + CB + KOP).
Logic dictates that there should be commands like DD(FD) + ED + KOP. Question -
How are these combinations actually worked out? Or DD(FD) is executed as
NOP, but is the ED + COP command actually executed?
Hello spensor
spe> - how are these combinations actually worked out? Or DD(FD)
spe> is executed as NOP, but the command ED + KOP is actually executed?
Judging by the source code of the emulator, this is true. From the preceding prefix chain
DD/FD is selected last. If the subsequent byte is equal to CB, then the
operations CB,XX, but with index registers instead of HL. But if the next one
byte is equal to ED, then everything is as you said - just the chain of prefixes is ignored
Hello Vitamin
2 Vitamin; Thank you; for the clarification!
Vit> Judging by the emulator sources, this is so.
This is a new approach in exploring the undocumented ;)
Vit> The last one is selected from the previous chain of DD/FD prefixes. If
Vit> the subsequent byte is equal to CB, then the operations CB,XX are performed, but with
Vit> with index registers instead of HL. But if the next byte is equal
Vit> ED, then everything is as you said - just the chain of prefixes is ignored
Then an additional question - how are commands with DD (FD) prefixes processed?
and DD (FD) CB if the command code does not work with the H and L registers - NOP is executed
or we get the same command as without the DD (FD) prefix, but it is executed
longer? This is essentially my first question, but in different words.
Hello spensor
spe> Then an additional question - how are commands processed
spe> prefixes DD (FD) and DD (FD) CB if the command code does not work with
spe> registers H and L - NOP is executed or we receive the same command as
spe> without the DD (FD) prefix, but does it take longer to execute? Essentially it's mine
spe> first question, but in other words.
DD,CB,n,00 = RLC B,(IX+n). and the same with all the first 64 teams of the CB group (RR
C,(IX+n); SLA D,(IY+n)...). Know what they do (obtained experimentally)
way), but how many clock cycles are eaten is another question... For the main commands
groups (without CB or ED) in which there are neither H nor L index prefixes in theory
should count as NOP. They do not affect the ED group (that is, again they are considered
NOPs)
Hello spensor
spe> This is a new approach in the study of undocumented;)
spe>
As they say, practice shows a lot. In particular, quite accurate
Emulation of the processor is sufficient for programs to run. Research
various "spherical horses in a vacuum" makes sense only to identify
emulator. But this is unreliable, since even with real crystals the results
work varies (see topic in this thread)
spe> Then an additional question - how are commands processed
spe> prefixes DD (FD) and DD (FD) CB if the command code does not work with
spe> registers H and L - NOP is executed or we receive the same command as
spe> without the DD (FD) prefix, but does it take longer to execute? Essentially it's mine
spe> first question, but in other words.
I look there and don’t find a single such team - all 32 different teams of this
groups work with IX/IY, but in addition to their main operation (shift/work with
bits) modify one of the 8 internal registers. Total 32*8=256 teams