Zilog Z180 Single Board Computer project

[ron.owens]

I have been working on a Zilog Z180 design for over a year now. I have a complete set of schematics and PCB layout completed in Eagle. I would be very interested in anyone that would like to look over the design and see if I got it right. An extra set of eyes would be very much appreciated.

I have been designing circuits for many years and it was a few decades ago when I built a Z80 board. I design electronics for a living, but mostly embedded stuff. I rarely get to work on the firmware anymore. This project was a chance to roll up my sleeves and take a trip in a Way-Back machine to the 80's and have some good old fashioned 8-bit fun.

I am planning to fab several PCBs once I'm certain the design is reliable enough to do that. I'm willing to give boards to collaborators in payment for their help.

I would also really appreciate help in writing an assembly level monitor to help with software development and debug. It's a bit overwhelming for me to do on my own, being a hardware guy. I'm sure I'll eventually get there, but help would be nice.

[obiwanjacobi]

Why not simply attach the design to you form post and people will respond for free 

There are a lot of Z80 monitors with source code out there. What type of functionality do you want?

BTW: I have written some blog posts on my Z80 project with some ideas that may be perhaps of interest to you.

[ron.owens]

Thank you for your interest in the Z180 design. I fist tried to upload the schematic, but it was too big - 3.54MB. I was able to shrink it to 909KB. Hopefully it is still readable and usable.

I have the SoftTool WinIDE for Z180 code development. I have only experimented with it on small example code so far. I am looking forward to writing some real code once I have a monitor up and running.

[ron.owens]

I'm currently working on a user's guide for the Z180 Single Board Computer. It's mostly a description of the hardware. I'll post it as soon as it is done enough to be useful.

[C]

Look at your serial I/O
With out the other serial port signals you are limited to software flow control.

You should have buffers at your expansion buss.

[ron.owens]

I planned to use software flow control. I intend to use a serial to USB module so I could talk to my PC running a terminal emulator.

The buffed the data, address and control buses of the processor. I didn't have room on the prototype board I started on for additional buffers. I also thought they would add even more delay to the bus timing.

[C]

A good USB to serial should do hardware handshake. Bring out to a jumper area if nothing else.

Buffers
You are thinking serial buffers, use parallel buffers. One to drive on-board stuff and a second to drive off-board stuff

Edit
The problem with two or more parallel buffers is which data buffer to enable so the Z180 see's the read data.  One signal cures this "I AM ADDRESSED". Not hard to feed all the on board chip selects into an OR gate.
   

[TassiloH]

Two additional suggestions:
1) Don't use the diode-resistor-capacitor-7414 reset logic. I did this with my first couple of Z80 boards until I got annoyed by unreliable resetting in case of power brownouts - if you have bad luck no reset or a too short reset pulse is generated with unpredicatble results. Better use a proper power monitor/reset chip, like the TL7705A or such. Only matters if you want to run the board unsupervised of course.
2) Make the FLASH ROM writeable. In this way, you can implement a routine that is later on copied to the RAM and that takes data via one of your serial ports and programs the ROM. As soon as you have this piece of software running, a separate programmer is not necessary to update the ROM contents (unless a bug prevents the programming routine from running). I think you just need to connect WE/WR to the ROM. Accidental writes are prevented by the ROM write command logic (although they may provoke a crash, the ROM might not react to the next read cycle if a malformed write cycle is seen).

[ron.owens]

Thank you all for the great suggestions. This is exactly what I was hoping for. I'll incorporate the suggestions and post a new schematic. My biggest concern was laying out cash for a few boards and winding up with junk. I consider myself a competent engineer, but it's very hard being the Lone Ranger on anything more than a novel 555 circuit.

[C]

If you are going to the trouble to make a PC board think of some options.
The more ram you have the better in long run as you can treat ram as rom.

You have a bunch of Z180 pins not connected, would be nice to have easy access to these.


Have you checked the timing of those parts?
You have a 12Mhz Z180 trying to talk to a bunch of slow chips think.

I would stress that going out of what is in the data sheet is going into the unknown. Just one small sequence can fail at a higher speed and just cause all kinds of trouble to find.

[ron.owens]

Thanks again for the suggestions.

I currently have 512K of SRAM. The Z180 can only address 1MB without help. I think a good solution would be to use a full 1MB of SRAM and overlap 32K or 64K of Flash to hold any boot-up code, or a monitor. The GAL16V8 should be able to easily map the memory. The SRAM I picked is available up to 55nS speed. Faster is probably available, just hard to find in through-hole. Do you have a recommended access speed? When I change to a smaller flash I would make sure it is writable in-circuit and fast.

I've got the reset circuit changed, however, I'm still looking for parallel buffers available as 'ALS' parts. TTL 'F' parts would also be acceptable.

[C]

You have an error. The output of max232 is connected directly to Z180 so TTL receive is not possible.

