Veeder-Root Counter

Posted on 2025-06-30 by M. Eric Carr

One favorite hobby of mine is visiting flea markets and antique stores, looking for inexpensive and weird pieces of technology, and figuring out what they do. The Mystery Telco Box is a good example; I knew it would be interesting but had no real idea what it did. (It’s a monophone power unit.)

Another gizmo bought roughly around the same time is a Veeder-Root device with a six-digit counter on it. The only control visible is a digit-reset wheel, which seemed to work correctly. It was clearly either a counter or timer — hard to tell which. (It could easily be based on a 60Hz AC motor, or could count pulses.)

The front of the device (after some testing)

The manufacturer’s plate, showing the model and expected voltage.
Still doesn’t directly say what it is. (I could look online, but that’s cheating…)

It wasn’t immediately obvious how to open it, other than removing the front cover plate. Loosening the four screws around the connection wires just seemed to loosen an internal piece, so I put them back in place.

Eventually, I noticed a drop of dried pitch in the middle of one side. Scraping it off revealed a flat-blade screw (the only mainstream choice worse than Phillips.) It came out with a minimum of fuss (for once), allowing the two halves of the cover to be removed. Pretty slick design, honestly.

With the covers removed, the inside is visible.

Now that the mechanism was visible, the device could be seen to be a counter. Two electromagnets work in tandem to pull a metal bar to advance the count. (The only problem was, manually pushing on this bar didn’t quite advance the count — the mechanism was out of adjustment.)

The back side, showing the escapement mechanism that advances the count.

A little experimentation revealed the problem — the bar was being pulled to the electromagnets correctly (good — I really didn’t want to re-wind the coils), but wasn’t being pushed back far enough by the spring to catch the next digit.

Veeder-Root helpfully provided a set screw for this function (and another for the backstop). By turning it almost to the end of its travel, I was able to get it to tension the spring enough to push the plate back in place, allowing a complete count. But we’re out of set screw at this point — if it fails again, it needs a new spring (or for this spring to be uncompressed a bit.)

The set screws. The top one tensions the spring, and is about as far in as it can go.

This counter will probably be a static museum display piece, so I don’t need it to be reliable. (Otherwise, I’d have replaced the spring.) But it’s working now, and (at least with a new spring) should keep on working for another eighty years or more.

Testing the repaired counter.
Posted in Mechanical, Reverse Engineering, Troubleshooting | Tagged , , , , , , | Leave a comment

World’s Worst BASIC?

Posted on 2025-05-30 by M. Eric Carr

I’ve heard people claim that the Timex-Sinclair 1000 / Sinclair ZX81 is the worst BASIC programming environment ever. That’s not even close. Borrowing the old Beatles drummer joke, the ZX81 isn’t even the least-capable computer made by Sinclair. The older ZX80 has half the memory and a smaller ROM. You kids were just spoiled by the ZX Spectrum having fancy features like color, a Chiclet keyboard, and sound.

And there’s a BASIC interpreter out there that makes the ZX80 look like a supercomputer.

A “Hello, World!” variant, in Atari BASIC Programming.
(You can see it running here, if the excitement won’t be too much.)

Back in 1979, people were designing all kinds of cool games for the Atari VCS (Atari 2600). This was a hastily-designed (but insanely popular and fun) video game system that was intended to be an upgraded version of Pong. It was designed to implement two player sprites, a missile sprite, static background graphics, and on-screen numeric scores. Famously, it didn’t even have a video buffer, so each line of video had to be drawn in real time by the program. (There’s a great book — Racing The Beam — that talks all about it.) It’s really a glorified, generalized Pong implementation. The tricks developers had to do in order to create the games I loved as kids don’t lose a bit of the magic when you start to understand how they’re done. Instead, you understand just how creative the developers had to be.

Despite the overall system being designed to handle games roughly as complex as Atari Combat (at best), creative programmers were able to use system features off-label to make the system do amazing things. The Atari graphics system provided for two player sprites, two scoreboards, and a “missile” sprite, in addition to a rudimentary background graphics system. (If you’re familiar with Atari Combat, that’s the sort of game that was envisioned.)

