Zilog Z180 Single Board Computer project - Page 1
Forum section: electronics / general

author: ron.owens
author_rank: Regular Contributor
timestamp: February 23, 2016, 12:28:58 pm
content: 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.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 23, 2016, 01:35:22 pm
content: Why not simply attach the design to you form post and people will respond for freeThere 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 23, 2016, 07:42:49 pm
content: 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 23, 2016, 07:50:43 pm
content: 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.

author: C
author_rank: Super Contributor
timestamp: February 23, 2016, 08:24:21 pm
content: Look at your serial I/OWith out the other serial port signals you are limited to software flow control.You should have buffers at your expansion buss.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 23, 2016, 08:30:03 pm
content: 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.

author: C
author_rank: Super Contributor
timestamp: February 23, 2016, 08:45:39 pm
content: A good USB to serial should do hardware handshake. Bring out to a jumper area if nothing else.BuffersYou are thinking serial buffers, use parallel buffers. One to drive on-board stuff and a second to drive off-board stuffEditThe 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.

author: TassiloH
author_rank: Regular Contributor
timestamp: February 23, 2016, 09:47:59 pm
content: 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).

author: ron.owens
author_rank: Regular Contributor
timestamp: February 23, 2016, 11:55:42 pm
content: 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.

author: C
author_rank: Super Contributor
timestamp: February 24, 2016, 12:23:14 am
content: 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 24, 2016, 12:39:59 am
content: 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.

author: C
author_rank: Super Contributor
timestamp: February 24, 2016, 01:00:39 am
content: 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.EDITlook at D1 & D2 connected to U9& LED1

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 24, 2016, 08:52:53 am
content: 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...

author: ron.owens
author_rank: Regular Contributor
timestamp: February 24, 2016, 04:59:42 pm
content: 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 +24V8. 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.

author: C
author_rank: Super Contributor
timestamp: February 24, 2016, 06:37:12 pm
content: Suggest looking at timing nowA 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.

author: C
author_rank: Super Contributor
timestamp: February 24, 2016, 07:08:48 pm
content: 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 belowGoing 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.

author: TassiloH
author_rank: Regular Contributor
timestamp: February 24, 2016, 07:53:29 pm
content: 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).

author: ron.owens
author_rank: Regular Contributor
timestamp: February 24, 2016, 08:38:56 pm
content: 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 25, 2016, 07:25:54 pm
content: 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..

author: ron.owens
author_rank: Regular Contributor
timestamp: February 25, 2016, 07:33:48 pm
content: Here is a very preliminary layout of the Z180 single board computer.

author: C
author_rank: Super Contributor
timestamp: February 25, 2016, 09:03:21 pm
content: For a Z180 read cyclehow 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 cycleHow long does the Z180 hold outputs steady?How long does each chip need for a write?

author: ron.owens
author_rank: Regular Contributor
timestamp: February 25, 2016, 10:02:36 pm
content: 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.

author: C
author_rank: Super Contributor
timestamp: February 25, 2016, 10:50:32 pm
content: Ortreat 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.QuoteBetter check the fine details, think that is very slow.

author: TassiloH
author_rank: Regular Contributor
timestamp: February 25, 2016, 11:56:33 pm
content: Quote from: ron.owens on February 25, 2016, 10:02:36 pmThat 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 26, 2016, 01:11:15 am
content: 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.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 26, 2016, 07:11:30 am
content: 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?

author: ron.owens
author_rank: Regular Contributor
timestamp: February 26, 2016, 01:54:47 pm
content: 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.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 26, 2016, 02:28:59 pm
content: 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

author: ron.owens
author_rank: Regular Contributor
timestamp: February 26, 2016, 02:48:09 pm
content: 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.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 26, 2016, 04:12:51 pm
content: Wow that 74-646 looks awesome, thanx 4 tha tipWhy would you use those two inverters if the TL7700A has both signals (30mA each - that should be enough, yes?)?

author: ron.owens
author_rank: Regular Contributor
timestamp: February 26, 2016, 04:55:57 pm
content: 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 26, 2016, 05:24:11 pm
content: 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"!

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 26, 2016, 06:00:18 pm
content: 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?

