For anyone interested in how the "motion circuit" works:
The basic building block is a counter chain, some simple counter chips in series. The horizontal counter chain counts clock pulses for a single horizontal video scan line, which is also used to generate the horizontal blank interval. Reset it each time, it reaches the end of a scan line. Now we have a digital counter in sync with the video signal. (Actually, we'll generate the video signal from this.) Another, vertical counter chain is used to count the rows and is pulsed each time, the horizontal counter chain is reset. Put a simple AND gate on the output of individual pins of the horizontal counters to put the output signal HI and you get vertical stripes. If we combine some output signals of the counters, we may narrow this down to single bar of arbitrary width. Do the same with the vertical counters and AND it with horizontal signal and you get what is known as a window, a basic rectangle.
So, how can we move this on the screen? Enter another set of counter chains, but this time with a bit of head room, which may be populated by a preset. These are known as slipping counter chains. E.g., have a 3-bit overhead and a preset of up to 4 bits, now the slipping counter chain will take head of the static one or fall behind it by up to 7 pixels in either direction, depending on the preset. (The extent of the "head room" is also known as the stop code, as setting the preset to that same value will result in a stationary signal. If the preset is zero, the counter chain will take 7 pulses longer to reach its end than the static one. If we fully populate the preset, it will finish early by the same amount.) If we start the slipping chain at a specific position of the static one, we may now move relative to it. Voila, we have a moving "window", which may be controlled by these preset values.
Basically, you need a set of slipping counter chains for each moving object and a set of static ones to generate the basic video signal and its sync pulses, as well as any static on-screen objects. For hit detection, just compare the signals emitted by those counter chains.
An amazing technical source on the subject is "The Textbook of Video Game Logic; Volume 1" by Arkush, William (Kush N' Stuff Amusement Electronics, Inc., Campbell, CA, 1976) [1]
"Now we have a digital counter in sync with the video signal."
This principle was maintained for many years until the homecomputer era came to an end. The CPU (and all the auxilliary chips) used to run in lock-step with the video signal.
The whole architecture of many games from that time was built around the position of the electron beam on the screen. We exploited that to switch video modes in the middle of the screen (text/graphics split screen), draw in the overscan area (raster bars) or multiply the number of hardware sprites by quickly alternating different sets at certain scanlines. The V-sync pause was a welcome rest and spent to calculate the game logic.
Another interesting consequence of this was that US homecomputer models ran at faster clock speeds than the Euro models because of the higher refresh rate of NTSC. With clock speeds in the single digit megahertz range the 60/50 ratio was not negligible. In Europe we did hw mods to add a switch that made the computer run at NTSC speed even if that meant no video. You had the choice: a fast computer with no output or a slow one with video.
With all the Apple I clones and the like, I am wondering why I have not come across a hardware Pong clone — using original TTL logic (not a modern microcontroller or FPGA).
It's been done, the schematics are readily available and the chips are still easy to find (technically not the original 74xx models, but the pin-compatible 74LS and 74HC series).
Nolan Bushnell was arguably one of the first consumer tech rock stars. He co-founded Atari and Chuck E. Cheese, and in one of the all time blunders of world financial history, turned down a offer to buy a 33% stake in Apple for $50K (about $260K today).
That's a big enough stake to alter the future direction of Apple. It might not have grew into what it is today with him owning so much back when they were beginning.
For sure. I think it it is almost inevitable that the trajectory would have been different in that case. For that share he would have had a board position. Would Sculley have become CEO under those circumstances? Impossible to know but if he would not, then the entire history would have played out differently.
Also, he sold Atari (to Time Warner) in order to finance the development and roll-out of the Atari VCS (AKA Atari 2600). – He sacrificed the company for its product becoming reality.
That would be using a very high inflation rate since 1980 (around when I assume this must have happened). I think the official factor is closer to 3x than 5x.
If it was a little earlier than 1980 it might be more realistic - inflation didn’t go below 6% between 1975 and 1983 and was often into double digits at that time
> Sound was also a point of contention at Atari. Mr. Bushnell wanted the roar of approval of a crowd of thousands; Mr. Dabney wanted the crowd booing.
> “How do you do that with digital stuff?” Mr. Alcorn asked. “I told them I didn’t have enough parts to do that, so I just poked around inside the vertical sync generator for the appropriate tones and made the cheapest sound possible.”
So the music genre should have been called cheaptune instead of chiptune after all.
> Atari secretly started a second company, Kee Games, with Bushnell’s next door neighbor, Joe Keenan, at the helm. “We took our number two engineer, our number two manufacturing guy, and every other game in our lineup, and gave it to Kee. We started Kee Games in August, and they were up and spinning by the November AMOA show (the big trade show in the games industry). Their goal was to pick up the rest of the distributors.”
> “We told the distributors that those bastards are stealing our games, and then the distributors would run off and grab the games. We would rag at our distributors’ meetings about [Kee] stealing our games—and stealing our employees no less.”
I'm hoping to be corrected, but I don't see any lying here (perhaps a white lie to spur a creative colleague into action). The original segment[1] was titled "Pong: an exercise that started an Industry" by Tekla Perry. I'm wondering if it was someone else at IEEE Spectrum who decided to change the title, and if so then it is a poor choice because it sounds misleading.
The basic building block is a counter chain, some simple counter chips in series. The horizontal counter chain counts clock pulses for a single horizontal video scan line, which is also used to generate the horizontal blank interval. Reset it each time, it reaches the end of a scan line. Now we have a digital counter in sync with the video signal. (Actually, we'll generate the video signal from this.) Another, vertical counter chain is used to count the rows and is pulsed each time, the horizontal counter chain is reset. Put a simple AND gate on the output of individual pins of the horizontal counters to put the output signal HI and you get vertical stripes. If we combine some output signals of the counters, we may narrow this down to single bar of arbitrary width. Do the same with the vertical counters and AND it with horizontal signal and you get what is known as a window, a basic rectangle.
So, how can we move this on the screen? Enter another set of counter chains, but this time with a bit of head room, which may be populated by a preset. These are known as slipping counter chains. E.g., have a 3-bit overhead and a preset of up to 4 bits, now the slipping counter chain will take head of the static one or fall behind it by up to 7 pixels in either direction, depending on the preset. (The extent of the "head room" is also known as the stop code, as setting the preset to that same value will result in a stationary signal. If the preset is zero, the counter chain will take 7 pulses longer to reach its end than the static one. If we fully populate the preset, it will finish early by the same amount.) If we start the slipping chain at a specific position of the static one, we may now move relative to it. Voila, we have a moving "window", which may be controlled by these preset values.
Basically, you need a set of slipping counter chains for each moving object and a set of static ones to generate the basic video signal and its sync pulses, as well as any static on-screen objects. For hit detection, just compare the signals emitted by those counter chains.
For some more detail (on the example of Computer Space) see: https://www.masswerk.at/rc2017/04/02.html
An amazing technical source on the subject is "The Textbook of Video Game Logic; Volume 1" by Arkush, William (Kush N' Stuff Amusement Electronics, Inc., Campbell, CA, 1976) [1]
[1] (PDF) http://www.tokensonly.com/images/resources/manuals/video-gam...