Retro CPU tinker boards/kits? - Page 1
Forum section: electronics / projects

author: paulca
author_rank: Super Contributor
timestamp: May 19, 2025, 10:46:37 am
content: I want a retro-CPU 'pet'. Basic bare bones CPU with minimal IO, aka, no display, just tty/uart/i2c IO.... maybe a Wifi "ROM sim" ala ESP32 later on (ie, you can flash it's ROM over the air).I have considered breadboarding it baremetal, datasheets only. However, strawmaning the effort and cost steered me more towards something that has already passed the "Breadboard" phase and maybe comes as a basic modular kit? Even if it's just OSH gerber packs.So I don't mind a dozen little PCBs with ribbons everywhere stuck to a 30cm square wooden board.At the same time I don't want to buy a modern Amiga or Spectrum clone fully built with an arduino in it, which believe exists.Something in the middle. Like a PCB with the main CPU, a PCB with RAM, a PCB with (EP)ROM, a PCB with the peripheral IC and basic IO interfaces. etc. etc. PSU, Clock... the list goes on.The CPUs I had in mind were the Z80 and 68000. Two CPUs which I have done an ASM tutorial in at some point when I was a kid.Can anyone make any recommendations while I go trawling myself?

author: brucehoult
author_rank: Super Contributor
timestamp: May 19, 2025, 10:51:33 am
content: https://www.olimex.com/Products/Retro-Computers/?Many of their products are stocked at Mouser and/or Digikey.

author: neillnz
author_rank: Contributor
timestamp: May 19, 2025, 11:34:58 am
content: There is this thing:https://zeal8bit.com/

author: paulca
author_rank: Super Contributor
timestamp: May 19, 2025, 11:37:30 am
content: Thanks.ChatGPT did googling for me and figures this is what I'm after:https://www.mega-micros.co.uk/The downside is... its "Email the guy for quote" ordering affair.

author: paulca
author_rank: Super Contributor
timestamp: May 19, 2025, 11:43:59 am
content: Quote from: neillnz on May 19, 2025, 11:34:58 amYea, what I am finding a lot of are SBCs. SBCs which are basically modern day SBCs that someone built around a Z80 or 68000. They are tiny, probably using 6 layer boards and come with every single bell and whistle crammed into it on mostly surface mount micro-circuitry.While cool. I'd buy it, get about 2 hours of fun from it and it will collect dust. I can probably get more fun out of the UAE emulator with all the settings janked that those SBCs.I kinda want something more basic. More spread out. Modular. Maybe get a few dozens of hours fun before it goes to the project bucket.Basically just one step up from a "Ben Eater breadboard" version.

author: johnboxall
author_rank: Unknown
timestamp: May 19, 2025, 12:00:21 pm
content: https://www.tindie.com/products/tec1/tec-1g-z80-single-board-computer-kit/

author: DLJ
author_rank: Contributor
timestamp: May 19, 2025, 12:15:08 pm
content: How about an arm 7?I am fond of the "Atmel AT91EB40 Evaluation Board". This board was the featured board used in the book "Embedded System Designon a Shoestring" by Lewin A.R.W. Edwards (PDFs are are available)Atmel ( Now part of microchip) also provide a user guide.So plenty of documentation and examples, and fairly retro.I have one available if you are interested. ( postage cost only)RegardsDavid

author: themadhippy
author_rank: Super Contributor
timestamp: May 19, 2025, 01:19:34 pm
content: Quotewouldnt that be a 6502, whilst breadboard thereshttps://eater.net/6502

author: Doctorandus_P
author_rank: Super Contributor
timestamp: May 19, 2025, 03:19:49 pm
content: There are quite a lot of such projects on the internet, both for Z80 and 68000 and others probably too. And the state of those projects vary from youtube video's with little extra info, to complete PCB projects (several in KiCad), and to complete kits. Some of the Kits also have (KiCad) schematics and PCB design files available, both easier for you, and by buying the kit you give a thumbs up to the original creator.Just one example is:https://hackaday.io/project/164305-roscom68k/But it's not my thing, I rather buy a EUR 3 microcontroller with 10x the speed of these old things.A very long time ago I nearly bought a stack of network interfaces for (even then) old HP printers. It was a PCB of about 120 by 120mm, with an 68000, ROM, RAM, Ethernet and I/O to plug directly into a laser printer.

author: MarkL
author_rank: Unknown
timestamp: May 19, 2025, 03:20:07 pm
content: Here's a modular Z80 system with a mini-backplane, reminiscent of the old S100 systems, and lots of interface (card) choices:https://rc2014.co.uk/You can buy the kits here:https://z80kits.com/Another interesting add-on: If you have an old HP/Agilent logic analyzer, someone developed a probe card for this bus, which can be used for program tracing/debugging:https://github.com/MustBeArt/LAIRI haven't pulled the trigger to get one of these RC2014 systems, but it's on my list when I have some time.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: May 19, 2025, 03:44:28 pm
content: Also noteworthy: The original BBC Micro, with only some small modifications done by MikesElectricStuff...

author: pqass
author_rank: Super Contributor
timestamp: May 19, 2025, 06:12:28 pm
content: After building a breadboard 8085+UART+PPI the enthusiasm wore off quickly after writting a few hundred lines of assembly.I wanted to stretch out with a bigger machine but still be breadboard friendly and found the 68008 (fits on 2 strips, 11 DIP packages: OSC,555*2,68008,'138,'00,'32,'20,62256,29F010,16550).It's very easy to program in C with the occasional assembly (tools used: binutils-m68k-linux-gnu.x86_64 and gcc-m68k-linux-gnu.x86_64).I've adapted the monitor from theGloworm OSproject (see undersrc/monitor/).I also foundBare Metal m68kvery useful as I come from an application programmer background (I didn't know what happened before main() was called).TheComputie68kproject (in several revisions from 68000 to 68030 with 2MB SRAM, 512KB Flash, 68681 DUART) is documented in Kicad with board layouts.Also, check out theGloworm OS. It's a basic UNIX-like OS recreation.

author: pcprogrammer
author_rank: Super Contributor
timestamp: May 19, 2025, 06:13:00 pm
content: How about the MiSTer FPGA.https://en.wikipedia.org/wiki/MiSTerIt is an open source FPGA project that allows one to setup almost any old retro system with the CPU configured in the FPGA. No emulation, but a cycle accurate copy of the original chip for a lot of them.It can be setup as a game console or a microcomputer, so good for many hours of play time. Both the Z80 and the 68000 are available in the form of for instance the TRS-80 or the Atari ST.Expansion boards and other stuff can be bought here:https://misterfpga.co.uk/or herehttps://misteraddons.com/or herehttps://ultimatemister.com/Not cheap, but very flexible.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 19, 2025, 06:26:35 pm
content: Tindie has a number of these kits, you also have modular Z180-based kits, such as this one:https://www.tindie.com/products/tindiescx/sc792-z180-romwbw-cpm-computer-kit-for-rcbus-80/Pretty cool if you were familiar with the Z80 but want to take advantage of this retro phase to try something different. The Z180 was relatively uncommon, and while mostly compatible with the Z80, adds many nice features we wish we had back when we were using Z80 computers!

author: brucehoult
author_rank: Super Contributor
timestamp: May 19, 2025, 10:13:59 pm
content: Quote from: Doctorandus_P on May 19, 2025, 03:19:49 pmThese days a 10c microcontroller is 20x or 50x faster than "those old things" when operating on bytes, and more for 32 bit values, and can easily emulate them at full original speed. RAM size is limited at those levels though, unless ZX81 is your thing. You have to go up to ~50c to get 64k RAM e.g. CH32V307. Hmm wait that's in qty 1000 ... seems you have to pay around $1.50 each in qty 10. Yeah, ESP32 is an option at that level too. Or RP2040/RP2350.

author: Benta
author_rank: Super Contributor
timestamp: May 19, 2025, 11:19:51 pm
content: Quote from: paulca on May 19, 2025, 11:37:30 amIf that's how you want to go, there's a another standard way: VME 3U modular boards.Based on 160 mm x 100 mm Eurocards with DIN 41612 connectors, the backplane basically carries the 68000 bus signals.It's documented in IEEE-1014 and has inherent interoperability if you find some exotic interface on a flea-market :-)But it's very much 68K-focused.https://www.vita.com/VMEbus-FAQ

author: alpher
author_rank: Frequent Contributor
timestamp: May 20, 2025, 01:17:02 am
content: https://github.com/skiselev/minimax8085I realy enjoyed building Sergey's 8085 board, cheap and easy to build, and these days you cannot go more "retro" on a cheap than intel 8085.

author: paulca
author_rank: Super Contributor
timestamp: May 20, 2025, 10:15:38 am
content: All good points/options. I did a bit of digging and figured I have too many requirements for a single project.I want bare metal. To start with just the IC and build from there. I'm talking "Blinky" and onwards.I would say that 90% of the available kits come pretty much complete. Sure some are self-assembly, some are a back plane, but basically you are going to spend a few evenings soldering it together and then pretty immediately it will be downloading the dev pack, test firmware/ROMs etc.That skips a MASSIVE amount of fun. It's like Arduino as opposed to AtMel/MChip assembler. It also dilutes the "bare metal" aspect by immediately giving me functional boot loaders, consoles, etc. etc.I want a system that I can start with +5V and GND and watch it do nothing. Then, put an LED on an address line and a debounced button on the clock and make it blink... or fail to.... take it up from there.So... taking advice to NOT breadboard a 68000 (as it's a special 24 address lines and 16 wonky, intermittent breandboard, data lines kind of tedious)I bought a genuine (I hope) second hand, tested, Zilog Z80A original. It can be my "Blinky". It can be my switches, buttons and LEDs project. Then I can do the other fun part with it. Take a modern MCU and emulate the expensive parts like RAM and ROM.I'm not going to go looking for a circuit example, except in the datasheet. I want to see how far I can get before I need to start googling solutions and when I google it will be "How do I solve this specific issue", not "Give me a working computer ChatGPT".That part taken care of the 68000 can go straight to PCB. I will need to pick and choose between the modular options. The Mega-Micros thing is a bit jank, you have to like email him and ask and arrange PayPal payment. No gerbers.The style however fits. I can take the CPU PCB board, put the 68000 in it's place and then start adding components while tagging everything else with probes or harnesses. When I'm done torturing the CPU into life bit by bit I can move onto the other boards.Depending on the cost of the boards and how many there are I could get 2 or 3 of each and butcher them.However, having the ability to carry on and add, say, a "modern interface" board with USB and maybe even networking later it would be nice to follow an "eco-system" where some of the harder work is already done... just not forced on you from the start. Baby steps have to be available, even if the "system" takes me to the moon ultimately.On the "Just use an MCU". Already done that. I've bare boned, bare metalled, Arduinos, ESPs, STMs. Usually they don't take much more than power and peripherals. Maybe a cap or two. "This" project is about what happens inside the MCU. You could say I'm just building my own macro-controller-unit.

author: brucehoult
author_rank: Super Contributor
timestamp: May 20, 2025, 10:54:43 am
content: Quote from: paulca on May 20, 2025, 10:15:38 amYou can't single-step one of those like you can a 65C02. The NMOS Z80 and 6502 need to have the clock running at a certain minimum speed (10s of KHz?) all the time to not lose register contents. The 6502 has a RDY signal which can be held low to stop the 6502 fetching instructions and pulsed hi for 1 cycle to allow the CPU to execute one instruction, which does allow tracing program flow but doesn't allow monitoring every instruction and load/store byte like stopping the clock on the 65C02 does. I don't know if the Z80 has a similar signal.

author: pcprogrammer
author_rank: Super Contributor
timestamp: May 20, 2025, 10:59:21 am
content: Quote from: paulca on May 20, 2025, 10:15:38 amI would say, get yourself a FPGA board and play with that. You can even write your own CPU from scratch. A board like the Tang Primer 20K offers immense possibilities.https://wiki.sipeed.com/hardware/en/tang/tang-primer-20k/primer-20k.htmlYou can get it from Aliexpress:https://www.aliexpress.com/item/1005004653308809.htmlIt uses the same FPGA core as the Tang Nano 20K but provides a lot more IO pins to play with. The core board with the extended dock board is more expensive than the Tang Nano 20K, but I wish I had spend the extra 25 Euros.

author: pcprogrammer
author_rank: Super Contributor
timestamp: May 20, 2025, 11:01:55 am
content: Quote from: brucehoult on May 20, 2025, 10:54:43 amYou sort of can if you use the "wait" pin.https://z80project.wordpress.com/2014/02/16/single-step-instruction-circuit/

author: brucehoult
author_rank: Super Contributor
timestamp: May 20, 2025, 11:08:02 am
content: Quote from: pcprogrammer on May 20, 2025, 11:01:55 amSo, similar to the 6502 RDY which I wrote about as an edit to my previous comment while you were writing yours.Neither one will allow you to observe each instruction and data byte read/write like Ben Eater shows with 65C02, just stop before the next instruction execution.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: May 20, 2025, 11:48:42 am
content: Quote from: brucehoult on May 20, 2025, 10:54:43 amOne way of single stepping, is to not modify the clock at all, but (ab-) use an ISR. The goal is to retrigger the ISR before it exits. In that case many CPU's execute exactly one instruction before going into the ISR again, except if another ISR is pending also. Further details vary on architecture of course.And I really don't care whether a uC costs 50ct or EUR5. Lets see:EUR 500 for my agilent scope.EUR 600 for my PC, Ryzen 5600G, bought during the corona crisis.EUR 1000 for my monitor (nice big one!)EUR 1000 or so for all the other lab equipment. (Power supply, soldering iron, function generator, etc)And then, whatever uC I choose, it's going to take me 100 or more hours to get familiar with it. The cost of the uC is completely irrelevant to that. I do like to keep initial costs somewhere between EUR5 and EUR10. I bought over 10 Black pills (also during corona when they were more expensive. I think each was EUR 7.5, but I've got plenty of spares for when I let the smoke out of a few.Cost optimization only becomes an issue when you're going into production, but below quanity 100 it's still negligible. I pitty all the fools struggling with not enough I/O pins on an attiny84. It wastes so many hours during development if you don't have a bunch of spare pins (and a uart / SPI, etc) for debugging, or have to multiplex your application with the programming wires. But when you're still doing old school retro computers, you're not afraid of a few extra pins anyway

author: brucehoult
author_rank: Super Contributor
timestamp: May 20, 2025, 12:39:00 pm
content: Quote from: Doctorandus_P on May 20, 2025, 11:48:42 amUsing a retro microprocessor or 10c microcontroller is not a decision made for rational economic reasons in the first place so none of that is relevant.It's for the fun and/or challenge of getting the most out of limited resources.Even at the $5 level now I'm using a board with a 1 GHz 64 bit CPU with length-agnostic vector processing (with 32x 128 bit registers that you can gang as 8x 1024bit registers) running full Linux in 64 MB RAM (enough for Ubuntu server), and with a 2nd 64 bit 700 MHz "microcontroller" for the real-time stuff. And an 8051 if you really want (it's there to handle the GPIOs). Bump that to $9.90 and it's got 512MB RAM and an Arm A53 core as well.

author: robert.rozee
author_rank: Frequent Contributor
timestamp: May 20, 2025, 02:26:11 pm
content: don't think anyone has mentioned this one yet:https://github.com/SuperFabius/Z80-MBC2https://hackaday.io/project/159973-z80-mbc2-4ics-homemade-z80-computerhttps://j4f.info/z80-mbc2it is called the Z80-MBC2, and is a 4-chip implementation that can run CP/M. the four chips are:- CMOS Z80 processor- 64k or 128k SRAM chip- atmega32A as boot ROM emulator, I/O controller, etc- 74HC00 as glue logicthere is some discussion here:https://www.thebackshed.com/forum/ViewTopic.php?TID=10957as well as numerous other places online.cheers,rob :-)

author: pqass
author_rank: Super Contributor
timestamp: May 20, 2025, 03:03:04 pm
content: QuoteI started with a can oscillator, 68008 with data lines pulled-down, LEDs on the upper 4 address lines, let itfree-runto confirm the CPU was okay.QuoteThe 68008 is 32 bits in software but with an 8 bit data bus and 20 bit address bus; breadboard friendly unlike the Texas cockroach older brother.QuoteAfter free-running and no RAM yet, I made a ROM emulator: 3 ICs+Arduino solution to wait the CPU on RD via FF and also trigger an '328 interrupt, respond with a byte to the data bus, then release the FF. The '328 can't respond fast enough @2.5MHz 68K8 clock speed without the FF-wait helper. The '328 code feeds the 68K8 opcodes+data (hardcoded first but later as Intel Hex file lines) like a very slow ROM.I used the same ROM emulator to boot a previous breadboard 8085 build.Then added RAM and an output latch to the system to get simple LED display going.Then added a 16550 UART (polled at first but later buffer+IRQ working).Played with several monitors and adapted one until the machine programmed its own flash ROM.I started from ZERO knowledge of the 68K. With the help of the Alan Clements book and several 68K projects on the interwebs, I'm still having a ton of fun shaping this machine. I plan to bootGloworm OSas soon as I can get more SRAM and IDE/CF interface.

author: paulca
author_rank: Super Contributor
timestamp: May 21, 2025, 10:01:29 am
content: Quote from: brucehoult on May 20, 2025, 12:39:00 pmIt's also stepping back to when things were simpler.Z80 I spend a few hours here and there when I was in my early teens, but back then even getting "computer time" to do things meant accessing the family spectrum. If you were really lucky (and this happened only once), there was a cover cassette on a magazine that had a mickey mouse assembler tutorial with a "Public domain" style assembler that gets you to print "Hello" and jank the colours a bit.68000 I owned an Amiga and again magazine cover disks occasionally provided tutorials cobbled together with "free" assemblers and either "hacked" or "donated" vector includes to system libs. They worked for just about nothing except the tutorial. The issue here is that to write anything for the Amiga you needed the AmigaOS includes (or hacks). In like 1993 the Commodore official SDK pack, manuals, disks etc, all "non-redistributable" was £125. That was a LOT of money for a late teens geek.By the time the internet came along, we were all on PC. It was one of the first things I did was explore the masses of free flowing information, public APIs, public docs there were so many options.However, when I actually tried to "get into" x86 assembler I discovered that by that stage (Pentium2/Celerons and Athlons), assembler was as impractical as it ever had been, to the point of being nearly completely useless outside of some "inline embedded ASM in C" affairs.ASM gets used much like in MCU land to boot the CPU up, then it call some C library and off you go into "General Purpose OS" land. ASM from that point on is a nightmare trying to boostrap and communicate with modern libs, kernel traps and "Cross platform" macros from hell. It is NOT accessible at all. If you complain about it being so, the answer is quite rightly, "Dont use ASM, use C and if it's not even a system program, use a higher level lang still. This is 2002, not 1992.So, I feel going back to the actual hardware where things were limited, but have a kinda beauty in their simplicity. If you can only bring 3 tools, you spend a lot of time picking and sharpening those tools. If you have 1000 tools, you can get sloppy. I feel older simpler stuff is far more full of interesting moments where you wonder why on earth they did something a certain way, then realise why and nod feeling like you learnt something cool.How better to take that journey than "dropping an IC" on the desk and saying "Do something with it." Probably very much like Sinclair and others did at some point. An IC and a datasheet.... go.Scope is important here. Which is why I am going to set the scope to:Create a macro-controller. Aka, something that could be called a Microcontroller but fits in a biscuit tin form factor rather than a finger nail.I don't really want to make a fully fledged computer and I don't (this time) want to even consider display.... although an RGB LED matrix doing something cool would probably count as a proving project for which I can side by side the fingernail STM8 matching or beating the Z80.The 68000 I have different ideas for, but I think one at a time is prudent so I will start with the Z80 MacroUnit.

author: brucehoult
author_rank: Super Contributor
timestamp: May 21, 2025, 11:32:39 am
content: Quote from: paulca on May 21, 2025, 10:01:29 amI learned programming on calculators. In my 6th form year (1979) I bought a TI-57 calculator for NZ$117 ($80 in the US). It had 8 memories and 50 program steps, including conditional flow control and subroutines. I would have loved a Casio FX502P, which was much more powerful but also much more expensive.In my 7th form year (1980) classmates had a TI-55 (8 memories that could be repartitioned into 8 program steps per memory, but there was no conditional flow control) and a TI-58C (up to 60 memories or 480 program steps, again partitionible at 1:8 ratio). We also had occasional access to an HP97 at another school. And there was a sewing machine shop that for some reason had a Commodore Pet you could play on.In class we write FORTRAN programs on hand-punched cards, which the teacher took into a local bureau at night and ran on a B1700/1800/1900 (I don't remember which now). Sometimes I went in with him.Right at the end of the year the school got its first Apple ][. The maths teacher said "Bruce, take it home for the summer holidays, figure it out, and come back and teach me". I was technically an ex-student by then (going to university after the summer) but cool.I spent maybe two days with BASIC before saying "screw this shit" and teaching myself 6502 machine code programming from reading the monitor ROM listing in the back of the manual.Assemblers? Where we're going we don't need assemblers.Well, ok, I did write my own simple assembler in BASIC. Saved calculating label addresses and branch offsets by hand (which changed every time you changed the program...).At university there were PDP-11s and from sometime in my 2nd year a VAX. In 1st year one friend had a ZX81 which I did a little Z80 machine code programming on (POKEing instruction bytes into RAM).QuoteBy 1986 there were excellent programming resources for the Mac Plus, including THINK Pascal and the Unix-like MPW (Macintosh Programmer's Workshop) which had assembler and Pascal and C compilers as well as shell scripting. They cost money but they weren't copy protected and people took pity on students and gave them copies.It's really hard to imagine having a 68000 machine in 1993 without programming resources!QuoteAll? The first machine I've ever owned running DOS or Windows was my i9 laptop I bought in February 2024. I tried to use WSL, I really did, but after a few months deleted Windows and installed Ubuntu natively.I did build some x86 machines for Linux starting in the late 90s, but I bought the components myself and never included Windows.I've never used MS-DOS. I did use CP/M on a Z80 at some point in 1984, with Turbo Pascal 1.0. Well, and after that the Amstrad Z80 CP/M home computers (1984-1990) were pretty good machines for "serious" uses. I liked them much more than the C64 or Spectrum.

author: Zenith
author_rank: Frequent Contributor
timestamp: May 21, 2025, 11:36:22 am
content: You might check out Jeff Tranter's blog.https://jefftranter.blogspot.com/No search facility I could see, which is a pain.He's done quite a lot on 68000 and Z80 SBCs. The boards for the Z80 version are available on ebay for a fiver or so. Great if you have a Z80 and the support chips hanging around, otherwise you'd have to buy them.I'm sure there are loads of other Z80 SBCs around.There must be Z80 IDEs and emulators which would save a lot of time. EEPROMs would save messing about with UV erasers.I can see the fascination, but it's not something I'm tempted to get into.

author: macboy
author_rank: Super Contributor
timestamp: May 21, 2025, 02:55:43 pm
content: Quote from: Zenith on May 21, 2025, 11:36:22 amIn that case I use google with thesite:keyword. For example, to find his 68008 SBC project, type this into google:site:jefftranter.blogspot.com 68008

author: paulca
author_rank: Super Contributor
timestamp: May 23, 2025, 11:13:16 am
content: The CPU hasn't arrived yet, so I started having fun with an emulator.Oh boy. Memories. I started BenEater style with some basic "print_str" routines calling the underlying ZXSpectrum ROM routines. Then I decided to print the numbers 0-255.Of course you have to do the binary to decimal to ASCII code yourself.DIV 100Nope. Z80 does not have a DIV. Curve ball. Iterative subtraction is it then. I did get it all working after a few hours of fun.Only then did the penny drop. I'm an idiot and I wasted at least an hour on "decimal". It would have been easier to convert it to hexadecimal, thus skipping the need for division and allowing bitwise operations instead. I might not even need 2 registers to do that.On the hardware side. I'm still procrastinating on what support chips I need and/or want. Most people are targetting a "Personal computer" and most of those want to ultimately target ROMs like the ZXSpectrum or similar era computer. I have no desire to remake a spectrum. So I don't need half of the normal paraphernalia associated with parallel ports and display buffers. I have to see how many legs just having the Zilog SCC serial controller works for me.ROM and RAM I find myself having to remind myself that it's entirely up to me. I own the memory map. I own the ROM and the library vectors. I own the stack. The only caveat is if I ever want to run third party software on it, like CP/M they will probably have stipulations which may cause issues if I depart from the realms of "normal" too far.Give it's not 1976, RAM is pretty easy. Compatible 256kbit and 512kbit SRAM chips make that part quite easy, very easy if you don't want banked memory.ROM. Here I will depart from the "era" and use an MCU. I want modern rapid cycle flashing, not pulling EPROMs etc. Still haven't quite decided on which MCU. There are many easy options regards GPIO quantities and speed needed, there are also options with nice comms, such as WIFI from the likes of the ESP32. The trouble is finding the overlap on the Venn diagram. The ESP32 modules top out at 36GPIOs and I doubt all are available that easily together. I need 16 address lines, 8 datalines and 4 control lines. Given the model of MCU like and having modern flash for ROM will I think trend me untraditionally towards having much more ROM than RAM. If my code will be "flashed" to the system, then it may as well all be flashed into ROM and completely dispense with boot loaders and extra things like I/O loading from 'tape' or 'disc'. Then again, that might be fun.There are other options for memory architecture. For example, the MCU can write to it's own flash RAM. It can also buffer quite a bit in static RAM. So, in theory I could give the CPU what it sees as 100% RAM. Its just that when it boots from its point of view that "RAM" is already full of code. So I might have 32K 'RAM' from the MCU flash and 32K of real RAM from a static RAM chip. That architecture however slams the door on a rather more clever architecture like Harvard. Where the program memory is in the lower 32K and the user RAM in the upper 32K. I believe with the Z80 and some logic gates I could implement the Harvard structure. Not sure about overlaying the two into being the same address space like a proper harvard, maybe by generating the MSB address line based on the CPU "M state lines", If it is accessing for "instructions" clear that bit and the address will only ever resolve into the lower 32K. If the M lines tell its a data read it can be set and resolve to the high range. Needs more research and if I want to bother.I do not want to run into a situation where that MCU starts doing too much though. That ends up with a Z80 test harness basically. So I don't think I will add it as an IO controller device on the bus. I can limit it to memory lines only and if I want to do any SMART swaps I can do that on the MCU and keep it opaque to the CPU.

author: kmm
author_rank: Regular Contributor
timestamp: May 23, 2025, 05:25:09 pm
content: I did a from scratch Z80 during the '20 cough of unknown origin lockdown from stuff I had on hand, might at least be a tidbit or two in my project notes that's useful or interesting.https://github.com/kmm/COOF-80Got it working, wrote a little ROM monitor from scratch (mostly in an emu), made an attempt at interfacing an old ISA MDA card with partial success, and then moved on. Pretty sure that Z80 was bought from BG Micro (RIP) back in the mid 90s when I was a teenager, it was fun to finally make it come alive.Using GALs for decoding and glue logic made it a lot more fun to experiment and prototype with, and possible to fit the minimal system on the ~4x6in protoboards I had around. Really like the tinyscale PLDs, too bad they're not really a mainstream part any more and the toolchain for working with them (WinCUPL) is about as ancient as it gets without it being a DOS program.Point to point on perfboard construction while quite tedious is totally viable for a minimal 80s 8-bit system, but if I were to do another scratch build 8 bit I'd use the PCBs that are laid out in the same way as a breadboard rather than a perfboard. Not having to tack 4x 30ga wires to one pad really helps with wiring and troubleshooting. I don't have anything published on it but I did a similarly minimal 68K on the "PCB breadboards" a couple years later and it worked out well, although I never got around to doing much more with it than running the standard Knight Rider blinkenlights test routine.

author: paulca
author_rank: Super Contributor
timestamp: May 24, 2025, 10:32:50 am
content: You lost me at GAL and PLDs.If I assume correctly in these are some form of "dynamic logic arrays". I can see how they appeal. Rather than fiddle with a set of 4 or 5 74 series gates ala period. Just drop a big ole dynamic array and give it all the lines. "Sort it out in post". EDIT: You know if you take this one step further, you can implement a full protected mode and run Unix on it. No... I aint going that far. Maybe with a 68000 project later on.It's not a project I expect I will launch into and complete in one swoop. If I was going to do that, I would just go "off the shelf Z80 SBC" and get it done.So the physical aspects are going to have to be iterative. This is where the challenge lies. The first "expensive counter" circuit, or a few other OPCODEs which produce testable results without and additional hardware (asides the clock).... these are obviously breadboard candidates.Other breadboard candidates are "Partial" memory line gate circuits.Once I get to that stage, going to full address lines and datalines ... I think it will be there that KiCAD comes out and the "two week round trip" prototyping begins at £30 a pop.Maybe not kiCAD immediately though. There are some legs on protoboards. "Some" as soldering a dozen connections on the back of a proto board I am likely to burn myself at least twice. Soldering 48 connections, I might need gloves. EDIT: This is because it was "Great Scott" on YouTube who taught me to solder protoboard. He insists on individual, non-insulated fuse wire. All neatly sized and bent into shape. Lovely work. I might be better off using insulated mod wire. I am fine with birds nests ala 1960s.Small focused boards. A CPU board. A memory board. Big ribbon cable. Move on. When I have a bunch of ribbons make a core board.... a back plane.

author: paulca
author_rank: Super Contributor
timestamp: May 24, 2025, 10:51:15 am
content: The Z80 is here and the first brand of cheap breadboards that will let me down.The fun begins. I can't find a 555. What I do have though is a 60Mhz signal gen and a 100Mhz scope. Can I make it blinky? (rhetorical)I am resisting the urge to spend an entire evening on RSCompents buying things I "might" need. I am going to wait until I DO need.

author: pcprogrammer
author_rank: Super Contributor
timestamp: May 24, 2025, 11:12:47 am
content: Quote from: paulca on May 24, 2025, 10:32:50 amGeneric Array Logic or Gate Array Logic and Programmable Logic Device are not so much dynamic in nature. Most are one time programmable and can vary from just simple gates and inverters to having flip flops to register signals.More advanced are FPGA's (Field Programmable Gate Array) which to some extend can be dynamic, where partial re configuration can be done to change the circuit on the fly, but are mostly used to configure them at startup and do a lot of things at the same time, replacing really many of 74 type IC's.Possibly for the same as what you paid for your Z80, you could get a reasonable sized FPGA that can make a complete Z80 based computer in one chip. With writing the FPGA configuration in verilog and simulating on a PC and afterwards in the FPGA, you could even have a lot more fun.As a first test it can become a drop in replacement for the Z80 if desired.Not fully retro, but definitely more possibilities in the long run. Just something to think about.

author: paulca
author_rank: Super Contributor
timestamp: May 27, 2025, 10:17:23 am
content: So the CPU works.All data pulled low = NOP opcode.clock - from a signal gen, it might as well get some use.Addr 0-4 with LEDs+10K resistor eachMost active low control lines pulled high.It did nothing. Until I RESET it. Then it start counting on the 4 LEDs.I did a bit of digging into FPGAs, watched the DigiKey Ice40 tutorial series and bought an Ice40 eval stick from DigitKey before I checked Ebay. So I paid £111 for a PGA dev board and then promptly bought another one on AliExpress for £35. I can see the appeal, but there is a lot to learn. The Ice40 would be a perfect candidate to "soft" the glue logic gates. The trouble the FPGA dev boards I bought only have an 8 pin IO header. That might get me 4 logic gates. So I might be on AliExpress again looking for one with a proper amount of IO broken out.Breadboarding was already old before I started. That is why I didn't put all 16 address lines. Instead I bought a collection of 8 LED modules for such purposes for 40p each. Of course that was before I realised that going forward, I can't have LEDs on buses, not without a tri-state buffer. If I put LEDs on a bus then it will load the bus and cause issues.So, for bus monitoring, I am going to go with something simple like Ben Eater. An MCU with enough pins and just enough grunt to log the address and datalines, maybe a few control lines. As they are cheap and will work, I just with an Arduino Mega clone. Its quick, dirty and works. Its pins are high Z when input, so should not drag the bus down or drive it.Memory architecture:1Mbit parallel flash 'ROM' 0-32K256kbit SRAM 'RAM' 32K-64KInitially the two extra address bits from the ROM can be tied low. They are not used for programming and the CPU will not use them for data. Later however, those 2 lines can be jumpered to give me 4 ROMs. Later still those can be connected to latches on the IO controller and switched from the CPU from code. I bought 4 of the SRAM chips for similar reasons, they can be page banked later to give more up to 128kbyte of RAM.When the breadboard practical worked, I moved to KiCad and dropped out the schematic for the next step. Adding the ROM at least, but I added the RAM too on the schematic.Schematics for a mostly IC circuit are pretty boring and quite a bit tedious until you get the hang of copy and paste for bus splits/joins etc.The PCB layout. Oh boy. I am so rusty. It took me 4 failed birds nests for a few of the old tricks to click in. The pattern recognition of crossing nets and being able to see "groups" which can neatly just route around each other rather than crossing in random places.However, still... whoever laid out the pins on these chips either had a very good reason for doing it how they did, or they were trolling. You get like 9 address lines in a neat row on one side of the chip and then it looks like they ran out of room and just shoe horned the rest in randomly across the rest of the chip. No matter how you go about it you end up with 75% of it can be neat and tidy, but will be completely ruined by the other 25% of birds nest. So, I decided to ..."when i rome" and went fully column and row on it's ass. The top layer shall not go up and and down. The lower layer shall not go across.When it comes to routing 2 ICs sitting side by side with "trolling layout crossing pins" that you can't avoid... Left/Right, VIA, Up/Down, VIA, Left/Right etc. Actually seems to work. It will be a bugger to clean up and make it look neat as in KiCad Vias have a habit or not pulling their tracks with them when dragged.. and it doesn't do bump and nudge routing that I am aware. Still, when you get into it, it's quite a pleasant little puzzle solving session.Glue logic:I boxed off a whole corner of the schematic for the glue logic. What I have on there right now is wrong, I mean it might work, for now, but it's making a few too many assumptions with timing and only routing the essentials and leaving zero room for expansion later. They likely also won't work with other bus sharing devices very well. I might still fit in the corner for this version when it's fixed, but I expect it will need a schematic sheet of it's own, if I don't indeed stuff it all into an FPGA or MCU.At the moment all it really does is "not" A15 and sent it to the RAM ChipEnable, the non-inverted A15 is goes to the ROM ChipEnable. Then route the RD to the RAM and ROM Output Enable <--- this is making a lot of assumptions which need checked. As I understand it, "CE" is over-ruling. It won't matter if RD enables "output" on both chips if one of the RAM/ROM chip is in "Standby" with a high CE. It might work, but I expect it will hamper things later when I come to share the buses with IO controllers and the likes.So, I'm not posting the schematic, I don't want the deserved scathing review and I don't want you guys to fix my problems and solve my puzzlesInterconnects and back-plane-ing:As the schematic was for the CPU + Memory I have obviously decided on them sharing a PCB.I am looking for "easy" options for multi-boarding. I spent a while looking into edge connectors and stuff and got bored and decided I could live with IDC ribbons.IDC ribbons max out at 02x25. 50 pins. For the best possible signal integrity and lower cross talk, I figured, as BOM cost is not an issue, when not just make one whole row of 25 pins, signals and their pairs GND. So the ribbon will be Signal-GND-Signal-GND-Signal-GND-Signal-GND.Do you think this is overkill? I ask as my first attempt at creating a full interconnect bus required 2x50 pin IDC ribbons. One for the address+databus. One for all the control lines for the RAM/ROM and CPU. These would be intended to allow me to add a ribbon to, say, a parallel/serial IO board, containing those two support chips. It would also allow me to attach a "spy board" for connecting monitors and logic analysers. If my glue logic on "Board 1" turns out to become an issue I can even remove it's components and add a whole new board to do that.But it's a lot of pins when you need to multiple them by 2 with grounds. In other places I see people putting gnds every 3 or 4 signal lines.... also they are probably placed strategically. For example, the clock signal (if it's not taken separately in a shielded wire) should be frame either side by GNDs. Slower, less common signals like the DMA lines probably don't need that much grounding.Of course... I can't do much about the capacitance. Not unless I want to make the back-plane active.... and if I do that I have timing and propagation issues abound.On capacitance. Bringing the bench online after a few months I tested the end to end with the signal gen, breadboard and scope. While probing a new breadboard to see where the power rails split I put the probe into the unconnected "GND" rail, while the signal gen was connected to the other rail. I got a signal. Not just a tiny noise, ghost signal, but a capacitive coupled square wave. The clock signal was 0-5V. The capacitive transfer between two rails on teh breadboard was 2.5Vpp. That's huge. That will mess something up rightly. Of course grounding that rail silenced it. This to me shows that that stuff will exist and the best place for it, is a nice clean, low resistance path to ground.The thing is though. Interleaving signal and ground is just making a "decoupling cap" out of the cable capacitance. That's great for DC-like signals, but as the frequency increases it will become less and less desirable as it will attenuate the higher frequency signals.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: May 28, 2025, 12:45:34 pm
content: Olimex has ICE40 FPGA boards starting from EUR16.https://www.olimex.com/Products/FPGA/iCE40/

author: paulca
author_rank: Super Contributor
timestamp: May 28, 2025, 12:47:29 pm
content: Quote from: Doctorandus_P on May 28, 2025, 12:45:34 pmThank you. Was surfing around and they did come up. Keeps me on a single platform for now and one supported by APIO.Tonight I'm going to try and use the verlog simulator to proof some nand gate address glue logic.... see if I end up with the breadboard and real chips or if I get into it.

author: brucehoult
author_rank: Super Contributor
timestamp: May 28, 2025, 01:19:36 pm
content: Quote from: paulca on May 27, 2025, 10:17:23 amNote that when connecting address and data pins between CPU and RAM it DOES NOT MATTER which order you use the pins in -- as far as correctness goes you can arbitrarily permute them. At maximum, on RAMs with fast page mode you can permute the upper half of the address bits arbitrarily, and permute the lower half of the address bits arbitrarily, but don't swap bits between upper and lower halves.It does matter for ROMs that you're going to program in something else.

author: brucehoult
author_rank: Super Contributor
timestamp: May 28, 2025, 01:23:57 pm
content: Quote from: Doctorandus_P on May 28, 2025, 12:45:34 pmAnd both Digikey and Mouser carry them, so you don't have to order from Bulgaria.

author: paulca
author_rank: Super Contributor
timestamp: May 28, 2025, 01:34:18 pm
content: Quote from: brucehoult on May 28, 2025, 01:23:57 pmYeah. That part was going so well until I told them I'm in Northern Ireland, then they wanted £25 delivery.Grabbed them (a board + the DIO module) on Mouser for "Free shipping".

author: paulca
author_rank: Super Contributor
timestamp: May 28, 2025, 01:45:56 pm
content: The FPGA is a dangerous rabbit hole here though.What happens if you take a CPU, attach nearly all of it's lines to a SoC and use that to not only boot the CPU but completely "pull the wool over its eyes" about memory and its addressing.You get a modern protected mode, virtual address space, multi tasking parallel bus system.Reading the Z80 datasheets, manuals and trawling through timing diagrams and address glue logic.... with a second eye on modern architectures, I can just see all the seeds of things like "Virtual Address space", Protected mode, parallel DMA/interface buses, Bus mastering, bus multiplexing etc. etc. All the tools are there. It starts to make sense.An FPGA makes a perfect place to put all that logic. "Memory TLBs" etc.I can download a Z80 Verlog file from GitHub, maybe get it running on the ICE and play to my desires. In theory.

author: paulca
author_rank: Super Contributor
timestamp: May 28, 2025, 06:20:39 pm
content: That didn't take as long as expected.... with ChatGPT help and hindrance.It's not complete and I'm not sure it's right, but the test bench is attempting to step through the Z80 M1 cycle - opcode read w/ refresh cycle.It's a start. It allows me to "visualise" and "sanity" test address logic. At some point I can convert that back to 74HC nand gates (or as I bought the other the luxury of discrete ANDs and NOTs too).The screenshot would be much clearer if I added the clock which I will do next (not as an actual timer, but manually in the test for reference, the ROM/RAM is have is clocked on CE/OE.It was quite a faff for just this:Code:// ROM: 0x0000 - 0x7FFFassign rom_ce_n = ~z80_mreq_n & ~z80_a;assign ram_ce_n = ~z80_mreq_n & z80_a;assign rom_we_n = ~z80_wr_n & ~z80_a;assign ram_we_n = ~z80_wr_n & z80_a;assign rom_oe_n = ~z80_rd_n & ~z80_a;assign ram_oe_n = ~z80_rd_n & z80_a;assign rom_we_n = 1'b1; // for nowI should probably update the title to "Screw the kits."

author: pcprogrammer
author_rank: Super Contributor
timestamp: May 28, 2025, 06:46:30 pm
content: No need to AND the read or write signal with the address line. Having it in the chip enable signal is enough.A memory chip will only be active when the CE signal is active, so the read and write signals can be connected as is.

author: paulca
author_rank: Super Contributor
timestamp: May 28, 2025, 07:21:51 pm
content: Quote from: pcprogrammer on May 28, 2025, 06:46:30 pmYeah. I spent 90% of the effort getting it to produce a useful graph and take my first steps with APIO, the contents do need review.Then I get to add IO and DMA and see if that changes things. It might add a bunch more glue for chip selects at least.EDIT:For the simulation aspect what I need to do is make it simpler to create sequences. For example a table of "ClockHalf, state..state...state" and then using an actual clock just iterate through those. I can even spreadsheet the colateral then.

author: paulca
author_rank: Super Contributor
timestamp: May 29, 2025, 11:40:40 am
content: So I upgrade the test bench .. a little... I imported someones full tri-state model of the Z80 in verlog and put my minimal test harness around it. "NOPS" from ROM.I was surprised to see a confirmation that mine isn't broken and I'm not mad, the memory refresh address does not actually start to generate it's own addresses for quite a period after reset.I seen this on the logic analyser on the real CPU and was expecting garbage addresses on T3-4 but found the address bus didn't change until the chip had run for a while, then they started interleaving PC and RFSH vector.This should help with "virtual circuit design" and save breadboards.

author: paulca
author_rank: Super Contributor
timestamp: May 30, 2025, 02:38:30 pm
content: Almost all of the hardware arrived all at once. Just waiting on sockets to move to solder-breadboards, but I can do some solderless this weekend.The parts bin now includes:A dozen assorted, genuine 74HC gates.All Period parts:1x Z80 Z84C020PEC (20Mhz CMOS)3x CTC timer IO chips. I didn't notice the order was for 3, but they were £5.69 for all 3.1x Serial interupt chip1x PIO Controller1x Dual ART 'terminal' interface.Modern ish, but compatible:4x 256kbit SRAM chips.2x 1Mbit flash 'ROM' chipsThe next step has nothing to do with the Z80 though. The next step is finding something to program the flash rom. I don't want to have to resort to finding some 74HC shift registers and using an arduino, but ... I will if I have to.

author: paulca
author_rank: Super Contributor
timestamp: June 02, 2025, 08:57:22 am
content: Programming the ROM chip.I decided to have a go with a BlackPill V2 board (STM32F411). It has "just" enough IO and not a single pin left unconnected in the config editor.Deciding life was too short for "HAL" I went LL and register direct. Wrote my own "GPIODriver" with specifics for things like "floating a bus", "grabbing a bus", Input bus, Output bus, "Release all", "AcquireAll" etc.Hooked it all up to a logic analyser and fine tuned it over the later part of Saturday. By when I went to bed, my sequences were looking near perfect.Sunday, I pulled the analyser off, hooked it up to a real flash chip and .... it didn't work.Why?Well I have no f'ing idea do I. It's not like it has an error system. It just "ignores you" if you it doesn't like what you send.So. No honestly I have no idea. It could be any number of things.1. The chip is dead.2. The breadboard circuit is wrong - swapped pins, wrong whole, etc.3. The breadboard wiring is poor due to breadboard4. Something entirely different.How do I find out? Connect the logic analyser to it of course.Problem: There just isn't enough room on a breadboard for that many lines. It's like 28 signal lines? Even the analyser struggles to do all of them and I've been leaving off the top of the databus as if I add another 4 lines I have to go to "low speed mode". The bug could be right there hidding.I did try to hook it up, I carefully made 2 rows in the BB for the headers, but after an hour trying to "weave, knit and sow" enough wires into that space it looked like a solid block of wires.I then realised I didn't keep notes on which lines went were on the analyser. I put them in "pin sequence", so trying to even see which line went where was near on impossible.I stopped. Decided that life is too short and even if it did get hooked up correctly. that 70ns low strobe on the WE line is very likely to get utterly trashed on such a system.Anyway. I downed tools.Change of approach as this breadboard crap is not going to work on the hardware side.1. Ordered some 150mmx200mm protoboards + high temp hookup wire.- These should be more reliable and easier to wire.2. Ordered some ZIF DIP40 DIL sockets for the ROM. Originally the idea was to get this working with BUSREQ and DMA quickly after it first works on a breadboard, so I could avoid the need for a ZIF and just program it in place. However as I'm realising what I have bitten off here, a ZIF socket and a separate programmer board might be a better place to start. Keep the BUSACK/REQ wired, but leave it for now.Hopefully they don't take too long to arrive.

author: oz2cpu
author_rank: Frequent Contributor
timestamp: June 02, 2025, 11:25:17 am
content: wow i am so happy you choose Z80,the first really good CPU to work with,i made quite a lot of Z80 systems,here is my firsthttps://webx.dk/oz2cpu/radios/z80first.htmi am also the person behind the first Z80 web page, later to becomehttp://z80.info/

author: paulca
author_rank: Super Contributor
timestamp: June 05, 2025, 07:18:28 pm
content: Board one - of hopefully many - that actually works.An STM32F411 ala BlackpillV2 and a 1Mbit parallel NOR flash.This is my first attempt at a digital circuit on a protoboard. Next time I will take the datasheet pin maps and mirror them along the right axis and use those. I had to rerwite about 20 of these connections because they were wrongly placed. I only found out because I actually "dilligently" "pinged it out" with the continuity tester... a step I often skip.... saved me lots of head scratching twice.The issue is the mirroring of the pin numbers. It's, so, so, so easy to get disoritentated and wire up a line of pins down the wrong side of a chip.Question: Any suggests for keeping that protoboard working while I get the PCB made? It looks fragile and it is.The protoboard does have screw holes. Maybe if I just took a sheet of wood (or cardboard) and screwed it (cabled tied it) to a back board to protect it?The next board is in flight hiding at the top of the photos on breadboard. The Arduino MEGA based debug clock. One STM32 is enough for anyone. The arduino was refreshing to use. Shame it's an anaemic weakling. So, a tiny oLED, a rotary encoder and it can barely manage to generate a 100kHz clock. I can't even use a Nano as I ran out of timers.Adjustable in "quarter log10" from 1Hz to 100kHz. Stop always stops on HIGH.TODO: "Step". Step steps high to high.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 06, 2025, 06:09:01 pm
content: Such protoboards can be quite reliable. I have built them myself with "enameled" / lacquered wire, similar to what Mike did with his BBC (@11 minutes into the video above) and I have my boards still working 20 years later. Mikes' BBC probably also still works, or has minor faults.I prefer quite thin lacquered wire. (0.2mm diameter) because I can easily bend it around a pin before soldering. One of theproblems you get is with unreliable soldering. With your thick wires, they are also very close to ajacent soldering pads.I normally poke the wire though the PCB before soldering, so the bulk of the wiring is on the top, and the bottom only has solder joints.Another big source of unreliability is mechanical stress on the wires. You have no protection at al on the bottom, and the wires bend each time you pick up your project or lay it down. Put some feet under the PCB, so the wire does not touch the table.For myself, (with the wiring at the top, and only solder on the bottom) I use simple corrugated cardboard. First I press the PCB into the cardboard, so you can see where all the pins are. Then I press all the damaged parts of the cardboard deeper down. The goal is that the PCB lays flat on the cardboard. When the PCB can lay flat on the top of the cardboard, I put a bit of glue around the edges (You can also use screws if you have mounting holes). This protects the whole underside of the PCB from shorts, for example from cut off pieces of wire or other metal scattered on your desk.When such a project is finished. I also put a few small drops of glue on the top. Just enough to fixate the wire, but still pull them loose when I want to change something. Hot glue is also nice. You can always remodel it just by making it hot. I did throw away all the cheap hot glue. It's garbage, and breaks down after a few years. I bought 1kg of hot glue from Steinel, and that stuff lasts. Other brands probably have high quality hot glue too.Sometimes I also make feet on the bottom of a PCB from hot glue:1. Add a blob on each corner.2. Let it cool down.3. Put another blob on top of the previous, to get a thicker layer.4. Wash with water while still hot. This cools down the outer layer, while the inner is still hot and flexible.5. Put it on a flat surface. Glass works good Metal is better because it absorbs more heat.6. The goal is that the outer glue is cool enough so it does not stick to the glass (metal) too hard.7. The inner layer must be flexible enough so the glue deforms a bit, and this levels the height of all the feet.8. Such feet will be "anti slip". Especially in the beginning they may still stick a bit to a lot of surfaces. But they will accumulate a bit of dust quickly, and that reduces the sticking.9. Optionally, you can model the feet a bit with a knife or a soldering iron at a low temperature (use special tip for melting glue) so they look pretty.-----------------------Working with THT parts and the constant rotating of the PCB is also very confusing for me. Lately I have adapted another method.1. Draw the schematic (I use KiCad, any PCB design program will do). Having a schematic is always nice for documentation too.2. Put the parts on the PCB (in the design software), and do the parts placement, and the routing.In the software you can easily plan how much room you need for everything, and shift things around to make more room if needed. If your footprint placement is all right, then do at least about half of the routing of the tracks. When working on protoboard, you can have as many crossing wires as you like. You can simulate this in the software by using multiple PCB layers. But it's not really necessary to layout the whole board. Just footprint planning and placement is the most important.KiCad has a very nice "cross probing" function. If you open the schematic and the PCB next to each other (dual monitor or big 4K monitor is very nice) then you can highlight a net in the schematic, and all pads (and tracks) of that same net get highlighted on the PCB too. WithPCB Editor / View / Flip Board Viewyou can mirror it, so you look at the bottom of the PCB. With a project such as InteractiveHTMLbom you also have a tool that is especially designed to assist with manual PCB assembly.A PCB design program can be used for much more then just designing a PCB.I don't like the very small letters on the Black (and blue) pills, and I make my own:1. Entered the text labels into a spreadsheet program2. Set the line height to 2.54mm, adjust font size so it fits.3. Print with a laser printer.4. Put sticky tape over the text to protect the paper.5. Cut out the text columns with scissors or a knife.6. Add generous amount of hot glue to the Black Pill, to level out the top.7. Press paper into the hot glue and let it cool. Make sure alignment is correct.8. Cut off excess hot glue and paper with a knife after the glue cooled down.Here is an example from a dusty BluePill I made a long time ago.

author: paulca
author_rank: Super Contributor
timestamp: June 06, 2025, 07:21:59 pm
content: I shall digest your post more tomorrow, but you gave me a realisation...With insulated wires, small enough to fit through "through hole" protoboard... I have VIAs! There is no reason why I can't therefore mirror the PCB layout.The issue I found with "correct length", "neatly routed" layout out is... well time. You can't just "do" you have to plan. I don't mind sharing that planning with PCB design... and feedback to it. So taking a wire from Pin23 on one IC straight to a hole, up through it and then route top side (and back down if needed) allows me to ... layout the PCB "in theory" design, convert vias to hole passes....The other idea I had was to forget using any "micro" wires and just use "steel pin", "rubber booted" breadboard wires. So much easier to manipulate and "see" when soldering. Also stiff enough to force into a currently occupied hole when melted. This is mutually exclusive to the above (per wire) though.Downside is birds nest. Upsides, they are designed for that.Hex spacer standoffs +1inch, fibreboard backing from the crafting shop.

author: paulca
author_rank: Super Contributor
timestamp: June 07, 2025, 05:11:32 pm
content: The verilog simulated version now has a display! In the from of a 16x2 LCD module. Well, not "really" of course I just get this:Code: Write Char 'H' at addr 00 Write Char 'e' at addr 01 Write Char 'l' at addr 02 Write Char 'l' at addr 03 Write Char 'o' at addr 04Showing when valid rights to the display happen.Spent most of today writing the display module simulation verilog itself, the asm code to initialise it and then write to it was fairly easy.I even went as far as to make the LCD dog slow just to annoy the ASM program with the busy flag.I think it's actually first time outside of Arduino that I did "IO" in assembler.So that's Blinky, check. Hello World, check. Whats next? PIO LED Chaser?Probably better to get caught up with the hardware, which hasn't run with a memory chip yet even.The gist of it is:Code:// CPUz80_top_direct_n cpu (.nM1(nM1), .nMREQ(nMREQ), .nIORQ(nIORQ), .nRD(nRD), .nWR(nWR),.nRFSH(nRFSH), .nHALT(nHALT), .nBUSACK(nBUSACK),.nWAIT(1'b1), .nINT(1'b1), .nNMI(1'b1),.nRESET(nreset), .nBUSRQ(nBUSRQ),.CLK(clk), .A(A), .D(D));// ROMram_async rom_inst (.addr(A[14:0]),.nCE(nROM_CE),.nOE(nROM_OE),.data(D),.clk(simclk));// RAMram_async #(.init_file("asm/rom.hex")) ram_inst (.addr(A[14:0]),.nCE(nRAM_CE),.nOE(nRAM_OE),.nWE(nRAM_WE),.data(D),.clk(simclk));mem_addr_glue_logic glue_logic_inst(.addr_15(addr_15),.nRD(nRD),.nWR(nWR),.nMREQ(nMREQ),.nROM_CE(nROM_CE),.nROM_OE(nROM_OE),.nRAM_CE(nRAM_CE),.nRAM_OE(nRAM_OE),.nRAM_WE(nRAM_WE));wire lcd1602_reset;wire lcd1602_rs;wire lcd1602_rw;wire lcd1602_en;lcd1602 lcd1602(.clk(simclk), // for internal delay simulation.rs(lcd1602_rs), // Register Select.rw(lcd1602_rw), // Read/Write.en(lcd1602_en), // Enable (acts on rising edge).data(D) // Bidirectional data bus);io_glue_logic io_glue_logic(.A(A[7:0]),.nIOREQ(nIORQ),.nWR(nWR),.nRD(nRD),.lcd_e(lcd1602_en), // "E" we assume for Enable?.lcd_rw(lcd1602_rw), // Read/write.lcd_rs(lcd1602_rs) // Data or instruction - reg select);

author: paulca
author_rank: Super Contributor
timestamp: June 09, 2025, 03:20:34 pm
content: First board... in "Review delay" phase.The ROM programmer. Just needs a few dimensions and/or notes. Then I have to remember how to bundle for PCBWay.

author: paulca
author_rank: Super Contributor
timestamp: June 14, 2025, 07:36:38 pm
content: Teetering towards going with an early prototype for logic analyser harness...I needs a few things first. It's missing some pullup/downs on control lines and Im debating whether to "island fill and stitch" the top layer ground plane or just leave it as is.$50 dollars to save me building the same thing on protoboard. I can spend that week doing something else while I wait. If it's wrong it's usually not that hard, especially in through hole to botch wire it.Then I can refine and use up that board space with something completely useless like an IO address decoder and LED + Button toys. Might even be room for the LCD16x2 pin header so it just floats over the board.

author: paulca
author_rank: Super Contributor
timestamp: June 15, 2025, 12:20:25 pm
content: Some thinking answers my own question.Yes. Yes I should plain and stitch the top ground, but not just randomly either, particularly focusing on that clock trace (and other edge trigger signals) and their ground return paths.For example, that big ugly VCC trace right under CLK is a radio anntenna. The easiest way to solve that is allow the clk ground return to "hop up over" it too... via stitching and extra upper ground pour for a shorter less inductive path than going around it.EDIT: Attempt 2...

author: paulca
author_rank: Super Contributor
timestamp: June 17, 2025, 05:13:38 pm
content: Programmer PCB arrived, just needed to wait on a new ZIF socket rather than steel one from a protoboard.Soldered it together in 10 minutes, plugged it in and ran the test script.PASS.This is my first board with "no known errors". Hopefully the CPU board that went to PCBWay last night is as "painless".Don't laugh, but it's currently only flashing at a rate of 1.5kBytes per second. Laughable, but now I have a PCB and not a breadboard I can start to push those timings tighter and double or quad that rate easily.

author: paulca
author_rank: Super Contributor
timestamp: June 19, 2025, 02:47:53 pm
content: Who needs a 50Hz clock anyway, when you live in the UK.... just leave the pin floating.https://www.youtube.com/shorts/zyfLaNVOhnQZ80s may be harmed in some of my experiments, but I do endeavour to keep it to a minima.

author: paulca
author_rank: Super Contributor
timestamp: June 22, 2025, 09:43:40 am
content: I got bored waiting on the CPU PCB. Soldering the protoboard version seems to be taking me even longer.So I connected all 40 pins of the Z80 to an Arduino mega and set about making a puppet rig.Turns out, 32k of ROM is easy enough. I just need to be careful where I map the 4K of RAM I can afford.It's fully synchronous. Aka, fast to write. It works because the Z80 is fully synchronous. If I don't clock it, it doesn't move.So, each loop I "singleStepClock", check status flags, respond to ROM/RAM requests.I can then add debug logging triggers like "only log after ROM init routines".I was struggling for a platform to test ROM boot/init routines, like building out the default interrupt handlers (256 of them), so they are (a) readdressable by applications, (b) not dangling pointers. They all get pointed to an innocent, "Enable Interrupts and return". In a verilog sim I couldn't get this routine to complete AND a user test application in "user_main" without waiting 15 minutes.I could run those routines in z80sim in a few microseconds (and unlimited simclock), but the z80sim doesn't come out of the box with any hardware or interrupt support. There are forks with some attempts, but when you did into it, it seems more of a "DIY" thing.So, one option was to softcore the z80 into the FPGA "proper" and use it's 12/24Mhz clock to run software debug. That rabbit hole ... well, when the 4th different core and setup tutorial wanted yet another completely different toolchain installed, I remembered why I wanted to build a z80 system in the first place. A breath of fresh air from "big iron bureaucracy".Using a REAL Z80 with a soft harness. That has more legs.How many legs was quick to demonstrate when I lifted the "IO Address Decoder" breadboard off the shelf and connected it to the real Z80.... reload the ASM program into the Arduino flash and reboot. (insert 10 minutes of datasheet, Wha?, Oh, Ah!), it works. Not only did it work, it taught me a few things my schematic had wrong. Notably that "!RD" is insufficient for setting the R/W flag on an IO device. Long story short, but there is mostly garbage on the buses from an (IO) application point of view. You have to be very selective at which bits see what, when.With the Serial.print() muted it "boots" my ROM in 3.5 seconds. Scope says the clock freq is about 5.2kHz. Duty cycle is 92%. This is because I do all my puppetry while the clock is high and only pulse it low to move to the next T-state.That is fast enough for purpose. Without debug print outs it can wrap a 256 8 bit output port once a second ish. Too fast to see the partterns, so too fast for purpose. When I add the serial debug printing buses and flag pin states the clock rate drops by orders of magnitude.In other parallel dev, the "slow debug" clock for the PCB board was still on a breadboard jumper wired to an Arduino mega. I considered converting it to a PCB, but honestly, I don't even really need it, I have a signal generator on the bench. So instead, for the first time ever, I bought an arduino shield kit. I have never seen the point in these, but for some reason, it fits here. Being on a protoboard should make it possible to add a real xtal and use the arduino to "sync switch" clocks from "Fast Clock" to "Debug clock" or "STOP" based on breakpoint triggers.

author: paulca
author_rank: Super Contributor
timestamp: June 23, 2025, 10:51:29 am
content: Well, this evenings fun just arrived. Largest board, from me, to date (mostly because I wanted the 50pins side by side forced the price up anyway). Looks lovely, hope it actually works. It's 100% through hole and hopefully well labelled, so it should be mod wirable if it doesn't work.

author: paulca
author_rank: Super Contributor
timestamp: June 23, 2025, 06:01:51 pm
content: It lives. I can just about tell by the LEDs, but more so, the ROM does a full "init" and then the user program calls "HALT". I can see the LEDs end up in the same patterns and the HALT line goes low.I think it's working!@100Hz

author: paulca
author_rank: Super Contributor
timestamp: June 24, 2025, 08:10:00 pm
content: This was not in the design, but I'm not arguing with it now.The two ribbons are perfect for breadboarding expansions... like a basic IO device. 138 3:8 demux 04 inverter and 573 latch.In other news the board runs its test script at 25Mhz. I stopped because the current went over 40mA. Lucky for that Z80 that I have no spares. It is a 20Mhz CPU that I have.https://www.youtube.com/shorts/dFYbpdKCea4

author: paulca
author_rank: Super Contributor
timestamp: June 25, 2025, 05:57:49 pm
content: As milestones go, this is the classic.Bare metal hello world. The only place lower level is to do the CPU ROM/RAM and LCD yourself.

author: paulca
author_rank: Super Contributor
timestamp: June 26, 2025, 10:08:37 pm
content: So I got the PIO up and running on BB.Output, check.Input check,Mode 2 interrupt, eventually, check.Then I went in to tidy up the assembler, as you do and ... things started to look quite "homely" for someone who's used an MCU before. This should not be a surprise to me, but some how I keep hearing pennies dropping every day I work on this now.This is the start of my GPIO driver coming to life. Honestly didn't think I'd get this far. CTC is next.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 27, 2025, 01:57:36 pm
content: Tindie has been mentioned a few times in this thread, but what's still missing is to mention that Tindie has a whole section devoted to "Vintage Computing"It has 40 pages and 33 entries per page, so that is over 1300 products listed.https://www.tindie.com/browse/vintagecomputing/

author: paulca
author_rank: Super Contributor
timestamp: June 30, 2025, 11:19:55 am
content: Quote from: paulca on May 19, 2025, 10:46:37 amInteresting. 18th May. Its June 30th and I am already starting to feel real ceilings to the project. Put another way, I feel like I'm 50% or more complete on the specified scope. An IO board (in progress) to contain a standard set of MCU like periphs and it's 80% there. The 20% like always be there like a derivative never reaching 0, just that there is always 20% remaining.Honestly didn't think I would get here this fast."So where next?" - thinking Autumn time or Winter when the Z80 runs out of legs.I did originally consider the 68000. It's still just about breadboard->PCB-able at amateur level.That brings me to the first non-functional ceiling. Voltage. Nothing is 5V anymore. Everything is 3.3V (and below!). I thought I got lucky and the Z80 would run fine on 3.3V. It actually ran fine at 1.8Mhz down to 2.8V before it crashed. However... the more period PIO chip does not. It craps out at about 4.0V and just stops responding - although it is on a breadboard.The 68000. When I went looking for "older" or "small" CPLDs to replace 74series sprawls.... I kept finding myself on retro 68000 forums with people begging for them. Most 5V CPLDs are not made any more. Some of the Atmel, now Microchip ones "exist" and there is new old stock, but when people have reached out to Microchip to ask about problems with modern programmers etc, they were told that Microchip doesn't know and nor will they be investing time researching old tech to find out.Door slammed. 5V get out.Of course the "no longer made" 3.3V 68000 variants are now like hens teeth for exactly this reason. I could trawl the second hand market maybe pick one up. Need to do the same with everything though and that "5V GTFO" is prevalent.From there up however it rapidly moves out of "hobby reach" at the "baremetal, ICs and traces to code and application" form. Even 32bit era means too many high speed, impedance matched DRAM bus traces and absolutely critical timing. CPUs with 100s of pins. BGAs, SoCs, MMUs, GHz clocks.I think the next "logical" step to stay "small and simple" is already in my hands. MCUs.Trouble with an MCU though, there isn't really anything left to do, except apply it straight to an application. Which I have already been doing for years. You can "baremetal" them and completely ignore the libs, but that will just get tedious and the more you gravitate towards the luxury of C and the MCUs IDE the more of the "highly modern GNU dev stack" you will encounter and your "DIY Freedom" shifts to, following the standards and complying with the norm. I think that is the exact thing Im trying to avoid. The modern magnet cieling. The closer your stray to the modern day the more risk you will just get SNAPPED hard into the current decade and no way back down.Want to interface with anything "off board" these days? It's all high speed serial. It's all based on standards like USB-3 which themselves assume standards which assume standards. You can, as BenEater showed, bare-metal and bit bang USB.One option is to leave the baremetal hardware to others. Research, buy and experiment until I find myself a nice little RISC-V dev board and begin writing an OS.... again though, why bother with a dev board at all. I can just run a whole emulation suite in gigabytes of virtual memory and do it all on a PC.A lot of these avenues end up with "Just buy a PC".A lot of other branches involve analogue or analogue/digital boundary stuff, like VGA outputs, but again... I don't even own a monitor that has a VGA port on it. To go to HDMI is a bit of a leap into Gigibit serial.Turning an MCU into a "1980s style" personal computer with commandline, graphics and multi-tasking sounds like it could be fun, or tedious and without HDMI hardware and drivers, I'm stuck with 5-6" TFTs.I could always go lower. Pick a platform like the Lattice Ice40 which has modern OSS tooling and make my own CPU.

author: paulca
author_rank: Super Contributor
timestamp: June 30, 2025, 11:34:38 am
content: On the topic of 5V.I wrote some "soft spi" GPIO drivers. gspi_driver.asm. Transmit only currently. To test receive I need a device.So I trawled through my parts bins, module boxes and could I find a SINGLE SPI device? Yes. A single one. A BME260 temp/humidity sensor. It's 3.3V and while it did come in an aruino kit, I can only see 1 mosfet. So they can't be level shifting both CLK and SDI. I actually suspect the circuit is designed for I2C and SPI won't work, certainly not 5V SPI. I don't want to use it to test the SPI libs if it's just going to burn out in the first 5 minutes and then waste hours of my time as I only have 1.Level shifted, those basic little mosfet boards will do here, it's just a pain to have to start adding them everywhere.Ordered a DS3231 which I believe is also 3.3V. But I don't mind level shifting it as it's likely to become a permanent board feature.

author: Paradroid
author_rank: Contributor
timestamp: June 30, 2025, 03:58:32 pm
content: I'd love to see you making a 68000 thing. Don't let the 5V vs. 3.3V thing hold you back. The trick is to ignore the fact that it's 3.3V if going into a 5V part (it'll be seen as "high" and "low" correctly), and use 74LVCxxx or 74LCXxxx chips for translating on the "transmit" side from 5V to 3.3V. That means: You supply these chips with 3.3V, and feed them 5V logic at the inputs, which is fine, as they are 5V-tolerant. The most complicated thing you'll need is a voltage regulator from 5V to 3.3V for supply of these logic chips. From what I've read in this thread, you're more than capable of using an LM1117-compatible regulator.The 5V-tolerant discrete logic chips can often do "two things in one": Not just level-shifting, but also apply some logic. When I first read that you want to make a minimal system with an LED and some USB-programmable flash, I immediately thought that you'll need lots of outputs for the flash address lines that shall be controlled with a USB-based MCU. So let's assume you launch the 68000 with two 29F010 flashes (to get 16 bits width), you also have a bunch of 74LVC595 shift registers that only require you to use 3 IOs on the USB MCU. Wire those outputs to the address lines, and use a tristate driver for the address lines from the CPU (a bunch of 74HC244 for example). Only enable one of them at a time, of course. Same with the data and control lines, but those should be controlled by direct MCU GPIO pins, as you need to change direction for data, and control quick timing waveforms for the flash control lines.First thing you'd write on the MCU is a flasher for the 29F010. Once you have that running, you have your dev system and can work on bringing up the 68000. ROM at address $00.0000 for it's startup vectors, more ROM at the very end of address space for vectors, possibly an Amiga-like overlay for the beginning of address space, so you can have memory (two S-Rams is the easiest thing) at address 0 after startup. Give it an 16c550 UART in an IO region of your choice, and you have a 68000 that you can log into with a terminal.Jens

