Stores of the famous Dr McCracken

Written 2023-09-12

Tags:UMR MST Rolla 

Back around 2008, I and a few friends had a computer architecture class that would change the course of my degree. There were two sections, and we started by designing a simple computer, maybe a 4-bit ALU, from scratch.

By scratch, I mean that we started with diodes, resistors, and transistors, from that built gates, latches, registers, address decoders, an ALU, memory.

The class was difficult, yet highly productive. Eventually, students of the two sections that year found each other, and merged our study groups at night in the library.

Eventually we wrote simple programs for it in machine code, which we would submit to him, he would evaluate, explain any errors or inefficiencies, and return to us. Up to that class, most of my programming had been on UNIX and Linux systems, so it was strange to find myself writing for a hypothetical machine that couldn't really be tested. At some point I wrote a simple assembler and simulator to help me.

But this post isn't about me, it's about a few of the things the teacher, Ted McCracken, mentioned about his previous career, during that semester. A few of these things, namely that he had survived three airplane wrecks and built one of the earliest 3D video cards pushing the limits of display the 1980s!

Thinking back on my career, I learned the most about system design in Dr Ted McCracken's class. One of the most knowledgable teachers in my major I had met, but a few of these things seemed maybe a little far fetched or at least unusual. But the more I learn, it's all true.


VECTRIX was a manufacturer of video graphics accelerators. A great resource on these is We can find the business registration for Vectrix of Missouri. We do know a few models: Some competitors included: Some contemporary IBM CGA modes for reference(which my family had as a child):

One thing that didn't make sense to me, for a time, about some of the VECTRIX units was the framerate and resolution claim.

For many display technologies pixels need to be periodically refreshed - this is true of phosphor CRTs, most LCDs, AMOLED and PMOLED displays, though with differing decay rates and corresponding minimum refresh rates to limit flicker. When display refresh is driven from a framebuffer it's usually known as scanout. It's fairly common to have at least a small amount of dedicated high speed or dual-ported video memory for the framebuffer(s), both for performance reasons and because scanout has some realtime requirements that must be met. For single-ported memories scanout bandwidth takes away from bandwidth usable for rendering, so today's GPU memory tends to be one of the fastests in the system.

We can estimate the minimum average memory bandwidth required for scanout like so: number of columns transmitted * number of rows transmitted * framerate * framebuffer bits per pixel. And when we do 1024x1024x60Hz*12bit, we find that the maximum spec'd VECTRIX Pepe minimum scanout bandwidth is ~95MB/s. An IBM CGA(color graphics array) adapter has almost 1MB/s. What gives?

That's really an unfair comparison - Pepe was a high end device, so we should compare perhaps with IBM's Professional Graphics Controller(PGC) at only 18.5 MB/s. The IBM PC/AT 16-bit ISA bus is only around 8MB/s, and a significant limitation if flinging pixels over the bus. The more I learned about embedded displays, the more I wondered how this thing could've worked because the framebuffer bandwidth is several times that of the system.

The truth is stranger than fiction - both PGC and Pepe supported both a fully remote framebuffer as well as offloading vector rendering to the display controller. The IBM PGC supported GKS and VECTRIX's had its own command set, and a bit-planed framebuffer.

The original VECTRIX VX series were external components connected by serial or parallel cable to a PC. The command set included instructions for 3D rendering, matrix rotation/translation/scaling, adjusting the synchronization between rendering and scanout(BLANK MODE vs FLASH MODE), but also, arbitrary code execution - the U-command allows uploader user-code to the VX to memory location 0x100 and jumps to it. The hardware registers are documented in the Vectrix Advanced Programming Manual. Eventually VECTRIX would ship their Pepe model, which fit everything into a twin-slot AT card, removing the serial port rendering command bottleneck.