The best idea I have seen is a power up reset of a latch. You then can have two states a Power-Up reset and a Z180 reset. The latch enables the power-up boot program and Z180 can change the latch and have full ram. A warm reset can then just reset the Z180.

Keep the huge flash an let the Z180 switch it in or out of memory map.

Was not thinking of RAM speed but the old chips on other pages.
You have to check the timing from the Z180 data sheet.
The R6522 is from a different processor family and listed as 1Mhz or 2Mhz.
Need to check that all chips are working in spec.

 
EDIT
look at D1 & D2 connected to U9
& LED1

[obiwanjacobi]

Nice! I agree with adding full RAM if you're going to make a PCB. Make a simple jumper selection switch to allow not populating all of it. Your bios should do a RAM check to find out how much RAM is installed. Also I would certainly get BUSREQ and BUSACK out onto an extension bus. But allowing to release bus control also requires you looking at your (address) buffers... ??

In my own design I have some facilities for debugging incl. a bus-sniffer that displays bus content as well the ability to slow down the clock to a crawl (in order to read what is on the bus status leds  ). I also plan to use halt and the NMI as a way to handshake programming state to an external debugger. I save all the registers if the CPU to memory and then send that memory block over to the external debugger. The external debugger can also take over the BUS(REQ) and probe the RAM as it pleases. Disclaimer: this is all still in development.

I looked for a nice Z80 (free) IDE but finally settled for the Z88 development kit and using Notepad++ with a Z80 language definition as an editor. Have a batch file to build. Currently just writing the bios in assembly. Later I want to enable C to write the programs / applications in.

Ask if you need something - I am planning on making it all open source, just haven't yet because it is not working correctly yet...

[ron.owens]

It's looking like a major change that will require a complete re-route. I don't mind because it's easier to do it in Eagle than cut and patch a PCB!

My fix list is now worth actually making a list:

1. Full 1MB of SRAM in 2 512K chips - as fast as available.
2. Smaller Flash memory - 32K or 64K, jumper selectable?
3. Fix TTL/RS-232 selection jumpers to actually work!
4. Add wait state logic for the ancient slow I/O chips.
5. Use buffers for the Expansion Bus - no buffers for on-board buses.
6. Add BUSREQ and BUSACK to the Expansion Bus.
7. Add on-board +5V switch mode power supply - Input will be from +9V to +24V
8. Different/faster parallel port part? (Any suggestions?) Or can it altogether?
9. Make the SPI bus from a PIC MCU.
10 Possibly make the Expansion Bus connector 60-pins.

I welcome any other ideas. I would like to consider this 'our board'. After all... some of the coolest things have happened when a group of tinkerers got together to have fun!

I'll have a new schematic up in a day or so. I'm looking forward to more input.

[C]

Suggest looking at timing now

A system that uses wait states can be faster with a slower CPU clock.
Need to compute what the Z180 needs for timing of signals. Then need to look at each chip and it's connection for it's timing of signals needs.

It could be better to put the real time clock on an I/O port for example.
You would see this if you looked at the timing needs.

There are some chips like the Z80 PIO & SIO that are usable with other cpu's Look at zilog and i/o chips for other then Z80.

While you may not be planning this change, think huge and see what would need to be changed. Back in 80's, systems with 16-18 Z80's plugged in to a system buss. System buss could have different family of chips.
The best CPU boards had three buses. The on board buss, the local expansion buss & the system buss. The better ones local expansion buss had almost or all of the additions needed for a system buss.

To get an idea, connect two of your boards together via the local expansion buss. A memory cycle for one board would be a DMA cycle to other board.  A DMA unit should work, while the two Z180's might need a helper circuit to connect them.

If you are having a PC board made would be nice to be able to connect the extras.

I would not use the old chips or put them on a separate board

#1 & #2  More memory then address space can be done with out much trouble.
You could think of having different modes.
During power up this is the memory map. This mode can then pick a new mode and reset the Z180 and have a different memory map.
You could have a small area that is flash. When running change one or more I/O ports and point the small area into a Very Huge flash memory chip. Think what Mass storage does   

#4 & #8   see above.

[C]

Thinking you may not have got idea or full possabilities of an "I AM ADDRESSED" signal.

You are thinking now of 1 MB of ram.

Think of two 8-bit output ports that have power up clear capability. You compare the outputs of these with the Z180 address buss. On a match you enable flash memory. So on power-up the top 16-bits of flash memory = 0. You have your Power-up boot.
Problem is the 1 MB of ram also wants to respond, but you use the "I AM ADDRESSED" signal that goes to flash chip select to prevent this.

Note the two output ports above. Any value to these ports moves the flash memory window address and at same time prevents the ram from responding to this window address.
You can easily have layers of memory or IO  that prevents conflict with lower layers.

Edit Adding below
Going a step further, the two IO ports would not have to be compared against Z180's address and could be used as an index into a very large memory that appears as a small area Z180 memory.

[TassiloH]

