Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Micro-controller <-> Z80 interface?

Status
Not open for further replies.

thundercat636

New Member
Hi everyone,

I am basically pretty new to the whole electronics/digital electronics thing, so please assume a pretty low level of knowledge.

I am looking to improve the interface I have between my micro-controller and Z80 SBC, which can run at 4 or 8 MHz. Currently, I am using a two-wire serial interface with no control from an ATmega328 Nano to my Z80's SIO/2 chip to allow commands and basic data transfer between the Z80 and micro-controller.

I want to move my system on from breadboard to a more stable PCB design now and am taking the opportunity to look into improving the interface and (hopefully) freeing up the serial port on the SIO/2 for other uses by creating a dedicated interface between the micro-controller and Z80.

I am by no means limited to using the '328 Nano - in fact I don't intend to use it for the PCB version; my options are open so I am considering an ATmega2560, PIC (16F?) or even an STM32F103.

However, what I can't do is decide upon an efficient method of interface any of these micro-controllers with the Z80 other than through the standard serial interface, which I'd rather not use for reasons stated previously. So, I'm asking for suggestions (and perhaps even a bit of a leg-up in the design!) on a replacement interface.

I'm going for simplicity (of design and software to run it) over speed.

Here's what I've considered so far:

1) I2C/SPI
This has serious benefits in many areas, as just about every micro-controller supports I2C/SPI and libraries for the micro-controllers are readily available. Implementing the bus at the Z80 end is what holds me back from going for this method. I don't want to bit-bang an I2C or SPI interface on the Z80, but I do have some MCP23017s and MCP23S17s lying around - maybe I could use one of those with some supporting logic chips?

I'm guessing that I'd need a fast flip flop to catch the IO read or write from the Z80 and trigger the MCP23017 to capture the byte on the data bus so the micro-controller can read it whilst holding WAIT low to stop the Z80 from rushing on to the next command?

I'd also need a way of getting the micro-controller to tell the Z80 that it has data to return to it - perhaps hold the INT line low and supply a vector on the data bus (I'm using Interrupt Mode 2) to call the 'data receive' routine on the Z80?

2) I2C/SPI with DMA
As above, but with the micro-controller having access to the 16-bit address bus, BUSACK and BUSREQ as well so it can write data directly to the Z80's memory. This could replace the micro-controller having to tell the Z80 it has data to return - it could just write it to memory and set a flag in a protected section of memory that the Z80 periodically checks on. This will require another 8-bit latch and a load more micro-controller IO pins (unless I use another MCP23017?) It is desirable, however, as it provides another level of flexibility for the micro-controller.

3) Bespoke interface
Some custom-built 2-way interface of a design I haven't yet thought about or am aware could exist.

4) Give up and stick with the serial interface
This is what I'm faced with at the moment. My electronics skills aren't up to building options 1, 2 or 3 above from scratch - hence this post - I might have a rough idea of what is required, but the specifics elude me.

So, I'd be especially grateful for any help and guidance you're willing to provide. I do best with pictures and diagrams and learn from examples much better than anything else, so if there's a solution to this out there already that I have somehow missed during my Googling, please let me know! And thanks. :)
 
It really depends how much data you're transferring, and how fast you need to do it - personally I'd stick with a serial interface, using software serial if required.

However, why are you using two processors anyway?, couldn't you just replace the SBC with a micro-controller, which should easily out perform the Z80 SBC.
 
It really depends how much data you're transferring, and how fast you need to do it - personally I'd stick with a serial interface, using software serial if required.

However, why are you using two processors anyway?, couldn't you just replace the SBC with a micro-controller, which should easily out perform the Z80 SBC.

It's a hobby project. The Z80 has sentimental significance to me in that it powered the first computer I ever had and I'm learning a lot about (digital) electronics by building my own system with one. Yes, I know micro-controllers are orders of magnitude more powerful, but I want to build a system from scratch using (mostly) tech from the 80's and improve on it a little if I can. The micro-controller was added to the system originally to provide a software-switchable system clock, but now also provides an RTC and potentially more via its I2C and SPI interfaces.

In terms of speed, I'm infrequently transferring a series of ASCII bytes between the two processors at 19200 baud, with no more than about 30 characters in the longest string - hence why I haven't bothered with flow control.

I'm going to need the serial port on the SIO for a future expansion, so sticking with serial for the micro-controller means I'll have to add in another UART/SIO for the Z80 which is something I'd like to avoid if possible.
 
