scruss
He appears to be fine, and just published Ansible® 471: https://news.ansible.uk/a471.html
Since it only ever got to prototype stages, the original C65s that are out there run a bewildering array of slightly buggy systems. All have quite different capabilities. Was it supposed to have a UI? We'll never know, and you won't get a unified answer from the ex-Commodore folks
The source is MIT-licensed, but the required credit is missing from the docs and distribution image.
For actual optimization of input files, [vpype](https://github.com/abey79/vpype)'s the one most people use.
Going back to really old/simple plotters, there wasn't enough code space to do any optimization. For example, the (fairly terrible) Commodore 1520 roll paper plotter had 2KB of ROM for all the 6502-compatible code its micro-controller used. When I first looked into the [firmware](https://e4aws.silverdr.com/hacks/6500_1/), I was pretty shocked that it printed text by scanning a table of character data from the start every time. Then I realized that even storing pointers for each character would use up about ⅛ of total storage, and the mechanical plotter mechanism was always way behind anything the code could do. So small mattered more than efficient
There is a feature in HP-GL that does make certain types of XY plotting simpler. While it's not a programming language like PostScript, you can scale, rotate and offset the plot by arbitrary amounts. HP instrumentation manuals claimed it was possible to directly plot experimental data by feeding it straight to the plotter after setting the scale. I feel this was a highly aspirational statement, and one not seeing much real use.
Fun fact: HP-GL is equally compatible with metric and US customary measure as it uses 1/40 mm as its base unit. This just happens to be 1/1016 inches: not a tremendously useful integer factor, but every bit of integer goodness mattered back when peripherals were 8-bit.
What I could never adequately explain is just how nicely made these digitizing sights are. They give a very bright, crisply magnified image of the point immediately under the pen position. This contrasts with how massively fiddly it is to try to operate exactly the right buttons on a pen plotter while squinting down a tiny optical sight.
Even though pen plotters weren't rare in the 1980s and early 1990s, I've never found any software (beyond the terrible script I wrote for that article) that uses this capability. There's probably some HP BASIC code lurking on a half-forgotten instrumentation archive that does the job, though.
To me, the 4 GB Raspberry Pi 4 is quite an acceptable desktop. Yes, I could have a Pinebook, but they don't have the support community.
I wrote about FreeCAD because the charity I work for — Makers Making Change [1] — makes open source 3d printed assistive tech to empower people with disabilities. We're always looking for free CAD solutions, and to get FreeCAD running well on a Raspberry Pi 4 was too good to miss.
I'm trying to get as many of our designs usable in free software as possible. Up to now, I've been a pretty solid OpenSCAD user. It's good, but not perfect: it's possible to generate non-manifold volumes even if you do the right thing all the way through.
Substituting ᱁𑛂೩᮴୫᱆᥍𑇘᱙꘠ for 1234567890, though: that would definitely be considered malicious. Even if it does work in Perl 6.
I'm guessing not everyone on HN is a huge fan of “Strictly Ballroom”, as the title is a key quote for dance movie otaku. It was also a weak joke about testing for random numbers; I'm imagining a little subroutine in a constant state of surprise when it encounters the next random number.
While I'm not sure if I implemented it correctly, RANDU isn't some ‘lousy homegrown software RNG’. It was the standard RNG for IBM mainframes in the late 1960s.