Source of origin of Z80 CMOS die

[Tadeusz Pycio]

I'm interested in the history of the Z80, so sometimes I ask the odd question. A user Reddit suggested that Zilog's CMOS dies came from Toshiba. Probably based on the fact that Toshiba released their CMOS processors in 1984 and Zilog a year later. I base my experience on tests (ZEXALL) which contradict this, as I have not been able to find any other information about this fact. All Zilog NMOS and CMOS processors tested pass the ZEXALL test, and in the case of Toshiba and NEC ICs, the programme raps an error with the <daa,cpl,scf,ccf> test. My tests may be subject to error as I was testing Z80 processors from the late 1990s so Zilog had time to develop their own dies. If anyone has a 1985/86 Zilog CMOS processor and has the opportunity to test it with ZEXALL and share the results, I would be grateful. As this was the only period where Toshiba matrices might have appeared, if this is true.

There is another interesting topic to explore is the Sharp LH5080 CMOS chips. Unfortunately, here too I do not have access to such chips. These processors were produced in two versions normal and with reduced power mode (prefix L). I'm curious about the ZEXALL test result of these processors, and most curious about whether the undocumented OUT(C), 0 - ($ED,$71) instruction which maybe(?) was intended to detect reduced power mode. NMOS processors respond $00 and CMOS processors respond $FF, so CMOS LH5080(A) chips should respond like NMOS and LH5080(A)L chips like CMOS. But this is just my speculation.

If anyone has such ICs and would be willing to take the time to check them and share the results, I would be extremely grateful. Perhaps someone has some documents that can answer these questions?

[Tom Storey]

I was going to quote you in a reply to that person, but I CBF getting in to an argument on Reddit. 😂

It seems very much like an urban legend at this stage, at least until someone can come up with something.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/43395597-3fd9-4b90-81f6-e412581e13e7n%40googlegroups.com.

[Tadeusz Pycio]

It seems unlikely to me that Zilog would use Toshiba dies. However, this cannot be ruled out, as Toshiba at the time was producing the T6497 chip, which later also appeared in the Zilog range as the Z84C60. Which indicates a collaboration between these companies at the time. Toshiba later changed the name of this chip to TMPZ84C60. It seems that only these two manufacturers produced this chip. Therefore, I am not sure how it really was.

[Bill Shen]

If you look at die photo of Z84C00, you can see the copyright dates of 75, 87, 91 Zilog.  So Zilog declared these were years of significant works on Z84C00.  Toshiba may have contributed, but Zilog was claiming the copyright.

  Bill

[Tadeusz Pycio]

I have adapted the Z80 tester program for the RCBus in the SCM environment. It requires an I/O module e.g.SC129 where the results are presented (as in the original tester). Below is the header part of the program and attached is the HEX file (running via G 8000). I will try to add procedures to detect Toshiba and NEC CMOS chips.

;==================================================================================================
; Z80 Tester
;
; Hardware: https://oshwlab.com/vitalian1980/z80-tester
; Software: https://bitbucket.org/rudolff/z80-tester/src/master/
;
; Additional code to detect U880 by kinzi @ Forum64 based on
; https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=11288
;
; Blink codes:
; 1 x = Z80 NMOS
; 2 x = Z80 CMOS
; 3 x = U880 NMOS (with litte pause between first and second blinking)
;       U880 CMOS (U84C00) does blink two times like Zilog CMOS CPU
;==================================================================================================

[Alan Cox]

You probably want to test for ez80 and Z180 first at least as they
will trap on invalid instructions

Z180 you can check with DAA
eZ80 by using a prefix and seeing whether it makes the instruction a byte longer

https://github.com/EtchedPixels/FUZIX/blob/master/Applications/util/cpuinfo-z80.S

is the approach I have been using which can also detect all but the
most recent T80 and spots some buggy emulations too

[Tadeusz Pycio]

Hi Alan,

Thank you, this will definitely make my job easier. I'll only be able to focus on detecting differences in Japanese Z80 processors built with CMOS technology (although I won't be able to test Sharp's CMOS chips anyway, as I don't have them). And so from a simple tester it has suddenly become complex ;-)

[Sergey Kiselev]

This thread got me interested. And I actually wanted get answers to some of the same questions you're having.

Specifically:

