Homebrew Z80 Computer

[Alberto]

Hey all,

So for the last few weeks I have been constructing a home brew Z80 Computer from my own schematic (kind of a mash up of two schematics online that did what I wanted!). The build has 32K of ROM and 32K of RAM, with a simple 2 in 1, 2 in 4 out decoder for both the IO and memory, although at the moment the IO side is not fully connected up as I am going to use a serial interface with my Windows PC instead. I got the wiring for the serial side from Grant Searle's website where he uses the 6850 ACIA to communicate with a pc using a serial terminal. My problem is, his systems use 8K of ROM not 32K. In the Memory Map it says that ROM goes from hex address 0000 - 1FFF and RAM goes from 2000 - FFFF. Do I need to change something in the ROM hex file he provides to tell the processor that RAM actually starts at 8001?

This is the first computer I have ever hand wired so this is a learning process for me, it seems logical to me that there should be some sort of memory map stored somewhere in memory, else how does the system know where is it looking?

My only other idea is that ROM must always start at address 0000 if it is housing the main code, so that the interpreter or operating system is immediately booted.

Thanks for any help in advance!

Alberto

[Codex]

Z80 reset vector is 0000.  So you always need your start code there. 

CP/M systems including Grant's CP/M designs will boot from ROM at 0000, load some code into RAM like at D000 then disable the ROM and enable RAM in the same address space.  This allows the full 64K of address space for RAM.

Grants code does have RAM allocations at those lower address, so yes you do have to move them if you RAM starts at 8000.  It easy to do, I have done with grants code.  Only need to change a few things. He provides the source code for this reason.

>>.. . be some sort of memory map stored somewhere in memory. . .
There is no map of memory stored, it does not work that way.  You really need to read a book on Z80 architecture and understand it, Rod Zaks Programming the Z80 or something like this.   You need to read the code to work out how it works and where stuff is stored, the hardware is only half of it.   Its actually easy to read when you get the hang of it.

  Have fun, I been playing with z80s since the 80s, and have ported Grants code to a few of the Z80 systems I own and build.

[Codex]

Looks like Grant actually has a 32K with RAM starting at 8000.

QUOTE from his site:
Memory Map
0000-1FFF   8K ROM
8000-FFFF   RAM (32K) <== Modified for 32K RAM

[Alberto]

Thanks for the advice, it makes sense that you would have to start the code at 0000, easiest way to do it! I will take a look at that book, I think I came across it before but that was when I was putting together the hardware, so it didn't seem as helpful at the time.

The build has been really fun so far, I enjoyed wiring it all up and it's been a great experience learning how it all works. It's greatly expanded my knowledge already and continues to do so! As I said it's the first computer I have put together completely from scratch, so I'm encountering all of this for the first time. The Z80 seemed like a good choice because it's widely accepted as one of the simplest processors to use. I can't wait to get it running, I just want to run some code and probe it to see what's going on!

Thanks for the help, it's very much appreciated!

[tggzzz]

I got the wiring for the serial side from Grant Searle's website where he uses the 6850 ACIA to communicate with a pc using a serial terminal.

There can be subtle nasty timing problems when using 68* peripherals on Z80 busses. I can't remember the details since I last looked at them in ~1983, but hold times are probably involved.

[ali6x944]

man see this:
http://z80.info/

[Alberto]

man see this:
http://z80.info/

Discovered that site whilst I was putting together the hardware! It's awesome someone would take the time to put together that amount of information. Maybe it's just me being dumb, but I couldn't seem to find so much about programming on there! It's hard to see what your looking for when you don't know what it looks like :S

There can be subtle nasty timing problems when using 68* peripherals on Z80 busses. I can't remember the details since I last looked at them in ~1983, but hold times are probably involved.

This is the sort of thing I hope to discover when tinkering with the system, I'm only 17 at the moment (currently studying A Level's including Systems and Control, which is kind of like a mixture of electronics and mechanisms) and only really got into electronics about a year and a bit ago. The more I can learn the better! Is it something to do with the Z80 sending information when it's not requested or vica versa?

[tggzzz]

There can be subtle nasty timing problems when using 68* peripherals on Z80 busses. I can't remember the details since I last looked at them in ~1983, but hold times are probably involved.

This is the sort of thing I hope to discover when tinkering with the system, I'm only 17 at the moment (currently studying A Level's including Systems and Control, which is kind of like a mixture of electronics and mechanisms) and only really got into electronics about a year and a bit ago. The more I can learn the better! Is it something to do with the Z80 sending information when it's not requested or vica versa?