author: ron.owens
author_rank: Regular Contributor
timestamp: February 26, 2016, 06:19:02 pm
content: 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.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 26, 2016, 08:15:07 pm
content: 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...

author: ron.owens
author_rank: Regular Contributor
timestamp: February 26, 2016, 09:21:22 pm
content: 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.

author: C
author_rank: Super Contributor
timestamp: February 26, 2016, 09:38:39 pm
content: 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 26, 2016, 11:14:05 pm
content: 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.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 27, 2016, 07:05:57 am
content: 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

author: ron.owens
author_rank: Regular Contributor
timestamp: February 27, 2016, 12:55:20 pm
content: 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.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: February 28, 2016, 01:36:36 am
content: Quote from: ron.owens on February 26, 2016, 01:11:15 amI 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.QuoteI 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 28, 2016, 03:10:07 pm
content: 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.

author: spudboy488
author_rank: Regular Contributor
timestamp: February 29, 2016, 01:01:46 pm
content: Quote from: ron.owens on February 27, 2016, 12:55:20 pmAnd 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 29, 2016, 02:27:35 pm
content: 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.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 29, 2016, 02:54:28 pm
content: 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 29, 2016, 05:28:48 pm
content: 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?

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 29, 2016, 07:19:36 pm
content: 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: February 29, 2016, 08:46:45 pm
content: 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,

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 01, 2016, 07:02:44 am
content: 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.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 01, 2016, 07:31:30 pm
content: 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.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 01, 2016, 09:48:32 pm
content: Serial: then perhaps one connector for real RS232 levels and one connector for ttl - instead of mixing the two levels in one connector?(looking into the attachments later)

author: ron.owens
author_rank: Regular Contributor
timestamp: March 02, 2016, 01:41:16 am
content: I like the idea of separate connectors for TTL and RS-232 ports. They would have to operate mutually exclusively, one or the other, never both. It is cool that each port can be TTL or RS-232 independently. Expect an updated schematic soon. By the way, to me at least, schematics are as much fun as comic books.I want to say I really appreciate the input. It has been so helpful. You are definitely getting a PCB. Beside, you building it will be even more debug help.All part of my evil plan.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 02, 2016, 08:53:53 am
content: Quote from: ron.owens on March 01, 2016, 07:31:30 pmDoes any of the ICs you use the three (!) interrupt lines for, support vectored interrupts? That is when the IC also puts a value on the Data bus when it signals interrupt and the Z80 (at least - not sure about the Z180 - it looks compatible) uses that to index a vector table (pointed to by the I reg) to jump to the ISR (Interrupt Mode 2). That way you can support 128 interrupt sources with one INT line. I would try to free up at least one IRQ line for that purpose if at all possible. That way you don't need any extra chips.(Extension bus/sheet 3: EX_IRQx point to sheet 3 (we're on sheet 3)? I suppose these are the extra IRQ lines from the 8259? Where is it?)

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 02, 2016, 08:55:54 am
content: Quote from: ron.owens on March 02, 2016, 01:41:16 amYou're welcome. No need to give me anything, although I really appreciate the gesture. Besides I am busy with my own Z80 board.Like you said: this is fun!

author: ron.owens
author_rank: Regular Contributor
timestamp: March 02, 2016, 06:21:28 pm
content: The original circuit had the three Z180 IRQ's going to the on-board hardware, and they were vectored. I changed it and used /IRQ0 to channel the 8 IRQ lines from the 8259, formerly the IRQ for the VIA parallel chip. The VIA's IRQ now goes to the 8259. I really need to go over all of the IRQ stuff. I want to make sure it's even close to right. I think the 8259 Priority Interrupt Controller uses vectored interrupts. It has several modes. There's a good article written by Jack Ganssel that covers Z80 interrupts and the use of the 8259. I really need to read through it a lot more carefully. It can be found here:http://www.ganssle.com/articles/acodeisr.htm.I'm uploading an updated schematic. A new set of bugs! I hope I cleaned up the sheet tags and I worked on the interrupt stuff, but I'm sure it need more work. Please feel free to go over it and let me know if you find any anomalies.On a separate note... if you don't build the Z180 board, you can always use it as a coffee coaster.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 02, 2016, 11:41:18 pm
content: I've attached a pdf version of Jack Ganssel's article in Interrupts. I find it's usually easier to read a formatted pdf than a web page that may go away some day. This will be my evening reading before i go back to the interrupt circuit on the Z180 SBC.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 03, 2016, 10:33:41 am
content: INT0 on sheet 3 goes where? On sheet 1 I cannot find INT0...?Sheet 5 has some missing lines for the clock circuit for the audio chips.Also I now see that both chips are in parallel on everything. That does not make sense to me. If you want stereo sound you should be able to control both channels separately - otherwise just use one chip and tie the stereo inputs of the output amp together...I scanned the document on interrupts and using the 8259 does introduce extra house keeping. You could argue that this complexity is unnecessary because the interrupts are only provided as a service to the expansion bus - they're not used for the board itself. Like I said before, expose on vectored interrupt on the bus, the rest is an extension...Do you think this will all still fit on a regular sized board?

