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 ...
A Z-80 program will be 15% smaller than an 8080 program.
To come up with this guess I took a reasonably tight Z-80 program, the TRS-80 4K Level 1 BASIC ROM and estimated the cost of replacing the Z-80 specific instructions with 8080 code. I'll get back to the limits of this methodology later but for now let me plow on with this example.
Of the 4096 ...
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).
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:
0 - 16383 16kB ROM (BASIC)
16384 - 32767 16kB RAM (starting with video memory)
32768 - 65535 two ...
Hard to do a lot better while keeping full generality but the code can be considerably smaller and faster by avoiding IX. Code hasn't been tested.
; call using:
; RST $08
; DB controlport
; DB controlbyte
; DW calladdress
RST08: ; $0008 contains a JP RST08
POP HL ; return point
LD C,(HL) ; control port
The normal way to handle cross-bank calls is to use a springboard which is either in an unbanked area of memory or appears identically in both old and new areas. If one doesn't mind using a different entry point for each origin bank, things can be pretty simple, especially if bank switching I/O addresses use the bottom bits of the address, rather than the ...
Considering what I learned in the comments under the question, I'd suggest a combined hard/software solution to this design issue. It's based around a single port, or a consecutive group of ports that are handled as one, by all 'cards'. Decoding is done as sum of address and data.
Assumptions for all following:
Bit-numbering in Address/Data is LSB ...
My opinion is that I wouldn't rely too much on Z80 daisy-chained interrupts. It was actually invented to "dissolve" the need for the dedicated interrupt controller IC among the ordinary peripheral chips. Besides that only useful feature, everything else is disadvantage:
The need for extra logic inside chips, i.e. decoding RETI instruction and ...
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 ...
Worth checking out this PS2 Controller built from TTL chips:
as part of this 8-bit computer: