• The Curious Case of the VZ200 Chip-set (Part 2)

    12/15/2025 at 04:00 0 comments

    What’s next?

    We’re still chugging along on the VZ200 clone, building it out as a set of RC39‑style modules on a back plane, all as part of our open‑hardware project with PCBWay. A bunch of the boards are already up and running, and the machine now boots into a serial ROM monitor where I can poke at RAM and ROM, its early days however things are progressing nicely!

    RC39 Backplane with VDG Board installed


    But then I hit a snag with the display memory circuit.

    So this is the story of what happens when you take a simplified 1980s chip set and try to squeeze it into a GAL to save board space and a bit of cash. Let’s walk through what it actually takes to get this tiny display module to read and write its RAM chip the way it’s supposed to.

    The VDG problem:

    Last time we talked about how the 6847 expects bus arbitration pulses to clear its address strobes off the bus so the CPU can write to memory. We went over how this creates snow artifacts as the 6847 tri-states the address bus outputs. We also went over how the timing of the specific logic inside the circuit is paramount to making sure the 6847 is off the bus so that the CPU can make an uncontested write operation.

    The Schematic:

    But what if we don’t want to use LS logic from the 1970s to accomplish our video module? Let’s go over the video circuit in detail by looking at the schematic.

    rweather schematic snip linked to github

    We see that the data bus is separated by a bus transceiver, from the 6847 (VDG – Video Display Generator) and RAM chip data pins. Going over what we know about the VDG from the last time, it has to strobe through all of the addresses on the RAM chip and build a raster 60 times a second no matter what. That's because the 6847 isn’t really a video display processor, it’s a finite state machine (FSM) with selectable states. Some of these states are selected by data pins, and some are selected by separate control signals from an external register typically (in our design they are). The VDG really only knows how to run a few tight loops: scan the RAM and display in text mode, scan the RAM and display in graphics mode and so forth. These “states” in a fixed path tight loop are what makes the VDG a state machine and not truly a dedicated video co-processor. Essentially, it scans the RAM really fast and pushes out a bit stream, as well as create all of the relevant sync and color information pulses over and over; forever, unless you change the state or interrupt them. Think of it as an elevated version of the “TV Typewriter” but with much of that circuit already built into the box, including the character ROM!

    The Crux of the Problem:

    So we have established, essentially, the circuit has to keep the data bus and the address bus clear of contention whenever the 6847 needs to push out a frame to the display. The circuit does this by separating the address bus with a bank of resistors, and the data bus with a bus transceiver. When the /DRAM signal is generated in the chip set the address bus on the VDG cuts out, the data bus aligns with correct directionality, and the RAM chip is selected. Ultimately this creates snow because the CPU does not know when the VDG is on the RAM it only knows it can knock the VDG off the RAM by writing to or reading from it. This works well, it’s simple and cheap but obviously the issues are:

    • Timing is tied to the logic family, and the specific construction requiring multiple chips
    • Even though the CPU and the VDG are clocked by the same clock, they are not synchronous. The Address decode, write and read cycles of the Z80 prevent the two devices from truly being able to avoid contending with one-another.
    • The VDG is knocked off the bus on every single write and read to the display memory, this “second fiddle” bus positioning means lots of artifacts.
    • Artifacts are annoying and they can ruin user experience.
    • The decode circuits cascade decoder chips, which leads to large ...
    Read more »

  • The curious case of the VZ-200 Chipset (Part 1)

    11/26/2025 at 22:25 0 comments

    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.)

    VZ200 Home Computer
    VZ200 image by way of wiki commons

    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:

    Cycle type MREQ RD WR M1 IORQ
    IN (I/O read) 1 0 1 1 0
    OUT (I/O write) 1 1 0 1 0
    Interrupt acknowledge 1 0 1 0 0
    Opcode fetch (memory) 0 0 1 0 1
    Memory reads 0 0 1 1 1
    Memory writes 0 1 0 1 1
    Bus idle / no cycle 1 1 1 1 1

    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,...

    Read more »

  • New DC-DC Circuit for the 48k Speccy

    06/30/2024 at 04:59 0 comments

    Just before applying the DC-DC mods for the original circuit
    Just before applying the DC-DC mods for the original circuit

    I received this 48K spectrum from a friend, in a mostly working state.  It needed to have the membrane replaced as well as one of the 32K ram chips.  Through the process of rework the DC-DC converter circuit began to fail.  I believe as a result of being run at a high level for a long period of time, from an unregulated 9v supply that may have drifted slightly.

    On initial inspection, I determined the 4116's must have failed as TR4 / TR5 kept blowing.  I replaced them (t4 and t5) and removed the ram chips, to no avail as the transistors kept failing even with the ram chips removed.  The next on the list to check was all the capacitors, I verified none were open or dead short with good ESR values ( all electrolytic were replaced first thing - and the board worked for a few hours at least).  I suspected the coil was bad.  At this point I started to deep dive into the circuit and read through two separate circuit descriptions trying to determine:

    1. why this circuit fails so much.
    2. why this was the most modified part of the circuit throughout the revisions.
    3. can this be improved uppon.

    I asked my father, who was an EE from the 60's all the way to the 90's to take a look at the inverter / DC-DC circuits across the several revisions as he's vastly better at looking at analog circuits than I am.  Together we determined that the DC-DC mods specifically address regulation and clamping issues in the previous versions of the circuit.  While these improve supply output and manage transient voltages which feed sensitive ram chips it does not address what is conspicuously missing from ALL revisions of the 48k DC-DC circuit; 4116 bring up timing.

    The 4116's and by in large the transistors inside the DC-DC circuit fail because the supply does not adhere to this note in the 4116 Datasheet:

    Simply put -  There is no timing mechanism beyond the R/C delay inside the circuit itself, which grants exclusively that VBB (-5v) is applied first, and removed last. Furthermore, when power is removed to turn off the system if the ground path is eliminated by disconnecting the cord completely or isolating the ground line in an improperly  wired switch. There is no way to assure any sort of state on power down.

    So - specifically when the 4116's fail, and they usually will, the DC-DC circuit is often damaged by an over current condition on the digital 12v rail.


    So how did I improve upon the design: 

    Back in the 80's the most commonly used dc power supply was an unregulated 9v center negative power supply.  Specifically because of this utility its obvious to me that that is the reason that iconically thrifty Sir Clive and his engineers chose this to be the supply they were to use.  Moreover - not wanting to spend any amount on a switch for every unit allowed them to cut the prices even further to save Sinclair millions, by simply having the public unplug the thing or turn the switch off at the wall socket.  What was needed was a minimal, cheep and dirty power circuit to create the multiple rails required for the computer and not break the bank.  I think they did the best they could with the limits they had, and specifically the computers worked well enough in the day for this oversight to not matter nearly as much as it does today.

    Today, we have commonplace, high quality 12V regulated power supplies that run cool and efficient and don't really break the bank. I decided to remove the DC-DC circuit in my issue 3, and use an external regulated center negative 12v power supply to power the whole computer.

    This has several advantages:

    1. The supply is more efficient we no longer have to "boost convert" a 12v rail using a charge pump and inverter. This reduces losses to multiple conversions going from 9v - > +5V -> +12v & -5v
    2. The supply is cooler - the LM7805 linear positive voltage regulator gets...
    Read more »