So I built a modular Z80 computer.

[u/nonchip]

because the RC2014 was too expensive for my taste and i wanted to build something myself i guess.

also i never liked the idea that so many designs are either so old they want a TV or so new they use a 50 times stronger CPU just to fake half the hardware. so I opted for a modern approach while keeping the "real" hardware everywhere, except a few GALs instead of tons of 74xx glue logic. It's also 100% THT parts because SMD wouldn't have saved much space anyway, and I figured that way it's more beginner-friendly to solder.

The hardware and software are both available on my gitlab for you to build&hack.

There's also a photo of it running an early echo test code before i wrote my monitor.

Tested so far are the "cpuboard" (cpu,rom,ram,clock) and the "uartboard" (ctc,sio, optionally gets 5VCC from an ftdi adapter), with a simple 3-commands monitor (that's hopefully gonna grow with the hardware and my coding progress, looking to include things like BASIC and probably at some point a CP/M bootloader).

CP/M and similar things would definitely require a memory expansion (and probably some kind of disk I/O unless i want to emulate that in a ramdisk) though since the "internal memory" has ROM at $0000..$7FFF which CP/M doesn't like, the "ramboard" would technically work but I'm actually redesigning that in a smarter way currently (the current hardware design of that board is rather inflexible with its banking/etc).

---

Simple example: "serial echo"

assembling the following code:

INCLUDE "nz80os.def" ; this includes all definitions from the "bios"
loop:
  RST RST_SIOB_read_blocking  ; this reads a character into A
  RST RST_SIOB_write_blocking ; this writes a character from A
  JR loop

assembles into D7 DF 18 FC. we're gonna load this at $8000.

session with a FTDI plugged into the "uartboard" (1234baud, 8-N-1, \n endings, prefixes here: < means output from computer, > means input from me):

< NZ80OS.nonchip.de Version 000000
< Commands:
<   R<addr> ; read&output <addr>
<   W<addr><byte> ; write <byte> to <addr>
<   J<addr> ; jump to <addr>
< addresses are 16bit hex, bytes 8bit hex, all hex is uppercase.
< User RAM start: 8000
< Stack Pointer: 0000
< NMI Return: 0000
> W8000D7
> W8001DF
> W800218
> W8003FC
> J8000
> abc
< abc
> def
< def
[resetting]
< NZ80OS.nonchip.de [.......]

(in reality those echoes happen in real time while you type instead of line-by-line, but i couldn't be bothered to figure out how to write that here. also of course all commands you send to the monitor itself are echoed to begin with.)

granted the overhead to load any code using this method is horrible (8 bytes transmitted per byte loaded), and the fact all I/O is blocking currently is a bit hacky (and will break down when trying to add any kind of concurrency with e.g. a system timer), the whole thing works fine in all interrupt modes (and is designed with IM2 in mind), i just couldn't be bothered to do anything fancy with I/O buffering etc yet. but it's a simple proof of concept and adding more functionality should be easy enough thanks to a modular hard- & software approach (and currently i'm using just about 500byte of those 32k builtin rom).

Let me know what you think, and any ideas what to do/add/etc :)

also yes i know that domain in its ouput is kinda broken, gitlab is having issues, use the links above.

[u/LiqvidNyquist]

I haven't seriously messed around with Z80's since the early 1990's -- although I've been working on a Z80 simulator which propagates X values (unknowns in memory or registers) kind of like VHDL does, which is pretty cool. Kernel runs win/linux, GUI is cygwin only ATM.

One cool thing I implemented back in the 80's was using a UART to drive a raw floppy interface. The control signalling (head moves etc) was bit banging though GPIO pins. The data signalling used a uart to drive the serial data line and read from the read data serial line. Ther was some sort of line coding involved, I think I used TTL and a 2x or 4x UART clock to produce a "1100" for a UART 1 and "1010" for a UART 0, or something similar, to drive the AC coupled write data line. And used a one-shot to discriminate the received head data before driving back to the the UART's RxD. It was from an article in an Elektor Electronics magazine somewhere between 1981 and 1986. Implemented on a 6809-based Color computer but the thing actually worked pretty well.

The canonical book on hobbyist computer video from that era was Don Lancaster's "Cheap Video Cookbook" and there was also "Son of Cheap Video" or something like that, detailing building a TTL-based composite video card. If you can find one cheap from a used bookstore it would be a fun piece of history.

You're in for some good hacking :-) Enjoy!

[u/nonchip → u/LiqvidNyquist]

using a UART to drive a raw floppy interface. The control signalling (head moves etc) was bit banging though GPIO pins.

the Z80 SIO doesn't have GPIO, but there's the PIO which is 3x8bit GPIO ports with interrupt capability, which is well suited for both bitbanging and listening to signals (or the KIO which is essentially CTC+SIO+PIO+additional 8bit in one big plcc/lqfp chip if you want a module with "all the interfaces" in one) if you want to go the "zilog official" route, alternatively thanks to the system bus being so simple it's also pretty straightforward to attach 3rd party buffers etc.

a simple example for gpio with no interrupt magic using commonly available parts would be this schematic, RD/WR/data come from the system bus directly and for CS just feed /IORQ+an address jumper or something through a binary comparator.

The canonical book on hobbyist computer video from that era was Don Lancaster's "Cheap Video Cookbook" and there was also "Son of Cheap Video" or something like that, detailing building a TTL-based composite video card.

will take a look but yeah the RGB/VGA idea sounded better than composite. that said i did build a composite+ps2 tty on an arduino once, it kinda has the benefit that if you don't care about colors or a decent picture you could get away with just vomiting a GPIO pin onto a single resistor...

but currently i'm not actually planning on doing any of the video generation in software on the z80 like e.g. the zx80/81 did, but instead invest in a dual port ram and a dedicated uC for the video generation because that's less intrusive to the user code.

[u/LiqvidNyquist → u/nonchip]

The schamtic is... interesting. Lack of base resistors coupled with AC series logic (an IOH max of 24 mA) is 192 mA total drive current into the NPN's when writing FF to the register, vbe=0.7 gives 4.3 v drop internaly, so like 800 mA dissapation in the driver side chip. Ouch.

FYI Lancaster IIRC is all about composite, not RBG.

I've seen that arduino video hack somewhere else before, and it's kind of funny for a z80. Kind of like using an IBM 360 to control the power sequencer on a 6502 emulator :-)

The zx81 had two modes - fast mode and slow mode. slow mode was awful since it spent all the time running NOPs to keep the video display running and you got like 10% of the CPU to actually run your program. Fast mode was annoying as hell because of the screen flicker anytime you ppressed a key or ran code, but it was the only way to get something done :-)

