Z80 memory banking for 128K - MMU design

[nockieboy]

Thanks Ken - but the reason I haven't gone for a more modern processor / microcontroller is because it defeats the purpose of doing all this in the first place - to build something similar in capability to my first ever computer, and maybe learn something about electronics at the same time.

Then why all this talking about flash memory and extreme amounts of memory? Imagine that the memory cost is about 5 UKP per kilobyte static RAM and build with what you "can afford".

Similar in capability. If I was going for that level of fidelity, I'd be trying to duplicate my old computer chip-for-chip.  Using something like a Z180 (or whatever) with a built-in MMU, timer and I/O would mean I would be just plugging a couple of chips together to get a working system.  This way I'm learning all kinds of stuff while I'm going and learning how to exceed the spec of my original Amstrad CPC464 in places (like memory size and clock speed currently.) I'm doing the things I wanted to but could never afford to do as a kid (and with information resources like the internet with easy datasheet access, tutorials and forums like this one, that never existed back then.)

[nockieboy]

Your last will work!

It certainly does, C!    I can now program the ROM without having to remove it from the breadboard - I've impressed myself with how smoothly it went!    I thought I had the ROM iteration down to a quick turnaround before, but now I can just type a command, paste the new ROM Intel Hex into the terminal window and watch as it buffers the data, erases the appropriate sector on the ROM and then writes the new data!  It even does it more quickly that my EEPROM programmer does!

I'm using an SST39SF010A, which has software protection against accidental writes, so there's a sequence of up to three address/value writes I have to do which, considering I'm writing to a RAM Area mapped to an arbitrary ROM Bank, involves some card-shuffling with the MMU to get the write sequence to the correct addresses on the ROM - but it works! 

[nockieboy]

Your flash rom has a software protect feature to prevent accidental writes.

You should be able to just connect your existing /WR that goes to RAM to your Rom chip with no problems.

Yes, that's exactly what I've done.  Couldn't be fussed messing around with switches and LEDs in the end when the ROM has software protection against accidental writes and (for the most part) is hidden behind the MMU and not always mapped into view for the Z80 anyway.

With some good code even CP/M2 can use a RAM or ROM drive.

With CP/M3 capability to run a program on CP/M2 and change to CP/M3 you have a great test environment.

Build a NON-Banked version of CP/M3
Use this to build two more CP/M3 versions
CP/M3 with ROM and/or RAM disk drives.
Banked CP/M3
Banked CP/M3 with ROM and/or RAM disk drives.

For future keep in mind that a CP/M disk drive could be a file or array of blocks on PC or something.

Yes, I'm now quite intrigued about the idea of a ROM drive seeing as how quickly writing to (and obviously reading from) the ROM is done.  This little sub-project has been a pleasant diversion from my CP/M 3 BIOS-writing woes, though - I need to get back to that and, in the process, no doubt I'll learn a bit about how drives work in CP/M and be better armed to deal with creating a FLASH ROM-drive later... 

[C]

With you being able to write to rom you have a good foundation you can build on.

If you have a good copy of Flash Rom, you could
Program the ROM using any programmer and if hardware was working, off you go with a working Z80

Now if a part of that Flash Rom looks like a CP.M disk then
You could boot to CP/M2 or CP/M3

If that CP/M disk has
CF Tools you could create a new CFCard disk drive
  Format new card & put on CP/M boot

If that CP/M disk has
  some comm programs, you could just run a program to send/receive via one of the many file transfer protocols.
  A BBS program would let you really go to town making it easy to move files from Z80 <-> PC

CP/M

You should have a copy of all Digital Research CP/M3 files on your Z80.
By using the relocatable macro assembler that comes with CP/M3 you can have files that work with rest of CP/M3

Run your current assembly files through the rmasm to see what you need to change if you are going to use PC to edit the files.
For small edit changes it could be faster to just startup WordStar3.3 on Z80.

Make Grant's code your own.
Grant has many different source files that only have a small change. This is hard to maintain. That rmasm assembler program for CP/M3 will let you remove this problem. Some will still work with PC assembler.

Think of this
  My Z80 could have many types of disk drives attached, many formats for floppies. Seldom did I need to change CP/M to work with these.
For my system's standard format floppies it would look at what was in the drive and make the needed changes in bios & CP/M.
You can make this easer by having a data table on each drive at a fixed spot.
If is not hard to have first Z80 instructions on a boot track to jump over a data table that has information of disk format.
For PC's this is the Master boot record at the start of drive.


So do not make getting CP/M3 hard.

what CP/M3 wants is a table that has entry points for each character I/O device.  It really wants a driver for a SIO and wants the driver to work with many SIO's.

The same is true of storage. You just need a few chunks of code that will use CP/M3's data tables to find out what to read or write.

One chunk of code to work with RAM/ROM disks.
One chunk of code to work with CFcard drives.

Where CP/M2 left a lot of work on BIOS programmer, CP/M3 does a lot more.
CP/M3 can do the blocking of 128 byte sectors into what the storage needs.
You driver gets simple,
  move this data <-> storage sector.
