4 ms·

I remember one of his books - perhaps the one on Apple assembly language - described an organized way to disassemble executables. It involved first going throu

I remember one of his books - perhaps the one on Apple assembly language - described an organized way to disassemble executables. 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.

ddingus 6y ago
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.
- wglb 6y ago
  > Also learned about the power of commenting. 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."
  - ddingus 6y ago
    I generally agree with all of that. 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.

ddingus 6y ago

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.

wglb 6y ago
> Also learned about the power of commenting. 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."
- ddingus 6y ago
  I generally agree with all of that. 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.