author: paulca
author_rank: Super Contributor
timestamp: July 01, 2025, 12:00:26 pm
content: So the 68SEC8000 chips do exist. (Static core, will stop clock, runs on 3.3V, available in QFP package).Oddly though, nobody is selling them, except wholesale distributors. Mouser it's "We have them, but you can't buy them". Digikey it's, "There are over 100,000 available by these marketplace sellers" and promptly lists a few dozen vendors.The minimum order size is a tape, full reel or a tray. ie. 11-15 minimum. It's basically a $300 minimum order.There are reports suggesting the 68HC000 chips will run at 3.3V. However they make no such claims in the datasheet. The 68HC is a "Low power HC CMOS compatible" part. It's a 5V part, but maybe because of it's "order of magnitude less power" consumption it can run at slowed clocks reliably? I can find them for £20 in the UK easily.In the meantime I am going to buy some 74LVC8T245 8bit dual supplier bi-directional tri-state buffers and have a go at bus arbittration with an MCU. Just for laughs. Maybe overcome my fear of them and the layout complexities and timing complexities they harbour.In other "leads" for future plans... I figured out I have 24 IO on the IceStick FPGA. While that is not enough to do full bus arb, it is enough to replace all the 74HC series IO decoders and have room to spare to generate the debug clock. Absolute overkill to use a 1200LUT FPGA to replace 5 74series ICs. But it's about the fun!It does come at the 3.3V max, VCCIO stipulations though.Experiments show that my PIO crashes below 4.0V. However I did get an alternative PIO chip I can try. If it runs at 3.3V and at 1.8Mhz I might be sorted for breadboarding. I could also remove the PIO for tests.For PCB I think full level shifting of all bus and control and a 5V/3.3V boundary arbitrated by "one" thing. Everything I add either side can, if it's done right, simply ignore the problem from then on.

