Tag Archives: 8-bit

Turning an NES into the ultimate 8-bit game console

This system transforms 8-bit side-scrolling console video games into totally immersive multiplayer experiences.

There’s no denying the nostalgic appeal of blowing into a Super Mario Bros cartridge, slipping it into your Nintendo Entertainment System and immersing yourself in an 8-bit world of blocky graphics and chiptunes. The side-scrolling game that we all grew up playing in our family rooms is pretty limited, though. You constantly move forwards, jumping over obstacles and hitting blocks, until you get to the end of a level — that’s about it. There’s no going back, you can’t zoom out and you can only have a maximum of two players.


What if there was a way to transform the beloved game into a collective, totally immersive experience? That’s exactly what a group from ETH Zurich and Disney Research set out to accomplish by developing the world’s first cooperative 8-player, 8-bit NES capable of continuous, panoramic side-scrolling.

For this endeavor, the team employed a real NES with real cartridges, giving it a true old-school effect. And it should be pointed out that there was no hacking of the actual console; instead, its creators enhanced the game using DIY hardware and software that multiplexes eight gmepad inputs to automatically handoff control from one pad to the next.


To connect eight controllers to the NES, they used an Arduino (ATmega328)-based multiplexer. Video from the NES is fed through an upscaler to get the output up to a solid 576p at 50Hz, whereas audio output goes directly from the NES to the room’s sound system.

Meanwhile, the NES output video signal is first captured and sent for analysis. A “tracking PC” running custom software processes the video stream, tracks the background and creates a wide, panoramic image. This image is then sent to a media server, which outputs the stream via eight projectors — two for each wall. Ars Technica notes that the tracking PC also has a real-time GPU algorithm to correct any distortion, enabling it to display clear graphics.


The Arduino multiplexer has two modes of operation: it can either cycle through each gamepad after a fixed amount of time, or the tracking PC can let the Arduino know to change to a specific gamepad, depending on where the players are in a level.

Once complete, the researchers tested the impressive system at a gathering with over 400 guests inside a Swiss night club. As you can imagine, it was a hit! The hope is that it will bring an entirely new level of social interaction to traditional game play. Think about it: Partygoers can swap in and out as they attempt to go from level to level, all while adding a unique ambiance to the environment. (Not for anything else, it can surely make for one heck of a drinking game!)


For those who don’t happen to have several projectors or giant walls, not to worry. The platform supports a virtual reality version as well, which reproduces a similar environment using an Oculus Rift headset.

Intrigued? Head over to the researcher’s official page to see how they’re ‘unfolding the 8-bit era.’ You can also head over to Ars Technica’s writeup or simply watch it in action below.

[h/t Ars Technica via ETH Zurich]

This MIDI synth lets you create Nintendo-style chiptune music

Connect this AVR-based board to a MIDI device and make your own NES-style chiptunes.

Chiptunes are a type of synthesized, electronic music produced by old-school video game consoles, which became ubiquitous throughout arcades and living rooms in the ‘80s. Originally, 8-bit tunes were primarily practiced by game soundtrack composers like Rob Hubbard; yet, it wasn’t before long that tools like Karsten Obarski’s Ultimate Soundtracker were introduced, making the creation of such sounds much easier and widespread. While it mostly remained an underground genre, chiptunes certainly had their moments of moderate popularity, influencing the development of electronic dance music for years to come.


Who could forget the routine of pulling out your Mario Bros. cartridge, blowing into it, slipping it back in, and once successful, being welcomed by its catchy theme song? Well, those looking to spark up some nostalgia will surely get a kick out of the Arcano MIDI NES Chiptune Synthesizer, an AVR-based MIDI device that allows artists to make Nintendo-style chiptune music.

Each Arcano MIDI NES Chiptune Synthesizer is equipped with a 1/8” mono audio output jack, MIDI input through a standard DIN connector, a seven-segment LED waveform mode indicator, a simple two-button interface, and a preprogrammed ATmega328 for its brains. Beyond that, a six-pin AVR ISP header enables programmers to Flash the embedded MCU with their own custom software and create waveforms, envelopes, software low-frequency oscillators and PCM samples.


