DIY Z80 Build

[jdgabbard]

I think this might be the most appropriate location for this topic, considering that the TRS-80 used a Z80. I'm in the process of putting together a Z80 based computer. This is being breadboarded now, and will eventually be etched. But I have a couple questions that I thought maybe the Tandy guys/gals could answer, or at least point me into the right direction.

 

I've already set up a test circuit and confirmed the CPUs that I have are working, this basically just sends NOPs to the CPU from the data lines. The specific Z80 variant I'll be using is the z84c0020PEC. The other chips I've settled on at this time are the TC55257PL-10 32k SRAM, UPD82C55AC-2 PIO, Z084406PSC SIO, and a MAX232. Obviously there will be some glue logic: 74xx14, 74xx04, 74xx32, etc... And a EPROM (still working out the size I'm going to go with. Which brings me to my next issue...

 

I've never written assembly. I can write some C derivative code, but have never touched bare metal. I don't fully understand how all the addressing works, but have a generalized idea. But where I'm a little stuck is how the addresses work with the Assembled code. Let me say this another way: My understanding is that whatever OS gets put on the EPROM, the addressing will be specific for "X" hardware, and might be broken with what I build. Now that is easy enough with address decoding I would assume. But do most of the OSes out there have a function that searches for peripherals and then labels them appropriately, or is this something I can expect to do on my end before first boot?

 