Regarding the slow I/O chips and wait states: Keep in mind that the Z180 has a built-in wait state generator. Maybe that is already good enough. Although I/O operations might be annoying if you have to change the settings of the wait state generator all the time (I think it only had one setting for I/O and one for memory cycles).

[ron.owens]

Thanks for the additional input.

I haven't considered multiple boards beyond maybe connecting two via the Expansion Bus. Using DMA for this would be a good idea, especially since two DMA controllers are built into the Z180.

I'm currently making memory 1MB of RAM and 32K of Flash, and a GAL22V10 will take care of address mapping. The File Register chip on the 28-pin module is intended to connect to a USB flash drive and will only be limited by the size of memory stick that is installed and what the firmware is aware of. The idea was to use it as mass storage rather than try to add an IDE interface and a SD or TF card. It would still require some system flash memory to boot up any OS on the memory stick. It looks like a pair of 8-bit I/O addresses - one for commands and the other for data. I'm sure that will require some kind of driver.

A real-time clock is very nice to have, however, they are hard to find as a byte-wide device. Most chips are SPI or I2C. I'm still holding out that the slow I/O idea can work. It would be sweet to have the speech sythn and sound generator. It's kinda why I started this thing in the first place.

I'm also bring out some of the unused pins of the CPU to a test header. Most of the unused pins are for hardware handshaking on the serial ports. I increased the size of the Expansion Bus connector to 60 pins. There are a number od spare pins, even after adding the BUSRQ and BUSAK signals.

The schematic is coming along nicely. As usual, there is always room for changes/improvements. As always, they will be welcomed.

[ron.owens]

Here's the updated schematic, ready for changes.

Please let me know of any error founds, changed needed, thingys to be added, thingys to be removed, etc..

[ron.owens]

Here is a very preliminary layout of the Z180 single board computer.

[C]

For a Z180 read cycle
how long is data ready at Z180 pins before the Z180 reads the data pins?
How long does each chip need for a read?

For a Z180 write cycle
How long does the Z180 hold outputs steady?
How long does each chip need for a write?

[ron.owens]

As far as I can tell from the datasheet on the Z180, address to read in @12MHz crystal is around 500nS. Write data is expected in 250nS from address to the edge of the WR signal. The SRAM and Flash chips operate around 70nS for a read. The write timing for the Flash chip says it writes 64 bytes in 10mS. This is going to require a lot of wait states for a Flash write cycle.

The Real-Time Clock wants a write pulse width of 500nS and an address hold time of 1uS. This looks like the GAL22V10 address decoder is going to have to do some fancy wait state sequencing. It will also have to generate the read and write pulses along with the address write pulse. I think the GAL22V10 is capable of doing state machine operations.

Conclusion: SRAM timing is good, Flash write timing is a problem and the Real-Time clock is a bigger problem. I can look for another bus oriented RTC and hope for better timing, or implement a fix for the chip I currently have designed in.

[C]

Or
 treat some of this as if connected to I/O or memory ports.

the Real-Time Clock could be connected to I/O ports instead of direct to buss.
Flash write could be an I/O operation. You start the write and then go away for a time while checking a status bit.

Note that you can have I/O in memory space and I/O space.

As far as I can tell from the datasheet on the Z180, address to read in @12MHz crystal is around 500nS. Write data is expected in 250nS from address to the edge of the WR signal.

Better check the fine details, think that is very slow.

[TassiloH]

The write timing for the Flash chip says it writes 64 bytes in 10mS. This is going to require a lot of wait states for a Flash write cycle.

That is not a problem. You can write a certain amount of bytes (refer to datasheet for row/page sizes) to the flash in much faster bus cycles (probably no wait states needed). After that, the flash will perform the write operation to its flash memory cells, which will take several milliseconds. During this time, you cannot perform read/write operations to the flash memory, but the data bus is available as long as you do not access the flash (usually there is even a way to do a read cycle to determine if the programming has finished). So as long as the programming software sits in RAM, the CPU does not have to wait for the flash. It would only be problematic if you want to execute software from one part of the flash while another page of the flash is being erased/programmed.

[ron.owens]

I would think the only time to write to the flash would be a firmware update or replacement. The source of the code to be written to to the flash would come from the system serial port or from the USB memory stick. Either of these would not require a read or execute from the flash while writing to it.

My concern at this point is what hardware would be needed to support any of these functions. It's one thing to make changes in software to fix stuff, it's another thing altogether to change hardware. The hardware could be made flexible with chips like the GAL22V10 that allow actual hardware changes to be made without hacking and patching the PCB. The place to to put the flexible logic seems to be between the CPU and the control signals of the memory and I/O chips. It would not be hard to place a couple of GAL chips on-board to support this. It seems to me this is what GALs were born to do.

Please let me know if there are any ideas along these lines. Changing the circuitry with programmable chips is much more desirable. All the parts on the board should be in sockets. I don't think in-circuit programmable GALs are not practical. I would not want to add a CPLD or FPGA.

I'll go deeper into the datasheet and make sure of the timing. I think this is a very important item that must be considered.