The card you see above is a floppy drive emulator for Macintosh. [Steve Chamberlain] has been hand assembling these and selling them in small runs, but is troubled by about a 4% burn-out rate for the CPLD which has the red ‘X’ on it. He settled into figure out what exactly is leading to this and it’s a real head-scratcher.
He does a very good job of trouble-shooting, starting with a list of all the possible things he thinks could be causing this: defective part, bad PCB, bad uC firmware, damage during assembly, solder short, tolerance issues, over-voltage on the DB connector, or bad VHDL design. He methodically eliminates these, first by swapping out the part and observing the exact same failure (pretty much eliminates assembly, solder short, etc.), then by measuring and scoping around the card.
The fascinating read doesn’t stop with the article. Make sure you work your way through the comments thread. [Steve] thinks he’s eliminated the idea of bad microcontroller code causing damage. He considers putting in-line resistors on the DB connector but we wonder if clamping diodes wouldn’t be a better choice (at least for testing purposes)? This begs the question, why is he observing a higher voltage on those I/O lines during power-up? As always, we want to hear your constructive comments below.
Fail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.
Gameplay is simple – users type their command (Up, Down, A, B) into their IRC or web client. In the original configuration, commands were processed in the order they arrived at the game. The system worked until the whole thing went viral. With thousands of people entering commands at any given time, poor “RED” would often be found spinning in place, or doing other odd things. The effect is so compelling that even [Randal Munroe] has written an XKCD entry about it. To help the players get through some of the tricky parts of the game, [TPP’s creator] added a game mode selection. Users can play in “Democracy” where the system takes votes for several seconds, then issues the highest voted command. The original anything goes game mode was renamed “Anarchy”. Switching from one mode to the other is determined by the users themselves in real-time.
While the hardware upgrades are impressive, there’s been a lot of work on the Bitbox software as well. A new game demo called Fire was created as a set of tutorials to help people start developing for the console. There’s also a BitBoy, a GameBoy emulator for the Bitbox. BitBoy is a ported version of gnuboy for the ARM Cortex-M4 processor that powers the Bitbox. It successfully emulates a number of commercial GameBoy ROMs.
We’re looking forward to seeing what’s next for the Bitbox. After the break, check out a video of BitBoy running on the Bitbox.
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.