Author Topic: Z80 Single (Perf)Board Computer  (Read 21672 times)

0 Members and 1 Guest are viewing this topic.

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Z80 Single (Perf)Board Computer
« on: March 16, 2017, 10:55:43 pm »
The recent thread started by nockieboy reminded me that after the earlier thread covering Z80 interfacing I had promised myself that I would turn the pile of junk Z80 bits that I have acquired into a "useful" computer.

I have a soft spot for the Z80, what feeble electronics I know stems mainly from fixing early computers in the late 70's and early 80's - mostly Sinclair Spectrum's and also designing and building my own Z80 systems. It all really started with a Nascom-2 I built when I was 16 or 17. I also cut my teeth programming on Z80 systems.

I set myself some totally arbitrary design goals:
  • Must support the 20MHz chip (I have one kicking around so why not?)
  • Must be buildable  on 0.1" perfboard so DIP or PLCC in a socket. SOIC on a carrier only as a last resort
  • GALs, PALs and PROMS would be OK but I don't have any way of programming them so in practice glue logic will be plain TTL
  • No wait states!
  • No using a much more powerful MPU to "nanny" the Z80 along (otherwise I might as well just write a Z80 simulator on a more powerful system)
  • Parts must be current, no dipping into the global obsolete parts bin (ebay)
  • Banked RAM for CP/M 3 or FUZIX
  • CF card for storage
  • Video not important, serial console is fine as I probably don't want to play graphical games on it. I can add video later and I might bend the "no more powerful MPU" rule for it, especially if embedded in a COTS display

Sadly one of these wish list items falls pretty much at the first hurdle - no wait states in a 20MHz is probably impossible, at least with banked memory. The problem is that the timing for the 20MHz part sucks a bit.

As usual we start with the M1 cycle which has the tightest timing - here it is  with some of the "worst case" timings for the 20MHz part filled in.



For reference the data sheet with the full timing diagram is here on Mouser See page 20 for the diagram and 31 for the timings.

The Z80 samples the databus with the rising edge of the clock at the start of T3 and needs 12ns data set-up time. The start of the read cycle would normally be based on the falling edge of MREQ - that is referenced to the falling edge of the clock in T1 but the data sheet says it could be up to 40ns after the clock edge - which is 15ns into T2. Thus we have 50-(15+12) or just 23ns to complete the read cycle.

OK, so fast, half meg RAMs can be had without difficulty, although I was trying to avoid SMD package adapters (I can't find a 36 pin one anyway). However it's not that easy.

First off I can't find a E/EE/P or FLASH ROM which I can program and which has a 5V supply which also has an access time of less than 45ns. Yes I could get around that by building a ROM-less system and have something else load up the RAM with boot code but I wanted to avoid that.

Second, any gate delays associated with MREQ or the address lines are going to eat into 23ns pretty quickly. In fact it's worse if you look at the official figure for the address set-up time (TdA(MREQf) - address valid to MREQ fall) it is given as -15ns! so the address bus might not even have stabilised by the time MREQ falls - that would reduce the time available for the access cycle to 8ns!

Sadly I decided to just add a wait state to the M1 cycle, that will stretch the needed access time so I can use much more friendly 55ns SRAM and 45ns flash. Just slowing the M1 will have a fairly minimal impact on performance and, to be honest, extracting the last MHz of performance from a Z80 system is a bit like wanting to be the world's tallest dwarf.

After some thought this is the current state of the design:



I've previously built systems using two 74F189 TTL RAM chips to make a fairly flexible mapping based on 4k pages which will allow access to 1M of RAM. Sadly the 74F189 is no longer available new.

So I have used a different scheme here. Using two 74283 4-bit full adders to make an 8-but adder the upper part of the address bus is formed by adding a fixed base address (specified by writing the base to a latch) to the top three bits of the address bus. In this way the 64 address range of the Z80 can be used as a window into a larger address space. In this case I am going to make it 512K.

The top 8k page is forced to the top of physical memory to provide a common page - this is exactly how CP/M 3 wants to set up banked memory.

Using a 512K RAM gives 504K or 9 banks of 56K exactly which is a nice fit.

32K of ROM space is provided - this is mapped into the low 32k of memory when the ROMEN signal is active.

On reset the ROM is enabled and the bank base address set to 0, the boot code can then copy code up to the top of RAM and then jump there which can disable the ROM.

Memory timing is still dodgy. If I use 74F283 adders the propagation delay for each is about 5ns, plus 6ns for a 74F32 OR gate making 16ns in total for the address manipulation. If the address really is not stable by the time MREQ goes active an extra 16ns delay with a 55ns RAM is too tight (58-16 = 42ns, oops). Ideally one would design to worst case not typical (or even best case) timings but I think I should be OK. In fact I will probably be OK with 74ACT parts which are only very slightly slower than 74F so I'm going to go for those first as 74F is a bit power hungry (up to 55mA per chip for the adder).

I still have to do the serial and CF card interface. The "easy" cop out of using the Z80 peripheral chips is actually not available as they do not (as far as I can see) exist in 20MHz speed. Also common UART chips like the 16550 are actually a bit slow on their data access times for a 20MHz Z80, even given that the IORQ cycle is slowed with a CPU generated WAIT state.

More when I have finished the I/O design.
« Last Edit: March 30, 2017, 10:24:30 am by grumpydoc »
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Z80 Single (Perf)Board Computer
« Reply #1 on: March 17, 2017, 12:04:34 am »
I think you can run fully static RAM using a few IS61C512 or maybe a single IS61C5128. Then if your Z80 is also implemented with static logic you can just simply cut the clock to put the computer in sleep, and bring it up later by restoring the clock.

I am planning a 80C88 IBM PC XT equivalent. The older DRAM is very hard to find but 5V SRAM is still all over the place. You can use a single IS61C5128 for your project here. Or 8x IS61C512 and a 74HC138 to decode the additional address bits.
« Last Edit: March 17, 2017, 12:11:55 am by technix »
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #2 on: March 17, 2017, 08:28:40 am »
I think you can run fully static RAM using a few IS61C512 or maybe a single IS61C5128. Then if your Z80 is also implemented with static logic you can just simply cut the clock to put the computer in sleep, and bring it up later by restoring the clock.

Yes I already identified a suitable 10ns SRAM - the Alliance AS7C4096A which is available in 10, 12 and 15ns variants.

The design would also tolerate stopping the clock to leave the RAM powered and retaining data, but you still have to get some initial boot code in there for a cold start.

There has been discussion on the forum of using a modern microcontroller in Z80 systems to handle housekeeping for the Z80, including acting as the system ROM. Some of the systems one can find detailed on the 'net go for that approach but I don't want to go down that route - I want a decently retro feel to the project - something I could have built in 1985 if SRAMs had been just a little bigger and Z80s just a little faster  :)

