9

I'm building a Z80 home computer and I need color graphics for it similar to other home computers such as the C64.

I thought that, like Motorola or MOS, Zilog would have a peripheral chip dedicated to Video Generation (like the VIC/VIC-II or Motorola 6847). But I couldn't find anything about such a Chip or Chipset.

The only thing I was able to find is that apparently most Z80 computers just connected to a TV via RF, but trying RF modulation on my own without any knowledge of it, would probably not be a good idea.

So what kind of video chips would be compatible with the Z80 that wouldn't cause any major timing issues? Or maybe other projects where they already documented everything I could use for my own system. I couldn't really find anything.

I'd just like to know before I go out and buy some chips.

  • Do you want to connect it to old analog TVs, to old analog VGA monitors, or to modern LCD monitors? – dirkt Jul 25 '18 at 9:13
  • VGA would be too modern, I was thinking about Composite or RF, both are still used today so I guess it would be the best choices for a video output – Proxy Jul 25 '18 at 9:43
  • Since VGA(alike) is still within TV range - and composite, as well as RF is adding complexity, I'd go with a simple RGB output, which next to any multisync CRT (or not too modern LCD) can pick up. – Raffzahn Jul 25 '18 at 12:37
  • what kind of RBG, like connector name.the only Analog RGB connector i know is VGA.... my TV also has this weird YPbPr jack – Proxy Jul 25 '18 at 13:06
  • VGA uses an HD-15 connector to output RGBHV. YPrPb is component video, not the same but similar quality. There's also RGBS which usually goes through SCART or BNC. And there are a few other forms of RGB. Maybe VGA (RGBHV) is easiest. – snips-n-snails Jul 25 '18 at 20:33
13

TLDR; - See below

And I thought that like Motorola or MOS, Zilog would have a peripheral chip dedicated to Video Generation (like the VIC/VIC-II or Motorola 6847). But I couldn't find anything about such a Chip or Chipset.

Zilog never did any graphics chips, while MOS did a 6845 compatible CRTC - well, plus all the Commodore stuff.

The only thing i was able to find is that aparently most Z80 computers just connected to a TV via RF, but trying RF Modulation on my own without any knowledge of it, would probably not be a good idea.

RF-Modulator is something independent of the graphics chip and related to display connection. Also not really rare. Ready-to-use units can be found all around the net (Example). You'll still need a video source.

So what kind of Video chips would be compatible with the Z80 that wouldn't cause any major timing Issues?

The question is less 'what's compatible' but rather what's available. It sure is possible to use even a C64's VIC2 with a Z80 system, but acquiring one means taking a C64 apart (*1). Also, I think it's safe to assume you're not firm with designing of such systems, so the selection should be easy to implement and handle. There isn't much left in that fits these criteria.

I'd say the prime choice would be a V9958, as it is still available in good quantities at reasonable prices. Even more, there's a good documentation and plethora of Z80 coding examples available, as it was the controller used in MSX2+ (*2) computers.

The V9958 is based on TI's iconic 9918 and fully compatible. So while that one is also still in supply, why go for the lesser? In addition to higher resolutions and more colors the V9958 even includes hardware accelerated commands for line draw and block operations. Even more important for your intended use is a plain RGB output, enabling an easy setup for VGA screens.

Finally there's the V9990. While mostly compatible with TMS9918 and V9958, it offers again improved resolutions (up to 640x480@4 colors), more speed and >120 sprites on screen - a dream for classic tile based game programming. On the negative side it features a QFP package, so you have to like SMD (*3). Considering that most actual chips are SMD anyway not so much of a bad thing. The V9990 is also in good supply, so no need to crack open various game cartridges (*4) .

All TMS9918 family chips offer a great advantage simple (8 bit systems): Video RAM is separated and only a few ports are needed for communication. Address space is a premium on 8 bit systems and not needing some (usually a lot) for video buffers is heaven sent - or the reason why TI did id (beside simplifying access and DRAM control :)).


