Ha ha
He also did the TV typewriter:
https://en.wikipedia.org/wiki/TV_Typewriter
which allowed people to have something to hook their bare board micro to.
I had money to buy his green book, but not the computer or the TV. :)
Try telling that to Isaac Newton. :)
Or better yet Edison or the USPTO.
The Sinclair ZX-80 was much closer to this than to the TV Typewriter (which was 100% hardware). Some other computers that used this technique back in the day:
https://en.wikipedia.org/wiki/Aamber_Pegasus
https://en.wikipedia.org/wiki/Galaksija_(computer)
And here is a recent project:
This was a Big Deal because the standard setup at the time was a Mac connected to a LaserWriter, but it occurred to him that you didn't really need to tie up a Mac if all you were doing was sending the same PostScript file to the printer over and over again.
He also corrected my pronunciation of "tinaja" when I called him.
"Don't fight the eagle."
It involved first going through the printout using colored pencils and color highlighters in a particular way to develop visible structure.
I remember being quite impressed with his methods.
The website is an amazing labyrinth. It’s rather like a higher dimension toroid full of dusty wonders from a simpler time. Very much old Arizona.
Was a teen at the time.
And it worked!
Back then, one could either display to screen, or dump to a printer, or file.
The paper was where this method shined.
And the beauty of it was having a plan and compartmentalizing the problems.
Start with program flow. And on 6502, 6809, which were the chips I was learning on, that was branch, jump, jump to subroutine, and a few other tricks, like pushing addresses on to the stack, then returning from subroutine. RTS.
I used colored pencil though. Highlighters were too big of a commit. Otherwise, yeah. Just start finding where program flow changes.
Structure just kind of happens! You are going along and insight hits. Early on, it hit over and over too. Small programs printed and in a binder became a sort of library. Examples, snippits, notes, tricks.
From there, one just peels back the onion. Loads, stores, program, data, math, compares as math...
Was very empowering frankly.
Also learned about the power of commenting.
Many attempts other peers and I did before checking out Lancaster, boiled down to literal descriptions.
LDA sprite, X 'Load A with contents of address, plus X
STA (screen), Y. 'Store A to address pointer, plus Y
LDA sprite, X 'get sprite data
STA (screen), Y. 'write to display
The other benefit of these two things combined was coding on paper. Thinking through printed out listings helped when writing programs out.
And often, I would start with an ORG statement, some EQU (equates) to define important values and addresses and then just write the comments.
If it reads well and each line contains one action, it translates into assembly language pretty well, maybe taking two or a few instructions. No big. Just work the problem a line at a time and before one knows it, a routine is done.
On the more fancy computers, we had sprites and sound chips. Writing values in places did a lot.
On the Apple 2 computers, there was none of that. But also pretty much everything needed software.
People made bits. Blitter, math, sounds, etc...
That simple (well, screen memory excepted) system, coupled with how Lancaster tended to think and communicate, proved effective. I left High School in the 80's basically fluent in 6809 and 6502 assembly and machine language and able to write non trivial programs, and or use them in tandem with high level languages to make applications.
I am not saying Lancaster's work was responsible. We all had magazines, teachers (who varied in what they could speak to), mentors, books and one another.
But, how he approached problems was a definite influence and I would argue a definite multiplier on progress.
Good times. Interesting character. Great influence.
I was on a compiler team at Sycor writing a compiler that took a language like PL/M and produced 8085 code. It produced relocatable object files and a listing that was annotated with comments generated by the compiler. Additionally, the listing would include the number of CPU cycles each basic block. This was useful to the developers, who were all assembly language programmers getting used to writing in a higher-level language.
As they started to use the compiler they would often come to my desk pointing out incorrectly generated code. We would sit down and go through the code. Usually, about 3/4 of the way through the suspicious section, they would say "wait--this is correct. But the code is so wacky". We would point out that it is faster than a more standard way. Our boss would tell us "A compiler should generate code that an assembly language programmer should be fired for writing."
The Lancaster way mentioned here is great for writing assembly code, and learning.
If one is maintaining assembly code, or authoring it, the derivative ideas remain solid today, particularly on smaller or simpler CPUs.
Found it: https://www.tinaja.com/ebooks/socv1.pdf
"Son of Cheap Video" :-)
Also noticed "Scungy Video" :) (Do NOT search for this term in your favorite search engine.)
Those two books were my best purchases back in the day, they helped immensely to grasp the technology. I see they're now free for download at Don's page, and they're still relevant today. I would highly recommend them to all newcomers to electronics.