Unlike many other MCU-based synthesizers which use internal PWM peripherals to generate weak, scratchy audio signals, the Arcano MIDI NES Chiptune Synthesizer employs an auxiliary digital-to-analog converter chip to produce a clear, high-quality audio signal. The synth is capable of generating audio at an output rate of 44.1 KHz; however, for a more authentic chiptune sound, lower output rates are recommended.

“The hardware is capable of up to 8-bit quantization. A software bitcrusher is used to achieve the lower bit depths used in the NES. This bit-crushing effect is most evident in the Arcano NES Chiptune Synthensizer’s reproduction of the Nintendo Entertainment System’s 4-bit triangle wave channel, often used for bass lines and tom-tom drums,” its creators explain.

What’s more, the latest version of its software features additional white-noise-based percussion sounds, such as open and closed hi-hats, along with additional waveform modes that can emulate the detuned reverb effects characteristic of the music from the Mega Man series of NES games.

Ready to recreate some magical 8-bit music? Head over to the synthesizer’s Kickstarter page, where Arcano Systems successfully garnered well over its asking goal of $1,000. The first batch of units have already begun shipping.

This embedded ukulele can teach you to play chords and songs

Of course, just moments after completing our list of Maker musical masterpieces, we came across the nifty ukule-LED, an LED-embedded ukulele that uses lights to instruct how to play chords and songs.


Designed by Cornell students Raghav Subramaniam and Jeff Tian, ukule-LED is equipped with 16 NeoPixels that are situated along the first four positions of the fretboard. This allows those playing the device to easily learn how to play each chord. All of the 16 LEDs are connected in series to a single pin on the ATmega1284P that sits on a board mounted to the bottom of the ukulele along with power and serial.


ukule-LED has two modes of operations: “Play” and “Practice.” First, in “play” mode, the user can feed the system a song file, a text file that contains the tempo, time signature, and an ordered listing of the chords in a song. The ukulele will then light up the correct chords at the correct times in the song. (Think of it like Guitar Hero.) While in “practice” mode, the user can specify a single chord, which is lit up indefinitely. For those more experienced musicians, the ukule-LED can still serve as an excellent chord reference.


“Our inspiration for this project comes from a variety of sources. Our idea to upgrade a musical instrument using LEDs comes from various Hackaday articles, including this one. We considered using LEDs to augment a couple of other instruments, including a keyboard and a guitar, before settling on a ukulele,” Subramaniam and Tian explain.


Once mastering the earlier stages of the string instrument, those wishing to build upon their existing skills can do so thanks to ukule-LED’s extension capabilities. Currently, the system only supports major, minor and 7th chords, which light up in green, red and blue, respectively. The Makers note that the project was built using an open, highly expandable Python script available for download.

See the DIY ukulele in action below!

Interested in fine tuning your strumming skills? Head on over to its official project page here.

8- or 32-bit, that is the question…

Writing for Electronic DesignAtmel’s Ingar Fredriksen and Paal Kastnes recently explored the latest market trends for both 8- and 32-bit microcontrollers (MCUs). While the 32-bit MCU devices continue to rise in popularity throughout the embedded community, 8-bit MCUs are still experiencing a CAGR close to that of their bigger cousins.

These 32-bit, function-rich devices suit an array of different applications, which explains why many embedded developers select them for their next designs. Designers recognize that such complex devices offer everything they need in terms of raw compute power, a rich peripheral set, and easy access to a wide range of development tools and libraries.

Many of these 32-bit devices — which are members of the Atmel | SMART family — are based on the highly-successful ARM cores. Thus, developers feel confident in having access to second source devices and a comprehensive set of development, test and validation tools being available in the market.

However, taking a closer look at recent MCU market trends has revealed that 32-bit devices aren’t the only ones experiencing strong growth. The surging 8-bit MCU market boasts a CAGR (6.4%) close to that of 32-bit (6.9%). Meanwhile, a number of other industry analysts forecast identical growth rates for 8- and 32-bit microcontrollers.

