It was on essentially ticker-tape, which was the medium at the time (wikipedia's photo: https://en.wikipedia.org/wiki/Altair_BASIC#/media/File:Altai...)
Paul Allen was still "writing" it on the plane which in this case meant taking careful notes, cross-checking it very carefully and then manually punching holes into the paper. This is 1975, laptops are many years away.
It'd take about 30 minutes to load into the machine. Paul Allen claims they were the longest 30 minutes of his life. The MITS people were just smiling and waiting patiently, eager to see the cool software while Allen, on the other hand, had absolutely no idea whether it would work or not (they wrote it on an emulator after all).
After the 30 minutes it was ready to go and bam, everything worked. Bill and Paul had a company. Microcomputer software was now a thing.
Maybe I should do a computer history podcast ... I just checked and I don't really like most of them ... The video game crash of 1983 for example, I'd do at least 10 30 minute episodes on. The NES came out of it. I mean yeah, at least 10 episodes. I'll pick something super small (for example the HP 9100a) and see how it goes
Woz wrote Apple integer BASIC in the evenings while working at HP in just a few months. Guys were writing crazy stuff at the time. The original version of DOS that Microsoft bought to license to IBM for the PC was written in 6 weeks.
I feel often the need to remind programmers, that they don't write code for the computer. The computer will make it obvious, whether it understands you or not. You write for the poor sod tasked to maintain your code three years from now, when you're at your next gig.
Sure you can usually use import/aliasing to narrow it, but sometimes you just need to grab some random global from somewhere.
Is this actually true? From https://en.wikipedia.org/wiki/Tim_Paterson
When a book appeared in 2004 claiming that 86-DOS was an unoriginal "rip-off" of CP/M,[6] Paterson sued the authors and publishers for defamation.[7][8] The judge found that Paterson failed to provide any evidence regarding "serious doubts" about the accuracy of the Gary Kildall chapter.
It wasn't a direct copying of the code, but the API was largely similar to CP/M.
(I started with 6800 / 6809 assembly language, and then Microsoft C 4.0).
Also: PDP-10 (TENEX) was awesome to use, was a very nice development platform.
It is interesting now to see Microsoft going back to its roots as a provider of developer tools for multiple platforms.
This is pop computing.
Gates and Allen had already been working on PDP-8 and Data General versions for a while.
I apologize for not taking current economic conditions into consideration with what was clearly a poorly-worded post.
(with stack overflow blocked)
There is Bresenham's circle algorithm - I don't know it, but I'd guess it's not that far off the above, because the above is a pretty obvious solution when you know even the idea behind Bresenham's line algorithm and you know basic trigonometry.
Basically "everyone" that has done anything graphics related pre-fast floating point and pre-fast general multiplication/division in CPUs are used to the fact that you can boil anything involving trig down into tiny tables of number of steps in one direction before the next step in the other direction to avoid multiplication. You can often forego the tables for a few shifts, but it's often not worth it. You then look for mirroring as a means to avoid replicating computations wherever possible.
It'd certainly take a bit of time to get it just right, but at a few dozen instructions at least, you have a reasonable amount of time to figure it out. But more importantly: Most of the code will include a lot of pieces that takes far less than a minute per instruction.
I wouldn't be able to do it fast enough now given that it's 30+ years since I last wrote much assembler by hand and it'd take me a few days to get back up to speed, but this isn't a difficult challenge. Of course it'd also depend on CPU.
One thing you need to keep in mind is that the code density of assembler is very low. Once you know you need to add two 16 bit numbers together on an 8 bit CPU for example, you know what to write for several instructions. E.g. you might end up with something like this (roughly 6502, though I don't remember all the details of the assembler syntax; I'm assuming the use of <var to address the low byte of a 16 bit pair, and >var to address the high byte as at least some assemblers used that as shorthand to indicate address offsets), assuming two 16 bit values in var1 and var2, with result stored in var1
CLC ; Clear carry flag; can be ommitted if you know carry will be clear
LDA <var1 ; Low byte of var1
ADC <var2 ; Add with carry of low byte
STA <var1
LDA >var2 ; High byte
ADC >var2
STA >var2
But even on much higher level CPU's like the x86 or M68k the density of high level concepts to assembly instructions is pretty low.
I wrote a routine to do it once for fun -- in python -- and it took me some time to get it right. I also had access to wikipedia and stack overflow, so I was able to get the integer method going with guidance.
for example, the middle of the main loop was:
x += 1
if d > 0:
y -= 1
d = d + 4 * (x - y) + 10
else:
d = d + 4 * x + 6
But when I read the source code I thought... writing geewhiz basic would take a long time now, let alone 1975 when there was no instantaneous communication of acm papers and computers were rare and graphical computers rarer.
Mostly it boils down to learning patterns for common things, and things like basic trig replacement was a staple of the demo scene.
> ORIGINALLY WRITTEN ON THE PDP-10 FROM FEBRUARY 9 TO APRIL 9 1975
Wow! I did not realize that it was written so quickly. Two months that literally changed the PC landscape forever.