That's a good age to start with this sort of thing, and a good choice of project. You will stretch yourself, make many mistakes, and learn a lot.

When it comes to university applications, CVs and job interviews, you will be able to demonstrate that you like this subject so much that you do "more than the minimum necessary" - that puts you ahead of 95% of people. Don't hide your mistakes, but use them as a way of demonstrating that you are always looking out for better ways to do things in the future - learning from your experience is a valuable attribute. You'll also have something to talk to the interviewers about - and sometimes it is good to find anything a candidate can talk about!

As to your last question, the problem isn't about info not requested, but is about the odd few ns here and there. As I say, I can't remember the detailed problem. You'll have to look at the timing details in the data sheets.

Very briefly, with digital logic typically:

• inputs expect the data to be stable before and after an edge - the setup and hold times which will be defined in the datasheet
• outputs are only stable a certain time after an edge - the maximum and minimum propagation times, which will be defined in the data sheet

Problems arise if the max propagation time plus setup time is shorter than the time between edges. Problems arise when the minimum propagation time is less than the hold time. Normally all devices from a single "family" (e,g, Z80 or 68*) are designed with a "similar internal structure", and will fit together just nicely. OTOH, different families have different "philosophies" and that can be the source of problems like this.

The best way is to draw on paper the timing diagrams for the key signals (typically a clock, then data, r/w, cs and similar). Start at the "master" device (the processor in this case), include all the logic between the processor and end at the "slave" device (ACIA). Show the minimum propagation delay, the maximum propagation delay and realise the signals can change anywhere between the two. If you think about it, the more devices in the chain, the wider that "gap" will become. Then look at the signals when the reach the ACIA, and see whether the setup and hold times are violated; if they are then you may have more or less frequent failures.

Later on you will use simulators for much more complex circuits, but starting by doing it "the hard way" has three benefits: you won't have to fight the simulator (yet!), you'll understand what the simulator is doing (later on), and you will have learned where problems are more (and less) likely to lie.

When it comes to building something, make sure you have good solid short ground connections between all the ICs (preferably a ground plane) and that you have a decoupling capacitor next to each IC with the shortest possible leads. Failure to do that has lead to many sleepless nights and disappointments!

[ali6x944]

man i have the same problem but with a NSC800N instead, plus  I'm a noob in these stuff man!
please help if u know any thing:
https://www.eevblog.com/forum/microcontrollers/help!-how-to-make-a-nsc800-computer/

[Alberto]

Awesome! I've looked at timing diagrams on datasheets before to see the order in which code in program's need to go, but I've never looked at it that in depth before. I shall get one drawn for the system! Understanding things more deeply seems to make troubleshooting a lot easier, I find the more I learn the more quickly I can get to the source of the problem with my projects.

With the propagation, setup and hold times. I understand what you are saying about when problems arise, but why do they arise with those particular timing issues. It seems counter intuitive that problems arise when the max propagation time + setup time is shorter than the time between edges, instead of longer (the same with minimum propagation time and hold time as well).

Also, I find it extremely confusing when selecting what values of capacitor to use. I have learnt about what capacitors do in physics but this does not get translated very well to the context of electronics in school. As I understand it they are there as a method of smoothing out the current and thus the voltage level's that are going into each chip. But how do you pick the correct value of capacitor?

 

[BloodyCactus]

this is an awesome reference;

Build your own z80 by Steve Ciarcia, this is freely available on the web, so its ok to link here.

https://www.modmypi.com/download/BuildYourOwnZ80.pdf

[Alberto]

Again I shall have to give that a read, a lot to go on!

I think I have seen that before as well, might be good for reference when I want to add stuff to my system later on!

[tggzzz]

With the propagation, setup and hold times. I understand what you are saying about when problems arise, but why do they arise with those particular timing issues. It seems counter intuitive that problems arise when the max propagation time + setup time is shorter than the time between edges, instead of longer (the same with minimum propagation time and hold time as well).

Yes, it is counterintuitive, for a very simple reason: it is wrong! My idiotic mistake has been caught by someone who thought and questioned what they did not understand.

With those attitudes, you will go far

Also, I find it extremely confusing when selecting what values of capacitor to use. I have learnt about what capacitors do in physics but this does not get translated very well to the context of electronics in school. As I understand it they are there as a method of smoothing out the current and thus the voltage level's that are going into each chip. But how do you pick the correct value of capacitor?

