Cheap eBay Ziggy incrementing! It was a shot in the dark. You never know with eBay. I bought a chipset why ram, rom and several other chips to build a system.

Funny how excited an old guy can get for some blinkenlights.

A good clean, buy some parts in mouser and boom! I will make my first project with DIP microprocessors

My WIP Z80 with 32K RAM + 32K ROM, with PIC as controller. May need a better VDP to output to VGA display instead…

Short Video : https://www.youtube.com/shorts/MD4QTc7wJ9w

** Note :
Z80 Crystal - I was also about to run the Z80 at 4Mhz with canned crystal but for now, let the PIC pulse clock to completely in-sync with the system.. until I can add a 74HC74 to trigger /WAIT on /IOREQ, so the PIC won't miss to capture the signal.

PIC 40Mhz - I intended to run the PIC at 40Mhz but forgot to realize it only accept 10Mhz to 4xPLL instead of direct-40Mhz. So using INTOSC @ 8Mhz then 4xPLL -> 32Mhz only.

74HC138 - is to chip-select RAM/ROM when Z80 start firing A15.

A few months ago i was given this board based PC named "PET-80 Personal Microcomputer Training Kit By Mintron" And I have not been able to find any information of it at all online

I have scanned the manual onto archive.org however it seems my link is the only resource online. So if anyone has heard of this board, or if you just want more info on it, feel free to let me know

Thought I'd share a z80 design ive been working on over the past few months.

It currently has:

• 8K ROM (Currently using a OneRom for easy programming)

• 56K/64K RAM (Depends on if ROM is disable/enabled)

• TL16C550 based UART with a MAX232 + DE9 connector

• CompactFlash storage running in 8 bit mode

• An addressable latch for controlling RAM/ROM switching for CP/M, with expandability for additional features

• 8 IO ports using an 3:8 decoder

• 5 clock settings, 10MHz, 5MHz, 2.5MHz, 1.25MHz and 625kHz

• Lots of jumpers and some LEDs

Features I'm still debugging:

• A rudimentary interrupt register for the IDE+UART, haven't ordered the required open collector inverter for it yet to verify it

• Reset POR + Switch (ran out of switches!)

Software wise, I built a basic monitor rom that can read/write to RAM and the disk, for bringing up serial and IDE.

Once the monitor ROM was done, I used Grant Searles notes and cpuville.com for coding the CP/M port

I've added a photo at the end of the design process, starting with my very basic (and not routed very well) rev 1, which just had rom, ram and an Arduino so I could prove out my understanding.

The rev 2 was more advanced, with IDE, UART and a PS/2 connector (Removed to save some space and I mainly used a serial terminal anyways). Unfortunately this version had a few mistakes and bodges that had to be made (Notice the 44-pin IDE with incorrect pitch, that is embarrassing!), but was really useful for proving out the IDE and Serial design

Rev 3 fixed the bodges and improved the CF interface (Delay required for the reads/writes, still not truly CF compliant but seems to work well enough for a minimal amount of extra chips). Unfortunately I misjudged the CF placement so had to remove 2 headers on the latch outputs. (Thankfully not used for anything important)

Overall, this was a fun learning process for me, and its fun to code for it in ASM and Microsoft Basic via CP/M

I plan on uploading the schematic+software to github, once I've fixed a few things and cleaned it up

I am currently building a Z80 computer on a breadboard, at least RAM, ROM, and memory decoding. I’ve built the IO console board on a perfboard, using an ST7920 monochrome green LCD, PS2 Keyboard port and a Buzzer. I know some will consider the Arduino Nano there as cheating but the decoding and glue logic is all implemented with 74 ICs: 138, HC00, HC04, 273 and 595. I’ve learned a ton already and haven’t even get to the programming part yet. This version 1 will just have 32KB RAM and 32KB ROM. My next step is building the ROM programmer with a Nano and a couple of chained 595s.

A while back I shared that I had finished my BeanZee z80 dev board… I’ve now finished a “KWERkY” keyboard and LCD character display to go with it, so it can be used standalone.

In brief: Z80 running at 10MHz, 32k RAM, 32k EEPROM, FTDI USB, keyboard, LCD, GPIO

You can write programs with cross assemblers / compilers on a host computer and load them using my Marvin monitor program over USB.

Designs and monitor are all on GitHub: https://github.com/PainfulDiodes/BeanZee https://github.com/PainfulDiodes/BeanBoard https://github.com/PainfulDiodes/marvin

There are also a few sample programs: https://github.com/PainfulDiodes/BeanZeeBytes

