I've mostly been building 6502-based SBCs so I have some prior experience with 6502. Recently, I decided to try building one with Z80 for fun (CMOS TMPZ84C00, found one for ~$1 locally).

I went through Z80 datasheet and some resources on the internet. Here's what I came up with.

Design considerations:
- $0000-$7FFF - ROM
- $8000-$FFFF - RAM
- 8 LEDs for visual output
- Using perfboard for this, so trying to keep it small & simple - will be adding more fancy things later (LCD, UART, etc).
- Simple 8-bit output through '273 flip-flop.
- No input or interrupts for now.
- I used AS6C4008 in schematic since it's included in Kicad parts by default. I have various SRAM chips available. Same with W27C512 EPROM.

This is my first time doing anything with Z80, so please let me know if something seems terribly off.




Any feedback is greatly appreciated!

I think I found a minor issue that would bite me once I add interrupts.

I forgot that /IORQ goes low when an IRQ is being handled. This means accidental writes will happen to my '273 during interrupts.

Seems like the easiest way to handle this is to gate /IORQ with /M1 (since /M1 is asserted during IRQ vector access) by introducing /IOEN, so that it's asserted when /IORQ is low AND /M1 is high. Then I can safely use /IOEN instead of /IORQ for my I/O:

After some considerations, I've decided to add simple input through 8-section DIP switch & '244 tri-state buffer.

I also replaced my 10-gate NAND address decoding with a single ATF16V8: it leaves more space on my PCB and allows me to reconfigure address decoding logic after I have my PCB printed, since I'm pretty sure there are some oversights in my design and I'll likely need to change something there. PLD will make it much easier.

Ha, I totally forgot to tie unused RAM & ROM address lines low.
Having fixed that, I feel like this is the optimal version. Will be ordering a PCB tomorrow, hopefully I'll have it ready for testing by weekend!

looks nice!

Looks great. I suggest if there is a next version to provide some pins with the address, data, and control signals present. It would make it easier to expand the I/O.

Absolutely. I'm planning to use Z84C20 PIO or even 65C22 VIA in next build. The purpose of this board was to see it I can handle Z80 and to get a very basic board working with least mistakes - i. e. to make sure there are no oversights with address decoding and clock, and possibly with more stuff I haven't thought about.



I used a very simple program for my initial smoke test to see if CPU works at all and if my address decoding does handle RAM/ROM/IO properly.

Luckily, this build seems to work just fine! I'm surprised to have it at the first try. I guess my 6502 "experience" helped me somewhat.

Turns out I actually do have an issue: RAM doesn't seem to behave.

It seems like data is simply not written to RAM. Furthermore, reading from RAM makes D0 read random values: the LED is constantly blinking.
It feels like data bus is floating during RAM reads.



I've seen somewhere that Z80 has very weak address lines. But the rest of the chips work just fine: some of my programs that use ROM & IO ('244, & '273), without RAM - work fine



I'm wondering if the issue could be with /RD line not strong enough to enable RAM most of the time, and thus I could get floating data. All my chip-enabling lines are driven with ATF16V8B, I've used it in combo with AS6C4008 in the past without any issues. The lines that go from my Z80 to RAM are data bus, address bus, /RD, and /WD. Only RAM/EN (/CE) is controlled by ATF16V8.

Do I need some buffers on address bus? Is Z80 not strong enough to control my RAM? I wish I had a good oscilloscope...

Edit: found this thread - https://www.retrobrewcomputers.org/foru ... &#msg_6676, and as per their response seems like the safest way to go is indeed to have 3x '244 (address bus + control) & 1 '245 (data bus).

Edit 2: I'm also suspecting that the cheapo Z84C0020PEC chips that I've got might in fact be re-labeled NMOS versions...

Here's what I think should work for me:



- Data bus goes through '245, output during non-read cycles and input during read cycles (using /RD instead of /WR because Z80 drives data bus during T2 without asserting /WR).
- Address bus goes through '244, constantly enabled (I'm OK with having my Z80 constantly controlling the address bus - I don't plan to do any DMA or bus sharing).
- /RD and /WR are buffered through another '244, with additional version of /WR for chips that might require a non-zero bus hold time. AS6C4008 has a requirement for data hold time of 0, but I want to be on the safe side. I initially thought about 74LS14, but it's much slower than '244.
- I'm ignoring /BUSACK, /WAIT, & /HALT since I don't use them.

