Drawing circles without sine/cosine? Sure - a classical "good way" to do that is the Midpoint Circle Algorithm.

...But you could also do it simpler...assuming you're not worried about getting the ideal version of everything.

//radius rad=30 //center cx=64 cy=64 //do it for x=-rad,rad do // use the pythagorean theorem to find y value y=sqrt(rad*rad-x*x) pset(cx+x,cx+y,12) // mirror everything on the y axis to draw a full circle pset(cx+x,cy-y,12) end

So this is super easy and all, but the problem with it is that it gives you some gaps at the left and right edges (because it doesn't know how to draw more than one mirrored vertical pixel per column). One option here is to increase the sampling rate near the edges, but this would take some extra math that I'm not gonna bother to figure out at the moment.

...So instead, the naive solution is to run the loop again, but do it on the other axis:

// do the above loop first, then also do this: for y=-rad,rad do x=sqrt(rad*rad-y*y) pset(cx+x,cy+y,14) pset(cx-x,cy+y,14) end

As I said, this solution is NAIVE - it doesn't guarantee a perfect outline (might be double-thick at certain spots), and it re-draws a bunch of pixels that it's already drawn while it's cooking.

In this example, the second loop is using color #14 instead of #12, so you can tell them apart.

That fancier algorithm I linked is all about fixing the gaps perfectly without wasting any pixel-setting effort. If you want a truly ideal solution, that'll be the one. Here's the link again.

BUT...why aren't you allowed to use sine/cosine?

It's, uh, easier, and the result is arguably better:

rad=40 // draw more pixels for bigger circles // note that pixel count is literally just the circumference (pi * diameter) dotcount=3.14159*rad*2 for ang=0,1,1/dotcount do x=cx+cos(ang)*rad y=cy+sin(ang)*rad pset(x,y,12) end

Not quite perfectly symmetrical (maybe you could fix it by subtracting .5 somewhere, or something?), but pretty dandy anyway.

Finally, just for visualization, here's what it looks like when we alternate colors for each pixel we draw in the sin/cos version (we can examine the resulting pattern to get a feel for how many of our pixels are redundant):

I dunno about the performance of sqrt vs. sin/cos in pico, but my assumption is that being less redundant with overlapping pset() calls makes this version lighter overall. Haven't measured it or anything, though, so I don't know for sure.