Probably not that hard to do in principle, but the codebase isn't very tidy to work in, so I expect there'd be a lot of edge cases to figure out how to adapt it.
In the firmware, the conversion functions are in
https://github.com/euphy/polargraph_server_a1/blob/master/util.ino

There's a couple of functions called things like getCartesianX(...) and getCartesianY(...) that convert native coordinates into cartesian, and then a couple of functions called things like getMachineA(...) and getMachineB(...) that do the opposite calculation.

In the controller, in https://github.com/euphy/polargraphcontroller/blob/master/Machine.pde
you'll find a couple of methods called something like asNativeCoords(...) and asCartesianCoords(...).

Not impossible, or even hard ... but a bit messy! If I wasn't the author, I'd probably adapt a firmware and controller that already exists. Use G-code to drive it, which is easier to generate. Kongorilla is a drawing fellow who uses LinuxCNC to run his cartesian machines (I think) - perhaps he can fill in some blanks about how easy that was to configure.

sn

Cool thanks for the detailed responses, I think I'll press ahead with GRBL / gcode route as that path seems well traveled (although I am quite used to navigating unfamiliar or less than pristine software libraries having written some myself 🙂 )