For this application it is not critical. You want a physically small capacitor to minimise its parasitic inductance, with a large value so it can supply lots of current for a short (ns) time.  Traditionally there is a 100nF decoupling capacitor for each IC plus a 100uF capacitor for the whole board where the power enters the board.

More important than the precise values is that you have a good ground plane. If a full ground plane is not possible, then approximate it by having a complete grid of ground connections from an IC to all of its neighbours.

[Codex]

As your using Grants design, the timing issues should not be an issue, if you just copying his Z80, 6850 circuit, you should be fine. 

In his CP/M design he used a Z80SIO, for UARTs, this is more common on Z80 designs, I always use either the Z80 SIO or DART, hence never have to bother with timing issues.

You could write a very small program, just a few lines of assembly, then assemble and link it. Look at the listing file and the BIN or HEX output file and see if you manually dissemble it; this is a good way to learn how the Z80 works.  Something simple, like load a value in the accumulator then out to a port, then loop forever.  Use a meter to check the bits arrive on the port.   

[Alberto]

I was thinking about writing some assembly and putting that straight into RAM to test the computer. However, I don't understand what you mean by assemble and link it. Is this when the assembly code is converted into binary and then put together into one long string?

[tggzzz]

I was thinking about writing some assembly and putting that straight into RAM to test the computer. However, I don't understand what you mean by assemble and link it. Is this when the assembly code is converted into binary and then put together into one long string?

Assembly yes.

It is usual to split source code (assembly or otherwise) into multiple files, for convenience and separation of orthogonal parts of the code. Each file is assembled (or compiled) individually, and then the resulting binaries are combined by the linker to form a complete downloadable image. In general file A will refer to functions/data in B, but cannot know where they are located in memory. The linker has all the necessary files and information, and can "link" all the references with the functions/data.

[Alberto]

Ok, makes sense. To test the code I write can I send it serially over the UART straight into RAM? I understand that the Z80 will boot the ROM first, in the case of my system it will launch into a basic IDE (at least I think thats how you refer to it...). Is there a command in basic that points the CPU towards a specific address in memory, telling it to start reading from there?

Probing the ports might be a bit more of an issue for me when it comes to high speed stuff, I plan to implement a way of switching between a manual clock and a crystal so I can clock the CPU manually to see it going through the motions. However I don't have access to an oscilloscope, at school or at home. So when it's running at its full 4Mhz I don't know how I will probe the ports. I have an FPGA (DE0 Nano Development Board) that I have been learning Verilog with. Is there any way I can rig up a simple usb oscilloscope from that. I understand the speed of FPGA's can be an issue and you need the analog capability. But the board has a DAC, so this could be used to take the analog input. Surely as well you could analyse the digital signals with the IO. It would be great to literally just have something text based that shows the current state of the outputs and can hold at any time. Possibly could do that with a Microcontroller?

Anyway enough of my rambling...

Edit: Thought it might be good to link in the videos I made about the build! There here >> https://www.youtube.com/user/TehMaxwell

[tggzzz]

I debugged my first computer with LEDs a multimeter and switches. It was a 6800 based with 128 bytes of RAM and 16bytes of ROM.

Some devices have a minimum clock speed. Switching between manual and crystal clock is possible,but you have to ensure there are no runt pulses. That is surprisingly subtle.

[Alberto]

The programming a Z80 book is awesome! Easy to read and it makes sense! Assembly seems like a very elegant language, hardware has always been more my thing and this makes a lot of sense. I like the ability to move things around in memory and load things into specific registers, I imagine that is very powerful if in the right hands. I've never encountered a low level language before, so this has taught me a great deal.

Once part I am still confused about. Say for example I have an assembly assembler flashed onto my Z80 ROM and a serial link to a PC that I have written assembly code on, how do I send the assembly code across to the assembler? Also how does the assembler then know how to store the program in RAM? From how I understand chapter 10 in Zak's book it seems that the assembler compiles the code into machine language and then runs it. Does the ROM have data on it that tells the CPU where RAM starts, so that it can throw the program into RAM from that address?

[tggzzz]

How do load a program into memory? Simple, you use a program that receives the program, stores it in memory, and then jumps to its first instruction. This is, of course, as easy as lifting yourself up off the ground by your boot straps.

Hence the concepts of "bootstrapping the computer" using "bootloader".

Traditionally the first level bootloader was entered one instruction at a time using front panel switches. Nowadays a bootloader is often stored in flash memory or other form of ROM. That is the technique used by the Arduino.

[Brumby]

Traditionally the first level bootloader was entered one instruction at a time using front panel switches.

I had that pleasure on a DEC PDP/8 many moons ago.

