It’s no secret that Commodore users love their old machines with the Commodore C64 being chief among them with 27 Million units sold worldwide. Speaking as a former Commodore Business Machines (CBM) engineer the real surprise for us is the ongoing interest and devotion to an era typified by lumbering 8 bit machines and a color palette consisting of 16 colors. Come to think about it, that’s the description of Minecraft!
Jump forward to today and it’s a generation later. We find that the number of working units is diminishing as age and the laws of entropy and physics take their toll.
Enter the Commodore Pi, an emulated Commodore 64 operating system for the Raspberry Pi. The goals of the project include an HDMI and composite compatible video output, SID based sound, Sprites and other notable Commodore features. They also plan to have hooks for more modern technology to include Ethernet, GPIO and expansion RAM.
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.