author: ron.owens
author_rank: Regular Contributor
timestamp: March 03, 2016, 06:10:58 pm
content: I'm working on the interrupt signals and I should have a new schematic soon. I'm also working on the sheet tags, they need a lot of help. I changed the clock source on the Sound Generators and that is now corrected in the schematic. The YMZ284 chips are paralleled except for the chip select lines. I need to resolve the additional chip selects in the Address Decoder GAL on page 1. The updated schematic will be a lot more complete when it is posted.I was planning on waiting for the code development on the Priority Interrupt Controller until after most of the board was up and running. I may temporarily wire the VIA interrupt to /IRQ0 to bring the board up, then change it back to being connected to the 8259.The current board size is 8.25 inches x 5 inches (224.8mm x 127mm). I doubt that's a standard size. I hadn't considered a standard footprint because it was more or less a one-of-kind design. Let me know if you are familiar with a stand size that this may fit. I am willing to change the board size to match something standard.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 04, 2016, 10:51:01 am
content: I'd check probable board size against cheapest manufacturer sizes and adjust from there.If I search for a 2 layer 8.25x5" pcb for quantity of 10 on pcbshopper - its about (US) $90,= Ouch.I am planning small (10cmx10cm (about 4" square) I think) modules for my own design. Cost will be down and I can develop/upgrade separate modules. Modules are strung together with the two 40-pin ribbon cables.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 04, 2016, 12:26:58 pm
content: I'll check out the current PCB size against prototype boards I can find from China on eBay. My board cost is more ouch than you thought: 4-layer, 5 boards ~145.00US.Update schematics are coming today.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 05, 2016, 12:40:23 am
content: I forgot to upload the USB interface board for the Flash memory stick. I should be getting 5 of these boards next week. This board works like a 28-pin carrier and goes in the MOD1 socket on the Z180 SBC.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 06, 2016, 02:14:02 am
content: It would seem the largest 'standard size' prototype PCB is 100mm x 80mm. The Z180 SBC is considerably larger than that. On the other hand, it's smaller than some VME boards. Unless there's a good reason to have a specific size, it looks like it will be a standard of it's own.I spent a lot of time working on the sheet tags in the schematic. It's not easy to do that by hand. I really wish Eagle had a ULP for this. I also brought out the audio signals going to the speaker amplifiers to the Expansion Bus. There were a number of 'spares' and it is only two signals. Who knows. it may come in handy.I've attached the latest schematic. It looks like it's getting close to ordering boards. I wonder if it would be worth adding a prototype area with .1" x .1" plated through holes. It would be a nice feature, but it would increase board size and cost. Let me know what you think.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 06, 2016, 07:25:31 am
content: (prototype) Eurocards are 100mm x 150mm ...With standard size I meant a size (like 100mm x 100mm) that the pcb houses uses as standard and will allow you to manufacture cheaply.I would not add anything at all to the pcb.I just noticed the !BUS_OWNR signal. What is it for?Other than that it looks fine. I am curious to see the board layout. Have you started on that already?