author: Paradroid
author_rank: Contributor
timestamp: July 02, 2025, 06:04:27 am
content: Quote from: paulca on July 01, 2025, 12:00:26 pmYes, they exist, but not in the quantities that "the marketplace" indicates. Problem is that if one broker lists them, all the other brokers will do the same, as they know where to get them, so the numbers are artificially inflated. You can only know for sure if you have an agent in China who will make the trip to the seller on your behalf. Been there, done that (last production run of ACA500plus was extremely delayed because of lack of 68sec000 CPUs).Quote from: paulca on July 01, 2025, 12:00:26 pmFor good reason: The CPUs don't work reliable. You need to compare the mask set, and the only ones that are not spec'd to run on 3.3V, but actually do, are the 68ec000 units with mask set size of 0.8µ or smaller. The 1.0µ and 1.2µ mask sets do require 5V. So you're looking for mask set E72N or G54B for the 68HC000 (pretty much impossible to find), and F30A and F90A for the 68ec000. These will run at 3.3V, but some bus signals may be a bit late in a cycle. This is not a problem due to the async nature of the bus - if you don't catch it on one cycle, you'll safely catch it on the next. It's not like you're running an RTOS, right?Quote from: paulca on July 01, 2025, 12:00:26 pmIf you're mixing 3.3V and 5V, there is no need for dual-supply level shifting. A plain 74LVT245 will do the trick. Supply that with 3.3V, and it's the perfect translator between 5V and 3.3V. Yes, it does not reach 5V output levels, but no, that's not a problem, as TTL switching level of 1.4V is below the LVCMOS switching level of 1.65V. Sending 5V to that 3.3V-supplied chip is well within spec - that's what "5V tolerant" is about.Even if you're mixing LVTTL with CMOS-TTL, where the switching threshold is 2.5V, you're hardly ever running into problems, as most 3.3V chips safely reach 3.0V high-level. Once you've digested what 5V-tolerance is about, it only comes down to choosing the correct supply rail for each chip, and making sure that all non-5V-tolerant inputs are only connected to 3.3V sources. And that really is the "problem can be ignored from then on"-state that you're looking for.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 02, 2025, 01:38:15 pm
content: I don't understand this 5V / 3V3 stuff. If you want to go into retro computing, then stick with the technology of that era too. Running that old logic in 3V3 is severely out of spec, and is likely to create endless headaches.If you want to use extra peripherals running on 3V3, that's fine, from what I remember the good old 74ls is quite capable as a level converter. Inputs of 74ls are TTL compatible, which has lower levels then the "Half of Vcc" of cmos. The outputs of 74ls also do not want to deliver much current when it's at a 3V3 level. But I do this from memory, and it's old knowledge, so verify it yourself.The whole switch from starting with Z80 (building a half board?) and then switching to 68000 is a bit confusing for me. I also loose track in those long posts. But there are retro-computing kits for 68000 too.Spelling misdirection is also doing it's best.