The upswing in 8-bit devices, like the incredibly popular Atmel AVR lineup, clearly highlights that there must be some compelling reasons to use an 8-bit device in place of a 32-bit MCU. The recently-published Electronic Design article looks to shed some insight as to why 8-bit devices are retaining market share.

Essential Differences

The principle differences between 8- and 32-bit MCUs are cost and price structure, CPU performance, ease of use, efficiency in hardware near functions, and static power consumption. When embarking on a new design, developers need to carefully scope out the requirements for an MCU based on the amount of processing capability required, the degree of interfacing needed, and, for battery-powered designs, the all-important power consumption profiles. There’s no doubt that a 32-bit MCU delivers higher performance than an 8-bit device, but the engineer faces the traditional decision of choosing between the best available device in the market versus an application’s actual needs.


Of course, these decisions will greatly influence the likely bill of materials (BOM) cost. With a lower gate count, a less complex 8-bit device will certainly be cheaper than a 32-bit device. When comparing 8- and 32-bit MCUs from leading vendors, each with a similar amount of flash memory, pin-out etc., 8-bit devices typically cost about 20% less. But this is only the first of many considerations. Another aspect relates to the ease in setting up for a new development.

Ease of Development

MCU suppliers tend to add more features and functionality to their 32-bit devices as opposed to 8-bit products. Consequently, far more setup considerations emerge with a more complex device. While some 32-bit MCUs can run with a limited setup similar to that of an 8-bit device, you’re unable to take advantage of the more powerful device’s additional features.

For example, a typical 32-bit ARM device will have independent clock settings for the core itself, the AHB bus, the APBA bus, and the APBB bus. They all can be set to different frequencies. Typically, you will also have to switch to the clock you want to use because it’s set in software, not in hardware like most 8-bit parts. Furthermore, changing the clock means you must set up the wait states for flash, possibly predicated on measured VCCvoltage.

Such a setup can be much simpler with an 8-bit MCU, though. For example, Atmel’stinyAVR and megaAVR products only require initialization of the stack pointer, which typically takes four lines of code, prior to coding the application. The choice of clock, brownout detector, reset pin function, etc., is all pre-programmed into the device.

The architecture is also much more straightforward than a 32-bit device with internal registers, peripherals, and SRAM all mapped on the same data bus. The peripherals and CPU would normally run at the same frequency, so no peripheral bus configuration is necessary. Moreover, designers can avoid being concerned about latency in synchronizing between different clock domains.


When it comes to desired CPU performance, the engineer should consider all use cases. The reality is that many embedded designs don’t have high compute requirements. Often, very little manipulation of data is required, so balancing those needs against power-consumption and peripheral-interfacing requirements becomes crucial.

For instance, a simple thermostat application will spend most of its life in a sleep mode. Every so often, it will wake up and measure the temperature and then make a decision to turn a relay on/off or send an instruction to a host controller. Then it will resume sleep. The compute and interface requirements of this application are small, but many other applications such as fire detectors, power tools, flow meters, and appliance controls have a similar use profile, too.

Efficiency of Hardware Near Functions

Many modern microcontrollers incorporate some hardware functions that serve to help the CPU operate as efficiently as possible. In Atmel’s case, both the 8-bit AVR and 32-bit ARM-based MCU families feature the Peripheral Event System. An event system is a set of hardware-based features that allows peripherals to interact without intervention from the CPU. It allows peripherals to send signals directly to other peripherals, ensuring a short and 100% predictable response time.

When fully using the capabilities of the event system, the chip can be configured to do complex operations with very little intervention from the CPU, saving both valuable program memory and execution time. In the case of detecting a hardware event, it’s important to first detect the event and then switch control to the desired interrupt service routine (ISR).

In these situations, CPU speed isn’t the single determining factor. It’s a question of how long, in terms of cycles, does it take to respond to the interrupt, run the ISR, and return. As the following example will show, 8-bit devices can be more efficient in handling hardware near actions.