Ah, the memories....

[pyromaniac4382]

I see you have already gone through the NOP run of the CPU. Great start!

As for the above questions, what I think is the easiest way to accomplish what you want to do is to first write code in assembly on your PC and then use a program on your PC called an assembler to turn this into machine code which is the string of 0's and 1's that the Z80 actually understands. We represent this machine code first in assembly language and sometimes in its boiled down hex representation. The boiled down hex representation is the result of what people call hand-assembling where you go line by line in your assembly code and translate your code into hexadecimal values using a lookup table. this is very similar to what the program does on your PC.

You then take this file and "burn" it into a ROM starting at address $0000. Now each time you power up your machine it will run this code.

How you get this code onto the ROM chip is up to you, you can purchase a universal eeprom programmer and get a supported parallel ROM chip which is a sometimes expensive route depending on what you wanted to buy. You can take the cheaper more tedious route and put in each byte of the assembled code one by one into the ROM via a circuit you could rig up with switches on the data, address, and control lines which is where the idea of hand-assembling would be useful. Following the datasheet for the chip in question you can get away with writing the bytes you need into the addresses you want. You can also find a great many people online making their own custom eeprom burners using Arduinos and RaspberryPis and etc.

The code you will write and put in ROM is the real question though. I wouldn't start with an all-out assembler as this is quite a complex program for getting something off the ground. You may want to first stick to lighting an LED via an I/O port or something along those lines to validate that everything is exactly working as you expect it to. (basically what Codex was saying above.)

Next as tggzzz was saying, after validating that you have a way to get the code onto memory and that the Z80 is executing that code as you expect you can start to make a program called a boot loader. This can take many forms, but in your current line of thinking I believe that you could write a small assembly program to read the values coming in from the serial port on your PC via that 6850 you mentioned, and then store these values one by one in a place in RAM. Your boot loader program would need to jump to the start of this RAM location and run that program you just transferred. You would require writing code to handle the 6850's initialization and read/write functions as well as writing code to place the data read from the PC into a RAM location. This is probably the most ideal way to start to get your hands dirty in assembly as you will learn a lot about low-level hardware and software interaction. 

[Alberto]

All that stuff sounds interesting, I got a big DIP switch so that I can directly enter stuff straight into RAM, I thought it might be a cool idea to make a switchable setting so that you could change whether RAM or ROM was at memory address $0000, that way if you wanted to enter stuff straight into RAM you could.

