Could a Z80 address a total of 128 KB of ROM and RAM?

Question

In a nutshell, could the Z80 address 64 KB of ROM and 64 KB of RAM, or just 64 KB for both RAM and ROM?

Unfortunately, I couldn't find an exact and a direct answer to my question while searching. Excuse me if my question has a very very direct answer, that I don't understand

Now whenever I see how memory a Z80 could address on many sites, Wikipedia and so it states 64 KB, but the type of memory isn't specified ROM or RAM. At the same time on other sites, it is specified that RAM and ROM share the 64 KB address space, so 32 KB for RAM and 32 KB for ROM. At other places I saw that the maximum RAM space is 64 KB, hence there should be extra space for ROM.

I became very confused, and tried to open the Z80 datasheet directly, but due to my simple understanding, I couldn't get a rigid answer, but I found what's called a stack pointer which is holding a 16-bit address for external RAM plus there is a pin called MREQ which supposedly becomes active when the Z80 is using RAM. Now some evidence suggest that the Z80 could address a total 64 KB total ROM and RAM, and some suggest that is could address 64 KB ROM and 64 KB RAM, so 128 KB total for both of the memory types.

Answer 1

The Z80 has an address space of 64KB. That means it can perform 8 bit reads or writes to 65,536 distinct locations as specified by the 16 address pins on the CPU. As far as the Z80 is concerned that's all it knows about.

Now it's up to the system designer to decide which of those locations lead to RAM, which lead to ROM, which might lead to memory mapped peripherals and which lead nowhere. The CPU doesn't know the difference between them and it will happily try to write to ROM even though that has no effect. On a system like the original 48KB ZX Spectrum the first 16KB of the address space led to 16KB of ROM while the rest led to 48KB of RAM.

Of course this kind of arrangement doesn't need to be set in stone. Bank Switching is a design where you can change what is connected to different address ranges dynamically in response to a command (such as writing a bank number to a specially chosen address or port). The CPU still only has 64KB of address space but you swap what portions of that address space actually connect to.

The ZX Spectrum 128 had more than 64KB of RAM and used bank switching to let programs access all of it. So the first 16KB of the address space still led to ROM, the next 32KB still led to the same fixed RAM but that last 16KB could be switched in between operations to connect to any one of eight 16KB banks of RAM in the system (the 16KB ROM could also be switched between accessing the original BASIC and a new 16KB editor).

Answer 2

TL;DR:

It's 64 KiB total in any combination imaginable.

---

Or more general:

The Z80 features

• 16 address lines (A15..A0),
• sufficient to address 64 KiB (via D7..D0),

which can be used to access one of two address spaces

• default memory (with next to all instructions, indicated by /MREQ) or
• I/O locations (with IN and OUT instructions, indicated by /IORQ).

Either address space can be filled at will with

• RAM,
• ROM,
• I/O or
• not at all.

Pick your choice.

(Not to mention swapping RAM/ROM/IO in and out by reconfiguration of address decoding - but that'll be design/machine specific and not due to CPU design)

---

In Detail:

Whenever I see how Memory a Z80 could address in many sites, Wikipedia and so it states 64KB, but type type of memory isn't specified ROM or RAM,

Because it's an address space of 64 Ki, independent of what is placed there.

I could understand that your confusion comes from modern SoC with separate channels for each use case. The Z80, like basically all classic CPUs offer only a single, generic bus for all types connected. All devices use the same interface. Selection is done by address decoding outside the CPU.

it is specified that RAM and ROM share the 64KB address so 32KB for RAM and 32KB for ROM,

Why does it have to be 32+32 KiB? Any split is possible. Some systems will have only a small 2-4 KiB Boot ROM, able to load some OS from an external media.

in other places I saw that maximum RAM space is 64KB, hence there should be extra space for ROM.

No, not necessary, as ROM may only be needed during boot and will be disabled after some OS is booted - the usual way for CP/M machines.

tried to open the Z80 datasheet directly [...] I found what's called a stack pointer which is holding 16bit address for external RAM

That's the software side. If you want to see how hardware is interfaced, you ned to look at the pins and their function. Like A15..A0 holding an address.

plus there is a pin called MREQ which supposedly becomes active when the Z80 is using RAM.

No, it's active when it accesses memory - independent of being RAM or ROM (or whatever). It distinguishes access to memory address space to I/O address space (marked by /IORQ).

Now some evidence suggest that the Z80 could address a total 64KB total ROM and RAM, and some suggest that is could address 64KB ROM and 64KB RAM so 128KB total for both of the memory types.

Now that would be nice to see that evidence. Because all I ever found is reference to a 16-bit address space that can be populated with anything.

Answer 3

We had a clone of ZX Spectrum called Didaktik Gama (with single m indeed). It had 16kB ROM and 80kB RAM total. As all Z80 based computers, it had 16bit address space - addresses 0 - 65535, with memory mapping like this:

Address          Contents
0 - 16383        16kB ROM (BASIC)
16384 - 32767    16kB RAM (starting with video memory)
32768 - 65535    two switcheable 32kB RAM banks (0 and 1)

Upon boot there was a default bank 0 mapped, and it was up to user to "manually" switch to the second bank. The data in the bank 1 survived reboot! That was a luxury back then, when normally you'd have to spend like 3-5 minutes after each reboot to load your programme from tape cassette. So many times, I just loaded my assembler development environment (I chose address above 32768 to load it) into bank 1 and it just stayed there (until a physical power off :)). If my assembler program screwed up, I just rebooted the computer, switched to bank 1 and everything was already there! Didn't have to wait 5 minutes again till my assembler environment loads from tape cassette :-)) Big luxury back then.