The key trick in attaining the needed framebuffer bandwidth was bit-planeing. Rather than byte-addressable RAMs, usage of single-bit RAMs allowed wiring as many as needed in parallel, so that framebuffer bandwidth scaled with the number of bitplanes, which scaled with log2(number of colors). Of course, the IBM PC, XT, and AT computers couldn't even reach this bandwidth but didn't need to, as they only needed to upload commands to the video system over whatever bus was available. There was a dedicated microprocessor responsible for managing the hardware. And, you can even upload your own instruction streams to it, like an early proto-shader.

Third Airplane Wreck

In order to more efficiently deliver video cards, Ted said they bought an airplane. At some point, I think while landing, he misjudged the windsock, leading him to land with a tailwind instead of a headwind. After touching down, he realized the airplane wasn't going to stop in time, and throttled back up to take off. However, at the end of the landing strip is a berm with a fence, topped with a power line. He's not going to make it over the powerlines, so he aims under them. This almost works, except that his landing gear catch the fence, pulling up fence posts until his airplane slows to a stall and falls into a barn.

About the time my friend Doug K became a pilot, he searched through the accident reports for small airports around the area we went to school in. Sure enough, he found the report for this wreck pretty much as described in class, registered to Video Systems Engineering.

ZFS Pool upgrade

Written 2023-09-10

Tags:ZFS 5big NAS Debian Lacie 

One of the old 500GB disks in my NAS has begin to throw errors.

Buy SSDs

I picked up 6x used PM863 SSDs from eBay. They came with 90%+ wear leveling remaining, except for one at 85%, which will be my cold spare and backup disk.

Checksum everything

find /media/ -type f -exec md5sum {} \+ >backup.md5sum 2>backup.failure
cat backup.failure #should be empty

zfs-send everything to the cold-spare

First, we need a root pool snapshot. In my case:
zfs snapshot -r tank@backup
Next, we send it to the external SSD that I've mounted at /media/usb, running in screen:
zfs send -vRI tank > /media/usb/backup.zfs

pro-tip: make sure you're plugged into the USB3 not the USB2 ports :p

Hardware swap

Take out the old array, put the new array into adapters and install.

recreate new zpool

sudo zpool create tank raidz

zfs-recv everything from the cold-spare to the pool

cat /media/usb/tank@backup | sudo zfs receive tank -F

verify checksums

md5sum --check backup.md5sum

Questionable XT90 Anti-Spark connectors

Written 2023-09-07

Tags:soldering Connectors RC 

When dealing with larger RC batteries, it's sometimes possible for the act of connecting a battery to an ESC or other component to exceed the max current for components like capacitors. To this end, anti-spark or soft-start circuits are used. These need to have two characteristics: limit inrush current, and not consume or waste a large amount of power themselves.

What I've used before is a small circuit board with a MOSFET and an RC circuit that slowly turns on the MOSFET, and soon the MOSFET is fully on. Sometimes with capacitor and inductor filtering as well.

Recently, I found an 'anti-spark' connector called XT90S. Supposedly it has great efficiency while still limiting current with a 5.6 ohm resistor.

Internally, this is much like a regular DC connector, except that there is an insulating ring and connecting ring with a 5.6ohm resistor. As the connector is plugged it first makes contact through the 5.6ohm resistor for current-limited charging, and lastly makes contact directly, enabling efficient operation.


But there is a significant problem with this design: it's accidentally a break-before-make connection. Due to the shape of the bullet contacts below, the bullet contacts actually disconnect between the 5.6ohm ring contact and final seated contact, leading to an intermittent no-current state, followed by a current spike that is likely to cause, you guessed it, a spark.


To test for this, I set up the following circuit using a 1-ohm resistor for current sensing, a power supply, and an oscilloscope:



I tried several times, but the fastest I could plug the connector in still resulted in a 25millisecond power-cut as the bullet connector glided over the insulator, followed by a large current spike:


I think this general idea is great - it's super simple and bypasses itself so it's even more efficient that a MOSFET. If one of the bullet connector fins could be made shorter, it would makes contact with the 5.6ohm resistor ring after the other three fins, but before they disconnect, it could keep the 5.6ohm ring connected until the other fins fully engage at the end.