For the preservation of our precious bodily fluids, we must remove the scurrilous larrikin influence of Australia upon our American home computers, and I know exactly where to start! Why allow Dick Smith's name (even though he'd already sold Dick Smith Electronics' controlling interest to Woolies by then but stop ruining my intro) to corrupt this, um, rubber-keyed diminutive beige home computer when we can return it to its prior, pristine, plasticky state as it once rolled out from a glorious Asian factory?

... after, of course, we compare this seppo VTech VZ200 with the Dick Smith units and the bumper crop of crap American home computers in 1983, and fix the keyboard and video. Then, to avoid wrecking it with a botched logic board repair, we'll bolt on a USB serial port using the very latest peripherals from down under, write cycle-counted Z80 assembly language to blast data to it at 57.6kbps, and hack a few games. Because only this will make the VZ200 great again!

Let us also acknowledge that the cultural context of 1980's home computers was naturally somewhat different between the United States and Australia, and I think that's primarily why the NTSC VZ200's fate was rather unlike the DSE rebadge's. There's not a lot of early history on these particular machines, but we'll try to construct a coherent one; similarly, as there are many down-under perspectives on this machine, I'll give an alternative view from the North American side as a kid growing up during that era.

Initially VTech, as it became known, concentrated on video games, primarily as an OEM for the more profitable North American and European markets. Their first products were Pong clones, released in the United Kingdom as the Grandstand Adman T.V. Game 2000 (black and white) and Adman T.V. Game 3000 (colour) in 1977, both based on the Texas Instruments TMS1965N, TI's clone of the well-known General Instrument AY-3-8500 Pong-on-a-chip (compare with the rather more complex MOS 7601). Grandstand was a brand name of Adam Imports, then a substantial toy and games importer to the UK and for a period of time New Zealand, and had other Asian contacts, notably Tomy. If the picture on VTech's history page is to be believed, and I point out there are some verifiable inaccuracies on that page, VTech continued to produce other consoles for Grandstand/Adam like the (deep breath) Grandstand Adman Colour TV Game 3600 Mk III, which used a regular AY-3-8500 and was produced until 1979. For the portable market, VTech produced a number of handheld LED, VFD, LCD games, sold under various brands and through retailers such as Radio Shack.

VTech was hardly the only such Hong Kong tech company, of course; across the Bay in Kwun Tong was EACA, established in 1975 by Guangzhou escapee Eric Chung. EACA also produced consumer products such as radios and its own video games, notably the 1978 Colour TV Game, also based on the TMS1965N and variously sold under other brands such as the Sonesta Hide-Away TV Game.

EACA, among others, noticed all three systems used largely off-the-shelf hardware and discrete TTL logic, and quickly planned for a clone computer to expand their product line. With respect to the TRS-80, the only custom part other than the system ROMs was a Motorola MCM6670 "character generator," effectively another ROM with character bitmap data used by the video circuit. Since it was the market leader, third-party support for the platform was growing and Tandy had little presence outside the United States, Chung decided to start there first.

The Sorcerer arguably found greater success in Europe than it ever did in the United States, particularly in the Netherlands where the licensed Compudata Sorcerer became the default government-supported educational system, and certainly in Australia due to Dick Smith's dogged promotion. Still, even in the US it was considered relatively expensive at $895 [$4580], and with tariff and import costs tacked on it didn't price itself well to the Aussie working class nerd. Conversely, the EACA Video Genie had meanwhile achieved some popularity of its own within Europe, notably West Germany, in no small part due to its lower cost. That alone made it a logical system to transition to, and better still, EACA had absolutely no objection to DSE outright rebadging it as a Dick Smith unit.

