Re: Z-80 coprocessor cards

Microcomputers work most efficient if intelligent
peripheral chips are used, and networking makes no exception here.
A Z80 running CP/M would profit a lot from
offloading the network stack to a network controller
and such things exist already.

Computer architecture always fascinated me, particularly I/O systems.
My joke (mostly to myself)
is how the mainframe folks will "have their day".
Mainframes never had the fastest CPUs but achieved high thruput
with a heirarchy of parallel I/O processors and specialized controllers.

Minicomputers kinda approximated that with smart I/O controllers
(when available; most were not-so-smart).

On a micro level, the Z80 CPU offloaded some tasks
to its peripherals, such as CTC auto-reloading,
parallel I/O chips being programmed
to interrupt on only certain conditions.
The strength of the "classic" Z80 CPU
was the variety of peripherals
- quad CTC: Counter Timer
- dual PIO: parallel I/O
- dual SIO: sync serial I/O ports
- dual UART: async serial I/O ports
They all interfaced with just address decoding,
self-arbitrating interrupts using the vectored mode 3.

The SIO chip was kinda an early NIC when used in SDLC mode:
up to 1 MegaBit speed, understoond the frame format
for responding to its own address,
automatic CRC generation and checking, etc.
I am led to believe that AppleTalk was based on the Z80 SIO/8530.
Many protocol converts were just a Z80 CPU
and a bank of SIO chips for the sync protocol.

At some point, the Z80 ceases to be your CPU and becomes instead
merely a PPU - peripheral processing unit.

In systems of the 80s, there tended to be Z80s in all roles.
Zilog's own MCZ2/50 used a Z80 for the main CPU
and another in the floppy controller to offload command processing.
The Zilog System 8000 used the Z8000 CPU
but several Z80s as firmware-programmed dedicated controllers,
or just the Z80 chips kinda shoe-horned to the Z8000
(I remember the device driver having to force
the Z80's "re" "ti" onto the peripheral bus
to reset the Z80 peripherals interrupt-pending).
Even the terminals and printers of the time
were microcontrollers such as the Z8.

Michael:
Well, it does what its best at. A Z80 can't interface a HD floppy
directly very well, so it uses a FDC and a DMA controller.

That's a nice distinction of microprocessors (Z80)
vs. microcontrollers (Z8, PIC, AVR, ...).
I really "missed the boat" with the Z8 and PIC
by looking at the spec *** and thinking
"that's really WEAK compared to the Z80"
without understanding its role in the entire system.

Microcontrollers are happiest running small programs
from their internal ROM (flash, EPROM, ROM)
with re-programming only for updates
whereas microprocessors are happiest with lotsa external RAM
and dynamically loading various tasks (from mass storage:
floppy, hard drive, flash drive, network ...).

Steal cycles from its RAM for video, and performance is bad,

I hope you mean "real cycle stealing" as in using
the refresh cycles for read/write of static RAM,
accessing data RAM during opcode fetch from a different RAM bank, etc.
All without impacting the CPU's cycles at all.

I ask because the IBM system 1130's manuals referred to
cycle stealing but it halted the CPU, so it was really DMA.

so you use a video controller with private RAM.

Or dual ported ram.

The SIO has a small FIFO buffer to reduce
latency requirements, and so on. In the eighties, all of that was already
common technology, and had people had ethernet back then, they had built
network controllers.

As I noted, the SIO was capable of NIC-style operation in sync mode
with filtering frames by address and only accepting those
with the station's address, or broadcasts.
If it got lost or confused, it could "hunt" for the next frame
without any CPU intervention.

The Z80 family includes many peripheral chips for a reason.
These days, PICs and the like allow to build you own
peripheral controllers at low cost and using low power.

Kinda, maybe, almost.
The PIC UARTS don't have the deep FIFO of the SIO or DART,
depending on interrupt servicing to make up for the lack of hardware.
The more I read about the PIC 18's peripherals such as USB,
the more I'm frustrated with the lack of silicon support.
Yes, they're cheap, single chip solutions
but it bothers me that we're using CPU cycles
for the lack of silicon for FIFOs, protocol state machines, etc.
But proponents would say
"why not, that makes them more versatile and CPU cycles are cheap".

I guess I can't totally ignore my "vintage" feelings:
(stolen from The Life Of Brian)
every byte is precious
every byte is great
when a byte is wasted
DEC gets quite irate

.