• Who designed the CMOS version of Z80? Or at least, are Toshiba TMPZ84C00 and NEC D70008AC CMOS versions of Z80 the same as Zilog Z84C00 CPU
• Are soviet KR1858VM1 actually originated from East German MME U880 chip, or were independent development or clone of Z80
• Is the German Thesys Z80 CPU a continuation of U880, or a licensed Z80? The story was that Zilog allowed Thesys  to produce Z80, and recruited them as Zilog distributors.

I did come across the Z80 tester mentioned above. But unfortunately, it relies on an I/O port connected to the LEDs as a part of the CMOS vs. NMOS test. The results of the test are not actually available in the code, but only as a visible LED output.

So I wrote my own z80type utility.

Implementation details:

• Distinguishing between NMOS and CMOS requires writing and I/O port and reading the written value back
• The utility uses SIO interrupt vector register to do this test. This register is available on RCBus/RC2014* systems with SIO modules.
• The utility can be modified to use another read/write I/O port, that will return the value written to it, or at least one bit of that value, ideally without disturbing the system's operation..

Testing results (some surprises here):

• All CMOS chips test the same regardless of the manufacturer. This likely tell that a single entity did CMOS redesign of Z80, and others reused the design. (It wouldn't be the only occurrence. For example, Harris designed the CMOS versions of 8088, 8086, and support chips, that Intel later manufactured)
• Soviet  KR1858VM1 chips test as Z80 NMOS. This contradicts the story above. They are not a development of U880, unless someone specifically fixed the OUTI instruction behavior...
• Thesys Z80H tests as MME U880... no surprises here.

Thanks,

Sergey

P.S. Alan gave some ideas to add detection of other Z80-compatible CPUs... Feel free to contribute to the code!

[Tadeusz Pycio]

Hi Sergey,

To distinguish between CMOS chips, one should (I think) use the SCF/CCF test, because the TMPZ84C00 and D70008AC chips in the ZEXALL test do not pass the <daa,cpl,scf,ccf> part correctly, unlike the Zilog CMOS chips. It is intriguing that the NMOS NEC D780C chips pass this test. It is possible that the NEC CMOS chips are licensed from Toshiba, which is why this "bug" manifests itself in them. I still believe that the Zilog dies are their own design. I suspect the STM Z84C00 chips will behave in the same way as Zilog (SGS had already licensed the Z80 family chips before the merger with Thomson).

It is highly likely that the first Soviet Z80s came from East Germany before they developed their own clone. This was the practice in the Eastern Bloc, the Polish i8080 initially also had Soviet silicon, before the technique of producing their own design was industrially mastered. I wonder where microELECTRONICA's Romanian Z80 design came from.

[Sergey Kiselev]

Tadeusz,

That's an interesting piece of information.

Does this describe the test correctly?

https://mametesters.org/view.php?id=2701

https://scratchpad.fandom.com/wiki/Z80

I'll try adding the tests to my utility.

I agree, that it is possible that first soviet K1858VM1 (and T34VM1?!) used East German U880 silicon. This not seems to be the case in two of K1858VM1 chips that I have - date codes: 9305 and 9306, so they were manufactured a bit earlier than what the article describes.

Thanks,

Sergey

[Tom Storey]

Has anyone drawn out a family tree of the Z80 and it's clones and reproductions? Sounds like it would be several layers deep! If it's even possible...

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/2292cd76-309e-4a1d-9920-3737dadbdc23n%40googlegroups.com.

[Tadeusz Pycio]

Hi Sergey,

Nice collection, mine is more modest as I don't have the layouts of the former Eastern Bloc. We have similar gaps in the collection - the STM & Sharp CMOS and the Rohm BU18400A chip.
I think the key to solving the puzzle of the OUT (C),0 instruction would be to be able to test both variants of the Sharp CMOS processors. Especially as the MAME test link you provided suggests that these processors were from Zilog (I previously thought they were Toshiba).

@Tom
Good idea with this tree, only it would be difficult to fill it because of the lack of information (as evidenced by the reason for this thread). However, I like the idea.

[Sergey Kiselev]

I've added detection of CMOS CPU manufacturers - Zilog/ST vs. NEC/Toshiba.

There is indeed a difference in SCF(STC) instruction output.

My test code is (8080 assembly):

LXI D,2800H ; SET A REGISTER BITS 3 and 5
PUSH D
POP PSW ; MOVE TO A and FLAGS
STC ; SET CARRY: FLAGS = FLAGS | 1
; DEPENDING ON THE CPU TYPE THIS ALSO CHANGES BITS 3 AND 5:
; ZILOG AND LICENCED CLONES: FLAGS = (FLAGS | A) & 28H
; NEC (AND TOSHIBA?): FLAGS = FLAGS & A & 28H
; TOSHIBA T9769C: FLAGS = (FLAGS & 28H) | (A & 8)
PUSH PSW
POP D ; NEW FLAGS IN D

Note, the comments above regarding NEC/Toshiba are copied from this MAME issue, and are likely incorrect. Here is what I see:

On Zilog CMOS CPUs I get 0x29 in FLAGS, that is they copy bits 5 and 3 from the register A and sets bit 0 (CF)

On NEC/Toshiba CPUs I get 0x09 in FLAGS, that is they copy bit 3 from the register A and sets bit 0 (CF)

Looks like a lot of discussions about this topic is related to the "proper" emulation. And I am totally not sure how many people actually tried testing the behavior on real hardware.

--Sergey

[Tadeusz Pycio]

Good work, there was a lack of such a tool, which generated various urban legends about the origins. I have found LH5080L chips on eBay and will try to order one, but this will not solve my dilemma as to whether the LH5080(A) in this test will behave like an NMOS (this is my speculation not backed up by any evidence), but it will confirm where the Sharp chips were licensed from. I don't think it is possible to find any other differences between Z80 clones from the software side, here you would have to open up such chips and compare their silicon. Arguably such activities were carried out by Zilog at one time, but there is no information on this.

[Alan Cox]

On Wed, 1 May 2024 at 20:19, Tadeusz Pycio <ta...@wp.pl> wrote:
>
> Hi Sergey,
> To distinguish between CMOS chips, one should (I think) use the SCF/CCF test, because the TMPZ84C00 and D70008AC chips in the ZEXALL test do not pass the <daa,cpl,scf,ccf> part correctly, unlike the Zilog CMOS chips. It is intriguing that the NMOS NEC D780C chips pass this test. It is possible that the NEC CMOS chips are licensed from Toshiba, which is why this "bug" manifests itself in them

It's some undefined bits that could simply depend upon any stray
charge which may in turn depend on the exact process and materials
used at each fab. I don't think you could conclude a mask change
occurred from that without comparing them physically. I mean - why
would they change it - it's totally undefined and obscure to the point
nobody discovered it for decades.

Some of the other things like the flag differences in block ops on the
Z80, and the differing behaviour of ANA and ANI on Soviet 8080 clones
on the other hand do point to them being really different, especially
ANA/ANI where they implemented the behaviour anyone would have
expected (as did AMD with the 9080) not the peculiar results the 8080
produce.

Alan

[Tadeusz Pycio]

Admittedly, without a physical comparison of the silicon, it is not possible to give a definite verdict. However, there are indications that these reproducible differences are noticeable. Zilog manufactured its chips in several factories, Italian SGS also used its own FAB, and these chips do not exhibit the characteristics of CMOS chips from NEC and Toshiba. I don't think the engineers of these Japanese companies didn't know this, and the subject of differences in SCF/CCF instruction behaviour has been around for a long time, just lacked a simple tool (other than ZEXALL) to check.

[Tadeusz Pycio]

I have tested my processors, the programme works correctly with one exception NEC D70008AC-6:

[Tadeusz Pycio]

Huge surprise (for me), I recovered a Toshiba TMPZ84C00AP (4MHz) processor (production date 26 week 1987) running continuously in my CA80 (old Polish Z80 trainer) and this one is recognised as Zilog(!) in Z80test. I have now turned on the ZEXALL test, but you have to wait a few hours for the results at 3.68MHz clocking. It may indeed be that these are the technical differences that Alan mentioned and are only apparent for nominally higher clocked processors. Admittedly, the NEC as well as this Toshiba tesed were running at the same clock during testing. This conundrum is getting more and more interesting.

[Sergey Kiselev]

This result (2801) is actually very interesting!

The the lower 8-bits of the printed value - 0x01 is the flags after running the test code above.

And 0x01 is what I originally expected to get on a NEC D70008AC CPU.

But the particular NEC chip which I have gives me 0x09, just as my Toshiba TMPZ84C00AP-8...

Let me add 0x01 as NEC.

I am wondering if NEC "fixed" the issue at some point, and made it work as Toshiba?

[Sergey Kiselev]

Updated the z80type to report '0x01' as a NEC CPU...

I tested the second Toshiba CPU that I have - TMPZ84C00AP-10 and the z80type properly reports it as Toshiba.

Regarding my NEC CPU that is reported as Toshiba, it is possible that:

• I have a fake NEC CPU. Although it totally looks like NEC. NEC has a very specific package shape, and even if relabeled, it would be some kind of NEC CPU - D780C or D70008AC. The one that I have is detected as CMOS...
• NEC and Toshiba used each other design/wafers? 

Regarding your Toshiba CPU, can you take a good photos of front and back. Toshiba also has a very distinct package shape...

--Sergey

[Tadeusz Pycio]

I'll take a picture of this Toshiba, but after I've finished the ZEXALL test - I don't want to interrupt it because it's already been running for an hour. It looks authentic and I have owned it for many years, the casing is typical of this company. Another processor from this company TMPZ84C00AP-8 production date 36 week 1990 in the Z80test gives the predicted result. I am waiting for the ZEXALL test to be completed as the result will be interesting.

[Tadeusz Pycio]

I have good news, in the ZEXALL test this processor does not pass the test:
<daa,cpl,scf,ccf>.............  ERROR **** crc expected:6d2dd213 found:44e8f9d3

The bad news, however, is that the Z80type SCF/CCF test does not detect this variation: Processor Type: Z80 CMOS Zilog or SGS/ST

[Sergey Kiselev]

Tadeusz,

It is good to hear that your Toshiba is *different* from a Zilog Z84C00. But I need to figure out what exactly test to use.

My tests so far are implemented using the documentation I found (linked above). But I found a lot of the documentation on the internet being inconsistent. Also often times people describe the behavior of the bits 3 and 5, but don't provide the code they've used to observe the behavior. For example, this description is bogus in many ways.

What version of ZEXALL are you using?

I've looked around, and there is more than one ;)

Also, thanks for the photo. I've got much newer Toshiba chips - date codes 9442 and 9544, where your is 8726, so more than 7 years younger.

I've ordered another Toshiba chip from eBay, supposedly with date code 8549... will see what it does ;)

--Sergey

[Tadeusz Pycio]

Hi Sergey,

Yes, this processor has been with me for 30 years ;) I admire the longevity of these components, it has been running continuously as a clock for a decade and still works.
I didn't even know that there were different versions of ZEXALL. I've been using the version I found on GitHub for a long time as I was looking for a Z80 emulator.