author: paulca
author_rank: Super Contributor
timestamp: July 02, 2025, 02:42:27 pm
content: There is a continuum of ideas. The actual hardware, is of course lagging behind.Here is for example the "standard 5V" peripherals board. Still in "settling stage". If I make a change, spot an error, it goes back on 24 hour cool down. If it survives 24 hours without needing a fix it gets sent to PCBWay.Double, double headers so I can have both boards connected, and have my breadboard ribbons.3v3 - 5v topic is two parts:1. Interfacing what I currently have with the 3.3V era for in circuit programmers or debuggers etc. Wifi<->UART modules, UART-USB modules etc. etc.2. Thoughts of the 68000 and, as far as I can tell the only place a 5V 68000 is going to get you is a useless bit of junk or a very large bill sourcing 5V support chips like CPLDs. This seems to be the consensus in the Amiga retro forums.If you look at many of the 68000 dev kits out there, the do infact have a big bank of 5V-3.3V level shifters wrapped around the 68000.These ideas are months away.

author: paulca
author_rank: Super Contributor
timestamp: July 02, 2025, 02:52:48 pm
content: On a different tangent I am exploring other "tinker" environments that negate the entire voltage problem.Soft core the CPU in an FGPA. Even the iceStick dev board I have has 24 IO. That is just enough to explore a full Z80 IO bus, just. If that works, it's not that big a step to "copy and paste" a dev board schematic into an actual FPGA in circuit and access to all the other IO.I am finding this challenging and I have yet to get a Z80 core to boot and flash an LED outside of simulation.