Consider receiving one byte on the SPI, using an interrupt to detect it, and then running a simple ISR routine to read the byte from the SPI peripheral and store it in SRAM. Using this scenario, table above draws comparisons between an Atmel 8-bit AVR device and an Atmel ARM Cortex M0+based 32-bit MCU. Calculated with information available, the results are based on minimum implementations. However, engineers should check with their own applications since the interrupt detection and return from interrupt could take more cycles than shown in the table. Requiring 12 cycles versus 33 cycles equates to having a theoretical maximum SPI bandwidth of 1.67 MB/s for the 8-bit CPU and a 606 kB/s bandwidth for a 32-bit CPU when running at 20 MHz.

The degree of numeric processing can also have an impact on the stack and required memory. Applying the Fibonacci algorithm is one particularly good method for testing memory requirements. Since it only uses a local variable, everything needs to be pushed to the stack.

When making a comparison between an 8-bit AVR and an ARM 32-bit CM0+-based device, and using a recursive 15-stage Fibonacci algorithm, the AVR uses a total of 70 bytes of stack, including 30 for return stack (15 calls deep). The ARM-based device uses 192 bytes (60 should be return stack). This means the CSTACK is more than three times the size of the 8-bit solution. In typical C code, more of the variables on the stack often come in a packed format, so this is an extreme corner. However, saying 1.5 to 3 times more SRAM is needed for the same 8-bit-centric application on a 32-bit (versus a native 8-bit) device is a fair estimation.

Power Consumption

No MCU article would be complete without investigating static power consumption. This alone may be a key factor in choosing between an 8- or 32-bit device, especially for battery-powered applications. The table below illustrates power-consumption differences between 8- and 32-bit devices in both active and static modes.


Aggressive manufacturing technologies increase transistor leakage current, which roughly doubles with each process generation, and is proportional to the number of gates. Leakage current increases exponentially at higher temperatures, which can be easily overlooked when designing a consumer design. Mobile phones and personal media players are transported everywhere, and as we have all found out, temperatures experienced during the summer inside a car can easily climb above 40°C.

The amount of time the microcontroller will spend in active mode versus static mode contributes significantly to the overall application power budget.

Naturally, the ratio between active and static modes will vary depending on the application requirements. Taking the previous SPI interrupt example (second table from above) and assuming a SPI data bandwidth of 80 kb/s, the 8-bit CPU will spend 1.2% of its time in active mode compared to that of the 32-bit, which will spend 3.3% in active mode (table below).



Contemplating whether to use an 8- or 32-bit microcontroller for a future design may involve an Internet of things (IoT) application. How IoT actually takes shape provokes lots of debate, but it will certainly challenge engineers to make a detailed appraisal of the MCU requirement. Wireless connectivity, especially ZigBee, will also be an essential component, but that doesn’t automatically mean that it will need a higher power device.

A number of available 8-bit microcontroller products satisfy the need for low levels of processing and wireless connectivity. One such example is the Atmel ATmegaRFR2 series, which provides an IEEE 802.15.4-compliant, single-chip, 2.4-GHz wireless microcontroller solution that suits battery-powered, low-cost IoT designs.

Interested in reading more? Be sure to check out the original article from Electronic Design here.

Going back to the beginning of AVR with Vegard Wollan

The first episode of this series talked about the very beginning history of the AVR microcontroller chip co-invented by Vegard Wollan. In this clip, we delve into the beauty of Flash memory.

As mentioned in the previous post, engineers used to have to develop their firmware using special ceramic chips with quartz windows.


This early microcontroller has a quartz window in its expensive ceramic package so you can erase the program in an ultraviolet eraser.

Bad enough the chips themselves cost a lot, the real headache was when you had to debug or change your program. You had to pry it out of its socket, and stick it in a ultraviolet eraser for 20 minutes. This really slowed down your code development. It was like playing tennis in molasses.


This UV eraser was used to erase the microcontroller program memory so you could reprogram it with something that you hoped would fix the bugs.

