Oscilloscope pong for 1 or 2 players.

[GK]

I'd have expected that to be much more difficult.

Ok now try to do NTSC color

I'm fairly sure, concerning the chroma only, converting to NTSC would just require disabling the PAL flip-flop and switching a different frequency subcarrier oscillator.
This circuitry isn't very complex as chroma components for only a few individual colours need be generated. Basically all you need to do is generate and inject your quadrature U and V; the polarity (phase) and amplitude of each is what determines the colour, and these can be computed from some basic equations. No need for mixers/modulators or any of that stuff.   

I made some very satisfying progress today - the prototype chroma encoder using that breadboard and those despicable integrated circuits has been dispensed with and substituted with a fully discrete circuit; I've now got vivid colour and it's back to discrete transistors only! And with the refinement of the design and a tidying up of the wiring and the dispensing of the breadboard, the picture quality has been very much improved. It is still suffering a bit due to noisy grounds on the remaining breadboard currently sporting the luma circuitry and video buffer, but I'm getting there.   

As the circuit was somewhat experimental and was modified and refined throughout the course of the day, I built it dead-bug with little care for neatness on an old and very tarnished square of copper laminate that I had handy; this isn't the final build, just a prototype and it currently doesn't have duplicate circuitry for gating any colour other than red. So the R&D for the colour encoding part of this project is now over and the electronic design is now complete. The next stage will be to build up the complete combined luma and chroma processing circuitry in its final form on a fresh, lacquered slab of blank PCB.

I won't have time this evening to draw up the schematics in a presentable form, so it's just some pretty photos for now. The success of my chosen method of implementing the quadrature "carriers" hinged on producing a discrete toggle flip-flop (of which three duplicates are used) that can happily toggle at 17.73 MHz and still give clean and usable squarewave outputs. I was obviously successful here and my flip-flops better the required performance by a rather comfortable margin, but I had to dig into some rather old and arcane design here!

Oh, and yeah, my Commodore 64 kindly donated the 17.73 MHz crystal (only temporarily, until my Mouser order arrives) 




 

[BrianHG]

Did you also order the 500KHz resonator from Mouser as well?  I believe they had stock.

[GK]

Oh, no, I didn't even think of it to be honest. I lied about scribbling a circuit diagram of the chroma circuit this evening. I realised that my fully-discrete proto didn't sport an inverter for V, and you need NOT-V to do green, so, not being able to help myself I went back into the shack and soldered up another MPSH10, flipped to NOT-V to check the green and then decided to redraw/scribble up the schematic too. And now I am typing post 1am - so much for my plan yet again for an early night  The schematic shows everything except for the U/V gating for the desired colours, but this is just, for each desired colour, a duplication of the circuitry shown in the lower left of the schematic for gating the colour burst, with the difference being that the U/NOT-U & V/NOT-V inputs are instead hardwired as required for the desired colour and the mixing resistors values are chosen for the required signal amplitudes respectively, and the gating input signal is a video signal line.

Three high-speed toggle flip-flops do the quadrature encoding. The first TFF divides the 17.73 MHz clock down to 8.865 MHz. The other two high-speed TFFs each divide the first TFF's output down to the 4.43 MHz chroma carrier frequency in parallel, except that one is clocked by the first TFF's Q output and the other by the NOT-Q output; hence the two 4.43 MHz clocks thus produced are 90 degrees out of phase. One "issue" with this simple arrangement, constructed from practical discrete-transistor TFFs, is that, depending of which initial state the TFFs assume upon power up, one of those 4.43 MHz quadrature signals might be leading the other or it might be lagging. It's essentially a random thing, but for PAL, this doesn't matter at all as the V signal is flipped 180 degrees in phase every second line and the receiver establishes its reference from the colour burst. Cool huh? I think I spent about one third to half a day pondering in the back of my mind (whilst doing boring stuff at work) how to overcome this design issue before finally realizing (DUH!) that it isn't an issue at all.

[BrianHG]

I'd bet good money if you replaced your 17.73 Mhz crystal with 14.31818Mhz (NTSC standard crystal) divide by 4 for 3.579545 MHz and had a jumper to limit your vertical counter to 262 or 263, though the text image would be stretched, your existing circuit would work on a NTSC display.  You might need to increase your vertical location ramp oscillator to adapt the paddle/ball positions and size.  Only your chosen colors may be different, but, they would still work.

[GK]

Probably, but still not persuaded. I made a start on the score counters late this afternoon. So far I've completed the BCD-to-binary and the binary-to-7-segemnt decode logic and have one of the BCD counter toggle flip-flops installed. The rest of the TTFs along with the associated control logic will run along the bottom of the board. On the right hand side besides the decoders I should have enough room to solder up the DFF for deskewing the scoreboard video signal and hopefully enough after that for an additional decoder I've decided to add to provide an additional video signal producing a bottom boundary for the ball play area.