author: paulca
author_rank: Super Contributor
timestamp: July 03, 2025, 08:50:18 pm
content: Tiny update:Got my tooling updated to build rom partitions instead of the full 32K everytime.Should speed up the 22 second flash time without having to upgrade the STM32 to double buffered with USB and the ROM Writer.Also implemented SECTOR ERASE on the programmer firmware.When I have partition larger than 1 sector I'll consider auto paging in the programmer.On the FPGA softcore. I have a Z80 blinking lights on a real FGPA, but... I landed straight bang into the depth of hell with shared tri-state data bus in verilog. Oh boy that's some serious nannying, but understandable.Short of it is, the "top level interface" provided by the soft core creator has to come out and I need to control the databus drive in sync with my peripherals. There can be no ambiguity as to what drives when or the synthesis tool isn't happy. I tried different ways of borrowing signals from the CPU directly, but its just not having any of this bi-directional tri-state bus crap. The "core" itself has uni-directional out/in registers underneath, I need to go that way and move the "D bus" mux to a single place. At least that's the theory.

author: paulca
author_rank: Super Contributor
timestamp: July 10, 2025, 07:10:06 pm
content: The IO PCB board is still in the post.In the meantime I have been experimenting with the Parallel IO chip and an STM32 via a bi-directional bus transciever.Managed to a classic "loader" working. Effectively at the end of the ROM it enters a state machine looking for a pair of "start bytes" on the PIO port B.The upload header, 55, AA, followed by 16bit target address, 16bit length and then "length bytes"55 AA 08 00 00 01 76For will upload 1 byte (hex 76, or HALT) to address 0x8000 and jump there.All I need to do now is write the python script to drive that process from a make file.Oh and fix the annoying bug where the MCU gets locked somewhere when it loops back to the start.EDIT: As a general rule, do not "return" from a function if you have an "in flight" Serial transaction. The buffer you are sending is on... or was on the stack. Crash.

