It covers some things that are rather counterintuitive, especially if you come from a modern programming background.
Now is it complicated? No not really, I read the answer and immediately understood what was going on.
But no modern programmer would ever come up with the solution of addressing x and y positions by setting timers to wake at the times when the point in the scan-line or the scan-line in the frame was reached (although sleep-sort does exist).
If anything, the point of the post is the fact that it's very easy to understand, despite how counterintuitive it may be.
If you're generating a PAL/NTSC/composite signal it's pretty intuitive to think of lighting up point X as turning on the signal (and this the electron gun) at a specific time because that's the way the "protocol" works. There's only one "wire" and the data is purely serial and synchronized to a specific scan speed.
This is also how the video hardware on CPU based consoles and home computers worked. They had counters and used them to either index into a frame buffer or look up hardware sprites, or both. Some machines did it more or less entirely in software (e.g. the ZX-80).
Ehm, now I feel really old. I just did a comment about this in some other thread. It's one of those timing things where it is hard to use a debugger. The scanlines scan in whatever frequency they are set to. You can influence the frequency and what color it should hit but you don't have exact control of the speed and have to set a timer or interrupt to fire when the electron beam is on the location you want to paint red. There are many programmers still alive that knows how this stuff works and now I feel like a dinosaur. :-)
I'm guessing you'd need to solder on your debugging tools (oscilloscopes?) in parallel, since anything else would completely invalidate anything that you were trying to do.
> But no modern programmer would ever come up with the solution of addressing x and y positions by setting timers to wake at the times when the point in the scan-line or the scan-line in the frame was reached
I would say it’s only fairly recently we stopped needing to do this - when we moved to graphics mode operation systems (oh god I say fairly recently but thinking now it’s probably close to 30 years ago yikes). I’m thinking Garmin app developer may still need to do it
It covers some things that are rather counterintuitive, especially if you come from a modern programming background.
Now is it complicated? No not really, I read the answer and immediately understood what was going on.
But no modern programmer would ever come up with the solution of addressing x and y positions by setting timers to wake at the times when the point in the scan-line or the scan-line in the frame was reached (although sleep-sort does exist).
If anything, the point of the post is the fact that it's very easy to understand, despite how counterintuitive it may be.