I hadn't seen that 2007 EDN article. I did know of some hobby people using an RC network on a shift register back in the old days (talking about the '90s) but there were some issues because of the lack of latching meaning it was only good for LED mutiplexing and some non-critical tasks and it was chip specific because not all of the manufacturers made logic chips that had reliable schmidt threshold voltages etc, some were prone to latchup or erratic operation.
Before I got too deep into this project I did some testing on new HC series CMOS and found the HC CMOS schmidt threshold voltages to be reliable and the inputs extremely resistant to latchup even with slow changing input voltages. Modern logic chips are so far advanced from the old things of 10 or 15 years ago! The HC series have great schmidt inputs.
So it's a combination of an old idea, plus some excellent modern shift registers and a bit of creating and experimenting thrown in...
And thanks people for the nice words!
PS. I've added a temperature controller to the Shift1-LCD Projects page too.
(edit)I just saw your last post Mike. It's an interesting idea, I hadn't really imagined connecting a 4x4 keypad to the thing, the PCB was designed to be little and cheap for making little controllers and "smart displays" etc. But now you said it, a 4x4 keypad could be connected to the 4 LCD data pins (D4-D7) and to 4 inputs of the 12F675.
You can make the time constants shorter, but the values I chose were to make the shortest pulse 1uS, which is usable on 12F675 (or any PIC) on 4MHz osc speed. That was a deliberate design factor. The 1:20 ratio of the two different time constants were chosen for max reliability, I wanted large safety margins around the timed values that work so it would not be fussy to use.
I tested on the finished hardware and many of my time constants (shown in green on the picture above) can be shortened a lot especially the recovery times. But 3 to 4mS to send a character is acceptable, there's not much to be gained by reducing that to 2.5mS or even 2mS. Data reliability is important, I set one up sending characters and commands to the LCD with no breaks (about 320 per second) for a full day, about 10 million bytes sent with never a glitch. You know if you get a glitch on a command as chars will be in the wrong spot or it will corrupt the whole display etc.
As for the speaker etc, since the 12F765 only needs 1 pin to drive the LCD and backlight, there are 3 to 5 pins still availble for things like that.