| Electronics > Beginners |
| Z80 Data, Address & Control signal buffering/driving design. Is this design ok? |
| (1/3) > >> |
| castingflame:
I wish to design a better way of connecting to my Z80 based machines to enable me to play around with the Z80 in a much safer way. Additionally, I will be using ribbon cables from each machine to my breadboard. My idea is to have a small PCB on the port of my machine with, the circuit show below, to introduce buffers to help 'drive' the signal over the ribbon cable and to create some safety margin from killing my machine (again!). This is what I have come up with so far ... I may well use HCT instead of LS because of the lower power consumption but not sure why else it is a good or bad idea with that one. What do you think? |
| TomS_:
You're going to need to change the LS32 (OR) to an 08 (AND), since you can't be doing both IORQ and MREQ at the same time, so the output would always be high and never enable the buffer for the data bus. Other concerns will be around additional delays introduced by the buffers, and whether that will present issues for any existing logic. If this is an older retro style computer system that shares memory between CPU and video for example, will your timing still be valid with another 10ns of delay added in. Perhaps adding a pull down resistor pack between the Z80 and data buffer so that those pins are never floating when everything is tri-stated would be a good idea. Otherwise ... The only other thing I can think of is what issues you are trying to protect against by fully buffering the CPU? |
| TomS_:
Also, you may also want to reverse the direction of some of the signals you are buffering, so that they can be manipulated from your breadboard. Or maybe dont buffer them at all and use an open collector/drain type interface to control them. e.g. the RESET, BUSRQ, INT, NMI and WAIT signals are all inputs to the Z80 which you can interact with from an external board. e.g. you may want to pull WAIT low while a peripheral does something, or you may want to generate an interrupt, or may want to pull BUSRQ low so that you can take over the bus. But in particular for the latter to happen, you'll also need to reverse the direction of the address bus and also the data bus buffer which will require a bit more logic to achieve. I guess it depends what you want to do from your breadboard. |
| Ian.M:
Your data bus buffer absolutely will not work, even with TomS's proposed change. You can do that sort of thing with a bare Z80, but if its in a system with any RAM, ROM, or I/O on the CPU side of the buffer, it will cause bus contention. You need to decode the memory or I/O address range for your breadboard, which *MUST* *NOT* clash with any used address range on the CPU side, and, during read cycles gate the buffer enable with the decoded address. If you don't get the access timing exact or make a mistake with the memory decoding, and are using 74HC/HCT logic, 330R resistors in series with all the databus lines on the CPU side will prevent bus contention causing any physical damage. |
| castingflame:
Firstly thank you for answering, it gave me plenty more things to think about. I will do a point by point response in hope to keep things clear (for mainly my benefit). Initial Requirements [After reading your comments] Initially I want something that will enable me to use my ZX Spectrum for port I/O. I will need access to the full address bus for 16bit address decoding. I am aware that normally only the lower 8 bits of the address bus is used but the spectrum does have the ability to address/and uses the full 16bit addresses in some hardware. I will not be adding anything like RAM or ROM etc just port I/O. --- Quote ---You're going to need to change the LS32 (OR) to an 08 (AND), since you can't be doing both IORQ and MREQ at the same time, so the output would always be high and never enable the buffer for the data bus. --- End quote --- If I am only concerned with IO, can I get away with just IORQ as a CS for the data bus buffer? --- Quote ---Other concerns will be around additional delays introduced by the buffers, and whether that will present issues for any existing logic. If this is an older retro style computer system that shares memory between CPU and video for example, will your timing still be valid with another 10ns of delay added in --- End quote --- I understand what you are saying but if I just stick with port I/O will this be a problem? --- Quote ---Perhaps adding a pull down resistor pack between the Z80 and data buffer so that those pins are never floating when everything is tri-stated would be a good idea. Otherwise ... The only other thing I can think of is what issues you are trying to protect against by fully buffering the CPU? --- End quote --- I want to use some LEDs on address, data & control lines. I understand they are fast but I will also use this for single stepping another project. With that in mind I was going to just put the LEDs on the other side of a buffer on their own but as I am using a ribbon cable from the Speccy I thought it would be a good idea to put them on the other end on the cable next to the Speccy to help drive the signal across the ribbon cable and provide enough current and isolation from directly connecting my 'self educating' rough designs directly to my Speccy. If I got things stupidly wrong for some reason (again!) the buffer should protect the Speccy. That was my idea. Is this reasonable or stupid?! --- Quote ---... you'll also need to reverse the direction of the address bus and also the data bus buffer which will require a bit more logic to achieve. I guess it depends what you want to do from your breadboard. --- End quote --- I believed that my RD on my Data Bus buffer, when 'inactive,' was supposed to indicate a WR. Thinking about it more I will need to bring WR to that pin with some additional logic too so the pin is actively changed to 1 to change direction of the buffer. I'll redesign. Will this basic design need a bi-directional address bus as I will only be using the address bus for decoding and not placing anything on it for other ICs to read? --- Quote ---Also, you may also want to reverse the direction of some of the signals you are buffering, so that they can be manipulated from your breadboard. Or maybe dont buffer them at all and use an open collector/drain type interface to control them. --- End quote --- I'll look into that. Any suggestions? --- Quote --- Your data bus buffer absolutely will not work, even with TomS's proposed change. You can do that sort of thing with a bare Z80, but if its in a system with any RAM, ROM, or I/O on the CPU side of the buffer, it will cause bus contention. You need to decode the memory or I/O address range for your breadboard, which *MUST* *NOT* clash with any used address range on the CPU side, and, during read cycles gate the buffer enable with the decoded address. If you don't get the access timing exact or make a mistake with the memory decoding, and are using 74HC/HCT logic, 330R resistors in series with all the data bus lines on the CPU side will prevent bus contention causing any physical damage. --- End quote --- As stated above I was going to just use port IO. Is there any reason why I can not put my decoding on my breadboard, downstream of the buffer? Nothing will be put on the data bus until all the correct address and control signal decoding is done, say with a 74LS138. It will not be the 138 but it is an example. As for I/O addresses, I know what I can and can not use, so that is not a problem. I have that bit mapped out. 330R resistors sounds like a very good idea. Will they go in front of the buffers? I will spend some more time in the morning updating the schematic. I will include the decoding to see if it is correct. TomS_ & Ian.M I really appreciate you help. As you can tell, I am still learning. :-+ |
| Navigation |
| Message Index |
| Next page |