author: C
author_rank: Super Contributor
timestamp: March 06, 2016, 01:43:09 pm
content: MSM58321http://pdf.datasheetcatalog.com/datasheet/oki/MSM58321.pdfThis chip will cause a buss conflict with the logic you have now.A problem does not go away by not reading all of the data sheet.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 06, 2016, 02:20:28 pm
content: Here's the PCB layout for the Z180 SBC. It still needs some tweaking with renumbering and such. I have routed the +5V on the 2nd layer and the 3rd layer is a ground plane. I will also use the 2nd layer for signals, if needed, but I plan to keep that to a minimum.v The current size is 225mm x 127mm.Thanks for the pointing out a problem with the Real-Time clock. Can you elaborate on what you found? That would be very helpful.The /BUS_OWNR signal establishes who is in control of the buses, the local processor or something on the expansion bus. I got this from earlier conversations regarding the expansion bus. It is currently not defined as to exactly how the signal is generated or works. I have yet to get into the details of the programmable logic chips. I thought it may be handy since the GAL16V8 looks at all the signals that should be needed to make it happen. Let me know if you think I'm on the right track with this signal and if it would be useful.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 07, 2016, 06:44:08 am
content: That is one big dense board! Nicely done!When the CPU signals BUSACK it clearly does not have control...I don't think you need BUS_OWNR...

author: ron.owens
author_rank: Regular Contributor
timestamp: March 08, 2016, 07:37:02 pm
content: I plan to leave the /BUS_OWNR signal on the board, for now. It could always go away at a future date. Who knows, it might actually be useful.I created an alternate schematic that includes an arithmetic processor for floating point math. This chip, AM9511/8231 would be entirely optional. Software could check if the part is installed and only use floating point functions if it is. I felt there was just a little too much empty space that begged to be filled. I have to attach the datasheet for the APU separately.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 08, 2016, 07:56:55 pm
content: Here's the AMD version of the arithmetic processor. Intel (and others) made the same part, 8231.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 09, 2016, 08:49:42 am
content: 12vI don't think I have ever seen that on a digital chip...I am currently routing my own board and I am curious how you have done your routing in such a dense board. Care to share?

author: ron.owens
author_rank: Regular Contributor
timestamp: March 09, 2016, 12:27:17 pm
content: On a board like this I always use ate least 4 layers. I make one internal layer a single ground plane. I normally also make a power plane on the other internal layer, but on this one I used this layer to route +5V and any other power signals. This way I could use this power layer for some signal routing, if needed. It's important to use an internal layer for any solid plane. It helps keep the board from warping, and a board this size can warp pretty easily.I set my clearances to 6mils and distances to 8mils. I use .01" traces for signals and .024" for power (wider is less inductance). I use .015" drills for all signals. I usually use .023" drills for power. Not all board houses can make boards with these geometries, but most can.Next I route the +5V layer. I have to make sure it is completely routed before using the autorouter. I only use the autorouter to verify my layout is routable. I save the the board right before I start the autorouter and then reload the board without saving to take me back to were I was before using the autorouter. As wonderful as the autorouter is, it does not route with any insight at all. It's a lot like using GPS, it will get you there, but takes the most unorthodox path to do it. It has a tendency to go around it's elbow to get to it's nose.If the board routes 100% you could just generate Gerber file and order a board. It would also look butt ugly. Cleaning up after the autorouter is more work than hand routing.I usually use the top layer for vertical traces and the bottom layer for horizontal traces. At first this will create a lot of vias, even for a board with a lot of through-hole parts. The vias will become fewer as you have to rip-up and re-route.I've found on most boards signals, and their traces, are clumped around groups of parts. This leaves traces that connect the groups. I route the local groups first and then connect groups. This seems to minimize the amount of rip-up. If the longer interconnecting traces become 'squiggly', consider ripping it up and starting from the other end.Routing PC boards is an art. It takes practice to get good at it. I have ripped up a completed board and started over just to get the experience. I often found the second, or even third, go at it produces a cleaner and neater route. I usually only do this on my own stuff at home, my boss isn't so understanding about taking two or three times longer to get it done just to make it look better.I use Eagle and have done so for nearly twenty years. I've used Pads and Mentor professionally, but Eagle is the only affordable package to use at home. Even then it's worth spending the money and get the better version. I use pro and I probably have over $1,000 invested in it. It's worth every penny! For me, drawing schematics and laying out PCBs is the most fun I can have with my clothes on.Let me know if you have questions or need any help. I'm glad to be of assistance.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 19, 2016, 01:48:13 am
content: I finally got the Z180 board routed. I've attached the board order files, including the Eagle CAD files. I'm pretty sure it's ready to order. If anyone sees any need for changes, please let me know,

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 19, 2016, 06:29:00 am
content: Wow that looks really impressive.I could not spot any problems - but then I am not a pro