For that reason I would prefer to avoid SMD parts. I'm kind of stuck with PLCC because the CPU I have is in that package but that's OK as it is pretty retro anyway.

But there is also the fact that the 20MHz part, if I am reading the the datasheet correctly, provides very little guaranteed time for RAM access - sufficiently short that almost any additional gate delays are going to potentially leave no time at all for the access or to implement mapping to extend the address bus.

I've not played wit the CMOS Z80's before. I am hoping that a "typical" part would manage to get the address lines stable before MREQ falls and do both before we have got very far into T2 but we'll see when I get the thing built.

Quote
I am planning a 80C88 IBM PC XT equivalent. The older DRAM is very hard to find but 5V SRAM is still all over the place. You can use a single IS61C5128 for your project here. Or 8x IS61C512 and a 74HC138 to decode the additional address bits.
Why would I use 8 SRAMS and a 138 (more delay) if I can use one? In any case that is going to push the capacitive loading up considerably.

Yes, the old 16/64/256K bit are now obsolete which does make life harder for retro projects. They can still be found on ebay.
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12806
Re: Z80 Single (Perf)Board Computer
« Reply #3 on: March 17, 2017, 09:43:01 am »
There was a long discussion on how to do paged memory on a Z80 back in 2015.
https://www.eevblog.com/forum/microcontrollers/retro-z80-project-memory-layout-and-software-management/msg821163/#msg821163
I contributed the suggestion of using a '486 era' fast cache SRAM for address translation.  Done right, you can map a 1 Meg address space in 4K blocks, with separate read and write mapping, and 256 instantly selectable (single OUT) page tables.   IIRC, we concluded that it would be *just* possible to run at 12MHz with zero wait states and interleaved access from a video controller, so without the video controller 20MHz is probably possible.

It would also vastly ease your ROM access time problems - boot from slow FLASH, EPROM or whatever with lots of wait states.  Set up the address translation tables, copy ROM into RAM and write  protect it by remapping write access to unimplemented memory, map out the original ROM and turn off the wait state generator.

That's quite a lot of benefit from compromising to accept one used or N.O.S. cache chip.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Z80 Single (Perf)Board Computer
« Reply #4 on: March 17, 2017, 12:23:59 pm »
I think you can run fully static RAM using a few IS61C512 or maybe a single IS61C5128. Then if your Z80 is also implemented with static logic you can just simply cut the clock to put the computer in sleep, and bring it up later by restoring the clock.

Yes I already identified a suitable 10ns SRAM - the Alliance AS7C4096A which is available in 10, 12 and 15ns variants.

The design would also tolerate stopping the clock to leave the RAM powered and retaining data, but you still have to get some initial boot code in there for a cold start.

There has been discussion on the forum of using a modern microcontroller in Z80 systems to handle housekeeping for the Z80, including acting as the system ROM. Some of the systems one can find detailed on the 'net go for that approach but I don't want to go down that route - I want a decently retro feel to the project - something I could have built in 1985 if SRAMs had been just a little bigger and Z80s just a little faster  :)

For that reason I would prefer to avoid SMD parts. I'm kind of stuck with PLCC because the CPU I have is in that package but that's OK as it is pretty retro anyway.

