Most 8 bit computers didn't have much in the way of organisation of their IO systems.  They just stuck all of the IO devices on a shared bus, and maybe if you were very lucky provided a DMA controller (although that was rare).

The Apple II was somewhat of an exception - it was designed to make expansion easy by providing slots where addressing was already decoded, making add-in cards cheap and easy to design.

In order to make a superior system, I have to improve on this state of affairs.  And by improving the organisation of the IO system, I can hopefully make the design of the most complex IO device in the system, the display adapter, both simpler and better.

My first thought was simply to provide a DMA controller.  The display system could use a DMA channel to read a framebuffer.  Like the IBM PC I could use another DMA channel to make sure DRAM refresh happens correctly.  And having spare channels would be useful for other hardware, too.

Unfortunately, standard DMA controller chips that were available off-the-shelf in 1981/1982 weren't ideally suited to what I want to do.  The logical choice for a Z80 system was Zilog's own offering the, Z8410.  Unfortunately, the speed grade I'd need for this system, the Z84C1006, is difficult to find advertised at the correct time (I'm not even sure if it was available yet, to be honest) ... but the pricing for the 2.5MHz to 4MHz variants ($29 to $37) scares me.  And even then it would need overclocking for the 6.25MHz I'm currently planning.  The most popular alternative was the Intel 8237A, and it was substantially cheaper than Zilog's chips, but as of 1982 it appears that the fastest speed available for that was 5MHz (it would later be used in the 8MHz IBM PC AT, but not until 1984).  Intel were pushing the 8259, and the 8MHz variant of that was definitely available, but I haven't found a price for it.  But it's telling that IBM chose to use the 8237A for the PC -- I presume the 8259 was noticeably more expensive.

But at about this time, I realised that what I really want to do is actually quite a bit more complicated than a simple DMA controller will allow.  On most 8 bit systems from this time period, you had to compromise by choosing a screen mode.  You could get high resolution and full colour, but only if you could only display text with no graphics at all.  Or you could get high resolution with limited colour (either monochrome or, if you're lucky, a 4 colour palette), low resolution with full colour (but using up a lot of your precious RAM for the framebuffer), or low resolution with lower-still colour resolution (to save RAM for your actual program to run in).  These compromises were necessary due to the limited memory bandwidth of these systems, and due to the fact that memory was too expensive and limited just to throw it away on colour depth that might be nice but probably isn't necessary in many cases.

But choosing which of these modes to use for your application often meant compromising in ways you really didn't want to.  What I really wanted was a solution where you could partition your screen into sections and use different modes in different sections.  There were systems that allowed this - the later Atari 8-bit systems supported something like this through their "ANTIC" custom IC.  ANTIC was basically a very simple processor that read a program called the "display list", which consisted of delays, mode changes, and pointers to blocks of data to display on the screen, and it fetched them and pushed them out to the display, changing how it interpreted them as necessary.  This is, in many ways, a lot like a DMA controller.  Why not combine these two functions?

A somewhat more generic approach was taken by Intel in their 8089 IO Processor.  This combines a DMA controller with a coprocessor (connecting to an 8086 or 8088 via the same control mechanism that is more commonly used for an 8087 maths coprocessor) that can perform simple operations to manage IO devices, perform data conversions, and so on.  It organises devices as "channels" of data that are read to or from main memory, which is a useful abstraction.  A similar abstraction was used in mainframes, although the 8089 was a lot more limited, most notably due to only supporting two channels.

If I implemented something like this, it would make producing the best possible display hardware of the era much simpler.  It would also make IO expansion amazingly simple, providing even better facilities than the Apple II did.  I'd need a lot more than two channels, though.

I think I can get a working design together that comes in within a component budget not much higher than the cost of the Z8410 chips above ... excluding the static RAM buffer (which I would have needed for the display hardware anyway), I hope I can get it down to as low as $40, so not too dissimilar to the cost of the Z8410, and shouldn't cause too much trouble for the overall project budget.  The static RAM that it will need is a little more expensive -- for the kind of performance I'll need, 12.5MHz is probably the minimum processor speed I can accept, and for that I'll need 70ns RAM, which was expensive in 1981.  The best I can see advertised is $3.15 for a 2147 chip (which were available in multiple speeds but 70ns seems to be the slowest, according to the 1982 Intel data book) which are 4Kx1-bit, so I'd need a minimum of $26 for the processor ... but I'm not happy that 4K is enough for this job, so I'll allow $52.

I've forked a new project for development of this system.  Because I'll have to use substitutes for some of the components I would have used in 1981 which aren't readily available now (e.g. the 74AS870 register file, which makes the processor design I'm thinking of possible in a single board, rather than requiring a separate board just for registers...), or where it would be substantially cheaper to use more modern components (e.g. I'll be working with 32Kx8 RAM chips rather than 4Kx1), I'll need to make sure I can make the system do what I want without exceeding the capabilities of the components that I would have been using, but I think that should be simple enough.