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 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!
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!
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 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.
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.
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 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!
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!
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.
There was a #hexcoders channel on IRC back in the 90s, admittedly very dead, and not just because octal is better for x86 code.
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.
It's taken me more than 40 years to learn a fraction of a % of what Woz knew in 1975.
For the sequel to this, see:
https://www.folklore.org/MacBasic.html
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.