I will try to encourage my local community to check their processors, maybe someone will get different results. This may help solve this conundrum, as the available information on the subject is indeed often incomplete and contradictory.

[Sergey Kiselev]

I played a bit more. I made some modifications to z80type, but I don't expect it to produce different result at this point. Mostly code cleanup.

Looks like I need to do more tests with SCF/CCF, perhaps using different initial value (up until now z80type uses just one initial value).

I did make a few interesting observations:

• For my KR1858VM1 the alleged differences in the hidden MEMPTR register behavior described here don't seem to work. I tried LD (rp),A and OUT (port),A. I am getting bits 5 and 3 set to the corresponding bits of the register A.
• But, it looks that there is a difference in the behavior of bits 3 and 5 on KR1858VM1 when using SCF instruction. In case where I set  A = 0, and FLAGS=28h (bits  5 and 3 are set), I get 21h as the output. So bit 3 gets reset, but not bit 5. Other processors, do not reset bits 5 and 3 in this case, and the result is 29h. I still have to verify this observation on my second KR1858VM1.
• I did run zexall on TMPZ84C00AP-8, date code 9544, NEC D70008AC-6, date code 8832, and KR1858VM1, date code 9306. They all fail some tests. More specifically:
  • Toshiba TMPZ84C00AP-8, JAPAN9544EFI
    <daa,cpl,scf,ccf>.............  ERROR **** crc expected:6d2dd213 found:7c56cfd2
    
  • NEC D70008AC-6, 8832
    <daa,cpl,scf,ccf>.............  ERROR **** crc expected:6d2dd213 found:05a60016
    
  • KR1858VM1 - 9306
    shf/rot <b,c,d,e,h,l,(hl),a>..  ERROR **** crc expected:a4255833 found:c3da486a
    
