I was thinking about using HDLC-like bit stuffing with NRZI for a project, and I wanted to see what the resulting waveforms looked like and have an easy way to try encoding different Unicode text strings. (My theory is that this encoding not only wastes less bandwidth than conventional asynchronous serial data with start bits and stop bits, it also guarantees transitions more often, making it more forgiving of timing error.) So I whipped up this DHTML SPA, inspired by Sigrok Pulseview, which is better-looking and more full-featured. It uses little-endian bit order.
To see the bit-stuffing in action, you need to have five consecutive 1 bits in your unstuffed bitstream. ASCII characters with five consecutive 1 bits inside the same byte include ^_ (control underscore, US), DEL, and “>?_|}~”. Non-ASCII characters include “¿”, because in UTF-8 that’s c2 bf, and the two high bits of c2 are both set, and they come right before the six low bits of bf, which are also all set. With non-ASCII characters, you can also get runs of five 1 bits that cross characters, as in “áo”, where the low 4 bits of “o” 6f follow the high bit of the second byte of “á”, c3 a1.
Last night on my cellphone in bed, I tried to get Claude Haiku to write the program for me. After an hour of prompting and code review, it had 250 lines of code that almost worked — displaying waveforms, but not correctly. This was pretty impressive for not having tested it, but still not really what I wanted.
So, in an hour and a half more, I got this waveform viewer working better than what it had produced, in... about the same amount of code, actually. And in a total of about two hours I had something more or less serviceable for my immediate purpose. So, maybe I could have gotten the AI to do it just as fast? I don’t know.
I did learn about the TextEncoder class and the “input” event on <input> elements from the bot.
This web
page by Kragen Javier Sitaker is
marked CC0
1.0