author: paulca
author_rank: Super Contributor
timestamp: July 15, 2025, 05:50:45 pm
content: Fun times. New IO Board arrived.Doesn't work.Started with the PIO. Nothing. Tried the LCD ... nothing.I've been poking and probing and it all says its working.Logic analyser however doesn't like the databus. Says it's garbage. Also says my control signals are glitching.However, it also says it's digital voltage is 3.3V, which it isn't.On the scope the databus is "tatty" but it's always tatty. It was floating all over the place, but again, it's normal, it's tristate. However I have an LED socket for the databus and a SIP9 10k resistor network also fits it, so I pulled the databus down with a 10k. That "cleaned it up", brough "floating" down to 0V rather than mid rail, but it did nothing to the problem or the logic analyser.That said. Analyser says there is garbage on the databus and the LCD and PIO agree by the looks of it.Going to take a break from it, later/tomorrow I'll break the bus out onto a breadboard and hook up the core board only. See if it can read the databus "O.G." then see if connecting the new IO board does something to trash the data bus.The really curious thing is, there is nothing else connected to the databus. The 8 lines all "ping" out with the meter as 0.5Ohm or less. So it has to be cross talk or coupling noise somewhere.

author: paulca
author_rank: Super Contributor
timestamp: July 15, 2025, 06:00:41 pm
content: I can probe or analyse the control signals.I can coorelate the signals to the assembler instructions 1 for 1 the whole want through the program. They are all correct.EN HIGH, RW HIGH, RS LOW = Read COM register (for busy flag)EN HIGH, RW LOW, RS LOW = Write to COM register.This repeats 3 times. The "init_lcd" function.Then it goes into a sequence of:EN HIGH, RW HIGH, RS LOW = Read COM register (for busy flag)EN HIGH, RW LOW, RSHIGH= Write to DATA register.In all cases the analyser shows the data lines are "stable" where they should be, but completely the wrong value and consistently the wrong values.I am holding out hope for a "DOH!" moment where something yet to assemble on the board is at fault. I have a lot of unpopulated stuff, but I don't see adding things helping the situation. The datalines are direct copper traces + the ribbon. That's been that way since a few hours ago when I took the ribbons (working) out of a breadboard and into the new PCB.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 15, 2025, 06:15:27 pm
content: You're treading on really dangerous ground there. Beware of Bruno!QuoteYou can read the whole story on:The Case of the Crashing 68000https://www.ganssle.com/tem/tem253.html

