Z8410 DMA chip as GPU?

Question

There are basically two ways to design a 2D graphics system:

1. Provide lots of hardware support in the form of tiles, hardware scrolling and sprites, to put together each frame on the fly from a small quantity of data, so you can have lots happening on the screen in every frame even if the CPU is slow. The Commodore 64 and NES are well-known examples of this strategy.

2. Provide a simple frame buffer that can store a relatively large quantity of data, and rely on the CPU (plus any support chips) to be able to move that data around fast enough. The Apple II and Amstrad 464 are well-known examples of this strategy.

The second strategy produces an elegant and flexible design, but has the disadvantage that if you want lots happening on the screen in every frame, you can get severe slowdown. For example, a 4 MHz Z80 can blit about 200K/second, which sounds like a lot but at 60 fps, it would be only about 3K per frame, and you really want something like 20K of frame buffer for good graphics without tiles or sprites.

It is said that the Z8410 DMA chip can blit much faster, up to 2 megabytes/second. Would it be feasible to use it as a sort of GPU, put it in a home computer and let it handle scrolling and suchlike for an order of magnitude speedup? If so, why was it never done?

It seems the answer is yes, doable! But a couple of people have pointed out it's not a full match for the Amiga's blitter, because it doesn't do bit shifting and masking, only byte transfers. This is true, but will be considerably ameliorated by using chunky pixels (as opposed to bit planes on the Amiga). Suppose we had one pixel per byte. The problem would disappear. Unfortunately that's not feasible on an 8-bit home computer, but suppose we have something like the low resolution mode on the Amstrad 464, two pixels per byte. Now we can move two pixels without bit shifting. Better yet, if we double buffer, each buffer can move two pixels without bit shifting, for a net effect of one pixel movement per frame.

Addendum: if the blit is for the purpose of horizontal scrolling, hardware scrolling - which I think is cheap to provide? - would also help.

Answer 1

I've been thinking about something like this myself, recently. I wasn't planning on using a Z8410, though, but an Intel 8257-5. This has a number of advantages:

• It has 4 controller channels rather than 2
• It was actually a cheaper chip than the Zilog chips

The interfacing to the Z80 wouldn't be quite as easy, but fundamentally the Z80 and the Intel 8085 that the 8257 was designed to integrate with were very similar chips, so shouldn't be too hard.

Why do I need 4 controller channels though? The answer to that is that the DMA chip can perform multiple functions: it can produce the address generation logic for reading lines from a framebuffer, for reading sprites to overlay on the framebuffer, and for doing memory bulk transfers (the latter operation requires two channels, one to read and one to write) or operations for drawing into the framebuffer. It handles taking control of the bus from the CPU and generating the signals that cause the CPU to wait if it needs to access memory (the scheme used by the 8085 and the Z80 for this look at first glance as though they are compatible, but more research will be necessary to be sure of this). Basically, a single DMA chip can perform the same operations that are more commonly associated with a CRT controller chip, and provide useful additional functions in the same package, for a similar price.

This also lends itself to a more advanced kind of video controller: one that uses a display list. In such a system, the processor writes a description of each scan line saying where in memory to assemble the various parts of the line from, and what formats they're in. One DMA channel reads this description, and the second acts on it. Display lists weren't exactly new (they were used in various Atari systems from the late 70s onwards, for example), but AFAIK there were no publicly available chips that could be used to easily implement them. A DMA controller would probably be the easiest and cheapest option for a custom system that worked like this.

Answer 2

It has been already done for ZX spectrum.

see Velesoft: DATA-GEAR

It has DIL40 socket compatible pins at the bottom and it replaces Z80 (so the bus is as short as possible). According to that site The bandwidth is around:

ZX128+ is 17.3 kB(17727 bytes) / frame = 865.6 kB(886350 bytes) / second

The higher bandwidth allows:

• fast scrolls
• MultiTech techniques to boost color resolution (8 pixel/attribute instead of 64 pixel/attribute)
• much easier doubling of screen resolution (256x384 instead of 256x192)
• easier and more precise border effects

Here MultiTech example (from my Emulator I got some timing issue with the DMA chip somewhere so there are few artifacts that are not present on real machine)

And the same image without MultiTech:

Here grayscale MultiTech output:

And here preview of DMA demo level2 (the choppy-ness is due to my RT GIF encoder, the emulation itself is smooth)

