The Story of Mel, A Real Programmer, Annotated (1996)(users.cs.utah.edu)
users.cs.utah.edu
The Story of Mel, A Real Programmer, Annotated (1996)
https://users.cs.utah.edu/~elb/folklore/mel-annotated/node1.html#SECTION00010000000000000000
The annotations are at https://users.cs.utah.edu/~elb/folklore/mel-annotated/node2.....
49 comments
The annotations say "... I don't have the exact instruction format for the either the LGP-30 or RPC-4000 ..." but the entire manual for the LGP-30 with this information, and way more, is available at http://www.bitsavers.org/pdf/royalPrecision/LGP-30/LGP-30_Op...
In 1973, Mr. Willoughby taught the Abington (Pennsylvania) High School computer programming class to code in LGP-30 assembly language. We didn't actually have an LGP-30; it just happened to be what he had been taught on when he was young. All assignments were graded by him simulating your code in his head. Of course, we then went on to learn the (slightly) higher-level NEAT/3 language, for which the school actually had an NCR Century-100 mainframe that would run programs that we submitted on punch cards. Mr. Willoughby's (nobody knew teachers' first names back in the day) theory was that it was important to learn the lowest-level machine language first, so you could understand what was really going on underneath. Worked fine for me; evidently it's not quite so universal anymore.
In 1973, Mr. Willoughby taught the Abington (Pennsylvania) High School computer programming class to code in LGP-30 assembly language. We didn't actually have an LGP-30; it just happened to be what he had been taught on when he was young. All assignments were graded by him simulating your code in his head. Of course, we then went on to learn the (slightly) higher-level NEAT/3 language, for which the school actually had an NCR Century-100 mainframe that would run programs that we submitted on punch cards. Mr. Willoughby's (nobody knew teachers' first names back in the day) theory was that it was important to learn the lowest-level machine language first, so you could understand what was really going on underneath. Worked fine for me; evidently it's not quite so universal anymore.
While not universal, I do recommend Charles Petzold's _Code_:
https://www.goodreads.com/book/show/44882.Code
which covers things down to a quite low-level and was recently updated:
https://www.amazon.com/Code-Language-Computer-Hardware-Softw...
https://www.goodreads.com/book/show/44882.Code
which covers things down to a quite low-level and was recently updated:
https://www.amazon.com/Code-Language-Computer-Hardware-Softw...
I think going as far as assembly up front is probably not worth it, also it's hard to keep people engaged at that level as it's difficult to make the computer do exciting things with assembler.
However I strongly believe it's good to start with C. You can still rather quickly do interesting stuff, C is a small language so learning the language itself isn't a huge barrier.
A big benefit of the small language is that it leaves more time available to explore important concepts, not just the super low level ones (memory/pointers, etc) but really important parts of the stack that are infectious to everything else. Specifically things like syscalls and the libc interface that most other languages are essentially built on top of. Working with building blocks like pthreads directly is also very important IMO, both to get a handle on parallelism and concurrency primitives but also to learn why high level languages are so valuable. Similarly for stuff like important socket APIs ala select/epoll and implementing your own event loop.
I was lucky enough to learn all of this early in my career and luckier still to have been able to pass on this knowledge to many mentees over the years.
If there are any aspiring programmers here that want to build from a solid foundation then yeah, ignore the haters, write some C.
man pages and ironically ChatGPT are your friend, use them to explore the foundations of (most) modern code so when you start writing modern code in earnest/for money you will be substantially ahead of your peers in actual understanding.
However I strongly believe it's good to start with C. You can still rather quickly do interesting stuff, C is a small language so learning the language itself isn't a huge barrier.
A big benefit of the small language is that it leaves more time available to explore important concepts, not just the super low level ones (memory/pointers, etc) but really important parts of the stack that are infectious to everything else. Specifically things like syscalls and the libc interface that most other languages are essentially built on top of. Working with building blocks like pthreads directly is also very important IMO, both to get a handle on parallelism and concurrency primitives but also to learn why high level languages are so valuable. Similarly for stuff like important socket APIs ala select/epoll and implementing your own event loop.
I was lucky enough to learn all of this early in my career and luckier still to have been able to pass on this knowledge to many mentees over the years.
If there are any aspiring programmers here that want to build from a solid foundation then yeah, ignore the haters, write some C.
man pages and ironically ChatGPT are your friend, use them to explore the foundations of (most) modern code so when you start writing modern code in earnest/for money you will be substantially ahead of your peers in actual understanding.
No, go down to assembler, just pick a smaller machine like a microcontroller where simpler programs can do more things more easily.
When you know assembler you can always see what compiled programs run as no matter what language that program was written in, if you start with C you won't have that ability.
When you know assembler you can always see what compiled programs run as no matter what language that program was written in, if you start with C you won't have that ability.
Assembler is much better approach, one gets to learn how the machines actually work (ignoring the microcoded part), and reach for something like a 8/16 bit computer emulator (ZX, C64, NES), or an Arduino like device with ARM/RISC-V.
Also the realization, C isn't that special, plenty of ways to play around with pointers.
Also the realization, C isn't that special, plenty of ways to play around with pointers.
If it makes you feel any better as of 2005 or so Pitt's computer science degree still includes learning assembly language and the particular Turtle-Headed Sadist that teaches it at the Johnstown branch campus won't let you use hex opcodes for the first few weeks of the course so you're literally coding in unadorned 1s and 0s. I hated him for it. I hate him for it. But nothing compares to the dopamine pop I had when figured out how to do long division using only addition, subtraction, conditionals and jumps. Not that that's a groundbreakingly difficult problem, it was just one of my favorite "aha!" moments in my entire career.
In the story it says:
> The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located
Is this correct? The manual you have seems to have a diagram with a +1 operation on the "counter register", which loops back down.
All instructions seem to use a memory address, but they use this for doing the instruction thing (adding, subtracting etc).
Maybe I'm just not understanding the format.
> The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located
Is this correct? The manual you have seems to have a diagram with a +1 operation on the "counter register", which loops back down.
All instructions seem to use a memory address, but they use this for doing the instruction thing (adding, subtracting etc).
Maybe I'm just not understanding the format.
The RPC-4000 (the "big brother" of the LGP-30) had each instruction specify the next instruction address. I believe this was to allow for optimizing your program such that the next instruction would always be right under a read head on the drum when the processor was ready for it, because if you missed it, it took a whole revolution of the drum to get back to it (kind of like a cache miss).
In any case, it seems that while Mel wrote lots of code for the LGP-30, the actual hack in the story involved code that Mel was porting from LGP-30 to RPC-4000.
In any case, it seems that while Mel wrote lots of code for the LGP-30, the actual hack in the story involved code that Mel was porting from LGP-30 to RPC-4000.
Sounds familiar. One of my first classes as an undergrad started with boolean logic and boolean gates, then IIRC (it's been a minute) assembly for a theoretical processor.
I had a class (in the late 90s/00s) where we had to code to a theoretical RISCish CPU, but the teacher had built a simulator for it which allowed you to inspect registries, flags, execute instructions step by step etc
It was quite entertaining.
It was quite entertaining.
Same here. We used LMC [1] before we moved to a real architecture.
[1] https://en.wikipedia.org/wiki/Little_Man_Computer
[1] https://en.wikipedia.org/wiki/Little_Man_Computer
On my case, on digital circuits lectures we did the whole thing, starting with boolean logic, gates implementation, using stuff like SPICE, eventually we designed our own toy CPU, the actual implementation on a breadboard was left as an optional exercise, which on my year I think no one did.
David of the Usagi Electric youtube channel received an LGP-21 computer (not Mel's LGP-30) a while ago which will become a future channel project. But along with it, he received a binder of LGP-30 code... with a bunch of programs written by Mel himself!
Apparently, Mel worked for Librascope for quite a while and wrote a lot of stuff. Mel's code is supposedly somewhat better commented and less cryptic than he is usually credited for (though from what I've heard self-modifying code on the LGP-30 was a somewhat intended feature). Whether or not that applies to Mel's blackjack program is probably anyone's guess. A paper tape dump of it is known to be out there, but I don't think the source code is.
The idea is to study some of those programs and maybe port a few to understand how the LGP-21 works (they are supposed to be similar), since so far I don't think much documentation on the LGP-21 has been found.
Apparently, Mel worked for Librascope for quite a while and wrote a lot of stuff. Mel's code is supposedly somewhat better commented and less cryptic than he is usually credited for (though from what I've heard self-modifying code on the LGP-30 was a somewhat intended feature). Whether or not that applies to Mel's blackjack program is probably anyone's guess. A paper tape dump of it is known to be out there, but I don't think the source code is.
The idea is to study some of those programs and maybe port a few to understand how the LGP-21 works (they are supposed to be similar), since so far I don't think much documentation on the LGP-21 has been found.
The very excellent "Advent of Computing" computer history podcasts had an episode involving The Story of Mel relatively recently: https://podcasts.apple.com/us/podcast/acting-up/id1459202600...
It provides a lot of context, and puts things into perspective.
Note that it helps to be familiar with The Story of Mel before listening to that episode. I think the podcast may have explained The Store of Mel itself in a previous episode that I haven't listened to yet, but I was personally familiar with it already through the usual folklore.
It provides a lot of context, and puts things into perspective.
Note that it helps to be familiar with The Story of Mel before listening to that episode. I think the podcast may have explained The Store of Mel itself in a previous episode that I haven't listened to yet, but I was personally familiar with it already through the usual folklore.
Mel was discussed in episode 114 (https://podcasts.apple.com/us/podcast/the-lgp-30-a-forgotten...), and there was a special episode which included a reading of the story (https://podcasts.apple.com/us/podcast/reading-the-story-of-m...). The machine also pops up from time to time when the host discusses "personal computers", which he has a very interesting definition of!
A bit of trivia I like to bring up when this comes around: those "hexadecimal numbers"? The digits would've gone 0-9fgjkqw.
After he finished his vacuum tube computer, the UE-1, I got hooked on the Usagi Electric channel on YouTube.
One of the things he did was restore a Bendix G-15.
It seems to use 0-9quvwxyz.
Does anyone know how/when they were standardize to what we have today?
One of the things he did was restore a Bendix G-15.
It seems to use 0-9quvwxyz.
Does anyone know how/when they were standardize to what we have today?
Seemingly not before the late 70s, at least—tar and cpio encode their numbers as octal(!) numerals.
There are many things that we take for granted today that weren't decided upon in the early days of computing, like the byte being 8-bits (which was popularized by the System/360) or word sizes being 2^(3+n). Some early machines were bit-serial (imagine an adder operating on one bit at a time, rather than on all of the bits in parallel). Even more fun: the Harvard Mark I and ENIAC were both base-10 machines. I can't imagine the amount of engineering that went into producing a base-10 machine out of inherently base-2 components. (Example: the relays of the Mark I. Tubes are analog, but I'm guessing that any use in computers would only use a high and a low state.) Many machines used sequentially accessed main memory rather than random access memory (the drum memory of the LGP-30 or mercury delay-lines). The list goes on.
The Kenbak 1 was serial.
https://www.kenbak.com/kenbak_registry
You can buy a replica one now (I've bought 2).
https://adwaterandstir.com/product/nanokenbak-1/
https://www.kenbak.com/kenbak_registry
You can buy a replica one now (I've bought 2).
https://adwaterandstir.com/product/nanokenbak-1/
The ENIAC components were (or at least some of them were) decimal. Things like tube decade-counters were combined into a computer. They picked components available off the shelf and cobbled it into a computer. I believe such counters were used in stuff like frequency counters before they were used in ENIAC.
Octal has advantages to be more readable when you are dealing with bits in groups of threes (or multiples), just like the decimal is advantageous when dealing with bits in groups of fours (or multiples).
In UNIX-like systems (and POSIX in general), POSIX permissions are in groups of threes: rwx for user, group, and others. Hence `chmod 777` means "rwx for user, group, others" (i.e. everyone can do everything), `chmod 0644` means "rw for user, r for group and others", and so on.
Before we standardize on 8 bit bytes, there were all kinds of word sizes. Some machines had 18 bit words, for example. 18 is divisible by 3, but not by 4, so octal made more sense for those at least.
In UNIX-like systems (and POSIX in general), POSIX permissions are in groups of threes: rwx for user, group, and others. Hence `chmod 777` means "rwx for user, group, others" (i.e. everyone can do everything), `chmod 0644` means "rw for user, r for group and others", and so on.
Before we standardize on 8 bit bytes, there were all kinds of word sizes. Some machines had 18 bit words, for example. 18 is divisible by 3, but not by 4, so octal made more sense for those at least.
I learned octal before hex. The Univac 1100/80 was my first machine. It was 36 bit words, and had circuitry to process multiple data sizes; 6, 9, 12, 18 bit. Octal made perfect sense.
http://bitsavers.informatik.uni-stuttgart.de/pdf/univac/1100...
>FIXED-POINT OPERANDS: One 36-bit single precision word. Addition and subtraction can also be performed upon 2-word (72-bit) double precision operands and upon 18-bit half-words and 12-bit third-words; the leftmost bit holds the sign in each case. Moreover, partial words of 6,9, 12, or 18 bits can be transferred into and out of the arithmetic and control registers. The 11 00/80 can also perform decimal addition and subtraction operations on 9-bit bytes, packed 4 to a word.
http://bitsavers.informatik.uni-stuttgart.de/pdf/univac/1100...
>FIXED-POINT OPERANDS: One 36-bit single precision word. Addition and subtraction can also be performed upon 2-word (72-bit) double precision operands and upon 18-bit half-words and 12-bit third-words; the leftmost bit holds the sign in each case. Moreover, partial words of 6,9, 12, or 18 bits can be transferred into and out of the arithmetic and control registers. The 11 00/80 can also perform decimal addition and subtraction operations on 9-bit bytes, packed 4 to a word.
Oops, "the decimal" in my answer should read "hexadecimal", obviously. (Too late to edit.)
I’ve noticed octal is common on front panels of computers, seemingly much more than nibbles.
It's interesting.
My first idea was that you consciously or subconsciously have the front panels from PDPs in mind (which are very iconic), and a lot of PDP had word sizes that were either only or also divisible by 3 (like 12 or 18). Even for the PDP word sizes that were also divisible by 4, it still made sense to keep it in grouping of threes for the overall line.
Looking at the equally iconic IBM s/360 front panel (a 32 bit architecture), or the IMSAI 8080 (the Intel 8080 is 8 bit), you see the bits grouped by fours.
But then you have things like the Altair 8800, which is also 8080-based, and which awkwardly groups the bits in groups of 3 anyway, which does not even fit. So now I wonder how common exactly octal was even for multiple-of-4 bit machines.
My first idea was that you consciously or subconsciously have the front panels from PDPs in mind (which are very iconic), and a lot of PDP had word sizes that were either only or also divisible by 3 (like 12 or 18). Even for the PDP word sizes that were also divisible by 4, it still made sense to keep it in grouping of threes for the overall line.
Looking at the equally iconic IBM s/360 front panel (a 32 bit architecture), or the IMSAI 8080 (the Intel 8080 is 8 bit), you see the bits grouped by fours.
But then you have things like the Altair 8800, which is also 8080-based, and which awkwardly groups the bits in groups of 3 anyway, which does not even fit. So now I wonder how common exactly octal was even for multiple-of-4 bit machines.
There's that old chestnut about how the x86 instruction format -- at least up to the 486 -- is easily hand-assembled in octal [1], and that this may be have been the legacy of a design decision made for the Datapoint 2200. [2]
[1] https://news.ycombinator.com/item?id=30409100 [2] https://en.wikipedia.org/wiki/Datapoint_2200
[1] https://news.ycombinator.com/item?id=30409100 [2] https://en.wikipedia.org/wiki/Datapoint_2200
The Altair is probably the one I’m thinking of besides PDP series. Because I too remember that weird extra bit standing out.
I’m pretty sure that’s due to Unix’s early existence on PDP machines from DEC, which used octal instead of hex for encoding binary values. Why DEC did that I don’t know - I never got a chance to use DEC equipment back in the 70s.
Several PDPs used 18 bit word sizes (we standardized on 8 bit bytes and multiples for word sizes later on). 18 is not divisible by 4, but it is divisible by 3. An octal digit groups three bits together, just like a hexadecimal digit groups 4 bits together.
It's been a while since we had a Mel thread. (It's good for the classics to reappear from time to time, especially for newer cohorts of users.)
Related past discussions—others?
94 years ago today – Hacker legend Mel Kaye was born - https://news.ycombinator.com/item?id=42695655 - Jan 2025 (1 comment)
The Story of Mel (1983) - https://news.ycombinator.com/item?id=38981958 - Jan 2024 (2 comments)
The Story of Mel (1983) - https://news.ycombinator.com/item?id=37131315 - Aug 2023 (4 comments)
Mel Kaye – CV - https://news.ycombinator.com/item?id=36188537 - June 2023 (2 comments)
Show HN: We found the grave of hacking legend Mel Kaye - https://news.ycombinator.com/item?id=36031476 - May 2023 (2 comments)
Show HN: 40th Anniversary – Who are you, Mel Kaye? - https://news.ycombinator.com/item?id=36019424 - May 2023 (4 comments)
LGP-30 found in basement, the same model of drum computer programmed by “Mel” - https://news.ycombinator.com/item?id=33514399 - Nov 2022 (53 comments)
Mel's Hack – The Missing Bits - https://news.ycombinator.com/item?id=33392127 - Oct 2022 (48 comments)
The Story of Mel (1983) - https://news.ycombinator.com/item?id=32395589 - Aug 2022 (167 comments)
Mel's Loop – A Comprehensive Guide to The Story of Mel - https://news.ycombinator.com/item?id=31458048 - May 2022 (2 comments)
The Story of Mel (1983) - https://news.ycombinator.com/item?id=20671031 - Aug 2019 (3 comments)
https://news.ycombinator.com/item?id=20489273 (July 2019 - classic comment by YeGoblynQueenne)
LGP-30 – A Drum Computer of Significance - https://news.ycombinator.com/item?id=20484330 - July 2019 (39 comments)
A Real Programmer: The Story of Mel (1983) - https://news.ycombinator.com/item?id=19283255 - March 2019 (2 comments)
The Story of Mel, a Real Programmer (1983) - https://news.ycombinator.com/item?id=11820569 - June 2016 (4 comments)
The Story of Mel Explained - https://news.ycombinator.com/item?id=9913835 - July 2015 (25 comments)
The Story of Mel (1983) - https://news.ycombinator.com/item?id=9017099 - Feb 2015 (8 comments)
The Story Of Mel - https://news.ycombinator.com/item?id=7869771 - June 2014 (77 comments)
A picture of Mel Kaye (the Real Programmer) [pdf] - https://news.ycombinator.com/item?id=3110883 - Oct 2011 (5 comments)
Mel the programmer was a real person - https://news.ycombinator.com/item?id=1155322 - Feb 2010 (16 comments)
The story of Mel (1983) - https://news.ycombinator.com/item?id=678999 - June 2009 (22 comments)
The story of Mel, a Real Programmer - https://news.ycombinator.com/item?id=181144 - May 2008 (9 comments)
Related past discussions—others?
94 years ago today – Hacker legend Mel Kaye was born - https://news.ycombinator.com/item?id=42695655 - Jan 2025 (1 comment)
The Story of Mel (1983) - https://news.ycombinator.com/item?id=38981958 - Jan 2024 (2 comments)
The Story of Mel (1983) - https://news.ycombinator.com/item?id=37131315 - Aug 2023 (4 comments)
Mel Kaye – CV - https://news.ycombinator.com/item?id=36188537 - June 2023 (2 comments)
Show HN: We found the grave of hacking legend Mel Kaye - https://news.ycombinator.com/item?id=36031476 - May 2023 (2 comments)
Show HN: 40th Anniversary – Who are you, Mel Kaye? - https://news.ycombinator.com/item?id=36019424 - May 2023 (4 comments)
LGP-30 found in basement, the same model of drum computer programmed by “Mel” - https://news.ycombinator.com/item?id=33514399 - Nov 2022 (53 comments)
Mel's Hack – The Missing Bits - https://news.ycombinator.com/item?id=33392127 - Oct 2022 (48 comments)
The Story of Mel (1983) - https://news.ycombinator.com/item?id=32395589 - Aug 2022 (167 comments)
Mel's Loop – A Comprehensive Guide to The Story of Mel - https://news.ycombinator.com/item?id=31458048 - May 2022 (2 comments)
The Story of Mel (1983) - https://news.ycombinator.com/item?id=20671031 - Aug 2019 (3 comments)
https://news.ycombinator.com/item?id=20489273 (July 2019 - classic comment by YeGoblynQueenne)
LGP-30 – A Drum Computer of Significance - https://news.ycombinator.com/item?id=20484330 - July 2019 (39 comments)
A Real Programmer: The Story of Mel (1983) - https://news.ycombinator.com/item?id=19283255 - March 2019 (2 comments)
The Story of Mel, a Real Programmer (1983) - https://news.ycombinator.com/item?id=11820569 - June 2016 (4 comments)
The Story of Mel Explained - https://news.ycombinator.com/item?id=9913835 - July 2015 (25 comments)
The Story of Mel (1983) - https://news.ycombinator.com/item?id=9017099 - Feb 2015 (8 comments)
The Story Of Mel - https://news.ycombinator.com/item?id=7869771 - June 2014 (77 comments)
A picture of Mel Kaye (the Real Programmer) [pdf] - https://news.ycombinator.com/item?id=3110883 - Oct 2011 (5 comments)
Mel the programmer was a real person - https://news.ycombinator.com/item?id=1155322 - Feb 2010 (16 comments)
The story of Mel (1983) - https://news.ycombinator.com/item?id=678999 - June 2009 (22 comments)
The story of Mel, a Real Programmer - https://news.ycombinator.com/item?id=181144 - May 2008 (9 comments)
My first HN post: https://news.ycombinator.com/item?id=3110883
"A picture of Mel Kaye (the Real Programmer) [pdf]"
"A picture of Mel Kaye (the Real Programmer) [pdf]"
Added above. Thanks!
[deleted]
It’s almost time for someone to annotate these 1996 annotations to explain “hard disks” and “floppy disks.”
This version combines the annotations and the text:
https://jamesseibel.com/the-story-of-mel/
https://jamesseibel.com/the-story-of-mel/
what a fantastic read
Very cool, those annotations!
Are there any photos of 'drum memory'?
Are there any photos of 'drum memory'?
There are videos: https://www.youtube.com/watch?v=-iRE2wlZ3pg
Awesome, those were hardcore engineers.
Thanks!
Oh yeah, i've met enough of these Mel dudes, who refuse to adapt and won't touch ai productivity tools because it's not real programming to them. Guess who is deploying his third app this week ;)
The old, poster-sized machinist's tooling chart on the wall in our shop has a great quote at the bottom: "Nobody will remember how long it took to do the job, but they will remember how well you did it."
To be fair... not on an LGP-30, you didn't.
when I first read this story out of the back end of the jargon file in the 90s it felt like Deuteronomy for internet people. It still does.
The Story of Mel is all you need?
If only hyperlinks were a thing...
Possibly this edition predates the web. The page has 1996 on it but could well have been created before then.
I've replaced the submitted URL (https://users.cs.utah.edu/~elb/folklore/mel-annotated/mel-an...) with the Story part, and added the Annotations part to the top text. Maybe that'll help.
I've replaced the submitted URL (https://users.cs.utah.edu/~elb/folklore/mel-annotated/mel-an...) with the Story part, and added the Annotations part to the top text. Maybe that'll help.
From the "About this Document" page (https://users.cs.utah.edu/~elb/folklore/mel-annotated/node3....)
About this document ...
The Story of Mel, A Real Programmer, Annotated
This document was generated using the LaTeX2HTML translator Version 95.1 (Fri Jan 20 1995) Copyright © 1993, 1994, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were: latex2html mel-annotated.tex.
The translation was initiated by Erik Brunvand on Tue Oct 15 13:41:12 MDT 1996
About this document ...
The Story of Mel, A Real Programmer, Annotated
This document was generated using the LaTeX2HTML translator Version 95.1 (Fri Jan 20 1995) Copyright © 1993, 1994, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were: latex2html mel-annotated.tex.
The translation was initiated by Erik Brunvand on Tue Oct 15 13:41:12 MDT 1996
[deleted]