Once again, DipTrace does a wonderful job auto-routing all my mess:


Unfortunately, too little space is left for PIO. Will have to figure something out.

Hmm, a difficult one to debug - not easy even to see whether the write is bad, or the readback.

But I feel it unlikely that the problem is a lack of drive, or a need for buffers. It feels more likely to me to be a timing problem, or possibly a logic problem, such that the situation during a write (or a read) isn't quite what you think it is. (Could even be a noise problem, perhaps.)

Can you successfully write and read back to a peripheral chip?

Can you share the datasheet of your RAM?

Yeah, it's hard to probe my data lines because they seem to be heavily impacted by analyzer's capacitance.

I've tested with AS6C1008-55PCN - https://eu.mouser.com/datasheet/2/12/AS ... 511508.pdf - not 4008 as I previously thought.

I/O seems to work just fine: '244 correctly reads DIP switches when reading port 0, and '245 correctly latches all writes to port 1. Memory decoding with ATF16V8B also seems to yield correct chip selects, tested with a digital analyzer, and also wrote a simple test for my TL866 II Plus:




My code:


Also, 0.1uF caps are placed near every ICs. ROM also works perfectly: it's just the RAM that's behaving strangely.

I made a huge mistake not adding pin headers for bus & control lines: it would have made debugging much easier, especially for this first build.

Data line "seems" to be stable during writes to RAM - at least I can see the proper bits on data line.

I wonder if there's a simple way to differentiate whether it's a bad read, a bad write, or both: the only way I can think of is to halt the CPU and read from RAM using another device without powering it off.

Maybe you're right and I'm missing some obvious timing violation in my chip selection scheme... I still am not used to understanding some obscure parameters in datasheet timing tables. :[

EDIT: I've noticed that it's only D0 and D7 that feel to be floating during RAM reads: D1-D6 always yield logical 1, no matter which RAM address I'm reading, but D0 & D7 are flickering when I touch them.
EDIT 2: When adding 0.1s~0.5s busy loops, D0 blinks almost as if like it's toggled during every read. The blinking stops (becomes 0) when I touch it with my finger, tweezers, or attempt to probe it. However, this happens only when reading even addresses.
EDIT 3: D0 blinking behavior seems almost unchanged when I remove my RAM whatsoever.
EDIT 4: I tried 2 different 1008 RAMs, both reproduce all those issues.

It looks like you're qualifying your RAM access with M1, that's probably not a good idea.That's the CPU indicator that an opcode fetch is in process, it won't be active in a data read.

If you want to block refresh cycles from hitting memory then you need to have RFSH connected to the GAL. RFSH and M1 aren't mutually exclusive.

However with RD and WR connected to you RAM, there won't be any actual access, just a small increase in current as the RAM comes out of standby for the 2 refresh cycles when the chip enable is active.

Thanks - it totally flew over my head that I actually should not disable RAM when /M1 is asserted if I want to run code from RAM.

Another update: I found the problem... I'm using AS6C1008, but my schematic is AS6C4008. For compatibility with 1008, I used to pull A15-A18 high in the past.
However, in this build, I tied them low... While forgetting that in 1008, pin 30 is actually CE2 (active high)!
So I literally hard-wired RAM to be always off...

I'll break the trace to pin 30, tie it high and see if it does the trick. Will post shortly.

EDIT: Yep, that was it.

If you want to check your CPU really is CMOS, there's a way to do it in code.

Opcode ED 71 is officially undocumented. It's where OUT (C),(HL) would have been if it existed. On an NMOS CPU the effect is OUT (C),0. On the CMOS CPU it's effect is OUT (C),FF.

Source:https://groups.google.com/g/comp.os.cpm/c/HfSTFpaIkuU/m/KotvMWu3bZoJ

So if you load BC with the port address of the LEDs and follow that by the illegal opcode, you'll know from the state of the LEDs which type of CPU it is.

Interesting! I just tested and it wrote 0xFF, so my CPU is indeed CMOS. Thanks for a neat trick!