-
I would like to build a Z80 computer based off of many designs I have found across the internet. I have been trying for some time to complete this project. I started about a year ago gathering components and trying to build off of my bread board repeating designs with no success. I was having trouble validating my design, but I was trying to accomplish too much at once, which prompted me to break down the project into sub-components. I have a blog where I have been documenting this so far which is z80project.wordpress.com.
I am stuck at the point where the hardware meets the software, which seems to be the all-in point. By all-in I mean that I need to have the system physically built to test the software, and the software completed to debug. It just seems like breaking the project down into pieces was easy up to this point, and the next chunk is just made up of the rest of the project.
I have a schematic that I have made up in eagle documenting the system, I just to make the computer into a serial terminal on my first go, and complete a ROM monitor to service the serial terminal.
I am attaching my schematic. Please let me know if I am headed in the right direction, and of any good resources that could help me get further with this project. I am open to any ideas.
-
I am stuck at the point where the hardware meets the software, which seems to be the all-in point. By all-in I mean that I need to have the system physically built to test the software, and the software completed to debug.
Ehm, no. There are many z80 emulators out there. They allow you to run and debug code without ever having to build hardware. Add a cross-assembler to it, and you can start. -
I will probably be taking your advice and looking into Z80 simulators/emulators to run/debug my code. I am just wondering though how does this help me figure out if I am sending the right data to my UART for instance. Other than the simulator telling me that the code is clean, how would it help in telling me my hardware external to the Z80 will work?
( I have never used a CPU emulator/ simulator in the past) -
is your uart intentionally without interrupt ? otherwise looks good at the first sight
keep going ! 
-
Hi,
In the 90’s I build a lot of control systems based on the Z80 family components. My major tools, for implementation of hardware specific functions, was an in-circuit EPROM-Emulator and a logic analyzer, because tools like JTAG-Programmer/Debugger or In-Circuit-Programmer are not available for Z80 CPUs. The EPROM-Emulator will help to reduce the turnaround time for changing the machine code and the logic analyzer is the easiest way to debug your code.
-
What UART is that? I can't see a number on it anywhere... (whereas almost all the other chips say what they are...twice, even!) Guessing an 8250 or 16550 or something like that... very typical whatever it is.
Some IO decoding may be handy later on, maybe some simple bus latches or whatnot. Almost trivial to put in some extra parallel outputs or inputs, or even a proper parallel port as such (in fact, a true-to-spec IEEE-whatever uni- or bi-directional parallel port is only a couple chips at worst). Then you can throw in LEDs or displays or keypads or whatever you like for easy I/O alternatives.
My old example: http://seventransistorlabs.com/tmoranwms/Elec_Z80.html
Also, a bus interface to introduce programming from an outside source. I used the parallel port and a mux'd and latched address/data interface. Real simple. Programming from Windows XP required the GiveIO ActiveX and DLL, but was simple and standard otherwise. (Heck, if I wanted to rebuild that, I have a proper Pentium now, with Win95 -- no port restrictions to worry about.)
Tim -
Back in the early days of processors they used a BUG program. Motorola called theirs MIKBUG (IIRC). This was a monitor program that the reset vector pointed at. It provided (using a dumb CRT monitor with keyboard and a RS232 UART) a basic ability to peek and poke memory locations, processor registers, sometimes a loader program. I worked on one called NUTBUG, as the original designer was driven nutty by it. It has a halt command for program debug. The system I worked on had a emulator that plugged onto the processor board, and disabled the on board EPROM and substituted RAM into the same memory map address. We loaded programs into ram from a paper tape, which evolved to a cassette tape ~1984. This plug on emulator board had the EPROM at the top of memory (FFFF/FFFC0 and 4K below) with the bug program (one was for a 65c102 and the other a 80186).
-
You can still break things down at this point.
The first thing I'd do is write the simplest possible program to set the baud rate, and check that BAUDOUT is wobbling at the right frequency. Or stick an LED on one of the handshaking lines and make it blink. If that works, you know you're talking to the UART correctly. If it doesn't, at least you've got single stepping and the ability to look at what's on the bus, and a program short and simple enough that you can step through it cycle by cycle without getting lost.
Once that's going, the next step up is "hello world". Then get it to echo the data being sent to it. Then do it with interrupts, if you want to use them. At that point you've got known good building blocks to do anything. -
Hi,
Been a while since I did any Z80.......
Is your only I/O going to be the UART?....might be an idea to add a bit of decoding on pin 20 of the Cpu with WR/RD to give you a bit of flexibility.....even if it's to drive a bunch of LEDs or read a few switches.
Ian. -
Thank you for all of your replies. The UART is in fact at 16550. I do not have any experience with any of these chips, but I am reading up day by day from each data sheet. What would make me estatic, and my first mile-stone, would be to get the system talking though a serial port on my computer using putty. I like the idea of throwing some LEDs on the UART to see that I am communicating with it properly.
To date I have successfully implemented a low-freqency variable clock source, and an instruction stepping circuit with the Z80. I made an LED driver board so that I could monitor the Z80 running, and tied its data lines so that it would just cycle NOPs. I validated that all this worked, and my next thought was to add in a ROM to the recipe. What I thought I would do is simply run instructions that did not need RAM to test if my ROM was being programmed correctly. I could step through these instructions with the stepping circuit.
I am using a G540 universal EEPROM programmer ("G" for garbage). I wish I had a better method of burning the ROM, since the software for this product leads me to believe that it does not work correctly.
I never got around to testing the ROM fully because I became interested in another project where I built and arcade cabinet from scratch, and I dismantled my stepping circuit. I was thinking I would build it back up again, maybe on a PCB, and make a modular system of interconnected PCBs so as to avoid the rats-nest that my breadboard becomes. Obviously at some point I will need to gravitate toward the PCB because I will be running at a frequency that makes breadboard applications unreliable.
I have not had much time to work physically on this project since I have just moved, but I am hoping to get back on this once my bench is set up again, but for now reading, designing in Eagle, and simulations are my best course of action.
I figured I would just attach my Eagle file if anyone was interested.
-
To develop firmware for your board I'd initially just write code which sends the same character repeatedly out of the UART - you can then hook it up to an RS-232 port or dongle and see the characters, then try a loop which just reads a character and echoes it back.
Once you have that you'll be well on your way.
Tight loops can be useful for debugging - a jump relative back to itself is "18 FE" in hex. Stick one of those at an even address and if the code hits it you can probe the address bus to find out where - just trigger on M1, then probe the address bus which will stay fixed (during M1 low). Very useful to put in the NMI vector (0x0066) if you're not expecting NMI's (and set IM1 and put a loop at 0x0038 if not using interrupts). -
When the reset button is closed, you are creating a voltage divider consisting of the 2 10k resistors giving 2.5V which is a little high. Consider lowering RESETRES2 or abandon it.
-
Yes, remove RESETRES2. It's also polite to have a diode in parallel with RESETRES1 (pointing upwards), so RESETCAP has somewhere to discharge when power is removed, and doesn't hold NOTA's input above VCC.
I don't know enough about Z80s to comment on the rest - it was always the 6502 for me. Except... doesn't the Z80 like its ROM at address 0? You've got ROMCE (which is active low) asserted when A15 is 1. And you've left the ROM's !WE input floating. -
Was there some reason you chose the Z80, as opposed to say, the 6809?
If you want to actually write useful software for an 8-bit CPU, I'd go for the 6809 any day. Much nicer. -
Was there some reason you chose the Z80, as opposed to say, the 6809?
If you want to actually write useful software for an 8-bit CPU, I'd go for the 6809 any day. Much nicer.
actually the Z80 is very nice CPU - it's compatible with 8080 instruction set , and has a wide instruction set. for learning & fun it's quite good and cheap CPU
-
Check out Colin Mitchell's Microcomp & TEC-1A Z80 computers:
https://www.eevblog.com/forum/beginners/3-chip-microcomp-1/
http://www.talkingelectronics.com/TE-1-15_pdfs/TE-Issue13.pdf
http://www.talkingelectronics.com/TE-1-15_pdfs/TE-Issue14.pdf
-
Dave, your post about TE Z80 computers and Colin Mitchell reminded me that I would like to see some interview with Jim Rowe from Electronics Australia. I suggested it for The AmpHour but it seems Chris does all the arranging of guests. It would have to be interesting to JR.
Good idea.
Never met Jim myself, but dealt with him with all my projects in EA. -
Quote
If you want to actually write useful software for an 8-bit CPU, I'd go for the 6809 any day. Much nicer.
The 6809 is quite a nice processor but arrived a bit late on the 8 bit scene to really fulfil its potential. I did quite a bit of 6809 assembler but never designed any 6809 hardware. -
I would suggest reading Quinns posts on building her homebrw computer.
She used a 6502 instead but had all the same issues, doing a rom monitor, board stack etc. You will find lots of good info in her posts
http://quinndunki.com/blondihacks/?page_id=1761 -
Dave, your post about TE Z80 computers and Colin Mitchell reminded me that I would like to see some interview with Jim Rowe from Electronics Australia. I suggested it for The AmpHour but it seems Chris does all the arranging of guests. It would have to be interesting to hear from JR.
He could demonstrate the operation of his EDUC-8.
-
Thank you for the suggestions on the schematic. I think I got the glue logic wrong as you pointed out. MREQ is ACTIVE-LOW and when A15 is LOW I would want the ROMCE on the first OR gate which is also ACTIVE-LOW to result in a LOW. (ROM READ) When A15 HIGH the inverter inverts to LOW, and get the same result from another OR gate. (RAM READ). Thanks for pointing that out, and also the /WE floating pin. This pin will be tied to VCC for now.
I am trying to understand the diode in parallel with Reset-Resistor. Is that because when the power is turned off 'VCC' becomes "GND" (0V), and the capacitor discharges through the diode bypassing the resistor? (Path of least resistance? Could I put an LED there to see this discharge?)
The UART's interrupt I have not sorted out, nor do I really understand it yet.. I figured I would either do the LED blinking test or the send a loop of a single character to see I am talking to the UART correctly.
What a freaking gold-mine. Thanks for that website Dave. I will look into all of this.
The reason I chose the Z80 is because I took an entire microprocessors class centered around the 80386, and learned a whole lot, but it just did not stick, and I think it is because the class aimed too high, trying to unravel the complexity of a 32-bit processor with a lot of bells and whistles. I figured that diving deeply into a more simple processor would give me a better understanding of the more complex processors later.
I am also a computer engineer, but never got my hands truly dirty with physical electronics. I was mostly exposed to software in university, and ever since I got out I have had a passion for the electronics hobby.
-
I was watching a youtube video on the history of programming languages and there was a bit about cpu architectures. I had never heard about it before, but right after the 8080 series, but before the 80186 series from intel, intel wanted to go away from the x86 architecture because of its many flaws. Intel designed and produced the 432, which executed bytecodes directly, and apparently was a much better architecture. It didn't perform, and so we were stuck with x86 until AMD designed the current 64-bit architecture we use today, which is just another advancement of x86.
I'd like to see inexpensive micros today that both perform well and that execute bytecodes directly, such as from Java or .NET. There are embedded Java and .NET micros, but they have virtual machines running on off-the-shelf microcontrollers, as far as I've seen.
Anyone know of anything like that? -
I would second bloodycactus' suggestion of looking at quinns site, also I found this immensely helpful for my z80 project:
http://searle.hostei.com/grant/cpm/index.html
I built that circuit on stripboard and it works really well, it was the best complete schematic I could find. -
I am trying to understand the diode in parallel with Reset-Resistor. Is that because when the power is turned off 'VCC' becomes "GND" (0V), and the capacitor discharges through the diode bypassing the resistor? (Path of least resistance? Could I put an LED there to see this discharge?)
That's it. VCC becomes 0V, and without the diode the capacitor will try to discharge through the inverter's input protection (if it has any - 74HC does, I don't remember about 74LS).
An LED wouldn't do much good. If the inverter input has protection diodes, they'll keep the capacitor just above VCC as it heads down, and the LED won't light. If it doesn't, the LED will only discharge the capacitor to its forward voltage (a couple of volts or so), which is likely to be outside the safe range for the input.
I don't know if it's strictly necessary, but it doesn't hurt. It depends how tough the inverter's inputs are. I've always put the diode in, just to be safe.
It doesn't really matter which processor you use. If you come from an Intel world, the Z80 is likely to be a little easier on the software side. But anyone who survived the C64 vs Spectrum wars knows the 6502 is the best :-)
Quinn's work is great, and worth looking at whatever you use. She's much better at testing and step by step progress than I am. And it's all documented very well.
Edit: And it's fine to ignore the interrupt on the UART. You can start out with polling to see if it's ready for another character. Later on, if you decide you need it, you only need to add one wire. Probably. I say this without reading the datasheets, and never having used those particular chips. -
Sounds like a plan. Quinn's work looks promising for help especially if I move toward making a dedicated video board which I will probably do. I found a perfect 15" Dell VGA monitor at a second hand store for ~$10, so I will probably look into getting some output on that as a second mile-stone.
I am in-between whether I should breadboard, soldered protoboard, wire-wrap vero board, or just go straight to PCB. In the past I ordered 10 boards from iTead studio for $30 shipped, which came out quite well. (seen below) Of course they did not work at all, but they make great (relatively expensive) coasters.
I am leaning toward getting back on the breadboard since I will have to buy something in every other situation, I always seem to run out of room, and it take longer to prevent rats-nest that it seems worth.
On a side-note does anyone have any suggestions regarding EEPROM programming hardware? As I mentioned before I have a G540 Universal Programmer, but I would like to look into something a bit more user-friendly.