author: ron.owens
author_rank: Regular Contributor
timestamp: March 29, 2016, 09:07:21 pm
content: The boards arrived today, It only took 8 days from order to received, very impressive. The total cost was $176 USD, very reasonable. I've attache photos of the front and back of the boards. They look perfect. I can't wait to get one built.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 29, 2016, 09:10:40 pm
content: I see I missed the back side of the PCB.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 30, 2016, 07:26:22 am
content: That looks really nice!I am curious how the build will go.Any ideas yet on the software?

author: ron.owens
author_rank: Regular Contributor
timestamp: March 30, 2016, 12:26:05 pm
content: I'm about 80% along with the build. I want to get all the passive parts and sockets on and then test power before installing and chips. Less chance of smoke that way. I'll post more pictures when I get it assembled.As for software, I want to use a ROM monitor to help bring up the hardware. This way I can check out stuff a piece at a time. First I want it to say "Hello World" over the Serial port to verify the CPU is running and the serial port is correct. I have an open source ROM monitor that was originally written by R. A. Surwilo in 1985 and maintained by D. R. Gibson through 1988. It was originally released as 18E - Z80/HD64180 Debug Monitor and has a copyright warning. It has a paragraph that follows the warning that says it was released to the public, but the warning was not removed. This monitor was written to work with several different flavors of Z80 and can be configured for different hardware and assemblers. It is written in Z80 assembly language. I have Softools' WindIDE and the monitor assembles without errors. I have to set a lot of assembler directive switches to configure it. I may just copy out the most basic parts as a separate piece of code just to get the board functional. If anyone is interested I can post the source code I have for the monitor.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 30, 2016, 01:06:51 pm
content: Yes, passives and sockets first then the semi-conductors!I think I have seen that monitor. It's a simple principle and you could expand the command set to call into test routines for all the peripheral chips you've got on the board. That way you can build a code base that has working IO routines for those chips.I am planning on doing the same for my Z80 board...

author: ron.owens
author_rank: Regular Contributor
timestamp: March 30, 2016, 03:02:48 pm
content: I'm about 75% done with the build. I'm waiting on some parts that have to travel 1/2 way around the planet to get to me.So far it is going very well. I really miss this part!I have a ROM monitor program I found on the web that covers a number of Z80 flavors. It has a number of selections that need to be made to determine which CPU, assembler, etc.. I also have Softools' WinIDE assembler for Z80 I bought when I started this project. The ROM monitor assembles without errors. That was a relief!It was originally written by Richard A. Surwilo in 1984 and maintained by Damon R. Gibson until 2000. It has a copyright warning followed by a paragraph stating that the warning wasn't removed when the program was posted publicly. Does that mean free??I may just take snippets from it to put together a very simple program just to get the Z180 SBC to come up and say "Hello World!".Let me know if you want me to post the ROM monitor in it's entirety.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 30, 2016, 04:27:31 pm
content: Sorry for the repeat post. I didn't think it worked the first time. Oh well... all good stuff worth repeating.

author: ron.owens
author_rank: Regular Contributor
timestamp: March 30, 2016, 04:44:30 pm
content: FYI...Just in case this project wasn't enough of a time drain, I started schematics for a MC6809 version of this board. It will use a 74LS610 Memory Management Unit to expand the address bus to 1MB. It will have a lot of the same good stuff that has gone into the Z180 board and the same footprint/form factor. The end result of that project will be to have a SBC that can run OS/9. I'll create a separate post when I get further along.It's my hope to have the Z180 SBC run CP/M and maybe do Atari type game stuff. I guess that means the add-on board will be for color graphics and joysticks. Good thing it has a USB port for a large memory stick!