Warren Robinett’s “Adventure” was one of the first examples that really showed what the platform could do, despite all of its design limitations. By creative use of the background and sprites, and triggering the loading of different screens when the player moved offscreen, a multi-room Adventure was possible, with dragons, swords, chalices, magnets, bridges, and the world’s most annoying bat. (Seriously — Rhindle the Red Dragon is just misunderstood, but that thieving bat has to go!)

Adventure was one of two cartridges Robinett wrote while working at Atari. The other was BASIC Programming. This isn’t so much a practical IDE for creating programs as it is a proof that with sufficient creativity and determination, a talented programmer could bludgeon the 2600 into doing just about anything. Even the much-maligned Atari port of Pac-Man was an impressive feat of programming, given the platform. To actually implement a BASIC interpreter is straight-up mad scientist level stuff.

Still, given the environment, Atari 2600 BASIC is necessarily limited. While you can technically have up to 26 variables, you probably couldn’t use all of them at the same time, due to the 63-character memory limit for programs(!) Variables are two-digit unsigned BCD integers, storing values of 0-99. There’s support for graphics (moving white and red dots around a blue field) and sound (playing one of eight notes). Input is actually BASIC Programming’s strong point, since it is able to handle four channels of analog input — two channels each of horizontal and vertical. (Presumably, this is done with four paddle controllers.)

BASIC Programming for the Atari 2600 is probably the single worst BASIC implementation I’ve ever come across, in more than four decades of programming every BASIC implementation I could get my hands on, from the Timex-Sinclair 1000 to the Tandy PC-6 and Model 100 to the IBM PC to 1980s smartwatches programmable by a custom app.

But it’s also probably the most impressive BASIC implementation, too — and no doubt inspired lots more games that the 2600 really shouldn’t have been able to play.

Posted in BASIC, Coding, Nostalgia, Reviews, Toys | Leave a comment

Mystery Box

Posted on 2025-04-30 by M. Eric Carr

I love flea markets, especially when I come across interesting-looking pieces of technology that I’ve never seen (or maybe just read about) before. Even better if I can’t tell what they are or what they do. Those always have something interesting to teach you.

So when I saw a large, vaguely telco-looking, Bakelite box for four bucks at a flea market in Maine, I had to get it. I’ve seen a lot of tech in half a century, but this was not only something I’d never seen before — it was heavy, obviously contained mechanics, and looked like some kind of telco device. (If you’ve seen the underside of mid-1900s rotary phones, you know what I mean.)

It’s Bakelite, has what looks like a generator crank on the side, and not much else…

The bottom side was not much more help in determining what it might be. Normally if it’s some kind of telephone ringer, you can hear the bells resonate when you shake it — but not so, in this case. Just a heavy, solid piece of Bakelite, metal, and whatever else was inside.

Gotta be a telco device of some kind. But what?

The two screws on the front were the obvious place to start opening it up (and I had tried this at my folks’ place when I first bought it), but the crank on the side was preventing the cover from opening. Turning it in either direction seemed to be turning a generator / dynamo mechanism inside the box, so it looked like the only way in was to punch out a retaining pin. I decided to wait until I came back with a car, because whatever this thing was, it was too big and too heavy to fit into my luggage. And I could just imagine the conversation with TSA, trying to explain why I’m flying with something that I didn’t know what it was.

So the Mystery Box got to go home the slow way — via The Great Kia Niro EV Adventure.
(The station wagon, in all its forms, remains one of humanity’s best inventions ever.)

Back home, I punched out the retaining pin, only to discover that the crank would have simply unscrewed — it was just stuck.) With the crank removed, the cover came right off, revealing a generator, mechanical crank-activated switch, terminal block — and two large dry cells. (Note to self: Carrying this back home by car and not plane was a good idea. It’s not a bomb — but I bet it would look like one if x-rayed.)