The What is in the tables but to make it easer to change from CP/M2 will still call set DMA, set drive, set track, ....

So just make a quick hack to Grant's to get it working. Then start making changes that will let you tap into CP/M3's full capabilities.

With CP/M'3 program that can build the CP/M3 drive tables, it could be easer to just skip the CP/M2 interface to bios and just jump to CP/M3's bios interface.
CP/M lets you have 16 drives. You could keep 8 working with Grant's drivers and 8 working with your drivers so that you can test your driver's functions.

A Drive is just chunks of storage that you have to work at a chunk of bytes level. Called a sector of which you put a bunch of sectors on a track and a bunch of tracks makes a drive.

 
 



 

[alank2]

Let me ask a question - maybe I am missing something.

With the 74LS670 being talked about on page 1.  Is there any reason you can't parallel two of them and have an 8 bit register?  The first one would get D0-D3 and then second one would get D4-D7.  They would share A0/A1/BANK/A14/A15

.

I ask so one could have A14/A15/A16/A17 on one of them and A18/A19/A20/A21 on the other.  Then you could access up to 4M for each of the 4 16K banks at 0x0000, 0x4000, 0x8000, and 0xC000, is that right?

[Ian.M]

Yes you can do that. See reply #29 onwards in this thread.

However it is sub-optimal for a fast Z80 system due to the high propagation delay of a '670 compared to '486 era cache RAM which can be found in speed grades from 15ns cycle time down to as little as 10ns, so has considerable advantages for a MMU address translator.

N.B. In a twin '670 MMU, to keep the software reasonably simple, you need to be able to write the mapping for a block to both simultaneously.  i.e. to map a block to any page set it up so you just write the block number to the mapping port.   The easy way to do that is to decode a block of four I/O addresses, + Z80 /WR to drive /WE, connect the WA and WB pins to A0 and A1, and connect the Dn inputs of each to one nibble of the databus.      Don't forget the pullups and logic to enforce a default mapping for the boot ROM until the MMU has been set up by your code, then enabled by taking /RE low.

[alank2]

Ian.M given speed concerns - what speed of SRAM would you need for 16 or 20 MHz Z80?  Digikey has sram in 10ns, 12ns, and 25ns.

I am thinking of just doing a very simple bank where the lower 48K is bank 0 or bank 1 and the upper 16K is common.  Selected with 1 signal and using 3 nand gates (2 in series).  The NAND used to decode a14/a15 to decide to keep the top 16K common.  With HC or AHC logic, would that limit the Z80 max speed to below 16 or 20 MHz?

[C]

Give your self a cookie.
 

At power-up contents of 74LS670 is unknown.
Disabling output and using pull up resistors puts top 16k of 4m space repeating 4 times.
A 74ls273 can be reset at power-up and one output can control output of 74LS670 leaving 7 for other uses.

This uses 5 output ports total for control ( 1 74Ls273,4 74ls670)

Power-up
4 writes to set 74LS670 and enable. now have full control.

Big problem with 74LS670 is address input to output delay.

Other option is cache ram chip that is faster then 74LS670.
Down side is A14 & A15 of Z80 must be directly connected to cache ram. This makes Z80 output more complicated but due able. You still need an additional chip to connect Z80 data bus to cache to write new map & proper logic to control.
Note a cache ram is just a very fast static ram that gives an output after ram delay.

One 138 decodes 4m into 8 512k spaces.

Reading other posts sense started this.
Memory timing becomes very tight and tighter getting up to 20M.

Think you are starting to see that fancy/powerful can be simple.

Note that one or more of the 512k spaces if not used gives future expansion.
One could be dual port.

[alank2]

Is the CD74HC670 faster in terms of speed?

http://www.ti.com/lit/ds/symlink/cd74hc670.pdf

[C]

