| Electronics > Projects, Designs, and Technical Stuff |
| Z80 Single (Perf)Board Computer |
| (1/10) > >> |
| grumpydoc:
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. |
| technix:
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. |
| grumpydoc:
--- Quote from: technix 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. --- End quote --- 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. --- End quote --- 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. |
| Ian.M:
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. |
| technix:
--- Quote from: grumpydoc on March 17, 2017, 08:28:40 am --- --- Quote from: technix 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. --- End quote --- 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. --- End quote --- 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. --- End quote --- 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. |
| Navigation |
| Message Index |
| Next page |