author: paulca
author_rank: Super Contributor
timestamp: July 15, 2025, 06:20:30 pm
content: I have to exclude the analyser results sadly. Having gone through the settings carefully, it doesn't support 5V CMOS. 3.3V, not 5V.It "should" work. It should be fine. But it's suspect.While the new board LCD is not functioning and the PIO didn't function, so something IS wrong, the logic analsyser saying the databus garbage ALL of the time is clearly incorrect. To execute that full program, trigger the expected sequence of control signals and end up in HALT at the end correctly could simply not happen without valid data on the data bus.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 15, 2025, 08:38:31 pm
content: Quote from: paulca on July 15, 2025, 06:20:30 pmMeh, it's quite common to make a few simple adapters for a LA. Jut a small PCB with some buffers from the right logic family may be enough There are also plenty of level converter IC's explicitly designed to convert signals to different logic levels.I've also attached the schematic of the Kingst LA1016 I have It works nicely with Sigrok, and it also has official software that works on Linux. This LA has a single bias voltage generator, and that is used with a bunch of RC networks on each input to shift the trigger level of all signals. Having the ability to sense RS485, CAN, RS232, etc levels would also be nice, but that requires different adapters. I do miss it a bit that the inputs connector on my LA does not have a 5V output to power such adapters. A 5V pin, combined with a 100mA or so PPTC would have been really nice.

author: paulca
author_rank: Super Contributor
timestamp: July 15, 2025, 08:42:13 pm
content: The first DOH! Moment.The analyser was wired wrong. The pins switch rows every 4. So I wasn't connected on DIN0-DIN11 I was connected to 0-4, 8-12, 16-18With that fixed the databus is correct.Still doesn't work though.Next thing to investigate are these "glitches" on the LCD enable.

author: paulca
author_rank: Super Contributor
timestamp: July 15, 2025, 08:55:12 pm
content: This looks fine. Writing ASCII "2" to the data register.These aren't meant to be there. The little short pulses.They seem to correspond to some databus transitions... but not all.Back to the scope.(Should have capped the legend, sorry)Register SelectRWEnableData 7v v v 6v v v 5

author: Paradroid
author_rank: Contributor
timestamp: July 16, 2025, 05:54:12 am
content: simple grounding problem? With "signal transitions that shouldn't be there", GND is a prime suspect.

author: paulca
author_rank: Super Contributor
timestamp: July 16, 2025, 09:38:05 am
content: LCD: It should all work. Scope and analyser say it should be working. However. There was a change to the logic gating on the PCB after bread boarding. On the BB, Enable, read and write where all flipped to positive logic and RD/WR XORd. On the PCB however this was replaced with a "Truth table compatible" AND w/ NOT negative logic. The truth table matches, however it was not tested on a breadboard. School boy mistake?The "false" pulses on EN. There is a non-zero change these result from that logic gate swap missing a condition. I note my schematic assumes that RD LOW + WR LOW is invalid.QuoteQuoteHmmmm. Indeed.So this morning I put the LCD asides and plugged the PIO IC back in. For 95% of pins this is a direct, pin to pin to the Z80. There is no custom logic beyond the 74HC138N decoder for address+IORQ.I have gone through all 40 pins with the scope and I have never seen a set of signals cleaner and clearer in my projects.Nothing works. Port B is floating. Yet I am spamming the chip port b registers with 3 words.COMMAND: MODE 1 = OUTPUTDATA: WRITE 55hDATA: WRITE AAhLOOPElectrically. VCC is 4.960V at the pin. GND is not really measurable against anything.Digital control signals are as clean as I have seen them. Sharp rise and fall times, a very slight sine modulation of 50mV maybe appears on some lines. Ringing is minimal. There is a bit of over/undershoot on the data lines, they nothing unexpected. The trace looks like a "garden fence" if that make sense. To me this is normal. If you single shot the scope the actual "High/Low" transitions are clean with a slight capacitive "hang" on the falling edges below about 1V if the SIP pull downs are not in place. In or out they don't change behaviour.HIGHs are all near enough VCC. Lows are near enough ground. <100mV missing at either end.Floating lines, where they exist float near to ground due to so much upper and lower layer ground plaining. You have to physically "fondle" them to get them to move.On floating pins there is about 150mV of high frequency noise.It looks electrically solid.The clock... I had to re-trigger the scope a few times to convince myself it was triggering. The clock at the PIO pin is so rock solid the scope doesn't even twitch or jistter at the 4th decimal place of the trigger frequency and I can't see the screen change except the constant "TRGD" blinking.Where to?The only leads I have are floating lines. There are a few peripheral side control lines floating. "They should not intervene.", but we are way beyond "shoulds" at this stage. It should be working.Expanding out from "floating lines". "Partial assembly". This was a late decision to assemble, populate the board in stages. The figuring being, less things to go wrong, start with the simple PIO, LCD and move on to the more complex timer and dart.However, that leaves a lot of passive copper and traces floating in the wind. Most of it expected to be tied down or driven by ICs which aren't there yet."They should" only be coupled via the bus and the IEO/IEI and INT lines. Which shouldn't prevent an "output mode" write.again... it "should" be working, so we are outside of "should" predictable world already.

