Lobsters retrocomputing - 13 Sep 2026

Page 5 of 8

Eventually I hit on a cheap solution of my own: a small single-layer sliver of alumin(i)um foil. I put the foil strip between the two points of the break and secured it with Kapton tape, and the whole thing laid nice and flat. If my theory turned out to be wrong, I could just remove them and try something else. But the keys now do work! Using the angle cutters I nibbled off any portion of the Kapton tape that might cover up nearby pads and exhaustively checked all the keys. They all worked. The keyboard is fixed. We then slip the keyboard PCB back behind the strut, making sure that the LED comes out through its little hole in the top case ... ... and replace the screws. Do not overtighten them or you will interfere with the conductive nubs being able to make contact. I had a couple dud keys initially after this which were returned to life by slightly loosening the screw nearest to them (to my great relief). While we were in there, I decided to make sure the display quality was as good as possible by tweaking the colour encoder's trim adjustments, since its components had likely drifted with age. On this board the two trimpots control the colour phase, while the trimcaps appear to adjust image stability. I wrote a quick BASIC program to display the 6847's full palette, which is only possible using semigraphic characters, and tweaked it by eye for good colour on both my handheld composite display, the Commodore 1702 and my composite capture box. Here is how it came out with alternate text colours (i.e., with the 6847 CSS pin set with COLOR ,1): and the default: That brings me to a brief digression on the VDG and colour. Many people, especially those who have only used VDG-powered machines in emulation, think they emit beautiful fully saturated RGB, that the green is a gorgeous #00ff00 and red is #ff0000 and so forth. That is definitely not the case; in fact, the default VDG palette is rather a bit muddy, with relatively poor saturation. For example, black (what the border is supposed to be) is often more like a very dark brown, buff is a dirty off-white, magenta becomes a flaccid purple where the red is a little too low, and what the documentation calls cyan comes out closer to seafoam green. Unfortunately, many simpler or older emulators provide an excessively rosy (no pun intended) simulation of what these typical home computer implementations usually generated. MAME uses the correct palette and the VDG's Wikipedia entry has a credible synthetic screenshot based on the YPbPr values in the datasheet, which you can compare with the real composite grabs above. That does not mean that the MC6847 VDG is incapable of good quality colour. It is absolutely capable of good output, but to do so it needs a quality encoder, and the VZ's ain't it. The best colour I have ever seen from a VDG is actually the Super Micro Script's, using a very high quality output stage as shown in the actual grab above, and comes out vibrant, beautifully saturated, and fabulous on a CRT. You would expect that, however - it's a $500 prosumer video titler from 1985, not a $99 crap home computer from 1983.

The next order of business is software. I'd rather not use tape or audio files, and I don't have the disk drive. Fortunately, because the VZ series is so beloved in Australia, those wacky Aussies occasionally create their own modern peripherals in between prawns on the barbie. If you have a VZ-series computer, then you need the BennVenn VZ300 SD Loader. It is fairly inexpensive and provides you a way to load software into your VZ-series computer via SD card, along with topping off the RAM, even more memory with bank switching, and optional solder-yourself connectors for gamepads and I/O expansion.

