#pcb — Public Fediverse posts

A medida que fui avanzando con el software, también se fue definiendo el hardware, y hoy llegó el momento de dar un paso importante: empezar el diseño del PCB prototipo de mi Timbre Escolar Inteligente.

El proyecto ya viene tomando forma con la lógica de control, la interfaz web y la comunicación por WebSocket, y ahora toca materializar esas ideas en una placa pensada para ser más ordenada, compacta y confiable.

Este tipo de avances son los que más me entusiasman, porque transforman una idea de software en un sistema completo, listo para iterar, probar y mejorar.

Próximo paso: comenzar el ruteo del PCB y preparar la primera versión física del prototipo.

#Electrónica #PCB #ESP8266 #IoT #EmbeddedSystems #Arduino #WebSockets #ProyectoPersonal #Ingeniería

A medida que fui avanzando con el software, también se fue definiendo el hardware, y hoy llegó el momento de dar un paso importante: empezar el diseño del PCB prototipo de mi Timbre Escolar Inteligente.

El proyecto ya viene tomando forma con la lógica de control, la interfaz web y la comunicación por WebSocket, y ahora toca materializar esas ideas en una placa pensada para ser más ordenada, compacta y confiable.

Este tipo de avances son los que más me entusiasman, porque transforman una idea de software en un sistema completo, listo para iterar, probar y mejorar.

Próximo paso: comenzar el ruteo del PCB y preparar la primera versión física del prototipo.

#Electrónica #PCB #ESP8266 #IoT #EmbeddedSystems #Arduino #WebSockets #ProyectoPersonal #Ingeniería

A medida que fui avanzando con el software, también se fue definiendo el hardware, y hoy llegó el momento de dar un paso importante: empezar el diseño del PCB prototipo de mi Timbre Escolar Inteligente.

El proyecto ya viene tomando forma con la lógica de control, la interfaz web y la comunicación por WebSocket, y ahora toca materializar esas ideas en una placa pensada para ser más ordenada, compacta y confiable.

Este tipo de avances son los que más me entusiasman, porque transforman una idea de software en un sistema completo, listo para iterar, probar y mejorar.

Próximo paso: comenzar el ruteo del PCB y preparar la primera versión física del prototipo.

#Electrónica #PCB #ESP8266 #IoT #EmbeddedSystems #Arduino #WebSockets #ProyectoPersonal #Ingeniería

A medida que fui avanzando con el software, también se fue definiendo el hardware, y hoy llegó el momento de dar un paso importante: empezar el diseño del PCB prototipo de mi Timbre Escolar Inteligente.

El proyecto ya viene tomando forma con la lógica de control, la interfaz web y la comunicación por WebSocket, y ahora toca materializar esas ideas en una placa pensada para ser más ordenada, compacta y confiable.

Este tipo de avances son los que más me entusiasman, porque transforman una idea de software en un sistema completo, listo para iterar, probar y mejorar.

Próximo paso: comenzar el ruteo del PCB y preparar la primera versión física del prototipo.

#Electrónica #PCB #ESP8266 #IoT #EmbeddedSystems #Arduino #WebSockets #ProyectoPersonal #Ingeniería

A medida que fui avanzando con el software, también se fue definiendo el hardware, y hoy llegó el momento de dar un paso importante: empezar el diseño del PCB prototipo de mi Timbre Escolar Inteligente.

El proyecto ya viene tomando forma con la lógica de control, la interfaz web y la comunicación por WebSocket, y ahora toca materializar esas ideas en una placa pensada para ser más ordenada, compacta y confiable.

Este tipo de avances son los que más me entusiasman, porque transforman una idea de software en un sistema completo, listo para iterar, probar y mejorar.

Próximo paso: comenzar el ruteo del PCB y preparar la primera versión física del prototipo.

#Electrónica #PCB #ESP8266 #IoT #EmbeddedSystems #Arduino #WebSockets #ProyectoPersonal #Ingeniería

うーん、 #ヒタフネン #PCB