But there is also the fact that the 20MHz part, if I am reading the the datasheet correctly, provides very little guaranteed time for RAM access - sufficiently short that almost any additional gate delays are going to potentially leave no time at all for the access or to implement mapping to extend the address bus.

I've not played wit the CMOS Z80's before. I am hoping that a "typical" part would manage to get the address lines stable before MREQ falls and do both before we have got very far into T2 but we'll see when I get the thing built.

Quote
I am planning a 80C88 IBM PC XT equivalent. The older DRAM is very hard to find but 5V SRAM is still all over the place. You can use a single IS61C5128 for your project here. Or 8x IS61C512 and a 74HC138 to decode the additional address bits.
Why would I use 8 SRAMS and a 138 (more delay) if I can use one? In any case that is going to push the capacitive loading up considerably.

Yes, the old 16/64/256K bit are now obsolete which does make life harder for retro projects. They can still be found on ebay.
During my part hunt a seller dumped 40x IS61C256's in TSSOP-28 on me. I bought those and a few 74HC138 (in TSSOP-16) to create SIPP-style fully static RAM sticks for my (otherwise mostly through hole, except the Ethernet and USB chipsets) 80C88 machine. Could have added a few latches to make those compatible with actual 30-pin SIPP DRAM sticks but I can't be bothered with it.

My plan for that machine would look fairly modern, with a serial port bridged to USB, a USB OTG port, 10/100 Ethernet and maybe a monochromatic LCD. The USB serial provides the console to the system, the built-in USB Mass Storage Class driver in the USB OTG chip allowed me to use a USB Flash stick (or my usual USB SD card reader) as storage devices without too much driver in the BIOS, and Ethernet allows netbooting.
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #5 on: March 17, 2017, 02:25:19 pm »
There was a long discussion on how to do paged memory on a Z80 back in 2015.
https://www.eevblog.com/forum/microcontrollers/retro-z80-project-memory-layout-and-software-management/msg821163/#msg821163
I contributed the suggestion of using a '486 era' fast cache SRAM for address translation.  Done right, you can map a 1 Meg address space in 4K blocks, with separate read and write mapping, and 256 instantly selectable (single OUT) page tables.   IIRC, we concluded that it would be *just* possible to run at 12MHz with zero wait states and interleaved access from a video controller, so without the video controller 20MHz is probably possible.

It would also vastly ease your ROM access time problems - boot from slow FLASH, EPROM or whatever with lots of wait states.  Set up the address translation tables, copy ROM into RAM and write  protect it by remapping write access to unimplemented memory, map out the original ROM and turn off the wait state generator.

That's quite a lot of benefit from compromising to accept one used or N.O.S. cache chip.
Yes, I remember the thread, as well as the 2013 thread to which I submitted various suggestions and bits of schematic. 4 years to actually sit down and design my own board - knowing me it might be that long again before I get it built :-\

Yes, I think that using a Winbond W24257A or similar is an excellent idea but there are some caveats.

It is a bit more complex than just routing A12-15 to the W24257A and then routing the data lines to A12-19 on the way out because you need to be able to write to the mapping RAM which means adding extra logic, I think I did figure out how to do that and it wasn't too hard but it does add a bit of complexity.

That is why I still preferred using the 74F189 - it has separate Din and Dout pins which nicely separates things. Using an adder keeps the inputs & outputs separate as well. It's just a pity there isn't a 6 or 8 bit adder in the TTL series.

I'm not sure you can extrapolate from 12MHz with video interleave being possible to 20Mhz without being possible. In fact was a working system ever produced at 12Mhz? The problem is that Z80's do not give you 1/clock speed for access during the M1 cycle. The time between MREQ falling and the time that data must be stable in an M1 cycle is, indeed, 255ns for the 4Mhz part but it is 97.5ns at 8Mhz, 70ns for the 10Mhz part (45ns if clocking a 10MHz part at 12MHz) and just 23ns for the 20Mhz part (or 8ns if there really is -15ns of address set up time).

The calculation is (0.5 x clock period - clock edge to MREQ fall delay) + (clock period - data set up time).

I agree that these are "worst case" timings, typical parts might be better. EDIT In fact I'm starting to hope so quite badly.

The wait state is almost inevitable anyway as soon as you add ROM into the picture, even if you plan to add the wait only when ROM is active you will realise that the address bus is not guaranteed to be stable until 5ns after the rising clock edge at which the Z80 samples WAIT, so you can't make any "Do I add a WAIT state or not" based on address.

Ah, figured that one. :)

If you could make the RAM work but not the ROM you could do it based on "is the ROM enabled" (chances are with the ROM enabled all the M1 cycles will be out of the ROM anyway).
« Last Edit: March 17, 2017, 02:35:18 pm by grumpydoc »
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Z80 Single (Perf)Board Computer
« Reply #6 on: March 17, 2017, 04:08:46 pm »
The wait state is almost inevitable anyway as soon as you add ROM into the picture, even if you plan to add the wait only when ROM is active you will realise that the address bus is not guaranteed to be stable until 5ns after the rising clock edge at which the Z80 samples WAIT, so you can't make any "Do I add a WAIT state or not" based on address.