author: obiwanjacobi
author_rank: Super Contributor
timestamp: March 30, 2016, 05:06:09 pm
content: Why not a 68000 family one...?

author: feilipu
author_rank: Contributor
timestamp: May 15, 2016, 02:14:04 pm
content: Sorry to join the conversation late.I'm very interested in this process.I was just thinking of building something similar, and pretty much all of the design work is similar to what you've done.I also just noted that the connections for the two parallel ports are not the same. Is that by plan or coincidence?Pin 6 8 10 and 12 specifically.Good luck. Will be reading along.

author: ron.owens
author_rank: Regular Contributor
timestamp: May 15, 2016, 06:08:42 pm
content: Never too late. In fact I'm getting ready to post some more stuff on this board.To answer your question about the parallel ports, I had originally designed the B port to be a SPI Bus with individual chip select lines. I was going to use the internal shift register of the 6522 VIA to shift SPI data in and out. The design required a separate 3-state buffer to make it work. After cramming more stuff on the board I decided to remove the SPI stuff and make it a TTL port. I never got around to remapping the pins to making it the same as port A.One little detail that is very embarrassing I forgot to post after I received my boards. Due to some error in the Eagle CAM utility to create the Gerber files did not create the ground plane on an internal layer. This means all of the ground connection are not connected at all. I had to wire all of those connection pin to pin. It should still work, but all of the benefits of a ground plane are gone.I'm currently working on the GAL for address decoding to get the board up and running. The first goal is to get the board to send a simple "Hello world" message over serial port 1.

author: ron.owens
author_rank: Regular Contributor
timestamp: May 15, 2016, 06:10:22 pm
content: In fairness and complete disclosure, here's the back side of the board.

author: feilipu
author_rank: Contributor
timestamp: May 16, 2016, 02:10:57 am
content: It was very fortunate for me to see the progress of your designs.I am starting to think about doing something similar, and am probably about 12 months behind where you are right now.Basically, I'm rationalising the right frame to build a solution for myself.Not too small, and not too big.I like to work with bare metal solutions, so I think going the full CP/M solution may be missing my point of interest.Stack180On the other hand, I do like smaller embedded RTOS and writing with C, so too small is also not right.Having said that, I've actually already purchased an RC2014 solution, to cut my teeth on Z80 assembler.RC2014My view of the perfect starting point is basing the design on the Z8S180.It has some improvements in power reduction modes over Z80, and is fully static.Also the clock generation, timers, USARTs and some other messy 1970s things are handled on chip,making the overall system design more robust (and easier).I would build the board the maximum compliment of SRAM (1MB), with the lower 64kB Bank 0 comprised of FRAM.Now that FRAM is available there is no sense to use Flash in kB sizes, with its limited lifespan and slow write speeds.I would focus on modern interfaces usingI2C-ParallelandUSB-USARTinterfaces to expand and access the board.You can even drive video off I2C, withFTDI EVE, and this works great.I was thinking of being original and using anFT245Rdevice for programming the FRAM, and avoiding the need for a bootloader by writing direct to FRAM.But it turns out thatPhilip Jacob Smith has already done EEPROM programming with USB... there's nothing new left in the world, it seems.So what I'm looking for, I think you've already built.I like the idea of having a RTC on board. It is one thing that I always need on my previous AVR solutions.I wouldn't bother to take the Z180 address & data bus off the board, as this may cause problems at 33MHz.Doing this also makes the board very busy, with all of the bus buffer, and interrupt management chips.Your use of the R6522 to provide parallel I/O interfaces is enough, I think.If it can't be covered by I2C, USART, or Parallel, then it is out of scope for me.Anyway, that's my 2C right now. Your starting point is already 90% of where I think I'm heading. So thanks