I didn't work with ZX Spectrum 128, but according to the description here it had 128kB RAM (not including ROM) and it used similar bank switching principle, just using the top 16kB address space (instead of 32kB) to switch between extra 16kB banks (scheme from the above link):

I personally preferred the 32kB banks because I had 32kB of continuous RAM safe from any reboot :-)

Answer 4

Yes, it could, with some help :)

I had an oddball CP/M (Z80) machine that had additional logic that let you switch at runtime between a Harvard and Von Neumann memory addressing. It had 128kB of RAM (and a little bit of EPROM overlapping some of it), and both 64kB address spaces could be used simultaneously when in the Harvard mode: you had independent 64kB of code space, and 64kB of data space.

On Z80, opcode fetches are signaled by asserting the M1 output signal. There was some discrete logic state machine that used M1 along with the contents of the data bus (i.e. the opcode(s)) to determine which operands came from the machine instructions (immediate operands and displacements), and which were actual data loads/stores. The output of that state machine classified each memory access as either code fetch (immediate operands/displacements) or data load/store.

There were a couple bits in configuration registers that let you customize this - it was quite flexible, in spite of how little logic was used to implement it. There were three kinds of accesses on CPU side: code, data, and I/O, and each could be mapped to any of the address spaces: code space, data space, or I/O space. The I/O accesses couldn't be mapped to the data space IIRC, since that'd be useless.

One of the configuration registers was used when within an interrupt handler, the other at all other times - the state machine used the /INT pin and opcode monitoring to determine when an ISR was entered and exited, to select the proper config register.

The default configuration provided 192kB of non-banked address space, split between three address classes: 64kB of code space, 64kB of data space, and 64kB of I/O space. The code and data spaces each had 64kB of dedicated RAM mapped to them, with some of both spaces also overlapped by EPROM, so that you could store both data and code in the EPROM.

There was no other memory banking, i.e. the RAM was always evenly split between the code and data address spaces. Two of the unused/invalid opcodes had special treatment by the state machine: a NOP would be placed on the data lines, and a "code space override" or "data space override" was latched, so that the subsequent instruction would do all accesses from that space no matter what was configured. This effectively added two prefixes not unlike segment override opcodes on 8086 - likely that was where the inspiration came from, I guess.

Answer 5

Practically, you could map 64k of memory into the I/O space but you couldn’t execute code from it since it requires special op codes to read/write. A typical application might be to store an audio recording and then read it out one sample at a time. Even with 1980s 8-bit sampling and 8ksps playback you’d have room for only 8 seconds of audio, but might be enough for some dings and beeps for a video game.

Answer 6

I owned a 128kb TRS-80 Mod IV.

64kb was available at any one time. There was a port you could write to that would swap in either of the extra 32kb banks in place of the normal ones--I forget all the details by now.

In practice the only safe way to handle it was to disable interrupts (which means you couldn't do it for too long), swap it in, do whatever you needed to with the data there and swap it back out. You had to ensure you code wasn't in the swap region and that your stack wasn't in the swap region. Thus it was realistically only useful as data space, you couldn't run code from it.

You could, however, store code there. One of the most useful things I did with it was write a program that would on boot load all the swappable OS pieces into the upper bank, then intercept the call to load them and bring them in from memory instead. (Some rather tricky coding as resident programs normally lived at the top of memory, but the OS swaps were fairly low in memory--there was no place to swap the bank to. I ended up writing the loader as a normal program and the part it left behind was partially written in a small hole in OS memory and partially overwriting part of the OS swapper that was no longer needed.)

Answer 7

The Z80 had a total address space of 128K, but one had to be very careful with ones coding. There was an early "multimedia" computer from- I think- Sony, which had a Z80, 128K of memory, and an optical disc.

This is from memory, but I was given chapter and verse on this a number of years ago by somebody who'd (professionally) written games for Z80-based systems.

The majority of opcodes assumed direct access to 64K of memory space (RAM+ROM with some arbitrary split, or with ROM only visible at boot, or with some form of bank switching).

In addition, the I/O opcodes were documented as handling 256 (2^8) port addresses, but in actual fact there was an indirect mode which handled 64K (2^16) port addresses... I think there was something odd in there like the indirection being nibble-swapped.

The Sony system (and perhaps some others) used this to support 128K of memory. I don't know what the performance was like, and I don't know how it handled I/O ports.

I note the older discussion at Z80 16-bit I/O port addresses which deals fairly concisely with 16-bit port address issue. Google etc. has a lot of noise relating to the the Spectrum 128K, I don't know how the extra memory on that was addressed but generally speaking it looks as though the port address bits were used for the keyboard etc.

Answer 8

The Z80 itself has 65,536 bytes of memory that are directly accessible, and the trick Zilog used to use in their old computers was to use 32K bytes of each and select between the two with the A15 pin. However, they created a new, better system and integrated it into their more recent chips where a set of registers select the address boundaries of the RAM and ROM, so an address between the boundaries of either memory type will select that type of memory, and the boundaries can be modified at any time for up to 64K of each. This trick is used in the Z182 and Z382 CPU. Also, paging the memory (used in the Z280) and adding an MMU (used in the Z180) will expand the memory as well.