Ah, figured that one. :)

If you could make the RAM work but not the ROM you could do it based on "is the ROM enabled" (chances are with the ROM enabled all the M1 cycles will be out of the ROM anyway).

I thought the WAIT line was sampled by the Z80 at a falling edge of the third T-state (cycle)?
That would give you more than 20ns to make up your mind. Should be plenty.

I have used a bank-switched mechanism using a fast SRAM. The only thing I would change having worked with it a bit, is I would use a 16 (data) bit SRAM if they exist - that gives you loads of memory space without any extra (timing) cost.

I have not figured out how to work with bank-switched (4k pages) yet in software. All my endeavors still fit in the initial 64k  ;D
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #7 on: March 17, 2017, 04:17:13 pm »
I thought the WAIT line was sampled by the Z80 at a falling edge of the third T-state (cycle)?
That would give you more than 20ns to make up your mind. Should be plenty.
Only in an "ordinary" read or write cycle which takes 3 T-states.

In an M1 cycle the instruction read is done in T1 & T2, refresh occurs in T3 and T4. WAIT in M1 is sampled with the falling edge of the T2 clock.

The 3 T-state read/write is not the problem :)
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #8 on: March 28, 2017, 09:21:56 pm »
OK, continuing the design for my Z80 SBC I have found time to decide on and draw out the I/O schematic, plus a couple of tweaks to the port decoding (see diagrams in 1st post)



