In this Series

We're going to build a replica VZ200, a very interesting off the shelf home computer, done on the cheap, but also quite popular in the markets that it dominated.  In this part we will go over the chipset at its heart and try to explain how it's one of the cleverest little minimal designs of its time. 

We will work with PCBWay (our sponsor) to build a brand-new backplane system all on cheap 100x100 or smaller PCB's just large enough for the task at hand and were going to do it all up open source, so you can hack on it to your hearts content and maybe make your own!

So come along with me as we explore the chip set of the VZ200, and the cheap computer that took the hearts of many young programmers.  It should be a very interesting prospect indeed, and in the end hopefully we get a working computer to show for it.

The Basics 

The VZ200 is a Hong Kong based VTECH (then Video Technologies) designed home computer. Produced in 1983 and based around the venerable Z80 CPU, and curiously the 6800 family IC the 6847 VDG (of Tandy CoCo fame).  The computer's clock is operating at the NTSC color burst frequency, approximately 3.5795 Mhz.  This computer was a first for a lot of kids in the eighties in places like China, Australia and Germany.  NTSC versions did exist but the majority of the machines are PAL based (a fantastic story but not why we are here today.)

The computer normally outputs in PAL, though NTSC versions do exist. The chrominance and PAL line timings are generated by way of a daughter card, whose schematics have been redrawn by this clever user on GitHub.   Video oddities aside, the scope today is simply to go over the 3-chip chip set, because like so many costs reduced computers of the day, it really was able to squeeze a ton of functionality out of such a low chip count.

The Design goals (squeezing blood from stone):

The VZ-200 uses 3 ICs to do all of the address selection and decode, 2 multiplexers (74LS138 and 74LS139) and a Quad OR (74LS32) .  It also manages to control the bus arbitration for the VDG, simply as a side effect of fan out. The logic is all standard LS type logic so we can fairly well guess the propagation delay from the data sheets.  Since the clock speed of our Z80 is known (approx.. 3.5795Mhz), we can calculate the T≈279.4nS.  If we look at the actual logic design we can then simply calculate the timing delays for all of the select lines by doing some simple arithmetic.

We have good schematics for the VZ200, so we don't have to guess how they are all connected.  for simplicity of this demonstration I took the liberty of building just the decode section in  H. Neemans Digital

The chip set had to do five things ascertained by simply looking at the outputs:

• Control a number of 2K SRAM chips
• Control a number or 8K ROM chips
• Time High-Z logic for the VDG address lines
• Control a memory mapped IO range
• be cheap.

It is strange on a CPU that has a dedicated IO port instruction would have anything in the way of Memory Mapped IO.  IO ports make accessing devices on the bus simple for the CPU but they can also add complexity to the selection logic.  It is odd, but also pragmatic.

Z80 Cycles:

IO selection on the Z80 happens when the CPU uses the OUT or IN instructions (mostly, but we will only go into that use case here).  When this happens, /IORQ goes low, and /RD or /WR goes low as well.  There's also another reason /IORQ goes low; that's during an interrupt acknowledge, however in that case M1 goes low.   So, to find all address ranges accesses that are true OUT/IN instructions we have to look at M1, /IORQ, /RD and /WR.  Just to get started, however the second case in this issue is the IO ports happen only on the lower byte of the 16-bit address bus.

If we organize the IO ports into 16 x 16 port ranges numbered 00-FF we need to ALSO look at a completely different set of address ranges to keep the ranges small.  In our example, all of the 16x16 ports would require address' A4-A7, when we look at our logic diagram for the VZ200 we can see we already are running a trace from the CPU for A11-A15, at the end of the day that is 2x the address lines simply to minimally decode an IO port range.  This leads us to the understanding that memory mapped IO was used simply so that the designer didn't have to bother doing the extra logic for the handful of ranges required for sound, video registers, tape signaling and keyboard.

Defined IO ports from Technical Reference Manual: 

In the simplest terms, it appears the designers only wanted to worry about one kind of /RD and /WR strobes. By limiting the IO range to only the active memory portion of the CPU's active cycles, you no longer have to consider or decode anything in the IO port ranges (which also require different address lines).

In short it was cheap, cheap is a core goal.