• I have more CPUs I need to run the zexall on. It is currently running on Thesys Z80H, which I suspect is the same as MME U880

--Sergey

[Sergey Kiselev]

More fun stuff.

Being a bit of a desperate regarding the above ZEXALL results, ZEXALL taking hours to run, and it not being particularly friendly in reporting what exactly caused instruction to produce "wrong" result, I decided to "brute-force it".

I wrote a piece of code, that iterates through all 2^16/0x10000 possible values of the accumulator and flags, and counts how many times a flag was set to zero.

While all defined flag bits behave the same on all processors that I've tested, two undefined flags YF (FLAGS.5) and XF (FLAGS.3) differ between processors.

The results are quite interesting:

• Both CMOS and NMOS versions of Zilog Z80, and East German U880 and Thesys Z80H produce the same count: 0xC000 for both YF and XF
• Both Toshiba TMPZ84C00AP chips that I have also produce the same count, but it is different from Zilog above: 0x8000 for both YF and XF
• NEC CMOS CPU always seem to produce 0x8000 count for YF (same as Toshiba), but the count for YF varies from run to run and generally is around 0x939C (so slightly more than 0x8000)
• NEC NMOS CPU always seem to produce 0xC000 count for YF (same as Zilog), but the count for YF varies from run to run and generally is around 0xAC0E  (closer 0xC000?)
• In Soviet KR1858VM1 with date code 9306, the count for YF and XF varies from run to run, in a rather interesting way
  
  • At 8 MHz, the YF flag count is around 0x8200 (so slightly more than 0x8000), while XF flag count is always 0x8000
  • At 1.8 MHz,  the YF flag count is around 0xBFF8 (almost 0xC000 like Zilog?), while XF flag count is around 0xA5F5 (also pretty close 0xC000?)
