For what it’s worth: when I used to do assembly on the commodore 64, after a while, your eyes are so used to seeing A9 close to LDA let you start knowing them by heart without even thinking. Of course this is possible on 6502 and will be way harder on modern CPUs. In the end of the number of common opcodes might have been 30-50, and you can always look up the rest from a one-page table.
I remember that was a book that went on to say that you should learn machine code (that is, raw opcodes), not assembly, to program the c-64. Not sure I would agree, but it’s definitely feasible.
The only thing that is strange in the Woz story is that you would usually start by creating a dirt-poor monitor/assembler so that he would have a sane environment to do further development in. That was the approach manuals from the era suggested for new hardware (eg Rodnay Zack’s)
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.
I find it amusing that so many of the comments were surprised about hand-assembling 6502 code. When I came to the Apple ][, assemblers were relatively more accessible, but even at around $200, it was well beyond my financial means so I would write code longhand in spiral bound graph paper notebooks in four columns: Addresses, labels, hex codes (up to three bytes per opcode) and then the assembly code.
And that $200 being out of bounds went pretty low: for the first couple years of my programming life, floppy disks were beyond my means, so any code I wrote lived in its official version as hand-written code and would have to be retyped any time I wanted it.
I was 4yo when I re-typed my first program from Atari manual to my Atari 800xl and was baffled that I had to retype it after restarting the computer. I tried saving it to a cassette tape but that didn’t work well. I envied my cousins who had their Atari with 5 inch floppy drive.
Mmm. It's tempting. And I did write plenty of basic on paper in detention when I was young; that exercise certainly did force me to think in unusual ways.
But I think I'll stick to my LLMs and the fond memories of spending a few evenings sussing out resolute performance from an RP2040 PIO's whole-several assembly instructions. :)
Kids these days... that's exactly how I wrote code, the 6502 was simple enough that you quickly memorized all the opcodes (A9 07 20 ED FD ...), and you sketched it out on paper and desk-checked it before typing it in... which you did by banging rocks together to get ones and zeros. Ay, we had it tough, but you know, we were happy in those days.
I once worked worked with a guy who had himself done 6502 assembler, for CompuServe[1], in their home base of Columbus. Good dude; I wish I'd chatted with him more.
He wasn't happy about the position he was in while we were chatting, except it paid some bills and it provided good health insurance.
For comparison, I never learned any 6502.
But we both answered the phones the same way in that call center, and both we worked to give callers the best troubleshooting advice we could, given our understanding and ability to control that system.
My local teenager Apple crowd could get you almost any game, or disk copy utility, or etc. But never an assembler or complied Basic, or Apple Pascal or anything like that. I was insufficiently 1335.
Anyway, my career in writing 6502 machine code in pencil pretty much ended at "Hello World".
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!
I think this comment is gold. Thanks for writing this. It feels like such a visceral description of the experience of "programming" back then. I've read a bunch of old books on programming or those that explain low level programming, but they mostly detailed the mechanics of programming, it feels like your comment captured something of the actual experience of it!
The days when I would remember everyone's telephone numbers AND Z80 instructions!
10 FOR N=0 TO 28
20 READ B: POKE 32768+N,B
30 NEXT N
40 RANDOMIZE USR 32768
50 DATA 62,2,205,1,22,17,16,128
60 DATA 1,13,0,205,60,32,24,245
70 DATA 73,32,65,77,32,65,87,69
80 DATA 83,79,77,69,13
It's a little scary that I can recognize a lot of those instructions from memory, even though it's been 40 years since I first got my ZX Spectrum.
Of course more recently I've been doing a lot of z80-based CP/M retro-fun. But "62, xx" is obviously LD A,xx, and similarly the 205 is CD which is CALL.
Fun stuf, thanks for the post, you are indeed AWESOME.
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!
That's how I learned to program. I didn't have access to computer as a kid, so I read books, wrote programs on paper and when I got access to a computer I would type in the program and see if it worked. I now have an abundance of computers at home. What a weird timeline all in all.
Since I learned to write machine code this way, I'll add a little bit of color.
You can take the instruction set of a simple microprocessor, and lay out its instruction set in a tabular format. This made it relatively easy to see the correspondence between an instruction in assembly language and its numerical code.
Handy "reference cards" were published for looking up the codes, printed on nice thick plastic. You can find these in a google image search for your favorite micro. I got by with a photocopy. Along with that, a programmer would have their own notes and diagrams taped to the walls for quick reference. Machines were simple enough that you really could have all of the vital information available at a glance.
Today, the "datasheet" for a sophisticated 32 bit microcontroller is many thousands of pages.
Microprocessors had relatively few transistors by today's standards, so the instruction decode logic had to be simple. Logical, if I may say so. This resulted in being able to describe operators and their operands as blocks of bits in an instruction word.
I arrived late enough in the game that personal computers already existed, yet I got myself started by hand assembling for the microprocessor circuits that I brought up from scratch.
Long before 8-bit computers, I had 15 minutes of access every Saturday to an IBM 1620, so I had a week to write (and erase) code (initially FORTRAN II, later 1620 ASM) before getting anywhere near the computer. When I got to the machine room I had to punch the code on cards using an IBM 026 card punch. For my larger FORTRAN programs, it took most of the 15 minutes to compile them and punch an object deck, which I couldn't run until the next week.
1) In the Saturday morning programming class that I attended just to get the computer time, an experienced student had a card deck and a brand new student asked to see it, and the former unfortunately agreed. The new student had no idea that the order mattered and scattered them all over his desk.
2) I rode a Honda 90 over Beverly Glen to attend UCLA. One morning I had a 300 card PL/1 program bungied onto the back of the motorcycle. The car in front of me slammed on its brakes when the signal turned at Beverly Glen and Sunset, I rear-ended them, and my deck went flying all over the road.
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.
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.
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.
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.
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^M, which would trigger the disk initialization routine.
> 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.
Ancient assembly hacker tip: A JSR/RTS sequence can be simplified to a JMP. To continue your example, the bytes you provided decompile as follows (assuming Apple 2 monitor ROM at $F800):
So, you load the A register with #$21, which is the ASCII code for `!` in hexadecimal, and then call COUT1 which will output the character in the A register, printing the exclamation point. When COUT1 is finished, it will return to you using an RTS instruction, and then you'll return to your caller using another RTS instruction.
Since the call to COUT1 is a tail call, you can borrow its RTS instruction to return to your caller and save one instruction. So the following code is equivalent to yours but a little bit smaller and faster:
PRINTBANG:
A9 21 LDA #$21
4C F0 FD JMP COUT1
Notice that the JSR instruction has become a JMP.
Another related trick: When you have a routine that callers often want to call twice—say to print `!!` for extreme exclamations—you may be tempted to create a do-it-twice call:
But we can do even better! We can eliminate the jump and save three more bytes by placing our do-it-twice routine immediately before the routine it is calling:
When PRINTBANG2 is called, it calls PRINTBANG to print an exclamation point, but when PRINTBANG returns, it returns to PRINTBANG2, which promplty falls through to PRINTBANG, calling it again and printing a second exclamation point. This time, however, when PRINTBANG returns, it will return to the original caller.
Back when every byte mattered, these tricks were useful to know.
There was also a mini-assembler [0] that let you enter assembly code directly into memory. It was dead simple to use, and since it printed an assembly listing after you entered each instruction, it was conducive to learning the hex codes by heart.
The mini-assembler didn't understand symbols (other than the opcodes themselves), but it did understand the addressing modes. This saved you from, for instance, hand calculating branch offsets.
Not all Apple II models included it, but I can't find a reference right now. Ours had it.
I haven't seen that in a long time! Young me was too young to understand 2s complement arithmetic, or that addresses would wrap around. I just thought it was some kind of magic.
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.
For later hardware like the TRS-80, the BASIC interpreter had an escape hatch: PEEK(addr), POKE addr, value, and USR1(). Basically you could read and write single bytes to RAM, and there was a magic 2-byte value which was a branch address that calling USR1() would jump into. So you could bootstrap some simple tooling that way. (I'd been writing hex machine code before I got any hardware, just pencil and graph paper, so it wasn't a big step to go from that to stuffing bytes into memory.) Of course there were tools available but actually paying for them was enough of a challenge that a lot of bootstrapping got done entirely anti-economically :-) (Once floppy drives and disk operating systems were a thing, you'd usually have a simple debugger where you could just type hex digits in, and load register values directly - so if you wanted to read raw disk sectors, you'd drop CD 75 46 18 FB somewhere, R DE track/sector, R HL where to read, R BC 0001 and then single step the code and it would read a single sector.)
(Note that while a lot of this was unjustifiable even then - my first real paying job in computers was down a step, working on a Z80-modded IMSAI so while most code was on 8" floppies, doing machine code in binary on toggle switches "just to fix something quick" was a legitimate skill :-)
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.
In case of Wozniak, he had access to a commercial programmer at work.
Some people did burn the code into electrically programmable PROMs completely by hand, using just a power supply, some wires and switches. Anyone could do this at home, but it was extremely tedious even for a tiny 256 byte chip.
And then manually translate all those opcodes into values that code be entered as DATA into a BASIC, with a tiny loader segmnent and RANDOMIZE USR to jump into executing it.
Kids these days don't know how good they have it, even when playing around with an ESP32.
I don’t know about other people, but back in the early 80s, I spent a lot of time writing code (mostly assembler, some BASIC and other dead languages) with pencil on paper for various reasons: sometimes I preferred it, sometimes I was writing code for computers I only had access to in labs or at school.
There were even pre-made paper forms for writing code, like the IBM COBOL program sheets and similar for assembler.
Even now, if I’m working on a tough issue, I still print out code sections on paper and hash it out with a pencil.
We did that at school. We would hand write Fortran code on sheets and send it off somewhere. A week to two later we would get the results back. I seem to remember most of the mistakes were when the operator entered the code.
Yup. All the way up to my second year of college ('85), I'd very carefully plan and write code by hand -- either in BASIC or 6502 assembly -- edit it and "test" it on paper, all so when I got a period at school or 15 minutes for $0.25 at the local library I could make the most of the time at the keyboard.
I will never forget the thrill of keying in a moderately-sized program I'd hand-coded -- a few hundred lines probably -- running it, fixing one or two typos, and then having the program just work. I'm sure they had bugs, but the fact was all that hand-coding effort paid off as programs that ran successfully on the first try.
Just having an assembler - the first and fundamental productivity tool for whatever chunk of hardware it was that you had on your table - was an incredible step upward. That and persistent storage, even if it was Mom & Dad's cassette recorder.
Follow-up question: how did Woz get BASIC into ROM?
The handwritten interpreter is fairly common knowledge since Woz has told that story many times, but I don't recall any accounts of how he bridged the gap from paper to silicon. All of the discussion about the machine language monitor doesn't really address the question. At best, it moves the question from programming a ROM for BASIC to programming a ROM with the machine language monitor. Even with the monitor, additional hardware would be required to program a ROM. At the very least, a latch would be required to hold the address and data. Of course, it is possible that he did it without the computer (using a rig that let him "toggle" the pins). It is also possible that he used another computer to program the ROM, but, as he said, he didn't have the money to program BASIC on a computer so why would that be different for a ROM?
Edit: Actually, I think the Apple I only had the monitor in ROM; Basic was typed in using the monitor, and then saved/loaded using cassette. Apple II put Basic in ROM; the shipping version used mask ROM; maybe they used PROMs in development, although at the time PROMs generally had half the capacity of mask ROMs.
What the Apple II did iirc depended on what version of the ROM. I believe the early versions booted into the monitor, at which point you had to type the magic commands. But they could be upgraded to a "II+" which autostarted the disk or dropped to AppleSoft. (And of course the easiest way to get the facts is to be wrong on the internet :)
Or the magic command to load a program from cassette tape, which was all they had. My later impression is the original Apple II monitor was a horrible UI. So probably most early Apple IIs were upgraded to the "II+" ROM.
Our Apple II+ booted to Applesoft without a floppy disk. I think it automatically tried to boot from the floppy first. I remember that the oldest models booted to the monitor, but don't think I ever saw it myself.
Which is why technically HP would've owned some of the IP for the Apple I. I remember hearing some account in a book where he told jobs "Wait a second; I did some of this at work, I used their equipment, I think my employer owns this." But then they got HP to sign a release that they had no interest in the IP, and then they were all good to start the company and get funding. Bet HP is kicking themselves for signing that release, though.
"Hey, this kid named Steve down in systems has been using one of the PROM burners to work on some hobbyist computer that he and another Steve who doesn't work for us have been working on.
I got a letter from one of them asking if that was OK -- it was just signed Steve."
HP sells more personal computers than Apple, and has for effectively as long as they've competed in the market, overtaking Apple in 1997.
They didn't bother Competing with Apple for nearly two decades, and once they entered the market, they were beating Apple about a year and a half after launch.
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. )
Wow, cool to see the 68008 mentioned here! I actually went through 'The Art of Electronics Student Manual Hayes, Thomas C.; Horowitz, Paul' when I was a teenager in the late 90s and the course included wiring up the 68008 into a breadboard and attaching a keypad to key in hand-assembled hex! That was so fun.
I actually wire wrapped the 68008 chip with some buffer chips on a Apple 2 wire wrapping protoyping board. From recollection (<< probably wrong) the 68008 chip was enormous - about 10cm long and 2cm? wide. Back in the 80s I dreamed of getting the DTACK grounded 68000 board advertised in Byte Magazine ... but it was always "..a bit expensive for me ..."
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.
$XX was a form of hex code notation, used by the 6502 and Motorola processors assembly language. But not universal: in 8080 or Z80 assembly, hex values were denoted by a `H` suffix (this required adding a `0` at the front if the leading digit was in the A-F range to distinguish them from idenitifiers).
Thanks for the answer! Wow, the Assembly from back then seems very different from today's - I'm learning it In uni currently. I'll have to ask my teacher
Since I was entirely self-taught on that first computer with zero prior education and no books other than the included manuals and a 6809 CPU reference card a very kind sales rep at Motorola mailed to me for free, I learned hex representation that way. It actually still seems a bit weird when I see other hex notations. :-)
$nn was a common way to write numeric literals (specifically in hexadecimal, if memory serves) in assembly languages, to differentiate from memory addresses or other uses for values
Ah ok, it does make sense now! Super interesting to read about the devices from back then and the difference from the then-Assembly and the one we use nowadays
I've never "assembled by hand" but I can believe it and imagine it. As a kid I did write basic code by hand and would type it into my Timex Sinclair with no ability to save it because we could not get the tape cassette to work to save it. So for the first few weeks it would all disappear when you turned the computer off. What a blessing it was to get that cassette to work and be able to save and load our programs back! The next thrill was finally getting a disk drive for a later acquired Commodore 64 and ditching the tapes. Not only storage but random disk access what a concept.
Back in the 80s I wrote an assembler and a simulator for a custom DSP before the board was manufactured (it was the 80s so several chips were required), and our team wrote and tested code for it before the board was ready. When the board was ready, we wound up having to modify the assembler and simulator because some control signals were wired backwards and it was easier to just change the instruction coding than to redo the layout. The tools ran on a Vax. Worse, it was Eunice, a Unix-on-top-of-VMS atrocity that we were stuck with because of code that needed VMS and other code that wanted a Unix-like system.
Pen and paper assembly? Kids these days... Try going mental!
Real story: sometime in 80s I was in bed with a nasty flu. Pain-in-the-eyeballs flu, 40°C body temp. Could not read, coult not watch TV, could not stand any light lit near me, radio caused booming in me poor head.
So I started programming, mentally, in BASIC. One of the outcomes of this activity was an algorithm that compressed any text to mere three bytes, but that is another story...
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.
I read a book on C that had this as an excercise; blew my mind at the time. It’s really a great excercise. I created and simulated an equihash machine this way many years ago; back when gpus were used for such thing as crypto mining and not ai!
The 'anlaytical engine' was partialy built, after a successfull smaller prototype, of which some of the original equipment exists, AND a full version has been built now, on the original plans, and after some refinement, works.
Dont know if the Lovelace algorythim has been coded and run through it, but we can be sure that they were on the right track, but operating in close to an absolute vacume, and would have had to fend off acusations of witch craft, idolitry, and the risk of bieng burnt at the stake, or worse.
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.
It's not entirely clear, but not much point in writing a monitor for a computer you haven't even designed yet.
I assume he wrote BASIC first to make sure he knew the computer he was building would be capable of running BASIC. And also not too capable, since the goal was a cheap computer capable of running BASIC.
But, he did write a simple monitor (and burn it into PROM) before actually running BASIC. Just 256 bytes: No disassembler, just the ability to read/modify and execute hex bytes. Before Woz created the tape interface, you had to type BAISC into the monitor as hex every time you powered up the computer.
The part that stuck with me is femto's 'slow programming' line. I never hand-assembled anything, I came up too late for that, but I still write the tricky parts of a program on paper first. Last month it was a little state machine for a game I'm tinkering with. Two pages of boxes and arrows, and I caught three logic errors before I ever opened an editor. I think the paper forced a kind of discipline that's easy to lose now, when the cost of trying something is one keystroke. The flip side is that Woz had to be right before he ran anything, and that's a brutal way to learn. I'm not sure I would trade the fast feedback loop we have now for it, even if the paper habit is worth keeping.
For what it’s worth: when I used to do assembly on the commodore 64, after a while, your eyes are so used to seeing A9 close to LDA let you start knowing them by heart without even thinking. Of course this is possible on 6502 and will be way harder on modern CPUs. In the end of the number of common opcodes might have been 30-50, and you can always look up the rest from a one-page table.
I remember that was a book that went on to say that you should learn machine code (that is, raw opcodes), not assembly, to program the c-64. Not sure I would agree, but it’s definitely feasible.
The only thing that is strange in the Woz story is that you would usually start by creating a dirt-poor monitor/assembler so that he would have a sane environment to do further development in. That was the approach manuals from the era suggested for new hardware (eg Rodnay Zack’s)
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.
I find it amusing that so many of the comments were surprised about hand-assembling 6502 code. When I came to the Apple ][, assemblers were relatively more accessible, but even at around $200, it was well beyond my financial means so I would write code longhand in spiral bound graph paper notebooks in four columns: Addresses, labels, hex codes (up to three bytes per opcode) and then the assembly code.
And that $200 being out of bounds went pretty low: for the first couple years of my programming life, floppy disks were beyond my means, so any code I wrote lived in its official version as hand-written code and would have to be retyped any time I wanted it.
I was 4yo when I re-typed my first program from Atari manual to my Atari 800xl and was baffled that I had to retype it after restarting the computer. I tried saving it to a cassette tape but that didn’t work well. I envied my cousins who had their Atari with 5 inch floppy drive.
A lot of us aren't quite old enough to have ever experienced that echelon of computing.
It’s still available if you want to try it :)
Like blowing into a gourd is still available to a modern saxophonist.
Mmm. It's tempting. And I did write plenty of basic on paper in detention when I was young; that exercise certainly did force me to think in unusual ways.
But I think I'll stick to my LLMs and the fond memories of spending a few evenings sussing out resolute performance from an RP2040 PIO's whole-several assembly instructions. :)
if you play blurays / want to make them region free, you can experience it today (the HDMV bytecode that run the non java parts)
It was fun; you should try it!
Kids these days... that's exactly how I wrote code, the 6502 was simple enough that you quickly memorized all the opcodes (A9 07 20 ED FD ...), and you sketched it out on paper and desk-checked it before typing it in... which you did by banging rocks together to get ones and zeros. Ay, we had it tough, but you know, we were happy in those days.
I once worked worked with a guy who had himself done 6502 assembler, for CompuServe[1], in their home base of Columbus. Good dude; I wish I'd chatted with him more.
He wasn't happy about the position he was in while we were chatting, except it paid some bills and it provided good health insurance.
For comparison, I never learned any 6502.
But we both answered the phones the same way in that call center, and both we worked to give callers the best troubleshooting advice we could, given our understanding and ability to control that system.
[1]: https://en.wikipedia.org/wiki/CompuServe
And honestly assembly consisted of tens of instructions, not hundreds
You could go a long way with mov/jz/jnz etc and basic bios calls
My local teenager Apple crowd could get you almost any game, or disk copy utility, or etc. But never an assembler or complied Basic, or Apple Pascal or anything like that. I was insufficiently 1335.
Anyway, my career in writing 6502 machine code in pencil pretty much ended at "Hello World".
1335? Though to be fair you were very almost 1337...
…and then you accidentally type 'O' instead of '0' when entering it, and it doesn't work.
Using a slashed zero when writing was common for this reason. The BBC Micro even had that instead of unslahsed 0 on its keyboard.
If you even had that button on your keyboard.
Apple 1 users had a keyboard. But its developers may have been using a hex keypad, or an array of toggle switches.
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!
I think this comment is gold. Thanks for writing this. It feels like such a visceral description of the experience of "programming" back then. I've read a bunch of old books on programming or those that explain low level programming, but they mostly detailed the mechanics of programming, it feels like your comment captured something of the actual experience of it!
The days when I would remember everyone's telephone numbers AND Z80 instructions!
It's a little scary that I can recognize a lot of those instructions from memory, even though it's been 40 years since I first got my ZX Spectrum.
Of course more recently I've been doing a lot of z80-based CP/M retro-fun. But "62, xx" is obviously LD A,xx, and similarly the 205 is CD which is CALL.
Fun stuf, thanks for the post, you are indeed AWESOME.
Thanks for posting this snippet, this is exactly what I meant with DATA and small loader section on another comment.
Yep,I did hex data but I still can do z80 like this; assembler does not help as 3e reads and writes faster than ld a,x.
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!
All I had was computer manuals in 1981. I wrote several assembly language programs on paper.
That's how I learned to program. I didn't have access to computer as a kid, so I read books, wrote programs on paper and when I got access to a computer I would type in the program and see if it worked. I now have an abundance of computers at home. What a weird timeline all in all.
Since I learned to write machine code this way, I'll add a little bit of color.
You can take the instruction set of a simple microprocessor, and lay out its instruction set in a tabular format. This made it relatively easy to see the correspondence between an instruction in assembly language and its numerical code.
Handy "reference cards" were published for looking up the codes, printed on nice thick plastic. You can find these in a google image search for your favorite micro. I got by with a photocopy. Along with that, a programmer would have their own notes and diagrams taped to the walls for quick reference. Machines were simple enough that you really could have all of the vital information available at a glance.
Today, the "datasheet" for a sophisticated 32 bit microcontroller is many thousands of pages.
Microprocessors had relatively few transistors by today's standards, so the instruction decode logic had to be simple. Logical, if I may say so. This resulted in being able to describe operators and their operands as blocks of bits in an instruction word.
I arrived late enough in the game that personal computers already existed, yet I got myself started by hand assembling for the microprocessor circuits that I brought up from scratch.
Long before 8-bit computers, I had 15 minutes of access every Saturday to an IBM 1620, so I had a week to write (and erase) code (initially FORTRAN II, later 1620 ASM) before getting anywhere near the computer. When I got to the machine room I had to punch the code on cards using an IBM 026 card punch. For my larger FORTRAN programs, it took most of the 15 minutes to compile them and punch an object deck, which I couldn't run until the next week.
Relevant Simpsons clip: https://youtu.be/UOAdGjj-hIg
Two related anecdotes:
1) In the Saturday morning programming class that I attended just to get the computer time, an experienced student had a card deck and a brand new student asked to see it, and the former unfortunately agreed. The new student had no idea that the order mattered and scattered them all over his desk.
2) I rode a Honda 90 over Beverly Glen to attend UCLA. One morning I had a 300 card PL/1 program bungied onto the back of the motorcycle. The car in front of me slammed on its brakes when the signal turned at Beverly Glen and Sunset, I rear-ended them, and my deck went flying all over the road.
Bill Gates used an emulator, he could tap into the resources of his school, as it had a computer
True, but Paul Allen wrote said emulator.
Impressive. Very nice.
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.
Yep. I've been playing with a KIM-1 lately—modernizing The First Book of KIM.
I've been staring at, fixing up enough 6502 op-codes ands their machine code equivalents that I'm beginning to remember the common ones too.
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.
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.
APL is great for paper coding, or even just coding in your mind on a stroll. (Dito for BQN and other array languages).
There was a #hexcoders channel on IRC back in the 90s, admittedly very dead, and not just because octal is better for x86 code.
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.
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^M, which would trigger the disk initialization routine.
> 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.
Ancient assembly hacker tip: A JSR/RTS sequence can be simplified to a JMP. To continue your example, the bytes you provided decompile as follows (assuming Apple 2 monitor ROM at $F800):
So, you load the A register with #$21, which is the ASCII code for `!` in hexadecimal, and then call COUT1 which will output the character in the A register, printing the exclamation point. When COUT1 is finished, it will return to you using an RTS instruction, and then you'll return to your caller using another RTS instruction.Since the call to COUT1 is a tail call, you can borrow its RTS instruction to return to your caller and save one instruction. So the following code is equivalent to yours but a little bit smaller and faster:
Notice that the JSR instruction has become a JMP.Another related trick: When you have a routine that callers often want to call twice—say to print `!!` for extreme exclamations—you may be tempted to create a do-it-twice call:
But now we know better and code it this way: But we can do even better! We can eliminate the jump and save three more bytes by placing our do-it-twice routine immediately before the routine it is calling: When PRINTBANG2 is called, it calls PRINTBANG to print an exclamation point, but when PRINTBANG returns, it returns to PRINTBANG2, which promplty falls through to PRINTBANG, calling it again and printing a second exclamation point. This time, however, when PRINTBANG returns, it will return to the original caller.Back when every byte mattered, these tricks were useful to know.
I did a ton of assembler programming on the Apple II but for some reason I don't remember the monitor at all.
There was also a mini-assembler [0] that let you enter assembly code directly into memory. It was dead simple to use, and since it printed an assembly listing after you entered each instruction, it was conducive to learning the hex codes by heart.
The mini-assembler didn't understand symbols (other than the opcodes themselves), but it did understand the addressing modes. This saved you from, for instance, hand calculating branch offsets.
Not all Apple II models included it, but I can't find a reference right now. Ours had it.
[0] https://www.callapple.org/vintage-apple-computers/apple-ii/a... (1978)
> CALL -151
I haven't seen that in a long time! Young me was too young to understand 2s complement arithmetic, or that addresses would wrap around. I just thought it was some kind of magic.
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.
For later hardware like the TRS-80, the BASIC interpreter had an escape hatch: PEEK(addr), POKE addr, value, and USR1(). Basically you could read and write single bytes to RAM, and there was a magic 2-byte value which was a branch address that calling USR1() would jump into. So you could bootstrap some simple tooling that way. (I'd been writing hex machine code before I got any hardware, just pencil and graph paper, so it wasn't a big step to go from that to stuffing bytes into memory.) Of course there were tools available but actually paying for them was enough of a challenge that a lot of bootstrapping got done entirely anti-economically :-) (Once floppy drives and disk operating systems were a thing, you'd usually have a simple debugger where you could just type hex digits in, and load register values directly - so if you wanted to read raw disk sectors, you'd drop CD 75 46 18 FB somewhere, R DE track/sector, R HL where to read, R BC 0001 and then single step the code and it would read a single sector.)
(Note that while a lot of this was unjustifiable even then - my first real paying job in computers was down a step, working on a Z80-modded IMSAI so while most code was on 8" floppies, doing machine code in binary on toggle switches "just to fix something quick" was a legitimate skill :-)
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.
In case of Wozniak, he had access to a commercial programmer at work.
Some people did burn the code into electrically programmable PROMs completely by hand, using just a power supply, some wires and switches. Anyone could do this at home, but it was extremely tedious even for a tiny 256 byte chip.
The KIM-1 has a hexadecimal keypad and six 7-segment LEDs.
You go to a start address, switch to data mode, and just start plugging in hex…
Front panel switches?
> so you wrote your program on paper
I guess whiteboard interview technique came from there. Probably rational was - If they can do it, why can’t you?
And then manually translate all those opcodes into values that code be entered as DATA into a BASIC, with a tiny loader segmnent and RANDOMIZE USR to jump into executing it.
Kids these days don't know how good they have it, even when playing around with an ESP32.
I’d read more on what you have to say about this
This is why we forgot how to program long before AI slop :)
I don’t know about other people, but back in the early 80s, I spent a lot of time writing code (mostly assembler, some BASIC and other dead languages) with pencil on paper for various reasons: sometimes I preferred it, sometimes I was writing code for computers I only had access to in labs or at school.
There were even pre-made paper forms for writing code, like the IBM COBOL program sheets and similar for assembler.
Even now, if I’m working on a tough issue, I still print out code sections on paper and hash it out with a pencil.
We did that at school. We would hand write Fortran code on sheets and send it off somewhere. A week to two later we would get the results back. I seem to remember most of the mistakes were when the operator entered the code.
Yup. All the way up to my second year of college ('85), I'd very carefully plan and write code by hand -- either in BASIC or 6502 assembly -- edit it and "test" it on paper, all so when I got a period at school or 15 minutes for $0.25 at the local library I could make the most of the time at the keyboard.
I will never forget the thrill of keying in a moderately-sized program I'd hand-coded -- a few hundred lines probably -- running it, fixing one or two typos, and then having the program just work. I'm sure they had bugs, but the fact was all that hand-coding effort paid off as programs that ran successfully on the first try.
Just having an assembler - the first and fundamental productivity tool for whatever chunk of hardware it was that you had on your table - was an incredible step upward. That and persistent storage, even if it was Mom & Dad's cassette recorder.
Follow-up question: how did Woz get BASIC into ROM?
The handwritten interpreter is fairly common knowledge since Woz has told that story many times, but I don't recall any accounts of how he bridged the gap from paper to silicon. All of the discussion about the machine language monitor doesn't really address the question. At best, it moves the question from programming a ROM for BASIC to programming a ROM with the machine language monitor. Even with the monitor, additional hardware would be required to program a ROM. At the very least, a latch would be required to hold the address and data. Of course, it is possible that he did it without the computer (using a rig that let him "toggle" the pins). It is also possible that he used another computer to program the ROM, but, as he said, he didn't have the money to program BASIC on a computer so why would that be different for a ROM?
> Follow-up question: how did Woz get BASIC into ROM?
See: https://retrocomputing.stackexchange.com/questions/18321/how...
He used equipment at his day job at HP
Edit: Actually, I think the Apple I only had the monitor in ROM; Basic was typed in using the monitor, and then saved/loaded using cassette. Apple II put Basic in ROM; the shipping version used mask ROM; maybe they used PROMs in development, although at the time PROMs generally had half the capacity of mask ROMs.
What the Apple II did iirc depended on what version of the ROM. I believe the early versions booted into the monitor, at which point you had to type the magic commands. But they could be upgraded to a "II+" which autostarted the disk or dropped to AppleSoft. (And of course the easiest way to get the facts is to be wrong on the internet :)
That sounds correct. I'll just add, for clarification, that the magic commands were to switch to Integer BASIC (which was already in ROM).
Or the magic command to load a program from cassette tape, which was all they had. My later impression is the original Apple II monitor was a horrible UI. So probably most early Apple IIs were upgraded to the "II+" ROM.
Our Apple II+ booted to Applesoft without a floppy disk. I think it automatically tried to boot from the floppy first. I remember that the oldest models booted to the monitor, but don't think I ever saw it myself.
Which is why technically HP would've owned some of the IP for the Apple I. I remember hearing some account in a book where he told jobs "Wait a second; I did some of this at work, I used their equipment, I think my employer owns this." But then they got HP to sign a release that they had no interest in the IP, and then they were all good to start the company and get funding. Bet HP is kicking themselves for signing that release, though.
"Hey, this kid named Steve down in systems has been using one of the PROM burners to work on some hobbyist computer that he and another Steve who doesn't work for us have been working on.
I got a letter from one of them asking if that was OK -- it was just signed Steve."
HP sells more personal computers than Apple, and has for effectively as long as they've competed in the market, overtaking Apple in 1997.
They didn't bother Competing with Apple for nearly two decades, and once they entered the market, they were beating Apple about a year and a half after launch.
They never really made much money on it though, for a long time the only thing keeping the company afloat was printer ink.
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. )
Wow, cool to see the 68008 mentioned here! I actually went through 'The Art of Electronics Student Manual Hayes, Thomas C.; Horowitz, Paul' when I was a teenager in the late 90s and the course included wiring up the 68008 into a breadboard and attaching a keypad to key in hand-assembled hex! That was so fun.
I actually wire wrapped the 68008 chip with some buffer chips on a Apple 2 wire wrapping protoyping board. From recollection (<< probably wrong) the 68008 chip was enormous - about 10cm long and 2cm? wide. Back in the 80s I dreamed of getting the DTACK grounded 68000 board advertised in Byte Magazine ... but it was always "..a bit expensive for me ..."
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.
I'm sorry I don't understand - you had to buy instructions?
$XX was a form of hex code notation, used by the 6502 and Motorola processors assembly language. But not universal: in 8080 or Z80 assembly, hex values were denoted by a `H` suffix (this required adding a `0` at the front if the leading digit was in the A-F range to distinguish them from idenitifiers).
Thanks for the answer! Wow, the Assembly from back then seems very different from today's - I'm learning it In uni currently. I'll have to ask my teacher
Here's the reference card I learned assembler from: https://colorcomputerarchive.com/repo/Documents/Datasheets/M...
I still have it in a box, as well as a working sample of the computer in my collection.
Oh, yeah... didn't even think of that. Sorry!
Since I was entirely self-taught on that first computer with zero prior education and no books other than the included manuals and a 6809 CPU reference card a very kind sales rep at Motorola mailed to me for free, I learned hex representation that way. It actually still seems a bit weird when I see other hex notations. :-)
$nn was a common way to write numeric literals (specifically in hexadecimal, if memory serves) in assembly languages, to differentiate from memory addresses or other uses for values
Ah ok, it does make sense now! Super interesting to read about the devices from back then and the difference from the then-Assembly and the one we use nowadays
I'll gladly pay you Tuesday for a NOP today.
I've never "assembled by hand" but I can believe it and imagine it. As a kid I did write basic code by hand and would type it into my Timex Sinclair with no ability to save it because we could not get the tape cassette to work to save it. So for the first few weeks it would all disappear when you turned the computer off. What a blessing it was to get that cassette to work and be able to save and load our programs back! The next thrill was finally getting a disk drive for a later acquired Commodore 64 and ditching the tapes. Not only storage but random disk access what a concept.
Back in the 80s I wrote an assembler and a simulator for a custom DSP before the board was manufactured (it was the 80s so several chips were required), and our team wrote and tested code for it before the board was ready. When the board was ready, we wound up having to modify the assembler and simulator because some control signals were wired backwards and it was easier to just change the instruction coding than to redo the layout. The tools ran on a Vax. Worse, it was Eunice, a Unix-on-top-of-VMS atrocity that we were stuck with because of code that needed VMS and other code that wanted a Unix-like system.
For the sequel to this, see:
https://www.folklore.org/MacBasic.html
And then he wrote SWEET16 which was also amazing. Him and Niklaus Wirth are two people I truly admire; they knew so much and shared so freely.
Same here, Woz is my earliest computing hero.
The source (assembly) code for Woz's SWEET16 is in the Apple II Reference Manual. I learned a lot by working through it back in the day.
Pen and paper assembly? Kids these days... Try going mental!
Real story: sometime in 80s I was in bed with a nasty flu. Pain-in-the-eyeballs flu, 40°C body temp. Could not read, coult not watch TV, could not stand any light lit near me, radio caused booming in me poor head.
So I started programming, mentally, in BASIC. One of the outcomes of this activity was an algorithm that compressed any text to mere three bytes, but that is another story...
“Any text to 3 bytes” - if you mean any length of text, that is not possible
Read carefully: flu, 40°C.
It's taken me more than 40 years to learn a fraction of a % of what Woz knew in 1975.
Same, but you probably learned lots of other stuff too.
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.
I was such a nerd, happily learning 6802 assembly on the II+...those were the days...I miss it.
Control codes had you down? ;)
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.
> Fun and educational, even if you don't know assembly prior.
Any book or resource? How do you do this without assembly?
I read a book on C that had this as an excercise; blew my mind at the time. It’s really a great excercise. I created and simulated an equihash machine this way many years ago; back when gpus were used for such thing as crypto mining and not ai!
Which book?
Ada Lovelace.. wrote the first language before any physical computer.
No, she didn't write a language. She published an algorithm to calculate Bernoulli numbers for Babbage's "Analytical Engine", which he never built.
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.
It's not entirely clear, but not much point in writing a monitor for a computer you haven't even designed yet.
I assume he wrote BASIC first to make sure he knew the computer he was building would be capable of running BASIC. And also not too capable, since the goal was a cheap computer capable of running BASIC.
But, he did write a simple monitor (and burn it into PROM) before actually running BASIC. Just 256 bytes: No disassembler, just the ability to read/modify and execute hex bytes. Before Woz created the tape interface, you had to type BAISC into the monitor as hex every time you powered up the computer.
Simple answer: Because Woz is the wiz that was.
You'll find he is a whiz of a Wiz, if ever a Wiz there was.
The part that stuck with me is femto's 'slow programming' line. I never hand-assembled anything, I came up too late for that, but I still write the tricky parts of a program on paper first. Last month it was a little state machine for a game I'm tinkering with. Two pages of boxes and arrows, and I caught three logic errors before I ever opened an editor. I think the paper forced a kind of discipline that's easy to lose now, when the cost of trying something is one keystroke. The flip side is that Woz had to be right before he ran anything, and that's a brutal way to learn. I'm not sure I would trade the fast feedback loop we have now for it, even if the paper habit is worth keeping.
>How did Woz write the Apple 1 BASIC before building the computer?
Time travel!