I hope it doesn't detract from my mystique as a serious dead-bugger, but I wimped out a bit here and made things easier on myself by cutting up some veroboard to support the diode arrays performing the decoding  .

The printed circuit diagram is of my LTspice score counter circuit simulation - it almost quicker to draft complete ideas in LTspice than to draw by hand.

[Mukrakiish]

Wow, your work is just so damn pretty. Not sure how it works but man does it ever look good doing what it does!

[tautech]

I hope it doesn't detract from my mystique as a serious dead-bugger, but I wimped out a bit here and made things easier on myself by cutting up some veroboard to support the diode arrays performing the decoding  .

That is very cool Glen, in fact that's probably the wisest layout for the arrays. Very classy. 
I particularly like how you've used decoupling caps as standoffs on the long runs of wire. 

Massive respect for your ingenuity and perseverance. 

[BrianHG]

I hope it doesn't detract from my mystique as a serious dead-bugger, but I wimped out a bit here and made things easier on myself by cutting up some veroboard to support the diode arrays performing the decoding  .

That's still dead bug, just that it's a dead bug on a few elevated tables...
Once again, impressive as hell... 

[timb]

Damn, that is pretty GK!

So, I've got one section (Paddle Collision) left to finish on the Scope Pong board. Once I finish that I've then got to route all interconnections together, do some cleanup and I'll be done. Hopefully in the next day or two.

I've also been working on a prettified "Theory of Operation" document to go along with the actual schematics. Here's a preview of how the graphics are shaping up:

[tautech]

Would it be wise to add 0V markers for each of the traces on the oscillograph ?

[GK]

That is very cool Glen, in fact that's probably the wisest layout for the arrays. Very classy. 
I particularly like how you've used decoupling caps as standoffs on the long runs of wire. 

The original plan for the diode arrays was parallel lines of the same wire supported by electrically benign 10M resistors, but that would have been fiddly to make as compact as the veroboard incarnations.   

[GK]

I've also been working on a prettified "Theory of Operation" document to go along with the actual schematics. Here's a preview of how the graphics are shaping up:

LOL, for a split second there I almost thought you had already started building the thing and were showing us an oscilloscope photo.
 

[GK]

Okaaaayy..... The score counters are complete. This was the last big chunk of boring logic circuitry to get out of the way and things are getting serious now. For the time being I have unstitched my chroma circuitry and the analogue board currently sporting the beginnings of the Paddle generator, and have put them aside.

I am now tacking these digital boards together in their permanent/ final orientation. The score counters are hardwired in and are operational and the next step is to properly stitch the horizontal board down and tidy up the interconnecting wiring, which will entail replacing all of those higgledy-piggledy flexible silicone-insulated wires with neatly routed solid-core stuff.

Each players score counter is identical and they share a common master reset. I'm currently working on a presentable schematic diagram but for now I've attached below a basic logic block diagram of one of the counters. It's basically a single-digit decade counter with an overflow/carry flip-flop for the half digit. The score counters are manually reset to zero by pressing a push button (which will be mounted on the consoles control panel). The reset button triggers a monostable which ensures a clean reset pulse sufficient to reset all counting flip-flops.  Every time a player misses the ball his/her opponents score counter will be incremented by a clock pulse. When a score counter reaches its maximum displayable value of 19, the "!lock-out" line goes low, inhibiting any further counting. This line will additionally lock out further game play and trigger an alarm in the sound circuit, indicating the winner. Play will be resumed by pressing the manual reset button to once again zero the counters.






     

[GK]

Here's a video of the score counters operating (clock inputs fed in parallel from my function gen. @ 1 Hz):

[timb]

Would it be wise to add 0V markers for each of the traces on the oscillograph ?

For some of the stuff it doesn't really matter; the outputs from Function Generator section for example all end up being AC coupled at their destination, so as long as they're xV/div the offset doesn't really matter.

Where appropriate the overall voltage range (or GND) will be shown either with callout lines next to the image in the document or by showing cursors on the image itself, depending on the situation.

I'm trying to keep the style like old Tektronix service manuals as much as possible.

I've also been working on a prettified "Theory of Operation" document to go along with the actual schematics. Here's a preview of how the graphics are shaping up:

LOL, for a split second there I almost thought you had already started building the thing and were showing us an oscilloscope photo.
 

Best compliment I could get, thanks! It is surprisingly hard to simulate the glow and blur of a trace correctly (the same is true for the look of an illuminated graticule too).

I can't wait for you guys to see the finished product. (The board *and* documentation.)

[tautech]

Would it be wise to add 0V markers for each of the traces on the oscillograph ?