• My other Soviet KR1818VM1 with date code 9305 is unable to run at 8 MHz
  • At 1.8 MHz,   the YF flag count is again around 0xBFF8 (almost 0xC000 like Zilog?), while XF flag count is almost always 0xC000, but I had 0xBFFF result in one of the runs

Discussion:

• To answer the initial Tadeusz's question, yes, it appears that Z80 CMOS, Toshiba CMOS and NEC CMOS CPUs are all independent design... although it is not impossible that NEC is based on Toshiba (or the other way around), but something mixed up in production
• It appears that the CPU clock affect XF and ZF values on NEC and soviet CPUs. Which probably means that these flags just indicate some residual value on an internal bus. Still, they might be useful to detect the CPU manufacturer

-Sergey

[Alan Cox]

> To answer the initial Tadeusz's question, yes, it appears that Z80 CMOS, Toshiba CMOS and NEC CMOS CPUs are all independent design... although it is not impossible that NEC is based on Toshiba (or the other way around), but something mixed up in production
> It appears that the CPU clock affect XF and ZF values on NEC and soviet CPUs. Which probably means that these flags just indicate some residual value on an internal bus. Still, they might be useful to detect the CPU manufacturer

To me these two statements kind of conflict

If the behaviour on some devices is a residual bus value that is
usually 0 and on some usually 1 that's not necessarily indicating
anything about the design. They may all be the same design but the
bias and residual values are merely a property of the specific
silicon, doping and metallisation process the given company used.

So I don't think it proves anything although it's fascinating.

[Tadeusz Pycio]

It is possible that these are differences in the manufacturing technology used, although similar differences should appear in the Zilog processors produced by different factories, as I do not suspect that they have identical manufacturing technology over so many years. There should be some deviation if they are dies from any of these Japanese companies.

[Sergey Kiselev]

Tadeusz (and everyone interested), can you please try running the latest z80type.com on your system (Toshiba CPUs, NEC CPUs, and other non-Zilog CPUs are more interesting) and report back the results?

I am particularly interested in the "SCF flags test" output.

Thanks,
Sergey

[Tom Storey]

Hi Sergey,

I have some contacts in a Japanese retro computing group that I can reach out to. There should be plenty of NEC and other Japanese makes available through that group.

But the website isn't working for me. Are there any known issues with it?

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/7bdcb7bd-e2ee-4408-b284-d3819c75686bn%40googlegroups.com.

[Tadeusz Pycio]

Tests of my processors (all tests were carried out at a clock of 3.68MHz)

- TMPZ84C00AP data code: 8726

Z80 Processor Type Detection (C) 2024 Sergey Kiselev
Processor family: Z80
Logic family:     CMOS
Manufacturer:     Zilog or SGS/ST
SCF flags test:   80008000A27A0000C000800000000000