It goes smoothly even above 1000 sprites (If the magenta counter really is count of used sprites) ... without any over-clocking of standard 48K ZXS

Answer 3

Pushing large chunks of bytes around is actually a task a DMA chip is very good at.

The point is:

1. Pushing partial bytes around is a task a DMA chip doesn't help sooo much, there is a lot of the job still left to the CPU. A DMA chip is not capable of shifting the bits in a byte, which was one of the main operations when handling retro computers sprite drawing and scrolling.
2. A DMA chip cannot mask out bits on the "sprite margin". It always works on byte boundaries.
3. Pushing lots of small chunks around somewhat slows down a DMA chip (you need to constantly re-load DMA registers)
4. A DMA chip is not built to handle overlapping source and destination memory ranges, something that is pretty common in screen handling.

What follows is:

1. A DMA chip is really good at moving large chunks of around that have no holes in them and do not need to be shifted - In a typical home computer, however, to scroll by one pixel horizontally, you need to shift the bits in the byte - the DMA chip doesn't help at all here. It would be very good at scrolling and sprite-blitting vertically and in 8-pixel-increments horizontally on a Spectrum, for example, but that would look pretty jerky.
2. If you move rectangular (partial) areas of screen memory around, you typically have small chunks of contiguous memory to move, then a gap of a line length, then another chunk and so on - Moving sprites would require you to constantly re-load the DMA addresses once per each line of your sprite being transferred, each re-load a number of I/O transfers. Maybe a bit faster than moving with the CPU (depending on sprite size), but all in all not so much of an improvement.

Where a DMA chip would be really helpful would be in

• Saving whole screens to memory and back (no gaps, no shifts)
• Scrolling whole screen lines (or whole screen) up or down (no gaps, no shifts)
• Scrolling whole screen lines horizontally in increments of 1 bytes (on a Spectrum, that would be a jerky movement by 8 pixels only)
• Scrolling vertically (that always moves on byte boundaries). For vertical scrolling, you're running into the additional problem that a DMA chip cannot handle overlapping source and destination regions very well: It will always copy towards increasing addresses, so downward scrolling wouldn't work well without an additional buffer.

This is a little bit limited for a blitter chip.

With a different screen memory layout (8 bits/pixel) as in later computers, you would get rid of the shifting requirements and could really speed up graphics. But most retro home computers simply don't have that much screen memory.

You could also store your sprites bit-shifted (that means, shifted by one pixel into every possible horizontal position in memory), which would relieve you of the need to shift when moving sprites horizontally) but that would need 8 times the memory for sprites, not a very good idea for a home computer with limited memory.

A chip that would probably do exactly what you want/need the Z80DMA for was the Blitter chip that came in the Atari STs: It had exactly the functions you'd miss in a Z80DMA chip like shifting, masking and gap-jumps plus fast memory-to-memory copying.

As a conclusion, I think history has proven that if you built a mass-market computer with relativly high-end graphics, custom logic turned out to be much cheaper than off-the-shelf DMA chips with their limited capabilities extended by (again) custom logic. The Commodore C64, the Amiga, Atari ST and similar computers all went that way.

Answer 4

Is it possible that you're using the here the term 'blit' as in Bit-Blit? If yes, than it's inaproptiate, as your examples are only about moving (byte) data. Moving is just one function of a bit blit engine. Beside logical operations, it also includes the handling od rectangular areas in a display wich are not (always) a consecutive series of memory cells (read, an icon or sprite is spread out over several screen lines which are wider than the image).

A (Z80) DMA can only move consecutive chunks of memory. To move something like an icon to a screen image, you would need to configure and start the DMA for each line. Unless we talk about icons half the size of a screen, the CPU will be faster in just doing the work by itself - especially when additional logic operations (like masking) are needed. There's a reason specific blitters have been designed. Standalone or as part of graphic chipsets.

A DMA as part of the graphics system only makes sense to handle the memory access and stream the video data toward the encoder. Like in two counter generating the pixel clock which is feed to the DMA-Request to fetch the according byte.

The only DMA alike chip I know that could be used as a blitter would be the 8089 IOP which in fact was already available in 1980. But maybe a bit more expensive than a 8410. Here some screen programm could run and do many operations quite fast, and at the same time generate all data for a video stream on the fly.

The 8089 can easy be interfaced with a Z80.