I got the buttons working! I needed to add some pulldown resistors (not sure how I thought it would work without them!) but it’s all fine.

It got me thinking a bit though and while I was lying awake thinking about z80 instructions rather than sleeping, I had a bit of a thought explosion about this.

Note: This post is a bit of a ramble so feel free to skip ahead to the summary at the end if you get bored!

The PIO

The more I think about it, the PIO isn't the best choice for interfacing on this project. It was originally chosen since it is the companion chip for the Z80 for IO in a parallel form, however it's relatively expensive and only provides 8 bits of input or output. It does have some fairly fancy features like interrupt support but to be honest, I'm not really sure how useful they'll be in practice on this project. It's also a fairly big 40 pin IC so isn't exactly great for board space efficiency.

The more I think about it, some discrete logic could do the same thing practically but significantly cheaper and probably easier to work a board design around. As a bonus, it would be easier to program for though it wouldn't support more advanced use cases

Expansion Ports and Usability

The first iteration of the design has a 50 pin IO port exposing various z80 bus pins (think address bus, data bus, various other interface pins and some spare CPLD lines lablled nominally as chip select lines)

This isn't a bad start, but I think I can do better. I was thinking about what it would take to port CP/M or one of the BASIC variants to the board, and then I realised I'd wandered into the early PC territory I said I wasn't targeting. It got me thinking about what would make this board more useful than just something to blink LEDs as a response to switch presses. At that point I realised it needs more IO.

I'm thinking as well as the LEDs it should have 8-16 inputs and outputs exposed on a header for simple external control. This would make it more like a z80-powered development board rather than something you talk to over serial or a keyboard.

That's not to preclude making it run BASIC or something, but it does give me some interesting ideas in terms of the hardware design.

Programming The Thing

Originally I'd envisaged a fairly bare metal programming style where the user's code runs straight away at boot and includes the hardware setup. This setup code could, of course be included from a library of snippets - I had thought about providing some files to include for this. The more I thought though, the more I think it makes sense to provide more than this.

One of the aims for this is to make the Z80 as easy to work with as possible and to demonstrate the different parts of a computer in a fairly simplistic form. It would be useful to provide a library of functions for the user to be able to call into, to save time and also to make it easier to get going. Of course they would be more than welcome to code from scratch if they wanted to, but the more I think about it, they shouldn't have to. I mean, they would still be coding in Z80 assembler, but at least they wouldn't have too much boilerplate to worry about.

Then it occurred to me that there's no need for the user's code to even include these libraries - by default the EEPROM could have the setup code on it that rarely changes and the user could just upload their own code to a known location. Of course there would need to be an easy way to upload the boot code as well in case they accidentally or intentionally overwrite it, but it would make it easier for the user to focus on their own code.

Then I started thinking even more,  and it occurred to me there could be a whole library of code present on the board for the user to call into. In order to leave space on the EEPROM for user code, this could either be some snippets that get pulled in on demand or another idea I had was to include some flash memory that gets bank swapped in when the user wants to call into it. Flash memory because it's quite a bit cheaper than EEPROM memory and only comes in larger sizes (compared to the EEPROM anyway)

The AVR

As I've mentioned before, there's an ATMega8515 on the board to act as a programming and rudimentary debugging interface for the board. This is an old and rather large (40 pin DIP) part that I chose because it has enough IO lines to access the address and data buses as well as all the other things it needs to deal with. Well, almost. It doesn't have a pin for the IOREQ line, meaning it can't talk to the IO interfaces. It also has no spare pins for some other stuff I'd quite like to add.

While browsing RS earlier for various parts (mostly logic to build out the IO) I stumbled upon some I2C port expanders. Originally I had planned to use some tristate shift registers to implement a port expander, allowing me to use a smaller AVR to do the same (and more) work. These I2C port expanders are much nicer for the job though, so I have ordered some of them.

To put it into some perspective, the similar - looking ATMega8535 doesn't have enough pins for this - because it has analogue ports on it, the AVcc pin actually steals a pin that the ATMega8515 uses for IO.

Other Thoughts

I think it will be important to nail down the layout of the expansion ports early on, so hardware can be designed to expand the board without worrying too much about future changes making older expansion boards obsolete.

I have been contemplating replacing the address decoder CPLD with discrete logic. It's probably something I'll try to design to see how it looks. Having the CPLD on the board has actually been very handy for fine tuning stuff and experimenting, but once the design settles down it's unlikely to provide  as much benefit. That said, it might be the most efficient in board space, cost or both to use it. I guess I'll see how that one pans out.

I do have a vague idea in my mind for a PC app for sending programs to the board, maybe even with an editor built in. The idea being to make it as easy as possible for people to use without having to locate an assembler and find a way of sending the hex files over serial.

Of course I probably should look at a BASIC port since it might provide another useful way for people to get to grips with the board. 

Overall, so far, it's looking like it's actually going relatively well.

In Summary: Next Steps

So to round all that out, I think my next steps are:

• Switch out the PIO for some logic
• Add more digital IO
• Think about how to organise a code library
• Experiment with port expanders
• Think more about the expansion port and what pins are on it
• Think about an easy way to send programs to the board

So many ideas, so little time!