I’m reminded of that scene in Battlestar Galactica (2004) where Starbuck cuts open a crashed Cylon raider, climbs in, and finds it’s actually organic rather than robotic — instead of the neatly-organized metal and wires and computers you’d expect to see in a hi-tech starship, it’s full of messy flesh and blood and organs.
In the same way, here they cut open a microcontroller and instead of finding a neatly organized CPU with all the usual recognizable bits and software written in a straightforward ISA, there’s this weird, surprisingly analog amalgamation between hardware and software, between control and data. It’s not obvious how anything even functions because it’s so alien compared to our nice, clean, modular general-purpose CPU. Instead it feels…almost natural, like the hardware and software grew and evolved together as a single unit (which, to be fair, they probably did). It’s beautiful and terrifying at the same time.
At least, that’s how it feels to me as a (sleep-deprived) software engineer. Maybe to a hardware guy, this is just Thursday.
The line between "chip" and CPU has always been a bit blurry. Anything that deals with USB or any other complex protocol is probably based on a tiny CPU (8051s are still weirdly common).
Software runs the world, but some of it is just cleverly disguised as hardware.
Oh, for sure. But my surprise is less because there’s a CPU in the chip, and more because the CPU is so weird, and so tightly integrated with the rest of the chip, rather than being a “normal” general-purpose processor that communicates using a set of cleanly-defined I/O interfaces.
As early as the mid-1970s, minicomputers and mainframes started incorporated microprocessors for things like system monitoring, booting, and peripheral interfaces. In 1981, the original IBM PC's keyboard had a 8048 microcontroller internally to handle communication with the PC. Architecturally, this is still how it's done, usually just all shrunk down to a single IC now. Pretty much any expansion card or USB device will have a microcontroller in it, possibly multiple.
I can second this, I remember looking at the spec sheet for an early USB interface chip. It includes a complete processor. No MMU, but the datasheet even showed how to prevent someone from reading the contents of the ROM.
"The way the paddles in particular are drawn is especially ingenious; in fact, the firmware doesn't even need to position them. The paddle controls are simple potentiometers feeding into an R-C circuit (external to the chip, not shown here) that discharges at a rate based on the pot's resistance. This then feeds into an on-chip comparator in the region marked "paddles," delaying drawing the paddle a number of scanlines based on the pot's position until the comparator triggers, thus eliminating the need for a more complex solution like an A-D converter (cheap!) and automatically drawing the paddle at the proper location without any intervention from the firmware."
Yes, the Apple II also uses a resistor-capacitor timing circuit to determine the paddle position. The big difference, however, is that the Apple II uses the timer and a counter to produce a paddle position 0-255. Software can then use this value to e.g. draw a paddle at a position on the screen.
The game chip, on the other hand, doesn't produce a value. Instead, the timer is synchronized to the screen drawing, so when the timer fires, it indicates to draw the paddle now. So the system never has the paddle position as a digital value and there's no register that holds the paddle position.
I think that the circuit at the top center of the chip detects collisions. E.g. if the paddle is being drawn at the same screen position as the ball, then you know that the paddle has hit the ball. This way, you don't need to store the paddle position and you don't need to compare the paddle and ball positions, you just check if a paddle pixel and a ball pixel happen at the same time.
I haven't figured out how the ball position is stored. It seems like they'd need a register for the X and Y position, along with an incrementer/decrementer, but I couldn't find that. Maybe there's something tricky going on. Or maybe I haven't looked in the right place.
The brilliance of this is there's no chance of bugs caused by the internal paddle position (that causes the ball to bounce) not matching the drawn position, which would make the ball either pass through the paddle or bounce off nothing. Whether that was any part of a motivation for this design or it was purely driven by technical limitations, it's just a very elegant solution.
If you want the least amount of lag possible, you now know which device to turn to. I'm thinking of the famous lag table of character entry for 80s 8-bit computers and modern PCs.
Using these machines on a 2022 display adds so much lag, it really makes them unplayable. On a CRT the connection between your movement and the paddle on screen is so immediate and undamped, it can be quite a powerful experience as you embody it despite its crudity. Helps to understand how simple games like this were so popular.
I have a few, but sadly I don't have the space to keep a CRT monitor too.
The MOS 7601 was the first CPU I learned how to write code for, circa late 1977 to early 1978. I would scour jumble sales for broken pong games and the other, more sophisticated console variants to cannibalize for parts, with one conversation about haggling with another buyer over who got what parts leading to a job.
There were several machines of the time that had pluggable cartridges, from Binatone, Telarude?/Telalude? (French or Italian company I recall, I forget), Telstra/Telstar, again, I forget, it was 45 years ago, along with many others, where the display circuitry, power and joytsticks were all on the main board, but each cartridge carried its own CPU and ROM, which was the fashion back in the day.
They were an absolute bugger to write code for, no complex ALU to speak of, no register storage, no RAM, you sort of just chased the CPU with a stream of instructions, stored stuff in decay buffers (you want a countdown from 10? charge up that cap for a brief period of time then let it leak) or on the display output circuitry that you could read back if you needed. If your code went wrong, you never knew it.
You were mostly bit-banging analogue circuits to get anything to display, same for the audio, though it could also talk to some AY audio synthesizer.
I recall the 7601 had a reasonably short lifespan in the marketplace for a variety of reasons.
There were two datasheets for it that were the bible, there might have been more but I only ever had access to bad photocopies of those two. One was the usual electrical characteristics and the other was the instruction set with the usual timings, delays and addressing modes.
The addressing modes were stupidly simple by the standards of today. There were EPROM variants (gold pin variant IIRC) available that you wiped with a strong ultraviolet light, but generally you had an off-board EEPROM and you tied two of the pins high to let it know it should use the external EEPROM.
When I tell people my first game I wrote fit in less than 500 (8-bit) bytes, they wonder how that is. The game was never released but Race Electronics and their desire to cash in on this new fad and exploit the younger, more gullible version of me, did give me my start in video game development so I am thankful for that, in a way. The next game I wrote fit in 2KBytes and I had the luxury of using a 6502 CPU and access to actual RAM on a CBM PET.
It is possible I am misremembering, and possibly even smushing two memories of completely different systems together. We are talking ancient history and I only worked on these systems for a few months at most. On your die photos or block diagrams that you are referencing, are there references of where the graphics were hard-coded into the system? If I wanted to show the playfield, I could strobe an address that would draw the playield? If I wanted to show a score of 9 for player two, I could strobe another address? I recall that the playfield was frequently mirrored (left-right or top-bottom), so it was possible to combine bits of playfield for different games.
Also look up old issues pf Microcomputer Digest, circa 1974 to 1976, same era as the MOS catalogues, as I am pretty sure the various processors were covered in there. Everyday Electronics or Practical Electronics, or one of those variants also included schematic and detailed instructions on using the "Pong on a chip" devices to make your own home console, though I don't recall which microprocessor they used.
Following up on this: I recall the microprocessor came in a plastic and ceramic variant, and the ceramic variant, I seem to recall, had an EPROM window on it (though my memory is a little fuzzy on that detail). I do recall that GI/MOS had an ICE that closely resembled the one for the Intel MCS-4x series of microprocessors, i.e. expensive and not available to anybody without a minicomputer on hand. GI MicroElectronics and AMI MOS put out a physical catalogue of components each year that I would pore over as a kid, along with the Maplin's catalogue, Siglent, and a few others.
Did anybody think to ask the original chip designers for GI out of Scotland? Many of them are on LinkedIn, though now retired. It is pretty easy to track down the GI MicroElectronics people.
Go grab a couple of back issues of Practical Electronics from the 1970's and a Maplin catalogue from the 1970's, they contain almost all of the GI and AMI MOS parts, including data sheets and example code. There's probably PDFs online by now. The GI catalogues and the MOS catalogues of the day also have all the datasheets and block diagrams in them and contain every non-custom part they made, though many parts could be customized to need. The General Instruments MCS/MPS (Microprocessor Ceramic System/Microprocessor Plastic System) 7600 is based, AFAIK, on the MCS5600 with extra bits. <strikeout>I recall that AMI MOS listed all their microprocessors under the "S" range, e.g. S6800.</strikeout> But again, fuzzy on the details and I wasn't privy to a lot of information and the internet back then wasn't what it is today (That's a joke). US Patents were definitely filed for these devices by GI MicroElectronics and AMI MOS, even though, technically, the 7600 variant was developed in Glenroathes. A quick internet search shows that the patents would be the 3,800,000 to 4,000,000 range based on the date of issue. Just need to search for the designers' names, or the corporation filing.
And if I have incorrectly stated anything, or lead you astray on details, it is not intentional. It's that 45 years later I didn't think I'd have to recall details about my middle-school and high-school years and my first forays in game development and electronics. And if it is a bit incoherent I blame only being on my third coffee of the day and trying to dredge up half-forgotten details. <insert Gandalf "I have no memory of this place" meme>
Thanks for the information, Justin. It's interesting to hear about your early programming adventures.
The MPS7600 chip I'm looking at was built by the company MOS Technology, not by General Instrument or AMI. (MOS Technology, which is unrelated to Mostek, later became part of Commodore.) The MPS7600 doesn't have any external address or data lines, so there's no way to program it externally or attach an EPROM.
So I think you're discussing a different chip. Maybe the General Instrument CP1600 processor, which was used in various video games?
Sketchy details from memory, so if I said anything that conflicts, assume your version of the facts is more correct than mine.
I do think I was confusing/conflating AMI MOS with MOS. And do recall that Mostek was a separate company. It doesn't help that MOS chose such a generic name for their company. Didn't they realize this wouldn't be searchable via Google?!? Did they learn nothing from Microsoft naming a language C# and an API .NET?!?
It is quite possible I am discussing a different chip. Again, apologies if I lead anyone astray, certainly not my intention. There were many such devices that came through my hands over the years. I wrote firmware in assembler for a bunch of slot machines I would swear blind used a TMS9900 but speaking to friend a few months back he assured me that it was not that CPU at all but one very much like it.
This comment discusses how ball and paddle collision detection worked but leaves open the question of how the ball position was known. https://news.ycombinator.com/item?id=32862403
Given your experience programming for it can you provide any insight to how this may have been done?
Yeah! when he mentioned making a timer by charging a cap and letting it discharge... that could apply to the ball position registers... it could also explain how they did various angles when there's no obvious multi-bit ALU.... varying dis/charge ratio...
Unfortunately there are no capacitors on the chip and the external capacitors can't fulfill this role. So I suspect they are describing a different chip.
The Magnavox Odyssey game, however, worked as you describe; the ball position was the voltage on two capacitors (X/Y), and they were charged or discharged to make the ball move. (This game system was analog, built from transistors.)
There were datasheets with the instruction set? But why does the article say that they were, until very recently, not sure whether it's a microcontroller?
I don't know. But really, how could somebody not know it was a microprocessor? It's in the name. MPS and MCS. MOS and GI didn't randomly and winsomely name their parts like it was a Node package on github.
The 6507 chip was essentially a repackaged 6502 microprocessor. The game chip is pretty weird, with a custom microcontroller and a bunch of specialized circuitry. So I don't think there is any connection between them.
I had the Coleco Telstar arcade and all its cartridges, thanks to my parents. I was just a young kid at the time. Thank you for this deep dive into a chip that shaped my childhood.
i had a binatone pong game that sounds like it was based on this chip. It had a bunch of variants of pong you could play based on moving a couple of physical sliders -- squash (bounced off a wall), football (two bars per player), etc.
The crazy thing was that if you turned the sliders just right, you could also play "off menu" games which had combinations of the attributes of the official ganes. I guess this was down to some of the tricks described here. It certainly confused me a lot when I learnt to program: you can't just compose two games together by half-clicking on an option!
This is called “circuit bending” now and has quite a following.
I did it with the Atari VCS (now called 2600) quite a bit. The Spider-Man cartridge had some great weird incarnations by moving power switch half-way, as did a few other carts.
I am still genuinely amazed about what was achieved in this era, bearing in mind that these things took years to develop so started much earlier when most people probably had never heard of a transistor.
Despite the infancy of the industry, these people not only designed an enormous electronic circuit but had to work out how to achieve compatability with inputs and outputs as advanced as graphics, how to store data in memory, had to perform a tonne of debugging and had to get this thing etched onto silicon and then produced at scale.
Steve Wozniak implemented Breakout with fewer 50 small scale integration chips, which is a fraction of the complexity of a 6502 CPU. I mean, a build system for a trivial JavaScript app is probably more complex than the software the flew the Space Shuttle
This seems like a lot of transistors for such a simple game....
If they could reduce the number of scanlines on the monitor, they could get many hundreds of clock cycles per pixel, and then do everything in software. 512 instructions seems quite possible for that - compare to 'boot sector games' which run in about one third of the space.
There are a couple of problems with that approach. First, the game uses a standard television, so you can't change the number of scanlines. Second, the pixel rate is about 1MHz, so you'd get about one clock cycle per pixel with a processor of that era. Of course, doing everything in software was a long-term solution.
> 512 instructions seems quite possible for that - compare to 'boot sector games' which run in about one third of the space.
Except a (boot) sector is 512 bytes (assuming x86)? Technically 510 because of the two bytes to indicate that it’s bootable, but that’s quite a bit more than 1/3 of 512.
In the same way, here they cut open a microcontroller and instead of finding a neatly organized CPU with all the usual recognizable bits and software written in a straightforward ISA, there’s this weird, surprisingly analog amalgamation between hardware and software, between control and data. It’s not obvious how anything even functions because it’s so alien compared to our nice, clean, modular general-purpose CPU. Instead it feels…almost natural, like the hardware and software grew and evolved together as a single unit (which, to be fair, they probably did). It’s beautiful and terrifying at the same time.
At least, that’s how it feels to me as a (sleep-deprived) software engineer. Maybe to a hardware guy, this is just Thursday.