I don’t know if people are upvoting this page because of the cool retro look of his home page, but I’ll mention that he’s well known for his TTL Cookbook and CMOS Cookbook. Everybody who was into digital electronics in the early 1980s had them. More than once visitors to my place took the “cookbooks” from my shelf expecting to see some delicious recipes and were sorely disappointed.
Yeah, he was also doing print-on-demand books using a fleet of dedicated Apple II machines sending PostScript to Apple LaserWriters.
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.
And the amazing cheap video cookbook! Given that it uses the 6502 as a glorified state machine it is a good model for building FPGA based CRT controllers.
I still have it on my bookcase, and I was not remembering correctly, it has only TTL type logic devices! So now I need to figure out which was the 6502 book.
Thanks! I noticed "PAiA" electronics sold kits of these--I remember that name from back then. Did they sell parts or other kits? Looks like they are still in business.
Also noticed "Scungy Video" :) (Do NOT search for this term in your favorite search engine.)
Which used the same technique as the Apple 1 video terminal, though Woz claims not to have known about it when designing it. Probably true, because there weren't many inexpensive options for RAM besides shift registers!
He later had books mentioned in other comments: "The Cheap Video Cookbook" and "Son of Cheap Video". In these he added just a few TTLs to a Kim-1 computer and generated video using mostly software.
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:
The article is from 1973. I think exact eras are getting a little muddled here. Altair, Mark-8, SCELBI, these are the sort of home computer that came out shortly AFTER this project was published.
You are probably right. I first wrote "many", then edited it to say "some", in the interest of accuracy, since I had only used a few kinds myself, and did not know if all the others supported that feature or not :)
I used that method early on after some magazine published it. Was either BYTE or Creative Computing.
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
The better way was to talk about what was happening!
LDA sprite, X 'get sprite data
STA (screen), Y. 'write to display
After a time, things like the Apple ROM listing made sense. Soon after that, our programs made sense to one another.
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."
> he’s well known for his TTL Cookbook and CMOS Cookbook.
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.
I've been reading his stuff for decades. Lately, I stumbled on his documentation of the canals built centuries ago. In addition to pictures, he has a video describing some of the research on the canals. https://drive.google.com/file/d/1XAEuZJETYPknGMhtXkUEGkbZBEx...
Ron Lancaster’s “tinaja” webpage was my dad’s browser homepage for years, I think starting back in the late 90’s. Maybe it still is. My dad loves it because it has links for just about everything he’s interested in.
Magazines have no use whatsoever? I hit back. I recently ordered some magazines from a neighborhood girl. As they arrive I flip through them and notice how perfectly currated and edited they are and this makes gleaning new, valuable information from them very easy. I flip to the back and see the ads from reputable companies making me aware of their innovations. So much valuable information so quickly about a deep subject (home building). After that I realized how chaotic the internet still is and how horrible search engines and websites are in general. Almost completely screwed up by data tracking, weak writers, SEO, noise, FUD,and just plain dilution. We have along way to go before we write off magazines as useless. I'm sure there is good, no great, information on that site. Have fun reading every last word to find it. Pick up a good magazine and see how it feels to consume it. You can even submit comments and if they are worth anything they will be published and replied to. Long way to go indeed.
It's because Don Lancaster refuses to sell outside of the United States, not even to Canada. He says in one of his articles that he had too much trouble with foreign orders, so he decided to never take a foreign order again. He set up his eBay store to reject IP addresses outside of the U.S. I tried connecting to his site from both a U.S. IP address and from a non-U.S., and I can confirm that outside of the U.S, you get zero results.
One thing I remember, that seemed right out of left field was Don basically compiling books.
Postscript printers could often deliver more pages per minute mechanically than their processing could deliver.
Lancaster showed how to basically compile and pre-process a book into a big postscript file that minimized the printer compute requirements. Load up an Apple //e machine with some respectable storage and it could deliver books on demand, printing at near max print speed.
Later Adobe productized this. Originally it was called "PostScript Distiller", but then they introduced some incompatibilities with PostScript and renamed it "PDF".
Sounds like an unanswerable question; it would be surprising if anyone reliably remembered earlier expansions for the initialism. Distiller remains an Adobe product.
48 comments
[ 4.6 ms ] story [ 93.1 ms ] threadThis 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.
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.)
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. :)
https://www.willegal.net/appleii/apple1.htm
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:
https://en.wikipedia.org/wiki/Gigatron_TTL
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.
The better way was to talk about what was happening! After a time, things like the Apple ROM listing made sense. Soon after that, our programs made sense to one another.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.
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.
Don Lancaster's “Guru's Lair” Archive - https://news.ycombinator.com/item?id=22457501 - March 2020 (8 comments)
Think of "using dollars" as "spending gasoline" [pdf] - https://news.ycombinator.com/item?id=700546 - July 2009 (7 comments)
How to Bash Pseudoscience - https://news.ycombinator.com/item?id=514491 - March 2009 (1 comment)s
https://www.tinaja.com/santa01.shtml
His "unauthorized autobiography" was an entertaining read.
https://www.tinaja.com/glib/waywere.pdf
https://www.tinaja.com/fwsamp1.shtml
https://www.ebay.com/sch/abeja/m.html
Postscript printers could often deliver more pages per minute mechanically than their processing could deliver.
Lancaster showed how to basically compile and pre-process a book into a big postscript file that minimized the printer compute requirements. Load up an Apple //e machine with some respectable storage and it could deliver books on demand, printing at near max print speed.
Damn cool.