Why no Z80 peripheral chips? I hear you ask (OK, maybe I don't) - basically because there were never 20MHz parts, I suspect that the more highly integrated chips overtook the faster CMOS CPUs. Maybe the 10MHz ones would overclock but I'm trying to stick approximately to device specs.

I wasn't originally going to bother with a PIA but it quickly became obvious that a 44-pin PLCC package would cost less board area than the latches and buffers necessary to talk to the RTC chip so it went in - in which case I might as well bring the unused lines to a connector. Ditto the spare general purpose lines that the SIO provides.

At some point I might try to design a VDU board for it so I've brought enough lines for I/O port expansion onto a header.

Everything looks like it will fit:



"All" I need do now is order the parts I don't have - most of the TTL will need to be ACT (or maybe ABT) to keep propagation delays down and sit down and put it all together.
« Last Edit: March 28, 2017, 09:26:42 pm by grumpydoc »
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Z80 Single (Perf)Board Computer
« Reply #9 on: March 29, 2017, 02:33:46 am »
OK, continuing the design for my Z80 SBC I have found time to decide on and draw out the I/O schematic, plus a couple of tweaks to the port decoding (see diagrams in 1st post)



Why no Z80 peripheral chips? I hear you ask (OK, maybe I don't) - basically because there were never 20MHz parts, I suspect that the more highly integrated chips overtook the faster CMOS CPUs. Maybe the 10MHz ones would overclock but I'm trying to stick approximately to device specs.

I wasn't originally going to bother with a PIA but it quickly became obvious that a 44-pin PLCC package would cost less board area than the latches and buffers necessary to talk to the RTC chip so it went in - in which case I might as well bring the unused lines to a connector. Ditto the spare general purpose lines that the SIO provides.

At some point I might try to design a VDU board for it so I've brought enough lines for I/O port expansion onto a header.

Everything looks like it will fit:

[url=https://www.tindie.com/products/maxtch/sushibits-arm-development-kits/]https://www.tindie.com/products/maxtch/sushibits-arm-development-kits/][/url]

"All" I need do now is order the parts I don't have - most of the TTL will need to be ACT (or maybe ABT) to keep propagation delays down and sit down and put it all together.
I wonder if you can use some 5V CPLD in socketed PLCC package like EPM7128 or the like. That would replace the sea of standard logic and make your wiring easier.
« Last Edit: March 29, 2017, 02:35:43 am by technix »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Z80 Single (Perf)Board Computer
« Reply #10 on: March 29, 2017, 07:47:32 am »
Quote
I already identified a suitable 10ns SRAM - the Alliance AS7C4096A which is available in 10, 12 and 15ns variants.
Don't you have a supply/logic-level voltage problem?   Your memory chip is 3.3V, and the Z80 is 5V (and supposedly pretty picky about voltage levels?  Or was that the other way around?)

You could take the approach from https://hackaday.io/project/19000 - use RAM only (assuming it works), and use an arbitrarily slow process at startup to copy bootstrap code into the RAM (which is what x86 PCs have been doing for ages, of course.   Fast "rom" is hard to find.)
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #11 on: March 29, 2017, 08:34:23 am »
Why no Z80 peripheral chips? I hear you ask (OK, maybe I don't)

No, you did hear me ask. Thanks for answering. I would (will?) go old school and stick to 4Mhz even though I have a 10MHz CPU on hand. Might try to overclock but it is not a priority. If I was chasing speed I wouldn't be doing it with a Z80. That wasn't part of the experience and hence I'm not nostalgic for it.
I have a fair few 2Mhz and 4Mhz parts lying around - CPUs and peripheral chips. But, for some reason, I also found this 20MHz CPU so I wanted to use that, mainly because 20MHz seemed like a challenge.

I also have Flash and 512k SRAM chips lying around although sadly, not in fast enough parts.

I wonder if you can use some 5V CPLD in socketed PLCC package like EPM7128 or the like. That would replace the sea of standard logic and make your wiring easier.

I have nothing against using CPLD's or GALs. In fact one area which is clearly crying out for implementation as a GAL is the address mapping section. However I have no experience with or way of programming a CPLD or a GAL.

The "sea of logic" is not that bad anyway, it fits on the board I want to use and it's only 14 chips for glue logic, plus a latch and buffer.

But I agree if I could program one it would make life easier - especially as there are a couple of things I already don't like about this design. For one thing the reset is very simplistic and I haven't included the Z80 "short" reset logic which guarantees no RAM corruption on reset, nor was I able to include a hardware single step (which needs an extra couple of 7474's), another thing is that the memory mapping is very simplistic and its going to be an absolute pain to do inter-bank moves (which CP/M3 needs).

Of course instead of using a Z80 and a large CPLD I could just use a Z80180 to much the same effect as it integrates the CPU, banked memory SIO, CTC and DMA - or even better the Z80181 (although 100 pin QFP is not overly perfboard friendly).

I might do a Mk II to see if I can squeeze the extra functionality in (although I think that the current project might sate my appetite for building Z80 systems at present).

Quote
I once tried to suggest not quoting an enormous post to add one line that didn't relate to the quote directly. That didn't work. Just making an ironic comment.  ;)
+1

Quote
I already identified a suitable 10ns SRAM - the Alliance AS7C4096A which is available in 10, 12 and 15ns variants.
Don't you have a supply/logic-level voltage problem?   Your memory chip is 3.3V, and the Z80 is 5V (and supposedly pretty picky about voltage levels?  Or was that the other way around?)

The AS7C4096A is a 5v chip although I don't actually plan on using it, I'm going to use the AS6C4008 which is also 5V.

Quote
You could take the approach from https://hackaday.io/project/19000 - use RAM only (assuming it works), and use an arbitrarily slow process at startup to copy bootstrap code into the RAM (which is what x86 PCs have been doing for ages, of course.   Fast "rom" is hard to find.)

Yes, I had briefly considered that but it didn't feel "right". I haven't discounted it completely though - especially if trying to integrate more modern interfaces such as USB
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Z80 Single (Perf)Board Computer
« Reply #12 on: March 29, 2017, 08:47:58 am »
I wonder if you can use some 5V CPLD in socketed PLCC package like EPM7128 or the like. That would replace the sea of standard logic and make your wiring easier.

I have nothing against using CPLD's or GALs. In fact one area which is clearly crying out for implementation as a GAL is the address mapping section. However I have no experience with or way of programming a CPLD or a GAL.

This would be a good opportunity to learn. I have used a CPLD and GALs too for the first time in my design and it's quite doable. I used an Altera CPLD (Max II which is 3V3) so you program that in Quartus (check the device support to see what version you'll need) and I used the Atmel WinCUPL to program the GAL, which had a decent manual and examples and was easy enough to figure out. Do test first if WinCUPL runs (Compiles/Simulates) on your system, because on mine (Win8.1) it didn't - I had to go back to an old XP machine...

Another benefit of programmable logic is that you can change it pretty easily. I remember 2 cases in my design that it saved my behind. Simple mistakes can be fixed in the logic or by swapping some pins. Pretty terrific in my book.

Also there are cheap adapter boards available on ebay that go up to 100 pin QFP. Of course you need to be able to solder the 0.5mm pin pitch ICs (flux is your friend)....
« Last Edit: March 29, 2017, 08:54:07 am by obiwanjacobi »
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #13 on: March 29, 2017, 12:42:03 pm »
This would be a good opportunity to learn. I have used a CPLD and GALs too for the first time in my design and it's quite doable. I used an Altera CPLD (Max II which is 3V3) so you program that in Quartus (check the device support to see what version you'll need) and I used the Atmel WinCUPL to program the GAL, which had a decent manual and examples and was easy enough to figure out. Do test first if WinCUPL runs (Compiles/Simulates) on your system, because on mine (Win8.1) it didn't - I had to go back to an old XP machine...

Another benefit of programmable logic is that you can change it pretty easily. I remember 2 cases in my design that it saved my behind. Simple mistakes can be fixed in the logic or by swapping some pins. Pretty terrific in my book.

Also there are cheap adapter boards available on ebay that go up to 100 pin QFP. Of course you need to be able to solder the 0.5mm pin pitch ICs (flux is your friend)....
It would certainly be neat to do GALs at least for projects like this, CLPD might be overkill.

 

Offline magetoo

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: se
Re: Z80 Single (Perf)Board Computer
« Reply #14 on: March 29, 2017, 01:40:44 pm »
Why no Z80 peripheral chips? I hear you ask (OK, maybe I don't)

Why the 65C21 and not the 65C22 VIA which includes timer/counters and "SPI-like" serial?  It could help with I2C interfacing.


For one thing the reset is very simplistic and I haven't included the Z80 "short" reset logic which guarantees no RAM corruption on reset,

I don't know what the Z80 requires, but since you include an RTC I wanted to mention there are ones that include a reset function with a debounced pushbutton.  It might be cheating, but you can get DS3232 modules on Ebay that includes a battery holder and everything; I'm sure there are plain 8-pin DIP ones too, but I don't have any of those datasheets saved.

If you bring out the handshake lines on the parallel connector, I think you could hang an FT240 there for a USB serial console.  The SBC could just write data as fast as it wanted into the FIFO, not sure if that would work for reading though.  I want to do something like that for a 6502 system, when I get around to it.

« Last Edit: March 29, 2017, 01:45:15 pm by magetoo »
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Z80 Single (Perf)Board Computer
« Reply #15 on: March 29, 2017, 02:08:40 pm »
This would be a good opportunity to learn. I have used a CPLD and GALs too for the first time in my design and it's quite doable. I used an Altera CPLD (Max II which is 3V3) so you program that in Quartus (check the device support to see what version you'll need) and I used the Atmel WinCUPL to program the GAL, which had a decent manual and examples and was easy enough to figure out. Do test first if WinCUPL runs (Compiles/Simulates) on your system, because on mine (Win8.1) it didn't - I had to go back to an old XP machine...

Another benefit of programmable logic is that you can change it pretty easily. I remember 2 cases in my design that it saved my behind. Simple mistakes can be fixed in the logic or by swapping some pins. Pretty terrific in my book.

Also there are cheap adapter boards available on ebay that go up to 100 pin QFP. Of course you need to be able to solder the 0.5mm pin pitch ICs (flux is your friend)....
It would certainly be neat to do GALs at least for projects like this, CLPD might be overkill.
Well in my 80C88 project the entire bus matrix is implemented in one 100-pin EPM7128 CPLD. There is no sea of standard logic. The EPM7128 is my sea of logic. It takes the entire demultiplexed address/data bus from the processor, emits chip select signals to everything, and have its own internal configuration registers so all slave ports can be assigned dynamically.
 
The following users thanked this post: sarahMCML

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #16 on: March 29, 2017, 03:14:39 pm »
Well in my 80C88 project the entire bus matrix is implemented in one 100-pin EPM7128 CPLD. There is no sea of standard logic. The EPM7128 is my sea of logic. It takes the entire demultiplexed address/data bus from the processor, emits chip select signals to everything, and have its own internal configuration registers so all slave ports can be assigned dynamically.
At some point I want to do a 6809 and then a 68k based system. For the former I will probably try to stick with discreet logic, perhaps a GAL or two if I can. For the latter I think I might need something more up market :)

Why the 65C21 and not the 65C22 VIA which includes timer/counters and "SPI-like" serial?  It could help with I2C interfacing.
No more than the fact that I didn't get past the 65C21 as it seemed to do everything I needed.

The SIO has a CTC so that was covered.

I'll peruse the datasheet to see if would be easier to interface to the RTC.

Quote
For one thing the reset is very simplistic and I haven't included the Z80 "short" reset logic which guarantees no RAM corruption on reset,

I don't know what the Z80 requires, but since you include an RTC I wanted to mention there are ones that include a reset function with a debounced pushbutton.  It might be cheating, but you can get DS3232 modules on Ebay that includes a battery holder and everything; I'm sure there are plain 8-pin DIP ones too, but I don't have any of those datasheets saved.

If you bring out the handshake lines on the parallel connector, I think you could hang an FT240 there for a USB serial console.  The SBC could just write data as fast as it wanted into the FIFO, not sure if that would work for reading though.  I want to do something like that for a 6502 system, when I get around to it.
The Z80 just needs a low pulse at least 3 clocks but if you just do a 1 clock long pulse, low with the rising edge at the start of T2 in an M1 cycle it just clears the PC without doing anything else (so more of a warm start).
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Z80 Single (Perf)Board Computer
« Reply #17 on: March 29, 2017, 05:24:17 pm »
Well in my 80C88 project the entire bus matrix is implemented in one 100-pin EPM7128 CPLD. There is no sea of standard logic. The EPM7128 is my sea of logic. It takes the entire demultiplexed address/data bus from the processor, emits chip select signals to everything, and have its own internal configuration registers so all slave ports can be assigned dynamically.
At some point I want to do a 6809 and then a 68k based system. For the former I will probably try to stick with discreet logic, perhaps a GAL or two if I can. For the latter I think I might need something more up market :)
If you are doing a 68k system, just forgo the MC68HC000 and go straight to a MC68LC040/MC68882/FPGA combo. This combo runs at 3.3V so you can use newer FPGAs. MC68882 is a better FPU than the one came with the '040, and it is easier to find LQFP 'LC040 than '040 anyway.

