20

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.

  • 3
    I can offer that the Atari Lynx, designed in '86 or '87 even though it didn't get to market until '89, is a rare example of an 8-bit frame buffer and [scaling] blitter, using an 8kb frame buffer for 160x102, 4bpp. If you trace by design team rather than company, it's between the Amiga and 3do in the procession that started with the 2600. I couldn't speak as to a proper history of blitters prior to the Amiga though, so I think am unhelpful re: earlier machines. I suspect the 7800 was one though, but would need to check. – Tommy Oct 9 '17 at 11:31
  • 2
    Having looked it up and found atarihq.com/danb/files/7800vid.txt it sounds like the 7800 is an interesting hybrid: there is a buffer and a blitter, but the buffer is one scan line long. Well, okay, there are two. One is being output while the next is being drawn to. So you're boxed in to having one line's time to draw one line, but there is a piece of hardware compositing bytes from a list of objects into a single buffer for later output. – Tommy Oct 9 '17 at 13:19
  • 1
    When you say GPU, do you mean the chip that moves memory around (blitting things like sprites and screen memory contents) or the beast that actually creates the video signal? – tofro Oct 9 '17 at 14:23
  • 1
    I'm tempted to challenge your "cheap to provide" statement in the last paragraph. That was what (years after the high time of Z80 HCs) delayed the Atari ST blitter chip so much it was introduced 12 months after the computer.... – tofro Oct 10 '17 at 7:03
  • 1
    You may need to look into using Z180, It it had the best of all the Z80 Peripherals all in one IC, DMA, MMU, CTC, Serial and Z80 Core plusd speed, I used one variation that was internally clock at 33Mhz. – forthnutter Oct 10 '17 at 23:44
13

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.

  • 1
    more channels are interesting one can be used for sound for example ... – Spektre Oct 9 '17 at 15:18
  • 2
    The Nintendo DS uses this approach for (3D) display lists - you set the DMA controller's target address to the 3D processor's command FIFO, and tell it not to increment the address after each write. – immibis Oct 9 '17 at 21:28
  • 1
    @tofro: On a system which uses discrete Nx1 DRAM chips, masking and partial bytes could be handled by selectively enabling/disabling chips. On Shifts could be handled with a barrel shifter and latch, wired so it would grab the bus contents on a single-address DMA read and output its contents on a single-address DMA write. A two-channel controller programmed to alternate reads and writes would thus perform the rotate while transferring data at normal speed, though a non-aligned transfer would require two passes--one for the left half of every byte and one for the right. – supercat Oct 10 '17 at 20:54
  • 1
    @tofro: Popular computers either didn't have any sort of graphical acceleration hardware, or were built in sufficient quantity to justify custom silicon for the purpose. If one needed to build a workstation with a blitter and didn't have enough projected sales volume to justify custom silicon, using a DMA controller for the address-generation portion of the job would reduce the number of chips required. I haven't studied enough low-volume-production designs to know to whether such chips were used (many designs that use a lot of discrete logic do everything with discrete logic)... – supercat Oct 11 '17 at 15:11
  • 1
    ...but if I were designing a Z80-based graphic system using period-correct parts and needed to support fast bitblt operations I can't think of a better way to do it./ – supercat Oct 11 '17 at 15:13
14

It has been already done for ZX spectrum.

see Velesoft: DATA-GEAR

DataGear

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 265x192)
  • 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)

multitech

And the same image without MultiTech:

normal

Here grayscale MultiTech output:

grayscale multitech

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

DMA demo

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

  • 2
    I sometimes wonder what my SAM Coupé could have been, had one of these been installed at launch. Something other than a machine that needs four or five frames to touch every pixel in its framebuffer, at least. I feel like at the time people were saying it would have added only £15 or so to the price — does that sound accurate? – Tommy Oct 9 '17 at 14:50
  • 1
    @Tommy - Z80 DMA chips were sold at retail throughout the early 80s for about £10. But IIRC the SAM Coupe was a Z80B machine running at 6MHz? If so, the common Z80 DMA chips weren't compatible as they only went up to 4MHz. – Jules Oct 9 '17 at 14:57
  • 1
    @Jules there are also 6-8MHz versions of DMA chip out there – Spektre Oct 9 '17 at 15:03
  • 3
    Also, are you sure that multiple balls demo isn't just proving that you can copy an entire screen buffer and draw a single ball in less than a frame? That was a common demo technique for that: eight back buffers, replayed in sequence, during each loop moving a single ball onward and an endless stream therefore seeming to appear because of the ball you drew last time plus the one from time before plus the one from the time before that plus ... . Still impressive regardless, as obviously having bandwidth to move an entire frame buffer-sized block opens up thousands of options. – Tommy Oct 9 '17 at 15:07
  • 2
    @Tommy hard to say we would need to disassemble and analyze the code to see if they are adding/not_clearing frames or really using many sprites. I was very curious about the MultiTech at that time so I incorporated the DMA chip and Data-Gear into my emulator. But sadly have some contention or timing problem somewhere (only with MultiTech as any other DMA stuff works without noticeable glitches) ... Btw If my memory serves well Data-Gear was not developed as graphic support but as a part of IDE/FDD/SDcard interface they where called MB01,MB02 or something like that. – Spektre Oct 9 '17 at 15:13
9

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.

  • 1
    If a computer used Nx1 DRAM chips it would probably not be particularly difficult to add gating logic to allow partial-byte writes. Probably two chips and an inverter (use an 8-bit latch or flop with 3-state output to select which chips should be active when writing, and an 8-bit 3-state driver to drive all 8 chip-selects with the same pattern when not writing). Shifting might be a little harder, but could still be practical in discrete logic. – supercat Oct 10 '17 at 6:10
  • 2
    @supercat Possibly, yes. But adding lots of external logic probably defeats the whole purpose of a standard chip - You'd be better off putting the whole shifting, masking, and DMA logic into a FPGA/CPLD today. – tofro Oct 10 '17 at 6:17
  • 1
    @tofro: Nowadays one would use an FPGA or possibly CPLD, but this is a retrocomputing q/a site which would typically favor "period-correct" solutions. Bit rotation is probably more expensive than would be worthwhile, but if memory serves EGA provided it; I'm not sure how it was physically implemented, but it was there. – supercat Oct 10 '17 at 14:44
  • 1
    @supercat EGA didn't use a DMA chip, to my knowledge and also didn't provide any blitting functions - It relied completely on the CPU for shoving bits around. If you're looking for a (somewhat) contemporary chip, have a look at the Atari ST blitter chip mentioned above. The 8514/A "standard" was the first to my knowledge to provide graphics primitives on an IBM PC compatible card as an API, to my knowledge (and, as such, the first "Graphics Accelerator Card" for the PC. That was, however, rather intended as a hardware copy protection. – tofro Oct 10 '17 at 14:56
  • 1
    @tofro: The EGA didn't include DMA, but it did have blit-ish functions. When the CPU reads an address in the 0xA000-0xAFFF range, a 256K EGA will latch eight bits from each of four 64K banks. Depending upon how mode registers is set, a write can update one byte in each bank based upon a combination of the latched data and the values that were written. There are a lot of modes, some of which seem much more useful than others. – supercat Oct 10 '17 at 17:17
7

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.

  • Out of interest, was just looking for a retail price for the 8089. Found one in April 1982 Radio Electronics magazine for $90 -- which comparing it against a Z80A-DMA at $28, or even $35 for an 8088 or $60 for an 8086 seems a bit expensive, but I guess they cost more due to not being all that popular. – Jules Jul 17 '18 at 6:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.