Off topic, Linux question but it is relevant.

[Bill E]

In the implementation of the Type 340 I was using nanosleep() for the short timing delays, but it turns out to really be unusable. Why? It allows rescheduling, and Linux does that a lot. When you're drawing a few thousand points with random rescheduling happening, flicker gets bad. Same problem the light panel had. Note the 340 was a computer in its own right, and I implemented it as such in its own thread.

So, I switched to a spinwait loop for delays of a few microseconds or less and only allow a reschedule at the end of a display cycle. No flicker. That's quite satisfactory, but of course one would think it's a resource hog. Well, going flat out it only uses about 17% of a cpu, so seems acceptable. Want to see a real resource hog? p7simES. 250% cpu, like the panel was before my mods for it. Sigh. OTOH, it does handle 8 intensity levels nicely.

I'm not sure how well this would work on  pi4, but I'm pretty sure a p-zero would fall over dead. And of course it can still get preempted by the scheduler regardless, but at least I'm not telling it to go ahead and do so.

Anyway, the other choice would be setting it up as a real-time thread like vpanel does, but that seems excessive and invites its own problems. Or maybe play with thread priority. But, that just adds more complexity and requires special permissions. Any opinions, suggestions?

Bill

PS - the pidp1 emulator itself suffers from this, it's just not as obvious. I collected timing for how long a 5usec cycle actually takes. Well, it usually does that just fine, but there are occasional delays of up to a couple of milliseconds, depending upon what else is going on.

[Peter Long]

Nice Computerphile episode

B is the forerunner to C - but seemed lost - Angelo Papenhoff decided to change it and brought it back from the brink! Here he tries to recreate Brian Kernighan's original 'Hello World' with a few wrinkles!

Enjoy

https://www.youtube.com/watch?v=cYS57xJuRP8

Peter