74LS670
[url][http://www.ti.com/lit/ds/sdls193/sdls193.pdf/url]
there is a drawing

Read Select that applies
Address changes and output is delayed with two values  tphl tplh

From what I see if labels match between datasheets then LS is faster.

[Ian.M]

For the full discussion of a possible 486 cache ram based MMU see https://www.eevblog.com/forum/microcontrollers/retro-z80-project-memory-layout-and-software-management/msg832195/#msg832195 (reply#112 onwards, + some stuff back at reply #34)

[alank2]

I've got another idea for a very simple MMU.

Something provides signals for bank0, bank1, bank2, bank3 such as a shift register.  Then you use OR gates to switch the lower 32K and keep the top 32K as a common area:

a15 from z80 OR bank0 --> a15
a15 from z80 OR bank1 --> a16
a15 from z80 OR bank2 --> a17
a15 from z80 OR bank3 --> a18

When a15 is low, then the a18/a17/a16/a15 come from bankX.  When a15 is high, a18/a17/a16/a15 are all high.

[C]

The problem with logic is time delays. This can lead to glitches down stream.
Simple question, do all your mmu outputs change at the same time?

Look at the logic inside a 74xx138 at the amount of effort to remove glitches. Still you get best results with care using the inputs and what is connected.

Your or is a version of a switch
 

[alank2]

I plan to drive bank0/1/2/3 from AVR I/O pins and they will only change when changing the bank, else they will be unchanging.

It will need to be able to respond to A15 changing very quickly, but it is a single OR gate to go through before the memory pins.

[alank2]

How fast does it have to be?  Enough that the memory can stabilize before its outputs are sampled, right?

Last night I was thinking about the typical four 16K banks where each bank can be selected from any of 32 pages in a 512 K SRAM.

For each bit (A18/A17/A16/A15/A14) you need a multiplexer to selection between 4 possible inputs.  A fast multiplexer like 74AC153 it has a prop delay if <7ns.  You feed it A14 and A15 and it will select the proper bit out of four for that signal.  Instead of supplying the (5x4) 20 bits you can use 3 shift registers to supply them.  The page setting bits don't change often.  It just needs to be able to respond to A14/A15 quickly, correct?  This would need 3 dual multiplexer IC's and 3 shift registers and could b changed with SPI.

[C]

First some things to keep in mind.
For I/O, some CPU's like 68k  have memory mapped IO.
Z80 has option of memory or i/o space for i/o.

Some day you might want to expand the Z80. If you do not have space it gets very hard to expand. For memory you have un-used memory space or memory you can disable.

There is a difference in microcontroller attached hardware and microprocessor.

Think of big picture
1. Z80 needs to update memory map.
2. Z80 uses mapped memory.

#2 memory access
If the Z80 was working with 100ns memory and you add a MMU that takes 15ns you will probably need 80ns or faster memory.
You want some ns between them to get stability.

That Z80 timing spreedsheet I suggested will let you get the numbers.

Many different ways to do MMU, it's the result that counts.
The 74xx670 combines three major parts.
A selector to write data.
The data
A selector to read data.

Your 153 is selector to read data in separate chips. You could think of two being in one 74xx670

#1 Write Data.
With Z80 using out instructions to change map, the map is active at end of out instruction.

Look at AVR
The Z80 requests map change and has to wait for AVR to make the change.
To be fair with 16k blocks being mapped into 48k banks this could take 6+ instructions,. one to read mad data from memory and one out repeated three times.
This is 8 bits per block, at 4 bits per block you have 4 instructions.

You are talking of using SPI which I think can be clocked at 16m.
This sets the max for data move at 500ns a byte.
AVR still needs to get request to change memory and start pumping it out SPI.

Best for AVR is if Z80 caused and interrupt to AVR.
AVR reading a byte from Z80 and here I think two bytes more likely.
Computing what request and then outputting map.

The big move to and from CPM's TPA will be blocks of 128 bytes.
A fancy bios might use the 16k map capability to put source in one bank with dest in second bank while making the move.
This fancy method would probably use three map changes.

The simple is move from TPA to common and then to bank, a possible larger bios common. This is still two map changes.

Worse case would be something like character I/O where bytes are moved


So yes mux or switches like 153 have been used for map.
Some systems had a chain of these but most were not trying to get max speed.

You talked about high speed
Look at spec for /mreq and note it changes with the CPU you have. A 20m z80 running at same speed of a slower spec Z80  will be faster.
/Mreq    8m = 100ns, 10m=75ns, 20m=25ns
These are pre-computed values that are not complete.
The actual address can be before with some time or after mreq goes low.
Data has to be valid at proper time.
You do not know if it's a read or write until the signals go low.

The numbers have to work properly with a little extra time or you get a CPU that works randomly.

 


 

[alank2]

C - Thanks for the detailed reply!

[alank2]

How are these control signals driven?  (WAIT, INT, NMI, BUSRQ, RESET)

I've looked at the Z80 Big Board schematics and they show a 10K pullup on WAIT/NMI/INT/BUSRQ.

Since multiple devices might pull down BUSRQ, do they use an open collector type of output?  On my AVR that might be HiZ or Output LOW.  I'm wanting to drive BUSRQ with the output of a 74AHC74 flip flop which doesn't have an open collector output.  I'm assuming it will drive high or low.  How should I make that work with BUSRQ?

[C]

By driving these pins with open collector gates you have a wired OR. With out this capability you have a hard time expanding.
With a wired OR you can add more outputs to drive these pins.

If you connect normal logic to Z80 input, have some place that has a pull-up and will create the signal.
Some use a Schmitt-Trigger Input gate to drive the Z80. Advantage is faster change on Z80 pin, bad is the added delay.

[alank2]

What is the best/easiest way to have the 74AHC74's output seem like an open collector to the Z80?  Use a schottky diode?

[David Hess]

What is the best/easiest way to have the 74AHC74's output seem like an open collector to the Z80?  Use a schottky diode?

A schottky diode or even a small signal switching diode usually works fine.  An NPN transistor driven at its emitter with a base resistor to the positive supply can be used to make a millivolt drop diode.  A low threshold n-channel MOSFET can do the same thing.