At this point it was inevitable someone would poke the Tandy bear, and that someone was Recortec (they're still around), established in Sunnyvale, California in 1969 to specialize in magnetic tape recording technology. In 1980 Recortec, also attempting to expand their product base, opened Personal Micro Computers, Inc. (PMC) as a new venture in Mountain View, initially entering negotiations with Exidy to buy out the Sorcerer — until, through EACA's American subsidiary, they became aware of the Video Genie. To PMC/Recortec, the Genie was a remarkable opportunity, a less expensive TRS-80 compatible system already selling in Europe and entering the Australian market, and PMC now had the chance to corner it for American distribution. The company immediately backed out of the deal with Exidy, bought up Genie distribution rights in August for the entire Western Hemisphere, rebranded it as the PMC-80 and launched it in 1981 with 16K of RAM for $675 [$2330].

In their motion to dismiss, PMC and EACA did not deny that the code had been copied and that then-current copyright law covered computer programs, but argued that section 117 of the in-force 1976 Copyright Act required the infringement claim to be interpreted according to the law prior to January 1, 1978 ("this title does not afford to the owner of copyright in a work any greater or lesser rights with respect to the use of the work in conjunction with automatic systems capable of storing, processing, retrieving, or transferring information, ... than those afforded to works under the law, whether Title 17 or the common law or statutes of a State, in effect on December 31, 1977"). Robert Peckham, chief judge for the Northern District of California, disagreed in August 1981 and denied the motion, writing "that section 117, as it existed in the 1976 act, was aimed at the problem of copyrighted material inputted [sic] into a computer, such as books, magazines, and even computer programs. It was not intended to provide a loophole by which someone could duplicate a computer program fixed on a silicon chip." Moreover, even if it did, "[t]he plaintiff has suggested that the evidence may well show that the chip was duplicated by first taking a visual display or printout of the program in question ... If this method of unauthorized duplication in fact is proved, there can be no doubt that the unauthorized duplication of a visually displayed copy of the program would fall within the reach of the federal copyright laws."

The case was quietly settled out of court, and although it obviously didn't enjoin EACA outside of the United States, domestically PMC replaced the line with the CP/M-based MicroMate in 1983. By then, and unknown to his backers, Eric Chung's failed investments in the Hong Kong real estate market had put him millions of dollars in debt. In October 1983 he abruptly fled to Taiwan reportedly with $10 million stuffed in a suitcase, leaving EACA to quickly fold. Simultaneously, Dick Smith sold a 60% stake in Dick Smith Electronics to Woolworths (the Australian version) later in 1980 and then the rest in 1982, leaving only his name and his bespectacled grin to remain at the company he founded. Although DSE sold the Video Genie's modestly upgraded direct successors also as System 80 variations, the System 80 family never included the Colour Genie, EACA's last system before its ignominious demise. PMC's former headquarters in Mountain View are now collectively Google Building E475.

The success of the ZX80 suggested other dirt-cheap home computers might also flourish. VTech accordingly began developing a low cost computer of their own in 1981 that could work like the TRS-80, planning to adopt its BASIC (and thus its Z80 CPU) much as crosstown rival EACA did and speed time to market, but by explicitly abandoning compatibility they were free to slash its production cost as much as practical. A substantial reduction in part count became possible immediately by using the inexpensive Motorola 6847 Video Display Generator, introduced in 1978, which replaced nearly the entire video system: with minimal support circuitry, the VDG chip could generate a 32x16 text display, comparable to the TRS-80 and Video Genie's 32-column mode for colour TV sets, 64x32 colour semigraphics reminscent of the same, and a variable high-resolution bitmap display depending on available memory. On top of that, the entire system could run from the VDG's standard 315/88 (3.58MHz) crystal, including the Z80, and part count could be reduced even more for a black-and-white low binned model by omitting the colour encoder completely. Everything else (cassette output, keyboard lines) could be supported with discrete components and a handful of TTL logic, price could be adjusted further on the basis of included RAM, edge connectors wired to the processor bus would suffice for peripherals and expansion, and any sort of keyboard would be a step up from a flat membrane.

While the low-end computer was in development, VTech also hedged its bets with a higher-spec video game system, which typical for the era (see, for example, the Intellivision Keyboard Component) was convertible into a home computer of its own. This console was likewise built from off-the-shelf components, using a 2MHz Rockwell 6502 CPU and the Texas Instruments TMS9918A for graphics, 17K of RAM (1K for the 6502's zero page, stack and low memory, and the other 16K for the VDP), and controllers that doubled as a membrane keyboard when used with the optional BASIC cartridge. It shared no parts or significant engineering with the computer prototype and proceeded along a largely separate development track, released to select European test markets first as the VTech CreatiVision in 1982.

Meanwhile, Sinclair Research and manufacturing partner Timex Corporation subsequently joined forces to launch the Timex Sinclair 1000 in the United States, a slightly reconfigured ZX81 with NTSC-compatible video output and 2K of RAM, but otherwise identical. It hit stores in the summer of 1982 at the same psychologically desirable price point, now US$100 [$345], though Timex Sinclair didn't get the bargain American home computer market to itself like the ZX80 mostly did in the UK: it now had to contend with Commodore, selling the VIC-20 as their well-supported low-end system, plus the ailing Atari and their Atari 400, Tandy's own TRS-80 Color Computer, and even Texas Instruments, then only months away from igniting a price war using the TI-99/4A. Nevertheless, industry observers generally believed the T/S 1000 would be a strong competitor, and its debut led to an accelerated scramble from VTech and others hoping to duplicate the ZX80/1's success. VTech identified two overall product positions, a super-low-cost black-and-white variation with Microsoft Level I BASIC for selected markets, and a colour model with full Microsoft Level II BASIC, each of which VTech intended to sell both under its own name and as an OEM. To prepare for the American launch of the nearly complete low-end computer and the CreatiVision, VTech opened a U.S. subsidiary that year in Elk Grove Village, Illinois outside Chicago (the picture above is from VTech's history page).

The latecomers arrived at the Summer CES in Chicago, though by that point the rot was already setting in. Against the background of Commodore slashing prices even lower on the VIC-20 and C64 to Texas Instruments' profound discomfort, Mattel suddenly decided the Aquarius needed a sequel (i.e., the other system Radofin was developing; price point to be determined but without a rubber chiclet keyboard); Timex Sinclair replaced the T/S 2000 with the enhanced T/S 2024 and T/S 2048 with higher resolution graphics, more RAM and a plastic chiclet keyboard, plus an upgraded T/S 1500 which was a T/S 1000 with 16K of RAM and a rubber chiclet keyboard; Rabbit Computer (who? also from Hong Kong) introduced its own Z80-based Rabbit RX83 with 2K of RAM, BASIC, three-channel sound, cassette storage, bitmap graphics and a plastic chiclet keyboard for $99; and Tomy unveiled the Tomy Tutor for "under $150" [$500] with a 2.7MHz TMS9995 (from a 10.7MHz crystal), 16K of RAM, cassette storage, bitmap graphics and a rubber chiclet keyboard. In the fall Tandy, never one to be left out of a race to the bottom, delivered the MC-10 Micro Color Computer for $120 [$400] with an 0.89MHz 6803 and 4K of RAM, cassette storage and bitmap graphics, and a rubber chiclet keyboard. Even Commodore, failing to learn its lesson from the critically maligned Max Machine, was working on their own ultra-low-end family of computers to follow on to the C64 — one of which (the 116) would have a rubber chiclet keyboard.

And, oh yeah, one other system made its debut at the Winter show.

There are certain attributes of the machine shown in both the COMPUTE! and Creative Computing photos that don't match released units, but we'll address this later on.

What these systems all had in common, other than crummy keyboards, a striking preference for the Z80 and an unabashedly low starting price, was aspirational and arguably fraudulent marketing, plus inadequate specifications requiring upgrades at additional cost to be practical — if there were any to begin with — alongside substandard quality control, a poor selection of software, and weak to non-existent customer support. Made cheap to sell cheap, most of these computers failed outright (e.g., the Mattel Aquarius) or were never even released (e.g., the TI 99/2).

The glut that hit the U.S. market that year not only soured many American consumers on home computers generally, but their game-heavy libraries were also likely a contributing factor to the 1983 video game crash. Although managing to move over half a million units, Timex Sinclair was not immune to this effect, and the company became unprofitable as the sales crossfire between Commodore and Texas Instruments forced the T/S 1000's street price below $50 in mid-1983. The situation was compounded by Timex's ill-considered decision to make the more expensive T/S 2068 (the eventual sole member of the 2000 family) largely incompatible with the ZX Spectrum, robbing it of the extensive British Spectrum software library, and the joint enterprise that was once expected to dominate the American home computer market collapsed in early 1984. Even large players like Texas Instruments and Warner Communications-era Atari took hundreds of millions of dollars in losses, with only Tandy (due to their strong retail presence) and Commodore (due to the C64's prodigious installed base and their vertically integrated manufacturing) able to weather the maelstrom effectively.

But by then it was too late. Although VTech never attempted to introduce the black-and-white model in America — and the T/S 1000's plummeting price would have made it impossible to make money on anyhow — the colour VZ200 fared little better, virtually disappearing from North American store shelves by the end of 1983 with no evidence any Laser 200 units were ever sold there under that name. In Family Computing's inaugural September 1983 issue the columnists mention the SV-318 and even the stillborne T/S 1500, but nothing on the Lasers, and Creative Computing around that time was only running ads for the 3000. A few VZ200s were rebadged by Texas door-to-door nuisance business Dynasty Computer Corporation as the Smart Alec Jr., though like their multi-level marketing attempt at rebadging the spent Exidy Sorcerer, they sold barely at all (the company folded in November). On the other hand, the (now) Laser 200 got off the ground in Europe under its own name and others, most notably through Sanyo, but also through Salora, Seltron and Texet. It launched there alongside the black-and-white model as an ultra-low-end system, originally dubbed the Laser 100, but after the ROM change becoming the Laser 110 with the same Level II BASIC of the colour version.

However, there was one market where the VZ200 had particularly strong success, and that was of course Australia, though not exactly in its original form. History does not preserve the thought process of Dick Smith Electronics management, but DSE's probable aim was to nose past the Commodore VIC-20 on price and capability (DSE themselves even sold them for a time), which was colour and shipped with 5K RAM. That immediately excluded the black-and-white variation, since the ZX81 had since landed in Australia and the potential profit margin wasn't enough to bother, and it is instead more likely that during negotiations DSE prevailed upon VTech to strengthen the colour system and keep the price low. VTech's solution was a small 6K daughterboard retrofit that could replace the 2K system RAM chip, internally expanding the unit to a more appealing 8K (the other 2K video RAM chip was left unmolested) while still being able to use previously manufactured components. This modified VZ200, badged as a Dick Smith computer and subsequently sold elsewhere by VTech as the Laser 210, appeared in the 1983-84 catalogue as "new for 1983" at just A$199 [approximately US$220 spot and US$720 in 2026 dollars].

I think that suffices for a more detailed backstory; we'll talk a little more about its later history in Australia and VTech's overall as a postscript at the end. For now, we'll turn our attention to this orphaned American unit. A convention I'll establish from now on in this and future articles: although Dick Smith was not consistent on the hyphenation, variously rendering it VZ-200 and VZ200, in the few places it appears the American version was invariably written without one, so I'll write "VZ200" for the North American computer and "VZ-200" for the Australian computer.

The box advertises 9 colo(u)rs, 16K "bytes" of ROM — more than the 12K of the CES units — Microsoft* BASIC, though the asterisk only indicates it's a trademark, "full on-screen editing" and "advanced graphic & sound features." A red flourish at the bottom prominently touts its "4K BYTES" of RAM.

Although the eBay seller was also American, I've concluded that these were likely products produced for the United States but ultimately sold in Canada, possibly as remaindered stock. For readers outside of North America, Canada used the same NTSC video standard and 110 VAC outlets, so it would have "just worked." Also, the 1983 Canadian dollar exchange rate was roughly about C$1.23 per US$1, explaining at least the initial price, and while the lack of markedly predominant French labeling might have prevented its sale in the Montréal outlet, that wouldn't have enjoined it elsewhere. As far as its provenance, however, the fact it wasn't labeled that way suggests Canadian sale was not initially contemplated, and it also has U.S. Federal Communications Commission clearance (I'll show you in a bit).

Compare the label and the keyboard to the previous COMPUTE! and Creative Computing pictures. Those earliest systems are labeled as a "VZ200 Personal Computer," not a "VZ200 Color Computer," and the colour labels over the number keys were absent. In fact, this same keyboard is used for the B&W Laser 110, though those early VZ200 systems must have been colour given that their colour capabilities were widely reported at the time. On the other hand, the VZ-200 that appeared in very early Dick Smith marketing like the flyer above was labeled a "VZ200 Color Computer" exactly like this one, including the American spelling.

The keyboard consists of 45 keys, with a bottom right SPACE key in the corner, only one SHIFT on the bottom left, and no ESCape key. Necessarily, many have multiple functions accessible with the CTRL key or CTRL-ENTER key combo. Most of these alternative functions are one-touch BASIC keywords like the Sinclair machines, though unlike those computers, you are not obligated to use them and can spell keywords out if you want. Semigraphics characters are also selected by key combination, as well as moving the cursor, inserting and deleting characters, and interrupting a BASIC program.

I was immediately suspicious of the wallwart and bought a regulated 9VDC 2A switched wallwart to replace it (the machine will run fine at this voltage). The user manual proper is very sparse, mostly just how to hook the computer up. The BASIC "reference manual" picks up from there, less an encyclopaedic reference text than an in-depth tutorial.

Notice the peripheral slot still has its cover on it, secured by two small screws, which ordinarily would have been removed before use. This is where the joysticks and printer interface (again, I have found no evidence it was ever sold States-side) would have connected, and we'll see why it was never used shortly. There should be a cover for the expansion slot also, but it was removed, because the 16K RAM expander connects there. The cover is not in the box and I'll presume it was lost or destroyed by the previous owner. That's annoying from a preservation perspective, but no great loss functionally, because we'll have something plugged in there pretty much all the time later on.

Although the serial number indicates his is a rather older unit, which we'll in fact confirm later, the label and keyboard are the same as mine and not those earliest CES models. Both units have FCC Part 15 clearance, specifically as a Class B computing device for home use; at the time Class B regulations were very strict and we'll see a consequence of that inside. The FCC ID is BNX84H80-0323, with an equipment authorization (EA) applied for February 10, 1983 and granted May 9, 1983. Accounting for publishing delays, this means Creative Computing must have had a pre-authorization prototype for their review. VTech later applied for a revised equipment authorization on July 11, 1983 and was granted BNX84H80-0323-1 on October 11, 1983; this change may have been for redesignation as the Laser 200. The listed address for VTech in Hong Kong appears on all entries for FCC grantee BNX and doesn't seem to have been their corporate address at the time, but the tester in both EAs is one Thomas Cokenias from Electro Service Corp., at 1116 Ninth Avenue in San Mateo, California, and Cokenias and Electro Service are seen in other EAs around that time for other Hong Kong manufacturers. However, the given address appears presently unoccupied, and the California Secretary of State indicates Electro Service is no longer in business.

The VZ-300/Laser 310 is otherwise nearly totally compatible with the VZ-200/Laser 210 except for its clock speed. As NTSC compatibility was no longer required, VTech switched to a single 17.734475MHz master crystal divided by four for the 4.43361875MHz PAL colourburst and five for the 3.546895MHz CPU clock. (The Motorola 6847 VDG in the VZ-300 and PAL systems generally is clocked with an altered signal which I'll talk about when we open the machines up.) Although that makes the VZ-300 slightly slower at 99.09% the speed of the VZ-200's 3.5795454MHz (315/88) oscillator, in practical terms the difference was imperceptible with most existing software — but of course it's going to be a problem for us later. VTech did no other upgrades, not even offering an alternate 6847 font ROM with lowercase, though we'll talk more about that when we get to the innards as well.

On the other hand, one manual unique to the VZ-200 was the Technical Reference Manual (TRM), which Rowe, by then highly placed in the Dick Smith organisation, wrote himself from VTech internal documents. This slim A4 book was never sold in America, and was a Christmas gift from my wife (I married well). The DSE pricetag on the back gives its price as A$9.50 but I don't know where or when it was originally purchased. While the TRM does not approach the sheer detail of, say, the Commodore 64 Programmer's Reference Guide, which even has an exhaustive memory map covering its 64K of RAM and 20K of ROM, it does include documentation on most of its important RAM locations and a full set of schematics, some of which we'll be using in this very article. A similar manual exists for the VZ-300 with its own set of schematics, which also discusses the VZ-200 and has some details not in the earlier text.

A single teal sticker on the VZ-300 says "PAL-V 18K." This likely means VHF because the DSE VZ-300 sends its TV signal on Australian channel 1 (57.25MHz), and the VZ-300 schematics show separate circuits for PAL-V and PAL-U, which accordingly would be UHF.

Early Laser 100 computers came with 8K of ROM containing TRS-80 Level I BASIC, while the prototype VZ200 units shown at CES had an larger 12K ROM set apparently using upgraded TRS-80 Level II BASIC. Subsequent Laser 200/300-derived systems and the Laser 110 have 16K of ROM and TRS-80 Level II BASIC as well, which was deliberately obscured in later revisions of the ROM. Level I BASIC is quite, uh, basic, evolved by TRS-80 designer Steve Leininger from Li-Chen Wang's "copyleft" Palo Alto Tiny BASIC which Leininger substantially altered, reworking its structure and adding floating point math (because it couldn't accept Charles Tandy's salary when he typed it in), two string variables and a single array, and support for the TRS-80 hardware. VTech's version is similarly modified to support its own architecture but is otherwise the same. Level II BASIC is Microsoft BASIC, derived from Microsoft's own Extended BASIC on the Altair, and again VTech initially imported it nearly unchanged except for adding support for their hardware and graphics, which replaced some of the keywords (like TROFF with COLOR). Proof can be seen by comparing the order of keywords in their token tables, which would have no reason to match as precisely as they do unless they came from the same origin. Another persistent relic in the VZ BASIC ROM is the old Microsoft two-character error message table (e.g., ?SN ERROR instead of ?SYNTAX ERROR) even though the existing code never references it.

Tandy's apparently successful legal action against EACA and PMC spooked VTech that they could be sued in the same way — but by Tandy and Microsoft. The company's solution was to dump Level I BASIC entirely, eliminating any objection from Tandy, and for Level II BASIC to secretly null out a large number of entries in the ROM BASIC keyword table potentially unusual enough to be used as evidence of copying. The tokens for those keywords still remained valid, however, and the ROM code for them also largely persisted. Disk-specific keywords were likewise omitted in the same fashion, at least until the VZ-300 disk drive debuted, but unlike the other gutted keywords were instead vectored through RAM for later expansion. These keywords (in token order) are CMD, RANDOM, DEFINT, DEFSNG, DEFDBL, RESUME, ON, OPEN, FIELD, GET, PUT, CLOSE, LOAD, NAME, KILL, LSET, RSET, SAVE, SYSTEM, DEF, DELETE, AUTO, FN, VARPTR, ERL, ERR, STRING$, INSTR, TIME$, MEM, FRE, POS, CVI, CVS, CVD, EOF, LOC, LOF, MKI$, MKS$, MKD$, CINT, CSNG, CDBL and FIX. Because their implementations often remained present, it was possible to resurrect many of them by hooking into the RAM vector for tokenizing "new" BASIC keywords, and some BASIC extensions did just that.

The earliest versions of the Laser/VZ ROM use light green text on a dark green background. Without a colour encoder this would produce light text on a dark screen, which is indeed what you see on a black-and-white Laser 110. Bill's earlier NTSC VZ200 is the same way, using the same ROM 1.2. By ROM 2.0, as in this VZ-200, the display became dark green text on a light green background, like the Tandy Color Computer which uses the same MC6847 video chip.

On startup the ROM tests available memory and stores that final valid RAM address to the systemwide TOM pointer at 30897-8. On a 4K system we would only have 2K of general RAM available, so the TOM pointer should be at $7800 + $07ff, yielding $7fff or 32767. That is indeed the value of the TOM pointer, so we do have a 4K system, just a very late one.

You may have noticed the oddly convoluted BASIC statement I entered to get that figure. That's because I had to avoid typing the number 5: the key didn't work. Normally the VZ200 will beep as you press keys, but there was no beep and no response when I did. In fact, an entire run of keys (5, T, G, B and N) was not working, and I was only able to enter the PRINT keyword by pressing SHIFT-P. We'll need to fix the keyboard now to do anything substantial with this machine.

My initial theory was that the column connected to R8 and U12 pin 8 was bad, which involves our 5, T, G, B and N keys as predicted. However, this column also involves the 6, Y and H keys, which did appear to work. Still, it seemed like the most reasonable place to start, so let's crack the computer open.

Much of the logic board is covered by a large sheet metal Faraday cage serving as an RF shield, festooned with soldered metal braids connecting everything to the ground plane, and then the whole assembly placed on an irregularly shaped metal plate on the bottom with the piezo. As mentioned, in those days the FCC was very strict about radio interference from computers and video games, particularly home units where a Class B device (as this is) had a 10dB lower maximum than a commercial Class A one. Some systems like the Atari 400 solved this problem by effectively encasing the entire system in a molded metal endoskeleton and placing as few holes in the case as possible from which radio signals could emanate. That made for a very sturdy computer but one more expensive to manufacture, so VTech went for this cheaper, hackier approach which was no doubt iterated upon until it just cleared the bar.

One major component is not under the cage, however, and that is the Motorola 6847 VDG video chip, in a plastic carrier (MC6847P) with a date code of 24th week 1983. It's not precisely clear why that is, but it can be seen that the left board is connected to some of its lines.

The TBA520 can be made to do the same task, even generating NTSC colour with the right crystal, albeit with more supporting electronics. (I presume it was less expensive than an MC1372, plus there would be the advantage of not having a different chip for Euro and Aussie systems, since the TBA520 can obviously do PAL video too.) Reference B-Y and R-Y signals are generated to the TBA520 using the 3.58MHz (315/88) NTSC colourburst oscillator on the left board, while the B-Y and R-Y signals from the MC6847 are passed on different lines, with the MC6847 running on the same 3.58MHz clock. We then pulse the TBA520's line inputs at the necessary horizontal rate, approximately 15.7343kHz, causing the TBA520 to emit a single NTSC chroma signal (on its G-Y pin) from the 6847's PbPr signals. (This theoretically makes it possible to get proper S-video out of the VZ200, though we're not going to try that this time.) Discrete components then combine the luma and chroma into composite video for both the monitor connector and for feeding into the separate RF modulator.

In this view, the MC6847 is the large DIP on the far left/west side. The chips in the back, going from left to right, are a Hitachi HM6116P-2 2K static RAM used for video memory, the CPU, a clone SGS Z80 (the former state-owned SGS Microelettronica "Società Generale Semiconduttori" of Italy prior to merger into STMicroelectronics in 1987) with a date code of 19th week 1983, a Hitachi 74LS139 and 74LS32 used as part of the address decoding for the memory mapped I/O range, and lurking in the back right (east) corner a 74LS174 6-bit flip-flop serving as a latch register. In the front, also left to right, are a Hitachi 74LS245 octal bus transceiver which bridges the shared 2K video RAM between the CPU and VDG, a Hitachi 74LS04 hex inverter used for various tasks such as the CPU reset circuit, a Hitachi 74LS244 octal driver, another Hitachi 6116 2K SRAM (the system RAM this time), and the two 2364 8K system and BASIC ROMs with date codes of 27th week and 32nd week 1983 respectively. On the Dick Smith schematic using the same order, these chips are numbered U15 (the 6847), then U7, U4, U3, U2 and U1 (74LS174), then U14 (74LS245), U13, U12 (assumed), no designation for the single 2K SRAM, and U10 and U9 for the ROMs. The ROMs are unsurprisingly the newest chips in the system and mean the computer could not have been assembled earlier than then, likely making it part of the last production runs before VTech abandoned the line in North America.

Obnoxiously, everything is soldered down; there are no sockets (cheap!). However, there are a number of unpopulated pads. Some extra pads near the ROMs were clearly intended to accommodate larger-capacity chips, and later machines indeed use a single 16K ROM with a change in board jumpers nearby. (Braver folks than I have extracted VZ-200 boards with 2364s and found bodge wires underneath. Apparently underpaid labour and smaller ROMs were less expensive at the time. Cheap!) There is also another set of pads near the VRAM chip between it and a big block of through-hole resistors. It's not clear what these pads were meant for, though the VZ-200 schematics show another resistor bank there serving as pull-ups. This bank is drawn on the schematic with dotted lines unlike the other set, so perhaps they were eliminated for cost reasons (cheap!).

Now let's talk about what we don't see. One thing we don't see here is a 3.58MHz master crystal. That's because ... we already saw it. The entire system runs from the 3.58MHz crystal on the colour encoder, so everything is precisely synchronized to the same clock source, including the TBA520, the MC6847 and the Z80. It is therefore impossible to merely switch the colour encoder boards and turn an NTSC VZ200 into a PAL VZ-200 or vice versa because of the added line padding circuit in the PAL unit and the absence of a second system crystal in the NTSC unit (cheap!). What about the VZ-300, where there's no 3.58MHz crystal either? In that system, the VDG is entirely clocked by one of the gate array chips, providing the same line padding logic, but also using the same 3.54MHz clock as the CPU which is apparently "close enough."

Another thing we don't see is something like a Motorola 6883 synchronous address multiplexer. Recall that the 6847 VDG has no externally exposed registers of its own (compare to, say, the VIC-II in a Commodore 64). Things like video modes and character attributes are twiddled by chip lines; for character attributes these lines are often wired to certain data bits from the video RAM, but to dynamically set a video mode under software control requires external hardware. Also, the VDG makes little attempt to cooperate with the CPU as to when it accesses video memory, other than indicating when it finishes a frame which is likewise asserted on one of its pins. In the Tandy Color Computers (prior to the CoCo 3, which uses a GIME), the MC6883 SAM sits between the 6809 CPU and the 6847 VDG and arbitrates all of this, managing the display mode and system timing, and servicing the VDG while the CPU is on the bus. On the other hand, this approach was judged too expensive for the cut-down Tandy MC-10, which instead uses a series of flip-flops to interleave bus access between its 6803 CPU and the 6847. A single 74LS245 bus transceiver allows the CPU unrestricted access to the video RAM when the processor is accessing memory.

Neither approach is suitable in this case, however. An MC6883 would be too expensive for the VZ200 also (cheap!), and the Z80 sits on the bus longer during a CPU cycle than a 6502 or 6800-family chip would, so the MC-10's interleaved approach won't work either. As it happens, the VZ200 does nearly exactly what the Scriptovision Super Micro Script does: during CPU video RAM access, the VDG's memory fetch is immediately suppressed using its MS pin and the 74LS245 bus transceiver temporarily kicks it off the bus. The contention problem is solved in both cases with software (cheap!) by simply not doing anything with VRAM until the VDG indicates it's between frames and not reading screen memory. The only difference is how they find that out; the SMS busy-waits on the VDG's FS signal before doing a screen update, while the VZ200 just wires FS to its IRQ line — screen updates using ROM routines are batched and when the interrupt is triggered, the ROM then blits the deferred changes to the screen all at once. Of course, if you write directly to the video RAM when the VDG is accessing it you'll get intermittent artifacts, and I'll show you what that looks like, but you can just watch for the IRQ yourself if you really care about it (many programs didn't). Otherwise, the VDG's mode pins for bitmapped graphics and alternate colour selection are handled through bits in the 74LS174 latch within the memory-mapped range, which also handles the piezo and cassette output. Overall this is a good demonstration of how the SMS was almost a home computer, because here's a home computer whose video architecture was almost the same.

A missed opportunity with the more upmarket VZ-300 was the potential for lowercase or at least an alternative character set, especially because it even got a word processing cartridge released for it later (we'll play with it, it works with the VZ-200 also). An external font ROM can be lashed to the 6847 with a bit of additional circuitry and the Super Micro Script has one to generate higher-quality character glyphs. It seems like VTech could have done something like that controllable by another latch bit, and with a six-bit latch there are a couple more data bits there that could be used, but I guess that was either judged too risky or not even thought about. On both systems the 6847 INT/EXT pin that would have controlled this is merely hardwired to ground.

One note about the metal RF shield: if the cage is not pulled back down into position, it may distort and contact some of the pins on the 74LS174. This will cause weird graphical artifacts and knock out the piezo (no keybeep). It doesn't appear to harm the computer, but I was very careful to ensure it was bent back to as similar a position as before after this happened a couple times. Obviously this is no problem if you just completely take it off.

I'm not sure how such a fault would have happened. The keys move, but they don't sweep or scour, and ordinarily they shouldn't be contacting the painted portions anyway. It also doesn't seem likely to have been a factory defect because that would have made the computer very difficult to use, and this computer was clearly used.

I pondered the best way to fix it, since any repair would have to be flat or it would distort the key sheet on top (e.g., no solder blobs, no top bodge wires). I have a circuit pen I could use to draw a new trace, but it's temperamental, and I didn't want to do something I couldn't undo later in case it wasn't actually the problem.

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.

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.

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.

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

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.

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.

A better measure of the hardware might be Five Finger Punch's 2018AD. There's not much of a VZ200 demoscene, but there are a few out there, and this exceptional demo is unquestionably one of the best. It will not run correctly on this particular computer because the video timing is different — not because the clock speed is faster, like you'd see between an NTSC Commodore 64 which is faster than a PAL Commodore 64, but because the NTSC VDG draws the screen faster and thus fires the end-of-frame interrupt more often, messing up synchronization. For that, you'll just have to watch this YouTube recording on actual PAL hardware.

It's set up like a trackmo, streaming cassette program data from one channel of a specially recorded CD audio track and using the other channel for music (admittedly a bit of a cheat but the music is excellent). If you didn't think rotozooms, raster splits and even FLD-type effects were possible on the 6847 VDG, then you're in for a treat. Another neat trick is the doubled vertical resolution while drawing the Kefrens bars. The source code is even available for your education.

Note the "snow" in this shot — that's because the program was animating screen memory at the same time the VDG was trying to read it, so the VDG's memory access got briefly suppressed during that period. Because the display scan can't wait for the VDG to be enabled again, the result is a brief splat of garbage on that line until the VDG is allowed to proceed. Dubois could have simply waited for the VDG's next interframe interrupt, but there's also only so much time between frames before the VDG will start drawing again. As a result, for many programs where significant CPU time was required to do screen updates, outright ignoring the video artifacts turned out to be the least bad approach.

Here's a short video I recorded of another high quality arcade clone, Galaxon (gee, I wonder what that was) by Stephen Clarke. It shows loading from the SD card, the title and options screen (even the VZ200 had software pirates), and then playing the game, which worked fine on the keyboard. This and the other recordings I did for this entry were generated from the composite capture rig for video, but for audio using a microphone near the VZ200's piezo speaker to capture sound (since there's no audio out). You'll notice I'm pounding on the keys a bit, which the microphone faithfully picks up, though you do have to hit the keys with a bit of, shall we say, deliberateness to get them to register.

An exceptional entry in the VZ's edutainment canon is Factory by VSoftwareZ. It oozes professional quality with a slick title screen and menu, and is an extremely fun puzzler to boot. The aim is to create a factory from various primitive machines (paint, rotate, hole punch) that will generate a specific product. It is so well animated and so thoroughly polished that it deserves this short video to fully appreciate it.

... alongside a rather good 3-D maze game by Laserlink. It's only rendered at 90 degree angles, but it's fast and well-written, and deserved another video.

As it happens, the very problem was there all along in some of the previous screenshots and videos. Can you see it? Here, let me clear the hi-res screen for you:

First let's understand why this was a problem for some games and not others. I am a 6502 dweeb of long standing and — hi Martin! — it is therefore excruciatingly painful for me to say anything at all nice about the Z80 (even though there's one in my beloved Commodore 128DCR), but one unquestionable strength is its block transfer instructions. As any schoolchild will tell you, six of the Z80's registers, B, C, D, E, H and L, can be turned into 16-bit counters BC, DE and HL which likewise can indicate addresses. The Z80 has an instruction LDI that copies the contents of the address referenced by HL to the contents of the address referenced by DE; the instructions LDIR and LDDR expand upon it, running LDI repeatedly and decrementing the count in BC each time until it reaches zero, respectively incrementing or decrementing HL/DE on every step.

The most obvious application for these instructions is copying a block of memory elsewhere, but a less obvious application is using them to fill memory. Consider this segment of actual code from Invaders (dumped with z80dismblr):

; Subroutine: Size=36, CC=1.
; Called by: LBL1[8254h], LBL4[8F3Bh].
; Calls: -
8C9E SUB40:
8C9E              ld   hl,7000h         ; 28672
8CA1              ld   (DATA47),hl      ; 8DCEh
8CA4              ld   de,7001h         ; 28673
8CA7              ld   bc,081Fh         ; 2079
8CAA              ld   (hl),00h         ; 0
8CAC              ldir        

Ignoring the instruction at $8ca1, you can see that this is setting the source to $7000 — i.e., the start of VRAM — and the destination to $7001 (?!), for a total of $0820 bytes (the zero test is post-decrement). Now, what would that accomplish? Just before the LDIR, we set the contents of $7000 (in HL) to zero. Let's step through the process LDIR takes manually. $7000 is first copied to $7001, which is now zero as well. HL is incremented to $7001, DE to $7002, BC decremented to $081e. Next, $7001 is copied to $7002, but $7001 had zero in it because it was copied from $7000, so all three locations are now zero. HL is incremented to $7002, DE to $7003, BC decremented to $081d. Then, $7002 is copied to $7003, so now all four locations are zero, and so on, filling all intervening locations with the immediate value before. At the end, when BC finally gets to zero, all locations from $7000 to $781f inclusive (i.e., the entirety of video memory and a little past it in system RAM) will have been zeroed out.

This is how Invaders clears the hi-res screen and it is indeed faster than a naïve loop, especially for large tracts of memory. But our obnoxious little plastic beast here throws in a wrench by having a location where the RAM isn't working properly. When the "copy" gets to that point, because the copy is only between adjacent memory locations, for every subsequent location the stuck bit will be propagated forward and faithfully copied to each and every byte afterwards. That's also why the pattern doesn't cover the whole screen, because the problem doesn't actually manifest until the "copy" operation arrives there. In fact, in the process Invaders was unwittingly corrupting some of its own game variables with the same stuck bit when they should have been zero, possibly another reason why it wouldn't run correctly.

The direct and most definitive solution would be to "simply" replace the VRAM chip, and I even have 6116 SRAMs in stock, but I warned you this is a very cheaply made PCB. Far better repairpersons than I have tried and failed to replace chips on these computers without requiring a lot of rework and bodges, and the prior portions of this article should have already convinced you it's only by the grace of God I haven't soldered my own fool face to the workbench yet. I did not want to try replacing that SRAM chip solely because of one stinking bad bit; I was only likely to make a bigger mess or render the computer completely inoperable.

But again: we have an alternative. This fill trick was not universally used or even known by all programmers at the time. The games that do work clear the screen with a simple loop that doesn't propagate the bad bit forward, which works because the store doesn't depend on what memory contents are already "there." Likewise, VTech doesn't seem to use it in the ROMs, which is why the problem didn't manifest during the demonstration tape or with BASIC programs drawing to the screen with BASIC keywords. Most VZ programs are small enough and this code idiom distinctive enough (and usually only present once) that such code can be found and patched to use a slightly slower but functional loop. As such a loop would generally require more bytes, the patch could either direct execution to a tacked-on routine to do the clear, or we could patch it to point to a standard routine in memory.

And how are we going to get a standard, always-present, stock routine into memory to do that? Easy: we're going to soft-alter the BennVenn SD loader's firmware. No, stop laughing, because we have a simple means to accomplish it. At the same time we'll combine that with a serial port loader so that we can test these programs live without having to constantly swap the SD card to and from the Talos II, so we'll also build it a bitbanged serial port (I said stop laughing). There were homebrew serial devices back in the day for these computers, so consider this one merely another entry from a venerable tradition.

        org 07fe8h              ; $8000 - $18
        ; emit .vz header (24 bytes)

        db 056h,05ah,046h,031h  ; "VZF1"
        db "HELLO\0\0\0\0\0\0\0\0\0\0\0\0" ; filename null terminated
        db 0f1h
        dw entry

entry   ; now at 8000h

        ld hl,msg
        call 028a7h
        ret

msg     db "HELLO WORLD", 13, 0

The 24-byte header marks this as a machine language program that starts at $8000, the beginning of the extra memory furnished by the BennVenn device. Although the magic number VZF0 (for BASIC programs, which always start at $7ae9) or VZF1 would appear to be critical, the firmware doesn't seem to check it on loading or even generate it on saving, only that the byte just before the starting address word (everything is Z80 little-endian) is either $f0 or $f1. Upon execution our program then calls a "display null-terminated string" routine in the VZ ROM, the update for which is pushed to the screen during the next VDG interframe period, and returns to BASIC. The binary is assembled with AS like so, using a simple Makefile:

% make hello.vz
asl -cpu z80 -t 2 -L hello.a80
Assembling hello.a80
PASS 1
hello.a80(17)
PASS 2
hello.a80(17)

0.00 seconds assembly time

     17 lines source file
      2 passes
      0 errors
      0 warnings
p2bin hello.p hello.vz
Deduced address range: 0x00007FE8-0x00008013
hello.p==>>hello.vz  (44 Bytes)
% xd hello.vz
00000000  56 5a 46 31 48 45 4c 4c  4f 00 00 00 00 00 00 00  |VZF1HELLO.......|
00000010  00 00 00 00 00 f1 00 80  21 07 80 cd a7 28 c9 48  |........!....(.H|
00000020  45 4c 4c 4f 20 57 4f 52  4c 44 0d 00              |ELLO WORLD..|
0000002c

We then copy it to the card, where LOAD"HELLO" will load and immediately execute it from the given entry address (which is both the load and execute address), as shown in the screenshot above.

As an example, in the Github repo I have a small program to cycle the LEDs on his proto board, which you can see in this brief video. It sets all GPIO pins to output and lights all 24 green LEDs connected to them (the red ones are check LEDs for 3.3V, 5V and 9V), then cycles a dark one through them from left to right until a key is pressed. This is done by hooking into the interrupt routine called when the VDG completes a frame, the only regular timesource on an unaltered VZ200, and used back in the day as a simple clock by various programs. Every third tick of the interrupt routine, this code runs:

        push ix
        and a           ; clear carry flag
        ld ix,scrby
        rl (ix)
        rl (ix+1)
        rl (ix+2)
        pop ix
        ld a,(scrby)
        ; put top bit back into low bit, if set
        jr nc, ledsout
        or 1
        ld (scrby),a
ledsout out (71),a
        ld a,(scrby+1)
        out (72),a
        ld a,(scrby+2)
        out (73),a

It rotates an in-memory image of the GPIO pin values, then emits that to the I/O locations. Because the rotation is to the left, we can see that the GPIO lines must also be oriented little-endian, i.e., the least significant bit of each GPIO output register is on the left.

This then informs how we'll set up our bitbanger. A half-duplex system will suffice for downloading, since the sender will wait for us to indicate receipt between packets, and that will let us concentrate entirely on receiving until a full packet is obtained. The absolutely fastest speed we can receive at is generally limited by how quickly we can clock data bits into an accumulator from the receive line. If we connect the receive line to the least-significant input of one of the GPIO registers (we'll use the leftmost for convenience), we can do it in 23 cycles:

getabit MACRO
        in b,(71)       ; 11 cycles
        rr b            ; 8 cycles (rotate b bit 1 into carry)
        rra             ; 4 cycles (rotate carry into a little-endian)
                        ; = 23 cycles
        endm

The Z80's clock speed (in any of these systems) does not neatly divide into any standard bitrate, but theoretically 23 cycles per bit gives us a maximum possible transfer speed of ((315 000 000/88)/23) =~ 155632.4 bits per second. That suggests you might be able to get 115200bps with an unrolled loop, but at speeds this fast time required for other tasks starts to be a concern, such as storing to memory, checking how many bytes have been received, and branching back to get another, all of which together will certainly be more than 23 cycles.

The other problem is the time required to sense the start bit, because this can occur at any moment, and hardware UARTs generally end up repeatedly snooping the line at some multiple of the bitrate to ensure they won't miss one. We, on the other hand, can't even check for a start bit at just twice 115200bps. In fact, the fastest we can check for a start bit (a zero) is

startbt in a,(71)       ; 11 cycles
        rra             ; 4 cycles
        jp c,startbt    ; 10 cycles taken or not
                        ; = 25 cycles

which because of the unavoidable branch is actually longer than the time to clock in a data bit!

However, these numbers do suggest that half that speed, i.e., 57600bps, is plausible. Flipping the equation around, that gives us a relatively generous ((315 000 000/88)/57600) =~ 62.1 cycles per bit, long enough to do our housekeeping tasks on each byte, and our tight startbit loop can poll the line at ((315 000 000/88)/25) =~ 143181.8 bits per second (a familiar number to some of you), which is at least twice the data rate and should be sufficient for the sort of continuous data transfer we'd experience receiving a data packet. We will target this speed. (Note from the future: an early draft used in a,(c) in the startbit loop, which is a 12-cycle instruction. This single extra cycle reduced the startbit poll rate to 137674.8bps, and at that speed multiple bytes got missed and/or corrupted. We are probably only just fast enough to make this work.)

Parenthetically, VZ-300 owners in the audience will now have asked if this will work for them. If we substitute its lower clock speed at 57600bps, we get ((17734475/5)/57600) =~ 61.5 cycles per data bit and a maximum startbit poll rate of ((17734475/5)/25) == 141875.8 bits per second exactly. Because you can sample a little bit faster but never slower, we would need a separate version for the VZ-300; the same code will not work reliably on both. Sorry! That will be the subject of a future article.

Note that by making receive fast, we made transmit slower: unless we occupy the least-significant bit of another GPIO register, which seems rather wasteful, the next fastest position is the second-to-least significant bit. This snippet needs no less than 31 cycles to send the next bit of a character stored in a register other than the accumulator (here we'll use B):

putbit  MACRO
        xor a           ; clear accumulator and flags (4 cycles)
        rr b            ; rotate low bit into carry (8)
        rla             ; rotate carry into low bit (4)
        rla             ; rotate up one more bit (carry must be zero) (4)
        out (71),a      ; 11 cycles
                        ; = 31 cycles
        endm

If we had to completely guard that GPIO register from interfering with any other GPIO pins on the same register, it would be even longer because we would need to read the current state and then do the bitmasks. Mercifully we'll just refuse to support that, and as 31 cycles is still well within our 62 cycle maximum per bit, she'll be right.

If you don't have his board, you can still figure it out a little less conveniently with a voltmeter. Ensure all pins are set to output and turned off (something like FORI=68TO73:OUTI,0:NEXT will do from BASIC). The only live lines at that point should be ground, 3.3V, 5V and 9V. Find ground first, which you might do by checking for continuity with the ground test point Ben provides on the board, then use that as your common to find the voltage pins. Mark those; the rest are GPIO. Turn on pins one and two individually (OUT 71,1 or OUT 71,2) and look for voltage.

Since we will be drawing power from the connected host and not the BennVenn, don't connect the 3.3V line. Instead, for the programs below, ensure the HW-597 is already plugged into your host (such as with a USB extension cable) and showing bright status LEDs before powering on the VZ-200, or it may try to unsuccessfully power itself from the other lines and get a little daft.

This program runs at a sedate 300bps, and the reason is because the VZ ROMs are written for space efficiency, not time efficiency, at least to any extent they're efficient at all. 300 baud gives us an apparent surfeit of cycles using our formula — 11931 cycles per bit — but we may well need all of them since we've really got no idea how long it can take the ROM routines to do any arbitrary screen update. We won't be using the ROM much for our data blaster program, but a general purpose terminal emulator would have to consider a proper solution to achieve faster speeds. This is something else we might revisit in a future article.

The other purpose of this ASCII test program is to mock up how we'll write the fast serial loader. Despite the fact we have over 10,000 cycles between bits at 300bps and could easily have written each bit we read as a subroutine call to save memory, I still inlined each clocked-in bit using a macro because we necessarily need to at 57.6kbps — among other things, each CALL is 17 cycles and the RET to return from it is 10, which would consume almost half our CPU budget by themselves. I'd also like to observe, again with my usual biases showing, that cycle counting isn't nearly as much fun on the Z80 as it is on the 6502. Most opcode tables will fortunately collapse the whole Z80 T-state and M-state business into a single unified cycle count, but unlike the 6502 where there are instructions with execution times of 2, 3, 4, 5, 6 or 7 cycles (so you can easily make a busywait from any combination), the Z80's cycle time options start at 4 and go as high as 23, skipping many numbers, and many of the smaller cycle times require specific conditions like not taking a branch. Having considered our little half-terminal program, here's what I settled on for 57.6kbps, written as AS macros:

getabit MACRO
        in b,(c)        ; 12 cycles
        rr b            ; 8 cycles (rotate b bit 1 into carry)
        rra             ; 4 cycles (rotate carry into a little-endian)
                        ; = 24 cycles
        endm

topwait MACRO
        ld (ix+0),b     ; 19 cycles
        endm

botwait MACRO
        topwait
        endm

getbit  MACRO
        topwait
        getabit
        botwait
        ; 19 + 24 + 19 = 62
        endm

From our previous maximal case I turned the in b,NN instruction into a slightly slower in b,(c), which burns an additional cycle, but means we have 38 cycles left over of our 62 which we can split exactly between two ld (ix+N),b instructions of 19 cycles each. (This also lets us possibly alternate between multiple connected serial devices by changing C, but one catastrophe at a time, I always say.) The separate top and bottom waits are for situations where we have an odd number of cycles left over and need to have different wait times; consider this future expansion for the VZ-300.

When the stop bit arrives, we need to dump the byte into a buffer and get ready for the next one in the same 62 cycles, since we expect the other end will be ready to fire the next start bit at us immediately. To make an interesting and vaguely useful display (as well as not requiring additional memory), the screen itself would seem like a good place, but this also imposes some constraints: we only have 512 bytes there (i.e., 32x16), some of which we also need for indicating status, meaning our received packets should really be no larger than 256 or 384 bytes to allow for a transmission log and other useful info. The protocol we select should have packets no larger than that, be easy to implement (because I'm lazy), and be something that pretty much everything can speak. While we've seen Xmodem-1K or Xmodem-CRC implemented other places (like The Newsroom's Wire Service variant), I just decided to go with good old O.G. Xmodem. That contains 132-byte packets and is easy to write and checksum, and any errors over USB between your host computer and the VZ200 would undoubtedly be from bad bit framing rather than line noise which the default checksum algorithm should detect. While it overruns memory a bit at the end, this is largely irrelevant for just loading something we intend to immediately execute.

All that preamble yields us a stop bit stanza like this:

        ; stow character in screen buffer during stop bit time
        ; unfortunately we don't have enough cycle headroom to do
        ; a running checksum, so we have to do it after the fact
        ld (ix+0),a     ; 19 cycles
        ld (ix+0),a     ; 19 cycles
        inc ix          ; 10 cycles
        dec l           ; 4 cycles
        jp nz,datapak   ; 10 cycles
        ; 19 + 19 + 10 + 4 + 10 = 62

Here we use the IX index register as a pointer into screen memory and the L register as the packet length countdown. A double-store of the same location onscreen once again soaks up 38 cycles, then the increment and decrement, then the branch. A nice thing about the JP instruction, which is absolute instead of relative, is that the conditional branch form requires 10 cycles regardless of whether it's taken or not, so this entire stanza always consumes precisely 62 cycles as well. We use that instruction a lot in the cycle-exact portions so that we always have predictable CPU time.

Once we get a full packet, we know the sender won't do anything until we reply, so we can relax our timing and validate the packet at leisure, copy it into the correct place in memory and send the ACK for the next one. We send bytes using the same send-bit route I showed you before or a trivial variation, padded to 62 cycles per bit and also inlined. We accept .VZ-format files in this loader, so we have special handling for the first packet to make sure it has a generally correct format and note the type and memory address, which is where the rest of this packet and subsequent packets will be copied to. If it doesn't, then we send CAN and force the sender to abort.

By contrast, the start bit is handled with the same 25-cycle code I showed you before, because this is the fastest way we can be sure we won't miss one. But this also means we have no way of checking the keyboard nor implementing a timeout: there is no spare time to count cycles or scan for keys, and the only free-running timer is the VDG end-of-frame IRQ which will totally mess up our timing if that runs, so during the entire transaction IRQs are disabled as well. The program therefore assumes your sender is up and ready to go the moment it starts executing. On startup it fires off the initial NAK and waits, possibly forever if the other end never gets the signal until you reset the VZ200. (We display a message to alert you that no transmission has yet been received, which is immediately overwritten on-screen by the .VZ metadata.)

Let's see our loader in action. On the host side, to send the program to the VZ200 you can use any terminal program that speaks Xmodem (and just about everything does), just as long as it automatically starts the transfer as soon as the initial NAK arrives. With both my MacBook Air laptop and my Raptor Talos II workstation, I use lsx with the usb2ppp tool from BURLAP, which we earlier used to tunnel PPP over a serial line for the Brother GeoBook, but can be used to run pretty much any program over a serial port. Here's an example, substituting the path to the HW-597 that your machine uses (e.g., Fedora Linux on my Raptor Talos II uses /dev/ttyUSB0):

% usb2ppp /dev/cu.usbserial-110 57600 lsx -b ascii.vz
opening /dev/cu.usbserial-110
setting up for serial access
setting flags on serial port fd=3
starting process lsx
subprocess pid= 64301
Sending ascii.vz, 2 blocks: Give your local XMODEM receive command now.

We start the loader, which you can run as a separate program on its own and it will load anything that does not encroach on its default location at $e000. (We'll find an even better spot for it in just a minute.) Since our ASCII half-terminal program loads and executes from $8000, this is no problem; it takes up three blocks (there's apparently an off-by-one bug in lsx), so it's a good quick test of the machinery. The loader immediately sends NAK and we're off to the races.

Bytes Sent:    384   BPS:20                              

Transfer complete
subprocess terminated
restoring terminal settings

Ta-daaaaa!

Now we want to make it part of the system. To convert it to "firmware" takes advantage of a specific feature Ben built into the SD card reader for easier updates: the ability to load and run a new system "ROM" directly from the card.

The default memory map for the VZ200 puts the system ROMs between $0000 and $3fff, reserving the space from $4000 to $67ff for ROM cartridges, though a cartridge could technically take over any address range above the TOM (that's how the RAM expanders worked, after all), and we'll come back to that point later. For the system to recognize code at $4000 or $6000 as part of a cartridge, a sequence $aa $55 $e7 $18 is required in that order, and execution then starts at $4004 or $6004. As shipped to you Ben's device not only fills in RAM above the TOM, it also fills RAM in from $4000 to $67ff and puts its own code there with that sequence, effectively "slushware" (a la the DECmate II, and we'll use the same term here since it's not really ROM). This code is run by the system ROM on startup like a "cartridge," because that's what it looks like to the system ROM, and this code is what does the RAM test and initializes SD card access. Once the system is up, it then does this:

To make our replacement code useful, we should provide some quality-of-life features. We'll make it autostart into a transfer so that all you have to do is load up the program into your Xmodem sender and reset the VZ200, and after a polite delay it will pull down and run the program automatically. We'll also let you load multiple times if you want instead of immediately trying to execute the current file being transferred. We'll also finally put that routine in memory for the slower but more forgiving memory fill operation, and enable the VZ sticks by default in case we find something that really needs them. But more important than those, we should also let you drop back into BASIC and use the SD card loader normally without having to pop the card out. That requires us to include a copy of the actual VZDOS.VZ which we will embed in our replacement code.

This adds an additional complication, because the 2.32 slushware (the most current as of this writing) is already 8068 bytes long minus the .VZ header, leaving us only a little over 2K for our own code. Moreover, if we're over 8192 bytes (and it's inevitable we will be), the loading process will overwrite at least 100 bytes of our code with the trampoline and fail to copy the rest. We'll solve this by immediately copying the remainder as the first step in our binary, and then post-processing the object to yield a new VZDOS.VZ with a 128 byte hole between the first 8K and the last 2K (remember it gets loaded to $8000, so we have plenty of space there). Part of this code will be used to make a jump table entry for our slower fill so the call will stay constant with future updates, if any. That looks like this:

        di
        jp uentry
        ; any jump table entries we want should go here, and then be
        ; pulled out from VZDOS's offset below
        jp sloclr       ; slow hires clear for bad video RAM

        ; include original VZDOS but jump to our code
        ; start at a different offset, skipping the first three
        ; instructions which are never called again, so we can do them
        ; elsewhere
        binclude "vzdos.vz_232", 35

uentry  ;;; this code must all be under the 8K mark ;;;

        ; copy remaining 2K from its "safe" location + 128
        ld hl,0a080h
        ld de,06000h
        ld bc,00800h
        ldir

uentryb ;;; end code that must be under the 8K mark ;;;
        ; ensure ROM reloads
        ld a,0
        ld (08000h),a
        ; patch our VZDOS to not try to reload itself
        ld a,201        ; "ret"
        ld (04046h),a   ; only valid for 2.32

Since we are embedding VZDOS but we need to keep all its relative offsets intact, we skip the first 7 bytes and the .VZ header, and run those instructions later just before we jump back into it (if we do). We also do a couple patches so that VZDOS will reload (us) on a reset, but not when we execute the embedded copy, and still use an unmodified 2.32 so that you can see there's nothing up my sleeve.

Time for our fill routine.

        ; acts like ldir but does it manually (assume hl, de, bc set, and
        ; byte is in a). save the byte somewhere! don't save it in VRAM!
sloclr  ld (slobyte),a
sloclrl ld (hl),a
        inc de          ; make it real
        inc hl
        ld (hl),a       ; double store to emulate 7000->7001, etc.
        dec bc
        ld a,c
        or b
        ld a,(slobyte)  ; flags kept 
        jr nz,sloclrl
        ret

This is pretty simple-minded, but it works. We stash the fill byte somewhere not in VRAM, then do everything LDIR would and leave the routine with A, HL, DE and BC set as they would be at the end. (We do set the Z flag on exit, but most routines won't care about this.) Then our Invaders example, which was

; Subroutine: Size=36, CC=1.
; Called by: LBL1[8254h], LBL4[8F3Bh].
; Calls: -
8C9E SUB40:
8C9E              ld   hl,7000h         ; 28672
8CA1              ld   (DATA47),hl      ; 8DCEh
8CA4              ld   de,7001h         ; 28673
8CA7              ld   bc,081Fh         ; 2079
8CAA              ld   (hl),00h         ; 0
8CAC              ldir        
8CAE              xor  a      

can be patched by overwriting the two instructions at $8caa with ld a,0:call 04008h.

We'll now create that loadable version of Wordpro as a useful hack and stress test, which by being over 96 blocks should unmask any insidious framing errors in BFL caused by long transfer drift. (The resulting WORDPRO.VZ can also be placed on the card and run from there as we did previously, though doing so doesn't enable file operations either.) You'll need copies of the actual ROMs, which do circulate. The entirety of the code — really a disguised linker script — looks like this:

        org 07fe8h
        ; emit .vz header (24 bytes)

        db 056h,05ah,046h,031h  ; "VZF1"
        db "WORDPRO\0\0\0\0\0\0\0\0\0\0" ; filename null terminated
        db 0f1h
        dw entry

entry   ; copy code to 6000h and d000h
        ld hl,rom1
        ld de,06000h
        ld bc,0800h
        ldir

        ld hl,rom1
        ld de,0d000h
        ld bc,03000h
        ldir

        jp 06004h

rom1    binclude "vtech_wordpro/wordpro.u3"
rom2    binclude "vtech_wordpro/wordpro.u4"
rom3    binclude "vtech_wordpro/wordpro.u5"

Remember that Wordpro was first and foremost written for the VZ-300, which has 16K of RAM, so its TOM is much higher ($b7ff). The cartridge, because it has full control of the bus, thus maps its much larger ROM in at $d000-$ffff, with 2K of $d000 also mapped to $6000 with the cartridge header sequence. This echo of the main cartridge ROM is what actually autostarts everything since the system ROM doesn't know to check anywhere else but $4000 and $6000. The same scheme works for the VZ-200, except there is no RAM between $9000 and $bfff.

But with the BennVenn cartridge, we have RAM everywhere, so we load to $8000 and copy the Wordpro ROM dumps upon execution to their proper location(s), duplicating $d000-$d7ff to $6000-$67ff like a real one, and jump into the "cartridge" at $6004. This copy operation will destroy BFL-the-slushware, but we can just reset to reload it. Wordpro will get all the RAM it would expect to get on a VZ-300, even on this 4K VZ200.

Now that we can iterate quickly on them, let's patch and play a few more games before we close.

Another outstanding edutainment title is Maths Armada (not Math Armada, which my wife would insists is patentlys incorrects), where you have to load your cannon with the right sum, quotient, etc., aim, and fire. In the video we autoload the new binary with the BFL and the game starts immediately. This one I had to tack on a custom routine; the programmer had been a little too efficient and constructed a general fill subroutine which lots of things called, the screen clear portion being only one of many. (Darn those efficient little assembly language programmers.)

Another Z88DK game is Arkaball by Jason Oakley, an obvious Arkanoid clone, but competently crafted and worth a video.

Finally, a much more modern game is (the vibecoded) VZ-DOOM, a Claude-written raycast Wolfenstein 3D-style game. It fortunately didn't need patching and "just worked." Your mileage may vary as to whether you think the AI usage is cheating, and this blog has a strict no-AI-article-text policy, but it performs as advertised on this NTSC machine and likewise merits a video. VZ-DOOM uses WASD for motion, comma and period to strafe, E to open and SPACE to shoot.

VTech learned from this just like they learned from EACA, and developed new ROMs that were carefully clean-room reverse-engineered, additionally incorporating a licensed copy of Microsoft BASIC retrofitted to act like Applesoft BASIC. This process provided the legal assurance that not a nybble of Apple's code was even consulted, and VTech used these unencumbered ROMs to create what was introduced at Summer CES 1985 as a redesigned "90% compatible" (per Creative Computing) Laser 3000. In turn, that reworked Laser 3000 was transformed into the 1986 Laser 128, a semi-portable riff on the Apple IIe with an expansion slot and built-in 5.25" floppy (later 3.5"). VTech's work paid off handsomely: reviewers were impressed by its value for money, most software never noticed the difference, and Apple's repeated attempts to prevent its importation and sale all ended in failure. The Laser 128 family's low price and exceptional built-in functionality made them the most widely sold Apple II clones in the United States, finishing on the market as late as 1989 in an upgraded 3.6MHz version with a 3.5" disk drive and over 1MB of RAM.

At DSE Jim Rowe left the company and after a brief stint at Microbee eventually returned to journalism in 1987. Meanwhile, DSE was still selling enough VZ-300s to keep them in this 1987-88 catalogue, and according to Greg Dubois' contacts at Dick Smith even at that late date they continued moving over 100,000 units a year, but in the end it was actually VTech that wanted out: VTech wanted to redirect factory capacity to the Laser PC and wasn't willing to keep producing the older system, and even DSE's offer to double the order couldn't convince them otherwise. Although some software and accessories still appeared in the 1989-90 catalogue, the computer itself did not, and the line disappeared completely by 1991. For a time afterwards DSE sold IBM consumer PCs and even Commodore PC clones in the process of adopting its own DSX PC brand.

In the 2000s the company failed to make a successful transition from its mail order origins to the new world of online sales, and despite several attempts to rework its retail presence Woolworths unloaded Dick Smith to Anchorage Capital Partners in 2012 in a controversial deal where much of the sale price was allegedly financed by Anchorage liquidating DSE's own assets. Anchorage took the company public in 2013, netting tens of millions, but the company did not recover and all 363 remaining stores were closed by May 2016. Today the Dick Smith brand lives on solely as a mark of online retailer Kogan, primarily selling consumer electronics.

As for this NTSC VZ200, it should be very possible to clone it because the ROMs are the same as the better-known DSE flavour and it's otherwise all off-the-shelf hardware; moreover, it would be infinitely easier to maintain and repair than the ghastly PCB it's got now. The schematics for the PAL Dick Smiths are widely available and there are even fewer components needed to build an NTSC one. At least one person has already made an NTSC-compatible RC2014 workalike, though that project uses a GAL, and it seems like we could make a more straightforward knockoff just using what the original did — with the exception of the colour encoder, which would be improved and somewhat simplified by using a proper MC1372 instead of the TBA520. I know "Leaded Solder" Mike has his clone CreatiVision, so I look forward to him picking this up as a new challenge. ;)

We'll be doing more with this system and particularly the VZ-300, now safely awaiting my next Southern Hemisphere trip, in future articles — along with a recently-acquired PAL CreatiVision of our own, the basis for the Dick Smith Wizzard, which we need to see if we can get up and running (I do like me a 6502 and a 9918). Meanwhile, David "Bushy" Maunder's VZ website can give you all the articles, technical information and software that you can stick on an SD card.

The programs we wrote for this article and their assembler source code are all on Github, including pre-built binaries and ready-to-go Bush Food Loader "slushware" you can use with your own SD card loader, all of which are under the BSD 2-clause license.