2K SRAMs, and 8K ROMs were very cheap at the time the computer was designed, so it's not a surprise they were chosen as default.  Optional ram expansions did use DRAM, SRAM was likely used in the core unit to save on even the small amount of hardware required for address decode and refresh. The computer itself in its most usual stock configuration has 

• Two 8K ROMs (for a total of 16K of level II basic)
• Four 2K SRAMs (three for 6K of user memory, and one for write only display memory)

if we take a look at the Technical Reference Manual, we can see the full memory map (here is simplified):

Simple enough, but you can see, most of the actively decoded section is at the top of memory, except for the first 2K of user ram. Conversely, decoding of that top 4K section is not hard to figure out, it's the single 74LS138 with an average propagation delay of 21nS, this hits our 279nS T budget by a long shot, the great part of this decoder IC is its basically purpose built for 2K / 8K selection logic.  

The dirty part of the trick comes in when you realize that due to the way the select lines work on this chip, wired in this way, it only selects 8000-BFFF.  Meaning the stock chipset completely ignores C000-FFFF (This turns out to be no issue at all, as that space is then handy for memory banking designs, but more on that later).

By the numbers:

Each of the three chips have a calculable delay timing (which we can determine an average delay through each.)  As we have said the delay for the upper ram is on average 21nS according to the LS138 Datasheet, in all cases having the ram decoded before a read or write strobe happens is the goal and this chip by itself beats it by miles. 

Very Rough Estimates:

Looking at the datasheets, we can see the propagation delay for each device.   And from this we can see the 8K ranges come up fairly fast in 47nS, about twice as slow as the upper ram decode which is the fastest thing the chipset does.  We get to this number by adding the propagation delays and all 8K ranges take one OR gate, and a single stage of the 74LS139.

Pathway through the chipset:

                +-------------------+
                |       Z80 CPU     |
                |  Addr[15..11],    |
                |  /MREQ, /RD, /WR  |
                +---------+---------+
                          |
                          v
                +-------------------+
                |   OR Gate (A15 +  |
                |       /MREQ)      |
                +---------+---------+
                          |
                          v
                +-------------------+
                | 74LS139 (Stage 1) |
                |   8K block decode |
                +---------+---------+
                          |
          +---------------+---------------+
          |                               |
          v                               v
+-------------------+            +-------------------+
| 74LS139 (Stage 2) |            | Direct 8K selects |
|   2K sub-decodes  |            | (ROM00, ROM01)    |
| (MMIO, VIDR, RAM) |            |                   |
+---------+---------+            +-------------------+
          |
          v
+-------------------+
|   OR gates with   |
|   /RD and /WR     |
| (MMIORD, MMIOWR,  |
|  VIDRWR outputs)  |
+---------+---------+
      
  

Taking a further look at the 2K ranges, we can see the lower ram (RAM0), the memory mapped IO ranges and the first of two video RAM strobes.  This is the meat and potatoes of the chipset.  Nearly all of the strobes happen from this place with the exception of the actual video /WR strobe.  This is, the most interesting and clever part of the design, and as I was doing research it surprised me at how simple it is.

Timing Delays:

Taking a look at the very edge of the decode circuit we can see that the video selection falls into two cases, 2K decode and qualified control.  This qualified control line is built with a second OR gate, which bundles the /WR line with the video selection in the 2K decode range.  The reason we don't use /WR and the 2K Video RAM select signal directly on the SRAM instead of the qualified control signal, is due to the way that the 6847 expects to handle bus contention.

Making it snow, the 6847 address strobes:

The 6847 has to strobe through the display RAM to build the raster 60 times in a second, no matter what.  But what if we want to write the ram at the same time?  There are loads of ways to do this: Synchronizing the clock by running it twice as fast, by using latches to handle the writes so they only fall when the VDG isn't on the address bus, or (what we are doing) simply ignoring synchronization. We do this by forcing the 6847 off the bus during the write and read cycles, which creates display artifacts. 