【銘板読み取り等によるＰＣＢ使用・不使用の見分け方】 http://web.archive.org/web/20250722010523/https://www.city.hiroshima.lg.jp/_res/projects/default_project/_page_/001/003/279/148572.pdf?

うーん、 #ヒタフネン #PCB

【銘板読み取り等によるＰＣＢ使用・不使用の見分け方】 http://web.archive.org/web/20250722010523/https://www.city.hiroshima.lg.jp/_res/projects/default_project/_page_/001/003/279/148572.pdf?

NextPCB Officially Launches Rev 0 PCBA — An Automated, No-Touch Prototype Assembly Service Built for Speed and Predictability (Sponsored)

https://fed.brid.gy/r/https://www.cnx-software.com/2026/05/13/nextpcb-officially-launches-rev-0-pcba-an-automated-no-touch-prototype-assembly-service-built-for-speed-and-predictability/

DIY-стенд для инспекции печатных плат (профиль, камера, шаговые двигатели и немного инженерного упрямства)

Я, как и многие, залип в датасеты , метрики и нейросети - и в какой-то момент понял, что почти не думаю о главном, как вообще проходит процесс инспекции печатных плат. Чтобы закрыть вопрос реального процесса инспекции печатных плат, было принято решение собрать собственный компактный стенд (подиум на алюминиевом профиле, камера, два шаговых двигателя и много (очень много) хомутов для проведения автоматической инспекции. Основные критерии, которые были заложены в основу будущего стенда: он должен быть простым в управлении, достаточно компактным, чтобы уместиться на рабочем столе и универсальным. Чтобы была возможность решать различные задачи инспекции. В статье расскажу, почему я не стал делать конвейер, как в промышленности, какие компромиссы пришлось принять, что пошло не так при сборке и почему этот DIY-подход оказался полезнее, чем ещё один прогон модели на готовом датасете. Если коротко, то я собрал из того, что было под рукой (местами буквально "на коленке"), и это неожиданно дало больше понимания, чем ещё одно обучение модели.

https://habr.com/ru/articles/1034422/

#diy #ии #стенд #из_говна_и_палок #диплом #ниокр #pcb #computer_vision #detection #arduino

DIY-стенд для инспекции печатных плат (профиль, камера, шаговые двигатели и немного инженерного упрямства)

Я, как и многие, залип в датасеты , метрики и нейросети - и в какой-то момент понял, что почти не думаю о главном, как вообще проходит процесс инспекции печатных плат. Чтобы закрыть вопрос реального процесса инспекции печатных плат, было принято решение собрать собственный компактный стенд (подиум на алюминиевом профиле, камера, два шаговых двигателя и много (очень много) хомутов для проведения автоматической инспекции. Основные критерии, которые были заложены в основу будущего стенда: он должен быть простым в управлении, достаточно компактным, чтобы уместиться на рабочем столе и универсальным. Чтобы была возможность решать различные задачи инспекции. В статье расскажу, почему я не стал делать конвейер, как в промышленности, какие компромиссы пришлось принять, что пошло не так при сборке и почему этот DIY-подход оказался полезнее, чем ещё один прогон модели на готовом датасете. Если коротко, то я собрал из того, что было под рукой (местами буквально "на коленке"), и это неожиданно дало больше понимания, чем ещё одно обучение модели.

https://habr.com/ru/articles/1034422/

#diy #ии #стенд #из_говна_и_палок #диплом #ниокр #pcb #computer_vision #detection #arduino

DIY-стенд для инспекции печатных плат (профиль, камера, шаговые двигатели и немного инженерного упрямства)

Я, как и многие, залип в датасеты , метрики и нейросети - и в какой-то момент понял, что почти не думаю о главном, как вообще проходит процесс инспекции печатных плат. Чтобы закрыть вопрос реального процесса инспекции печатных плат, было принято решение собрать собственный компактный стенд (подиум на алюминиевом профиле, камера, два шаговых двигателя и много (очень много) хомутов для проведения автоматической инспекции. Основные критерии, которые были заложены в основу будущего стенда: он должен быть простым в управлении, достаточно компактным, чтобы уместиться на рабочем столе и универсальным. Чтобы была возможность решать различные задачи инспекции. В статье расскажу, почему я не стал делать конвейер, как в промышленности, какие компромиссы пришлось принять, что пошло не так при сборке и почему этот DIY-подход оказался полезнее, чем ещё один прогон модели на готовом датасете. Если коротко, то я собрал из того, что было под рукой (местами буквально "на коленке"), и это неожиданно дало больше понимания, чем ещё одно обучение модели.

https://habr.com/ru/articles/1034422/

#diy #ии #стенд #из_говна_и_палок #диплом #ниокр #pcb #computer_vision #detection #arduino

DIY-стенд для инспекции печатных плат (профиль, камера, шаговые двигатели и немного инженерного упрямства)

Я, как и многие, залип в датасеты , метрики и нейросети - и в какой-то момент понял, что почти не думаю о главном, как вообще проходит процесс инспекции печатных плат. Чтобы закрыть вопрос реального процесса инспекции печатных плат, было принято решение собрать собственный компактный стенд (подиум на алюминиевом профиле, камера, два шаговых двигателя и много (очень много) хомутов для проведения автоматической инспекции. Основные критерии, которые были заложены в основу будущего стенда: он должен быть простым в управлении, достаточно компактным, чтобы уместиться на рабочем столе и универсальным. Чтобы была возможность решать различные задачи инспекции. В статье расскажу, почему я не стал делать конвейер, как в промышленности, какие компромиссы пришлось принять, что пошло не так при сборке и почему этот DIY-подход оказался полезнее, чем ещё один прогон модели на готовом датасете. Если коротко, то я собрал из того, что было под рукой (местами буквально "на коленке"), и это неожиданно дало больше понимания, чем ещё одно обучение модели.

https://habr.com/ru/articles/1034422/

#diy #ии #стенд #из_говна_и_палок #диплом #ниокр #pcb #computer_vision #detection #arduino

RC2014 Bus Reverser

I’m not sure quite how universal this is, but this started because I wanted to add a single RC2014 card to my Easy Z80, which supports an RC2014 bus interface.

Easy, I thought, just add a 40-way socket and the card will plug in. And in principle it would. I would end up with something like this.

But then I realised that the orientation of the RC2014 bus was probably meant to be used for pin headers to make the EasyZ80 be more of a CPU card in a bus system, as shown below.

But what I’m heading towards is being able to plug in a compact flash card, which means connecting the following:

And in either of the above configurations, the cards will be sticking out at odd angles, and feeling somewhat precarious. It would be great if I could just connect them horizontally as shown above.

So that is what I’ve built.

This is an RC2014 bus pin reverser. In the photo above pin 1 is at the bottom on the left hand side and at the top of the right hand side.

There is an option to not pass through VCC, just in case at some point I wanted to connect two independently powered systems.

Originally I envisaged the silkscreen as shown above being the top, but it turns out I got things the wrong way round for that to happen. And it does need to be the right way around as the VCC connection is a wider track and GND connects to the GND fill. Also the jumper and capacitor would be between the wrong two connections if I tried to connect it up the other way round. I guess what I’m saying is that it is not a fully symmetrical reversal of all 40 pins.

It actually works quite well for any “all in one” CPU card being connected to a single IO card. Below I have my RC2014 Micro connected to the digital IO module.

There isn’t a lot else to say really. The BOM is pretty minimal: just two 40-way right angle headers in addition to the PCB, capacitor and jumper. The capacitor and jumper are optional and the jumper can be replaced with a wire link if required.

The schematic and PCB files can be found on GitHub here.

I originally thought the converter would have pin headers on one side and a pin socket on the other. But once I realised I really wanted to connect a card to a card, the use of two sets of pin sockets seemed right. But really, any combination can obviously be used if it works.

Note: I have no idea what this does to any signal integrity. There is certainly no attempt to keep trace lengths equal or anything like that. But I figure if the RC22014 can get away with pin headers in the first place, I suspect that kind of thing is not going to be a big issue.

Kevin

RC2014 Bus Reverser

I’m not sure quite how universal this is, but this started because I wanted to add a single RC2014 card to my Easy Z80, which supports an RC2014 bus interface.

Easy, I thought, just add a 40-way socket and the card will plug in. And in principle it would. I would end up with something like this.

But then I realised that the orientation of the RC2014 bus was probably meant to be used for pin headers to make the EasyZ80 be more of a CPU card in a bus system, as shown below.

But what I’m heading towards is being able to plug in a compact flash card, which means connecting the following:

And in either of the above configurations, the cards will be sticking out at odd angles, and feeling somewhat precarious. It would be great if I could just connect them horizontally as shown above.

So that is what I’ve built.

This is an RC2014 bus pin reverser. In the photo above pin 1 is at the bottom on the left hand side and at the top of the right hand side.

There is an option to not pass through VCC, just in case at some point I wanted to connect two independently powered systems.

Originally I envisaged the silkscreen as shown above being the top, but it turns out I got things the wrong way round for that to happen. And it does need to be the right way around as the VCC connection is a wider track and GND connects to the GND fill. Also the jumper and capacitor would be between the wrong two connections if I tried to connect it up the other way round. I guess what I’m saying is that it is not a fully symmetrical reversal of all 40 pins.

It actually works quite well for any “all in one” CPU card being connected to a single IO card. Below I have my RC2014 Micro connected to the digital IO module.

There isn’t a lot else to say really. The BOM is pretty minimal: just two 40-way right angle headers in addition to the PCB, capacitor and jumper. The capacitor and jumper are optional and the jumper can be replaced with a wire link if required.

The schematic and PCB files can be found on GitHub here.

I originally thought the converter would have pin headers on one side and a pin socket on the other. But once I realised I really wanted to connect a card to a card, the use of two sets of pin sockets seemed right. But really, any combination can obviously be used if it works.

Note: I have no idea what this does to any signal integrity. There is certainly no attempt to keep trace lengths equal or anything like that. But I figure if the RC22014 can get away with pin headers in the first place, I suspect that kind of thing is not going to be a big issue.

Kevin

RC2014 Bus Reverser

I’m not sure quite how universal this is, but this started because I wanted to add a single RC2014 card to my Easy Z80, which supports an RC2014 bus interface.

Easy, I thought, just add a 40-way socket and the card will plug in. And in principle it would. I would end up with something like this.

But then I realised that the orientation of the RC2014 bus was probably meant to be used for pin headers to make the EasyZ80 be more of a CPU card in a bus system, as shown below.

But what I’m heading towards is being able to plug in a compact flash card, which means connecting the following:

And in either of the above configurations, the cards will be sticking out at odd angles, and feeling somewhat precarious. It would be great if I could just connect them horizontally as shown above.

So that is what I’ve built.

This is an RC2014 bus pin reverser. In the photo above pin 1 is at the bottom on the left hand side and at the top of the right hand side.

There is an option to not pass through VCC, just in case at some point I wanted to connect two independently powered systems.

Originally I envisaged the silkscreen as shown above being the top, but it turns out I got things the wrong way round for that to happen. And it does need to be the right way around as the VCC connection is a wider track and GND connects to the GND fill. Also the jumper and capacitor would be between the wrong two connections if I tried to connect it up the other way round. I guess what I’m saying is that it is not a fully symmetrical reversal of all 40 pins.

It actually works quite well for any “all in one” CPU card being connected to a single IO card. Below I have my RC2014 Micro connected to the digital IO module.

There isn’t a lot else to say really. The BOM is pretty minimal: just two 40-way right angle headers in addition to the PCB, capacitor and jumper. The capacitor and jumper are optional and the jumper can be replaced with a wire link if required.

The schematic and PCB files can be found on GitHub here.

I originally thought the converter would have pin headers on one side and a pin socket on the other. But once I realised I really wanted to connect a card to a card, the use of two sets of pin sockets seemed right. But really, any combination can obviously be used if it works.

Note: I have no idea what this does to any signal integrity. There is certainly no attempt to keep trace lengths equal or anything like that. But I figure if the RC22014 can get away with pin headers in the first place, I suspect that kind of thing is not going to be a big issue.

Kevin

RC2014 Bus Reverser

I’m not sure quite how universal this is, but this started because I wanted to add a single RC2014 card to my Easy Z80, which supports an RC2014 bus interface.

Easy, I thought, just add a 40-way socket and the card will plug in. And in principle it would. I would end up with something like this.

But then I realised that the orientation of the RC2014 bus was probably meant to be used for pin headers to make the EasyZ80 be more of a CPU card in a bus system, as shown below.

But what I’m heading towards is being able to plug in a compact flash card, which means connecting the following:

And in either of the above configurations, the cards will be sticking out at odd angles, and feeling somewhat precarious. It would be great if I could just connect them horizontally as shown above.

So that is what I’ve built.

This is an RC2014 bus pin reverser. In the photo above pin 1 is at the bottom on the left hand side and at the top of the right hand side.

There is an option to not pass through VCC, just in case at some point I wanted to connect two independently powered systems.

Originally I envisaged the silkscreen as shown above being the top, but it turns out I got things the wrong way round for that to happen. And it does need to be the right way around as the VCC connection is a wider track and GND connects to the GND fill. Also the jumper and capacitor would be between the wrong two connections if I tried to connect it up the other way round. I guess what I’m saying is that it is not a fully symmetrical reversal of all 40 pins.

It actually works quite well for any “all in one” CPU card being connected to a single IO card. Below I have my RC2014 Micro connected to the digital IO module.

There isn’t a lot else to say really. The BOM is pretty minimal: just two 40-way right angle headers in addition to the PCB, capacitor and jumper. The capacitor and jumper are optional and the jumper can be replaced with a wire link if required.

The schematic and PCB files can be found on GitHub here.

I originally thought the converter would have pin headers on one side and a pin socket on the other. But once I realised I really wanted to connect a card to a card, the use of two sets of pin sockets seemed right. But really, any combination can obviously be used if it works.

Note: I have no idea what this does to any signal integrity. There is certainly no attempt to keep trace lengths equal or anything like that. But I figure if the RC22014 can get away with pin headers in the first place, I suspect that kind of thing is not going to be a big issue.

Kevin

RC2014 Bus Reverser

I’m not sure quite how universal this is, but this started because I wanted to add a single RC2014 card to my Easy Z80, which supports an RC2014 bus interface.

Easy, I thought, just add a 40-way socket and the card will plug in. And in principle it would. I would end up with something like this.

But then I realised that the orientation of the RC2014 bus was probably meant to be used for pin headers to make the EasyZ80 be more of a CPU card in a bus system, as shown below.

But what I’m heading towards is being able to plug in a compact flash card, which means connecting the following:

And in either of the above configurations, the cards will be sticking out at odd angles, and feeling somewhat precarious. It would be great if I could just connect them horizontally as shown above.

So that is what I’ve built.

This is an RC2014 bus pin reverser. In the photo above pin 1 is at the bottom on the left hand side and at the top of the right hand side.

There is an option to not pass through VCC, just in case at some point I wanted to connect two independently powered systems.

Originally I envisaged the silkscreen as shown above being the top, but it turns out I got things the wrong way round for that to happen. And it does need to be the right way around as the VCC connection is a wider track and GND connects to the GND fill. Also the jumper and capacitor would be between the wrong two connections if I tried to connect it up the other way round. I guess what I’m saying is that it is not a fully symmetrical reversal of all 40 pins.

It actually works quite well for any “all in one” CPU card being connected to a single IO card. Below I have my RC2014 Micro connected to the digital IO module.

There isn’t a lot else to say really. The BOM is pretty minimal: just two 40-way right angle headers in addition to the PCB, capacitor and jumper. The capacitor and jumper are optional and the jumper can be replaced with a wire link if required.

The schematic and PCB files can be found on GitHub here.

I originally thought the converter would have pin headers on one side and a pin socket on the other. But once I realised I really wanted to connect a card to a card, the use of two sets of pin sockets seemed right. But really, any combination can obviously be used if it works.

Note: I have no idea what this does to any signal integrity. There is certainly no attempt to keep trace lengths equal or anything like that. But I figure if the RC22014 can get away with pin headers in the first place, I suspect that kind of thing is not going to be a big issue.

Kevin

Anyone knows eu based pcb manufacturing services (besides eurocircuits) with some reasonable prices for hobbysts / prototyping and / or low quantity manufacturing / assembly? #electronics #pcb #manufacturing

Anyone knows eu based pcb manufacturing services (besides eurocircuits) with some reasonable prices for hobbysts / prototyping and / or low quantity manufacturing / assembly? #electronics #pcb #manufacturing

Anyone knows eu based pcb manufacturing services (besides eurocircuits) with some reasonable prices for hobbysts / prototyping and / or low quantity manufacturing / assembly? #electronics #pcb #manufacturing

Anyone knows eu based pcb manufacturing services (besides eurocircuits) with some reasonable prices for hobbysts / prototyping and / or low quantity manufacturing / assembly? #electronics #pcb #manufacturing

Anyone knows eu based pcb manufacturing services (besides eurocircuits) with some reasonable prices for hobbysts / prototyping and / or low quantity manufacturing / assembly? #electronics #pcb #manufacturing

【統計情報】5月11日、日本電子回路工業会 #JPCA がプリント配線板輸出入動向を更新。2026年3月分を追加。財務省貿易統計による。数量と金額の国別データとグラフ (Excel, 172KB) は https://jpca.jp/wp-content/uploads/yushutsunyu_toukei.xlsx に。
#Statistics #PCB #Export #Import

5月9日にオープンソースのプリント基板CADソフト #KiCad ( https://www.kicad.org/ ) は、新版 KiCad 10.0.2 バグ修正リリースを発表。重要なバグ修正と軽微な改良を含む安定版。発表とChangelogは https://www.kicad.org/blog/2026/05/KiCad-10.0.2-Release/ に。ダウンロードは https://www.kicad.org/download/ から。
#Release #PCB #CAD

New Blogpost:
"How to repair electronic devices"

>Lot of stuff to lean
>tinker with electronics
>good for the planet

https://nucular.eu/posts/Repairing-Electronics-Chapter-1/

#electronics #repair #pcb

New Blogpost:
"How to repair electronic devices"

>Lot of stuff to lean
>tinker with electronics
>good for the planet

https://nucular.eu/posts/Repairing-Electronics-Chapter-1/

#electronics #repair #pcb

New Blogpost:
"How to repair electronic devices"

>Lot of stuff to lean
>tinker with electronics
>good for the planet

https://nucular.eu/posts/Repairing-Electronics-Chapter-1/

#electronics #repair #pcb

New Blogpost:
"How to repair electronic devices"

>Lot of stuff to lean
>tinker with electronics
>good for the planet

https://nucular.eu/posts/Repairing-Electronics-Chapter-1/

#electronics #repair #pcb

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:

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: 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

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:

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: 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

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:

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: 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

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:

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: 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

https://www.europesays.com/africa/226515/ PCB announces Fatima Sana-led squad for Zimbabwe T20Is – Cricket #AmberKainat #FatimaSana #PakistanCricket #PCB #SairaJabeen #squad #T20is #WomenCricket #zimbabwe

“Most of us probably have a mental image of tankers sailing through the Strait of Hormuz laden with Gulf crude, off to be processed by refineries somewhere else in the world. Certainly a load of oil takes just that route, but for the Saudis and other oil-producing nations in the region, it also makes economic sense to site petrochemical industries at source.

They export the much more valuable refined products, among which is the polymer #resin used in #PCBProduction. The Reuters report says that consequent to this and a rise in #copper prices, the cost of a #PCB in China has risen by 40%. Naturally this doesn’t sound like good news”

#HackADay / #computing / #shortages / #PCBShortage <https://hackaday.com/2026/05/06/youve-seen-the-chip-shortage-and-the-memory-shortage-now-prepare-for-the-pcb-shortage/>

“Most of us probably have a mental image of tankers sailing through the Strait of Hormuz laden with Gulf crude, off to be processed by refineries somewhere else in the world. Certainly a load of oil takes just that route, but for the Saudis and other oil-producing nations in the region, it also makes economic sense to site petrochemical industries at source.

They export the much more valuable refined products, among which is the polymer #resin used in #PCBProduction. The Reuters report says that consequent to this and a rise in #copper prices, the cost of a #PCB in China has risen by 40%. Naturally this doesn’t sound like good news”

#HackADay / #computing / #shortages / #PCBShortage <https://hackaday.com/2026/05/06/youve-seen-the-chip-shortage-and-the-memory-shortage-now-prepare-for-the-pcb-shortage/>

“Most of us probably have a mental image of tankers sailing through the Strait of Hormuz laden with Gulf crude, off to be processed by refineries somewhere else in the world. Certainly a load of oil takes just that route, but for the Saudis and other oil-producing nations in the region, it also makes economic sense to site petrochemical industries at source.

They export the much more valuable refined products, among which is the polymer #resin used in #PCBProduction. The Reuters report says that consequent to this and a rise in #copper prices, the cost of a #PCB in China has risen by 40%. Naturally this doesn’t sound like good news”

#HackADay / #computing / #shortages / #PCBShortage <https://hackaday.com/2026/05/06/youve-seen-the-chip-shortage-and-the-memory-shortage-now-prepare-for-the-pcb-shortage/>

“Most of us probably have a mental image of tankers sailing through the Strait of Hormuz laden with Gulf crude, off to be processed by refineries somewhere else in the world. Certainly a load of oil takes just that route, but for the Saudis and other oil-producing nations in the region, it also makes economic sense to site petrochemical industries at source.

They export the much more valuable refined products, among which is the polymer #resin used in #PCBProduction. The Reuters report says that consequent to this and a rise in #copper prices, the cost of a #PCB in China has risen by 40%. Naturally this doesn’t sound like good news”

#HackADay / #computing / #shortages / #PCBShortage <https://hackaday.com/2026/05/06/youve-seen-the-chip-shortage-and-the-memory-shortage-now-prepare-for-the-pcb-shortage/>

“Most of us probably have a mental image of tankers sailing through the Strait of Hormuz laden with Gulf crude, off to be processed by refineries somewhere else in the world. Certainly a load of oil takes just that route, but for the Saudis and other oil-producing nations in the region, it also makes economic sense to site petrochemical industries at source.

They export the much more valuable refined products, among which is the polymer #resin used in #PCBProduction. The Reuters report says that consequent to this and a rise in #copper prices, the cost of a #PCB in China has risen by 40%. Naturally this doesn’t sound like good news”

#HackADay / #computing / #shortages / #PCBShortage <https://hackaday.com/2026/05/06/youve-seen-the-chip-shortage-and-the-memory-shortage-now-prepare-for-the-pcb-shortage/>

Anyone know of a simple breakout PCB that has all of the different kinds of ZIF connector including clear labels on it that you can use to more easily prototype as well as identify which exact one you need to connect to a specific cable?

#PCB

Anyone know of a simple breakout PCB that has all of the different kinds of ZIF connector including clear labels on it that you can use to more easily prototype as well as identify which exact one you need to connect to a specific cable?

#PCB

Anyone know of a simple breakout PCB that has all of the different kinds of ZIF connector including clear labels on it that you can use to more easily prototype as well as identify which exact one you need to connect to a specific cable?

#PCB

Anyone know of a simple breakout PCB that has all of the different kinds of ZIF connector including clear labels on it that you can use to more easily prototype as well as identify which exact one you need to connect to a specific cable?

#PCB

【刊行物】5月1日に、基板実装の技術誌 #SMT007 の5月号が公開。今月号の特集は、“Spotlight on North America”(北米にスポットライト)。全66頁。閲覧は https://iconnect007.uberflip.com/i/1544707-smt007-may2026/ に、PDF版は https://magazines007.com/pdf/SMT007-MAY2026.pdf に。
#PCB #Assembly #Magazine

Quick test of the velocity sensitive buttons for the keytar.

I have to hold the 3d printed test rig in place so please forgive the shoddy note triggering. 😅 Overall it feels pretty good; there are 3 different velocity curves to choose from.

#diy #maker #pcb #3dprinting #midi #keytar #synth

Quick test of the velocity sensitive buttons for the keytar.

I have to hold the 3d printed test rig in place so please forgive the shoddy note triggering. 😅 Overall it feels pretty good; there are 3 different velocity curves to choose from.

#diy #maker #pcb #3dprinting #midi #keytar #synth

#Firefox shippt #Brave-#AdBlock-Engine, Looksmaxxing und das Harz der Apokalypse

c't 4004 – der c't-3003-Podcast: #Meta zwingt zum #Keylogger | 22

- 17:32:

Take der Woche: Warum man sich von Meta fernhalten sollte

-1:22:32 News aus der #Krise: #PCB-Harz wird knapp

- 1:32:32:

Firefox shippt heimlich Brave Adblock Engine

Webseite der Episode:
https://ct-3003.podigee.io/23-new-episode

Mediendatei:
https://audio.podigee-cdn.net/2482245-m-c27baab9b05f1a15697574de167edcd2.mp3?source=feed

#Vorratsdatenspeicherung
#Facebook

@ct_3003
@keno3003

#Firefox shippt #Brave-#AdBlock-Engine, Looksmaxxing und das Harz der Apokalypse

c't 4004 – der c't-3003-Podcast: #Meta zwingt zum #Keylogger | 22

- 17:32:

Take der Woche: Warum man sich von Meta fernhalten sollte

-1:22:32 News aus der #Krise: #PCB-Harz wird knapp

- 1:32:32:

Firefox shippt heimlich Brave Adblock Engine

Webseite der Episode:
https://ct-3003.podigee.io/23-new-episode

Mediendatei:
https://audio.podigee-cdn.net/2482245-m-c27baab9b05f1a15697574de167edcd2.mp3?source=feed

#Vorratsdatenspeicherung
#Facebook

@ct_3003
@keno3003

#Firefox shippt #Brave-#AdBlock-Engine, Looksmaxxing und das Harz der Apokalypse

c't 4004 – der c't-3003-Podcast: #Meta zwingt zum #Keylogger | 22

- 17:32:

Take der Woche: Warum man sich von Meta fernhalten sollte

-1:22:32 News aus der #Krise: #PCB-Harz wird knapp

- 1:32:32:

Firefox shippt heimlich Brave Adblock Engine

Webseite der Episode:
https://ct-3003.podigee.io/23-new-episode

Mediendatei:
https://audio.podigee-cdn.net/2482245-m-c27baab9b05f1a15697574de167edcd2.mp3?source=feed

#Vorratsdatenspeicherung
#Facebook

@ct_3003
@keno3003

#Firefox shippt #Brave-#AdBlock-Engine, Looksmaxxing und das Harz der Apokalypse

c't 4004 – der c't-3003-Podcast: #Meta zwingt zum #Keylogger | 22

- 17:32:

Take der Woche: Warum man sich von Meta fernhalten sollte

-1:22:32 News aus der #Krise: #PCB-Harz wird knapp

- 1:32:32:

Firefox shippt heimlich Brave Adblock Engine

Webseite der Episode:
https://ct-3003.podigee.io/23-new-episode

Mediendatei:
https://audio.podigee-cdn.net/2482245-m-c27baab9b05f1a15697574de167edcd2.mp3?source=feed

#Vorratsdatenspeicherung
#Facebook

@ct_3003
@keno3003

https://www.europesays.com/uk/943036/ Mohsin Naqvi: Mohsin Naqvi-led PCB rocked by billion-rupee crisis as PSL payment row explodes | Cricket News #Cricket #FinancialPressure #MohsinNaqvi #pakistan #PakistanCricketBoard #PakistanSuperLeague #PCB #psl #PSLTeams #Sports #SuperLeague #UK #UnitedKingdom #UnpaidDues