-TMPZ84C00AP-8 data code: 9036

Z80 Processor Type Detection (C) 2024 Sergey Kiselev
Processor family: Z80
Logic family:     CMOS
Manufacturer:     Toshiba or NEC
SCF flags test:   8000800083850000C000800000000000

-D70008AC-6 data code:8720

Z80 Processor Type Detection (C) 2024 Sergey Kiselev
Processor family: Z80
Logic family:     CMOS
Manufacturer:     NEC
SCF flags test:   80008000800000006B97800000000000

others including NMOS(!) something happened to the procedure for detecting production technology
- Zilog Z84C0010PEC, Sharp LH0080A, GoldStar Z8400A PS, Zilog Z8400HPS, STM Z8400AB1, Bridge MK3880N-4, NEC D780C-1

Z80 Processor Type Detection (C) 2024 Sergey Kiselev
Processor family: Z80
Logic family:     CMOS
Manufacturer:     Zilog or SGS/ST
SCF flags test:   80008000C0000000C000800000000000

[Sergey Kiselev]

Tom: My apologies, Google groups interpret anything ending with <dot>com as a website and inserts a link. z80type<dot>com is actually the CP/M executable file name :)

My z80type utility that I wanted people to try is here: https://github.com/skiselev/z80-tests

Tadeusz:

Interesting... So both of your Toshiba CPUs have a "weird" count for YF (FLAGS.5). My Toshiba and CMOS NECs seem to have 0x8000 there.

Your CMOS NEC does gives an unusual count for XF (FLAGS.3), but the count is lower than 0x8000. I get above 0x8000 there.

Regarding CMOS vs. NMOS... it still works for me. Are you sure you have a SIO with its channel B command port at 0x82?

So far the algorithm to detect the CPU might be something like:

