Help Needed w/ z80 processor

Discussion in 'Technology Talk' started by Q2DM1, Sep 4, 2017.

  1. Q2DM1

    Q2DM1 New Member

    I have three z80 processors and no know-how. I need help getting a working circuit/program.

    I have a z80 processor (actually I have three) that I want to do something--anything--with, even if it is flashing an LED. Okay, I already did flash a few LEDs using a basic test circuit I found online, but I want to actually program the flashing.

    I already have what I need to build a system (RAM, ROM, Arduino Uno that I can sorta turn into a programmer). I found schematics for wiring it all together and they seem rather straightforward. But that's about where my knowledge ends.

    I have looked and looked and looked, but have yet to find a single project that uses very minimal parts and programming, outside of the basic test circuit. I came across a few posts of people saying they have built small projects like that but didn't have schematics or the program or anything.

    As stated before, I don't care if I flash an LED (I literally looked that up and found nothing). I just want to have something I can say, "hey, look at what I did, bitches."

    Do I program the processor itself or the ROM or both? That's a question I need answered too.
    Last edited: Sep 4, 2017
  2. Saiko

    Saiko GTWT Survivor

    First, to answer your closing question, your wording for "do I program the processor itself" is a bit wonky. You could play with semantics to make any answer work. The precise way this whole thing works is that the z80 reads the current instruction from the memory, runs it, reads the next instruction, runs it, ad infinitum. So, to "program the z80," you have to flash your program onto the memory at the correct memory address.

    As for a project, there are several routes you could take here because you actually have two separate, fully-capable processors - a z80 and whatever the Arduino uses. Both are full-blown microprocessors with instruction sets and everything, and for what you're doing, you'd really only need one or the other. From your perspective the main difference between the two is that the Arduino already has a processor, memory, and an associated software suite that makes it relatively easy to create and run firmware for it. The z80 is capable of running the CP/M operating system, but you'll have to hook up the memory and whatnot yourself and figure out your own way of flashing your firmware onto it. This is why you couldn't find any simple projects for a z80. If you're just starting out with this stuff, I recommend sticking with the Arduino and leaving the z80's alone for the time being.

    Although I don't know the specifics, your LED project should be quite straightforward with the Arduino.
    1) Design a circuit for the LED that accepts an ON/OFF control signal from the Arduino, and connect the two accordingly. Remember to check voltages and such, so you don't fry anything.
    2) Using the Arduino IDE on your computer, write your ON/OFF program to produce the control signal. This program will be in C, and the IDE will compile it to the Arduino's machine code for you.
    3.) Plug the Arduino in with its USB cable and compile/write your program to it. If I remember correctly, it should start running the program right away.

    If you're interested in using a z80, this will be considerably more complicated (although pretty damn cool imo) because you'll basically have to start by building your own "custom Arduino" from scratch. As I said before, the z80 is just the processor; and it needs all of the supporting components in order to work properly. This includes a circuit to produce a clocking signal, memory, a way to initially write your firmware to the memory, and probably a button to trigger a RESET. It might be good to have a power switch or something like that too. The specifics for this part would be completely open-ended because, as I said, you'd be building your own itty-bitty system. After this was done, though, the LED project would be comparable to the Arduino procedure. You'd build your LED's circuit, write your program for the z80, flash it to the memory, and turn it on. The big differences here, though, are that you probably would be programming it in assembly instead of C; and flashing the program to the memory wouldn't be as simple as plugging in a USB and clicking a button.
  3. Q2DM1

    Q2DM1 New Member

    Aye, I have plenty of experience with the Uno, so I'm not too terribly lost in what I am doing. I have made a clock circuit using an NE555 timer; at first it was a simple astable circuit (50Hz), but i turned it into a one-chip ring oscillator (and measured about 400KHZ with it), so I am set in that department. When I asked about programming the z80 itself, well, let me think here. I read on one of the sites I came across (it's been a while back), it was mentioned that the CPU itself contains enough RAM/ROM to store and run a very small program. It may have just been an error on their part, or an interpretation error on my part, or both, but that's why I thought "program the processor." It would be less of programming the actual processor, but programming some of the internal ROM.

    I stumbled around some more forums and finally checked about connecting an LCD display to it. It seems rather straightforward too, but I am pretty sure I am nowhere near ready for that level of programming - even for an Arduino (ignoring there's already a library that exists for that). For flashing the program, I planned on wiring the Uno to the EEPROM stick using shift registers and writing a program for the Uno to take incoming serial data (over USB) and programming the ROM like that. Sure it'll take forever, but its better than using lots of switches lol. Hell, if nothing else, I'll write the program, order a new stick of ROM and have Digikey to flash it before shipping.

    For the very basic LED circuit, I guess I could just connect the LED to a data line (or one LED/data line (8 LEDs)) and flash it by writing a number to the data bus using glue logic (AND the data bus with /IORQ).

    But as I interpret your answer to the programming part, all I really need to do is learn assembly and flash the ROM and the rest should happen automagically by the CPU without extra doing on my end. Well, okay, some extra doing, but you know what I mean. If I am correct on that interpretation, then I'm fairly set on getting started aren't I?
  4. Saiko

    Saiko GTWT Survivor

    No, the z80 shouldn't come with any internal memory apart from its registers; the instructions specifically come in over the D0-D7 pins. In any case, it sounds like you have everything you need; and the idea to use the Uno to flash the memory is cool.

    My only question is whether the read/write operations for the EEPROM require the same voltages at the pins. I know that kind of memory uses a higher voltage to perform the write operations, but I don't know if that's handled internally or not. I'd double-check that before I soldered anything. And of course remember to put the memory behind appropriate MUX/DMUX circuitry if you're going to have both the z80 and Uno connected to it simultaneously, so they don't interfere and corrupt stuff.

    EDIT: Now you've got me wanting to build one of these things myself lol.
    Last edited: Sep 4, 2017
  5. Q2DM1

    Q2DM1 New Member

    Lol. But yes, the data sheet specifies 12V to drive the write operation. I have actually tested it in the past and it works fine on 5V. I uh, I have some nonsense data stored in the lower addresses already from the experimenting. But thanks for clearing stuff up for me. This project doesn't seem so scary to me anymore. I'll probably be back with more questions, though.
    Saiko likes this.
  6. Q2DM1

    Q2DM1 New Member

    It felt like a century, but I have the computer portion built. If I can from iPod, I'll share pics. There's a good chance it may be wired wrong. I'm more worried about the Inverter I built from a FET and resistor. But assuming all wiring is good, all that's left is writing a program and flashing the ROM. I went with four LEDs; two green and two orange (okay, one is yellow) to keep it simple but not too simple. But let me try to get those pics now.

    [pre-post edit]
    Pictures are being too difficult. I'll do it from a computer
  7. Q2DM1

    Q2DM1 New Member

    IDR what the forum rules said about double posting, but I am able to add more useful "stuff" this time

    Now that I have had the chance to do more stuff with this project, that's exactly what I did. Still no images, but let me explain my circuit. First I connected all address lines and data lines as one should expect. I used this image to connect the RAM and ROM sticks (more specifically, the control connections). For the inverter, I used a 555 timer. I originally was going to AND /IORQ and /WR (both inverted) on the CPU together and then AND that to the lower 4 bits of the data bus but then I found a few of these things. I ended up needing to keep the AND gate as a buffer lol. Also, I was unable to successfully invert /IORQ and /WR. Luckily I found a few NOR gates and utilized one to drive the CLK pin of the octal flip-flop.

    As for my programmer, I ran out of jumper wire and had to make my own. I used this little (big) digital electronics trainer thingy because it has more room than the board the computer is on and it also has 8 logic indicator LEDs, so it was helpful debugging that circuit. A few hand-made jumpers, some coding issues, and lots of staring at datasheets later, I finally managed to get the programmer working. That's where things went more downhill. I found--but only read three chapters of--a book on how to program a Z80 computer. I ended up looking up the instruction set and converted the op-codes to decimal. I made a text document to write the ROM address with the decimal code to fit in that address and then inserted them one at a time. And that is where I currently am in this project.

    In my code, I attempted to load into registers B, C, D and E: 5, 10, 6 and 9. This is supposed to be a data/light pattern. Green LEDs are on data pins 0 and 2 while data pins 1 and 3 are yellow/orange. I also tried to get the CPU to send the patterns to my output device (the octal flip-flop and, ultimately, the LEDs). The LEDs do change colors. Between the changed patterns are 15 NOP instructions (this is 60 clock cycles total on a 60 Hz clock for a 1 second delay (minus clock cycles to execute other instructions)). At the end of the patterns and their NOPs, I attempted a jump to an address where the pattern begins. Remember how I said the LEDs light up? They don't do so correctly and the program doesn't loop. I also had to remove the RAM because it interfered with the operation of the device.

    I have not verified the integrity of the contents of ROM, but I suspect it is programming correctly and I'm just an idiot. I suspect the former because when I changed the program, the LEDs behaved differently. The latter is a given.
  8. Saiko

    Saiko GTWT Survivor

    Hrmmm, to prevent the interference between the RAM and ROM, I would try putting their data output pins behind an 8-bit DMUX with A15 as the control bit. It looks like the diagram you used assumes those pins output high impedance when each chip is disabled, but that might not be the case for yours. With the DMUX, that shouldn't matter.

    As for the software, you've gotten to the point where I can't help much without being there because it's software debugging. My best suggestion is to convert the instructions to hex instead of decimal because that is considerably easier to calculate and thus less prone to error. I'd also double-check the jump instruction to make sure you calculated the target address correctly. You could fork the A pins out to a display to help debug that, although you might have to put the clock behind a manual control to actually be able to read it.
  9. Q2DM1

    Q2DM1 New Member

    lol I converted the numbers to decimal because I sent them via the IDE's serial monitor and it seemed like it would be easier to convert let's say "124" from a string to an integer as opposed to "3E". I have done more research on the op-codes and it appears I have them correct. I also added the RAM back in and it didn't seem to affect anything. I also added LEDs to the address bus after removing the upper 4 bits (disconnected via CPU side and grounded). It's like the processor isn't trying to access the ROM correctly? It reads addresses 0 possibly, then 1 and 2 and back to 1 and then all 8 LEDs are lit. From there, it's like it doesn't care where it reads from as long as it reads from it. Addresses 0, 2, 4 and 6 contain the "ld" instructions for registers B, C, D and E while addresses 1, 3, 5 and 7 are the values to load. Should I have kept reading the book?

    I found an emulator that looks like it'll be of great help. I just wish I had $25 to pay for the license lmao. I modified the code to what the emulator runs best with. Forgetting text files (aka: Notepad), I think I should be set now. Will update once I convert these numbers back to decimal and send them, again, via serial monitor and see how it behaves.

    *EDIT 2*
    I only had to modify three lines of code. Turns out the jump instruction grabs the low byte first as opposed to the high byte. This accounted for two changes. The third change I don't recall, but the value was one-off (I think it went from 72 to 73). It still behaved erratically, so I went back to the programmer. Turns out, it has an issue I'm trying to track down. Some output pins--specifically, the ones used for the ROM's /WE and /OE--aren't staying high. So perhaps as the address/data pair sent to it changes, the data is getting corrupted.

    *EDIT 3*
    Turns out I'm just stupid and forgot I removed a ground wire on my test equipment lol. So I attempted again to re-program the EEPROM using my fixed hex file. I removed the RAM again too. But progress has been made probably because the output LEDs do light up, they change every second as designed. However, one LED doesn't light, one stays lit, and the other lights up. One second later, the next lights up. One more second and the two turn off. And then one last second and it starts over again. But, hey, it's better than nothing.
    Last edited: Sep 10, 2017
  10. Q2DM1

    Q2DM1 New Member

    Geeze it's been a while, but I finally have news. After some electrical and programming changes, I was still unable to get a working program. I used the emulator I found along with some troubleshooting tips and still ended up lost and confused. So I have LEDs on the data bus as opposed to the address bus and I used a very slow clock to match the data with what it was supposed to be and I started to notice inconsistencies. So I tore down my programmer circuit to make room for a test circuit of the EEPROM. And low and behold, the data after a few addresses were indeed wrong. So I pulled up a datasheet for a reference and programmed the EEPROM by hand by flipping individual switches, popped the EEPROM back in the circuit and now I have a computer that counts up indefinitely in increments of 5 (no overflow/carry detection).

    Somewhere my programmer circuit/coding got hecced, but at least I know that now. It upsets me that I haven't discovered this earlier. I guess it's time I go and see if I find where the problem with it lies. If anyone wants the program I wrote, just ask; I have it ready for distribution.

Share This Page