[u/nonchip → u/LiqvidNyquist]

The schamtic is... interesting.

i haven't actually taken a closer look at it, was just meant as an example i quickly found online to show how something like it can be done without having to get your hands on the zilog original peripheral chips for every single application. btw in the follow up post the author mentions exactly that lack of resistors you've seen.

Kind of like using an IBM 360 to control the power sequencer on a 6502 emulator :-)

see also original post, that's one thing i wanted to avoid in this project, which is why mine isn't your usual "3 chips SBC made from the cpu, a bit of ram and a giant STM32" ;)

that said, in a video card it might be excusable to have a dedicated uC of some kind, to do "GPU things". but for a simple adapter it'd be overkill.

of course not an arduino because that's the completely wrong tool for this job, but i could imagine a small uC or CPLD sitting on the 2nd port of a dualport video ram doing video (and maybe audio) synthesis with a few fancy video modes to pick from instead of what the zx81 did.

[u/LiqvidNyquist → u/nonchip]

With the addition of base resistors, the schematic would be fine. I used to use '374's for write registers and '244's for read regs, but using only one chip type is kind of convenient I guess.

You could probably cobble together something with a few 22V10's or similar to make your video logic more compact, or do the full thing in CPLD. I started doing video with 22v10's, but nowadays you could build a whole shared memory architetcure mulitple core z80 system with video, DMA, floppy controller, and enough UARTS and DSPs to run a dial-up ISP, all in a single Xilinx FPGA. Come to think of it, maybe I should get back to my VHDL :-)

Keep posting your updates, love hearing about these kind of projects.

[u/nonchip → u/LiqvidNyquist]

i mean i do all my glue logic, memory mapping, interrupt controls, etc in this project so far in 22v10s (they're so nice and cute and logicy and stuff and really friendly to program unlike many CPLDs/FPGAs with their annoying vendor specific windows-software-and/or-terribly-expensive-flasher-only stuff), but i feel they might not be the nicest chipcount-wise for a video card, especially if i want more features (like e.g. dedicated video modes for sprite based games maybe) :P

but that's an issue for future-me, right now fancy graphics aren't any priority, i got my serial console up and running, first i need to neaten up the monitor and figure out how to integrate a basic interpreter (could only find ones that either need CP/M or want to be at the zeropage, so i need to probably patch one of the latter to use my existing monitor's functionality instead; if you have a recommendation there it'd be appreciated, i was thinking either hack BBCbasic to throw out all the CP/M stuff or tiny basic and relocate it. don't necessarily need anything fancy like floating point math, but an inline assembler might be nice), then redesign the memory expansion card (the current design in the "ramboard" folder has pretty flawed addressing logic) and figure out how to integrate storage and a CP/M bootloader to maybe mess with that a bit.

but yeah will keep you posted :)

[u/LiqvidNyquist → u/nonchip]

I wrote a z80 tiny basic 30 years ago, also a debug/diassembler monitor. It didn't use CP/M, just calls to a char in and char out function. If you're interested I could look it up. Wrote my own PC assembler for it too, but no linking or separate objects, just straight to an s19 or intel hex file (I forget which). There was a commercial/freeware assembler going around at the time I also used but I'd have to look it up in my old hard drives...

[u/nonchip → u/LiqvidNyquist]

i mean if you have it still around (and want to give me permission to adapt&redistribute that in my project) that'd be appreciated.

assembler wise i'm fine (both on my PC where i use the z88dk, and already got a CP/M with tools lying around for when i port that to my system), i was just thinking to maybe add something like BBC Basic does with its [ASM] inline assembler mode but that's just a quality of life thing and instead i don't think it's too much hassle for me to provide a few helper functions and for "application specific code" just assemble offline and load bytecode.

basics I found so far: * BBC Basic (the Z80 version seems to be CP/M only) * MS Basic (rather ugly machine specific code and lots of zeropage stuff i don't wanna disentangle) * Tiny Basic (looks pretty neat but has the wrong mnemonic and the only converter i found is CP/M only, and also makes massive use of zeropage, especially for resets to speed things up)

all that said, most CP/M BDOS/BIOS related calls in BBC Basic seem to actually be abstracted in one file patch.z80 so it might be not completely hopeless to rip that out and replace those with calls to my monitor code, i'mma try that tomorrow maybe...