• Check if the CPU is CMOS or NMOS using the undocumented 0EDh,071h instruction, which works as OUT (C),0 on NMOS and as OUT (C),0FFh on CMOS
• Run the SCF test. Count the number YF and XF are set.
  • For NMOS CPUs:
    • if YF count is 0xC000, but XF count is not 0xC000 - it is likely a NEC D780C
    • if YF count is not 0xC000 - it is likely a KR1858VM1 or Goldstar?! (on two Goldstar CPUs that I have I get YF and XF count close to 0xC000, and in some runs 0xC000, but more often that not it is not 0xC000, but something like 0xBFD3... maybe you can run z80type on your Goldstar several times and see if you get different result?)
    • else do the U880 OUTI test. If it sets CF - we have U880/Thesys Z80, otherwise any other NMOS Z80 (Zilog, ST, Goldstar, Sharp)
  • For CMOS CPUs:
    • if YF count is 0xC000, but XF count is not 0xC000 - it is likely a NEC D70008AC
      
    • if YF count is not 0xC000, and XF count is 0x8000 - it is likely a Toshiba TMPZ84C00AP
      • If YF count is exactly 0x8000 it is a newer Toshiba TMPZ84C00AP (question what is newer? Somewhere in early 90's between 9036 and 9442?)
    • if YF count is 0xC000 and XF count is 0xC000 - Zilog Z84C00 (possibly other CMOS CPUs - more testing needed here)
    • Otherwise (both YF != 0xC000 and YF != 0xC000) - a CPU we haven't seen just yet ;)

BTW, I tried checking what affects the XF and YF bits.

At least on the NEC D70008, if prior to executing SCF the only bits set in accumulator are bits 5 and 3 (28h), and none of the bits set in FLAGS, it always produces predictable result - 01h, but setting other bits in accumulator and FLAGS leads to this variation of YF and XF count.

So it appears that other bits from flags or accumulator somehow leak to YF and XF flags. In theory the flip-flops that store these bits, in case of SCF instruction, don't get a valid input signal, and remain floating, so they pick up whatever noise is in the CPU.

I need to do more experiments to determine what bits initial flag/accumulator setting cause the random YF and XF behavior. It is possible that this will be different for different vendors (or not).

Thanks,

Sergey

[Tadeusz Pycio]

Hi Sergey,

I ran the test five times for each of the three GoldStar processors I own (date code: 9019, 9315 and 9318). I always got the same results:
SCF flags test:   80008000C0000000C000800000000000

Perhaps it's a system clock issue? I run the tests with a clock of 3.68MHz.

PS. I don't understand this problem with OUT (C),0 and SIO/2 that I have. I checked it on the IM2 interrupt system, it works, so it is not a SIO error. Very strange problem. Tomorrow I will have my "Universal SIO" module so I will test this with other SIO chips. I completely don't understand this... and it's probably some stupid bug.

[Tom Storey]

Haha whoops! Ok. I completely glossed over the fact this was a CP/M tool.

Is it strictly necessary to use an SIO register to store the test value? I don't know how many people in this Japanese group have RC2014/RCbus hardware, so some alternate register may be needed in what ever hardware they have to test with.

To make it easier to port, can the reads and writes to the test register be turned into macros or callable code?

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/416492be-bfed-4365-9a02-c8b7fcd7b463n%40googlegroups.com.

[Sergey Kiselev]

The NMOS vs. CMOS test requires writing an I/O register using an undocumented instruction, which behaves differently on NMOS and CMOS, reading the written value back and comparing it to determine what value that undocumented instruction has written.

I use SIO interrupt vector register as that "scratch" register for the test. The register address is currently hardcoded to 0x82 -  RC2014/SC SIO module address for channel B (the interrupt vector only accessed through channel B, but applies for both channels).

I need to find or possibly build a ~4MHz clock source. I currently have 1.8 MHz and 8 MHz oscillators.

--Sergey 

--
You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/rhKeKpXmAXM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/81d1ca43-3ec0-43ee-82fd-28ac9a89e923n%40googlegroups.com.

[Sergey Kiselev]

On Sunday, May 5, 2024 at 1:31:55 PM UTC-7 t...@snnap.net wrote:

Is it strictly necessary to use an SIO register to store the test value? I don't know how many people in this Japanese group have RC2014/RCbus hardware, so some alternate register may be needed in what ever hardware they have to test with.

It is not necessary to use SIO for the NMOS vs. CMOS, detection algorithm, but it requires writing and reading back an I/O port. Even one bit that can be read back to check what was the value written.

To make it easier to port, can the reads and writes to the test register be turned into macros or callable code?

I can convert that to a separate subroutine, if needed, to make it more modular. 

I am actually more interested in SCF test results test. Perhaps I'll separate that code, so that there will be no dependencies on the I/O port...

[Sergey Kiselev]

I did a bunch more tests, and made a few more updates to the z80type utility.

From the user perspective, now it tries to print the CPU or the list of CPUs that match the detected features.

I also added /D command line option to show more debug information that might help with adjusting CPU detection or adding new CPUs.

From implementation perspective I implemented four separate test routines, and separated the UI (output) and the decision logic from that. This might make the code more maintainable and portable
The test routines are:

1. NMOS vs. CMOS using OUT (C),0 instruction
2. U880 detection, using OUTI behavior difference
3. Quick(er) XF/YF flags test. It checks 4 test cases:
   1. FLAGS.5 (YF) value following SCF with A.5 and some other bits in A register set, and FLAGS register set to 0
   2. FLAGS.3 (XF) value following SCF with A.3 and some other bits in A register set, and FLAGS register set to 0
   3. FLAGS.5 (YF) value following SCF with FLAGS.5 and some other bits in FLAGS register set, and A register set to 0
   4. FLAGS.3 (XF) value following SCF with FLAGS.3 and some other bits in FLAGS register set, and A register set to 0
4. Optional (runs only with /D) test, what walks though 2^16 possible values of A and FLAGS and counts how many times YF and XF were set
   • While slower, this test doesn't provide the precision of the previous test, as it doesn't check separately all permutations of YF, XF, A.5 and A.3
   • Still it is useful for checking deterministic vs. non-deterministic behavior of XF and YF flags on a given CPU 

A few interesting finds too:

• Sharp LH5080A - the CMOS Sharp Z80 variant seems to be different from Toshiba and NEC designs in a few ways:
  • It "fails" the CMOS test, and the undocumented OUT (C),0 instruction behaves the same way it does on NMOS CPUs
  • The SCF/CCF YF/XF test result is very different from other CMOS CPUs
• I've got another NEC D70008AC-6, this one is manufactured in Ireland, and it behaves similarly to Tadeusz's one (and differently from another, Japanese CPU)... I cannot tell if it is a difference in implementation, or just a result of manufacturing, and having some floating signals read as '0' more often that as '1'
• ST Z84C00 behaves similarly to Toshiba TMPZ84C00 (and differently from Zilog, NEC, or Sharp)
• Most NMOS CPUs behave similarly, but under certain conditions some fail to set YF and XF flags. Zilog Z80 seem to always set these flags.

Example of the output without and with /D option:

A>z80type

Z80 Processor Type Detection (C) 2024 Sergey Kiselev

Detected CPU type: Toshiba TMPZ84C00AP, ST Z84C00AB

A>z80type /d

Z80 Processor Type Detection (C) 2024 Sergey Kiselev

Raw results:       CMOS: 2C U880: 00 XF/YF: 3F
XF/YF flags test:  8000C000
Detected CPU type: Toshiba TMPZ84C00AP, ST Z84C00AB

[Tadeusz Pycio]

The behaviour of the CMOS STM processors is a huge surprise to me, such a result was not expected. It will be interesting to see what result the LH5080L I expected will give and whether it will confirm my speculation about the role of the "OUT (C),0" instruction (the LH5080A gave a result I assumed to be NMOS).
I have ordered both of the above types of these processors (Z84C00AB6 and LH5080L) and am now waiting with growing impatience for delivery. It is a pity that there is no response from other owners of less popular processors.

[Sergey Kiselev]

And I've got a Romanian Microelectronica MMN 80CPU, and it identifies as...

Guess who else got East German Z80 dies (dice?!) :)

