To understand the mechanics of the game, the ROM source was explored. Since the NES was based of the MOS 6502 microprocessor, this involves looking at the 6502 assembly. The article details how the blocks (called Tetriminos) are created and how they move across the screen. The linear feedback shift register used for random number generation is examined. Even details of the legal screen and demo mode are explained.
After the tour through how Tetris works, an algorithm for the AI is presented. This AI is implemented in Lua inside of the FCEUX NES/Famicom emulator. It works by evaluating all of the possible places to put each new Tetrimino, and choosing the best based on a number of criteria. The weighting for each criterion was determined by using a particle swarm optimization.
The source for both the Lua version and a Java version of the code is available with the article. Everything you need to run the AI is available for free, except the Tetris ROM. If you’re interested in how 8 bit games were built, this dissection is a great read.
The most popular computer ever sold to-date, the Commodore C-64, sold 27 Million units total back in the 1980’s. Little is left to show of those times, the 8-bit “retro” years when a young long-haired self-taught engineer could, through sheer chance and a fair amount of determination, sit down and design a computer from scratch using a mechanical pencil, a pile of data books, and a lot of paper.
My name is Bil Herd and I was that long-haired, self-educated kid who lived and dreamed electronics and, with the passion of youth, found himself designing the Commodore C-128, the last of the 8-bit computers which somehow was able to include many firsts for home computing. The team I worked with had an opportunity to slam out one last 8 bit computer, providing we accepted the fact that whatever we did had to be completed in 5 months… in time for the 1985 Consumer Electronics Show (CES) in Las Vegas.
We (Commodore) could do what no other computer company of the day could easily do; we made our own Integrated Circuits (ICs) and we owned the two powerhouse ICs of the day; the 6502 microprocessor and the VIC Video Display IC. This strength would result in a powerful computer but at a cost; the custom IC’s for the C-128 would not be ready for at least 3 of the 5 months, and in the case of one IC, it would actually be tricked into working in spite of itself.
[Maurizio] loves using his Amiga 500. His classic piece of hardware has been serving him well for years, except for the floppy drive, which recently gave out on him. No problem for [Maurizio], he just cracked his case open and added a Raspberry Pi as a real-time floppy emulator. [Maurizio] didn’t want to make any permanent changes to his A500 case, and more importantly he wanted to use the Amiga’s original floppy drive interface. The latter placed some rather stringent timing requirements on his design.
The interface hardware is relatively simple. Most of the circuit is dedicated to level shifting from the 5v Amiga 500 to the 3.3V Raspberry Pi. A 74LS06 Hex inverter converts the signals to the open collector outputs the A500 requires. [Maurizio] powered his Raspberry Pi from the floppy power connector of the Amiga. His model A Raspberry Pi works fine, but a model B would pull a bit more power (700ma) than the Amiga floppy power supply is capable of providing (550ma). The user interface side of the equation is simple: Two buttons, one used to switch disks, and one to “Write to SD”. Live disk images are stored in the Raspberry Pi’s ram, so the user needs to hit the “Write to SD” button to store any changes to disk before swapping floppies.
The software is perhaps the most interesting portion of this build. [Maurizio] is emulating a floppy drive in real-time – this means emulating MFM encoding in real time. Calls have to be made with a timing accuracy of 2 microseconds. The Pi’s stock Linux Operating system was just not going to cut it. [Maurizio] coded his drive emulator “bare metal”, directly accessing the Arm Processor on the Raspberry Pi. This gave him access to the entire processor, and allowed him to meet the hard timing requirements of the floppy interface.
After seeing [Dimitry] build the most minimal Linux computer ever, [Kyle] decided he needed one for himself. In true hacker fashion, he decided to take this build for the worst Linux PC one step further: he would add I2C to his version, making it somewhat useful, considering the number of I2C peripherals out there.
This build is based on [Dmitry]’s ARM Linux computer emulated on an 8-bit AVR. It’s a full-blown Linux computer with 16 MB of RAM courtesy of a 30-pin SIMM, a lot of storage provided by an SD card, all running on an emulated ARM processor inside a lowly ATMega1284p. [Kyle] built this clone over the course of a few months, but from the outset decided he wanted to implement an I2C protocol on this terribly under specced computer.
After booting his computer, [Kyle] eventually got an I2C module loaded by the kernel. With an I2C module and a few spare GPIO pins, he set out to create something to attach to this terribly slow computer – an ancient LED dot matrix display. With a real-time clock, this display became a clock with the help of a homebrew program written in C. Considering the speed of the emulated processor, the program takes nearly three seconds to read the RTC and display the current time to the display. We’re thinking it was a wise choice to only implement hours and minutes in this clock.
If having a useful computer running at about 10 kilohertz isn’t enough, [Kyle] also compiled the classic text-based adventure Zork. It actually runs, proving you don’t need Megahertz of power to do something useful and fun.
Christmas is coming, and if you have nieces, nephews, or ankle biters of your own roaming your house, you’re probably wondering how you’ll be subsidizing Santa this year. it looks like Toys R Us will be selling the Leapfrog LeapsterGS for $30 on Black Friday this year. It’s a Linux device running on a 550 MHz ARM 9, with 128 MB of RAM and 2 GB of Flash. Overpowered for a children’s toy, but perfect for when the kids forget about it in a month, because now you can replace the firmware with a proper Linux install and run classic emulators.
Putting Linux on these cheap handhelds made for children isn’t anything new; we’ve seen it done with the Leapfrog DIDJ and the Leapfrog Explorer. Those consoles, however, had rather anemic CPUs and not a whole lot of RAM. Moore’s Law finally kicked in for stocking stuffers, it seems, and the Leapster GS is powerful enough to play all those Nintendo, Game Boy and even MAME games.
All that’s needed to flash the new firmware is soldering a few wires onto the LeapsterGS’ board for a serial connection. The new LeapsterGS firmware even has an MP3 and movie player, so even if the recipient of one of these machines grows tired of it in a week, there’s still a lot of life left in it.
Video of the LeapsterGS playing the greatest arcade game below.
A simple resistive DAC is all you need to drive a VGA display. Combining that with an on-chip DAC for audio, the STM32F405RGT6 looks like a good choice for a DIY game console. [Makapuf’s] Bitbox console is a single chip gaming machine based on the STM32 ARM processor.
We’ve seen some DIY consoles in the past. The Uzebox is a popular 8 bit open source game system, and [makapuf] was inspired by its design. His console’s use of a more powerful 32 bit processor will allow for more complex games. It will also provide more colors and higher quality audio.
One of the keys of the Uzebox’s success is the development tools around it. There’s a full emulator which allows for debugging with GDB. [Makapuf] has already built an SDL based emulator, and can debug the target remotely using GDB. This will certainly speed up game development.
After the break, check out a demo of the first game for the Bitbox: JUMP. Also be sure to read through [makapuf]’s blog for detailed information on the build.
[Kevin] just finished a project for someone who lives in his apartment complex. This resident loves the game Pop ‘n Music – a Guitar Hero sort of game for the original Playstation and PS2 that uses nine colored buttons instead of five buttons along a fingerboard. His original idea was to wire up a few arcade buttons to a Playstation controller but this plan fell through, forcing [Kevin] to figure out the PSX bus all by his lonesome.
The initial code began with simply bit-banging the PSX controller interface with an AVR. This had a few problems, namely speed, forcing [Kevin] to move onto assembly programming to squeeze every last bit of performance out of a microcontroller.
The assembly route failed as well, dropping some transactions Looking at the problem again, [Kevin] realized the PSX controller bus looked a little like an SPI bus. There were a few changes required – reversing the order of the bits, and using the MISO line to drive a transistor – but this method worked almost perfectly on the first try.
Now, [Kevin]’s building mate has a custom Playstation controller for his favorite game. Of course all the code is up on github for all your PSX controller emulation needs, but be sure to check out this completely unrelated Pop ‘N Music video from someone who desperately needs a piano.