That has half the components I thought it should have.
Well done! ![ThumbsUp :-+](https://www.eevblog.com/forum/Smileys/default/icon_smile_thumbsup.gif)
I managed to fit the entirety of the ball video generator, movement and collision detection circuits on a single board; picture attached.
Due to some neglected chores that ended up sapping much of my time on the weekend, I didn't get as much done as I had hoped for; I thought I'd be able post a video of myself playing a match against the machine by now, but my paddle generator circuitry (somewhat revised/improved) still isn't entirely operational.
So below is a video of where I am at now; it is of the machine playing against itself but due to the incomplete paddle generators the paddles are currently invisible! Also for the time being I have (for testing purposes) the relevant collision detection inputs hardwired so that the ball bounces off the right hand paddle at 45 degrees and the left hand paddle at 68 degrees. When the paddle generators are finished the ball will deflect at 45 degrees only if it hits either paddle in the center section, and the 68 degrees is it hits the outer edges. The 68 degree deflection is achieved by multiplying the vertical speed by two.
I made a few other changes. I increased the thickness of the lower border from four lines to 16. I also changed the decoding for the paddle horizontal video components. The paddles were previously ~600nS wide and closer in to the center. The paddles are now 2uS wide and pushed further out to effectively enlarge the playing area. 2uS is the thickness of the vertical segments of the score counter digits.
I increased the thickness of the paddles and the lower border as this permits a faster ball speed. The ball movement circuitry has a lot of similarity to the 'scope display version; there is a Velocity integrator which provides a progressively increasing ball speed and the x and y movements are governed by integrators with flip-flops for each axis setting the direction of travel. However the collision detection between ball, paddles and boundaries and the attendant setting and resetting of the flip-flops this time around is done entirely digitally. Basically the ball video signal (a non-blanked version) is individually NANDed with the scoreboard background video signal, the lower boundary video signal and the video signals of each paddle. If the ball video signal is coincident in time with one of those other video signals, then there is a collision on the screen between the two and the respective NAND gate output will go low.
All of this makes the collision detection in the video version simpler and much more flexible than in the 'scope-display version, but there is a catch. There are over 200 lines to the playing field vertically. Suppose that the velocity is such that it takes 1s for the ball to travel vertically from the very top to the very bottom of this field. In that 1s there will be 50 frames drawn. So the ball will move >200/50 = more than 4 lines vertically between each frame. The lower border was originally only 4 lines high, meaning that at this vertical velocity, the ball, now moving faster than 4 lines per frame, could pass through the lower boundary without the video collision detection noticing!
The horizontal velocity is similarly limited. There are 48uS of each horizontal line visible on the screen to the playing area. Suppose that the ball velocity is such that the ball takes 1s to traverse from leftmost to rightmost. In each frame the ball has therefore traveled 48/50 = 960nS. As my paddles were originally only 600nS wide, they would not permit consistent collision detection at that velocity.
A velocity of only 1s left/rightmost-right/leftmost and 1s upper/lowermost-lower/uppermost is pretty fast, but after watching the screen I decided not quite so fast that a good player wouldn't be able to keep up it and keep a match/duel going too long. I thought the game would be better overall if I could impose a higher upper limit to my velocity integrator, and increasing the paddle widths to 2uS and lower boundary width to 16 lines permitted me to do that.
In the video below I stopped filming at 60 seconds, at which point the velocity integrator had reached about 80% of its maximum speed. As you can see the ball is moving quite fast here - I think it would take a pretty damn good player to keep up!
Anyway, my paddle generators are currently about 60% complete. The next video posted will be of me playing against the machine.
I filmed this on my employer-provided Iphone this time - the strobing effect isn't nearly as bad as for my cheepo pocket digital camera (there is only a brief periodic "lightning" flash) but there seems to be a mismatch in frame rate between the camera and monitor causing the ball movement at low speed to appear in the resultant video a little bit jerky. It seems to be a bit difficult to make decent video of a video screen. My cheepo digital does 50 Hz so I'm toying with the idea of opening it and probing to see if I can find a reference clock for the frame scan anywhere. Theoretically if available I could knock up a breadboard PLL to substitute my Pong system master oscillator and adjust the phase of the lock such that the previously visible, vertically-drifting strobing bar is shifted to the invisible vertical blanking interval.