Second question, I know there are a lot of the old OSes out there available somewhere on the webisphere, Do you Tandy guys ever swap EPROMs on your machines for a different OS? If so, which ones are in the Public Domain now, and can anyone provide a link to or have a copy of any of theses? I found a copy of the 8KBasic (http://www.nascomhomepage.com/lang/8kbasic.asm) , but I must be too stupid to figure out how to compile it, as every time I try with the Assembler 8080 (Z80 compatible assembler, I've also tried ZASMDOS, same story) I get about 5500 error or warning messages.

 

I have looked at the z80.info site. Problem is that this is not organized very well, and is somewhat difficult to get at the information you're specifically looking for. And many of the links are dead...

 

Are there any Technical Guru's on the Tandy Board that have delved this deep into the z80?

[JamesD]

Computer Hardware Design 101
Page 1

...

You are in luck, I've just been messing with Z80 interfacing and programming.

What's your hardware background?

You are going to want to grab some docs for the Z80 from a Z80 site.
I would start here:
http://z80.info/

You need to understand timing of buss signals in order to get the chip selects, read, write, etc... active at the right times or you will have problems.
IOREQ, MREQ, RD and WR timing are critical.

If you feel daring, try learning Verilog or VHDL. I finally set down and decided to learn how to write verilog and it took me about a day or two to get where I'd call my code decent.
It's actually not that difficult but I have some hardware and a lot of software experience including embedded systems.

Verilog is kinda like software that runs in parallel.

I was able to design a fairly complex MMU, programmable timer interrupt and some other stuff in a few days work while I was learning and when I quit procrastinating I'll add an SD interface and then layout a circuit board.
The nicest part of using a CPLD is being able to remap hardware, alter timing and add new features without rewiring anything.
You just need the I/O signals I mentioned, A0-A8 and D0-D8 as inputs. Once you have that you need chip select outputs for RAM, ROM, etc...

As far as software goes, CP/M, MP/M, Uzix, SymbOS or FutureOS are options.
CP/M would be easy. You just need to write a small section of code to interface a few routines to your hardware, there is a table at the end of the CP/M code with the list of routines. Then you have to set the available RAM for the existing code and create a bootstrap for all that.
CP/M 3 supports paged RAM if I remember right. It would impact your hardware design so you'll have to read up on if before you go to far if you want to go that route. My design had to page RAM at a different address space so I can't support it without a lot more code.

MP/M is like CP/M but supports multi user.

Uzix is sort of a Unix for the Z80. It takes more RAM than CP/M but I would say it's more powerful. It's a tradeoff.

SymbOS is an OS + GUI and you'd need to port it to your hardware. I'm guessing FutureOS is similar but I haven't really looked at it.

If you want easy, I'd go with CP/M.
I also suggest an IDE port based on the TRS-80 lo-tech interface.

some other links:
http://www.cpm.z80.de/drilib.html
http://nemesis.lonestar.org/computers/tandy/software/os/logical_systems/lsdos6/src631/index.html
http://obsolescence.wix.com/obsolescence#!cpm-internals/c247i
http://www.uxpro.com/cpm/www.cpm.z80.de/develop.htm

http://www.benryves.com/journal/tags/Z80
http://www.retroleum.co.uk/z80-ideinterface.html
http://www.lo-tech.co.uk/trs-80-ide-hard-drive-interface/
http://www.cosam.org/projects/z80/

Edited May 3, 2015 by JamesD

[jdgabbard]

Thanks for the reply James. My hardware background is remedial at best. I decided to take this project on as a learning project. I've written some stuff for AVRs with AVR Studio, and obviously started on Arduino IDE. But as for background, it's basically all self taught through trial and 'lots of errors.' The latest project was a rover style bot, but it was lacking in the bridge design. Still working that one out.

 

I've read through a lot of the links that you've provided already. But found the information lacking because it either provides a broken link referencing what it is talking about, or speaks in a cryptic language that is not well defined for the novice.

 

I am not familiar with Verilog or VHDL, I'll have to take a look at them this evening. I do have the documentation by Zilog for the various chips in PDF format, and have scanned through them on various topics to get a better understanding of some of the different aspects. One think I haven't seen is any information on address breakdown. Ie, pins A0-A3 = <insert address range>.

[JamesD]

Ok, I'll see if I can explain a couple things about the Z80 that might help.

The Z80 doesn't use memory mapped hardware in the same way as the 6502, 6809, 6803, 6800, etc...

It uses what are referred to as I/O ports. Technically, it is memory mapped but you only have to test address lines A0-A7 (I think I said A8 above... oops) to see what port the CPU is trying to access instead of A0-AF.
IORQ signals access to an I/O port and MREQ (I think that's what it's called anyway) signals access to memory. So you have to do address decoding for RAM/ROM separate but that is usually a large block so you don't have to test the lower address bits anyway.

Addresses are whatever you want them to be. You can put anything anywhere you want it. Just remember that the Z80 starts executing code from address $0000 when you turn it on or reset it. So you need a bootstrap ROM at the base of memory. You also have to check where interrupt vectors are located and the Z80 has several levels of interrupts. The Z80 prioritizes interrupts so more important pieces of hardware can be responded to before less important pieces of hardware. For example, you may want to make an interrupt related to disk I/O and serial I/O more important than printer I/O or keyboard I/O. You can prioritize interrupts based on speed of the I/O device.
Many Z80 copies do not support multiple interrupt levels including many of the high speed pipelined models so you have to design the hardware and software accordingly..

The IORQ and MREQ signal goes active before the read or write line. This will allow your address decoding circuit to detect the address and start decoding along cascaded gates so the circuit will be settled by the time the Read or Write takes place. I don't know how older hardware deals with the chip select but I trigger it based off of the request lines AND the read write lines. Older hardware might tie Write to the write line and MREQ to the chip select.
Write remains active for a relatively long part of the clock cycle so your hardware has plenty of time to switch from a read to capture the write. Read is pretty short and only a little longer than is required for the Z80 to capture the data.
Timing may differ on different Z80s or clones. There were timing diagrams in one of the Z80 books off of the Z80 info site.

All handshaking signals are active low (zero). So when you get an IORQ, that line is 0, when you get a MREQ that line is zero, when you tell a RAM you want to write, that line is zero, when you want to select a chip, that line is zero, etc...

That's not just Z80 but normal for ROM, RAM and most(?) hardware devices.

[JamesD]

...

It uses what are referred to as I/O ports. Technically, it is memory mapped but you only have to test address lines A0-A7 (I think I said A8 above... oops) to see what port the CPU is trying to access instead of A0-AF.

...

Perhaps I should have said A0-A15 instead of A0-AF.

[jdgabbard]

I thought that the way the addressing worked was based on binary of the Addressing lines? And this is what is exhibited by the CPU when the processor is being fed NOPs, it just cycles up in binary to 65,536 looking for something to do?

[potatohead]

Yeah.

 

It's binary. Each address line has two states, and there are X unique states given Y address lines. 8 address lines = 256 states, or %11111111 etc...

 

He's talking about I/O, and that's a special operation that addresses communications using some of the address lines so that the memory is just memory. In this way, another address space is created, and the I/O happens in that address space instead of being shared with the memory space.

 

6502 systems don't have this facility, and everything gets stuffed into the 64K address space, I/O, RAM, ROM, etc...

[JamesD]

Also note that many Z80 machines memory map things like the keyboard, video, etc... due to the amount of space it takes up.
The TRS-80 Model I/III/IV, Laser VZ200/300, etc...

[JamesD]

I thought that the way the addressing worked was based on binary of the Addressing lines? And this is what is exhibited by the CPU when the processor is being fed NOPs, it just cycles up in binary to 65,536 looking for something to do?

I/O ports are based on the lower 8 address lines so address decoding requires less hardware.

When chips and board space were expensive this was a great idea. It also lets RAM or ROM completely fill up 64K of memory space without hardware I/O stealing space.

The Z80 uses the same address and data lines whether it's I/O or a memory access, it just uses the IORQ or MREQ lines to differentiate between the two.

 

If you want built in video on a Z80 machine, some of the best chips you can use are the V9938 or V9958.

They only require a few I/O ports and use their own video RAM so they don't steal any main memory. They also support 80 column text which makes compatibility with CP/M or MP/M easier.

The Memotech MTX is probably the closest machine to that built back in the day. It used the 9918 or 9928 which do not have 80 column support so it's CP/M compatibility was probably limited.

 

[jdgabbard]

Now I'm assuming that when we're talking about peripheral addresses (ie, PIO/SIO are what you're referring to as I/O), they use the 8-bit DB, the specific chip I'm looking at uses the A0-A1 as well. So I'm I to assume that the addresses for the peripherals are held within, and determined by, the PIO, or in this case the 82c55?

 

James, that looks like a great option for a video display, but I cant tell if either one is NTSC or PAL? I have been looking at how I was going to supply video. I'm am assuming that one is PAL and one is NTSC... Any idea which one is which??? Also it looks like, on the datasheet, that it uses 1-bit or 4-bit DRAM??? It says on page one of the Yamaha Datasheet located here (http://pdf.datasheetarchive.com/datasheetsmain/Datasheets-110/DSAP0015970.pdf) that it uses 16k x 1b, 16k x 4b, 64k x 1b, and 64k x 4b DRAMS. I don't have any in my stock, so I'd have to order some, but considering the V9938 is as cheap as it is, I don't think that would add a lot of cost...

 

This would actually fit well in my idea for a board layout. I'm planning on using peripheral expansion slots in the form of Edge-Card connectors that are connected to a large bus. They're easy enough to etch, so this makes them desirable, versus a simple GPIO header that would likely break the traces away from the board the first time a slight twist happens. The only down side to this is that I'm looking at trying to keep this relatively compact, read: 4x6 main board, so things are going to be tight already. And considering this is going to be etched, I've got all of the normal concerns about not having any throughhole plating, so most of the pads will likely be on the bottom side only with simple vias on the top to get to the bottom without having to worry about the socket being in the way. What this all means is that I'll likely only have room for maybe 2 expansion slots. And I'm ok with that, as I plan on having one as a graphics card, and the second as some type of storage media. Possibly CF flash as I have plenty of cards at my disposal. This makes the board layout extremely cramped, as I plan on having, at least, the Z80, a SIO & Max232, clock circuit, reset on power-on circuit, and the basic glue logic on the main board. I'd also like to have the PIO on it as well, but at this point I'm not entirely sure I'll have the room, and may have to do without a storage media unless I design a breakout board with a few additional headers on it. But then I basically loose sight of being somewhat compact. There I go rambling...

[JamesD]

Now I'm assuming that when we're talking about peripheral addresses (ie, PIO/SIO are what you're referring to as I/O), they use the 8-bit DB, the specific chip I'm looking at uses the A0-A1 as well. So I'm I to assume that the addresses for the peripherals are held within, and determined by, the PIO, or in this case the 82c55?

The PIO/SIO chips themselves use the 8 bit data buss to transfer data to/from the processor.

If they use A0 - A1 they they can occupy up to 4 I/O ports (binary 00, 01, 10, 11). These would contain internal registers for sending/receiving data and/or configuring the device. A serial port would need baud rate, parity, and start/stop bit settings for example.

The chips will also have a chip select pin.

 

Additional hardware looks at IOREQ and A2 - A7 to determine if:

1. The CPU is trying to access in I/O port.

2. If so, what address it is accessing to activate the proper hardware device's chip select.

 

If you want a PIO/SIO port like you mention to be addressed on I/O port with the binary address 00000000 - 00000011, you have to check A2-A7 to see if they are all zero. You could check the address easy enough by ORing A2-A7 all together. If the result is 0 and IORQ is low (active) then you make the chip select for the serial chip active (low).

 

There are cases where a chip stacks registers internally so they don't take up a lot of address space or I/O ports on the target machine.

A good example of this would be the General Instruments AY sound chips (and Yamaha derivatives).

They have many registers but only occupy two addresses/ports.

The first port tells the hardware what address you want to access on the chip and the 2nd lets you read/write to that port on the chip.

It has an internal "latch" (register) that sets up the internal address lines that pick what register is visible at the 2nd external address.

 

James, that looks like a great option for a video display, but I cant tell if either one is NTSC or PAL? I have been looking at how I was going to supply video. I'm am assuming that one is PAL and one is NTSC... Any idea which one is which??? Also it looks like, on the datasheet, that it uses 1-bit or 4-bit DRAM??? It says on page one of the Yamaha Datasheet located here (http://pdf.datasheetarchive.com/datasheetsmain/Datasheets-110/DSAP0015970.pdf) that it uses 16k x 1b, 16k x 4b, 64k x 1b, and 64k x 4b DRAMS. I don't have any in my stock, so I'd have to order some, but considering the V9938 is as cheap as it is, I don't think that would add a lot of cost...

 

This would actually fit well in my idea for a board layout. I'm planning on using peripheral expansion slots in the form of Edge-Card connectors that are connected to a large bus. They're easy enough to etch, so this makes them desirable, versus a simple GPIO header that would likely break the traces away from the board the first time a slight twist happens. The only down side to this is that I'm looking at trying to keep this relatively compact, read: 4x6 main board, so things are going to be tight already. And considering this is going to be etched, I've got all of the normal concerns about not having any throughhole plating, so most of the pads will likely be on the bottom side only with simple vias on the top to get to the bottom without having to worry about the socket being in the way. What this all means is that I'll likely only have room for maybe 2 expansion slots. And I'm ok with that, as I plan on having one as a graphics card, and the second as some type of storage media. Possibly CF flash as I have plenty of cards at my disposal. This makes the board layout extremely cramped, as I plan on having, at least, the Z80, a SIO & Max232, clock circuit, reset on power-on circuit, and the basic glue logic on the main board. I'd also like to have the PIO on it as well, but at this point I'm not entirely sure I'll have the room, and may have to do without a storage media unless I design a breakout board with a few additional headers on it. But then I basically loose sight of being somewhat compact. There I go rambling...

I thought both chips supported RGB. The V9958 has some additional functionality the V9938 does not.

For more details I would check MSX pages because they were used in some MSX machines.

 

And there's this:

http://primrosebank.net/computers/mtx/techlib/design/V9958-Technical-manual_v1.0.pdf

 

 

Your biggest problem with those two chips is going to be the pin spacing. Printing your own board with those chips might not work out well.

The size of the chips + RAM may be too large for your target board size. If you don't mind dropping to 40 column text you could go to the TMS9118 or 9928.

https://en.wikipedia.org/wiki/Texas_Instruments_TMS9918

 

I planned on making my own Z80 system and was going to use a Z180 and V9958. Both chips are 64 pin with narrow pin spacing.

I wasn't even considering printing a board like that myself.

Edited May 4, 2015 by JamesD

[JamesD]

http://www.gamedev.net/blog/161/entry-2160326-booting-cpm-3-from-an-sd-card/

[jdgabbard]

Yeah, I'm familiar with the 9918, I have 3x TI-99/4a. One with a bad VDP, which I need to order a 9918 and ram for. I had originally been considering looking into it as a VDP for this project, but then thought that the F18A might give me more functionality and still be pin compatable. Either way, I think I am a ways off from getting to that point in the project.

 

The first thing I want to do is get the concept breadboarded. I'm still waiting on a few parts, and once here I'll finish that. Then I want to get the prototype talking over rs232. Once that is done I'll design the basic schematics for whatever addon boards I decide to go with. Then I'll start messing with board layout after those have been tested.

 

I think that this is important, because until I do that and confirm what is working I really won't know what connections I'll need on the bus.

 

Also, this will let me modify whatever code I need to modify while I'm working my way through the board. I'm leaning towards wanting CP/M for the capabilities that it has. Although using something else and adding in functions my not be too terribly hard.

 

I'll have to look at the links when I get to the office, and I'll comment on those afterwards.

 

James, if you would, what software are you using for writing your assembly? I've downloaded several, but all have been poorly documented and somewhat confusing in their general use.

[JamesD]

To be honest, I've just been using tasm (Telemark Cross Assembler package).
I write code for multiple CPUs and I didn't need multiple assemblers by using it
You will run into incompatibilitys from one assembler to another pretty much no matter what you use if the code takes advantage of any unique features of one particular assembler.
Tasm probably has more than it's share of differences but it does work fine for what I've worked on.

I switched some 6502 code to as65 because it came with the CC65 compiler and it's what someone else was using.

[jdgabbard]

See, I couldn't even get TASM running on Dos Box... Sometimes having a 64bit PC sucks....

Anyhow, I found an interesting read on the TMS9918 this afternoon at work. It looks like someone has already used it for a edge card board similar to what I had envisioned, so reverse engineering the project might be worth the time. The down side, is this was all built around the 6502. So its not exactly a perfect solution. But should work with some changes to code, and a little hardware tweeking if needed. See the link below:

 

http://www.classiccmp.org/cini/pdf/byte/Hi-Res%20Graphics%20TMS9918%20BYTE%200882.pdf.pdf

[JamesD]

Just be aware that the 6502 does not have IORQ, MREQ (or whatever it's called) and uses a single read/write line instead of separate ones.

[jdgabbard]

Just from looking at the pinout and reading the article, it looks as though the read enable (CSR) could be connected to RD. CSW is write enable, and likely needs to be connected to WR. These could be connected through NAND gates I would think.

 

There is a page someone on using the z80 with the 9918, I'd just have to find it and see how he did it. Either way, the link above is s good read. It's written by Ciarcia.

Edited May 6, 2015 by jdgabbard

[JamesD]

Just be sure you don't confuse pins for controlling VDP RAM with pins used to interface to the CPU. I'm not going to look them up myself.

 

To keep the 9918 to 40 pins, address and data lines are multiplexed. (they share pins and alternate function during different phases of the clock cycle)

So you'll need to deal with that (The AD0-7 pins)

If you can use at least the V9938 you don't have to deal with that.

You can use SRAM for the VDP if you do something like this:
http://bitcycle.org/retro/spectrum/SRAM_replacement/

Here is a 6809 machine with a 9918
http://www.msarnoff.org/6809/

Notice he uses SRAM as I mentioned could be done above

 

Here is some Z80 code to get the 9918-9958 up and running:
http://www.s100computers.com/My%20System%20Pages/VDP%20Video%20Board/HW9938.pdf

[JamesD]

This might be of some help
http://zx80.netai.net/grant/cpm/index.html

[JamesD]

*bump*
Just curious how far you got jdgabbard

[jdgabbard]

Oh, it's still a work in progress... What takes so long is waiting for parts. I'll decide I need something, then order it. Half the stuff on fleebay comes from China. So there is usually a several week delay between working on the board. But that's fine, as it gives me plenty of time to think about how I want to build it.

 

Currently it is wired up for ram and rom (switchable between two 32k banks), a UART (a 16C550 addressed at 00h-07h), and a PIO (8255 addressed at 07h-0Fh), and once I get some 24-pin sockets it will have an ICM7170 RTC. But I'm still working that out, as there is a problem. That problem being that with that RTC it needs 5 address lines. But I currently have my address decoding done, leaving only 4 address lines with with the upper addresses being used for chip select signals. So I'm thinking I might use the upper pins of the PIO to fake address lines so that I can still read from it. I'll simply have to write a driver to bit bang it. But I'm sure it can probably be done. Really, I only need one bit to go high on the PIO, and that is to access the command register. So, it may not be critical timing wise.

 

Of course once this is prototyped and confirmed working, I'll likely etch a board. But for now it's Perfboard so I can make changes as I go.

 

What about you?

 

[jdgabbard]

Oh, one thing I forgot to mention. Initially I'll probably go the serial route until I get a decent monitor coded. (Will likely rewrite portions of the ZAP-Monitor to be compatible with my machine). I then plan on expanding by adding keyboard input (I'll be using a TI-99 keyboard) through the PIO. Once that is done the pin header is for an expansion board, I'll probably use the 9918 in text mode. I've been trying to learn assembly as I go. But I haven't sat down with it in several weeks. Things have been hell at work. But I figured a memory check function could be a useful first code to write. I've got the concept down on paper. But still working out the details. It doesn't appear to be working yet (last compile). But the idea is to write a high to every other bit of each address of memory, then check it. Then once at ram-top, go back and rewrite the opposite bits and check.

 

One more useful thing I've been doing is keeping a journal on the build. It has everything from board layout, to pin connections, even ideas. Helps me to not forget during the down times.

[JamesD]

If you put a 4 to 16 line decoder on the upper address lines (A4-A7) for the I/O ports that will break out the ports into 16 byte blocks.
You can use the outputs as chip selects but you'll need logic to activate the decoder for I/O reads/writes.
The chip that requires 5 address lines can also use A4 giving it 32 bytes.
(32? really? You could use a latch to map it to two I/O ports, one for the latch, one for the clock)
I'd map it at the top of the I/O port range.

A 2nd decoder on A0-A3 and some logic could refine that further if you wanted.

[jdgabbard]

Yeah, I already did that. I'm using two 74HCT138s to decode the upper 4 address lines. Then I can break the decoded signals down further (like I did with the UART and PIO) but using the A3 and CS line with an OR (LS32) gate. I havent tested it yet, but it should work fine. Pretty much the same method used in my RAM/ROM space (used Grant Searle's memory design). I've thought about that problem, and also came to the same conclusion as you. As an example: if I were to address the RTC's normal functions at the address range of 20h-2Fh, and the command register at 10h-1Fh, and run A4 to the A4 of the RTC, then it should decode it well enough. But I havent decided exactly how many peripherals this computer may grow to. And have held off using this as a way of thinking it through a bit deeper. I really can't see needing 16 peripherals. However, when you put it into perspective, with 3 of the 16 CS lines being used for the PIO, UART, and the RTC (if I were to do that), and the an additional one used for the 9918, mostlikely another two used for two additional PIOs (one for general IO, and another for Mass Storage), that would only be 6 of 16. And I think that would encompass just about everything I would need. However, you never can tell when you're going to want to add something (say a sound chip). So I am just making sure I do not use up the entire IO address range. I want it to be as efficient as possible when it comes to the address range. Especially since I plan on eventually making a board for this, I might even have a board house cut 10 or so and offer the additional boards at-cost to members here incase they want to play with something without the risk of messing up a vintage PC.

[jdgabbard]

And really, if I were to offer boards to the community, you never know what they will want to add...