Since the 'LC040/'882 combo is a full 32-bit system with MMU, you can build a DDR DRAM controller into the FPGA that accepts a single standard SODIMM memory stick. 2GB should be enough for most applications, and used 2GB DDR3-1600 SODIMMs should be fairly cheap to find.

If you want to reduce the amount of IP core types (aka licenses) you can use this three-IP solution: the aforementioned DDR DRAM controller, a quad-SPI XIP Flash controller, and a PCI Express root complex with 24 lanes configured in x16/x4/x1/x1/x1/x1. The quad-SPI core supplies the CPU with a firmware. The PCIe controller allows you to use COTS graphics (a GPU occupying the x16 lane,) storage (an NVMe SSD occupying the x4 lane,) audio (sound card occupying a x1 lane, also the HDMI/DP audio output on the GPU,) USB (a USB 3.1 chipset occupying a x1 lane,) wired (Gigabit Ethernet occupying a x1 lane) and wireless networking (Wi-Fi occupying a x1 lane, Bluetooth over the USB chipset)

As of software, the '040 definitely warrants a full Linux distribution. The firmware can be built from U-Boot chainloading UEFI. U-Boot for better low level initialization capability and UEFI for better expansion bus support (especially when PCIe is involved.) The kernel and initrd can be loaded from the SSD, with an OpenFirmware device tree embedded in the firmware. Thanks to the GPU you can have 3D accelerated graphics from the get-go. Video playback can also be delegated to the GPU so the '040 is not choking.
« Last Edit: March 29, 2017, 05:29:47 pm by technix »
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #18 on: March 29, 2017, 05:49:41 pm »
If you are doing a 68k system, just forgo the MC68HC000 and go straight to a MC68LC040/MC68882/FPGA combo. This combo runs at 3.3V so you can use newer FPGAs. MC68882 is a better FPU than the one came with the '040, and it is easier to find LQFP 'LC040 than '040 anyway.
I can aim that high but I think you overestimate my abilities, not to mention time available :).