That is what Vegard realized back in the early 1990s: You could make a microcontroller using Flash memory and reprogram in seconds, not hours. Atmel already had a Flash 8051-style micro, so we were a natural to develop the AVR chips.

The aforementioned video touches on the low-power heritage of AVR, which as you already know, Atmel memory products are famous for extremely low power. This advantage was “baked into” the AVR products, since they knew that many applications would run on battery power.

Vegard was also nice enough to bring some early AVR prototypes from his lab in Norway.

Vegard Wollan holds one of the first 10 AVR prototype chips, the S1200.

Vegard Wollan holds one of the first 10 AVR prototype chips, the S1200.

When Vegard holds up the various prototype chips, you can see the pride of an innovator on his face. I think every engineer gets a real charge out of that first prototype, as even I have a collection of my own at home.

In case you missed our earlier segment on the history of AVR, you can check that out here. Feeling inspired to create and share your own 8-bit ideas? Enter them in our Simply AVR Design Contest today for your chance at $1,500!

ATmega8 powers this pool cleaning robot

Pools are great, especially in these summer months. Cleaning them, however, not so much. A Maker by the name of David Gironi has simplified this process by powering an automated pool cleaner with an Atmel ATmega8-controlled timer.


James Hobson over at Hackaday alerted us to Gironi’s Atmel-powered cleaning unit. After the Maker’s store-bought pool cleaning unit failed, in true DIY fashion he decided to employ some technology to fix the robot on his own. The project is broken down into two parts, the ATmega8-based timer and the underwater cleaning robot.


According to the Maker, the ATMega8-powered timer alternates between a “working” and “pause” periods. As a result, Gironi can run the robot at a predetermined interval of days, for any designated time period, i.e. 30 minutes. The out-of-water timer is responsible for converting 220VAC to low voltage DC for the robot. Apart from the timer, the robot itself features two motors. One of the motors pumps the water through the unit to filter it, the other to maneuver the cleaner under the surface.

To delve deeper in the Maker’s design, head over to his in-depth blog piece here.

Video: Interactive m!Qbe redefines lighting

The Atmel-powered m!Qbe is an intuitive, interactive platform that allows users to easily control multiple lights. The system comprises a number of components, including the m!Qbe (central) module, m!base, m!charger and WiFi.

The m!Qbe is designed to be used in one room with an m!Base and should, depending on the layout, cover a circle with a diameter of 20 meters.

“Just flip it and switch to the suitable lighting situation for your current activity such as low yellowish light to relax on the couch, bright white light to read the newspaper or different colors for your birthday party,” an m!Qbe rep explained in a recent Indiegogo post.

“Use it in everyday life with many more possibilities than a traditional light switch and much faster than manual control on a mobile device.”

Indeed, the m!Qbe’s three faces, or sides, are designed to “memorize” specific settings.

“You predefine them once and recall them whenever you like,” said the rep.

“In addition, you can add a delay on every favorite. So you can go to bed or leave your home in bright light for instance. The m!Qbe [will] automatically turn off all your [lights] after a while.”

As you can see in the video above, the m!Qbe can be rotated to manually change color or brightness, while a brief touch on the icon switches from one light to another, allowing the user to easily select and adjust specific fixtures.

So, how does the platform work?

 Essentially, the m!Base component communicates with the m!Qbe and the network of lights.

“It converts the detected motion into lighting situations and provides access to the settings of the m!Qbe,” the rep continued.

“The installation of the m!Base is a plug and play solution. In its standard configuration you connect the m!Base with a cable to your network. If you want to connect it wirelessly, please order the WiFi option.”

As noted above, the m!Qbe is built around an Atmel 8-bit microcontroller (MCU), which uses data generated from a three-axis acceleration sensor and a three-axis gyro sensor to precisely calculate motion.

“Additionally on each of the two manual faces, a capacitive touch sensor is integrated and allows to detect touch actions of different lengths. In the m!Base a Linux system transfers the commands received via bluetooth from the m!Qbe to commands for every single lamp in the network,” the rep added.

