Talk:Zilog Z80

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Is the NSC800 a "second source" or a "derivative"?[edit]

It's a clone (some sources say there are enhancements, but I haven't found any yet) as far as software is concerned, but has a different pinout with an 8085-style multiplexed bus, so isn't hardware compatible.

If I can find the claimed enhancements, it goes into "derivative".

Ref: https://media.digikey.com/pdf/Data%20Sheets/National%20Semiconductor%20PDFs/NSC800.pdf
Ref: //sci-hub.st/10.1049/ep.1981.0107
64.44.80.252 (talk) 04:19, 9 January 2021 (UTC)[reply]

Bugs: we really should have a source for this[edit]

Under Zilog Z80#Bugs we list a bug that I couldn't find mentioned anywhere else. From the description, it would be a bug, as the User's Manual says that the condition bit C is not affected by OTDR. However, I think that this wouldn't be such a difficult bug for users to run into, and this makes me think that it should be more widely reported around the Internet. Lastly, there's also a slim chance that it may have been a bug in a few chips, not all Z80s.

Pinging Dhrm77 who introduced this section in [1], who claims to have "(...) found the problem described back in 1991 while making extensive use of the OTIR and OTDR instructions (...)": do you remember where you found it described? Did you try and manage to reproduce it? BernardoSulzbach (talk) 18:22, 6 July 2021 (UTC)[reply]

I never found it described anywhere. I had written a program using a lot of OTIR and OTDR and optimized in such a way that the state of the Cy was important. The program wasn't working as expected, and I eventually found out that although the Z80 documentation says that OTDR doesn't affect carry, it in fact does. Furthermore, I wanted to know how it affected Cy. And after many experiments, I found out that it does a spurious compare between the last (or perhaps all) bytes being transferred and the Accumulator, and the result of that compare is what sets or resets Cy. I forgot what I did to solve the problem, either not use Cy to store some information, or save the flags... Also I don't remember which exact processor I was using, it could have been the Mostek equivalent MK3880, the SGS Z84C00, the NEC µPD780, or the actual Zilog Z80 running at either 4Mhz or 6Mhz. And I'm not sure if I tried other processor to determine if the bug exist across multiple versions of the Z80, So it is possible that the bug only exists in some versions. But for anyone who still uses a Z80, it's a very simple matter to verify the problem. I think I remember later trying that bug on a Z180, and found that in fact the bug doesn't exist on that processor. Email me if you have more questions. Dhrm77 (talk) 21:11, 6 July 2021 (UTC)[reply]
Also, I am not surprised that nobody else found the problem. What I was doing was a little special. I had to send a lot of bytes to a particular port, out of order. For example, send 4 bytes in ascending order, then the next 4 bytes in descending order, then the previous 4 in ascending order again, and so on... So I would use OTIR, then add 3 to HL, use OTDR, subtract 17, use OTIR again, and so on... The problem is that there is no SBB instruction for HL, you have to use SBC which uses Cy. So Cy needs to have the right value, otherwise you are sending the wrong bytes. This isn't typical programming. So no wonder no-one else found the problem. Dhrm77 (talk) 21:27, 6 July 2021 (UTC)[reply]
In this forum thread (in German) people tested various CPUs and found that the orignal Zilog Z80 does indeed have a bug with the CY handling for the OUTI opcode while the East German U880 and the Romanian MMN80 do not. Drahtlos (talk) 22:02, 6 July 2021 (UTC)[reply]
Interesting... My problem was with OTDR, not OUTI, but the 2 instructions are related, and neither should affect the Carry. That's interesting how they use that bug to distinguish between 2 brands of processors. Perhaps someone could gather more information about that, and expand that section. Dhrm77 (talk) 01:50, 7 July 2021 (UTC)[reply]

TLCS 90[edit]

is not a Z-80 compatible device. This device has all instructions Z-80 have, but instruction binary bit-assigns are completely different, and does not have binary compatibility. 2400:4051:4CE0:C400:922B:34FF:FED6:A16D (talk) 11:09, 15 August 2021 (UTC)[reply]

Merge from Zilog Z280[edit]

Per User_talk:Mark_viking#Zilog_Z280 and Wikipedia:Articles for deletion/Zilog Z380. @Mark viking

Quite a few other entries in Category:Zilog microprocessors could use similar consideration. Piotr Konieczny aka Prokonsul Piotrus| reply here 00:44, 11 August 2023 (UTC)[reply]

@Pavlor and @Gábor who also participated in Wikipedia:Articles for deletion/Zilog Z380 Piotr Konieczny aka Prokonsul Piotrus| reply here 02:10, 14 August 2023 (UTC)[reply]
No contest. Redirects are cheap and can be turned back into an article, if more sources are found. Pavlor (talk) 05:01, 14 August 2023 (UTC)[reply]