z80 Experimentation Kit

Since the last log I’ve mostly finished the AVR code for loading data into the EEPROM. Then things slowed down a lot. Firstly, I wanted to build some of the circuit on strip board however the piece of strip board I have is a bit too small and it’s a very tedious design to prototype this way. Likewise with breadboarding - there would just be a sea of wires! Yes I could do it, but the data sheets are clear enough I decided I’d just send off boards for production - Chinese PCB services are cheap enough to take a chance on (and I have done this a few times now for my other project, an LED matrix controller so I’m not sure why I wa so keen to prototype this the hard way)

But then another thing came up: I wanted to make a change to the design to make the AVR more capable - there aren’t quite enough pins available for it to control some of the lines. In the end I decided this can wait until a second revision. The design change in question is to add a tristate shift register or three to act as a port expander. This would also potentially allow for using a smaller AVR to make up for the board space taken up by the shift registers. 

Then came the next challenge - Chinese New Year would slow down board production - I wanted to get an order in before then but in the end doubted myself enough that I didn’t - I was still thinking about that design change!

After that life (by which I mostly mean my day job) somewhat got in the way and nothing happened. Anyway a couple of weeks ago I tidied up the board design and today I finally submitted the order! 

I decided to start by developing the AVR-based programmer for a couple of reasons. Firstly, I’m somewhat more familiar with AVRs than z80s. Secondly, the z80 parts will be much easier to develop if it can be done without ripping the eeprom out all the time.

It’s coming along nicely, despite some infuriating bugs and kinda awkward birds nests of address lines on the breadboard!

I still intend to try using some shift registers on the address and data lines, but I’ll get it working without then look into that - it should be a relatively simple code change once I get the wiring sorted.

Next I need to write something to receive dats over serial and write it to the eeprom - I’m thinking it might make most sense to just send intel hex format over serial. I actually have some software flow control implemented, so hopefully I won’t lose any bytes!

a large pile of components were delivered today. Unfortunately I have to go to work :(

Things to test/do in no specific order:

• Assemble a basic z80 circuit on a breadboard and test some basic ideas 
• Implement rest of AVR for programmer

I suspect I can do this as two separate projects then bring them together later - the only thing that actually ties them together is the busreq and busack lines to coordinate bus access. Well, that, and the fact that programming the z80 is that bit more difficult when you have to pull the ROM off a breadboard - it shouldn’t be too bad.

Random thoughts 

It might not be a bad idea for the AVR to be able to reset the CPU - though like many of my ideas it would require a set of shift registers for port expansion to actually be able to do that. I guess that’s something else to try!

• Investigate shift registers for port expansion

The code is basically a bunch of C so it shouldn’t be too hard to support both modes for testing if I wanted to.

I have done an initial PCB layout (Thanks to Diptrace’s autorouter!) and started writing some AVR C for the programmer.

PCB Design

I have been working on a PCB layout - I haven’t spent too much time on it so far, but I do think what I have would work quite well. Obviously, it is not the final design - for that I’ll need to do some extra tests on a breadboard first!

The usual wisdom is to avoid the autorouter, but for this board it seems to be the best option - there are so many through hole components I was struggling to route it by hand. I might be able to do better on another attempt, but it at least proves the board is routable! I’ll come back to this later.

Programmer

As mentioned before, the design currently includes an ATmega8515 as an EEPROM programmer for downloads of z80 code. The 8515 is an older part, but is about the only thing  with enough pins for this. Initially I chose it because  it’s cheap, but actually, all other parts have A/D converters on - and therefore you lose a pin or two to Things like ARef. This does mean I need to be fairly careful to make sure my code fits into the 8Kb of program flash - That said it isn’t looking too bad so far as long as I am careful. Link time optimisation helps a lot here. 

I have a suspicion I’ll end up using tristate shift registers as a port expander - however that’s not without its own problems - not least that it adds cost and components. The other option would be to disable in circuit programming (probably not actually incredibly useful if the microcontroller has a boot loader on it) but that would me a anyone wanting to use a blank Atmega8515 would need to be able to program it in parallel mode, raising the barrier to entry somewhat. Still, it’s an option though it wouldn’t be perfect since it wouldn’t allow me to both use a different AVR and drive more pins at the same time- only one or the other. That might be fine, but I can’t shake the idea that using a different AVR might be advantageous somehow.

Ive been writing and testing some of the code using the ATmega328 currently on a spare arduino board - it provides enough (power, serial) to be able to test some of the code - and I can’t get going on testing the meat of programming the EEPROM until my component order arrives anyway - and the ATmega8515 is in the same order.

Other Thoughts

It’s beginning to take shape nicely. I do wonder if I’m worrying too much about the whole pin count thing on the AVR - it’s a somewhat theoretical problem right now!

I have been thinking I probably need to use a boot loader on the AVR - tho is would make future updates a whole lot easier since it wouldn’t require a separate programmer. 

Another idea I had would be to clock the AVR faster (I currently have it using the same 8MHz clock as the Z80) and use software USB instead of serial. It might allow faster data transfers and be easier to work with - on the other hand, serial is easier to use - but would probably require some form of serial to USB converter! Hmm, decisions... Clocking the AVR faster might also allow it to monitor the busses in real time - though I’m not sure how fast it would have to be - and given I might have to use a shift register it might need to be quite a bit quicker to be useful. Again, more tests and thinking needed here.

I’ve been researching and playing around with schematics for a few days now and I think I’m getting somewhere. A non-exhaustive list of what I have is:

• Z80 CPU
• Z80 PIO (Parallel IO)
• 8MHz oscillator
• 8Kb EEPROM
• 32Kb SRAM
• ATmega 8515 for external programming (more on that later)
• Switches
• LEDs
• 40 pin exapansion header
• Altera CPLD for address decode

External Programming

One of the things I’d like to have in this design is an easy way to program the EEPROM within the circuit to create something more self contained. Currently I have an ATmega 8515 in the design - mainly because it’s the cheapest AVR on RS with enough pins to do this. It sits on the address and data busses so it should be possible to have it read and write the SRAM as well. Unfortunately it can’t use the IO components because there weren’t enough pins on the microcontroller for the IO toggle line. I have an idea though that might allow it access to more pins - or maybe even allow using a smaller microcontroller. The only issue is it requires some extra ICs and the part count is getting quite high!

Next Steps

In no particular order, the next steps are:

• Breadboard out some of the ideas to check them
• Start designing a PCB from the schematic
• Write some z80 examples
• Write an easy to follow tutorial 
• Design the address decoder
• Write the AVR code to implement the programmer

Other thoughts

Right now there are a few things that need more thought:

• Would it be better to use discrete logic instead of the CPLD?
• Should the microcontroller use bidirectional shift registers as a port expander for the data and address lines?
• is this actually going to work? ;-)