“For the configuration of this transfer and to read out statistical information a web interface is implemented. If you want to extend the functions of the m!Qbe the easiest way is to modify the software of the m!Base.”

Last, but certainly not least, m!Qbe supports the Philips Hue system that includes not only the connected bulbs but also Friends of Hue such as LightStrips and LivingColors Bloom, along with dimming plugs for more traditional lamps.

Interested in learning more? You can check out the official m!Qbe page on Indiegogo here.

Agricultural monitoring with Atmel AVR

Calibit is a digital caliper equipped with an AVR-powered data logger that allows the device to efficiently monitor hectares of orchards.


The datalogger – based on an 8-bit Atmel microcontroller (MCU) – features 128Kb EEPROM memory, LCD display, USB/UART slots, watch/calendar, as well as a rechargeable lithium battery with integrated safety system and temperature control.

“[This] new technology promotes the monitoring of fruit growth as it simplifies data collection – 15-20 minutes is all it takes to gather enough data to monitor each hectare,” a FreshPlaza writer explained in a recent article.


“[Plus, users can] create multiple measuring sessions to group data and improve management, [with] the USB cable and software enabling data downloads in CSV format.”

Although Calibit was originally designed to monitor fruit growth, the platform is capable of supporting a wide-range of applications including:

  • Cooperatives and collection warehouses to sample fruit before processing
  • Plant nurseries to verify the diameter of striplings, branches and trunks
  • Mechanical and carpentry workshops
  • Scientific laboratories


Interested in learning more? You can check out Calibit’s official product site here. Readers may also want to browse through some of our previous stories on technology and farming including “The Internet of Things, Stalk by Stalk,” “Smart Urban Aquaponics in West Oakland“, “DIY Farming with Atmel and Arduino” and “Open Source Aquaponics with APDuino.”

Video: This vuvuzela is also a (soccer) remote

beIN has introduced a fully-functioning (and loud) vuvuzela that can also be used as a remote control.

When the aptly-named GameChanger is blown, a mini microphone recognizes the vuvuzela sound signature, instructing the platform’s 8-bit, Atmel-based microcontroller (MCU) to respond. The MCU then sends IR LED signals to a cable box – commanding it to change the channel to beIN sports.

The GameChanger was designed by BeIN’s agency, TBWA\Chiat\Day New York and prototyped on an Atmel-based Arduino board.

“Soccer fans are diehard fans, they will get up at any hour of the morning to watch a game, but in the U.S. soccer is kind of like the ugly stepchild of sports compared to football or basketball,” Ed Rogers, account executive at TBWA\Chiat\Day New York told DigiDay.

“We wanted to create something that shows soccer fans that we really understand their passion.”

Interested in learning more? You can check out the GameChanger’s official page here and DigiDay’s full write up here.

Sir Mix-A-Lot raps and rhymes with Atmel

Throwback Thursdays at Atmel are always quite popular, although it isn’t every day that our tech tweets attract the attention of a celebrity rapper like Sir Mix-A-Lot (a.k.a. Anthony Ray).

“We like 8-bits and we cannot lie. All you other Makers can’t deny,” we tweeted about our lineup of 8-bit microcontrollers (MCUs).

The chippy pun, made in the style and tune of the ’90s hit “Baby Got Back” (from the album Mack Daddy), prompted Sir Mix-A-Lot to tweet:

“I like my mosfets wide & juicy. That bandwidth has to double. 30mhz bubble, high frequency RF trouble.”

Sylvie Barak, a former EETimes reporter who now works in Atmel’s communications department, told AllThingsD that having Sir Mix-A-Lot join the online conversation was a big surprise.

“At first I was a little skeptical it was actually him, but a quick Internet search … revealed he’s actually quite the techie,” Barak confirmed. “His rhymes were awesome.”

Sir Mix-a-Lot is an American MC and producer based in Seattle, Washington. The founder of the Nastymix record label, he debuted in 1988 with Swass. Sir Mix-a-Lot is best known for his 1992 album Mack Daddy and its Grammy Award-winning single “Baby Got Back.”