Hi TC636 . My indulgence in Z80 nostalgia … Having “played “ with Z80 in the 1980's I had the idea now that an mcu could be like a PICkit3 to a vintage Z80 system , the result , its not final by any means and I'm probably not taking it any further , just an interesting exercise.

z80pic.jpg
The concept hinges on the Z80 M1 fetch cycle , after a reset is released , the first memory request is at h'0000 , if a WAIT is instigated at this point processing is paused. the attached PIC18F45k22 ( other mcu s are available ) can do what it likes with the Z80 's memory location.. read / write / verify... after this pause, the Z80 bus is loaded with h'00 the RD and WR are inhibited from the memory, and the WAIT released, Z80 “sees” NOP and increments address and starts another M1 cycle , PIC detects again and the cycle continues reading / writing up to the memory limit . Timing is the crucial part, the PIC needs a faster instruction time than the Z80 clock, so with a 10Mhz Z80 device I had to run the PIC at 64Mhz, 16MIPS. Following the Z80 addresses would appear to be a weakish part of the design as PIC assumes address have incremented , connecting to all 16 addresses I think would make the system over engineered , so just A0 is monitored to check its 0,1,0,1,0,1,0... progress.

Possible things for the PIC to do would be clear , fill , dump , load ,verify Z80 memory from either an external input or a file from a storage device. With a little clever coding a single step function could be implemented , I was also thinking Z80 could use the PIC as an IO device while in run mode. The PIC C code , so far can read / write up to the 32k of my Z80 test bed with EEPROM as storage. I have not taken this further , perhaps another day...
PICz80.jpg


TERM1.jpg
 
In terms of speed, I'm infrequently transferring a series of ASCII bytes between the two processors at 19200 baud, with no more than about 30 characters in the longest string - hence why I haven't bothered with flow control.

Personally I've never used flow control, and usually stick to 9600 baud, which is nice and easy to do even in software.

I don't know if you were aware? (as you're obviously a Z80 person), but the 6502 based VIC20 from a similar era used a software serial port - supposedly because they couldn't afford to add a hardware one. So you could do the same, or add a second hardware one.
 
Yeah, my '328 runs at 16 MHz so it's not quick enough to detect a change on an IO line and read the data bus to get an IO 'OUT' instruction, for example. I've got an STM32F103 that I'm testing (well, have been testing some time ago - need to get it back out again) as a replacement, but I'm considering using a 74LS74 or similar flip flop to drop the WAIT line low when an IO select is triggered, allowing the '328 (or whatever micro-controller I'm using at the time) to pick up the interrupt and read the data bus in its own sweet time before resetting the flip flop again.

I could send a whole sequence of bytes this way, with a terminator at the end so the micro-controller knows the entire sequence has been received and it can start acting upon it. I guess then it's just a case of returning the data and for that I'm considering the DMA-route. It'd be handy for the micro-controller to have DMA access to the SRAM anyway. Part of the instruction/request sequence from the Z80 could include a return memory address (as it does now via the serial interface, except the Z80 writes the returned data to that location via an Interrupt Service Routine) and when the micro-controller has done what it needs to do, if it needs to return any data to the Z80 it could pull BUSREQ low via an IO pin, wait for BUSACK to go low (another IO pin with an interrupt on it perhaps or just continuously sample the IO pin until it goes low) then set the target memory address on the address bus using an MCP23017 (I2C 16-bit IO expander) and output the data onto the Z80's data bus via an MCP23008 (I2C 8-bit IO expander).

In fact, the micro-controller could read/write both the Z80's data bus AND address bus with those two chips on an I2C connection, with a couple of flip flops and extra IO ports for BUSACK, BUSREQ and to reset the WAIT flip flop...?

Thing is, would this work with timings etc? This is my weakest area I think - the above sounds good but can I pull WAIT low in time to read the data bus etc?

Hi TC636 . My indulgence in Z80 nostalgia … Having “played “ with Z80 in the 1980's I had the idea now that an mcu could be like a PICkit3 to a vintage Z80 system , the result , its not final by any means and I'm probably not taking it any further , just an interesting exercise.

Possible things for the PIC to do would be clear , fill , dump , load ,verify Z80 memory from either an external input or a file from a storage device. With a little clever coding a single step function could be implemented , I was also thinking Z80 could use the PIC as an IO device while in run mode. The PIC C code , so far can read / write up to the 32k of my Z80 test bed with EEPROM as storage. I have not taken this further , perhaps another day...

Thanks for that, granddad - it's good to see that it can be done (albeit with a much faster clock speed). I didn't mention at the start, but my system could potentially work with a number of different micro-controllers, or that's what I'm aiming for anyway, so I think the flip flop/s and IO expanders are important additions to ensure that any micro-controller, whatever its GPIO count or clockspeed is, will work.

I'm not sure the DMA route to return data is necessarily the best, but it certainly seems to be the simplest in terms of software AND hardware where anything more than transferring a single byte is required.
 
I don't know if you were aware? (as you're obviously a Z80 person), but the 6502 based VIC20 from a similar era used a software serial port - supposedly because they couldn't afford to add a hardware one. So you could do the same, or add a second hardware one.