Dry-cell batteries, a generator, and a switching mechanism. But no electronics…?
(Also, that’s the wrong size nut. Redneck engineering spans generations!)

…So, what is it, (other than old enough to have batteries I’ve never seen in use — and I’m 52)?

Dry-cell batteries! I remember reading old 1960s science books that talked about them!

A few minutes’ Googling found the answer: it’s apparently the power unit of a “monophone,” a predecessor of the two-element telephone. It was made by Automatic Electric, and is roughly 100 years old. (I’m guessing the batteries might be newer, but who knows?)

Near as I can tell, the batteries (which seem to be non-rechargeable) power the monophone for speech, while the generator creates higher voltage for the ring functionality. (There’s a switch that’s activated when the crank is turned, changing the output terminals from battery to generator. When the crank is released, it springs back to its center position, releasing the switch.)

Neat.

But the coolest part is, somehow the dry cells still produce voltage! (They can only source microamps, but the voltage is still there.)

What do you mean, it still has most of its voltage?!?
(It briefly hit 1.2345 volts, trending downward, just to add to the surrealism.)

…I wonder if it will power some 1970s-era telephones I have?

If nothing else, those Hercules batteries will make great Thévenin source demonstrators.

Posted in Analog, Nostalgia, Reverse Engineering | Leave a comment

Transistor Reliability

Posted on 2025-03-30 by M. Eric Carr

Today’s computers depend on billions of tiny switches known as CMOS transistors (CMOS logic) to process information using Boolean logic. Each transistor, smaller than a virus, flips billions of times a second without error—a feat that would amaze the early inventors of the transistor, whose first devices were famously unreliable.

But just how reliable must these transistors be? Our intuitions can fail us badly here — do they have an error rate of one part in a billion? Maybe even one part in a trillion? Amazingly, such an ostensibly-reliable CPU, whose transistors have only a one-in-a-trillion chance of malfunctioning, wouldn’t even get through the bootup process. It would fail in milliseconds. You might be lucky enough to see a few characters on the screen before it halted.

So, just how reliable do the transistors in modern CPUs need to be? Let’s estimate.

Imagine a university computer lab with 100 computers (or, 100 students in a lecture using their smartphones, which are roughly as complex). Each device has a CPU with about one billion transistors (this is conservative for 2025), and we’ll assume that about 10% switch states every clock cycle (sounds reasonable to conservative, since transitions happening where there shouldn’t be any is a problem, too) at 4 GHz (typical for modern CPUs). That’s around 100 million transistors switching 4 billion times per second, for 8 hours every school day. And yet, crashes due to transistor errors are almost unheard of. (That’s what software is for.)

To quantify this, if we assume there’s a 10% chance a single transistor error causes a computer crash, for the lab to have only a 50% chance of experiencing at least one crash in an 8-hour day, each transistor switching event must be about 99.9999999999999999999994% reliable —that’s less than one error in every 10²³ switches!

…And one computer failing each day would be a big reliability problem for the lab. You shouldn’t have anywhere near that many hardware problems. Not in 2025. Maybe a few per semester or something if your PCs are old. And most of those will be related to bad power supplies, failed motherboard capacitors, or just good old PEBKAC.

In practical terms, this reliability means each transistor would likely switch continuously at 4 GHz for millions of years without making a single mistake. Engineers achieve this remarkable reliability through precise manufacturing, rigorous testing, and built-in error correction mechanisms. (The very nature of digital electronics corrects for noise.)

Real-world studies from companies like Intel and research institutions like CERN confirm this high reliability, noting that rare errors, often caused by cosmic radiation, are usually managed through error-correcting systems.

Next time your computer runs flawlessly for days or months on end, consider the silent marvel happening billions of times every second—tiny transistors working almost perfectly, making modern digital life possible.

This article was coauthored by ChatGPT 4.5 in Deep Research mode, and then abridged and modified upon request and edited and expanded by the author.

Posted in Components, Digital, EET205, Electronics, Math, Science | Tagged , , , , , , | Leave a comment