author: paulca
author_rank: Super Contributor
timestamp: July 16, 2025, 10:56:33 am
content: Progress. The LCD is fine with the address decode and it's enable line is fine. What it doesn't like is being passed "CPU_WR" directly.If I swap that out via the breadboard to be!CPU_WR ^ !CPU_RD it works.LCD RW pin expects 0 = Write, 1 = Read.So that doesn't make sense. XOR'ing both inverted signals gives you a 1 if either where low, not if both are low. So in the case of a write, CPU_WR will be low, so !CPU_WR is high, we assume !CPU_RD is low. The output is 1 high.That should equate to a read. Anyway, I can debug and mess around to figure that out, then botch wire something in.It turns out when I put the PIO controller back into the breadboard it doesn't work. So either the breadboard has been disturbed, that PIO is now dead or I introduced a bug somewhere else.If I can restore it work working on the breadboard I can "port signals" across one at a time to figure out which is broken.

author: paulca
author_rank: Super Contributor
timestamp: July 16, 2025, 11:06:53 am
content: Thank you Zilog you bawbegs.Mode 1 is output, right.No.

author: paulca
author_rank: Super Contributor
timestamp: July 16, 2025, 11:19:17 am
content: The desk is perfectly tidy thank you.Look what I spotted, nicely labelled too.... can I get lucky?EDIT: No.[ Specified attachment is not available ]

author: paulca
author_rank: Super Contributor
timestamp: July 16, 2025, 11:32:03 am
content: PIO Functioning on the new PCB! Port B tested as output so far.So that's one hardware casualty of not testing logic circuits and one software blunder.Certainly better than yesterday where zero worked with no apparent reason.So more cheering up. As the photo in the previous post shows, not only does the board/bus stacking work (spacers are not installed, hence the paper card to prevent accidents), but the breadboard breakout still works while the boards are stacked. This is why I painstakingly doubled the headers up so I didn't have to start hacking up custom daisy ribbons.CPU Board-> IO Board -> <insert board here> Breadboard. All address, data and signals broken out to the BB.The only smart thing I didn't do was to add key IO board signals to the header's available pins.Further. As I now have two address decoders in service, the IO Board and the breadboard that confirms the twin 138N (or more) strategy works. I can also test them operating on non conflicting addresses in the same HIGH/LOW range.I think I feel brave enough to solder up the rest of it.-----On ribbons. I did buy 3 meters of ribbon. I also bought a bag of 10 50pin IDC connectors for them, even the tool to clamp them correctly.The reality however is that the connectors took forever to arrive. They are extremely fragile, unforgiving, a slip or pull in the wrong way getting the ribbon in and it snaps the clips off the holding bracket rending that connector useless. So I opted to use the pre-made ribbons until I get to more stable board config, then I'll make a set of custom daisy ribbons for the back plane.

author: nfmax
author_rank: Super Contributor
timestamp: July 16, 2025, 12:08:20 pm
content: Quote from: paulca on July 16, 2025, 11:06:53 amIt all comes flooding back into mind: 1 => I => in; 0 => O => out. Perfectly logical!

author: paulca
author_rank: Super Contributor
timestamp: July 16, 2025, 02:40:27 pm
content: Board assembled.PIO works both channels.With the full set of ICs it pulls 146mA. So I expect there is something else broken. It's not completely un-reasonable. However when I take the DART out it falls to 96mA.CTC comes next. Part expecting the floating TRG/CLK lines to be upsetting it.CTC or adding the parallel USB loader. If I get the bootloader setup in "Load from USB" mode like before the PCB arrived, I can code and load from the PC only needing to reach behind me to hit RESET. That might speed up the CTC experiments.

author: paulca
author_rank: Super Contributor
timestamp: July 16, 2025, 04:03:07 pm
content: That would be a 115200 baud rate pulse from my new CTC.It's a bit ... weak, needs investigating if that's thebest it's got or if it's (a) broke, (b) badly wired. There is a bit of a lottery here. Most of the period chips are S/H and the CTC was in a "lot" of 3 with no "verified" or "tested".

author: paulca
author_rank: Super Contributor
timestamp: July 16, 2025, 04:58:00 pm
content: The 3.2V thing may be all these guys have left. They may once have put out Vcc-0.8V but no longer.All 3 have the same markings, including a painted serial stamp on the bottom, they are all the same manu-date code and all behave identically.All sink about 10 times more current than they should.They are likely OG 1986 parts.EDIT:Part number says they are NMOS parts. The datasheet says the supply current can be upto 120mA! LOLAll it says about it's Voh is... MIN 2.4V

author: paulca
author_rank: Super Contributor
timestamp: July 17, 2025, 02:29:29 pm
content: Another key milestone:So to sum up the board works with one signal mix up on the LCD.Now the fun starts. I can write loaders, command line, monitor app, etc.The noise. God knows. My nose is sniffing the 100R series resistors being little antenna. Might be better when loaded with something on the other end,,,, or worse.

author: Paradroid
author_rank: Contributor
timestamp: July 17, 2025, 04:17:42 pm
content: Quote from: paulca on July 16, 2025, 04:58:00 pm...so your threshold is 1.5V. Perfectly fine if you use 74HCTxxx TTL logic.

author: zmetzing
author_rank: Contributor
timestamp: July 17, 2025, 07:08:35 pm
content: > I want bare metal. To start with just the IC and build from there. I'm talking "Blinky" and onwards.I'm surprised nobody suggested the COSMAC Elf (RCA 1802).http://www.cosmacelf.com/You can breadboard yourself one, or buy a Altoids-sized "Membership card".http://www.retrotechnology.com/memship/memship.htmlIt is neat in that you can really do the whole "flip switches and write a byte into RAM" programming style, with just the processor, an oscillator, and some RAM.

author: paulca
author_rank: Super Contributor
timestamp: July 17, 2025, 08:25:15 pm
content: But it's the Sanatra effect.QuoteZ80 datasheet... go.The thread title is miss leading. When I seen a "kit" all I had were questions of "Why that way?", "How does that limit me?", "Why is that complicated?"I didn't want a build, flash, test single hit. I wanted a drug.

author: paulca
author_rank: Super Contributor
timestamp: July 18, 2025, 02:13:36 pm
content: So my brain is fried. Spent the day writing string utils, parsers, command line state machines.It's getting closer to a UART boot loader...UPDATE: The loader works. (64bytes per second @9600baud, but it works). I can successfully use a python script to puppet the command line, upload as hex file and execute the user program. Bonus is that user programs can just "reboot" on exit and the UART terminal returns to the command line. I am intending on spliting this across the UARTs so that the uploader can connect on channel 2 for the upload, while the terminal stays on channel 1. Hopefully will facilitate the following sequence:>LOAD 0x8000 0x0123...........ok>RUN 0x8000Hello World!>

author: paulca
author_rank: Super Contributor
timestamp: July 19, 2025, 11:57:03 am
content: The LCD 16x02 failing to work. Been thinking about this.Here's the crux. The LCD interface chip: HD44780 is "asynchronous" at the Z80 point of interface.So, in a given sequence of T-states the Z80 will switch control signals when executing instructions.These do not happen simultaneously. Even the datasheet shows that those signal transitions have order and propagation time. There are mentions of which signal should be taken as the trigger, for instance I believe it is RD or WR for memory. All other control signals will be stable when RD, WR go low. It's not IIRC exactly the same across all instructions.This normally doesn't matter. What matters is that the signals are stable on a clock edge.... but we are not synchronous with the Z80 when using the LCD. The CTC, DART, PIO are all synchronous. The ROM and RAM do their own gate timing and where basically designed to fit the JEDEC standard, so "just work".So when I take signals like A7-4, IORQ, RD, WR and use them to 'gate' an "Enable line" for the LCD, or I deconflict RD, WR for it. The order does matter.So while I design my logic for the final stable state, the LCD being "edge triggered" async doesn't agree. If a 'transient' state forms within the "transition phase" of the CPU signals, which triggers an edge trigger on the LCD interface, the LCD IC will start doing something. It may even read from the databus into a config register. It might even conflict the databus writing something to it.Now even the fact I had this working on a breadboard with the gates I did, does not meant they where correct. Even the fact that I can connect a jumper from the breadboard to the new PCB and get the LCD to work... that doesn't mean they are correct. It just means they are correct enough for that "delay context". If I move the same logic onto a PCB with a 10mm trace between pins, it might not work. A small "pulse" generated as say, IORQ and RD transition 5ns apart, might disappear in breadboard capacitance and materialise just clear enough on a PCB to trigger the LCD.To do it correctly. I need to account for the transients and place the gates in the correct order such that it doesn't generate false transitents. Maybe pay attention to which signal is the last to change and ignorantly OE a buffer or flipflop at the end to ensure nothing changes until that signal changes.What is more likely to happen, is I'm going to hack at it until it works and forget it.

author: paulca
author_rank: Super Contributor
timestamp: July 22, 2025, 01:27:19 pm
content: Oh dear. I had to go and read the 68000 datasheet.Having spent the last few months so intimately with the Z80, looking at the 68000 datasheet and so many things speak to me with "reason and justification" now.I understand the power, for example of DTACK and why it exists. The pain the lack of a bi-directional signal for ASync bus access causes for hardware design.The 3 bit base INT vector, auto vector or self vector. So much more convenient that the "Z80 Mode 2 cult". At least the 68000 bus can tell the CPU 8 different things without the need for further bus cycles. Yet, bus cycle vector publishing is also provided with even more power.CPU supervisor mode. At least a basic one. Opens up the path to multi-tasking or at least better interleaved OS management of user tasks and being able to take sharp tools away from the user code entirely.Bus faults and supervisor mode opening up the basics for virtual memory and even possibly storage mapped memory paging.Then I found out that the async bus handling is tolerant of very, very long wait states. So while you can't run it with a "stop/step" clock, you can stop/step the bus. Therefore you can breadboard it and puppet rig it for play. How the breadboard takes to an 8Mhz OSC or the signal gen remains to be tested when my "old stock" 80s vintage 68000 arrives.

author: Paradroid
author_rank: Contributor
timestamp: July 22, 2025, 03:42:05 pm
content: Singing my song :-)

author: paulca
author_rank: Super Contributor
timestamp: July 28, 2025, 08:11:10 pm
content: Starting to get nicely built up with comforts.The direct IO read write from the console is lots of fun.The console can run code, but the code is expected to return (or jp) to the console entry point on exit. The precursor to a shell?Code:>LOADLoading to 0x8000Complete... 0x042Fbytes.>RUN 8000Press ENTER to continue...Memory Monitor V1.0M> hRom Monitor Helpr hhhh - display 16 bytes from address hhhhw hhhh hh - write hh to address hhhhi hh - read IO address hho hh hh - write hh to IO address hhs - Display last 8 stack 16bit pairs if availh - Display this helpq - Quit to consoleM> q>LOADLoading to 0x8000Complete... 0x0432bytes.>RUN 8000Press ENTER to continue...Memory Monitor V1.0M> hRom Monitor HelpThe load has to be actioned on both sides for now. The "LOAD" with no args means LOAD to 0x8000 if you want it elsewhere thats an option too. Once executed it will wait for up to 5 seconds on a header. So within 5 seconds I have to run "make install" IDE side.