I don't want to big-bang a serial port for performance reasons (not to mention software complexity - I'm no expert at Z80 assembly) and adding another hardware serial port has cost and space implications, hence why I'm exploring other options for the interface.

I do feel as though I'm leaning towards the solution mentioned above, though, with the MCP23017, MCP23008 and flip flop combination. It seems to offer the best of everything (except perhaps performance, but I'm dealing with an 8 MHz 80's CPU here) and if I add in another signal line for Clear To Send I wouldn't even need to bother with a terminator character, I could send whatever data I wanted. That is, unless there's an obvious problem with this set up that I'm unaware of with my lack of experience?
 
Hi TC , the port expanders design sound good on paper, however I think you may run into speed issues , I2C gets a little 'tight' above 400khz , a fast PIC with at least 24 IO for address and bus + control would keep up with a 10Mhz Z80 ...
Not sure , what is this Z80 interface doing ?
 
Not sure , what is this Z80 interface doing ?

It takes commands from the Z80 software and performs functions like resetting the system, setting the system clock speed and passing the date/time from the RTC. With a more versatile connection I could look at interfacing storage or even a PC via the micro-controller.

Okay, so I2C may not be up to snuff - how about SPI? The MCP23S17/S08 have SPI interfaces...? The reason I'm looking at IO expanders is because of the versatility they offer in terms of what micro-controller I might use. For the bigger micro-controllers with more GPIOs, I'm looking at SMD components with dozens, if not hundreds, of pins. My SMD soldering skills are non-existent at the moment (though I'm looking to start building them up, just not quite that quickly..) ;)
 
Okay, so I just need to bite the bullet and get some practice in soldering SMD components.... It's been a long time coming, but I guess I now have a big reason to get my toes wet. So I'll need a minimum of about 30 GPIO pins (16 address, 8 data and a handful for control signals).

I can still use a flip flop to hold WAIT low while the micro-controller samples the data bus, so clock speed isn't critical, but another concern with using SMD micro-controllers (and I don't profess to know much about them at all) is that most (if not all, for all I know) are 3.3V... My Z80 system is 5V and I could do without the extra hassle of level converters on the buses and control lines to the micro-controller. I'll have to go take a look at the options..
 
I admit I am a 'fanboy' for PIC24, so 'perhaps' look at PIC24FV32KA304 44 pin , 38 IO .. and 5v . I put them on a TQFP 44 pin break out board.. flip flops are good :) some PICs have an SR latch IO
 
1) Use Dual Port RAM?

2) Some other kind of DMA connection?

On my Z80 system, I went ROM-less and use a PIC to load and save from the Z80 RAM. In simple terms, the PIC will do a bus request from the Z80 and then read or write the entire 64K of RAM. It then releases the bus back to the Z80. A tiny bit more detail here: https://modernretroz80.blogspot.com/
 
Hmm... okay, so I'm seriously warming to the idea of SMD parts... and the two PICs you've mentioned look very promising - especially when I can see the schematics too for some obvious clues and guidance on how to put a working system together. Thanks for that, Spudboy488 !

I see you're using two latches to hang the 16-bit address on, all driven from 8 'data' IO ports - that's pretty much exactly what I was looking to do, so I didn't have to start looking at micro-processors with 32+ IO ports. The USB setup for the programmer is also interesting - I don't know anything about the MCP2200 - I'm using an FT232RL adaptor module to connect my Z80 up to a PC terminal over USB currently; would be nice to have my own USB-TTL circuit on the PCB, instead of an adaptor module.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top