author: ron.owens
author_rank: Regular Contributor
timestamp: May 16, 2016, 08:47:23 am
content: feilipu,I'm glad you like the design. I can't post the Eagle files for the Z180 board due to the blog's file size limitation. Perhaps you can send me your email address in a blog message I can email the project to you. That would let you modify the project to fit your needs. I only have it in Eagle format as I've been using Eagle for the last couple of decades. I like to think I've finally got the hang of it.Cranking up the speed to 33MHz will probably require a number of changes. First, the L/O in this design will be very slow for that fast a CPU. That would mean a lot a wait states to talk to I/O. Secondly, I'm fairly sure all of the memory is going to be too slow. And you are right about the external bus not working at that speed.My plan for serial comm was to use an external USB to serial module to talk to a PC and set the Z180 on-board jumpers to TTL and use the TTL port. I also planned to use the 2nd serial port for debug, mostly spitting out progress statements to a log file as it executed code. I went with 80's vintage serial ports mostly out of nostalgia, which is the primary reason I did this design in the first place.You can still use a Z8S180, I think they are pin compatible to the Z180 I used. You can also use the Hitachi part, HD64180. All of these chips are readily available on eBay. In fact, everything that goes on this board can be purchased online. I plan to post a list of the vendors I used, along with a real bill of materials as soon as I get it done.I also plan to post the code for the GALs on board and any Z180 code I get working.

author: feilipu
author_rank: Contributor
timestamp: July 14, 2016, 02:00:08 pm
content: Well its taken about 2 months to move from ideas to PCB Order, but it has happened.Yet Another Z180 (YAZ180) ProjectPretty happy that I have one item from each manufacturer of the 70's devices on the board (just missing Motorola).Zilog Z180AMD Am9511A-1Intel 82C55Texas Instruments TIL311The next step is to assemble the system, and bring it up item by item.That will probably take another 3 months to 3 years.Such is the nature of a hobby.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 14, 2016, 04:40:40 pm
content: Nice layout. What PCB software did you use?

author: ron.owens
author_rank: Regular Contributor
timestamp: July 14, 2016, 08:48:07 pm
content: Nice job on the PCB layout. It looks great. I see you used PLCC parts more than I did. Do you have a schematic you can post?Cheers,Ron

author: feilipu
author_rank: Contributor
timestamp: July 15, 2016, 01:19:19 am
content: What PCB software did you use?I used Eagle, Hobby licence. Hence the board size limitation to 16cm x 10cm. Manufacturing limitation by Seeed Studio to 4 layer.That pretty much defines my decision making on the physical layout, and why I used so much socketed PLCC.Do you have a schematic you can post?The schematic is on the Web link. Linked here directly for completeness.YAZ180 SchematicYet Another Z180 (YAZ180) ProjectI'd just point out that the CUPL definitions picture for the Address pin input decoding on the ATF16V8 is reversed from what the schematic shows. Swapping the pins ordering meant that I had a clean run for addressing layout, and means changing just one line of CUPL.I'll update the CUPL pictures once I'm actually working with the ATF16V8 devices.I purchased a couple of Am9511A-1 FPUs and 20x TIL311 LED displays, before I finished the layout.I think TIL311 LED devices are still being manufactured, but the Am9511A-1 FPU certainly is not.I'm guessing that the Am9511A-1 FPU may still be about 4x faster than C on the Z8S180. The FPU has to run at 1/6th of the CPU clock, and the CPU ALU can run at double the CPU clock. Anecdotally, the FPU was 50x faster than CPU in the 70s, but today I guesstimate it to be about 50/(6x2) = 4. But, optimising floating point code across both platforms (CPU & FPU) will be an interesting experiment.I put TIL311 LEDs on the Address and Data lines. Data display is blanked unless #WAIT is asserted. But, I left Address display running because a locked up subroutine may uncover itself by locality persistence in the Address space. The 82C55 Port B also has 2x TIL311 LED, which are latched by Port C Bit 1.

author: feilipu
author_rank: Contributor
timestamp: January 14, 2017, 12:05:55 pm
content: I've reached a key interim milestone in this build of a Z180 SBC.After having the project being on hold for months waiting for Lattice GALs to arrive from China eBay (because my TL866 programmer won't program Atmel PLDs), I've finally gotten the YAZ180 to the stage it is "useful". Useful in that it can runNASCOM BASIC Ver 4.7, and can read and write a serial console.The next step is to convert to programming using the FT245 USB to parallel port, and integrate thez88dkC environment.More progress notes on myYAZ180 Post.

