Yet another Hacker News

How did Woz write the Apple 1 BASIC before building the computer?

62 points Skyfall106 2 hours ago 22 comments

WillAdams 1 hour ago | parent

For the sequel to this, see:

https://www.folklore.org/MacBasic.html

femto 1 hour ago | parent

What Woz did was the default way of writing assembly language programs for owners of 8-bit computers (mostly hobbyists). You didn't have money for a second machine, so you wrote your program on paper, you entered it then tested it in situ. Mostly you got it right, as doing it on paper was slow and meant you had the opportunity to put lots of thought into it. 8-bit instruction sets were simple enough that you eventually learned the most common instructions by heart. There was a point where I could mostly translate a Z80 program from assembly to machine code from (my) memory.

Maybe that is part of the nostalgia for the 8-bit days: the practice of "slow programming"? It was relaxing, sort of like those "slow tv" shows.

abecedarius 1 hour ago | parent

There was a #hexcoders channel on IRC back in the 90s, admittedly very dead, and not just because octal is better for x86 code.

MarkusWandel 56 minutes ago | parent

My first exposure was Commodore PET computers at the high school (I'm old). Nobody had home computers then, this stuff was crazy expensive, even a floppy disk (singular!) to save your work on the shared drive (on a dolly - it could be hotplugged) was >$20 in today's money. But what you could use all you want was the line printer (a CBM 2022) and its consumables. So at the end of whatever computer room time you could scrounge (lunch, who needs lunch?) you'd print off your 3-4 page epic program to continue coding and debugging with a pencil, on the long school bus ride. This does form "slow" habits. To this day I detest autocomplete, autoindent, syntax highlighters and the like. Never did hand assemble though.

billforsternz 46 minutes ago | parent

Yes. My first serious program was done this way. At the start of the project (final year of EE degree, 1981) I didn't really understand what a program was, but I learned by studying the technical reference manual for the Intel 8085 CPU. It kind of seemed like magic, I can mold the functionality by storing codes in memory? Wow!

I figured out exactly what I wanted to do, wrote it out very carefully on paper, looked up all the hex codes, wrote those out very carefully, adjusted addresses etc. as needed. This took many hours spread over weeks. Then I entered the whole thing on the hex keyboard and display of a primitive development board each time I needed it, perhaps an hour or so each time (I think I only did it twice). It worked first time, because why wouldn't it if you were sufficiently meticulous about your work in a process that was very obviously very intolerant of the tiniest mistake?

I must admit my program (gather input information from some transducers, do some calculations, present some results) was likely somewhere between one and two orders of magnitude simpler than a complete Basic interpreter!

tverbeure 35 minutes ago | parent

I got my first computer, a C64, when I was 14 in 1985, and wrote my 6510 assembly in paper as well.

You had to carefully calculate the address distance for a branch instruction. The release of DISMON was a revolution: suddenly the computer did all of that for you. It even supported moving pieces of code to a different address to make space for inserting more instructions somewhere!

ashleyn 33 minutes ago | parent

How exactly did you "enter it" without a second computer though? Was there a simple test rig or something that you would make as an electronics project, where you would input opcodes and ascii and it would write it to a rom? Only real thing i can think of.

AnimalMuppet 23 minutes ago | parent

Front panel switches?

asdefghyk 21 minutes ago | parent

RE "...How exactly did you "enter it" without a second computer though...."

You would use the "monitor program" to poke hex data into memory locations, starting at a nominated RAM memory address. Needed to be done VERY CAREFULLY. one bad hex digit and your program likely crash. After entering all the program into memory, you would use a monitor program , command to get tell the CPU to jump to a certain address and start executing a program there. OLD computer magazines often had such hex listings printed in them.

holgerschurig 10 minutes ago | parent

Can't tell it for 6502... but for Z80. Because was my first own "computer":

* a single Z80 (which was nicer than 8080, because the latter needed an extra clock IC) * 256 bytes of static RAM * 1 8bit D-Latch (Flipflop) with 8 LEDs * 1 8bit D-Latch with 8 dip switches * 2 8bit buffers that can go tristrate between the hex-thingies and the address & data bus * 2 rotating hex thingies: you could rotate them between 0-f for data * 2 rotating hex ones for address

Now, how did it work? I pulled nBUSRQ down (bus request). This made the Z80 go tri-state. It also made my buffers non-tristate.

Then I used 2 of the hex-thingies to set the address and 2 of them to set the data. Now I set nWR to low and that would write the entered data byte into the SRAM.

When I was done, I turned nBUSRQ back to high, so the Z80 again was the boss of the bus. And then I simply used nRESET to low to make the Z80 execute my program starting at address 0.

I did only tiny programs, like adder, some PWN/sound wave program, an traffic light simulator.

But, since I soldered this all by myself, I had no "monitor program" like the KIM-1 had. So I had to do all of that by hardware.

sowbug 7 minutes ago | parent

The Apple II had a thing called the monitor, which was a tiny CLI program in ROM that you could invoke from the BASIC command line (CALL -151). With it you got the ability to disassemble memory (300L would spit out 6502 opcodes starting at address 768), set memory regions to sequences of hex digits (300: A9 21 20 FO FD 60 would write a tiny program on an Apple II Plus that printed an exclamation point, if my memory serves), and execute memory (300G).

With these three commands, and a working memory of the hex that corresponded to the opcodes, you could be reasonably productive writing short 6502 programs.

Fun and extremely niche fact: the typo CALL -161 jumped into the monitor, but only after the weird side effect of unhooking the sniffer that watched for DOS 3.3 commands sent via the ROM's text I/O. Not only did this make text print faster -- useful when you were visually dumping memory to the screen to find something quickly, but it also protected against accidentally destroying your disk if you unwittingly printed a sequence like ^M^DINIT HELLO, which would trigger the disk initialization routine.

wernam 22 minutes ago | parent

You can observe the same behavior from modern LLMs, when working on firmware or closed library and they need to fix or bypass a small thing, sometimes they just directly modify the binary without any disassembler. At least the Chinese non de-cybered LLMs.

fasterik 16 minutes ago | parent

I was born too late for that era of computing, but I've spent enough time programming that I can easily "run" a program in my head and reason about how it works, find bugs, etc. I would imagine that muscle was even more developed for the people who had to do it out of necessity, though.

david-gpu 1 hour ago | parent

I only had to assemble instructions by hand three times in my career. It is not difficult if you are already familiar with the ISA of that particular processor, but it is tedious.

The first time was in my first job writing OpenGL ES 2.0 blending operations for the Imagination Technologies SGX 535, which was a remarkably advanced little GPU for its time. Alpha blending happened through special instructions in the fragment/pixel shader. We did have a compiler, but it didn't handle blending, for whatever reason.

Through testing I noticed that NVidia GPUs performed blending incorrectly, according to the specification, which was a big surprise. Only years later I figured out that the specification had some errors; I now would bet that NVidia was doing the correct thing.

The second time I had to assemble instructions by hand happened while working on a stripped down version of the Radeon 7xxx series that shipped on some mobile phones. I don't recall what the problem was, whether we were adding a feature or optimizing the microcode generated for a particular OpenGL operation, but it involved a rarely-used feature called user-defined clipping planes. We didn't have an assembler for that GPU; all microcode was assembled by hand.

The third time happened at NVidia, and I will be vague, as not enough time has passed for me to be comfortable going into any detail. I had an idea for how to provide hardware acceleration for persistent CUDA kernels, which eventually was marketed as Cluster Launch Control (CLC). In order to quantify the benefit of adding some hardware, when it was possible to approximate that functionality in software, I needed to test the most efficient software implementation that was possible, and the compiler wasn't quite giving the assembly I wanted, so I had to manually patch some instructions post-compilation. Why did I not use the assembler that was available? I couldn't, because the assembly language did not provide a way to express the exact feature I had to patch.

johndubchak 43 minutes ago | parent

I was such a nerd, happily learning 6802 assembly on the II+...those were the days...I miss it.

wewewedxfgdf 47 minutes ago | parent

It's taken me more than 40 years to learn a fraction of a % of what Woz knew in 1975.

asdefghyk 37 minutes ago | parent

I would say bit by bit, I mean "small part" and then keep making small extensions to the program(s)

First for new hardware would be a monitor program. Either write one, or port one from other hardware. A monitor program allows the inspection and edit of memory data and also to run programs in such memory. The monitor program often placed in ROM for convenance. A 6502 cross assembler, could be used to avoid the need for hand assembly the program to 6502 machine code.

Probably where WOZMON came from.

Then using WOZMON start writing a VERY simple basic interpreter.

Maybe the monitor program was borrowed from other hardware that used a 6502 ( would need slight mods for the Apple 1 ) NOTE This is just a possibility - I actually have NO idea I suspect WOZ would have invented his own in any case ...

(OFF TOPIC - I messed around with a 68008 chip in mid 1980s?? and I recall I found a book with a complete montor program in for this chip - I can not recall the name of the book. )

iberator 26 minutes ago | parent

It's easy to relearn those skills:

Just design and build a virtual CPU architecture in the language of your choice:) (not verilog but php, c, rust, zig or whatever)

