Zilog Z180 Single Board Computer project

[obiwanjacobi]

What do you do with the bus buffers when an external device asks for a BUSREQ and the processor activates the BUSACK and the device starts manipulating the Address and Control lines? 

[ron.owens]

Thanks for pointing out the bus buffer issue. I had completely overlooked that. My original design didn't consider it either. There is a cool chip that can handle most any bus configuration, the 74LS646. It is bi-directional and has built-in registers for both directions. There are a number of control pins that set up the modes and how they are used. Perhaps these parts on the external bus with some programmable GAL logic would make for a very flexible interface that would handle DMA, bus sharing or good old fashioned external hardware controlled by the local processor. The mode of the buffers would be a function of the decoded states of the processor and request & grant signals to the external bus.

I originally thought the external bus would simply connect to hardware that would be completely controlled by the local Z180. Now it looks a lot more practical to accommodate the functionality beyond a simple expanded bus, like S-100. This way future add-on devices would not have to be defined and accounted for at the time of initial design, thus making it a true expansion bus.

This is one of the very reasons I wanted to have others look over the design and contribute. I knew there was a fair chance I would make a catastrophic boo-boo and waste a lot of time fixing it. Worse yet, just give up on the project altogether.

[obiwanjacobi]

Do you want extensions (on the bus) to reset the CPU? If so you could make the inverters of the open collector kind (74xx14 i believe) and add pull-ups. Could be handy for externally programming flash or setting up test configs in RAM.

I have not studied it, but what happens on reset? Looks like all devices reset at the same time (RESET a tad before !RESET). Are you sure this will not cause any race-conditions? What happens when they all come alive at the same time. Again could just fine, but can also be a headache if there is some dependency. A simple RC delay could fix that easy enough.

A 100uF for speaker out sounds like a lot 

[ron.owens]

Being able to reset the Z180 from the external bus would be handy. I'm sure it would also need some rules.  The TL7700A reset chip has an open collector /RESET signal and an open emitter RESET signal. The datasheet doesn't mention, or show, what the timing skew, if any, would be between the RESET outputs. Using the /RESET open collector output to drive active low reset signals and also be tied to an external open collector /RESET would handle the reset signal sharing. A single 74F04 inverter for the active true RESET would only have a 3.5nS propagation delay. It might even be a good idea to have separate inverters for a local and extended RESET. The RESET would be controlled by the shared O.C. /RESET.

According to the LM386 datasheet (see attached), 100uF is a little light. I've always used a 100uF with this part and it seems to work fine. I'vw always wondered why it had to be so high. Maybe that's what it take to keep and DC element out out he speaker signal.

[obiwanjacobi]

Wow that 74-646 looks awesome, thanx 4 tha tip 

Why would you use those two inverters if the TL7700A has both signals (30mA each - that should be enough, yes?)?

[ron.owens]

Some chips want to see a 'real' TTL signal on their Reset input. The open collector and open emitter stuff has poor rise time and fall time, respectively.

The 74LS646 (or 74F646 for the faster part) is awesome, but requires a lot of hand holding to make it work. Reading about the control pins can make you dizzy! It usually comes down to being very specific on how it's control lines are manipulated. That's why I thought a GAL22V10 would be a good choice to control these buffers. The GAL22V10 would get signals from the Z180 and the external bus device and use those to configure and operate the 74LS646 parts. The data bus and address buffers will operate differently, and the buffers on the control lines should work like the address buffers.

Defining the control signals on the 74LS646 parts will take some serious logic work. I once saw a Karnaugh map tool that might help with this. Hopefully I can find it again.

[ron.owens]

I've done some serious redesign work on the Z180 SBC. I removed all of the audio circuits. Don't worry, I saved the schematic as a separate board. I took the SPI bus off of the R6522 VIA and made it 2 parallel ports with handshaking. I've replaced all the external bus buffers with the 74F646 parts. I found a few sources on eBay that sell them for around $1US each. The R6522 should work fine as a slow I/O device because the Z180 can talk to it as if it were a 6502 or 6800 peripheral chip.

