Z80 CPU module with MMU3

[Tadeusz Pycio]

The Z80 processor module with a simple MMU that allows addressing 1MB with 32/32kB banks for RomWBW or 48/16kB for MP/M. This solution is not as versatile as the MMU used in Zeta2 (74x670) or the one presented here on 74HCT612, but it is inexpensive and built from readily available parts. Despite its simplicity, the MMU concept is significantly faster at switching banks under MP/M than solutions based on lookup tables.

[Mark T]

Looks good, a nice simple MMU, similar to one Alan Cox made some time ago, though I think that might have been on an 8085.

Are you planning on a DMA module with its own MMU? That seems to be the reason why BUSAK would disable A16.to A19.

I can see how it would work for MPM but not so sure about ROMWBW. It splits the memory into 64K banks where the high 16K/32K of each bank can only be mapped to the high 16K/32K of the z80 and similar for the low 48K/32K. I’m not sure how that will work with ROM and RAM disks, unless you can work around that in software.

[Alan Cox]

On Thu, 22 Jan 2026 at 21:10, Mark T <mark...@gmail.com> wrote:

Looks good, a nice simple MMU, similar to one Alan Cox made some time ago, though I think that might have been on an 8085.

Sort of. It's on the 8085 board but independent so you can build the board with an 8085, with an MMU or with both.

 

Are you planning on a DMA module with its own MMU? That seems to be the reason why BUSAK would disable A16.to A19.

I can see how it would work for MPM but not so sure about ROMWBW. It splits the memory into 64K banks where the high 16K/32K of each bank can only be mapped to the high 16K/32K of the z80 and similar for the low 48K/32K. I’m not sure how that will work with ROM and RAM disks, unless you can work around that in software.

MP/M is a weird one. It supports a separate DMA bank setting in the memory management and this was actually used by some machines from folks like Altos. On a modern system however it's basically useless because your disk is so fast you might as well use PIO, or the DMA if used has to stall the CPU to be fast enough to be worth it anyway.

The high/low handling for a ramdisc is actually really quite easy. You need to find somewhere in the reserved space bytes of your CP/M low page to hide an LDIR, out (port),a, ret and the rest is trivial for the upper banks.

The advantage (beside simplicity) of this scheme is you can actually make the MMU a separate card that supplies A16-Awhatever on the RCbus and use it with any 16bit CPU card.

Alan

[Tadeusz Pycio]

The DMA issue is a bit funny, because the available 8-bit chips operate within a 64 kB range, so by default the BUSAK signal will not be used (JP2 jumper shorted to ground). Its use is more forward-looking, as it would require the development of a solution that would work within a 1 MB range.

Yes, originally the concept was even simpler, but Alan convinced me not to limit the supported RAM to 400 kB out of 512 kB, so I changed the design as he did in his 8085+MMU module.  Changing the size of banks also changes the meaning of the latch halves, so that a different way of dividing the address space does not cause an error (software expecting a switched memory bank from address 8000h will not work with the jumper set to 48/16, and vice versa). There is also a ready-made version that does not work this way; halves 74273 define the same memory area.

When talking about RomWBW, I was thinking more about the available half of the RAM, so without ROM/RAM Disk. I haven't yet considered whether there is a solution that could use all the available memory without modifying the design (e.g. as was done in SC730).

[Alan Cox]

The Altos just has a latch that provides the upper address bits when the Z80 DMA owns the bus. MP/M never tries to DMA across banks. Indeed it has no internal model of a linear address space so the concept of "across banks" simply does not exist.

Alan

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/31c48824-202e-4995-9923-196ea0daff1fn%40googlegroups.com.

[Tadeusz Pycio]

The Altos just has a latch that provides the upper address bits when the Z80 DMA owns the bus. MP/M never tries to DMA across banks. Indeed it has no internal model of a linear address space so the concept of "across banks" simply does not exist.

That's right, so leaving the A16-19 addresses active by shorting the jumper to ground will allow the DMA to take over the A0-A15 bus. Admittedly, I was unable to use DMA to transfer data from the disk read buffer to the user buffer because MP/M switches banks, but I will return to this topic because I have not resolved it. These are memory-to-memory transfers.

When using DMA in an MP/M system, its only reasonable application is for console support. Context switching makes XModem transfer practically impossible, even when using interrupts and queues (unless we use an absurd queue buffer). Of course, you can create and add a module to the kernel that would support ‘fast’ and packet transmission types, but it will not resemble what CP/M has accustomed us to with XModem support programmes. You can also use DMA for mass storage transmission, which will be noticeable in MP/M.  

[Tadeusz Pycio]

I have observed strange behaviour of this MMU. In 48/16 mode, where a NAND gate is used to switch banks, the device refuses to operate at a system clock speed of 7.38 MHz, but works at 6 MHz. The delays introduced by the NAND gate and the 74HCT257 multiplexer should not be that significant. I conduct tests using a ROM emulator, but it should not have such long delays that the appearance of the address a little later would affect such behaviour. Interesting, another mystery to solve.