For some of the stuff it doesn't really matter; the outputs from Function Generator section for example all end up being AC coupled at their destination, so as long as they're xV/div the offset doesn't really matter.

Where appropriate the overall voltage range (or GND) will be shown either with callout lines next to the image in the document or by showing cursors on the image itself, depending on the situation.

I'm trying to keep the style like old Tektronix service manuals as much as possible.

Yep, I get that and that is no problem for an oscillograph with only one waveform that would naturally have a 0V position on the center graticule. Most Tek ones had only one waveform/graph. 

A little triangle indicating 0V of the same colour as the waveform would be quite adequate.
For a scope novice it takes away any ambiguity.

[bitseeker]

I've also been working on a prettified "Theory of Operation" document to go along with the actual schematics. Here's a preview of how the graphics are shaping up:

LOL, for a split second there I almost thought you had already started building the thing and were showing us an oscilloscope photo.
 

Best compliment I could get, thanks! It is surprisingly hard to simulate the glow and blur of a trace correctly (the same is true for the look of an illuminated graticule too).

I can't wait for you guys to see the finished product. (The board *and* documentation.)
[/quote]

I thought you had started building too or using some kind of simulator. Excellent "scope" work.

[bitseeker]

Here's a video of the score counters operating (clock inputs fed in parallel from my function gen. @ 1 Hz):

That board is art. Should mount it to the wall.

[BrianHG]

Okaaaayy..... The score counters are complete. This was the last big chunk of boring logic circuitry to get out of the way and things are getting serious now. For the time being I have unstitched my chroma circuitry and the analogue board currently sporting the beginnings of the Paddle generator, and have put them aside............................................

That's just too much! 
I could never imagine wiring sooooooooooooooooooooo many transistors and diodes by hand, or, even, after the rest is added, making a PCB with so many discrete components in my life...

[GK]

I dunno, I think it just requires a little patience. I made some reasonable progress today. I now have all three 300mm X 150mm digital boards permanently stitched together and have tidied up almost all of the interconnecting wiring. In the spare space besides the score counter decoders I had room to spare for the video deskewing DFF (the simpler type comprised of only six NAND gates) and the additional decoding to provide the bottom boundary/border video signal. The screen looks much more complete with the lower boundary, IMO.

[bitseeker]

The screen looks much more complete with the lower boundary, IMO.

Agreed. That does put the finish touch on the playing field.

[BrianHG]

Arrrrg, after seeing that bottom line, plus one of your old analog gravity bouncing ball demos, I'm now thinking shrink the middle fence lower.....x/y use analog joystick bats for each player......tennis......  Just ignore me, continue on....

[GK]

He he.... In addition to the original "Tennis for Two" A good old game that would make for a nice demonstration of analogue computing principles and circuitry would be a variant of one we ran on the BBC micros in high school called Missile Attack or something like that. There were a lot of variants of this game, one which I think came bundled with QBASIC called either Gorillas or Bananas or whatever. Basically the opposing  players have positions on either side of the screen and take turns launching missiles at each other. Firstly, IIRC, you hold your fire button down for a period of time that sets the initial trajectory and then a second time to set the initial velocity, releasing to fire. Then you sit back and watch your projectile take flight and hope that it comes down right on top of your opponents head!

But back to Pong.... For the sound effects this time around I wanna do something a little more sophisticated than the simple "computer sound" beeps of the oscilloscope-display version. I've been playing around in LTspice with simple percussive sound circuits in order to approach something sounding like the thunk of a ball against a wall or bat. Attached is the circuit I think I am going to settle upon, which is an amplifier with a twin-T filter in the negative feedback path, giving a high-Q resonant peak in the pass band. Excitation/triggering is a brief 1mS pulse which will be provided in real life by a monostable. Using the .wave spice directive I've recorded the output to a .wav audio file, which you can listen to:

Bonk.wav

I think that sounds kinda like the bonk of a ball on a bat. I'll have two of these generators, one for the paddle-ball collisions and another lower pitched version for the ball-boundary collisions. Cool, huh?

[bitseeker]

Yep, sound is half the experience.

[GK]

Yep, sound is half the experience.

Ha ha (flame suit on!) - For a dull and boring George Lucas film (like Star Wars Episode 0 through 250) that's probably more like 95%! 

Continuing with the documentation, I've revised the Vertical Timing and the Scoreboard Video Signal schematics to correct minor errors and reflect the most current hardware modifications. The former now sports decoding for the net video signal (I was previously assembling this component on the breadboard) and decoding for the lower boundary video signal. The latter now incorporates the video signal deskewing DFF. Some changes have been made to the Horizontal Timing circuit and the buffer of the Master Oscillator circuit (to provide adequate current sinking to drive the DFF clock input) as well, but they're currently a work in progress.