A>z80type /d
Z80 Processor Type Detection (C) 2024 Sergey Kiselev

Raw results:       CMOS: 00 U880: 01 XF/YF: FF
XF/YF flags test:  C000C000
Detected CPU type: Newer MME U880, Thesys Z80, Microelectronica MMN 80CPU

[Tadeusz Pycio]

Unfortunately, the first delivery was a disappointment. These are not STM processors, but probably Zilog - one CMOS, the other NMOS. The counterfeiters have the momentum to date the production date, 20 years after this company ceased production.

[Brian Cockburn]

Some what OT I know, but a worthwhile point to make IMHO.  The word 'die' is singular e.g. a CPU die, a cube with digits on it faces.  The word 'dice' is plural e.g. two die rolled together to give a player a random movement in a board game.  Modern (slack) parlance tends to 'allow' the use of the word dice for just one of the cube things. e.g. "Pick the dice up of the floor please Brian."

Sorry about that, Brian.

[Phil Pin]

The term "die" can be used as both singular and plural in the semiconductor industry. 

wikipedia

There are three commonly used plural forms: dice, dies, and die.^[1][2]

... there is also the TI Texan lingo  ("bar" for die and "slice" for wafer).  - Phil

[Tadeusz Pycio]

After a long wait, I received my delivery of the Sharp LH5080L.

The tests challenged my assumption about the meaning of the instruction "OUT (C),0". The CMOS version of the Sharp processor with reduced power mode (L tag) gives the same result as a processor from this company that does not have this functionality.

z80t is the latest version of the z80type test, the previous one has the default name.

[Sergey Kiselev]

Tadeusz,

Thanks for testing! That seems to be consistent with my results for Sharp LH5080A, I will add LH5080L to the message.

I've been a bit busy with other things (work, life, and the RTC8088 project). And there are a few things that still not fully implemented in z80type.

I found a similar project for ZX Spectrum - Z80_XCF_Flavor, although it is limited to Zilog (any), NEC NMOS, and ST CMOS - I assume the CPUs that were shipped with ZX Spectrum?!

For whatever reason, I cannot reproduce the NEC Z80 NMOS behavior they are describing. So it might be more... perhaps so called MEMPTR register affects the results (that would change depending on the addresses and other 16-bit temporary values used in previous operations).

I've got a couple more NEC U880 NMOS CPUs and a couple more ST Z84C00 CMOS CPUs. ST behavior seems to be consistent with my previous observations. One of the NEC U880 CPUs, seem to give a bit more deterministic results, and z80type sometimes confuses it for Zilog Z80 NMOS... So more work needed there.

Also, on related topic, I've been contacted by Stephan Slabihoud. He developed this Z80 tester, and he ported some of my code to his project, so it shows the CPU type using the LEDs.

This kind of reminds me my earlier post in the RC2014 group, regarding the Z80 tester improvements. Looks like Stephan implemented some of them already. A couple of things missing are - programmable CPU frequency divider and a watchdog to reset the CPU in case it gets stuck...

--Sergey