BASIC Was the People’s Language
An update on the 1970s Sphere computer history work, including an essay on BASIC and a technical dive into Microsoft BASIC on Sphere.
Hi, I’m Ben, the fellow working on 1970s Sphere Corporation computer history. This update starts with some administrivia, offers an essay about the BASIC programming language, and concludes with a deep technical dive into porting Microsoft BASIC to Sphere in 2024.
Why are you here?
If you got this by email, it's because you signed up on my site at sphere.computer at some point for updates on the book or about the computers. If you're reading on the web, you may have seen one of my YouTube videos, or attended a talk I gave, or visited our booth at the Vintage Computer Festival West.
What should you expect?
The research and writing for the book have been fruitful and if you subscribe here you will be the first to know when it is imminent! But I also wanted to share some of the work (both historical and technical) along the way.
To recap: The Sphere was an early microcomputer out of Utah, launched in 1975 by Sphere Corporation and based around the Motorola 6800. The company was gone by 1977, and left only a faint trace in the record for many reasons. But the computers and company were more interesting than their obscurity suggests.
I'll say more in future updates about research explorations. But I wanted to use this very first one to talk about the origins and longevity of the BASIC programming language, and its importance in early microcomputing. This touches on Sphere, but is a broader story. For the courageous, there’a also a technical description afterwards about porting Microsoft BASIC to Sphere today. I hope you enjoy. Please feel free to let me know your thoughts.
BASIC Was the People’s Language
I've been thinking a lot lately about BASIC, the simple computer language that was absolutely everywhere in the 1970s and 1980s and then largely disappeared. From the perspective of a modern computer programmer, it's strange that early microcomputers tended to have just two way of programming them: assembly language—the lowest possible level of coding—or BASIC, so absurdly abstract that it barely has any structure at all. In retrospect that seems crazy: if you weren't willing to write raw assembly, then the other option was the thing they taught to children! And indeed there were plenty of very complex pieces of software well into the 1980s that were done entirely in BASIC for this reason.
But the reason that BASIC was the lingua franca of microcomputers for so long makes sense once you understand its origins, as well as the environment in which the first microcomputers emerged.
BASIC came out of the Dartmouth Computer Science department in the 1960s, and was both designed and evangelized as a instroductory programming language. BASIC is an acronym for Beginners' All-Purpose Symbolic Instructional Code. At the time it was invented, mainframe systems were programmed in assembly (direct machine language), or something involved like FORTRAN, which was a compiled language for mathematic and scientific computing. Both of these required specialized training and were suited to specialized tasks. BASIC offered a simpler way in to computing, and long before an individual was able to own a computer, a computing advocate named Bob Albrecht was tirelessly spreading BASIC’s gospel outside academia. Digital Equipment Corporation (DEC) published Albrecht's popular "My Computer Likes Me When I Speak in BASIC" book in 1972. That same year he opened his People's Computer Company storefront in Menlo Park, California, where they offered minicomputer access on terminals. Kids paid less than adults for computer time. The kids played games, and they learned BASIC.
By the start of the early micro era (1975-77), from which Sphere emerged, there was therefore a computing culture already primed to want BASIC on these fledgling little computer systems. But the hardware was just incredibly limited at first. When you purchased a MITS Altair 8800, or indeed a Sphere, you were expected to create your own software for it, but you were expected to do that directly in assembly language using pencil and paper to work out your program's code before laboriously entering it into the system. The computer itself might have had just 256 bytes of memory (Altair)—barely enough for a tiny machine program, let alone a BASIC environment.
The BASIC that Bob Albrecht was teaching came from DEC or Hewlett-Packard and was easy to learn but also quite sophisticated, and there was no way the first micros could mimic its full capabilities. But with just a bit more space to move around in, some version of BASIC would be within reach, and there was a powerful incentive to make these blinking boxes more useful. The first out of the gate was a remarkable and lasting effort: Bill Gates and Paul Allen—Harvard undergraduates at the time—sold a very good BASIC to Albuquerque's MITS for their Altair 8800. It required 4 kilobytes of memory to load, leaving less than 800 bytes for user programs. But it was a very capable miniaturized version of the DEC-style standard. It also of course marked the beginnings of Microsoft.
Four kilobytes was a costly memory upgrade for an Altair, however, and MITS also charged at least $75 for a copy of the software (far more if you didn’t own an Altair). Bill Gates famously aggravated the early hobbyist community by railing against free sharing of his software. In response, Bob Albrecht kicked off a grassroots effort within the People's Computer Company and its newsletter to create a "Tiny BASIC" that would be cheap or free, and ideally could run on a more limited computer. Stanford professor Dennis Allison was credited with creating the overall "design," while computer-specific implementations were left to others to contribute. It was an early forerunner of a collaborative open source project. The resulting BASICs were indeed tiny—allowing only a few variables, no loops, no strings, no floating-point math. But suddenly, you could write programs for your new computer without a deep understanding of how the CPU itself worked. This was revolutionary.
Different flavors of BASIC proliferated across all the various microcomputers. Through the crucial early micro era, as the cost of memory quickly fell, 4K and 8K and eventually 16K BASICs showed up, offering increasingly sophisticated feature sets and enabling complex software to be created on ever-more-capable home computers.
Back in 1975, Sphere computers shipped with 4K of system memory on day one. That was unusual, and was made possible by the use of dynamic RAM (DRAM) technology—a freshly commercialized form of low-cost memory chip that required a more complex circuit design to make work. Sphere Corp opted for this tradeoff, so even though their users had a useful mini-assembler built in, the system was already ripe for a simple BASIC. Customers wanted it.
Unfortunately, Sphere didn't have it yet. As MITS had done, Sphere contracted out a BASIC for their machine. The contractor abandoned the project before it was complete, leaving the company scrambling to piece something together in-house. As a result, it took well into 1976 for Sphere to ship a BASIC. Once they did, customers discovered it was difficult to use, required an expanded 20K of memory to load—and was unusably slow. Meanwhile, because the Sphere was based on a different CPU than the MITS Altair—the Motorola 6800 vs. the Intel 8080—eager users could not even "bootleg" a version of the Gates and Allen software to get it working on their systems.
Sphere users were left to work with what ultimately became available for the 6800. Engineer Tom Pittman wrote the most popular Tiny BASIC for the 6800 computers, which he sold on paper punch tape for $5, by mail. Tiny BASIC worked fine on the minimal Sphere configuration. Southwest Technical Products published hobbyist Robert Uiterwyk's BASIC on cassette in 1976, meant for users of their SWTPC 6800 computer. Uiterwyk's BASIC was frequently purchased (or shared) and modified to run on the Sphere. Later, Technical Systems Consultants (TSC), Computerware Software Services (CSS), and Programma International all published sophisticated BASICs that saw regular use on Sphere machines, the last of these being Sphere-native.
The one BASIC that never found a toehold in the Sphere community was, oddly, the Microsoft one. MITS launched their own 6800-based computer, the Altair 680, and by mid 1976 Microsoft's Ric Weiland had taken Gates and Allen's original code and ported it to the new hardware. Later, Microsoft licensed an adaptation of that code (as updated by Mark Chamberlin) to a company called GRT Corporation, which sold it under the name "G/2 Standard BASIC" for the SWTPC 6800. The "G/2" user manual included specific instructions for how to customize it for other computer systems, which made it a good fit for Sphere. There is no evidence that anyone did this in the 1970s, so I'm happy to inform you that at this late date, your author has done it.
Here is Microsoft's BASIC running on a Sphere:
Ta-da! This required some contortions to get working because the way I/O is handled on the Sphere is very different than on the SWTPC (or any other early micro for that matter). All the gory details of how this adaptation had to be set up are below, in the guaranteed-fun section “Engineer’s Corner.”
But in any case, you can try it out for yourself on the Virtual Sphere! Press the "Start BASIC" button in the header, and it will do all the correct loading sequence for you. Then just hit enter for MEMORY SIZE and TERMINAL WIDTH and anything you want for trigonometry, and then you’ll get dropped at a standard BASIC prompt. Have fun!
But for now, back to BASIC on microcomputers. In 1976 Steve Wozniak designed one of the first computers based around MOS Technology's new (and more affordable) 6502 processor. This was the Apple Computer, a.k.a. the Apple 1, the first product for the company he formed with Steve Jobs. Wozniak understood the importance of BASIC for the viability of a microcomputer, and he set about writing his own: "It needed a BASIC, there was no other choice." Part of what motivated him was the knowledge that no one else had created a BASIC for the new 6502 yet, and he wanted to be known as the first to have done it. It took a grueling four months of work—it was more difficult for him than the hardware design had been—but the result, distributed on cassette, was excellent. Wozniak's BASIC crushed all the other microcomputer BASICs, including the MITS/Microsoft gold standard, in performance benchmark tests run by Kilobaud magazine a year later. It ranked second in speed only to a Control Data Corporation mainframe.
Apple BASIC had two drawbacks, however: one technical and one of usability. Wozniak didn't support floating-point numbers (decimal values), and could operate only with integers (whole numbers). This simplified his code, but anything with nontrivial mathematics—science, accounting, and some kinds of games—were off-limits to users. Secondly, Wozniak's day job was at Hewlett-Packard, so he had naturally turned to H-P's own minicomputer BASIC manuals to understand how the language worked as he was designing it. Unfortunately, Wozniak was unaware until later that H-P's dialect of the language was quite different from the DEC-derived syntax that Microsoft (and most others) had implemented. It could take some effort to convert "standard" programs to work with Apple BASIC.
These issues proved fatal, and Apple's "Integer BASIC" survived only long enough to be shipped with the very first Apple II computers at their launch in 1977. It was quickly replaced by a licensed version of Microsoft's BASIC tailored to the new Apple, dubbed "Applesoft." In fact, 1977 turned out to be a watershed year for microcomputers, and with them, BASIC. The launch of the so-called "1977 trinity"—the Apple II, Radio Shack's TRS-80, and Commodore's PET—heralded the arrival of home computers. These were the first computers sold complete, at retail, fully assembled, and encased. Unlike the Altair, the SWTPC and even Sphere, these were affordably priced and could be used right out of the box by someone with no particular electronics knowledge. The customers weren't hobbyists or tinkerers; they were families and schools. The wild success of these computer lines secured the hegemony of BASIC: all three included a full version of BASIC pre-programmed in the computer's read-only memory. When a user turned the computer on, there was BASIC, ready to go! And it wasn't a scruffy "tiny" version, but a fully capable programming environment.
Where the most successful early micros sold thousands of units, the new wave of home computers ultimately sold millions. Every one of them started up to BASIC—and most used a licensed Microsoft BASIC. That was clearly great for Bill Gates—Microsoft’s revenues passed a million dollars by 1978–but also meant a common dialect for kids and others to learn to program with. The descendants and competitors of these original home computers, domestically and around the world, mostly all started up to BASIC. Many people remember carefully typing in BASIC game listings from magazines. Elementary schools had lessons in BASIC in their math classes. A cottage industry of developer aids—debuggers, compilers, line renumberers—sprung up around BASIC.
Other programming languages became usable on PCs soon enough, and were quickly adopted for professional work, finally splitting the difference between the grind of assembly language and the sandbox of BASIC. But nothing really challenged the universal access to, and educational usefulness of, BASIC in home computing until the Graphical User Interface (GUI) era took hold in the late 1980s and beyond. Without a text-based command line environment as the default computing experience, BASIC finally began to fade from computing culture.
But why aren't we still using some derivative of BASIC today to teach programming to young people? I'm not sure what the answer to that is. My good friend, who works in modern youth computer science education, thinks it was just too primitive: “It taught such bad habits, especially with line numbers, that you had to actively unlearn it.” There's something to that, I think. In addition to the syntax, the environment is dated: unlike on the computers of late 1970s and 80s, where a BASIC program could access most of the capacity of the computer it was running on, today's computers aren't well suited to that sort of simple text control and imperative structure. Without any professional usefulness, BASIC seems a toy, even as a pedagogical tool. Perhaps Javascript is the closest modern heir—you can open the console of your browser right now and start typing in expressions to manipulate web UI, the portal to all modern computing.
Engineer's Corner!
The project of adapting Microsoft’s BASIC to the Sphere was assisted by specific patch locations in the documentation but made complicated by the fact that Sphere has a very different I/O architecture than similar microcomputers.
Pretty much every microcomputer launched prior to 1977 used a serial terminal for programs to communicate with the outside world. This was true of the Altairs (once you expanded beyond lights and switches), as well as the SWTPC, the IMSAI, and all the little ones you’ve never heard of—even the Apple 1 was internally organized like this. From the perspective of software, input was a series of characters and output was a series of characters; where those characters came from and went to—a Teletype unit, a CRT terminal like an ADM-3A or Hazeltine, or anything else—was up to the user, who had to plug something in.
The Sphere was different, which is both good and bad. It used “memory-mapped video” before any other integrated system. The “screen” is backed by a 512-byte range of RAM, all of which can be accessed directly by the CPU like any other memory. Whatever the contents of those memory addresses are, is what the Sphere’s screen will display. So cursor management, scrolling of the screen, carriage returns– all of these must be handled by software, and those routines conveniently reside in the built-in PDS (Program Development System) standard ROM.
So the first thought for a Microsoft BASIC adaptation is: OK, we can just patch the BASIC’s output to Sphere’s PUTCHR routine, and its input to GETCHR, and we should be good to go, right?
Unfortunately, no. The Sphere PDS ROM keeps its own variable storage in the direct page of memory (the first 256 bytes, ie, addresses that start with $00xx). These locations are special, and the CPU instructions that access this range are both shorter and more efficient, which is why the PDS keeps state there. The PDS also generally keeps its stack in the next page ($01xx).
The problem with this is that Microsoft BASIC is designed to be loaded directly at (and run from) address $0000, and keeps its own variables, state and code in the direct page and beyond. That conflicts with the PDS storage, which is therefore incompatible–we cannot have the firmware stomping all over the BASIC running state as it tracks the cursor updating the screen!
To remain compatible with the standard firmware, we need to write a small driver for the console I/O. Instead of patching BASIC to point to the PDS routines, we can replicate the needed functionality in a small chunk of code that lives in memory alongside BASIC, does the right stuff with the screen text, but also knows to not interfere with low memory.
That code is not difficult to write or very lengthy, but we need to figure out where to put it and how to load it, and then we come to another problem: When BASIC starts up, it likes to occupy all available memory to use for program storage (makes sense), starting from the end of its own code. So we’ll place our driver at the top of user memory. Because a “standard” Sphere system had 20K of memory, I put the drivers at $4E00. That way BASIC can use everything up to the start of the driver code. (How does it know to stop there, though? We’ll get to that in a moment.)
So we have BASIC, which is one big binary chunk, and a console driver, which is another smaller binary chunk, and they sit very far from each other in memory. Because Sphere cassettes don’t permit the loading of “sparse” binary programs, we will store these as two separate blocks on the cassette: the small driver first (loading at $4E00), and then the actual original BASIC (loading at $0000), and then we can run the original BASIC once we manually load both.
Actually, no, we can’t. The problem is that we (the user) have to use the interactive PDS commands to load the cassette blocks. Recall that the PDS routines use low memory. So the act of loading the BASIC will already result in corrupted memory! Yikes.
The solution here is to combine our drivers with a custom loader. The loader code can use the PDS routines to load the BASIC itself, but intentionally placing it at a different (higher) memory address. That ensures that the load can complete safely. Only then, when there is no longer a need for the firmware routines, the loader can shift the code down to its correct location at $0000.
Because we are using this loader idea, we can also take that opportunity (after shifting BASIC to its final location) to patch the I/O routines in it. The software engineer in me finds it satisfying to load a “stock” BASIC binary without any modifications, and only apply the patches at runtime. So that’s how the console hooks get patched, and repointed to the driver routines that appear within the loader/driver above $4E00.
I took the opportunity to add a few more useful patches. Remember how BASIC wouldn’t necessarily know to stop using memory above $4E00? When it starts up, it asks the user “MEMORY SIZE?” and if you just hit Enter, it will use all of memory. I instead patch BASIC such that if you just hit Enter, it will quietly know to stop before the driver code. Similarly, BASIC will ask for “TERMINAL SIZE?” and its default is 80 columns (which was very common in video terminals). But the Sphere screen is much more cramped, at 32 columns, so that’s now the default if you just hit Enter. No sense in making it difficult to have a good user experience!
And speaking of user experience, I ended up adding some gentle special logic in the driver for the backspace key, so the cursor will be sure to move backwards when deleting characters as a user would expect.
Finally, we need to do something about CSAVE and CLOAD. These are the crucial BASIC commands that save and load to cassette—that’s how you get programs in and out without constantly retyping them. Normally we might hook up these routines to the Sphere firmware cassette routines, but once again we have a direct page problem. Just as during the initial load, we cannot use the built-in cassette routines without corrupting BASIC’s state. So we need to replicate that functionality within our driver as well. Fortunately, this is quite simple. The cassette presents a standard ACIA interface on the serial board, and BASIC writes out its own cassette file metadata and doesn’t need the extra folderol of Sphere’s block format.
So that’s essentially the whole adaptation: We have a small loader/driver that loads as usual from cassette into address $4E00. Once loaded, we jump to that address and the loader takes over: it looks for the full BASIC block next on tape, loads it at a safe address, moves it to its real address, patches the console and cassette I/O routines to point to the routines that are in the loader/driver, and then makes some usefulness patches for memory and terminal size. Then it jumps directly to address $0000, and BASIC, none the wiser, takes off from there.
The commented loader/driver assembly code that does all the above work can be found here if you're interested. A complete bundle including final cassette files, and the manual for BASIC can all be downloaded from the Resources area. As mentioned above, the Virtual Sphere can run this whole operation for you, simply click “Start BASIC” in the header, and it will trigger the loading process without having to learn any PDS incantations at all, and then you can try your 20 GOTO 10 print program for kicks. Enjoy!
Selected Sources:
A People's History of Computing in the United States, Joy Lisi Rankin, 2018.
iWoz: Computer Geek to Cult Icon: How I Invented the Personal Computer, Co-Founded Apple, and Had Fun Doing It, Steve Wozniak, 2006.
Founders At Work: Stories of Startups' Early Days, Jessica Livingstone, 2008.
Hard Drive: Bill Gates and the Making of the Microsoft Empire, James Wallace & Jim Erickson, 1993
Engines of the Mind: The evolution of the computer from mainframes to microprocessors, Joel Shurkin, 1996.
Various magazines and newsletters, 1975-76.
You can always reach me at bzotto@gmail.com. The main site for this project is at https://sphere.computer. All text is copyrighted by Ben Zotto.