Retrotechtacular: Bell Labs introduces a thing called ‘UNIX’

dennis

Modern operating systems may seem baroque in their complexity, but nearly every one of them  – except for Windows, natch – are based on the idea of simplicity and modularity. This is the lesson that UNIX taught us, explained perfectly in a little film from Bell Labs in 1982 starring giants of computation, [Dennis Ritchie], [Ken Thompson], [Brian Kernighan], and others.

At the time this film was made, UNIX had been around for about 10 years. In that time, it had moved far from an OS cloistered in giant mainframes attached to teletypes to slightly smaller minicomputers wired up to video terminals. Yes, smallish computers like the Apple II and the VIC-20 were around by this time, but they were toys compared to the hulking racks inside Bell Labs.

The film explains the core concept of UNIX by demonstrating modularity with a great example by [Brian Kernighan]. He took a short passage from a paper he wrote and found spelling errors by piping his paper though different commands from the shell. First the words in the paper were separated line by line, made lowercase, and sorted alphabetically. All the unique words were extracted from this list, and compared to a dictionary. A spell checker in one line of code, brought to you by the power of UNIX.

Retrotechtacular: How I wrote Pitfall for the Atari 2600

how-I-programmed-pitfall

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.

[Read more...]

Teaching a computer to play Mario… seemingly through voodoo

computer-learning-mario

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?

[Read more...]

Fixing the worst video game ever: E.T. for Atari 2600

fixing-et-for-atari-2600

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.

[via Reddit]

Debian Linux on a PowerMac 7200

debian-7200

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.

via [twitter]

Interpreting Brainf*#k on an AVR

brainfuck

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.

[Read more...]

Automatic, custom Eagle schematics

sch

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.

Follow

Get every new post delivered to your Inbox.

Join 96,311 other followers