author: rrinker
author_rank: Super Contributor
timestamp: January 14, 2017, 09:11:22 pm
content: Nice. A lot of old 1802 guys would kill for a pair of those TIL311's.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 16, 2017, 09:11:14 am
content: Yeah those TIL311's are hot! (litterally!)

author: feilipu
author_rank: Contributor
timestamp: February 26, 2017, 07:21:15 am
content: I've finished withYAZ180 v1, and have ordered a revised PCB which addresses the issues I found.The new PCB for theYAZ180 v2has been ordered.

author: feilipu
author_rank: Contributor
timestamp: May 11, 2017, 05:54:02 am
content: I've done another revision of theYAZ180board,and have added an IDE interface capability to the 82C55 PIO device.Still going through testing.It is now clear that the Am9511A APU needs additional logic, to gate WR with E Clock, to work effectively.The IDE interface, and I2C interface, are being tested now.Might take me a few months to generate the drivers for these interfaces, but that's the fun.

author: ron.owens
author_rank: Regular Contributor
timestamp: May 11, 2017, 12:20:33 pm
content: That is a great looking board. I agree with Obiwan about the TIL911's running very hot. They do look great and are a big help in debugging code.It would be very nice if you could post the schematic of your board. I'm very interested in seeing your solution for the Am9511 and the IDE interface.

author: feilipu
author_rank: Contributor
timestamp: May 11, 2017, 12:52:31 pm
content: Sure, I've attached the schematic to this post.The IDE interface is derived from the work ofPJRC, who derived it fromPeter Fraasse. I did make some changes to retain generality for the 82C55 interface. Some of the Port C lines are required to be inputs, in Mode 1 and Mode 2. Both Paul and Peter chose to run those lines through inverters, which prevents them being used as inputs. Note I'm still translating Paul's 8051 code, so this is a work in progress.The Am9511A is sensitive to feed and water. I've gone through three iterations trying to get it to work. On the Z80, the standard configurations work fine, but with Z180 the timing of CS, WR, and the data lines is wrong. I've put some months into getting it running, but now I thinkI have it right. But, there's still testing to be done.This image is doing a floating point divide in 179 Clock Cycles - from end of CS to End Interrupt. In the first iteration I was using Phi/6, but that only worked at 9.216MHz. I've now moved to using Phi/8 or 2.304MHz, off the full speed 18.432MHz Phi. Using the E Clock signal to generate a short WR signal provides the Am9511A with the 30ns it needs after WR to latch data. Normally, the Z180 only provides 5ns, which is insufficient.The Am9511A also runs incredibly hot. Finger dwell time is less than two seconds. I don't know what that converts to in Celcius. Initially I thought I'd done a circuit oops. But, they consume about 70mA of 5V and 70mA of 12V, so there's lots of power being dissipated. In comparison, TIL311s have an infinite finger dwell time. They're hot, but not unbearably so.I'm looking forward to getting the I2C interfaces running. Then a lot of options open up.

author: grumpydoc
author_rank: Super Contributor
timestamp: May 11, 2017, 05:19:03 pm
content: Nice board.If I ever get my current Z80 project -https://www.eevblog.com/forum/projects/z80-single-(perf)board-computerrunning I plan on using a Z180 or maybe EZ80 rather than the "plain" Z80 for the next build.

author: feilipu
author_rank: Contributor
timestamp: March 19, 2018, 05:17:51 am
content: To close the loop on this YAZ180 project after nearly two years of work, from my point of view, there is:a Github repository with all theGerbers, and board layouts for the current Version 2.2 PCB.ayabioscreated that allows applications developed withZ88dkto be loaded from serial ports or fromFATFS formatted IDEhard drives.yabios v0.6 provides all of the features required to build multi-bank (>60kB) applications.support forCP/M v2.2applications with the ability to read files off a FATFS formatted IDE hard drive as CP/M drives.access to the internet via theESP01SandJeelabs ESP-Link.satisfaction that it has all worked out, considering I had no idea what I was getting into.I'm continuing to work on applications for the YAZ180 platform now, and I am focusing on FreeRTOS, number crunching with Am9511A, and interfacing to the real world with the I2C interfaces. This work guarantees me at least a few more years of further fun and games.