06085: pong, pongf: Various Pong notes

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
06085	Documentation	Typo	Have not tried	Nov 28, 2015, 02:41	Dec 29, 2019, 13:22

Tester	Stiletto	View Status	Public	Platform	MAME (Official Binary)
Assigned To	couriersud	Resolution	Fixed	OS	Windows Vista/7/8 (64-bit)
Status [?]	Resolved			Driver	atari/pong.cpp
Version	0.168	Fixed in Version		Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	06085: pong, pongf: Various Pong notes
Description	Preserving some commentary on Pong I always found interesting. First, from Vigo at AtariAge: "I noticed some differences between the real Pong and all simulations: - The graphics are mixed through resistors, which means that all elements are bright grey, and everything which overlaps with the ball is white. - I have to investigate it further, but it seems that on the original, the second paddle is displayed 4 more pixels to the right" http://www.atariage.com/forums/blog/52/entry-3291-pong-project/#commentsStart Two days later... " I am also noticing some subtle differences between the 2 existing hardware emulators (Dice & Discrete Sim) and the real PCB: - Once the ball collides with the horizontal and vertical screen boundaries, it is stretched into the HBLANK and VBLANK area for 1 frame. Actually, that's exactly how I would expect it to behave when looking at the schematics. The simulations don't reflect that. - There is a space of 1 pixel between the right score display and the right paddle, when the paddle is on the same level as the score display. On both simulators, there is no space between the right paddle and score display, which looks kind of odd." http://www.atariage.com/forums/topic/137964-where-to-find-hires-pictures-of-pong-pcb/ AdamB of DICE said the following to me in response: "The space between the score and rightmost paddle is due a difference in propagation delays through the score and paddle circuits... Discrete logic games don't really have true pixels, so the width of objects can be 1.3 pixels, 4.9 pixels, etc., based on the delay in the different paths from the pixel counters to the screen. I think the space between the score and paddle in Pong ends up being something like 1/2 a pixel. DICE 0.3 takes all of this into account when drawing the screen, and you can see the space, at least in full screen mode. In DICE 0.2 everything was "snapped" to the nearest pixel, so there was no space. I'm not sure how MAME currently handles this?" Secondly, the infamous Pong "gap" bug ("it's not a bug, it's a feature"): According to Curt Vendel and Marty Goldberg's "Atari Inc.: Business Is Fun" regarding the original Pong: "Because of the cost concerns, the timing chip that Al (Alcorn) had to use to control what scan lines the paddle was drawn across couldn't handle the full range of the screen. It actually left a small gap at the top of the screen. However as Nolan (Bushnell) and Ted (Dabney) played it during the design process, everyone realized that problem actually enhanced the game play. If two players were that good, the small hole would provide a break in the stalemate if a player could direct the ball through it. Rather than fix it by going a more expensive route, it was decided the bug would stay. The experience led Al to the mantra, "If you can't fix it, call it a feature."" See also Al Alcorn's quote about it from this IGN interview in 2008: http://www.ign.com/articles/2008/03/11/al-alcorn-interview?page=2 "The other – not hack – but, one of my lessons learned, is that if you can't fix it, call it a feature. The paddles on the original Pong didn't go all the way to the top. There was a defect in the [circuit] – I used a very simple circuit, I had to, to make the paddles, but they didn't go to the top. I could have fixed it, but it turned out to be important, because if you get two good players they could just volley and play the game forever. And the game has to end in about three or four minutes otherwise it's a failure as a game. So that gap at the top, again – a feature. So that was sort of a happy accident. "
Steps To Reproduce
Additional Information	I can confirm based on observation that MAME properly makes graphics bright grey, and white when they overlap. However, in comparison to Vigo's observations, it seems MAME does not have a pixel width or more between the right-hand paddle and the score but maybe it is merely some sort of rounding issue. As for the other observation (the ball stretching into HBLANK/VBLANK) I believe MAME probably does do this, but haven't checked. As for the official BTANB, MAME probably emulates this, but I haven't checked.
Github Commit

Flags	Verified with Original
Regression Version
Affected Sets / Systems	pong, pongf

Attached Files

No.17305 couriersud Developer Dec 29, 2019, 13:22	Emulation in MAME now displays a gap between score and paddle.
No.17306 couriersud Developer Dec 29, 2019, 13:22	Closing this.