In a nutshell:

  • Take a TMS9918 if you want to have the real good old feeling of many limitations and a wired video interface.

  • The V9958 for a great and simple solution with many features to play with

  • Or the V9990 if you want to get something that may more fit today's needs - the maximum possible except building your own chip and/or slaughtering an Amiga.


For further reading you might want to take a look at these questions:

Or take a look at the Steckschwein project. Their new video card (*5) uses a V9958. Also a nice example that more generic chips, like video, are less CPU dependent, as the Steckschwein is a 6502 system, where the 9958 was designed for Z80 systems.


*1 - I wouldn't mind getting rid of one more of them - but even after selling the SID on ePay, there's still about the same amount of electronic waste left as before taking apart </DuckAndCover>

*2 - The 9938 used in MSX2 got basically the same features, but might be harder to come by without taking an MSX2 apart.

*3 - The V9958 also got a little quirk to take into account when doing a board, as it's a 2mm DIP (condensed DIP).

*4 - Though, getting a Sunrise GFX9000 or a Tecnobytes Powergraph might be a good way to acquire an 8 bit compatible graphics card, as it's interface is based on the Z80 bus.

*5 - Their first card was TMS9918 based.

  • 2
    The list of home computers and game consoles that paired the Z80 with the TMS9918 family of VDP's and its derivatives is both LONG and DISTINGUISHED. – Brian H Jul 25 '18 at 16:41
  • the TMS9918 seems a bit rare, and i never soldered with SMD and it would also break the feel of this project. so i will look at the Yamaha V9958, it seems quite powerful for an 8 bit VDP. one thing that confuses me though is the strange clock speed of ~21.48MHz, i mean it says that it can go up to 22.55MHz so it would be alright if i just use 22 MHz to not have to deal with odd numbers. also that measn this chip is twice as fast as my CPU... is that a problem? if not then i can test it out with my Arduino Mega like i do with all hardware before i put it in my Z80 system – Proxy Jul 25 '18 at 17:40
  • @Proxy the TMS9918 predates the TMS9918A, which adds an extra graphics mode and is the one most widely used. The former was in the TI-99/4 only. I don't know whether that affects your search. Also the 9928 and 9929 are the same thing with different output. The 2s are S-Video rather than composite; the 9929 is 50Hz rather than 60. – Tommy Jul 25 '18 at 18:03
  • i searched for the TMS9918A and it only showed the ANL at most. and even those were rare – Proxy Jul 25 '18 at 18:34
  • 1
    @Proxy No, (clock) speed isn't a problem here, as the CPU interface is asynchron with the chips clock. – Raffzahn Jul 25 '18 at 19:06
5

Partly as a joke: if you want you can rely on no specialized video chips. Take a look here (schematics), it is ZX spectrum clone that is able to generate TV video (either black-and-white or RGB) in about 30 TTL ICs, plus Z80 itself, plus ROM and eight DRAM chips.

5

You could build your own relatively powerful video controller.

One option is to use dual port RAM to hold a bitmap display, and have a microcontroller on the video side that handles generating the actual video signal. It helps to clock the micro at some multiple of the video signal, or at least close to it.

You can have the microcontroller produce the display by simply clocking words out of the RAM directly into a DAC or lookup table (EEP)ROM. The latter will give you a classic 8 bit fixed palette, the former could do 3:3:2 RGB.

You could also have a command table in the dual port RAM that the microcontroller reads during the vertical blanking period, to allow for some graphics acceleration like line drawing and blitting.

Alternatively you could use a Spectrum/C64 style set up where instead of bitmaps you use a combination of block attributes and bitmaps, again with the microcontroller. You have great flexibility to develop different modes with this system.

Another option is to use something like an ARM or Propeller microcontroller with its own on-board RAM and some kind of interface with the Z80. A reasonably fast ARM with DMA for the display could connect directly to the Z80 bus, or you could use RS232 or similar.