I figured it might be fun to build some hardware for it (and we're going to create a very simple expansion ourselves for the VZ200 in this article), so I ordered the full kit. It works well for my purposes and my wife has ordered another for the VZ-300 now at my in-laws' house in regional NSW. However, I am neither affiliated nor associated with Ben, merely an overall satisfied customer, so this is the part where I will also make three gentle constructive complaints about it.

First, things like new firmware are largely delivered through a private Facebook group. This group appears to be very welcoming to new members, but it requires you to be on Facebook, and I don't want to be on Facebook. I managed to get the current firmware another way, and I will be putting it in the Github repo for this project so you don't need to join Facebook either. (If you do want to join, however, I'm sure the "VZ200 VZ300 Laser210 Laser310 fans" group would love to have you.) On the other hand, Ben was reasonably accommodating of my questions over E-mail which I did appreciate.

The second complaint has to do with assembly. If you don't want to hook up joypads (it's reportedly compatible with SNES ones) or create your own expansion device with its GPIO pins, and you're only using the RAM expansion and SD card interface, then you can just put it in the included 3D printed case, insert a card, plug it in your computer and use it immediately. I think most people are doing exactly that. However, I wanted both those things, so I started on the GPIO connector first. The expansion GPIO pins need their own headers and Ben provides a set of right-angle through-hole headers that you solder on. Once attached, the 3D case has a thinned-out rear strip you can snap off to expose the pins. Unfortunately, the GPIO pins are not strictly wired in order, so finding a bad solder joint may require checking continuity in unexpected places. The proto board here that Ben used to sell has a set of surface mount LEDs that makes finding a bad line easier, and all of the LEDs should be lit when enabled, so I was immediately able to detect a couple of dud joints on my first pass. (It doesn't look like these boards were very popular and he doesn't appear to sell them right now; check his site for the latest.) However, I then proceeded to waste an entire hour reflowing one particular joint repeatedly that looked like the right one until I got out the continuity tester and realized the actual fault was elsewhere. I'm not sure why some of them were routed around instead of in a straight line. The third complaint also has to do with assembly, but the joypad connectors this time. VZ joysticks have various, uh, deficiencies in their design that I'll get to soon, but they also have two buttons, which means you can't directly substitute something more familiar like an Atari stick. (The Tomy Tutor has a two-button joystick, however, and being a Tutor dweeb I have a number in stock, so I might think about how I could use one of those.) Ben's solution was to implement support for Super Nintendo game pads, where they can emulate a VZ stick, and software aware of the extra buttons can read those too. There are no ports on the cartridge, though: you get to solder those lines on yourself as well, passing the cable through preweakened holes in the case that you ream out. I doubted myself several times on the orientation because of how the cartridge has to get mounted in the case. On the case side where the wires come in, the board is actually mounted upside down, and the joypads on each side are wired in mirror images of each other. I first wired the left pad completely wrong, then got it right but wired it to the wrong side of the board, then didn't notice the mirror image orientation and wired the second pad wrong. Police may have been called for a welfare check by this point. In the end I never got the joypads working. I realize I have less manual dexterity than an inebriated wombat, and it is possible that the Shenzhen knock-off SNES pads I used were defective, but I had continuity from the inside of the joypad all the way through to the SD loader board and it still wouldn't work. Plus, because SNES pads generate a clocked data stream, not individual switches like Atari (or Tutor) sticks, if you mess up even one line you'll probably get nothing. That's indeed precisely what I got, so I just cut off the ends of the cables and gave up. I may try putting a port on in the future and messing with it some more but I don't think I'm going to be up to that for awhile. I'm glad this unit exists; it just shouldn't have been quite that tricky to get the most out of it. Still, our prize for all that is ... the BennVenn board "just works" with this seppo VZ200, though I suspect this is the first time his board has ever been used with an American unit, and the TOM pointer is filled out all the way to 65535 as expected. It appears the cartridge thinks this machine is a Salora Fellow, a Finnish rebadge of the 4K PAL Laser 200 (by contrast, the Salora Manager is a Finnish rebadge of the CreatiVision-derived Laser 2001). This is determined by a simple memory map check in a snippet of its VHDL that Ben shared with me:

RAMarea300 <= '0' when (Address > x"B7FF" ) else '1'; --B800 or higher

RAMarea200 <= '0' when (Address > x"8FFF" ) else '1'; --9000 or higher

RAMareaSelora <= '0' when (Address > x"7FFF" ) else '1'; --8000 or higher

This section checks the detected top of memory and sets certain flags to be able to fill the rest of the address space with RAM. The VZ-300 has the most onboard RAM ending at $b7ff, so the cartridge only adds on an extra 18K. On the other hand, the Fellow's memory space ends at $7fff, just like ours, so it gets an entire 32K to fill the remainder. The cartridge detects our memory map is the same as a Salora Fellow, so we also get the extra 32K, which is exactly what we want.

I also plugged it into the DSE VZ-200, and it worked perfectly there too.

Since we're not going to use the joypads, that means we'll be using the joysticks. (Note from the future again: many VZ games play just fine with the keyboard and I didn't use the joysticks much after all, so I'll probably just not bother with joypads when I build the unit for the VZ-300.) The BennVenn cartridge emulates VZ sticks by default, even if the joypads aren't connected, but you can easily turn this off and use the regular joysticks.

The joysticks are technically three separate peripherals, namely two JS-20 joysticks and one JI-20 interface, though they're in practice one unit since they can't be easily separated; the joysticks themselves are soldered directly to the interface board (cheap!). Both the VZ-200 and VZ-300 joystick sets are internally the same. This is the interior of the interface, with only three chips: a 74LS09 quad-AND, a 74LS138 for address decoding and a 74LS367 hex bus driver. The computer itself has no specific support for reading the joysticks (cheap!), moving all the "smarts," as it were, to the interface and querying their state through ports in the Z80's canonical I/O space instead of memory-mapped I/O. When the IORQ line is asserted by the CPU, the 74LS138 is used to check the address on the low eight bits of the address bus, which are the only address lines carried on the peripheral port connector, and correspondingly enable (or not) the switch status for the appropriate joystick to be put on the data bus. Separate ports (39, 45) are used for the buttons as well as the directions (43, 46). Although we have a brand spanking new set for the VZ200, when I tested the VZ-300's some of the directions didn't seem to work at all, so let's see if we can fix them. I'll set some expectations here beforehand: even at their best these were pretty horrid joysticks. We know this because we can use the brand-new VZ200 sticks as a benchmark; they have little throw and you have to hit directions dead on or sometimes they won't register. This is because the stick pushes a plastic ring with four pins into one or more metal leaf-spring switches (again mounted on a crummy phenolic resin PCB) to indicate direction. Unfortunately these plastic pins are neither particularly durable nor especially hard, and unless you hit it squarely and precisely, the pin may not be able to engage the corresponding switch. The leaf-spring switches themselves can also go bad, either because the leaf is fatigued and stretched from too many presses, or because the metal button it contacts is oxidized or otherwise unable to make an electrical connection. To rehabilitate each directional switch in each joystick, I started by scraping the top of the metal button to ensure that there was exposed conductive metal, then crimping the leafspring against the button until that bit in the port went low (engaged). I then pried the leafspring up little by little just until the bit went high (unengaged) and checked the switch's responsiveness with my finger, repeating as necessary. This at least got the VZ-300 sticks to respond as "good" as the VZ200's, which is to say somewhere between annoying and obnoxious, and that's all I have to say about that. If the sticks fail again and end up being unserviceable, I think I'll look into a way of connecting a Tutor or modified Atari stick here instead.

When reassembling the sticks, be sure that the square pin on the bottom of the plastic ring goes through the hole for it in the switch board, and that the central screw is tight (the whole thing is spring-loaded).

For completeness, here's the inside of the RAM expansion. Even though I don't think this was subject to FCC clearance, and certainly has no tag for it, the box is sheathed in a sheet metal cage as well. The case has ventilation holes top and bottom, covered with a bit of screening to filter junk, but I can't imagine they would have helped much if that cage ended up trapping heat. On the PCB side, however, you can see what we need to see: eight footprints for, in this 16K expander, what must be 2K RAM chips. The TRM shows them as 4116 DRAMs. The rest of it, according to the schematics in the TRM, is two 74LS157 4-bit multiplexers for managing the address bus, a 74LS74 dual flip-flop, a 74LS123 monostable multivibrator, a 74LS32 quad-OR, a 74LS00 quad-NAND and a 74LS266 quad-exclusive NOR.

As we finish getting our system in order, there was one more modification I ended up doing out of concern for the workout I was giving its rocker power switch, especially when all I really wanted to do is merely reset the computer. (The BennVenn reader does not handle card re-insertion, even the same card, without a reset.) Like most CPUs of the time, the Z80 does not reset itself automatically when power is applied, so a small circuit in the VZ200 briefly pulls its reset line to ground when the power switch is first turned on. The length of time the reset line is grounded is determined by a single capacitor also connected on one side to ground. Once this capacitor fully charges, the reset line is pulled up to +5V and the chip continues operation.

Earlier VZ reset switches simply shorted this capacitor to discharge it, thus forcing the reset line to be grounded anew until the capacitor charged back up, and this particular modification was well-documented in Australian hobbyist magazines of the time. Unfortunately, although the TRM schematics label resistors and capacitors, the VZ200 board itself does not (or anything else), and the capacitor in question appears to have moved with the redesign of the board for PAL. I also couldn't think of a place to put the reset button, nor was I particularly enthusiastic about drilling a hole in the case to make one, first due to the questionable quality of the plastic itself and second for purposes of historical preservation of an unusual machine.

Happily we have another option, and it doesn't require altering the VZ200 at all: the expansion port itself has both reset and ground lines that go directly to the CPU. Recall from our wire-up of a Gremlin Blasto arcade board (where we had no reset circuit of any kind) that its 8080A CPU could be crudely reset by simply putting a pushbutton switch between its reset pin and ground. As the Z80 can serve as a drop-in upgrade for an 8080, it can be reset in the same way. That means all we have to do is solder a pushbutton switch between the corresponding pins (i.e., pins 1 and 2) in the SD loader cartridge, in this orientation the farthest two from the SD card slot. One caution: don't get this backwards because even though pin 22 appears as N/C in the TRM, it's actually ground - and pin 21 is +5V. However, not only do we have to modify the cartridge's case to make the switch accessible, but we also need to figure out some way of detaching the switch if we want to even open the case. For that, the wires I actually soldered to the pins go to two Dupont female jumpers. I then soldered the pushbutton to two Dupont male jumpers (polarity doesn't matter). After that I drilled a second hole in the side of the cartridge case ... ... and threaded the female jumpers out through it. Last but not least, we connect the male jumpers to them. If we need to get back into the case, we just pull off the button switch and reattach it after. Our complete upgraded system, with cartridge, joysticks and reset button, is ready to go. (Perhaps a reset button feature could be considered for a future revision of the SD loader.) That makes it time for a little tour of the system - which is where another, less tractable problem with this particular unit will emerge shortly.

Meanwhile, let's put some files on the SD card and try them out. The firmware expects them to be in the more or less standard .VZ format, which has a trivial 24-byte header indicating filename, starting address and type (BASIC or binary). The LOAD command will conveniently auto-execute binary files when the load completes. You can find many programs on Dave "Bushy" Maunder's exceptionally comprehensive site containing software, photographs, articles and documentation, and most software he offers can be copied directly to the card and used immediately.

Next page | Previous page | More Lobsters retrocomputing | Headlines

Original: http://oldvcr.blogspot.com/2026/09/a-dick-smith-vz200-without-dick-smith.html