Hacker News Reader

Comment by hggigg | Hacker News Reader

Pong isn’t that complicated. If you go even further back it gets even simpler. There’s a good example here: https://www.eevblog.com/forum/projects/oscilloscope-pong-for...

It looks complicated but it’s really not if you break it down into small bits and think of it like you would with a piece of software I.e. abstractions.

View on HN

Did you RTFA?

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).

http://blog.tynemouthsoftware.co.uk/2023/10/how-the-zx80-gen...

Of course there are modern programmers who still do this today, bit-banging VGA on little microcontrollers and the like.

>>Pong isn’t that complicated.

>Now is it complicated? No not really, I read the answer and immediately understood what was going on.

Seems like you agree? Not sure why you asked if the parent poster RTFA.

As a side note: I find the usage of RTFA and TFA pretty impolite and don’t like to see it on HN a lot.

Many come here just for the comment section and the discussions, not the article per se.

Thanks for calling it out, I feel the same.

> If anything, the point of the post is the fact that it's very easy to understand, despite how counterintuitive it may be.

Much like he seemed to have missed the point of the post, you seem to have missed my point about him seeming to miss the point of the post.

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. :-)

How do you debug it?

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.

It honestly sounds like a recipe for Heisenbugs.

> 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

Reply on news.ycombinator.com