There would be a definite walk before run element to any ambition for a system that powerful - perhaps when I retire so I have unlimited time to play.
 

Offline daybyter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: de
Re: Z80 Single (Perf)Board Computer
« Reply #19 on: March 29, 2017, 06:58:24 pm »
It would certainly be neat to do GALs at least for projects like this, CLPD might be overkill.

For GALs, you need a programmer like the tl866cs? And most GALs are EOL long ago? For Xilinx CPLDs, there are cheap parallel port cables to program and there are 5V versions available (also EOL, though).

Another option are those cheap FPGA boards:

http://www.ebay.com/itm/ALTERA-FPGA-Cyslonell-EP2C5T144-Minimum-System-Learning-Development-Board-/401255830236?var=&hash=item5d6cb612dc:m:m-tMy5MOZfxAvfiGVkWVMGg

I'm playing with such a board (for a c64 z80 module) and it's a great way to learn about the fpga technology, methinks.
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #20 on: March 30, 2017, 09:40:11 am »
It would certainly be neat to do GALs at least for projects like this, CLPD might be overkill.
I'm interested in the use of GALs if you decide to consider it. Although any design you make available will be more generally useful without them just because they are obsolete. I think you'd have to one with TTL chips and then show how it could be done with a GAL.
Well, Mk I will be using discreet TTL as I'm not going to revisit the design much now, Mk II could wind up using programmable logic but would probably be based on a Z80182 which will remove the need for a lot of the glue logic anyway.
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #21 on: March 30, 2017, 09:02:33 pm »
Why the 65C21 and not the 65C22 VIA which includes timer/counters and "SPI-like" serial?  It could help with I2C interfacing.
No more than the fact that I didn't get past the 65C21 as it seemed to do everything I needed.

The SIO has a CTC so that was covered.

I'll peruse the datasheet to see if would be easier to interface to the RTC.

Having read the 65C22 datasheet I am not sure that the serial interface capability will be that useful. The problem is that the 6522 was designed to be a 6502 peripheral and the PHI2 input is expected to be the CPU phase 2 clock - i.e a fixed period square wave.

In a Z80 design we are making use of the fact that the really important thing about PHI2 is the rising edge so if we apply an active high pulse when we want to read or write the chip registers it will still work - but it makes PHI2 completely useless as a timing source - which is pretty much what the timers and shift register want to do with it.

Having said that I was hopeful initially that I could implement a hardware single step function if I used a 65C22 - basically the way this works is that you set up the registers either with an initial state or with the state saved at the last breakpoint or single step, toggle a bit on an output latch which enables a hardware counter triggered on M1 and then execute a return.

After a set number of opcode fetch cycles (however many it takes to complete restoring the registers, plus the return, plus the first M1 of the following instruction which is the one you actually want to execute) you pull \$ \small \overline{INT} \$ or \$ \small \overline{NMI} \$ low**. the Z80 finishes executing the current instruction and takes the interrupt - whereupon you give control back to the console, print the registers or whatever.

