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.
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″
Gather ’round children, we’re about to hear a story about the good old days. Except that this is really more of a horror story of what it used to be like as a code monkey. [John Graham-Cumming] shares his experience programming a 6502-based KIM-1 machine back in 1985. Simple, right? The caveat being that there was no assembler or hardware for loading the finished code!
The machine in question was a label application tool for a production line. You know, product goes in bottle, label gets slapped on the side. But the slapping needed to be perfect because consumers shy away from packaging that looks shoddy. Computer control would end up being far superior than the mechanical means the factory had been using because it simplifies the ability to adjust calibration and other parameters. [John] started from square one by interfacing the KIM-1 with the existing hardware. It has a hex keyboard which is how the program was entered into the device. But first he wrote the software on sheets of notebook paper like the one seen above. It includes his hand assembled code, which was then typed in on the keypad. Kind of makes you appreciate all the tools you take for granted (like Eclipse), huh?
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”
Although having a 3D printer means you can create custom object of your own design, that doesn’t change the fact that most object printed on Makerbots and RepRaps are copies, or slight derivations, of already existing object. If you need a gear, just go grab an OpenSCAD file for a gear, and a custom smart phone case can be easily made by modifying an already existing one. The problem with this approach, though, is you’ll need to learn OpenSCAD or another 3D design tool. Enter the Makerbot Customizer, a web app that allows you to create custom versions of other people’s work right in your browser.
The idea behind Customizer is simple: someone creates an OpenSCAD file with a few variables like the number of teeth on a gear or the number of turns on a screw. Customizer takes this OpenSCAD file, puts sliders and radio buttons on a web page, and allows you to create custom objects based on user-created templates.
Already we’ve seen a lot of Hackaday readers send in some pretty cool customizable things, like [Bryan]’s coil form for DIY inductors and [Greg]’s customizable PVC pipe couplers. If you already know OpenSCAD, it’s easy to create your own objects that are customizable by anyone on the Internet.
Here’s an interesting tool for making simple 3D games. It’s called 3DPL, the 3D programming language, and it’s a real-time interpreted language that allows you to create cubes and other primitives that respond to user input and internal logic. Not only that, but you can build 3D versions of breakout and asteroids very simply with only a few lines of code.
It’s still a very early build, but looks to be pretty interesting for an ‘introduction to 3D graphics programming’ perspective. You can grab a copy of 3DPL to try out over on [amigojapan]’s github. Hopefully we’ll see a gravity method soon for a proper 3DPL Tetris implementation.
[Kory] has been experimenting with genetic algorithms. Normally we’d expect his experiments to deal with tuning the variables in a control system or something, but he’s doing something much cooler. [Kory] is using genetic algorithms to write computer programs, and in the process bringing us one step closer to the Singularity.
The first experiments with genetic algorithms generating applications did so in BASIC, C, and other human-readable languages. While these programs nearly worked, there were far too many limitations on what could be produced with a GA. A simpler language was needed, and after turning to assembly for a hot second, [Kory] ended up using brainfuck, an extremely minimal but still Turing-complete language.
The use of brainfuck for creating programs from a genetic algorithm may seem a bit strange, but there’s a method to [Kory]’s madness. It’s relatively simple to write an interpreter the GA’s fitness function can look into and come up with a score of which programs should breed and which should die. Also, the simplicity of brainfuck means a computer doesn’t have to learn much syntax and grammar at all.
Right now, [Kory]’s computer that can program itself only does so by creating simple ‘hello world’ programs. It should be possible, though, for this AI to create programs that take user input and generate an output, whatever that may be. Once [Kory] is able to have the computer generate its own fitness functions, though, the sky is the limit and the Singularity will be fast approaching.