Actually, even a modern 8 bit microcontroller could connect to the Z80 bus with minimal hassle, when the clock speed is an order of magnitude higher than the Z80. A well crafted interrupt or DMA trigger could accept writes to the Z80 bus easily. Alternatively some PIC parts have a built in Z80/6800 compatible bus anyway.

  • 2
    It's a bit of a segue, but the just-announced VidHD is a good example of this. It's an expansion card for the Apple II that disables its internal video and provides a dual-ARM reimplementation which natively generates HDMI rather than the original NTSC composite. Alas only original announcement slides available in the way of information, with no concrete details on the generation side of things; they're primarily about Apple II video: drive.google.com/file/d/1cm52xhgW6aIsIcCM_V_Qw-438tG6e5tS . Slide 9 is the closest to relevant. – Tommy Jul 27 '18 at 13:55
4

The TMS9918a and family were commonly paired with the Z80, e.g. in the ColecoVision, original MSX, Memotech, Sega SG1000 and elsewhere. It provides a Spectrum-esque background, albeit with 8x1 attributes, and hardware sprites but be warned that there's no hardware scrolling. It's tile-map based though so an 8px scroll is easy and speedy.

It's relatively unique amongst 8-bit solutions in having its own dedicated RAM though, which might mean a more complicated build than you were hoping for?

Both the MSX 2 and Sega Master System use different backwards-compatible developments of the same chip with improved scrolling and sprites, but they tend to be harder to come by, both having been approximately specific to a single machine. The MSX 2's Yamaha V9938 or the later V9958 are the more likely to be findable.

A pin-up compatible FPGA implementation of the original is available in the form of the F18a supposing you wanted to stick to an authentic design but preferred not to try to pull 30-year old chips to build it.


If you wanted to use one of the 6502 chips, the CPC's solution to bus sharing is simple and would work.

Supply a 4Mhz clock to the Z80. Also build a WAIT generator, which has a four-cycle period. For the first three of those cycles, assert the WAIT line. On the fourth leave it alone. I'll number them for clarity:

  • cycle 1: assert WAIT;
  • cycle 2: assert WAIT;
  • cycle 3: assert WAIT;
  • cycle 4: don't assert WAIT.

That will have the effect of ensure the Z80 accesses memory only during cycles 4 and 1.

That allows you to run whatever you selected from 6502 land at 1Mhz, as they'd expect. Just signal PHI1 during cycles 2 and 3.


Similarly, don't rule out just not making shared usage transparent. Systems like the TRS-80 had the simple rule that if the CPU and video circuits both try to read the same physical chip at once then the CPU's address is the one communicated, and the video simply gets a value other than the one it wanted.

Vsync, etc, is then made visible to the programmer, and it's their job to avoid graphical interruptions.


Of the other Z80s, the only one that I'm aware of with shared memory but an asynchronous design is the Enterprise. That also would work with a 6502-esque chip and relatively simple arbitration.

The logic is pretty simple: there is one clock for the video. There is another clock for the processor.

The arbitration logic sits between the CPU's crystal and the CPU itself.

Reacting to CPU crystal clock transitions:

  • if the CPU is accessing something other than the shared area, or the video processor is in a fallow cycle, it applies a clock transition to the CPU;
  • otherwise it does nothing.

On that machine video data is fetched in two cycles out of three of the video clock; as many Z80 accesses as will fit then occur in the other one. With something like a 6847 it'd be every other cycle that the Z80 was allowed to access the shared resources in.

This scheme scales to any CPU input clock. Also the pauses are never very long so even if your CPU weren't static (though Z80's classically were), it shouldn't be problematic. And if your processor can fit multiple memory accesses into the video gap, it will.

  • I'd say the dedicated RAM makes it easier -- no need to manage the bus contention. Sure, you need a second RAM chip (and a pair of latches to handle the fact that it was designed for DRAM but you almost certainly want to use SRAM in order to not need multiple RAM chips), but that's simpler than arrange for sharing the bus as you'd need for a 6845-type solution. – Jules Jul 25 '18 at 8:24
  • slowing the CPU down to 4MHz doesn't seem like a good move though. also one reason why i don't think i would want to use any MOS chips, most were made for the 6502/6510 which runs at a 1/10th the speed of my Z80... – Proxy Jul 25 '18 at 17:42
  • @Proxy yeah, the Z80a was of course only rated for 4Mhz, so the scheme makes more sense there. I'll add some comments on what other machines I'm aware of do, in case they're of any help. – Tommy Jul 25 '18 at 17:52