You create architecture, then OPCODES, then you can write simple programs in machine code.

Then its SUPER EASY to write an assembler and disassembler.

Then forth compiler.

I did it all once as I was homeless on my phone in the mall .

Fun and educational, even if you don't know assembly prior.

heisenbit 20 minutes ago | parent

Did he really write the BASIC before he wrote the monitor program which sits at the top of the address space? The monitor was documented as part of the systems manual of the Apple ][ and contained a small disassembler which helped a lot when coding some instructions or jumps wrong. I learned a lot from that code.

Grimeton 11 minutes ago | parent

>How did Woz write the Apple 1 BASIC before building the computer?

Time travel!

mrandish 7 minutes ago | parent

I got my first computer in 1981, a 4K Radio Shack Color Computer for $500 (a huge purchase decision at the time). So I missed hand assembling for bare metal and Altair-type toggles.

However, there was an interesting period of a few years where assembler tools were either unavailable or fairly expensive, so it was common to use the computer's BASIC to write an assembly language monitor program. Such program listings were pretty common in early hobbyist 'zines. It was also pretty common to use BASIC to POKE in a quick bootstrap program to load a value in a register and jump to an address, which I could usually do from memory. After 40 years I still remember the 6809 RTS was $39 and NOP was $12, two very handy instructions to POKE a quick mod into a program.