This week we’re taking another departure from the ordinarily campy videos featured in the Retrotechtacular section. This time around the video is only two years old, but the subject matter is from the early 1980’s. [David Crane], designer of Pitfall for the Atari 2600 gave a talk at the 2011 Game Developer’s Conference. His 38-minute presentation rounds up to a full hour with the Q&A afterwards. It’s a bit dry to start, but he hits his stride about half way through and it’s chock-full of juicy morsels about the way things used to be.
[David] wrote the game for Activision, a company that was started after game designers left Atari having been told they were no more important than assembly line workers that assembled the actual cartridges. We wonder if any heads rolled at Atari once Pitfall had spent 64-weeks as the number one worldwide selling game?
This was a developer’s panel so you can bet the video below digs deep into coding challenges. Frame buffer? No way! The 2600 could only pump out 160 pixels at once; a single TV scan line. The programs were hopelessly synced with the TV refresh rate, and were even limited on how many things could be drawn within a single scan line. For us the most interesting part is near the end when [David] describes how the set of game screens are nothing more than a pseudo-random number generator with a carefully chosen seed. But then again, the recollection of hand optimizating the code to fit a 6k game on a 4k ROM is equally compelling.
If you like this you should take a look at an effort to fix coding glitches in Atari games.
Continue reading “Retrotechtacular: How I wrote Pitfall for the Atari 2600″
Some people know [Tom Murphy] as [Dr. Tom Murphy VII Ph.D.] and this hack makes it obvious that he earned those accolades. He decided to see if he could teach a computer to win at Super Mario Bros. But he went about it in a way that we’d bet is different that 99.9% of readers would first think of. The game doesn’t care about Mario, power-ups, or really even about enemies. It’s simply looking at the metrics which indicate you’re doing well at the game, namely score and world/level.
The link above includes his whitepaper, but we think you’ll want to watch the 16-minute video (after the break) before trying to tackle that. In the clip he explains the process in laymen’s terms which so far is the only part we really understand (hence the reference to voodoo in the title). His program uses heuristics to assemble a set of evolving controller inputs to drive the scores ever higher. In other words, instead of following in the footstep of Minesweeper solvers or Bejeweled Blitz bots which play as a human would by observing the game space, his software plays the game over and over, learning what combinations of controller inputs result in success and which do not. The image to the right is a graph of it’s learning progress. Makes total sense, huh?
Continue reading “Teaching a computer to play Mario… seemingly through voodoo”
This hack has got to be every gamer’s dream. Someone actually took the time to dig through the binary file of E.T. the Extra-Terrestrial and fix the errors that made it an abomination of a title for the Atari 2600.
This is quite a feat in many ways. First off, you need to know the game well enough to understand where they problems lie. The Internet is a huge help in that regard as there’s no shortage of sources complaining about the game’s shortcomings. This turns out to be one of the articles strongest points as the author takes time to address the most common myths about bugs in the game. From there he goes on to discuss the problems that were actually fixed. Some are just general tweaks like the color fix listed above. But most of them are genuine improvements in the game play, like the falling fix which prevents E.T. from falling in this pit when his feet are obviously not anywhere near the edge.
So you couldn’t get your hard earned bucks back for a bummer of a game back in the day. But at least a few decades later you can fix the things that made it suck and play it through the way it should have been.
Those of us that run Linux on a modern or nearly-modern PC know that it’s a capable operating system. It’s also (at least in my case with Ubuntu) extremely easy to install on a semi-modern computer. On a mid-90s era PowerMac 7200, things aren’t quite so simple.
In a testament to both his technical ability, and possibly even more so his tenacity, [Chris] was able to get Debian 6.07 running on a PowerMac destined for destruction. He had slated a few hours to upgrade this 56 Megabyte monster, but it turned out to be a several-day event. Those that are well-schooled in Linux may find the hairy details useful, and some more background can be found in part one. This project was a stepping-stone to something else, so we’re anxious to see what the end result is.
If you find this interesting, feel free to check out the retro edition of our site. It’s not entirely about ancient computers, but it can hopefully be displayed on one.
We won’t call it useless, but we will ask why [Dan] wrote a brainfuck interpreter for the AVR
It’s not generating code for the AVR; think of it more as a bootloader. To run a brainfuck program, [Dan] uploads it to the EEPROM inside his ATMega32, after which the microcontroller takes over and starts performing whatever instruction the brainfuck program tells it to do. Because the whole thing runs off the EEPROM, the code size is limited to 1022 bytes. Enough for any brainfuck program written by a human, we think.
As for why [Dan] would want an AVR to build an interpreter for a language that is nearly unreadable by humans, we honestly have no idea other than the common, ‘because it’s there’ sentiment. There are some pretty cool projects out there that use brainfuck, including this genetic algorithm software developer. Right now, though, blinkey LEDs are enough to keep us happy, so you can see a video of brainfuck doing its thing on a LED bar display after the break.
Continue reading “Interpreting Brainf*#k on an AVR”
It’s a simple fact that for every circuit you design, someone else has done it before. If you’re working on a high altitude balloon project, there’s already a project out there with a microcontroller, barometric pressure sensor, and an SD card somewhere out there in a corner of the Internet. Google will only help so much if you want to copy these previous builds, which led [Ben] to come up with a better solution. He took dozens of building blocks for basic digital projects and put them all into one really great interface called HackEDA.
The premise is simple: most electronic projects are just electronic Lego. You connect your microcontroller to a sensor, add in a battery, throw in a few caps and resistors for good measure, and hopefully everything will work. HackEDA takes all those basic building blocks – microcontrollers, power sources, and sensors – and creates a custom Eagle schematic with all the parts your project needs
HackEDA is still very much in beta, so there aren’t a whole lot of building blocks to choose from. That said, being able to generate an Eagle schematic with all the parts necessary for your next project is a boon. With this, all you need for a final circuit board is to create a new board file, hit the autorouter, and spend a half hour fixing whatever mess the autorouter made.
Panoramic photos are nice, however a full 360 degree x 180 degree, or spherical panorama would be even better. [Caleb Anderson] decided to take this concept much further, attempting to extract panoramic photos from video taken at 100,000 feet using a high-altitude balloon and six GoPro cameras.
The overview of this project can be found here, and gives some background. The first task was to start prototyping some payload containers, which for a device that you have little control over once out of your hands is quite critical. As well as some background, there’s a cool interactive panorama of the first test results on this page, so be sure to check it out.
The “real” hacking in this experiment wasn’t a matter of putting a balloon into the stratosphere or recovering it, however. Chaining these images together into pictures was a huge challenge, and involved a diverse set of skills and software knowledge that most of our readers would be proud to possess. There are several videos in the explanation, but we’ve embedded one with the cameras falling out of the sky. Be sure to at least watch until (or skip to) just after 1:05 where all the cameras impressively survive impact! Continue reading “Operation StratoSphere”