I plan to post a new schematic when I figure out how to control the 74F646 bus buffers. I'll post an incomplete schematic if I can't figure it out with enough certainty to trust it. Please let me know If anyone any thoughts/ideas on using the 74F646 chips.

I'm still offering a free bare PCB for serious contributors. That's the salesman's way of saying "I would like help with the software"!

[obiwanjacobi]

I have some GALs coming but have never worked with them. I was going to use one to control my system bus led display, latching in (with 74-573's) bus addresses, data and control signals for certain 'conditions' (like input, output etc). Not sure how 'big' they are and if what you're planning here will fit..?

I don't think you need the 646's here, although it might be interesting to play with.  (BTW farnell has them cheaper for me.)
A couple of 245's for the address and control lines should do, right? When the CPU has control they 'point outwards' when a BUSACK is active they 'point inwards'. That should do it, should it not?

What (kind of) help do you need with the software?

[ron.owens]

I've used GALs several times, mostly to replace a lot of SSI TTL and the like. A good program for write GAL code and compiling the binaries is WinCUPL from Atmel. It's a freebe and comes with a lot of example code. I recent bought a TL866CS USB Universal Programmer on eBay and it programs these parts easily.

I'm sure a GAL22V10 will do the job because its more than combinational logic, it has macro cells that can be configured a lot of ways. Also, output and mid terms can be fed back as inputs. I'm thinking that one GAL22V10 will be the address decode, like in the schematic now, and a second one to control the external bus buffers. I think you're right that the 74F646 chips might be overkill. They are only used if you have to latch the data on the bus, like in pipe-line based computers. The 74ALS245 should work fine for all the bus buffering. They are a lot simpler to control. When I go off the deep end, I like to go 'very deep'! Thanks for bringing me back.

For software help, I would like to port an existing Z180 monitor to this board. I'm not sure how the code works for the internal serial ports. It would be nice if it eventual ran CP/M. I've written a lot of Microchip PIC code in assembly, but it doesn't seem to translate well to the Z80 world.

[obiwanjacobi]

Yeah I have had some struggles with WinCupl on Win8 and finally got it running on an old WinXP machine. I have not studied Cupl yet but opened a couple of examples and it looked understandable with some minor help. After looking into Verilog and VHDL, Cupl should be a breeze.


After a quick scan of the Z180 datasheet the serial programming looks like the typical register based control. So if you did UART stuff on a PIC it shouldn't be hard to get going..?  As for a monitor, I think you can look for any Z80 monitor code on the net and take that as a basis and extent what you need/want for the Z180. I think resources on the Z80 are more plentiful than on the Z180...
I have some Z80 assembly knowledge but never delved into the Z180. Sites like Z80.info are a good place to start...

[ron.owens]

My methodology for GAL programming is to have WinCUPL open, along with the appropriate datasheet, and a CUPL tutorial. Then I start from an example that's as close to what I want to do as i can find. This has worked pretty good for me.

I have a monitor that was written for a Z180 board. It's vintage 1980's. It assembles without errors in my Z180 assembler. That sounds like a good place to start. Hopefully it will be a matter of reassigning I/O in the source code.

Here's a preliminary schematic (no color) that has the new stuff in it. I added back the Hex displays. I think they will be helpful. Besides, they have that very retro 80's look about them. 

[C]

Guess you need to decide what you really want.
For me, only having software handshake for serial is a fail.
I would want all the z180 serial i/o pins at a min to be to a header.

A computer that has access to mass storage has very little need for a Z180 monitor. If you are trying to debug a program, you use the system debug program as it is much more capable then a Z180 monitor rom can be. This does not equal small flash memory size. A huge flash memory can be a big help, but needs to be swapped in and out of the memory map.

Look at the expansion buss.
With the last drawing the only thing the on-board Z180 could do with that memory space is use it as a write-only address space. A write to on-board memory and expansion buss memory. There are uses for this type of memory.
And if a Z180 read gets to the expansion buss, you can have a buss conflict.

You need a signal that says that something on the board is responding to a read and prevents the expansion buss from enabling it's buffer in the read direction. The  expansion data buss buffer needs to go to tri-state in this case.

Many ways to make what you have better but are limited by what you want.

[ron.owens]

I have built a lot of embedded controllers, most use software handshaking on the serial port. I've never had trouble with this. All of the USB to serial modules I've used don't support hardware handshaking. I'm sure there are some available.

The monitor is primarily for hardware debug. Especially trying out new hardware devices. I planned to use it to initially bringing up the board. It would also be a good starting point to get familiar with writing Z180 assembly code.

I can't see how the hardware of the expansion bus would result in a write only memory. The read and write signals from the bus and the Z180 go to the programmable logic that controls the buffers. I thought DMA control and the BUSRQ and BUSAK eliminate bus conflict. The Z180 board would always be the master until it is relinquished under control. Extra control signals would be great. I'm not sure how that works, or how to implement it. However, I believe it should be added. Please let me know if you are familiar with this.

Please let me know if you have some ideas to improve this project. I can only make choices if I know they exist. This design is a new type of experiment for me. I usually get a product specification and design circuitry to make that happen. An open ended project sounds like it would be the results of a group working together. Not just one persons plan. I've taken on the role of schematic capture and PCB layout engineer. I doesn't mean that everyone has to do as I say. It's my desire to build a way cool Z180 board that would be fun to play with. No goals beyond that.

[obiwanjacobi]

The address decoder GAL for the internal memory has IO_EN as input. Do you think there is enough space in there to include an IO latch to enable/disable internal memory access? That way you could switch off (or on) internal memory access with an OUT instruction and use an extra output on the GAL to signal the extension bus decoder..?

Look at LED1 in the power supply   

[ron.owens]

THE address decoder GAL should be able to set a  latch  for internal/external memory events. That's a very good idea. That signal would be brought out to the Expansion Bus. I'll start working on the GAL program.

Good catch on the power LED.

[Bruce Abbott]

I would think the only time to write to the flash would be a firmware update or replacement.

I wouldn't bother with in-system flash updates. Just put the ROM in a socket and use an EPROM programmer to update it. I use a Winbond W27C512 - same as a 27C512 EPROM but only takes a few seconds to erase and reprogram.

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 agree. GALs are great for quickly changing glue logic. In-circuit programming makes no sense when you can just pull the GAL and put it in your EPROM programmer. Firmware will be developed on the PC anyway, so why bother transferring it to the Z180?

One tiny suggestion: the AY-3-8912 sounds much better in stereo. If you don't want to have two amps on board, at least include a 3.5mm phono socket so you can connect it to an external stereo system.   
   

[ron.owens]

I agree about programming Flash and GAL chips off-board. That's one of the reasons I always use sockets on board with through-hole parts.

I'm thinking about adding the sound stuff back in. It can always be 'no populate', at least until some code to drive it is worked out. I like the idea of making the audio stereo. I've seen some methods for doing stereo with the AY-3-8912, but the speech chip will have to drive a separate cap for each channel to act like stereo.

I was wondering if the expansion bus connector might be a real parallel bus, like the kind that go in a card cage with a back plane. If it goes that way, we may want to consider a standard for factor for the Z180 SBC. I like the idea of using 96-pin VME connectors for the bus. Lots of pins for special board to board signalling. Just thinking out loud. This would take the project is a very different direction. I guess it would be possible to make the SBC a standalone board that could also plug into a back plane.

[spudboy488]

Good catch on the power LED.

And check D1 and D2 (which were also mentioned earlier in the thread so I can't take full credit) when you start diagnosing why your clock doesn't work.

[ron.owens]

Thanks for the catch on the diodes in the RTC circuit. My biggest concern on those diodes was the voltage drop across them would be low enough. The RTC chip has to see 4.5V or more on it's VDD pin to function. The datasheet recommends that the +5V supply operates at +5.5V. That isn't a good idea for the rest of the circuit. I chose Schottky diodes with a very low forward drop to meet the requirement. I really need to bread board this to verify I'll get the correct voltages. This would break the RTC every bit as bad as the diodes being backwards!

I should be able to post an updated schematic today with the VME 96-pin Expansion Bus and the audio stuff added back in. I would like this board to be a stand-alone Single Board Computer AND be able to be the processor board in a back plane based computer. I would really like to hear from everyone if this is a good idea, or just trying to make a one-size-fits-all-board that will not be worth building.

[obiwanjacobi]

Personally I would not put any expensive connector on the board but opt for low cost solution. On my own board I have 2 40-pin IDC pin headers to connect multiple boards with a flat-cable - at least that is the idea.

There is so much on it already it does not need a whole lot of extending IMHO.

[2c]

[ron.owens]

Thanks for the snap back to reality. When I go over the edge I tend to leap rather than step. I had designed in a 60-pin ribbon cable connector, but I think I like your pair of 40-pin connectors better. One 40-pin could have 8-bits of data, 16-bits of address and the most essential control lines. The other 40-pin connector would have the other 4 address lines and the more expansive control lines. This way a simple external device could easily be attached with the primary 40-pin and wouldn't need the expanded 40-pin. How do you implement your dual 40-pin configuration?

[obiwanjacobi]

I decided on separating between memory and io access. So one connector has Address and data lines and MEM_EN, RD, WR and WAIT (and a couple of free pins for future enhancement). The other connector has all control lines and some internal signals - no redundant address or data line here.

I use the Z80 which only has 16 address lines but my system has 20 address lines. These connectors are not really meant as an extension bus, more a system bus because I use small boards to link everything together.

[ron.owens]

You expansion connectors sound very good. Please look over the expansion connectors on this updated schematic and let me know what you think. There are a lot of changes, so there should be some new bugs, 

[obiwanjacobi]

Are D1 and D2 still the wrong way around?

The audio of the speech is mixed in with 2 1k resistors. I would increase (10k) these to avoid affecting the stereo width of the sound chips. You probably have to find the correct resistor values with a bit of experimentation to balance out the volume between speech and sound.

Connectors look fine, although I would not supply two resets to the bus. Pick one and if the expansion needs the inverse the have to do that themselves. I would also transfer a couple of signals from the first to the second connector in order to free up some extra pins for future use..? If you take the memory/io perspective you could put all address lines (and data lines) on the first connector as well as the obvious memory related control lines (MEMRQ,RD,WR,WAIT etc).
Also, I saw NMI but do you expose any other interrupts on the extension bus?

Serial/RS232: my choice would be to make separate headers for ttl and headers for a DB9 connector (such that you can plug in a flat cable, like: http://www.ebay.com/itm/2pcs-DB9P-IDC-Ribbon-Cable-Connector-RS232-9-pin-/160932605661)

Hope it helps.

[ron.owens]

It would appear the diodes were correct in the original schematic. I'm turned them back around.

I think I'll use socket pins for the mixing resistors and experiment with that once the board is up and running.

I've moved all of the address lines to the primary expansion bus connector and move a few signals around to make it more loke what you were talking about.

I got a crazy idea to add a 8259 type chip to expand the number of interrupts by eight. All of the Z180's interrupts are committed to the on-board hardware. Adding he Priority Interrupt Controller was fairly easy. There is a good application note in the Zilog Questions and Answers notes covering how to add an 8259 to a Z180. Check out pages 6 and 7 of the attachment. I attached a snap-shot version of the updated schematic. The GAL16V8 next to the 8259A is for the glue logic in the Zilog ap note.

My original plan for the serial ports was to connect them to a serial to USB module and connect them to a modern PC running a terminal emulation program. The selection of TTL and RS-232 to to accommodate more serial converters. A DB-9 would take up a lot of space on this board.