The VZ200 uses a bank of resistors to split the address bus CPU side and VDG Side.  These resistors dampen the signal to from end to end. This is done so that when the VDG is writing to the address bus, it won't be able to pull down the CPU's address lines and cause damage and contention.  These resistors are also sized appropriately so that during a memory write or read, the signal from the CPU will still register as a high, though it will be considerably dampened (more on this in a minute).    Realistically doing this with buffers would require another two IC's and VTECH couldn't have that, instead they took a page from Sir Clive Sinclair's book and just put in chunky resistors to do their dirty work.

Really, there's two problems: The first is the address bus as we have mentioned, but the second is data bus directionality.  The RAM IC is normally just outputting its contents onto the data bus, but also it has to read from the bus occasionally during video writes.   This is accomplished using a bidirectional bus transceiver - but the rub is it has to switch the bus direction and get the ram chip off of the bus BEFORE we strobe the ram, we also have to do this with enough time to keep it within our T state of 297nS.  We would also like it only long enough that when it collapses the raster generation can continue.    

From the VDG side its actually quite simple, the 6847 has a /MS (memory select) pin that when strobed low causes the address lines to go into High-Z (tri-state).   We control this from the first of two video strobes along with the rest of the rest of the 2K ranges.   This selection line enables the bus transceiver and allows the data through while the /WR line tells the transceiver which direction the data flows.  The /MS line is also driven Low at the VDG, which allows the damped signals from the CPU to control the address pins on the RAM chip uncontested.

Time --->

ADDR[15:0]      ===[ 7000–77FF ]========================================
/MREQ           ______________________\__________________/______________
/WR             ____________________________\__________/________________

Decode /2KVIDR  ---------------------------------\___/-----------------
(OR + 2x139)                                   (~72 ns after ADDR+/MREQ)

/VIDRWR         -------------------------------------\_____/-----------
(/2KVIDR & /WR; delayed by one OR)                (~94 ns total)

Skew            
Purpose         Ensures any VDG‑related strobe (/MS) could occur
                before RAM /WR, avoiding overlap in single‑port designs.

At this point, we are still JUST BEFORE, we actually write to the RAM, but how do we tell the RAM IC to hold off latching the actual data?   This comes by way of the second OR gate, which we call our qualified control line.  This simply comes down to propagation delay timing.  The second OR gate takes another 22nS to trigger the low signal, and so right around the same time busses are in a perfect state to latch, 94nS later - the data latches.   At that point the CPU backs out the cycle, this releases the /MS line (and all the other addressing).  Once released the VDG continues to build the raster.    

If at any point any of the above happens during the same time the VDG is drawing the raster, it causes an artifact (snow) to appear on the screen.  So this is the reason the VZ200 shows a snow effect when updating the screen in video games, The RAM chip can only be accessed by one device at a time, and the pixels are literally being drawn as a white dot when the CPU is writing.  

Looking forward, when we replicate the chipset, this timing window would be the hardest part to reproduce using simple devices like a GAL, as mostly there is fixed timing delay from one side of the device to the other.  To prevent this issue, we may have to upgrade the video circuit to handle bus contention another way.  This is a bit of foreshadowing, but I think it's significant to point out here.

The Memory mapped IO range is minimally decoded, with the analog outputs being built with simple differential pair circuits, and the keyboard matrix is strobed using the address bus.  Both are well documented in the service manual, and so I won't take a lot of time explaining how they work.  It is a very clever way of scanning a keyboard, and similar to how the ZX80 scans the keyboard.

While the VZ200 isn't as minimal and exploitive of the Z80 decode cycle, as say the venerable ZX80, it still is a very clever design.  The fact that many clones exist as well as multiple revisions tell us that it was easy to manufacture, as well as inexpensive.  I think this is one of the big reasons that it sold so well in areas were Asia had good access to the high street markets, like in the case of the Dick Smith version.

In a future post, I will go over the tool chain I use to develop the chipset replacement in our modular backplane system.  But I do want to take some time to thank our sponsor PCBWay, who's always been a very good partner in all our projects.  Please take a look at all the services they have on offer for your next project.

Feel free to leave a line if you think I've gotten something horribly wrong.   I have started on building up the PCB's for the recreation and have been posting my progress mostly on Facebook.  For now, that's about it, but I expect to make intermittent progress as this whole writing on the internet is my 5-9 but I would very much like to make it my 9-5.