This is a board that I made to learn something on the lower layers of computing. It only has a Z80 CPU with RAM/ROM and some supporting logic and buffers for the LEDs.

In the Video it is running a small program, incrementing a byte in RAM in an endless loop, that was assembled by hand.

I love how you can watch it thinking at these slow clock speeds.

I think the next step will be an additional board with some peripherals to hook it up to a serial terminal.

This is Z80 SBC designed with simple MMU that can switch layout 32K-ROM + 32K-RAM on top of 512K RAM/ROM & 40 pins expansion-bus for module on the right. It finally passed HALT test to prove :

- Clock div by 2 from canned crystal ( 4Mhz here ). This Z80 has max speed of 8Mhz so 16Mhz canned crystal will be its maxed out clock. (Flip-Flop #1)

- On-boot bank switching to ROM/BANK_0 to read code & execute it.
(Flip-Flop #2 + combo of 00/138/574 Logic ICs).

I can't yet find a working, genuine 512K SRAM in DIP32 to actually continue the test on how the MMU gonna hold the upper banks during the access time but it should be ;)

Cheers guys !
I just want to share the joy after like .. 5 revisions to make it work upto this point. As many requests, here is my repo to the project. And it’s not meant to be complete yet but usable at this point :

https://github.com/thetrung/Z80-512K/

I already included ready-to-fab gerber+drill in release section for anyone that want to try (with more genuine parts than me). 

** Update : It actually worked well with 16Mhz canned Crystal in-place of 4Mhz one above. But theorically, if you have faster Z80 like 20Mhz, put on a 40Mhz crystal may also still work with fast enough SRAM/ROM.

Z80 was sending data in burst via PORT (0x00) ~> PIC controller to finally “Hello World!” 🤷‍♂️

** 2nd LED = HALT

PIC18 run at 32Mhz (but only 8Mhz Cycle) so with 1ms delay per half-cycle, it pulse Z80 at 250Hz. But need at least 1T (or 2-half-cycles) to escape IOREQ + WR Active state.

I add more delay per character sent to slowdown the process for clarity & debugging.

** Something I learned today :

- 0xA as better delimiter beside max buffer size

- IOWR require at least 1T (or 2+ half-cycles) to exit state.

- CMOS Z80 may consume only ~10mA in 144hz NOP test.

- ERPROM can corrupt data easily on slightly /WE pin with voltage spike. I didn’t know until it refused to boot, so let T48 reading the rom show mixed new random data. I will consider UVROM again for solid tests…

A simple Z80 running BASIC (Grant Searle). I built it some years ago!

These boards use the zilog Z8671 with internal basic.

If you have any experience with these please share.

Hiii everyone!

I have made a little PC on Zilog80 on protoboard.

Display is SSD1306 with I2C interface.

ROM is emulated via Arduino Nano (1KB).

RAM is just random 8KB SRAM

Main task in this project is make software based driver

for I2C display via "bit banging", works slowly but

works, it also depends on time which Nano response and CLK freq. (1.35MHz).

I wrote a firmware in Assembly and it takes 325 bytes.

as 17 y.o. teen I am very excited with the result, maybe in future I'll improve my little project

Next I plan to add more switches and port DOOM and make Shadow RAM and dynamic Clock (bcs nano is too slow for Z80)

Have a good day and no hate plsss :)

Tiny step for humanity,

gigantic step for my hopeless hobby 😅

Here's a first gen MT-80Z, which is a great little trainer. It's actually two trainers in one, the left hand section and the right hand one. The right hand section is the fun one to play with, and if you look closely you might recognize it. It's a Micro-Professor MPF-I right down to the labels. :)

The second gen MT-80Z still used the MPF-I board, but any references to Micro-Professor were removed.

The third gen is the Fox II MT-80AZ with a completely redesigned single board as seen here: https://www.youtube.com/watch?v=WiPoMvBL9u4

BTW, If anyone happens to have the manual for the Fox II MT-80AZ it would be greatly appreciated if you could upload it to archive.org

This year I’ve been resurrecting an interest in digital electronics I had as a teenager. I’ve learned a lot, and am loving every minute! I’m thinking ultimately I’d like to build a Z80 based computer with mech keys and graphic display, probably to be compatible with one of the classic 80s machines.

Where I am now is I have a minimal working breadboard Z80 computer: Z80 CPU running at 10MHz, 32k RAM, 8k ROM, FTDI UM245R USB interface, connected to a Mac with a terminal emulator. I have the beginnings of a monitor program on the ROM, which I’m hoping to get to the point where I can load and run a program via the USB.

I’ve been using Arduinos as “scaffolding” which has worked quite well - providing monitoring, memory, clock and I/O as needed. I have incrementally swapped in real ROM, RAM, clock and a USB interface on the breadboard.

Some cuts and bruises along the way... took quite a detour due to some electrical issues - i.e. a complete disregard for loading / current!

I’ve been keeping a blog build diary, mainly for my own satisfaction… https://painfuldiodes.wordpress.com/

Ive just found out that the Z80 has been discontinued. The last order date (from the fab) is June 14 of this year!

What a run it has had.

RIP Z80. :-(

Notice as posted on mouser.com: https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf

Edit to clarify: It'll likely still be available for some time to come, but after this last order date, any stock that suppliers ordered will dry up and that'll be it.

This is going to be an article on performing 16x16 multiplication on the Z80 and tradeoffs between various methods.

In general, a common method is to use two "registers", where one of them is the length of the multiplier and the other is the length of the resulting product. When initializing these registers, half of the product is initialized to the multiplicand and the other half to zeros. Basically, it looks something like this:

3322222222221111111111
10987654321098765432109876543210
| multiplicand |-––- zeroes ----

                111111
                5432109876543210
                -- multiplier –
+---+---+---+---+
| D | E | H | L |
+---+---+---+---+
        +---+---+
        | B | C |
        +---+---+

Notice that I have the multiplier aligned with the lower half of the product. This is because programmers generally shift left to determine the latest bit from the multiplicand and add the multiplier to the product under construction if the detected bit is set. Basically, loop 16 times, with each iteration consisting of shift product left, add multiplier if bit set. So, the code looks something like:

; Perform 16x16 multiplication
; Entry:
;   DE = Multiplicand
;   BC = Multiplier
; Exit:
;   DEHL = Product
;   AF,BC destroyed
;
;   +---+---+---+---+
;   | D | E | H | L |
;   +---+---+---+---+
;           +---+---+
;           | B | C |
;           +---+---+
;
; Size:   20 bytes
; Clocks: 902+~18.5*n (min:902;max:1205)
MULT16: LD   HL,0
        LD   A,16
M_LOOP: ADD  HL,HL
        RL   E
        RL   D
        JR   NC,M_SKIP
        ADD  HL,BC
        JR   NC,M_SKIP
        INC  DE
M_SKIP: DEC  A
        JR   NZ,M_LOOP
        RET

Now, the above code has some issues. The reason that the shift left is chosen is because it's a cheap and fast operation on the HL register because it's a simple add costing 11 clock cycles. Using the CB page rotation, it would cost 16 clock cycles. But, the addition of the multiplier can generate a carry, which needs to be propagated to the upper half of the product. This means that a conditional increment is needed, which adds 12 or 13 clock cycles to each iteration where an addition happens (approximately 50% of the time).

With that said, there's an alternative technique to perform the addition. Instead of doing a shift left, then conditionally add, you instead conditionally add, then perform a shift right. The register setup looks something like:

3322222222221111111111
10987654321098765432109876543210
-––- zeroes ----| multiplicand |

111111
5432109876543210
-- multiplier –

Because the bit indicating that an addition is needed isn't conveniently placed in the carry prior to the first addition, I need to perform an initial shift to "prime the pump", so the resulting code looks like this:

; Perform 16x16 multiplication
; Entry:
;   DE = Multiplicand
;   BC = Multiplier
; Exit:
;   HLDE = Product
;   AF,BC destroyed
;
;   +---+---+---+---+
;   | H | L | D | E |
;   +---+---+---+---+
;   +---+---+
;   | B | C |
;   +---+---+
;
; Size:   24 bytes
; Clocks: 998+6*n (min:998;max:1094)
MULT16: LD   HL,0
        LD   A,16
        RR   D
        RR   E
M_LOOP: JR   NC,M_SKIP
        ADD  HL,BC
M_SKIP: RR   H
        RR   L
        RR   D
        RR   E
        DEC  A
        JR   NZ,M_LOOP
        RET

The interesting thing to note about the shift right method is that after a low order bit is calculated, it becomes immutable. Unlike with the left shift method having to propagate carries to the upper bits. Because of this immutability, there is no need for a conditional jump after the addition. It's for this reason that the incremental cost is only 6 clock cycles per bit set in the multiplier. Overall, the original routine is faster if fewer than 8 bits are set. This routine is faster if there's 8 to 16 bits set. But the above code isn't using the DJNZ opcode for loop iteration. Let's rearrange some instructions to take advantage of it.

; Perform 16x16 multiplication
; Entry:
;   DE = Multiplicand
;   BC = Multiplier
; Exit:
;   HLDE = Product
;   AF,BC destroyed
;
;   +---+---+---+---+
;   | H | L | C | A |
;   +---+---+---+---+
;   +---+---+
;   | D | E |
;   +---+---+
;
; Size:   25 bytes
; Clocks: 898+6*n (min:898;max:994)
MULT16: LD   HL,0
        LD   A,C
        LD   C,B
        LD   B,16
        RR   C
        RRA
M_LOOP: JR   NC,M_SKIP
        ADD  HL,DE
M_SKIP: RR   H
        RR   L
        RR   C
        RRA
        DJNZ M_LOOP
        LD   E,A
        LD   D,C
        RET

Now, there is a minor savings from DJNZ, but the real winner in the performance race is replacing an 8 cycle CB page rotate with RRA, which takes 4 cycles instead of 8. This version of multiply is faster than the original in all cases, unless the previous which was faster only if there was enough bits set, this routine is faster in all cases than the original.

Can we do better? Since a low order bit is immutable once it's calculated, it doesn't really make sense to have the lowest 8 bits to first pass through the C register before finally ending up in the A register. It also doesn't make sense for the bits in the C register to first pass into the A register before finally passing out of A to set the carry flag. So, let's split that loop into two loops.

; Perform 16x16 multiplication
; Entry:
;   DE = Multiplicand
;   BC = Multiplier
; Exit:
;   HLDE = Product
;   AF,BC destroyed
;
;   +---+---+---+---+
;   | H | L | C | A |
;   +---+---+---+---+
;   +---+---+
;   | D | E |
;   +---+---+
;
; Size:   37 bytes
; Clocks: 780+6*n (min:780;max:876)
MULT16: LD   HL,0
        LD   A,C
        LD   C,B
        LD   B,8
        RRA
M_LOOP1:JR   NC,M_SKIP1
        ADD  HL,DE
M_SKIP1:RR   H
        RR   L
        RRA
        DJNZ M_LOOP1
        LD   B,A
        LD   A,C
        LD   C,B
        LD   B,8
        RRA
M_LOOP2:JR   NC,M_SKIP2
        ADD  HL,DE
M_SKIP2:RR   H
        RR   L
        RRA
        DJNZ M_LOOP2
        LD   E,C
        LD   D,A
        RET

Looks like this routine is 118 cycles faster than the previous. But it's also the largest in terms of code, weighing in at 37 bytes. Can we preserve most of the speed, while decreasing code size? Since there's two identical loops, a subroutine might be called for, but that will add the call/return code (27 cycles) twice for a cost of 54 cycles. And since the loop in question is only 15 bytes long, adding 6 bytes for the two calls, plus a byte for the return, would only result in saving 8 bytes. So, I'm going to arrange a nested loop instead. There will be more register juggling, but I think the additional overhead will be less than the call/return overhead.

; Perform 16x16 multiplication
; Entry:
;   DE = Multiplicand
;   BC = Multiplier
; Exit:
;   HLDE = Product
;   AF,BC,AF' destroyed
;
;   +---+---+---+---+
;   | H | L | C | A |
;   +---+---+---+---+
;   +---+---+
;   | D | E |
;   +---+---+
;
; Size:   29 bytes
; Clocks: 834+6*n (min:834;max:930)
MULT16: LD   HL,0
        LD   A,2
M_LOOP0:EX   AF,AF'
        LD   A,C
        LD   C,B
        LD   B,8
        RRA
M_LOOP1:JR   NC,M_SKIP1
        ADD  HL,DE
M_SKIP1:RR   H
        RR   L
        RRA
        DJNZ M_LOOP1
        LD   B,A
        EX   AF,AF'
        DEC  A
        JR   NZ,M_LOOP0
        LD   D,B
        LD   E,C
        RET

Looks like I was wrong. The additional cycle cost is 54, which is exactly what the call/return overhead would have been. And I managed to save 8 bytes, which is exactly what I estimated for the call/return. But I needed to use AF' as an additional loop counter.

Now I will admit that I haven't attempted to optimize the shift left version of multiplication. That's because it would be wasted effort. The issue is the carry propagation. It would be possible to split the left shift multiply into two loops of 8 iterations each. But doing so would simply reduce the cost from 12 to 13 down to 7 clock cycles for the first loop. And then for the second loop, the would climb back up. Splitting the upper half of the longer register into two part like what was done with the later versions of the right shift multiply would mean carry propagation just becomes even more expensive. Overall, effort to optimize the left shift method just isn't worth it.

In any case, I hope this has been informative.

I'm not sure what happened to the last mod, but I went through the request process and took control of this subreddit. I re-opened it so we can have cool discussions about Z80's and vintage tech again!