As I can't squeeze in the extra flip-flops to make the counter I got quite interested in the fact that timer 2 can be set to count input pulses on PB6 until I noticed this comment "The decrement pulse on line PB6 must be Logic 0 during the leading edge of the PHI2 clock" - so it is still using PHI2 to drive the counting, not just the falling edge of the pulse on PB6, so I can't just route \$ \small \overline{M1} \$ to PB6 and use the counter to count instructions.

I briefly thought that I could drive PHI2 from \$ \small \overline{\overline{M1} \land \overline{IORQ}} \$ and drive CS2B from \$ \small \overline{IOB_2} \$ thinking that I could count M1 pulses by applying them continuously to PIH2 - plus applying a pulse when \$ \small \overline{IORQ} \$ is active for when we want to talk to the chip.

However I don't think that will work out - doing so will mean that the rising edge of PHI2 will almost certainly arrive before the chip is enabled by a high on  CS2B and I won't be able to access it correctly/at all.

So, at present, I can't see an advantage in using the 65C22 over the 65C21.

** - well, \$ \small \overline{NMI} \$ really as it is better suited to this task being edge triggered and not (potentially) having a complex acknowledge cycle. You could use \$ \small \overline{INT} \$ but it would be painful to do so, I think.
« Last Edit: March 30, 2017, 09:38:12 pm by grumpydoc »
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #22 on: March 31, 2017, 10:01:24 pm »
So, quick update.

I know building Z80 systems is a minority sport but I'm enjoying designing this so I hope that you don't mind indulging me.

I thought I'd finished the layout etc. but when ordering parts realised that I had made a small mistake - I had used a 3-input OR gate to generate chip select for the ROM but placed a 74xx27 which is a 3-input NOR gate. Turns out that there isn't a TTL triple 3-input OR gate, there's one in the original CMOS CD40xx set but the fastest available is HC(T) which is probably a bit slow for this build. So I'm going to have to cascade 2 x 2-input OR gates to do that.

That meant I could take a package off the board and looking at the layout again I realised I could squeeze a couple more in if I was a bit less conservative about leaving space for power rails.

Consequently I have room for a hardware single step and thought it was worth showing how this works - I can't claim any credit for this as it is totally ripped off from the Nascom 2.

This is the circuit



It works as follows - following reset FF1 is clear so the default state is with the STEP input low and the Q output of FF1 also low - in this condition M1 pulses are applied to the clear input of FF4 hence \$ \small \overline{NMI} \$ is held high. The set inputs of FF2 and FF3 are held low hence their outputs are high and input clock pulses to these two flip-flops are ignored.

To step a single instruction the code sets up all the registers with the stored contents from the last breakpoint then executes the following

   push    af
   ld      a,8      ; Toggle the "STEP" line high
   out     (0),a
   pop     af
   retn


The timing is then:



NMI is pulled low with the rising edge of the first M1 cycle of the target instruction, the falling edge of NMI resets FF1 and allows M1 to reset FF4 with the next low pulse. The processor takes the interrupt at the end of the target instruction.

It's quite neat.
« Last Edit: April 08, 2017, 10:05:23 pm by grumpydoc »
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #23 on: April 01, 2017, 07:20:41 am »
Your high speed ideas are little outside my approach of choice but ideas like this are welcome.
I wouldn't see any problem with the slower parts and the same schematic.

Quote
Is there a link to the location of the Nascom 2 info?
http://www.nascomhomepage.com/

Lots of useful info and programs there

Also http://80bus.co.uk.mirror.jloh.de/pages/magazines.htm for the newsletters and club magazines - in fact the home directory of that site also has some useful stuff.

http://www.cpm.z80.de/ is  worth a browse as well.
 

Offline grumpydocTopic starter

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Z80 Single (Perf)Board Computer
« Reply #24 on: April 01, 2017, 02:39:06 pm »
Final (I hope) layout



This would be so much better on a PCB although I want to make sure that it works first, I need to have another go at learning some EDA tool, not sure which though. Free Diptrace is probably too restricted (this design is well over 500 pins, for instance), I tried KiCad and could not manage the odd UI and I wasn't that impressed with gEDA though did stick with it for longest as I managed to hack some of the PCB layout tools a bit.

Does anyone have any suggestions?

All the bits now ordered. That was rather...................... expensive, much more than I'd anticipated.

Partly because I always order at least twice as many items as I need on the basis that "they will be useful in the parts box". I'm slowly realising this is mostly a fallacy but the odd thing does prove useful once in a while so it's hard not to do it. The problem is figuring out which 5% of what I bought but did not immediately need will turn out to be useful.

Partly, some items just were quite steep, especially the PIA and SIO.

I also keep forgetting just how much saying "I'll use some nice turned-pin sockets for this projects" adds to the cost, not to mention headers, batteries, etc which are really not that cheap in small quantities.

With luck I should find time to put it together after Easter.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf