DanBoris' Tech Blog

Seems a bit overcomplicated. If the volley counter bits are VC1 and VC2, how about computing "move" as

 

temp1 = /V2 or VC1 ; High is good (could use V2 nand /VC1)

temp2 = /V4 or VC2 ; High is good (could use V4 nand /VC2)

Move = temp1 and temp2 and V256 and /V1

 

I don't remember whether /V1, /V2, and /V3 are available. If so, MOVE takes half of a quad-2-input-OR and half of a dual-4-input-AND, eliminating six NANDs, two NORs, and two JK flipflops. If they're not available, add half a hex invertor.

 

This should cause a move pulse to be generated on line 256 all the time, on line 258 if VC0 is set, and on line 260 if VC1 is set.

 

If three velocities were desired instead of two:

 

temp1 = V1 nor V2 nor VC1 ; Low is good

temp2 =/V2 nor VC2

Move = temp1 nor temp2 nor /VSync

 

This would generate move pulses during VSync. During line 0 of VSYNC, pulses would be controlled by temp1. During line 1, they'd be on always. During lines 2-3, they'd be controlled by temp2.

What is the effective horizontal speed for each of the settings? If I recall, there was 455 clocks horizontally. (I don't know but I'm guessing that 320 would be visible). How many clocks/frame or pixels/frame for the horizontal movements.

 

I understand that MOVE stays high for one, two or three horizontal lines. Does that translate into one, two or three pixels per frame?

djmips,

Yes, the number of horizontal lines when MOVE is high corresponds to the number of pixels the ball will move each frame.

 

supercat,

It's an interesting idea, although I haven't studied it carefully, I don't think it will work because it appears you will end up with MOVE being high for to many lines. Also you still can't get rid of the NOR and 3 NANDs right after the counter since you need these to decode the number of hits that correspond to each speed range.

 

With that said, I do recall reading an interview with Al Alcorn at one point that said if he had to do the design again, he could probably do the same game with even fewer logic chips then the original design.

 

Dan

It's an interesting idea, although I haven't studied it carefully, I don't think it will work because it appears you will end up with MOVE being high for to many lines. Also you still can't get rid of the NOR and 3 NANDs right after the counter since you need these to decode the number of hits that correspond to each speed range.

 

Well V256 is active for six scan lines, and VSYNC is active for four, so I think I have the decodes right.

 

As for decoding the number of hits, I think I took care of that. If 0-3 hits, then only hit on line 256. If 4-7, hit on lines 256 and 258. If 8-11, hit on lines 256 and 260 (still two hits). If 12, hit on lines 256, 258, and 260.

 

With that said, I do recall reading an interview with Al Alcorn at one point that said if he had to do the design again, he could probably do the same game with even fewer logic chips then the original design.

 

No doubt. But it's still neat to see what was done. I'd also be curious to see Breakout.

Thanks for the info. RE: Breakout - just heard this podcast the other day of Alcorn talking about Jobs/Wozniak Bushnell and Breakout. I think Supercat might learn something from this. :-)

 

http://www.podtech.net/home/?p=881

 

Well V256 is active for six scan lines, and VSYNC is active for four, so I think I have the decodes right.

 

As for decoding the number of hits, I think I took care of that. If 0-3 hits, then only hit on line 256. If 4-7, hit on lines 256 and 258. If 8-11, hit on lines 256 and 260 (still two hits). If 12, hit on lines 256, 258, and 260.

 

 

In this, what exatly are VC1 and VC2?

 

temp1 = V1 nor V2 nor VC1 ; Low is good

temp2 =/V2 nor VC2

Move = temp1 nor temp2 nor /VSync

 

Dan

In this, what exatly are VC1 and VC2?

 

Sorry, I was unclear. VC1 and VC2 are the two bits of the volley counter used for determining speed; they didn't have net labels, so I assigned them arbitrarily ("If the volley counter bits are VC1 and VC2...") Perhaps I should have called them VC4 and VC8 to keep with the other naming conventions. Does that clarify things?

 

BTW, I was just pondering the score circuitry. Seems pretty complex. I was thinking it would have been interesting to use a '164 (shift register) to hold the two scores, feeding it four pulses near the middle of the screen and four pulses near horizontal sync (flipping the upper and lower nybbles). There would a a latch for an inverted carry signal; on each step the data into the '164 would be the xnor of that the QH output and the latch; the latch itself would receive the nand of itself and the QH output. If the latch had an async reset (very common), that could be hit once to cause one of the scores to be incremented.

 

The biggest annoyance I could see with this method of score counting would be that it would be necessary to either decode a number 0-F into decimal or else use something other than a 7-segment driver chip. I don't see either of those issues as presenting particular problems, though.

 

Incidentally, a few other thoughts:

 

-1- Did Computer Space multiplex any circuitry the way PONG does with the score digits?

 

-2- The first home video game system was based entirely on analog circuitry; nearly all later ones were entirely digital. The first arcade systems were entirely digital, but many later ones used a fair bit of analog circuitry. Interesting, eh?