2

No, the Z80 did not have a preferred or Zilog-designed video controller. The Z80 was developed when integrated video circuitry was just about coming up and everyone was still using serial terminals.

You didn't exactly specify what your requirements are. Graphics, text-only, resolutions?

A simple text-only VGA video interface can be built from an AVR and some dual-ported RAM. There are various example projects out there.

The next stage of sophistication would be a text-only implementation based on a Motorola 6845 or one of its successors.

Once you are looking into graphics, the memory map and 64k restriction of an 8-bit CPU comes into play - you need to decide how you want to address serious amounts of frame buffer memory, for relatively "modern" screen resolutions, you will definitely have to look into memory banking. You can build a graphics display based on a 6845, but that gets a bit complicated.

The Yamaha chips for MSX and MSX-2 (V9938 and successor) would be a good starting point with some interesting concepts on framebuffer handling.

  • I have no idea what would be a good resolution for text or graphics, which is why I didn't specify it. My systems only uses half of its addresses for ROM 16kB × 16 banks and RAM 16kB × 16 banks. – Proxy Jul 25 '18 at 9:54
  • @Proxy On a side note, you might want to use three ram banks within address space to enable A op B -> C operations without too much banking. Even if the programm is in ROM. – Raffzahn Jul 25 '18 at 12:39
  • "A op B -> C operations" what exactly is that. i'm pretty new to the whole Retro computing thing... so please excuse me not knowing some or a lot of things – Proxy Jul 25 '18 at 13:08
  • @Proxy - operations that take two memory buffers and copy the data from both of them into the third, e.g. taking a background and overlaying another image with transparent sections onto it (an example of the category of operations generally called "blit" or bitwise logical transfer). – Jules Jul 26 '18 at 20:04
2

While it wasn't designed to be compatible, there were numerous machines that paired a Z80 with an MC6845 chip. Typically these designs used a separate timing controller (perhaps built using some kind of programmable logic) to latch the 6845's output signals and either drive them onto the bus during periods when the Z80 is guaranteed not to use the bus (e.g. in the two empty bus cycles that always happen after an instruction fetch) or suspend the Z80 (typically by asserting WAIT) until the access is finished. The best known of these was probably the Amstrad CPC464. For a simple implementation, you could even just stop the processor while the screen is being drawn and only run it during retrace intervals.

Another alternative, albeit not a popular one, is the Intel 8275. This is very similar to the 6845 in capability (i.e. it's designed for text mode output, but can be used for general raster graphics because it relies on an external character generator, which can be swapped for a graphical decoder if you prefer), except it's designed to integrate with an 8257 DMA controller in order to control access to the bus, and has memory buffers that read display data ahead of being required to make timing easier. The 8257 DMA controller's protocol and timing is compatible with the BUSRQ/BUSACK signals of the Z80, which means if you don't need an external DMA chip it can be wired directly to a Z80. One limitation, however, is that it supports a display of at most 80x64 blocks, and expects its data to be 7-bit ASCII with embedded attributes (allowing 5 bits of attribute control), so with a 2 byte sequence you can control 12 bits of output... this somewhat limits the total output resolution if used in graphics mode. It would be sufficient for a 320x192 monochrome display.

0

A major question to consider is whether it would be acceptable to tie up the Z80 during significant parts of each frame. If one is willing to tolerate a severe amount of CPU loading, one could produce a Z80 video subsystem with a surprisingly small number of off-the-shelf parts. The Sinclar ZX80 used off-the-shelf chips but couldn't maintain a video display while the CPU was trying to do anything else. The ZX81 used some custom silicon, but added a "slow mode" that would let the CPU run for a little while each frame and then interrupt it when needed to generate the video. The "slow mode" could also have been achieved using off-the-shelf chips, but I think the custom silicon was a little cheaper.

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.