In the summer of 1982 I had a job working at Bell & Howell's headquarters. At the time, B&H was Apple's "in" to schools. The B&H flavor of the Apple II (1) had a black case and (2) had some extra A/V jacks on the back. No school had a budget for computers, but most had a budget for A/V equipment. B&H also had a nationwide service organization that frequented schools, due to B&H selling lots of projectors to them.
Anyway, I used a B&H Apple II to automate some accounting tasks for one department. At lunch I would eat quickly then work on the Apple II exploring it's capabilities -- simple graphics programs, etc. I ended up writing a sector editor, then used TASC to compile it to make it useful. I recall uploading the program to a BBS when I was done, as I had no personal use for it.
My pay was $5/hour, but I burned up $5/day in gas money and $5/day for food, so really I was making $30/day.
I graduated HS and went off to college, and a few times I got calls asking me to debug something or add a feature. I had the listings with me, but it would result in a painful process verbally telling a non-programmer how to edit the program. There was no ability to dial in, so it was a purely verbal process.
"3990 Old Town Avenue, San Diego" is permanently burned into my brain. I was finally in that neighborhood about 10 years ago and visited the shrine myself, even though any evidence of the company there is long gone now.
Applesoft II fit in 10 kilobytes of rom and had to be able to run in as little as 4 kilobytes of ram. The one thing that Microsoft was an expert at (in that era) was sacrificing features to fit.
There was no special version for machines with more ram or with a floppy disk.
> But it seems odd that they wouldn't at least save a LUT relating the shortened and expanded variable name.
BASIC implementations based on Microsoft BASIC store tokenized program lines. A keyword takes 1 byte. Comments, variable names, spaces between tokens, etc take up memory on a character-by-character basis.
I didn't use Apple BASIC, but I spent too much time on various flavors of Commodore BASIC which shared this heritage. Changing a variable from "ACCUMULATOR" to "AC" to "A" saved memory and made the program run faster. The problem of not being able to make sense of your own program after was very real.
There was a weird thing in IBM BASICA (which apparently became GW-BASIC) where runtime writes to a pointer to a program variable could corrupt your program listing itself. I think this had to do with variable contents actually being stored inside the source code somehow? Do you know any more about this, or does anyone else remember this?
>I’m confused about deleting comments and renaming variables unless TASC itself written in Applesoft. Which seems crazy.
The article doesn't ever explicitly say so but, yes, Chen expects the reader to understand from his words that TASC was written in Applesoft BASIC. Crazy, indeed!
I’m pretty amazed it was self hosting. I’m sure it was faster to iterate that way but it seems like it would be so much more efficient to use assembly. Kilobytes were so precious.
Maybe it didn’t matter as much since it was a compiler and not a runtime environment.
A tangential story about renaming variables to save memory...
Back in the early 2000s, I worked at EA on Madden Football. I was working on a project to replace the old system Madden used for the game's UI (HUD, menu screens, etc.) with a new one based on Flash. A very smart engineer out of EAC in Vancouver wrote a custom ActionScript bytecode VM that could run on consoles and I was integrating it into Madden's game engine.
I was a lowly tools and UI engineer. In EA's culture back then, that placed me near the bottom just above QA on the prestige totem pole. One of the lead engineers on Madden wanted to talk to me about how much memory the new UI system was using.
I explained that part of it was that we needed RAM for all the variable names. He looked at me like I was an absolute idiot and condescendingly explained that compilers for programming languages don't keep the name of the variable around. The name is just used to identify a storage location and you only need memory at runtime for the value. He may or may not have hinted that this was something I was expected to understand if I ever wanted to become a senior engineer like he was.
So I sat down at his computer and tapped out this bit of ActionScript and ran it in our VM:
var someVariable = "its value";
var some = "some";
var variable = "Variable";
trace(eval(some + variable)); // Prints "its value".
Here, it's dynamically computing a string, which is then used used to look up the value of a local variable by that computed string name. In order for this to work, every variable name must be kept around in memory.
The look of confusion and anger on his face was priceless.
(You might rightly wonder why in the hell EA picked a dynamically-typed scripting language with eval() that required keeping variable names around in memory for consoles that were incredibly resource constrained. The answer was that they struggled to hire UI artists who were willing to use the previous weird proprietary tools. They figured if they moved to Flash, they could hire Flash artists. Also, it meant they didn't have to maintain a custom UI editing tool.)
On a side note, early Microsoft’s business strategy seems to be licensing half-baked software written by independent programmers and then making a product out of it.
They did that for years, just not as much these days. Visual Basic was an outside product/demo developed by Alan Cooper. The infamous Visual Source Safe [0] was originally sold by One Tree Software in Raleigh (the word "Visual" was added by Microsoft)
[0] Microsoft's own source control product that it replaced was Microsoft Delta. Believe it or not, Source Safe was a major improvement over Delta.
To my knowledge, Applesoft BASIC would have been written by Microsoft with some modifications done by Apple. On top of that, it is likely that TASC made calls directly to the BASIC ROM. Reimplementing bits of BASIC would have used already scarce RAM. Licensing probably made the most sense in this case since little (if any) of the original BASIC code would have been of value and it offered the developer the opportunity to sell their software without publishing it themselves or maintaining the software if they found someone to publish it.
Was quite an interesting article, enjoyed it. But I must be daft, because I don't understand how the title relates to the article. From the title, I had assumed that the source code to TASC had somehow been recently recovered.
I suppose the title means that they have the source code physically, just no one can understand it, because the author had to remove all comments and shorten all variable names to one character so that the code would fit into the RAM.
I searched but I couldn't find out who this author is/was. Lines like "The author of TASC was very proud of this optimization." makes me think that Raymond Chen is the author, is this right?
I tried this compiler out back in the day and found the benefits, at least with the AppleSoft programs I had access to (mostly MECC titles) were fairly negligible. What rarely popped up, however, were show-stopper errors — programs would compile & run. That was nice.
>I tried this compiler out back in the day and found the benefits, at least with the AppleSoft programs I had access to (mostly MECC titles) were fairly negligible.
I suppose that a compiler wouldn't do much to make something like the original BASIC The Oregon Trail feel much faster; I think the sailing-on-a-raft part wasn't added until the 1985 version, which likely was not written in Applesoft.
>What rarely popped up, however, were show-stopper errors — programs would compile & run. That was nice.
Beyond being itself written in Applesoft BASIC as I noted elsewhere, TASC's coverage of BASIC keywords is almost entirely complete, going by chapter 7 of the manual. Any given Applesoft program has a very high chance of successfully compiling out of the box, and the very few differences with the interpreted language can be easily worked around (if the `DIM` command is any indication). As one used to aftermarket compilers that only support subsets of the language, TASC's comprehensiveness is very, very impressive.
The article doesn't ever explicitly say so, but Chen expects the reader to understand from his words that TASC was written in Applesoft BASIC!
Further, TASC's coverage of BASIC keywords is almost entirely complete, going by chapter 7 of the manual. Any given Applesoft program has a very high chance of successfully compiling out of the box, and the very few differences with the interpreted language can be easily worked around (if the `DIM` command is any indication). As one used to aftermarket compilers that only support subsets of the language, TASC's comprehensiveness is very, very impressive.
Yes the article does mention that TASC was written Applesoft
> Even if you hadn’t made it that deep into the manual, you could have figured out that TASC was used to compile itself because TASC used its own runtime library.
In the summer of 1982 I had a job working at Bell & Howell's headquarters. At the time, B&H was Apple's "in" to schools. The B&H flavor of the Apple II (1) had a black case and (2) had some extra A/V jacks on the back. No school had a budget for computers, but most had a budget for A/V equipment. B&H also had a nationwide service organization that frequented schools, due to B&H selling lots of projectors to them.
Anyway, I used a B&H Apple II to automate some accounting tasks for one department. At lunch I would eat quickly then work on the Apple II exploring it's capabilities -- simple graphics programs, etc. I ended up writing a sector editor, then used TASC to compile it to make it useful. I recall uploading the program to a BBS when I was done, as I had no personal use for it.
My pay was $5/hour, but I burned up $5/day in gas money and $5/day for food, so really I was making $30/day.
I graduated HS and went off to college, and a few times I got calls asking me to debug something or add a feature. I had the listings with me, but it would result in a painful process verbally telling a non-programmer how to edit the program. There was no ability to dial in, so it was a purely verbal process.