home.social

#cmos — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #cmos, aggregated by home.social.

  1. This Tiny Chip CHANGED EVERYTHING! - YouTube

    The Stroy of the CMOS sensor and NASA.

    m.youtube.com/watch?v=LqSLD4LB

    #cmos #photography #nasa

  2. Z80 CPU Tester (Fail)

    Recently I was watching Lee from More Fun Making|Fixing It with an “unpacking” video that contained a pile of Z80 CPUs ordered from a large Chinese supplier, and he was testing them using a neat Z80 CPU tester to work out if they were CMOS or NMOS devices and what frequency they would support.

    I have a few Z80 CPUs kicking around, and not all nice new ones (that I was able to get from people like RC2014 and Small Computer Central) but random ones from a while back or more recently from online auction sites and so on, so thought it would be interesting to have a tester too.

    I pretty found quickly found an open design that looked similar to the one in Lee’s video, but as I looked into the design, decided I didn’t really want to send off and pay for the larger PCB. Also the latest version of the tester I found has additional features that I’m not particularly interested in, so I thought I’d take the schematic and see if I could spin up my own version.

    Spoilers: I made a wrong assumption and actually this is no good! But read on for the full tale of woe 🙂 Or just do what I ended up doing, and get yourself one of these: https://github.com/djtersteegc/z80-cmos-nmos-tester which is pretty much identical to the one used in the video!

    There are a few “off the shelf” testers available from a number of places online, but they aren’t quite the same. This one from MyRetroStore looks like one of the easier ones to get and use: https://myretrostore.co.uk/product/z80-cpu-nmos-cmos-tester/ (Noting that this includes an ICSP header, I wonder if this is using a microcontroller. That was another thing I wondered about doing…)

    The Original Design

    I’m basing everything on the design from here: https://github.com/slabbi/Z80-CPU-Tester

    This is using firmware for the Z80 that uses a lot of the information from this: https://github.com/skiselev/z80-tests

    The basic idea of the original is that the board has a socket for the Z80, some ROM and RAM and IO decoding driving two sets of LEDs which give the status readout from the tests. The board also has a jumper-configurable clock which can select between 16MHz and 20MHz with divisors of 1,2,4,8,16. These all serve to allow the Z80 to boot and run a test program which uses some differences in undocumented features of the Z80 to determine which make of device it is and run it through its paces. Note, not everything is tested, but it will test basic instruction processing and IO.

    The later V2 of the board also includes additional headers to break out the two IO ports and includes the option for IO input too.

    The memory map is as follows:

    0000-7FFFROM8000-FFFFRAMb1111 1110 (IO)IO PORT Ab1111 1101 (IO)IO PORT B

    Key components from the original design:

    • 32K x8 27C256 or 29C256 ROM.
    • 32K x8 SRAM (e.g. 61256, 62256, etc).
    • 16MHz and 20MHz oscillator through a 74HC04 hex inverter into a 74LS393 4-bit binary counter for subdividing.
    • 74LS573 for the INPUT port and 2x74LS574 for the OUTPUT ports (LEDs).
    • 74LS02 quad 2-input NORs for address logic for the ROM/RAM selection and IO ports.
    • Direct USB (5V) powered.
    • RESET and NMI button switches.

    As I say though, the provided Gerber files present a neat design all ready to go, but on a 109×124 mm PCB. I want to see if I can get it into the magic 100×100 mm cheap PCB footprint.

    My Z80 Tester Design

    I don’t need the external IO features, so I can lose the 74LS573 and associated circuitry. This also means I can reuse the logic that has to decode IO reads, which also allows me to lose one of the three 74LS02s.

    Pretty much everything else is the same. A0-A14 are routed to both ROM and RAM. D0-D7 are routed to both ROM and RAM, and the two IO ports via the two 74LS574s.

    The address decoder logic is as follows.

    The left-hand side signals come from the Z80 and the right-hand side signals go off to the memory or IO ports. CP0 enables PORT A and CP1 enables PORT B. The other signals are mapped as follows.

    Z80 SignalsControl SignalDestinations/WR
    /MREQ/MEMWRRAM /WE/RD
    /MREQ/MEMRDROM /OE
    RAM /OEA15/RAM_ENRAM /CSA15A15ROM /CE/WR
    /IORQ
    /A0CP0PORT A Cp/WR
    /IORQ
    /A1CP1PORT B Cp

    From this we can see that A15 selects between ROM and RAM (inverted to create /RAM_EN) and the memory read/write signals come from /MREQ and /RD or /WR respectively.

    For the IO access, we can see that only /WR is supported and keyed into /IORQ. Then CP0 or CP1 are enabled depending on the state of A0 or A1 respectively. No other address decoding is performed for IO, so any values of A2 onwards are essentially irrelevant. I guess it is also possible to write to both ports at the same time using an address where both A0 and A1 are cleared (LOW).

    The other piece of control logic worth noting is that the following signals on the Z80 are all pulled HIGH: /BUSREQ, /INT, /HALT, /WAIT.

    /RESET and /NMI are also pulled HIGH but connected to a push button switch to allow them to be pulled LOW to activate them. I’ve used the circuits directly from the original here.

    The clock circuit is again directly taken from the original:

    This provides a jumper to select between 16MHz and 20MHz. It then passes through two inverters, presumably to clean it up, and then further jumpers to connect the output of the 4-bit binary counter to provide the actual used CLK signal.

    Here is one of the output PORTs connected to 8 LEDs.

    We can see that this is triggered by CP0. PORTB is the same but triggered by CP1.

    PORT A is used as an indicator that the tests are running. PORTB is used as an indicator for the type of Z80 CPU detected.

    Here is the extract on decoding PORTB from the original Hardware (V2) English Manual:

    The Big Fail

    It turns out that removing the INPUT was based on a wrong assumption.

    It wasn’t clearly documented that I could find initially, but after following some links from some links from a readme as part of researching this blog, I found the original code that everything is based on (here).

    It turns out that the CMOS/NMOS detection relies on an undocumented OUT (C), 0 instruction. This can be hard-coded into the assembly with the line:

    defb $ed, $71

    Which will force the unrecognised “OUT (C), 0” instruction to appear in the code. This apparently will output $00 for an NMOS device and $FF for a CMOS device. This has to be read back via a subsequent IN instruction to see what kind of chip is present.

    Here in lies the problem. Without an IN device containing the latched output value, this won’t work. Sigh.

    The original circuit uses a 74ALS990 read-back latch, which is quite hard to come by. The second version uses the combination of 74LS573, 74LS574 and transistors.

    At this point I went off to the other circuit I discovered here: https://github.com/djtersteegc/z80-cmos-nmos-tester

    As full design files are available for this one, and the PCB is withing the fabled 100×100 mm size, at this point I abandoned my own attempt and just got some of these boards ordered!

    Further Thoughts

    Seeing as I have some boards on the way though, I am pondering possible ways to get some use out of them. As the key undefined behaviour we’re interested in, is an OUT instruction, I’m now pondering if a sequence like:

    LD C, 0
    LD A, $FF
    OUT (C), A ; LEDs ON
    XOR A
    OUT (C), A ; LEDs OFF
    defb $ed, $71 ;OUT (C), 0
    OUT (C), A ; LEDs OFF
    LD A, $FF
    OUT (C), A ; LEDs ON
    XOR A
    OUT (C), A ; LEDs OFF

    With some appropriate delays, might be possible. As C is the address for the PORT driving the LEDs, then this would have the effect of flashing them twice for NMOS or flashing three times for CMOS.

    Of course it renders the CMOS indicator itself LED useless. But I think this might work as an indicator, so this is one to test when the boards come back.

    Someone Else’s Working Design

    I’m still deciding if it is worth spending any more time on my board – either attempting to get the one I’ve now received working, or just redesigning a V2.

    In the mean time, I’ve built up the existing one, which is a lot simpler design:

    • It has no RAM, running only from ROM.
    • It has no INPUT readback.
    • It only uses a single port of 8 LEDs.

    This works by flashing a number of times to indicate the type of Z80 – 1 flash for NMOS, 2 for CMOS and 3 for a U880. So as there is no INPUT readback, this must be doing exactly what I was pondering above – a sequence of OUT instructions, some of which will illuminate the LEDs (for a CMOS chip) and some of which won’t (for NMOS).

    On passing a number of cheap Z80’s (all marked as Z84C0020PEC – yeah right ;)), I’ve ended up with most being NMOS, but running at least up to 8MHz, and two being CMOS. Two don’t seem to run at any frequency, so I’m guessing they are dead on arrival.

    At present, I don’t have a 16MHz and 20MHz crystal, so I’m only testing up to 10MHz for now.

    Conclusion

    There is always a danger when modifying designs that something isn’t fully appreciated. And it gets worse with designs that are respins of earlier designs, and in this case that was a respin of yet another.

    I often find that some of these projects that are widely used are often based on design decisions that seem lost in the mists of time. Or at least the depths of a random forum somewhere.

    Anyway, this was one case where I was only considering the hardware as it appeared and not why it might have been the way it was. Oh well. All I’ve lost is an afternoon’s fun designing a board and around £5 on a PCB that will probably be useless once it arrives.

    Ironically if I’d started this post prior to sending, I would almost certainly have found the error. As it happens, I started writing this a few hours after hitting “upload” and the erroneous board is now already in production! One day I’ll learn this lesson 🙂

    Still on the plus side, the other board was only following on a few hours behind.

    Kevin

    #cmos #logic #nmos #pcb
  3. Z80 CPU Tester (Fail)

    Recently I was watching Lee from More Fun Making|Fixing It with an “unpacking” video that contained a pile of Z80 CPUs ordered from a large Chinese supplier, and he was testing them using a neat Z80 CPU tester to work out if they were CMOS or NMOS devices and what frequency they would support.

    I have a few Z80 CPUs kicking around, and not all nice new ones (that I was able to get from people like RC2014 and Small Computer Central) but random ones from a while back or more recently from online auction sites and so on, so thought it would be interesting to have a tester too.

    I pretty found quickly found an open design that looked similar to the one in Lee’s video, but as I looked into the design, decided I didn’t really want to send off and pay for the larger PCB. Also the latest version of the tester I found has additional features that I’m not particularly interested in, so I thought I’d take the schematic and see if I could spin up my own version.

    Spoilers: I made a wrong assumption and actually this is no good! But read on for the full tale of woe 🙂 Or just do what I ended up doing, and get yourself one of these: https://github.com/djtersteegc/z80-cmos-nmos-tester which is pretty much identical to the one used in the video!

    There are a few “off the shelf” testers available from a number of places online, but they aren’t quite the same. This one from MyRetroStore looks like one of the easier ones to get and use: https://myretrostore.co.uk/product/z80-cpu-nmos-cmos-tester/ (Noting that this includes an ICSP header, I wonder if this is using a microcontroller. That was another thing I wondered about doing…)

    The Original Design

    I’m basing everything on the design from here: https://github.com/slabbi/Z80-CPU-Tester

    This is using firmware for the Z80 that uses a lot of the information from this: https://github.com/skiselev/z80-tests

    The basic idea of the original is that the board has a socket for the Z80, some ROM and RAM and IO decoding driving two sets of LEDs which give the status readout from the tests. The board also has a jumper-configurable clock which can select between 16MHz and 20MHz with divisors of 1,2,4,8,16. These all serve to allow the Z80 to boot and run a test program which uses some differences in undocumented features of the Z80 to determine which make of device it is and run it through its paces. Note, not everything is tested, but it will test basic instruction processing and IO.

    The later V2 of the board also includes additional headers to break out the two IO ports and includes the option for IO input too.

    The memory map is as follows:

    0000-7FFFROM8000-FFFFRAMb1111 1110 (IO)IO PORT Ab1111 1101 (IO)IO PORT B

    Key components from the original design:

    • 32K x8 27C256 or 29C256 ROM.
    • 32K x8 SRAM (e.g. 61256, 62256, etc).
    • 16MHz and 20MHz oscillator through a 74HC04 hex inverter into a 74LS393 4-bit binary counter for subdividing.
    • 74LS573 for the INPUT port and 2x74LS574 for the OUTPUT ports (LEDs).
    • 74LS02 quad 2-input NORs for address logic for the ROM/RAM selection and IO ports.
    • Direct USB (5V) powered.
    • RESET and NMI button switches.

    As I say though, the provided Gerber files present a neat design all ready to go, but on a 109×124 mm PCB. I want to see if I can get it into the magic 100×100 mm cheap PCB footprint.

    My Z80 Tester Design

    I don’t need the external IO features, so I can lose the 74LS573 and associated circuitry. This also means I can reuse the logic that has to decode IO reads, which also allows me to lose one of the three 74LS02s.

    Pretty much everything else is the same. A0-A14 are routed to both ROM and RAM. D0-D7 are routed to both ROM and RAM, and the two IO ports via the two 74LS574s.

    The address decoder logic is as follows.

    The left-hand side signals come from the Z80 and the right-hand side signals go off to the memory or IO ports. CP0 enables PORT A and CP1 enables PORT B. The other signals are mapped as follows.

    Z80 SignalsControl SignalDestinations/WR
    /MREQ/MEMWRRAM /WE/RD
    /MREQ/MEMRDROM /OE
    RAM /OEA15/RAM_ENRAM /CSA15A15ROM /CE/WR
    /IORQ
    /A0CP0PORT A Cp/WR
    /IORQ
    /A1CP1PORT B Cp

    From this we can see that A15 selects between ROM and RAM (inverted to create /RAM_EN) and the memory read/write signals come from /MREQ and /RD or /WR respectively.

    For the IO access, we can see that only /WR is supported and keyed into /IORQ. Then CP0 or CP1 are enabled depending on the state of A0 or A1 respectively. No other address decoding is performed for IO, so any values of A2 onwards are essentially irrelevant. I guess it is also possible to write to both ports at the same time using an address where both A0 and A1 are cleared (LOW).

    The other piece of control logic worth noting is that the following signals on the Z80 are all pulled HIGH: /BUSREQ, /INT, /HALT, /WAIT.

    /RESET and /NMI are also pulled HIGH but connected to a push button switch to allow them to be pulled LOW to activate them. I’ve used the circuits directly from the original here.

    The clock circuit is again directly taken from the original:

    This provides a jumper to select between 16MHz and 20MHz. It then passes through two inverters, presumably to clean it up, and then further jumpers to connect the output of the 4-bit binary counter to provide the actual used CLK signal.

    Here is one of the output PORTs connected to 8 LEDs.

    We can see that this is triggered by CP0. PORTB is the same but triggered by CP1.

    PORT A is used as an indicator that the tests are running. PORTB is used as an indicator for the type of Z80 CPU detected.

    Here is the extract on decoding PORTB from the original Hardware (V2) English Manual:

    The Big Fail

    It turns out that removing the INPUT was based on a wrong assumption.

    It wasn’t clearly documented that I could find initially, but after following some links from some links from a readme as part of researching this blog, I found the original code that everything is based on (here).

    It turns out that the CMOS/NMOS detection relies on an undocumented OUT (C), 0 instruction. This can be hard-coded into the assembly with the line:

    defb $ed, $71

    Which will force the unrecognised “OUT (C), 0” instruction to appear in the code. This apparently will output $00 for an NMOS device and $FF for a CMOS device. This has to be read back via a subsequent IN instruction to see what kind of chip is present.

    Here in lies the problem. Without an IN device containing the latched output value, this won’t work. Sigh.

    The original circuit uses a 74ALS990 read-back latch, which is quite hard to come by. The second version uses the combination of 74LS573, 74LS574 and transistors.

    At this point I went off to the other circuit I discovered here: https://github.com/djtersteegc/z80-cmos-nmos-tester

    As full design files are available for this one, and the PCB is withing the fabled 100×100 mm size, at this point I abandoned my own attempt and just got some of these boards ordered!

    Further Thoughts

    Seeing as I have some boards on the way though, I am pondering possible ways to get some use out of them. As the key undefined behaviour we’re interested in, is an OUT instruction, I’m now pondering if a sequence like:

    LD C, 0
    LD A, $FF
    OUT (C), A ; LEDs ON
    XOR A
    OUT (C), A ; LEDs OFF
    defb $ed, $71 ;OUT (C), 0
    OUT (C), A ; LEDs OFF
    LD A, $FF
    OUT (C), A ; LEDs ON
    XOR A
    OUT (C), A ; LEDs OFF

    With some appropriate delays, might be possible. As C is the address for the PORT driving the LEDs, then this would have the effect of flashing them twice for NMOS or flashing three times for CMOS.

    Of course it renders the CMOS indicator itself LED useless. But I think this might work as an indicator, so this is one to test when the boards come back.

    Someone Else’s Working Design

    I’m still deciding if it is worth spending any more time on my board – either attempting to get the one I’ve now received working, or just redesigning a V2.

    In the mean time, I’ve built up the existing one, which is a lot simpler design:

    • It has no RAM, running only from ROM.
    • It has no INPUT readback.
    • It only uses a single port of 8 LEDs.

    This works by flashing a number of times to indicate the type of Z80 – 1 flash for NMOS, 2 for CMOS and 3 for a U880. So as there is no INPUT readback, this must be doing exactly what I was pondering above – a sequence of OUT instructions, some of which will illuminate the LEDs (for a CMOS chip) and some of which won’t (for NMOS).

    On passing a number of cheap Z80’s (all marked as Z84C0020PEC – yeah right ;)), I’ve ended up with most being NMOS, but running at least up to 8MHz, and two being CMOS. Two don’t seem to run at any frequency, so I’m guessing they are dead on arrival.

    At present, I don’t have a 16MHz and 20MHz crystal, so I’m only testing up to 10MHz for now.

    Conclusion

    There is always a danger when modifying designs that something isn’t fully appreciated. And it gets worse with designs that are respins of earlier designs, and in this case that was a respin of yet another.

    I often find that some of these projects that are widely used are often based on design decisions that seem lost in the mists of time. Or at least the depths of a random forum somewhere.

    Anyway, this was one case where I was only considering the hardware as it appeared and not why it might have been the way it was. Oh well. All I’ve lost is an afternoon’s fun designing a board and around £5 on a PCB that will probably be useless once it arrives.

    Ironically if I’d started this post prior to sending, I would almost certainly have found the error. As it happens, I started writing this a few hours after hitting “upload” and the erroneous board is now already in production! One day I’ll learn this lesson 🙂

    Still on the plus side, the other board was only following on a few hours behind.

    Kevin

    #cmos #logic #nmos #pcb
  4. Z80 CPU Tester (Fail)

    Recently I was watching Lee from More Fun Making|Fixing It with an “unpacking” video that contained a pile of Z80 CPUs ordered from a large Chinese supplier, and he was testing them using a neat Z80 CPU tester to work out if they were CMOS or NMOS devices and what frequency they would support.

    I have a few Z80 CPUs kicking around, and not all nice new ones (that I was able to get from people like RC2014 and Small Computer Central) but random ones from a while back or more recently from online auction sites and so on, so thought it would be interesting to have a tester too.

    I pretty found quickly found an open design that looked similar to the one in Lee’s video, but as I looked into the design, decided I didn’t really want to send off and pay for the larger PCB. Also the latest version of the tester I found has additional features that I’m not particularly interested in, so I thought I’d take the schematic and see if I could spin up my own version.

    Spoilers: I made a wrong assumption and actually this is no good! But read on for the full tale of woe 🙂 Or just do what I ended up doing, and get yourself one of these: https://github.com/djtersteegc/z80-cmos-nmos-tester which is pretty much identical to the one used in the video!

    There are a few “off the shelf” testers available from a number of places online, but they aren’t quite the same. This one from MyRetroStore looks like one of the easier ones to get and use: https://myretrostore.co.uk/product/z80-cpu-nmos-cmos-tester/ (Noting that this includes an ICSP header, I wonder if this is using a microcontroller. That was another thing I wondered about doing…)

    The Original Design

    I’m basing everything on the design from here: https://github.com/slabbi/Z80-CPU-Tester

    This is using firmware for the Z80 that uses a lot of the information from this: https://github.com/skiselev/z80-tests

    The basic idea of the original is that the board has a socket for the Z80, some ROM and RAM and IO decoding driving two sets of LEDs which give the status readout from the tests. The board also has a jumper-configurable clock which can select between 16MHz and 20MHz with divisors of 1,2,4,8,16. These all serve to allow the Z80 to boot and run a test program which uses some differences in undocumented features of the Z80 to determine which make of device it is and run it through its paces. Note, not everything is tested, but it will test basic instruction processing and IO.

    The later V2 of the board also includes additional headers to break out the two IO ports and includes the option for IO input too.

    The memory map is as follows:

    0000-7FFFROM8000-FFFFRAMb1111 1110 (IO)IO PORT Ab1111 1101 (IO)IO PORT B

    Key components from the original design:

    • 32K x8 27C256 or 29C256 ROM.
    • 32K x8 SRAM (e.g. 61256, 62256, etc).
    • 16MHz and 20MHz oscillator through a 74HC04 hex inverter into a 74LS393 4-bit binary counter for subdividing.
    • 74LS573 for the INPUT port and 2x74LS574 for the OUTPUT ports (LEDs).
    • 74LS02 quad 2-input NORs for address logic for the ROM/RAM selection and IO ports.
    • Direct USB (5V) powered.
    • RESET and NMI button switches.

    As I say though, the provided Gerber files present a neat design all ready to go, but on a 109×124 mm PCB. I want to see if I can get it into the magic 100×100 mm cheap PCB footprint.

    My Z80 Tester Design

    I don’t need the external IO features, so I can lose the 74LS573 and associated circuitry. This also means I can reuse the logic that has to decode IO reads, which also allows me to lose one of the three 74LS02s.

    Pretty much everything else is the same. A0-A14 are routed to both ROM and RAM. D0-D7 are routed to both ROM and RAM, and the two IO ports via the two 74LS574s.

    The address decoder logic is as follows.

    The left-hand side signals come from the Z80 and the right-hand side signals go off to the memory or IO ports. CP0 enables PORT A and CP1 enables PORT B. The other signals are mapped as follows.

    Z80 SignalsControl SignalDestinations/WR
    /MREQ/MEMWRRAM /WE/RD
    /MREQ/MEMRDROM /OE
    RAM /OEA15/RAM_ENRAM /CSA15A15ROM /CE/WR
    /IORQ
    /A0CP0PORT A Cp/WR
    /IORQ
    /A1CP1PORT B Cp

    From this we can see that A15 selects between ROM and RAM (inverted to create /RAM_EN) and the memory read/write signals come from /MREQ and /RD or /WR respectively.

    For the IO access, we can see that only /WR is supported and keyed into /IORQ. Then CP0 or CP1 are enabled depending on the state of A0 or A1 respectively. No other address decoding is performed for IO, so any values of A2 onwards are essentially irrelevant. I guess it is also possible to write to both ports at the same time using an address where both A0 and A1 are cleared (LOW).

    The other piece of control logic worth noting is that the following signals on the Z80 are all pulled HIGH: /BUSREQ, /INT, /HALT, /WAIT.

    /RESET and /NMI are also pulled HIGH but connected to a push button switch to allow them to be pulled LOW to activate them. I’ve used the circuits directly from the original here.

    The clock circuit is again directly taken from the original:

    This provides a jumper to select between 16MHz and 20MHz. It then passes through two inverters, presumably to clean it up, and then further jumpers to connect the output of the 4-bit binary counter to provide the actual used CLK signal.

    Here is one of the output PORTs connected to 8 LEDs.

    We can see that this is triggered by CP0. PORTB is the same but triggered by CP1.

    PORT A is used as an indicator that the tests are running. PORTB is used as an indicator for the type of Z80 CPU detected.

    Here is the extract on decoding PORTB from the original Hardware (V2) English Manual:

    The Big Fail

    It turns out that removing the INPUT was based on a wrong assumption.

    It wasn’t clearly documented that I could find initially, but after following some links from some links from a readme as part of researching this blog, I found the original code that everything is based on (here).

    It turns out that the CMOS/NMOS detection relies on an undocumented OUT (C), 0 instruction. This can be hard-coded into the assembly with the line:

    defb $ed, $71

    Which will force the unrecognised “OUT (C), 0” instruction to appear in the code. This apparently will output $00 for an NMOS device and $FF for a CMOS device. This has to be read back via a subsequent IN instruction to see what kind of chip is present.

    Here in lies the problem. Without an IN device containing the latched output value, this won’t work. Sigh.

    The original circuit uses a 74ALS990 read-back latch, which is quite hard to come by. The second version uses the combination of 74LS573, 74LS574 and transistors.

    At this point I went off to the other circuit I discovered here: https://github.com/djtersteegc/z80-cmos-nmos-tester

    As full design files are available for this one, and the PCB is withing the fabled 100×100 mm size, at this point I abandoned my own attempt and just got some of these boards ordered!

    Further Thoughts

    Seeing as I have some boards on the way though, I am pondering possible ways to get some use out of them. As the key undefined behaviour we’re interested in, is an OUT instruction, I’m now pondering if a sequence like:

    LD C, 0
    LD A, $FF
    OUT (C), A ; LEDs ON
    XOR A
    OUT (C), A ; LEDs OFF
    defb $ed, $71 ;OUT (C), 0
    OUT (C), A ; LEDs OFF
    LD A, $FF
    OUT (C), A ; LEDs ON
    XOR A
    OUT (C), A ; LEDs OFF

    With some appropriate delays, might be possible. As C is the address for the PORT driving the LEDs, then this would have the effect of flashing them twice for NMOS or flashing three times for CMOS.

    Of course it renders the CMOS indicator itself LED useless. But I think this might work as an indicator, so this is one to test when the boards come back.

    Someone Else’s Working Design

    I’m still deciding if it is worth spending any more time on my board – either attempting to get the one I’ve now received working, or just redesigning a V2.

    In the mean time, I’ve built up the existing one, which is a lot simpler design:

    • It has no RAM, running only from ROM.
    • It has no INPUT readback.
    • It only uses a single port of 8 LEDs.

    This works by flashing a number of times to indicate the type of Z80 – 1 flash for NMOS, 2 for CMOS and 3 for a U880. So as there is no INPUT readback, this must be doing exactly what I was pondering above – a sequence of OUT instructions, some of which will illuminate the LEDs (for a CMOS chip) and some of which won’t (for NMOS).

    On passing a number of cheap Z80’s (all marked as Z84C0020PEC – yeah right ;)), I’ve ended up with most being NMOS, but running at least up to 8MHz, and two being CMOS. Two don’t seem to run at any frequency, so I’m guessing they are dead on arrival.

    At present, I don’t have a 16MHz and 20MHz crystal, so I’m only testing up to 10MHz for now.

    Conclusion

    There is always a danger when modifying designs that something isn’t fully appreciated. And it gets worse with designs that are respins of earlier designs, and in this case that was a respin of yet another.

    I often find that some of these projects that are widely used are often based on design decisions that seem lost in the mists of time. Or at least the depths of a random forum somewhere.

    Anyway, this was one case where I was only considering the hardware as it appeared and not why it might have been the way it was. Oh well. All I’ve lost is an afternoon’s fun designing a board and around £5 on a PCB that will probably be useless once it arrives.

    Ironically if I’d started this post prior to sending, I would almost certainly have found the error. As it happens, I started writing this a few hours after hitting “upload” and the erroneous board is now already in production! One day I’ll learn this lesson 🙂

    Still on the plus side, the other board was only following on a few hours behind.

    Kevin

    #cmos #logic #nmos #pcb
  5. Z80 CPU Tester (Fail)

    Recently I was watching Lee from More Fun Making|Fixing It with an “unpacking” video that contained a pile of Z80 CPUs ordered from a large Chinese supplier, and he was testing them using a neat Z80 CPU tester to work out if they were CMOS or NMOS devices and what frequency they would support.

    I have a few Z80 CPUs kicking around, and not all nice new ones (that I was able to get from people like RC2014 and Small Computer Central) but random ones from a while back or more recently from online auction sites and so on, so thought it would be interesting to have a tester too.

    I pretty found quickly found an open design that looked similar to the one in Lee’s video, but as I looked into the design, decided I didn’t really want to send off and pay for the larger PCB. Also the latest version of the tester I found has additional features that I’m not particularly interested in, so I thought I’d take the schematic and see if I could spin up my own version.

    Spoilers: I made a wrong assumption and actually this is no good! But read on for the full tale of woe 🙂 Or just do what I ended up doing, and get yourself one of these: https://github.com/djtersteegc/z80-cmos-nmos-tester which is pretty much identical to the one used in the video!

    There are a few “off the shelf” testers available from a number of places online, but they aren’t quite the same. This one from MyRetroStore looks like one of the easier ones to get and use: https://myretrostore.co.uk/product/z80-cpu-nmos-cmos-tester/ (Noting that this includes an ICSP header, I wonder if this is using a microcontroller. That was another thing I wondered about doing…)

    The Original Design

    I’m basing everything on the design from here: https://github.com/slabbi/Z80-CPU-Tester

    This is using firmware for the Z80 that uses a lot of the information from this: https://github.com/skiselev/z80-tests

    The basic idea of the original is that the board has a socket for the Z80, some ROM and RAM and IO decoding driving two sets of LEDs which give the status readout from the tests. The board also has a jumper-configurable clock which can select between 16MHz and 20MHz with divisors of 1,2,4,8,16. These all serve to allow the Z80 to boot and run a test program which uses some differences in undocumented features of the Z80 to determine which make of device it is and run it through its paces. Note, not everything is tested, but it will test basic instruction processing and IO.

    The later V2 of the board also includes additional headers to break out the two IO ports and includes the option for IO input too.

    The memory map is as follows:

    0000-7FFFROM8000-FFFFRAMb1111 1110 (IO)IO PORT Ab1111 1101 (IO)IO PORT B

    Key components from the original design:

    • 32K x8 27C256 or 29C256 ROM.
    • 32K x8 SRAM (e.g. 61256, 62256, etc).
    • 16MHz and 20MHz oscillator through a 74HC04 hex inverter into a 74LS393 4-bit binary counter for subdividing.
    • 74LS573 for the INPUT port and 2x74LS574 for the OUTPUT ports (LEDs).
    • 74LS02 quad 2-input NORs for address logic for the ROM/RAM selection and IO ports.
    • Direct USB (5V) powered.
    • RESET and NMI button switches.

    As I say though, the provided Gerber files present a neat design all ready to go, but on a 109×124 mm PCB. I want to see if I can get it into the magic 100×100 mm cheap PCB footprint.

    My Z80 Tester Design

    I don’t need the external IO features, so I can lose the 74LS573 and associated circuitry. This also means I can reuse the logic that has to decode IO reads, which also allows me to lose one of the three 74LS02s.

    Pretty much everything else is the same. A0-A14 are routed to both ROM and RAM. D0-D7 are routed to both ROM and RAM, and the two IO ports via the two 74LS574s.

    The address decoder logic is as follows.

    The left-hand side signals come from the Z80 and the right-hand side signals go off to the memory or IO ports. CP0 enables PORT A and CP1 enables PORT B. The other signals are mapped as follows.

    Z80 SignalsControl SignalDestinations/WR
    /MREQ/MEMWRRAM /WE/RD
    /MREQ/MEMRDROM /OE
    RAM /OEA15/RAM_ENRAM /CSA15A15ROM /CE/WR
    /IORQ
    /A0CP0PORT A Cp/WR
    /IORQ
    /A1CP1PORT B Cp

    From this we can see that A15 selects between ROM and RAM (inverted to create /RAM_EN) and the memory read/write signals come from /MREQ and /RD or /WR respectively.

    For the IO access, we can see that only /WR is supported and keyed into /IORQ. Then CP0 or CP1 are enabled depending on the state of A0 or A1 respectively. No other address decoding is performed for IO, so any values of A2 onwards are essentially irrelevant. I guess it is also possible to write to both ports at the same time using an address where both A0 and A1 are cleared (LOW).

    The other piece of control logic worth noting is that the following signals on the Z80 are all pulled HIGH: /BUSREQ, /INT, /HALT, /WAIT.

    /RESET and /NMI are also pulled HIGH but connected to a push button switch to allow them to be pulled LOW to activate them. I’ve used the circuits directly from the original here.

    The clock circuit is again directly taken from the original:

    This provides a jumper to select between 16MHz and 20MHz. It then passes through two inverters, presumably to clean it up, and then further jumpers to connect the output of the 4-bit binary counter to provide the actual used CLK signal.

    Here is one of the output PORTs connected to 8 LEDs.

    We can see that this is triggered by CP0. PORTB is the same but triggered by CP1.

    PORT A is used as an indicator that the tests are running. PORTB is used as an indicator for the type of Z80 CPU detected.

    Here is the extract on decoding PORTB from the original Hardware (V2) English Manual:

    The Big Fail

    It turns out that removing the INPUT was based on a wrong assumption.

    It wasn’t clearly documented that I could find initially, but after following some links from some links from a readme as part of researching this blog, I found the original code that everything is based on (here).

    It turns out that the CMOS/NMOS detection relies on an undocumented OUT (C), 0 instruction. This can be hard-coded into the assembly with the line:

    defb $ed, $71

    Which will force the unrecognised “OUT (C), 0” instruction to appear in the code. This apparently will output $00 for an NMOS device and $FF for a CMOS device. This has to be read back via a subsequent IN instruction to see what kind of chip is present.

    Here in lies the problem. Without an IN device containing the latched output value, this won’t work. Sigh.

    The original circuit uses a 74ALS990 read-back latch, which is quite hard to come by. The second version uses the combination of 74LS573, 74LS574 and transistors.

    At this point I went off to the other circuit I discovered here: https://github.com/djtersteegc/z80-cmos-nmos-tester

    As full design files are available for this one, and the PCB is withing the fabled 100×100 mm size, at this point I abandoned my own attempt and just got some of these boards ordered!

    Further Thoughts

    Seeing as I have some boards on the way though, I am pondering possible ways to get some use out of them. As the key undefined behaviour we’re interested in, is an OUT instruction, I’m now pondering if a sequence like:

    LD C, 0
    LD A, $FF
    OUT (C), A ; LEDs ON
    XOR A
    OUT (C), A ; LEDs OFF
    defb $ed, $71 ;OUT (C), 0
    OUT (C), A ; LEDs OFF
    LD A, $FF
    OUT (C), A ; LEDs ON
    XOR A
    OUT (C), A ; LEDs OFF

    With some appropriate delays, might be possible. As C is the address for the PORT driving the LEDs, then this would have the effect of flashing them twice for NMOS or flashing three times for CMOS.

    Of course it renders the CMOS indicator itself LED useless. But I think this might work as an indicator, so this is one to test when the boards come back.

    Someone Else’s Working Design

    I’m still deciding if it is worth spending any more time on my board – either attempting to get the one I’ve now received working, or just redesigning a V2.

    In the mean time, I’ve built up the existing one, which is a lot simpler design:

    • It has no RAM, running only from ROM.
    • It has no INPUT readback.
    • It only uses a single port of 8 LEDs.

    This works by flashing a number of times to indicate the type of Z80 – 1 flash for NMOS, 2 for CMOS and 3 for a U880. So as there is no INPUT readback, this must be doing exactly what I was pondering above – a sequence of OUT instructions, some of which will illuminate the LEDs (for a CMOS chip) and some of which won’t (for NMOS).

    On passing a number of cheap Z80’s (all marked as Z84C0020PEC – yeah right ;)), I’ve ended up with most being NMOS, but running at least up to 8MHz, and two being CMOS. Two don’t seem to run at any frequency, so I’m guessing they are dead on arrival.

    At present, I don’t have a 16MHz and 20MHz crystal, so I’m only testing up to 10MHz for now.

    Conclusion

    There is always a danger when modifying designs that something isn’t fully appreciated. And it gets worse with designs that are respins of earlier designs, and in this case that was a respin of yet another.

    I often find that some of these projects that are widely used are often based on design decisions that seem lost in the mists of time. Or at least the depths of a random forum somewhere.

    Anyway, this was one case where I was only considering the hardware as it appeared and not why it might have been the way it was. Oh well. All I’ve lost is an afternoon’s fun designing a board and around £5 on a PCB that will probably be useless once it arrives.

    Ironically if I’d started this post prior to sending, I would almost certainly have found the error. As it happens, I started writing this a few hours after hitting “upload” and the erroneous board is now already in production! One day I’ll learn this lesson 🙂

    Still on the plus side, the other board was only following on a few hours behind.

    Kevin

    #cmos #logic #nmos #pcb
  6. Interesting video from Caltech (where I went to college) and JPL about the invention of CMOS image sensors (though Wikipedia makes me think lots of others were working in this area at the time) in the 1990s.

    youtu.be/LqSLD4LBEIU

    Amazingly I bought my first digital camera, a $600 Olympus with 640x480 resolution and non-removable memory for only 20 such images (I think it was the D-200L) in time for my cross country bicycle trip in 1997.

    #Caltech #JPL #CMOS #DigitalCamera #1990s #Olympus

  7. Interesting video from Caltech (where I went to college) and JPL about the invention of CMOS image sensors (though Wikipedia makes me think lots of others were working in this area at the time) in the 1990s.

    youtu.be/LqSLD4LBEIU

    Amazingly I bought my first digital camera, a $600 Olympus with 640x480 resolution and non-removable memory for only 20 such images (I think it was the D-200L) in time for my cross country bicycle trip in 1997.

    #Caltech #JPL #CMOS #DigitalCamera #1990s #Olympus

  8. Interesting video from Caltech (where I went to college) and JPL about the invention of CMOS image sensors (though Wikipedia makes me think lots of others were working in this area at the time) in the 1990s.

    youtu.be/LqSLD4LBEIU

    Amazingly I bought my first digital camera, a $600 Olympus with 640x480 resolution and non-removable memory for only 20 such images (I think it was the D-200L) in time for my cross country bicycle trip in 1997.

    #Caltech #JPL #CMOS #DigitalCamera #1990s #Olympus

  9. Interesting video from Caltech (where I went to college) and JPL about the invention of CMOS image sensors (though Wikipedia makes me think lots of others were working in this area at the time) in the 1990s.

    youtu.be/LqSLD4LBEIU

    Amazingly I bought my first digital camera, a $600 Olympus with 640x480 resolution and non-removable memory for only 20 such images (I think it was the D-200L) in time for my cross country bicycle trip in 1997.

    #Caltech #JPL #CMOS #DigitalCamera #1990s #Olympus

  10. Interesting video from Caltech (where I went to college) and JPL about the invention of CMOS image sensors (though Wikipedia makes me think lots of others were working in this area at the time) in the 1990s.

    youtu.be/LqSLD4LBEIU

    Amazingly I bought my first digital camera, a $600 Olympus with 640x480 resolution and non-removable memory for only 20 such images (I think it was the D-200L) in time for my cross country bicycle trip in 1997.

    #Caltech #JPL #CMOS #DigitalCamera #1990s #Olympus

  11. #CMOS Meteorological and Oceanographic Society #meteorology #weatherForecast

    Two lectures on the Silanniarviit #weather station project, which was established to provide real time weather information for community members across Inuit Nunangat

    youtube.com/watch?v=ZCzPc3EsDBY

  12. FYI: Zeta Global's Athena is now live - and it's targeting CMOs directly: Zeta Global today opened Athena to all ZMP customers, an AI agent built on OpenAI models that converts enterprise data into predictive marketing decisions with 6x reported ROAS. ppc.land/zeta-globals-athena-i #ZetaGlobal #Athena #CMOs #Marketing #AI

  13. ICYMI: Sorrell says CFOs, not CMOs, will force AI adoption in agencies: Sir Martin Sorrell argues agency holding companies face overcapacity and structural decline as CFOs drive AI adoption, with Monks producing millions of assets for GM and BMW. ppc.land/sorrell-says-cfos-not #AIAdoption #CFOs #CMOs #DigitalMarketing #AgencyLife

  14. Just found IADIY.COM as a source for embedded camera lens systems. I've been looking for how to use a surface mount CMOS camera sensor, and it looks like an M5 or M7 lens system from IADIY might work. Just ordered 8 of these super small lens systems, which should each fit within an 8mm by 8mm square for the tip of our pen-like stylus product to allow a blind person to feel visual art through a haptic interface.

    iadiy.com/board-camera-lens

    #blind #a11y #fosh #foss #ee #optics #pcb #cmos #sensor #lens #bce #pensee #maker

  15. CMOs say they trust agencies but still switch them anyway: CMOs across Europe claim to view agencies as trustworthy partners yet continue to undermine relationships by holding constant pitches and changing agencies. ppc.land/cmos-say-they-trust-a #CMOs #Marketing #Agencies #Trust #Partnerships

  16. I'm looking at a potential camera for our first accessibility tool. It's a 60 FPS 640x480 color camera with a parallel output. If I'm not mistaken, it looks like the specifications for configuring it are publicly disclosed in the available datasheet.

    digikey.com/en/products/detail

    #ee #camera #cmos #pcb #fosh #foss

  17. Electronics idea.

    There are opamps with bipolar junction transistors (BJT) in the input stage.

    There are others with junction field-effect transistors (JFET) in the input stage.

    There are yet others with metal-oxide semiconductor field effect transistors (MOSFET) [1] in the input stage.

    Idea: find an application for the bizarre possibility of an opamp with insulated-gate bipolar transistors (IGBT) in the input stage. This is more stunt-designing than anything practical.

    [1] IIUC, "CMOS" opamps are really just MOSFET-input opamps. I'm not sure why the process technology name is more commonly used rather than the device type as is universally used for BJT and JFET input opamps.

    #OpAmp #electronics #OperationalAmplifier #JFET #BJT #MOSFET #IGBT #CMOS #stunt

  18. P-type semiconductor? N-type? NPN? ? is dope!

    And you can build and simulate yourself: app.siliwiz.com/?preset=nmos

    I bought Last Call BBS from Zachtronics to learn, but it's a game, simplified to the point where capacitors discharge instantly.

    Meanwhile, siliwiz is used as a tutorial for designers of actual circuits in Tiny Tapeout:

    tinytapeout.com/siliwiz/resist

    Brb, redoing game challenges in simulator.

  19. If you've done any assembly language programming, especially on the C64 certain hex numbers stay in your mind forever.

    I have a set of these floating in my Hex Memory Matrix which pop up under various circumstances.

    I loved writing to the display on the VIC IC with the ROM routines. Logical that that Hex address is in the upper range of the hex matrix. The same with writing to the SID chip.

    #RetroTechnology #RetroComputing #Commodore #C64 #CMOS #SID #VIC #programming #assembly #mnemonics

  20. Commodore C64 Basic V2
    38911 Basic bytes free
    Ready

    This is what I remember from my C64 starting up.

    Of course I had already protected the Program Logic Array 96114 with a heat sink after I replace it while socketing the new IC

    #RetroTechnology #RetroComputing #Technology #Commodore #Amiga #C64 #CMOS #PLA906114

  21. [Перевод] Невидимая оборона 386: как защищены входы и выходы процессора

    Я давно занимаюсь реверс-инжинирингом процессора Intel 386 и недавно наткнулся на любопытные схемы узлов выводов ввода/вывода (I/O). Поскольку эти выводы взаимодействуют с внешним миром, им угрожают особые опасности: статическое электричество и защёлкивание (latch-up) способны разрушить кристалл, а метастабильность — вызвать серьёзные сбои. Эти узлы ввода-вывода полностью отличаются от логических схем процессора 386, и мне попалась ранее не описанная схема триггера, так что я вступаю на неизведанную территорию. В этой статье я подробно разбираю, как именно узлы ввода-вывода защищают 386 от «драконов», способных его уничтожить. Читать технический разбор 386

    habr.com/ru/companies/otus/art

    #микросхема #процессор_386 #метастабильность #защита_IO #схемотехника #кремний #CMOS #реверсинжиниринг

  22. @mjg

    I love the fact that you also really like the Commodore 64, which means that you may have intimate knowledge of the Program Logic Array 906122

    I love that IC because the fact that it got so hot beyond 70° C which was its Max operating temperature, I learned how to replace these ICS at a very young age on the C64. I could already solder very fluently at the tender age of 8.

    #RetroTechnology #RetroComputing #Commodore #C64 #CMOS #SID

  23. Op-Amp Challenge: MOSFETs Make This Discrete Op Amp Tick - When it comes to our analog designs, op-amps tend to be just another jellybean par... - hackaday.com/2023/05/20/op-amp #operationalamplifier #opampchallenge #contests #mosfet #op-amp #parts #cmos

  24. Got my stupid editing song in my head again:

    (extremely Frank Sinatra voice)
    Chicago, Chicago, that manual of style!
    Chicago, Chicago, I'll edit a while
    I love it!
    Betcha bottom footnote you'll choose to use
    with Chicago, Chicago
    The style that Kate Turabian can't shut down!
    I had the time, the time of my life, and
    I know which compound words take a hyphen
    Chicago! My home style!

    #Academic #AcademicEditing #Copyediting #Citation #Referencing #CMOS #ChicagoManualOfStyle #Turabian

  25. Got my stupid editing song in my head again:

    (extremely Frank Sinatra voice)
    Chicago, Chicago, that manual of style!
    Chicago, Chicago, I'll edit a while
    I love it!
    Betcha bottom footnote you'll choose to use
    with Chicago, Chicago
    The style that Kate Turabian can't shut down!
    I had the time, the time of my life, and
    I know which compound words take a hyphen
    Chicago! My home style!

    #Academic #AcademicEditing #Copyediting #Citation #Referencing #CMOS #ChicagoManualOfStyle #Turabian

  26. Got my stupid editing song in my head again:

    (extremely Frank Sinatra voice)
    Chicago, Chicago, that manual of style!
    Chicago, Chicago, I'll edit a while
    I love it!
    Betcha bottom footnote you'll choose to use
    with Chicago, Chicago
    The style that Kate Turabian can't shut down!
    I had the time, the time of my life, and
    I know which compound words take a hyphen
    Chicago! My home style!

    #Academic #AcademicEditing #Copyediting #Citation #Referencing #CMOS #ChicagoManualOfStyle #Turabian

  27. Got my stupid editing song in my head again:

    (extremely Frank Sinatra voice)
    Chicago, Chicago, that manual of style!
    Chicago, Chicago, I'll edit a while
    I love it!
    Betcha bottom footnote you'll choose to use
    with Chicago, Chicago
    The style that Kate Turabian can't shut down!
    I had the time, the time of my life, and
    I know which compound words take a hyphen
    Chicago! My home style!

    #Academic #AcademicEditing #Copyediting #Citation #Referencing #CMOS #ChicagoManualOfStyle #Turabian

  28. Got my stupid editing song in my head again:

    (extremely Frank Sinatra voice)
    Chicago, Chicago, that manual of style!
    Chicago, Chicago, I'll edit a while
    I love it!
    Betcha bottom footnote you'll choose to use
    with Chicago, Chicago
    The style that Kate Turabian can't shut down!
    I had the time, the time of my life, and
    I know which compound words take a hyphen
    Chicago! My home style!

    #Academic #AcademicEditing #Copyediting #Citation #Referencing #CMOS #ChicagoManualOfStyle #Turabian

  29. At last, some sounds! Here's 20 minutes of different patches on my new synth. I'm still learning to play it, here are some sounds that aren't too difficult to create with it. I'm sure there are a billion more, just waiting to be discovered.

    #lunetta #synthdiy #cmos #analog #synthjam

    https://www.youtube.com/watch?v=Ur00thCWRwE