In general I'd rely on symmetry per 1/8th I think, because within each quadrant you can mirror half by swapping x and of offsets. Then basically use the same approach as Bresenhams line algorithm adapted to integer, but instead of calculating a fixed slope, look it up in a table and adjust based on radius.

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

That's 7 instructions that you'll do "automatically" when you're programming these CPUs daily and know you need an addition.

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.

Wow, pretty good. I mentioned that because the first source file I pulled up was a circle drawing routine written in assembler.

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

(btw I was doing this not to draw a circle as much as draw a moon)

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.

It's one of those things where you relatively quickly get used to a specific way of thinking, and while we didn't have instantaneous communications of papers, we did have endless numbers of computer magazines with actual listings in them that often also discussed fairly in depth algorithms.

Mostly it boils down to learning patterns for common things, and things like basic trig replacement was a staple of the demo scene.