The Exhaustion of #Responsibility

#Humanity suffers from a peculiar #paradox.

We largely agree on many of the world's biggest problems. We know that extreme inequality destabilizes societies. We know that women should live free from violence. We know that climate change threatens ecosystems, economies and ultimately human civilization itself.

Yet knowledge rarely translates into action.

The reason may be surprisingly simple: meaningful change demands effort. It requires people to question habits, surrender privileges, consume less, participate politically and critically examine their own behavior. These are cognitively and emotionally costly activities. Humans tend to avoid such costs whenever possible.

Instead, we prefer narratives that reassure us. We support leaders who promise that difficult problems have painless solutions or that no real changes are necessary at all. Shared self-deception becomes socially acceptable because it reduces feelings of guilt. It is easier to maintain comforting illusions when millions of others do the same.

This contradiction is deeply human. Most people value animal welfare while contributing to industries that harm animals. Most people support environmental protection while maintaining lifestyles that increase emissions. Most people favor democratic principles while investing little time in democratic participation.

The problem is therefore not hypocrisy in the moral sense. It is inertia.

Democracy, social justice and sustainability require continuous engagement. They depend on citizens who are willing to think, learn, vote, organize and sometimes accept personal inconvenience. Freedom itself imposes obligations, and obligations are tiring.

Powerful individuals and institutions possess influence, but their power ultimately depends on public consent, indifference or passivity. Societies are not shaped solely by elites. They are shaped by millions of ordinary decisions made every day.

Human beings are capable of remarkable achievements. We eradicate diseases, build scientific instruments that reach distant planets and create systems of unprecedented cooperation. We are equally capable of ignoring foreseeable risks.

The central question is therefore not whether humanity understands its challenges.

It is whether humanity is willing to accept the discomfort that comes with addressing them.

Knowing what is right has never been enough.

Civilizations are ultimately defined by what they are prepared to do, not by what they merely acknowledge.

#civilization #future #logic #ethics #philosophy #democracy #environment #climate #change #society #protest #resistance #problem #politics #worldorder

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: github.com/djtersteegc/z80-cmo… 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: myretrostore.co.uk/product/z80… (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: github.com/slabbi/Z80-CPU-Test…

This is using firmware for the Z80 that uses a lot of the information from this: 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:

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.

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: github.com/djtersteegc/z80-cmo…

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, 0LD A, $FFOUT (C), A ; LEDs ONXOR AOUT (C), A ; LEDs OFFdefb $ed, $71 ;OUT (C), 0OUT (C), A ; LEDs OFFLD A, $FFOUT (C), A ; LEDs ONXOR AOUT (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