The boot loader makes a lot of sense, I never thought about writing my own but that would be an awesome project to do once the computer was up and running! I plan to initially flash a ROM with Grant Searles Basic Assembler (I think that's what it is), so that I can see if everything is working properly and also play around with BASIC a bit. Which I have never done before!

In terms of an EPROM programmer I plan to use a design I found online using an arduino, as you mentioned (Here's a link >> http://www.ichbinzustaendig.de/dev/meeprommer-en) ! I think it needs modifying to the 27xx EPROM's that I am using, but this shouldn't be too difficult. The person who wrote it has written a java GUI to help with sending the files across, although I cannot get it to launch on my windows PC. There is also a command line written in python, again I can't get this too launch! I might try it on my Raspberry Pi to see if that helps!

My USB to Serial 5v TTL Cable arrived today, the driver installed correctly so when the 6850 chip arrives I will be ready to go. The video's you see are not actually up to date, as I have made a lot of progress since then! The computer is pretty much complete, I just need to make a few more connections and add in the required capacitors and then its ready to go! It's a bit of a wirey mess, but I just treat that as being a bit more authentic!

[C]

As others have stated
Timing is very important. A logic glitch can be very hard to find.
Next to this is load on output pins & getting good logic levels to input pins.
If you look at the NMOS Z80, you should see that the clock input pin is different for example.

When you try to use chips built for a different processor family you can have problems.
Look at a Z80 SIO for example, the system clock input and M1 input. A for a different cpu the timing will probably be different. In fact note that Zlog has a 4mhz SIO & a 6mhz SIO. Strong hint that a slower SIO will have problems doing everything properly connected where a faster SIO version is needed.
Next why do these pins exist?   
What other CPU's will look the same to a SIO?

The 6850 is a part for a different CPU line. Pin 14 the (E) signal is a signal from a 6800 0r 6809.
What all is this used for inside the chip?

When you use a chip outside it's specifications, you are entering the UNKNOWN on what will break, work or work part of the time.

Here is a simple test for your design
A good computer can send and receive data.
In the video you have parallel inputs and outputs on connectors

Can your Z80 computer say "HELLO" to a second copy of your Z80 computer as you have it now?
Connect the inputs of one computer to outputs of the other.
Note this is not the same as just connecting the outputs to the inputs on one computer. The second computer could be running at a different speed and/or doing other things.

[Alberto]

The whole chip family thing is something I never really considered before in terms of timing, the posts here have definitely taught me a lot about that! I may struggle to do that test as I don't have another built computer to link my original one up to :S. Also I don't currently have the parallel register chips wired up to the CPU. I decided that I would wire the data bus and any other necessary signals up to one of the horizontal headers, that way I could but in the Serial Communications chip, as well as have room for more expansion later on. Buffering both of those headers wouldn't have limited me as far as I can tell, but it seemed a bit unnecessary and I wanted to put the serial chip in as I liked the idea of communicating with another PC.

Really shooting right into the future here, but I thought I might ask about it anyway whilst it crossed my mind. Because I have an FPGA I wondered if it would be possible to replicate an early graphics processing chip for the Z80? Obviously as far as I know if you know what your doing and it fits in the number of gates your FPGA has then you can do anything, but has anyone actually done this before? I think the custom chip for the ZX spektrum has been done before, but are there any others?

[C]

"HELLO" test
Use what is between your ears.
You have your drawing, that is all you need except to think.

To make it easer for you
Computer One is running at a 4Mhz clock.
Computer Two is running at a 1Mhz clock.

When you understand what happens above then switch the clocks and look again.

Then do what some leave out. Think of what will happen as the clocks get closer to the same speed.

You want to build a computer that works all the time. Trying to find a glitch is a working computer is very hard. It is much easer if you think before you build.

[Alberto]

Okie dokie!

A nice thought experiment for the weekend! Do you think it might be a good idea to print out the schematic and write on the printout showing how the bits move through?

[C]

Hello
You are thinking too low level now.
You should have done the low level thinking when you designed in the I/O.

Keep it simple
Output data and then input data.

Should take less then to read these two posts

The cheapest video and easiest video would probably be to use something like a raspberry PI.

All most all I/O you would want for a Z80 can be done cheaper and easer by using a micro controller as a slave of the Z80.

Back in the 80's, you might have your Z80 computer talking to the hard drive controller in a very expensive system. Some of the hard drive controllers had a Z80 on board.
The Z80 interface to the hard drive controller was not limited to ONE.
The same interface could talk to other Z80's and many other things.
Was very complicated interface.
Two 8-bit output ports & two 8-bit input ports for unlimited I/O.
Very Very simple.

So the simple question
Can you program a micro controller?
If you can then everything just got cheaper, easer, faster and expands greater.

[Alberto]

Hmm ok just got my brain in gear, very tired today!

As far as I can tell two computers running at different speeds would be able to communicate through the 8 bit data ports. Both of the ports are buffered, so if one computer sent some information output register it would sit there until the other computer made an read IO request and loaded the information into it's input buffer. That information can be then dealt with by the other computer at it's own speed. Internally both computers could operate at their own speeds, but when communicating one might have to wait for the other to reply slightly more slowly. However I imagine this is much the same even with modern hardware.

[C]

The output in your video is too simple
How would the reading computer know the difference between the first "L" in hello and the second?

With a fast sender and a slow receiver, the receiver would see "O"
Switch this and "HHHHHHHHHHHHHHHHHHHHEEEEEEEEEEEEEEEEEELLLLLLLLLLLLLLLLLLLLLLLL"

Your ports in the video work fine for LED's but not much else.

With a micro controller you would fix this with extra bits on ports and more software.
For a micro computer like the Z80 you want the fix in hardware so it is fast and easy.

The modern hardware has more then just the 8-bits of data on an output port.
One simple signal to add would be "I Just Wrote new data to this output port"
Now you just need to know when the other computer has the data.

The reading computer when it sees "I Just Wrote new data to this output port"
knows to read the input port and then say "I got IT"

You need a status port that the Z80 can read and a FF on each computer.
 

[C]

For input/output ports you often need more

You can do it in logic chips
If it is a common need then someone will make a chip

here is one by national semiconductor
http://elektronik-lavpris.dk/files/sup7/131555dp8212.pdf

Look at page 6
Note:
 that it's just logic
 that it works as an input or as an output port and adds some logic to make it more widely used.
Will work with out programming the chip.

So page 6's logic could be more then you need at times or not enough for a simple port.


Then you get into the even more fancy that requires the CPU(Z80) to configure the chip before it can be used
Intel 8255
https://en.wikipedia.org/wiki/Intel_8255


The next step up is a chip special for Z80
Z80 PIO
The PIO makes it easy to use the Z80's vector interrupt mode.

And if you may find a chip that does everything the PIO does but not Z80 specific.

[Alberto]

Hmm ok, this makes sense. I didn't think about the fact that the faster computer would just keep churning out information which would cause problems with the slower computer, or vica versa. I also see what you means with modern hardware, a wider bus means more information!

I can program a Microcontroller and have quite a bit of experience with Arduino, I could program it to handle the IO fairly easily, as long as I fully worked out myself exactly what the hardware was doing and how the Arduino would have to match it to integrate properly into the system.

My only thought about this is that it seems like a bit of a cheat to me, pairing a modern microprocessor/microcontroller with an older piece of hardware seems like it kind of defeats the point. Yes you want to build a retro system, but you have some much more capable hardware sat there doing all the complicated stuff. I want to learn more about hardware with this stuff, and although the microcontroller route is cheap and very accessible, I feel like I would learn a lot more by finding other ways to do things. To be honest, I will probably do both!

[AlxDroidDev]

The next step up is a chip special for Z80
Z80 PIO
The PIO makes it easy to use the Z80's vector interrupt mode.

And if you may find a chip that does everything the PIO does but not Z80 specific.

Check out Zilog's Z84C20 and Z84C90

[C]

Check out Zilog's Z84C20 and Z84C90

Both chips are Z80 specific and work only up to a specific Z80 clock speed.

Check out the Z80C30/Z85C3
http://www.mouser.com/ds/2/450/ps0117-21818.pdf
Any processor and I think higher speed

[Alberto]

Awesome! Thanks for the links, I will make sure to keep those handy for when I implement this into the system. I was thinking of going kind of modular and making lots of boards that you could mix and match. Any ideas what are good things to start with in terms of inputs and outputs for the Z80, I thought adding a real time clock might be a really nice idea.

[C]

Do you have a serial printer or a serial terminal?
Do you have an old video monitor?
If not then are you cheating when you connect to a PC?
 What is the difference of cheating with a USB to serial adapter that talks to a serial port hardware on Z80
vs
using your Arduino as what looks like the serial port hardware to Z80.
When you are done you have the Z80 console showing on PC for both.

Using a computer to get a new computer working is much easer and faster then from scratch. Some of the big computers use a small micro computer to get them started an is a fixed part of the big computer.

Think of it this way, with a micro controller you can get the Z80 working.
A little program change on both and you have new virtual hardware at very little cost.
You still learn on Z80 side.
Then you can build what you want on Z80 side to learn more.

If you have a good simple interface from micro controller to Z80 and think a little ahead, you could have one or more of the classic computers connected.

So simple is better if the simple lets you expand as far as you want.

A USB micro controller with some software changes could add the printer connection also.
Some more software changes and you have mass storage.
An old CP/M operating system Z80 could have two serial ports and mass storage.
One serial port was console, one the printer. 

With this much in place it is much easer to do more, learn more.
With CP/M working you have many languages and tools to work with hardware.

By using new parts the old classic becomes better and cheaper.

When all is said and done a serial port to the Z80 is a few I/O ports
The same is true of the fancy parallel I/O chips.

The proper program on a Arduino and a cable would let one of my old fast Z80 computers boot via the Arduino using it's existing 512 byte boot program. The Arduino would be acting like the old hard drive. Arduino would be slower while with a faster micro controller could be faster then old drive. 

Z80 Parallel port
8-bit data port: For Z80 it will be output or input.
When you put new data on output port, you need a signal to tell receiver there is "new data".
For Arduino you would use a pin on a port using software.
For Z80 you can use the signal that put the data on the port,
For printers you time stretch this signal with a One-shot.
For other parallel use you save the signal using a FF. The output of this FF goes to input port of other computer.
The status of the FF normally shows in a Status input port for Z80.
The output status port which is an input port to Z80 is used to handle the output port.
The Z80 uses status port to slow the data rate and look at status of receiver of the data.
 
For an Input port
8-bits of data
Status outputs & status inputs.
One of the status input bits is "new data".
One status output is busy which shows in the senders  status port.
One of the status output bits is "have read new data". Again making hardware do the work, reading the input port could generate this signal. Signal could clear the FF of the sender.

The chips I listed are for 8-bits. One easy thing to do if you are using logic is to go wider then 8-bits. If Z80 can write to 8-bit output port using two addresses, then the address line can be used as a 9th data bit.
Smart use of the 9th bit is to allow sending 8 bits of data or 8 bits of control data.
An input port can then read the 9th bit from the status port.

Note that this setup allows sending many bytes of data as control data. The amount is a software function yet it is separate from the raw data bytes.

The control bytes could specify what the Arduino is to do.
Write following data to console window
Read Arduino data received from console
Read/write program or data to storage.
read real time clock
Sky is the limit.

 

[Alberto]

You make an extremely good argument, It definitely looks like a better line to take, as long as I can still incorporate the older hardware as well along they way. I would like to look at the PIO and other chips, although I am sure that is possible with a modular system and different ROMs to accommodate for the changes in hardware. I think I will go down the microcontroller route as it is definitely more accessible to me in the near future. Using specific hardware does have the added pain of costing more money! Also the microcontroller would allow me to use newer hardware that can access an I2C Bus for example.

Also you make a good point, that using a usb cable and a windows computer as a serial monitor is also a cheat. Building something completely old school is something I would like to do in the future, but from a learning stand point it's probably not the best route. It would take me quite a while to expand things with specific hardware, which I don't really have the time for, especially with exams coming up. Also it will let me learn about communication between two different processors, which has always been rather intriguing to me.

Nope, I concede, the micro is the logical step.

[C]

Ok dumb and simple
No fancy chips on Z80 side
Two 8-bit ports on micro controller side with one port able to change direction.
You have a speed difference
  logic is fast while a micro controller being logic is slowwer

Using open collector drivers on a buss is a way of allowing more then one device to talk on a buss with no time schedule problems. This Wired-OR logic lets the low level win.

Z80 data bus to input of A 273 latch(output port) with outputs going to 7406 open collector drivers to the I/O buss.
From I/O buss a 240(input port) to z80 data buss

one set for data and a second set for status & control.
The 273 is used here so that a signal on the buss can turn off other devices outputs, a reset signal.
one additional FF can make software faster on Z80

Problem:
 the AVR and a lot of micro controllers do not do Open Collector on ports.
Changing this to tri-state outputs loses some capabilities while being less parts.
For example "data available" is one signal to every one on the buss even when the direction of buss changes. Multi-receivers with each slowing the data rate and many others.
So tri-state loses capabilities but is what is needed for Arduino

A tristate version
Z80 data bus to input of A 373 latch(output port) with outputs to the I/O buss.
From I/O buss a 240(input port) to z80 data buss
one set for data and a second set for status & control.
one additional FF can make software faster on Z80

Now the Arduino needs to control the outputs to the I/O buss as logic is too fast for Arduino.
Some Z80 outputs the Arduino needs to see all the time and some like the data buss part I/O buss the Arduino must control.
Aduino controls Oc of Z80 data buss 373 ("data direction").
By using two wires and crossing, one bidirectional wire(signal) becomes two one direction wires(signals). 
Two wires cross for "New data" to have "New data out" and "New data in"
Two wires cross for "New Data Ack" to have "New data out Ack" and "New data in Ack"
Two wires cross for "Command/Data" to have "Command/Data out" and "Command/Data in"


Arduino's first port:(data)
8-bits of data connected to data input (244) & data output(373) port of Z80

Arduino's second port(status/control)
0. Buss direction (To Z80 output data output latch OE)
1. "New data out"
2. "New data in Ack"
3. "Command/Data out"

4. " "New data in"
5. "New data out Ack"
6. "Command/Data in"
7. free for now
Note: 0 - 3 are outputs all the time for Arduino and input only to Z80
4-6 are input all the time for Arduno and output & input to Z80


Z80 side
Z80 Data out(373):
outputs To Z80 data in port & to port 1 of Arduino

Z80 Control out(373)
All outputs connect to Z80 status input
Only pins listed in Arduino's second port connected to Arduino.

Z80 Status input(244)
 as above
Z80 data in(244)
as above
A FF or two with a little logic makes Z80 side much better.
Use two Z80 addresses for the data in & data out so that A0's state does not matter.
A future speed up mod can use this.

Could be an error in above

Note that each side can say new data available and the other side can say got it.
Both can identify what is data data and what is command data. This is what makes software expansion easy while at same time software simpler.

[Alberto]

Awesome, you guys are definitely great at pointing me in the right direction! Once this section of the build is done I will try to but together a schematic of what is described above, it will be good to work it all out for myself as that is something I am yet to completely do in this project!

Speaking of working things out for myself, I am still having trouble launching the software that goes with the Arduino EPROM programmer that I found, so I've decided to make one myself instead. It will be a great learning process and I'd imagine a fairly useful skill for the future. I don't think I will have any issues with constructing the hardware, as I am going to do what a lot of people have done online and use two 74HC595 Shift Registers to control the address BUS. I have used these Shift Registers before and understand how they operate, so it shouldn't be hard for me to connect everything up properly. One of my Arduino Micro's definitely has enough IO for the programmer, so no issues there either.

I've learnt a bit about Hex Editors so that I can look at Grant's ROM file, from what I understand all I need to do is write some code that will control the shift registers to cycle through the ROM addresses, as well as some code that will send each byte of data to the correct address. In other words:

• Initialise Arduino
  Starting at address 00000000 take data from hex file for that address and put it onto the data bus
  increment the address by one and then repeat previous step

As far as I understand as long as I am controlling the the enable pins on the ROM chip correctly I can just throw each byte into memory one at a time. I read a post online that talked about physically storing the hex file in the Arduino's RAM. The AVR Chips have 32K of Memory and I will probably never fill my 32K RAM Chip, so I can just put the file straight into RAM as an array and read it from there, instead of reading it from an external memory source!

Can anyone see any problems with this plan?

[C]

eprom programmer
Sounds good
You might want to check out your eprom programmer using a ram chip.

Good idea when programming like this is to program the chip and then read the chip to see if programming is correct.

You should know that some Z80 computers had no rom's. On power up the Z80 reset line was held and a second computer loaded a program in ram. This second computer then released the Z80's reset and Z80 started reading program from ram starting at address 0.

 
Grant's ROM file
Note that if the hardware changes, this could require program changes.
Better look at the program to see if it needs some changes.

[Alberto]

I'm fairly sure that the ROM file should be ok, as his site has a memory map that corresponds with mine. I need to check if the memory decoding is the same, although I'm pretty sure it must be if the memory map is the same as mine.

In other news I made another video showing progress, this will show you the computer as it is now >>

[Alberto]

Ok, an update on the EPROM programmer. I have started to write the code, however I have hit my first issue. I was just going to put the code into the arduino file as an array in a list format so that I could access the individual values in the list, each one being a byte of information. All that would be left is to increment the value of the address counter by one, take the value from the array that corresponds to that address and write it to the data bus in binary.

My issue is, how can I put the hex file into the arduino code in this way? I can't find a suitable method apart from copying and pasting it, and then entering a comma between all of the values! :S

[Markybhoy]

Alberto although not Z80 releated you might be interested in this free course -

Build a Modern Computer from First Principles: From Nand to Tetris

https://www.coursera.org/learn/build-a-computer

[rrinker]

 Use code to write code? You can create a .INO file using a text editor, by extension with anything that can write a text file. Or you could just read the .hex, format it with the required keywords and whatnot, save t as a text file, and then copy/paste into the IDE. If you're using Windows, I'd probably cook up a quick Powershells script to generate the code.

[C]

A good programmer can

Program a chip, read a chip & verify a program on a chip.
For an EPROM and some other chip types you need a verify blank chip function.

One common format for chip data is INTEL HEX format, there are other formats.

The program on the arduino would not change with each change in programming data for the chip to be programmed.

For a chip read the arduino would read the binary contained in the chip and output the data in INTEL HEX format to the console output.

For a chip write INTEL HEX format data to console input, arduino converts HEX to binary value and puts binary value in chip.

For a chip Verify INTEL HEX format data to console input, arduino converts HEX to binary and compares HEX binary value to binary value in chip. Arduino would output to console output "Match" or output locations that do not match.

The small memory Arduino can then work with hex files larger then then the Arduino has memory.

Note that INTEL HEX format has location data and might not be in order.
Most terminal programs on PC's allow sending text files & recording console output as a text file.

[Alberto]

Ok, an update on the programmer!

Everything is going according to plan at the moment, as you guys previously suggested I have written a sort of handler that deals with the hex files. This runs on a raspberry pi. It takes the hex file, which is viewed by the Pi in ASCII, and sends it byte by byte over the serial port (in this case a USB Connection to an Arduino!). The firmware on the Arduino takes this data and converts it to binary. At the moment that's as far as I have got!

The plan is to pair an individual IO pin with each bit from the 8 bit byte. I will then write some code that controls the 74HC595 Shift Registers to set the correct address on the address BUS. It's going really well so far, and I thank you for your advice!

If you guys want I will release the code afterwards so that others can use it. Theoretically it can handle a hex file of any size as long as you want to send it on a parallel BUS. Although I am sure you could modify the firmware to use SPI and I2C as well.