This feature has been used on many Z80 systems such as the Australian microbee & British Amstrad CPC. On the microbee the B register value output on the address pins A[15:8] is used as a data bus for IN A,(C) instructions. It done to provide two output ports from a single port address where one uses the standard OUT (port),A to write to the original port and LD BC,# (
Thanks for pointing these machines out. I knew some commercial designs used this but it is great to learn about others. This is useful not only for new retro designers but also in understanding old hardware designs. Without knowing the technique, some old schematics and designs would be impossible to understand so thanks for helping to convey and archive a bit of old school knowledge!
"Something [Intel] intended, but did not finish". Hmm, sounds a lot like the 8051 instruction set. The Z80 already was more time efficient than the 8080/8085, without this video's little gem. I haven't worked with the Z80 since ~1989, but used it almost exclusively for more than a decade up to that time. My work switched me over to microcontrollers. First the Motorola HC05, which was a joy to code, in assembly. Then the 8051, which had parts made by everybody, and their mom ! But the 8051 instruction set always puzzled me a bit. It looked like the Intel design team, for the original part, took a break in the middle of specifying the instructions, but never finished, before sending off the part for production.
pratically the out (C),r instruction should be written as out (BC),r but it is a little messy out (0x90), A place the A contents on the upper high address bits.
So this is how the Sinclair ZX machines did their screen generation. A keyboard array code would be best generated by autonomous clocking hardware, so a code and strobe generated externally to the CPU. All depending how cheap the hardware needs to be.
I have never used a Sinclair ZX. Could it’s performance have been improved by using dedicated hardware? Or were they able to do the keyboard and video essentially by utilizing mostly dead time?
@@HelloWorldETX The keyboard diagram is from the ZX Spectrum, though the design originates from the ZX80. The reason is to save the hardware cost. In the ZX80 and ZX81 generating the video is effectively the primary task of the CPU. Hence the ZX80 would blank the screen whenever it did any processing. The ZX81 had few additional logic gates to provide a SLOW mode where Non-Maskable Interrups were used to tell the CPU when to generate a video signal or a FAST mode which behaved like the ZX80. With the ZX Spectrum, the ULA contained a video generator. The Spectrum ULA had priority accessing the lower 16k RAM, where the video memory resised. Which it would do by controlling the clock signal to the CPU. Which is an undocumented DMA method,
@@markevans2294 This cheap method has the advantage of slowing down the processor the least possible (though Soviet clones used a different bus sharing method that didn't slow it down at all, but of course used much more additional components), compared for instance to shared access to the video RAM 1 cycle out of 2 in for instance Commodore machines, that effectively halved the resulting processor speed.
The block I/O instructions IND, INDR, INI, INIR, OUTD, OUTDR, OUTI & OUTIR also output the contents of the B register to A8-A15. Potentially a peripheral could use this to know how many bytes the CPU is expecting to read or write.
I had not noticed this. the z80 technical manual has a nice table on page 54 that lists in the comments everything that goes out onto the address bus during the I/O instruction group. www.bitsavers.org/components/zilog/z80/03-0029-01_Z80_CPU_Technical_Manual_1977.pdf So far, i have not found where zilog makes any mention of actually *using* this feature. it seems like something that others would have put out an application note or some other means of providing insight.
@@HelloWorldETX It doesn't help that the timing diagrams on page 15 of the same manual imply that only the lower eight bits of the address bus are active for I/O cycles.
@@markevans2294 indeed. It is these sorts of things in the data books that make me wonder if some things were intentional design features or just design accidents
yes, but you need to discriminate the others opcodes that also place the B or A content on high address bits. otherwise the external hw could be 'confused' by instructions like out (0x90),a or out (C),r
@@HelloWorldETX Not accidents but just undefined. In these first microprocessors, not everything is decoded/gated completely to save few transistors (remember these were designed by "hand" on big sheets 🥵) so as long as the main goal is achieved.
No, the Z80 has only an 8 bit IO address space according to its datasheet. That you can put an additional byte of data onto A8..15 does not make it a 16 bit address space, although you can (ab)use it this way. But whether it is specified as an immediate or indirect, the IO address is still only 8 bits. The datasheet is consistent in its explanation of this so I'd doubt that it is any kind of error or omission. The source of the value for A8..15 is also inconsistent depending on which instructions you use, which I think further cements the fact it is 8 bit only. If it were officially 16 bit then A8..15 would be sourced from a consistent register to ensure that no matter which instructions you used you could always address 16 bits worth of IO space in the same way.
@@TomStorey96 Nonsence. Since CPU does drive address bus w/ full 16 bit address from BC, executing register-indirect i/o instructions, it is full 16-bit address space (and 8+8 extended for immediate indtructions). It is not a kind of hack, it is designed and documented behaviour. Designers, probably had their reasons, why they omited that in specs page (and "BC" in instructions args), probably because of 8-bit address legacy and string instructions. But that fact should not be doubted.
@@semibiotic the datasheet states: "IORQ indicates that the lower half of the address bus holds a valid I/O address for an I/O read or write operation"
That sounds like and interesting project. Some of those OEM custom keyboard controllers (with their custom character mapping) are getting hard to find.
pencil drawing remembered placing 2732 EPROM over data and address pins and soldering directly some of the pins . The takeaway for the project was that an address or data line pin does not have to be used as comventionaly labled and high order address line could be used as keyboard row select . The code was echoed in the EPROM , translation table , brute force and easy . Most important was it fit and could be replaced with original device later .
Yea, nice things about EPROMS for look up tables is no matter what is controlling the inputs, each input configuration results in a known (stored) value on the data lines. Doesn’t matter if the inputs are an address, a position encoder, a coordinate, a temperature, a keyboard, or anything else.
This feature has been used on many Z80 systems such as the Australian microbee & British Amstrad CPC. On the microbee the B register value output on the address pins A[15:8] is used as a data bus for IN A,(C) instructions. It done to provide two output ports from a single port address where one uses the standard OUT (port),A to write to the original port and LD BC,# (
Thanks for pointing these machines out. I knew some commercial designs used this but it is great to learn about others. This is useful not only for new retro designers but also in understanding old hardware designs. Without knowing the technique, some old schematics and designs would be impossible to understand so thanks for helping to convey and archive a bit of old school knowledge!
"Something [Intel] intended, but did not finish". Hmm, sounds a lot like the 8051 instruction set. The Z80 already was more time efficient than the 8080/8085, without this video's little gem. I haven't worked with the Z80 since ~1989, but used it almost exclusively for more than a decade up to that time. My work switched me over to microcontrollers. First the Motorola HC05, which was a joy to code, in assembly. Then the 8051, which had parts made by everybody, and their mom ! But the 8051 instruction set always puzzled me a bit. It looked like the Intel design team, for the original part, took a break in the middle of specifying the instructions, but never finished, before sending off the part for production.
😂😂😂😂😂"It looked like the Intel design team ... took a break in the middle of specifying the instructions"🤣🤣🤣🤣🤣🤣
You explained this very clearly! Thank you.
Thanks. I hope your Z80 projects go well
Out (c), a etc are basically a 16 bit port address, they should be really called out (bc), a or in a, (bc) etc.
Effectively IN and OUT in a single operation? Add a couple shift registers and it would seem you have an SPI interface in the works.
It would be a fun exercise to use this to interface not only SPI but maybe some of the other “few wire” interfaces
pratically the out (C),r instruction should be written as out (BC),r
but it is a little messy
out (0x90), A place the A contents on the upper high address bits.
The V or Vector register is in the high byte of Address bus during Refresh cycle.
Generally called the “I” register
excelent
So this is how the Sinclair ZX machines did their screen generation.
A keyboard array code would be best generated by autonomous clocking hardware, so a code and strobe generated externally to the CPU.
All depending how cheap the hardware needs to be.
I have never used a Sinclair ZX. Could it’s performance have been improved by using dedicated hardware? Or were they able to do the keyboard and video essentially by utilizing mostly dead time?
@@HelloWorldETX The keyboard diagram is from the ZX Spectrum, though the design originates from the ZX80. The reason is to save the hardware cost.
In the ZX80 and ZX81 generating the video is effectively the primary task of the CPU. Hence the ZX80 would blank the screen whenever it did any processing. The ZX81 had few additional logic gates to provide a SLOW mode where Non-Maskable Interrups were used to tell the CPU when to generate a video signal or a FAST mode which behaved like the ZX80.
With the ZX Spectrum, the ULA contained a video generator. The Spectrum ULA had priority accessing the lower 16k RAM, where the video memory resised. Which it would do by controlling the clock signal to the CPU. Which is an undocumented DMA method,
@@markevans2294 This cheap method has the advantage of slowing down the processor the least possible (though Soviet clones used a different bus sharing method that didn't slow it down at all, but of course used much more additional components), compared for instance to shared access to the video RAM 1 cycle out of 2 in for instance Commodore machines, that effectively halved the resulting processor speed.
@@markevans2294 there is another thing related to video. they should had use the busrq signal instead they 'decoupled' the bus by using resistors
@@Z80Man How did the soviet clones completely avoid cpu pause during video fetches?
The block I/O instructions IND, INDR, INI, INIR, OUTD, OUTDR, OUTI & OUTIR also output the contents of the B register to A8-A15.
Potentially a peripheral could use this to know how many bytes the CPU is expecting to read or write.
I had not noticed this. the z80 technical manual has a nice table on page 54 that lists in the comments everything that goes out onto the address bus during the I/O instruction group.
www.bitsavers.org/components/zilog/z80/03-0029-01_Z80_CPU_Technical_Manual_1977.pdf
So far, i have not found where zilog makes any mention of actually *using* this feature. it seems like something that others would have put out an application note or some other means of providing insight.
@@HelloWorldETX It doesn't help that the timing diagrams on page 15 of the same manual imply that only the lower eight bits of the address bus are active for I/O cycles.
@@markevans2294 indeed. It is these sorts of things in the data books that make me wonder if some things were intentional design features or just design accidents
yes, but you need to discriminate the others opcodes that also place the B or A content on high address bits. otherwise the external hw could be 'confused' by instructions like out (0x90),a or out (C),r
@@HelloWorldETX Not accidents but just undefined. In these first microprocessors, not everything is decoded/gated completely to save few transistors (remember these were designed by "hand" on big sheets 🥵) so as long as the main goal is achieved.
Yeah, Z80 has 16-bit wide i/o space. I wonder, why datasheet crypting that fact, and does even worse - explicitly omiting A8-A15 from signal diagram.
Maybe it was an accidental feature so it wasn’t documented as an actual function.
No, the Z80 has only an 8 bit IO address space according to its datasheet.
That you can put an additional byte of data onto A8..15 does not make it a 16 bit address space, although you can (ab)use it this way.
But whether it is specified as an immediate or indirect, the IO address is still only 8 bits. The datasheet is consistent in its explanation of this so I'd doubt that it is any kind of error or omission.
The source of the value for A8..15 is also inconsistent depending on which instructions you use, which I think further cements the fact it is 8 bit only. If it were officially 16 bit then A8..15 would be sourced from a consistent register to ensure that no matter which instructions you used you could always address 16 bits worth of IO space in the same way.
@@TomStorey96 Nonsence.
Since CPU does drive address bus w/ full 16 bit address from BC, executing register-indirect i/o instructions, it is full 16-bit address space (and 8+8 extended for immediate indtructions).
It is not a kind of hack, it is designed and documented behaviour. Designers, probably had their reasons, why they omited that in specs page (and "BC" in instructions args), probably because of 8-bit address legacy and string instructions. But that fact should not be doubted.
@@semibiotic the datasheet states:
"IORQ indicates that the lower
half of the address bus holds a valid I/O address for an I/O read or write operation"
@@TomStorey96 Datasheet lies (more precisely it lacks that and other essential parts), as I stated in initial commentary, and I wonder why.
This awarness let me make a Z80+ROM only keyboard encoder design to replace a blown and overpriced keyboard chip .
That sounds like and interesting project. Some of those OEM custom keyboard controllers (with their custom character mapping) are getting hard to find.
That's awesome. Did you ever document the project?
pencil drawing remembered placing 2732 EPROM over data and address pins and soldering directly some of the pins . The takeaway for the project was that an address or data line pin does not have to be used as comventionaly labled and high order address line could be used as keyboard row select . The code was echoed in the EPROM , translation table , brute force and easy . Most important was it fit and could be replaced with original device later .
Yea, nice things about EPROMS for look up tables is no matter what is controlling the inputs, each input configuration results in a known (stored) value on the data lines. Doesn’t matter if the inputs are an address, a position encoder, a coordinate, a temperature, a keyboard, or anything else.