The only thing that matters in this world is the likes you get on social media platforms. To that end, YouTube has been sending out silver and gold play buttons to their most valuable creators. [Sean] hasn’t screamed into a microphone while playing Minecraft long enough to earn one of these play buttons, so he decided to build his own.
This play button isn’t just a bit of pot metal ensconced in a frame brought to you by Audible dot com; this YouTube play button actually does something useful. It’s a PCB with 144 LEDs working together as a display. There’s an Atmel SAMD21 microcontroller on board to drive the LEDs, and an ESP8266 to pull data down from the Internet. What data is worthy enough to go on an Arduinofied YouTube play button? The subscriber count for [Sean]’s channel, of course. Go subscribe, it might crash his Play button.
Admittedly, there were a few problems with this Play button PCB. Firstly, the ESP8266 can’t directly communicate with the YouTube API to pull down the subscriber count. That problem was fixed with a Raspberry Pi that could connect to the API, and programming the ESP to pull the data from the Pi. Second, this was [Sean]’s first experiment with double-sided SMD boards reflowed in a toaster oven. The first side to be assembled was easy, but to get the second side on, [Sean] turned to low-temp bismuth solder paste. Except for a small error in assembling the board, everything worked as planned.
It’s a great project, and if you want to check out what the better parts of YouTube look like, check out [Sean]’s video below. Don’t forget to rate, comment, like, unlike, or subscribe.
Ever so slowly, the main storage in our computers has been moving from spinning disks, to SSDs over SATA, to Flash drives connected to a PCI something or other. The lastest technology is NVMe — Non-Volitile Memory Express — a horribly named technology that puts a memory controller right on the chip. Intel has a PCI-based NVMe drive out, Samsung recently released an M.2 NVMe drive, and the iPhone 6S and 6S Plus are built around this storage technology.
New chips demand a reverse engineering session, and that’s exactly what [Ramtin Amin] did. He took a few of these chips out of an iPhone, created a board that will read them, and managed to analize the firmware.
Any reverse engineering will begin with desoldering the chip. This is easy enough, with the real trick being getting it working again outside whatever system it was removed from. For this, [Ramtin] built his own PCIe card with a ZIF socket. This socket was custom-made, but the good news is you can buy one from ITEAD. Yes, it is expensive — that’s what you get with a custom-made ZIF socket.
With the chip extracted, a custom PCIe card, and a bit of work with the NVMe implementation for Linux, [Ramtin] had just about everything working. Eventually, he was able to dump the entire file system on the chip, allowing anyone to theoretically back up the data on their iPhone or MacBook Air. Of course, and especially for the iPhone, this data is encrypted. It’s not possible to clone an iPhone using this method, but it is a remarkably deep dive into the hardware that makes our storage tick.”
Over the past few years, the BeagleBone ecosystem has grown from the original BeagleBone White, followed two years later by the BeagleBone Black. The Black was the killer board of the BeagleBone family, and for a time wasn’t available anywhere at any price. TI has been kind to the SoC used in the BeagleBone, leading to last year’s release of the BeagleBone Green, The robotics-focused BeagleBone Blue, and the very recent announcement of a BeagleBone on a chip. All these boards have about the same capabilities, targeted towards different use cases; the BeagleBone on a Chip is a single module that can be dropped into an Eagle schematic. The BeagleBone Green is meant to be the low-cost that plays nicely with Seeed Studio’s Grove connectors. They’re all variations on a theme, and until now, wireless hasn’t been a built-in option.
This weekend at Maker Faire, Seeed Studio is showing off their latest edition of the BeagleBone Green. It’s the BeagleBone Green Wireless, and includes 802.11 b/g/n, and Bluetooth 4.1 LE.
As all the BeagleBones are generally the same, each with their own special bits tacked on, it’s only fair to do a line by line comparison of each board:
While the BeagleBone Blue is still in the works and due to be released this summer, the BeagleBone Green Wireless fills the WiFi and Bluetooth niche of the BeagleBone ecosystem.
As with any single board computer with a fast ARM chip running Linux, comparisons must be made to the Raspberry Pi. Since this is the first BeagleBone released with wireless connectivity baked into the board, the most logical comparison would be against the recently released Raspberry Pi 3.
The Pi 3 includes an integrated wireless chipset for 802.11n and Bluetooth 4.1 connectivity. The BeagleBone Green Wireless has this, but also adds 802.11 b and g networks. This gives the BBGW the ability to sense when anyone is using a microwave in the vicinity – a boon for that Internet of Things thing we’ve been hearing so much about.
Unlike the Pi 3, the BBGW has connections for additional antennas in the form of two u.FL connectors. While the Pi 3 can be hacked to use external antennas, it’s not a job for the faint of heart. The availability of external antennas in a small, compact, low-power format is the ideal solution for any wireless network connectivity dealing with range or a congested network.
The BeagleBone Green Wireless is a Seeed joint, and as with the original BeagleBone Green, there are Grove connectors right on the edge of the board. These connectors provide one I2C bus and one serial connection each for Seeed Studio’s custom modules.
To be honest, I’m of two minds when it comes to Seeed’s Grove connectors. On one hand, breadboards and DuPont cables already exist, and with the two 46-pin headers on the BeagleBone Black, there was nothing you couldn’t wire into the BeagleBone Black. The addition of Grove connectors seems superfluous, and in the most cynical view, merely an attempt to make a system of proprietary educational electronics.
On the other hand, there really isn’t any system of easy to use, plug-in modules for the current trend of educational electronics. Just a few years ago, people were putting out boards with RS-442 into RJ45 sockets. We don’t have DE-9 connectors anymore, and a smaller, easier to use connector is appreciated, especially when the connectors are a mere $0.15/piece.
Then again, the intelligence of a Grove module is purely dependant on the operator. On the BeagleBone Green, there are two Grove connectors, one for I2C, and another for serial. Apart from some silkscreen, there is no differentiation between these two connectors. On the Grove base cape, there are exactly four different implementations using the Grove connectors: four I2C, four digital I/O, with two GPIOs each, two connectors dedicated to analog input, and two serial ports. This is the simple way to connect a lot of devices via common wires; it is not the most user friendly.
The BeagleBone Green Wireless doesn’t really do anything new. The SoC is the same, and of course the PRUs in every BeagleBone are the killer feature for really, really fast digital I/O. The addition of WiFi is nice, and the inclusion of extra antenna connectors phenomenal, but it’s nothing a USB WiFi dongle couldn’t handle.
If anything, the BeagleBone Green Wireless is a signal for the future of the BeagleBone platform. The number of versions, each with their own small take on connectivity, is the bazaar to the Raspberry Pi’s cathedral. It’s encouraging for any fan of Open Hardware, and at the very least another tool in the shed.
The 6502 is the classic CPU. This chip is found in the original Apple, Apple II, PET, Commodore 64, BBC Micro, Atari 2600, and 800, the original Nintendo Entertainment System, Tamagotchis, and Bender Bending Rodriguez. This was the chip that started the microcomputer revolution, and holds a special place in the heart of every nerd and technophile. The 6502 is also possibly the most studied processor, with die shots of polysilicon and metal found in VLSI textbooks and numerous simulators available online.
The only thing we haven’t seen, until now, is a version of the 6502 built out of discrete transistors. That’s what [Eric Schlaepfer] has been working on over the past year. It’s huge – 12 inches by 15 inches – has over four thousand individual components, and so far, this thing works. It’s not completely tested, but the preliminary results look good.
The MOnSter 6502 began as a thought experiment between [Eric] and [Windell Oskay], the guy behind Evil Mad Scientist and creator of the discrete 555 and dis-integrated 741 kits. After realizing that a few thousand transistors could fit on a single panel, [Eric] grabbed the netlist of the 6502 from Visual6502.org. With the help of several scripts, and placing 4,304 components into a board design, the 6502 was made dis-integrated. If you’re building a CPU made out of discrete components, it only makes sense to add a bunch of LEDs, so [Eric] threw a few of these on the data and address lines.
This is the NMOS version of the 6502, not the later, improved CMOS version. As such, this version of the 6502 doesn’t have all the instructions some programs would expect. The NMOS version is slower, more prone to noise, and is not a static CPU.
So far, the CPU is not completely tested and [eric] doesn’t expect it to run faster than a few hundred kilohertz, anyway. That means this gigantic CPU can’t be dropped into an Apple II or commodore; these computers need a CPU to run at a specific speed. It will, however, work in a custom development board.
Will the gigantic 6502 ever be for sale? That’s undetermined, but given the interest this project will receive it’s a foregone conclusion.
Today, Apple has announced their latest bit of hardware. Following in the tradition of the Raspberry Pi, BeagleBone, and the Intel Edison, Apple have released a single board computer meant for embedded and Internet of Things applications. It’s called the Apple Device, and is sure to be a game changer in the field of low-power, Internet-enabled computing.
First off, some specs. The Apple Device uses Apple’s own A8 chip, the same dual-core 64-bit CPU found in the iPhone 6. This CPU is clocked at 1.1 GHz, and comes equipped with 1GB of LPDDR3 RAM and 4GB of eMMC Flash. I/O includes a Mini DisplayPort capable of driving a 4k display, 802.11ac, Bluetooth, and USB. In a massive break from the Apple zeitgeist of the last decade or so, the Apple Device also includes a forty pin header for expansion, much like the Raspberry Pi, BeagleBone, and Edison.
Although Apple’s first foray into the embedded computing market is a shocker, in retrospect it should come as no surprise; the introduction of HomeKit in iOS 9 laid the groundwork for an Internet of Apple Devices, embedded into toasters, refrigerators, smart homes, and cars. The Apple Device lives up to all these expectations, but what is the hands-on experience like?
See our review of the Apple Device after the break.
The first question anyone should ask when discussing an Apple Internet of Things board is, ‘what operating system does it run?’ This is, by far, the most pressing concern – you don’t need a purely graphical OS with a headless machine, and you don’t want an OS that is locked down with proprietary cruft.
Of course. the idea that Apple is built upon proprietary and locked down operating systems is a myth. iOS and Mac OS are built on Darwin, an open source kernel based on BSD. This is the core of the DeviceOS, and booting the device (through a terminal, no less!) provides everything you could ever need in a tiny, single board computer.
Apple isn’t committing themselves to a purely command line board here, though. Apple hasn’t built a computer like that for more than 30 years. There’s a Mini DisplayPort on the Apple Device, and of course that means a GUI. It’s obviously not as capable as the full feature OS X, but it is very useful. It’s not iOS, either; I’d compare it to a Chromebook – just enough to do the job, and not much else.
While the Apple Device is intended to run headless most of the time, in fact it’s how Apple expects you to set this device up.
To power the device, all you need to do is connect the Device to a computer and open up a terminal. This drops you into the Device’s shell, with access to the entire unix-ey subsystem. Once the WiFi credentials are set, just unplug the device from the computer, plug it into a micro USB charger, and the Device is connected to the Internet.
This USB port isn’t just for power – it’s also the way to connect keyboards, mice, peripherals, and USB thumb drives. You will, however, need the Apple Powered Device USB Hub (sold separately), that breaks out the USB into four USB Type A ports while backpowering the Apple Device. It’s a brilliant physical user interface for a device that will run headless most of the time, but still requires a few ports to be useful.
Of course, if you’re not running the Apple Device headless, you’ll need to connect a monitor. This is where the Mini DisplayPort comes in. Boot the device with the Powered Device USB Hub, plug in a monitor, and you’re presented with a ‘desktop’ that’s not really OS X, and it’s not really iOS, either. It’s minimal, and almost chromebook-esque.
The OS looks a little bit like OS X, but it’s not. Right now, the only programs available for the DeviceOS are the HomeKit app, the Safari browser, and playing around with the settings. If you want to look something up on the Internet, just click on the Safari icon. If you want to change the WiFi address or the device name, just go into the settings.
Configured as a Desktop, you can see the brilliance of Apple in the Device. It’s not a desktop computer, but neither is a Chromebook. Considering most people can do most of their work on the web, this is a game-changing device. Combine it with Apple’s iCloud, and you have something that will be exceptionally popular.
The Downside of Apple
Apple has their hands in a lot of cookie jars. The Apple TV is their device for streaming videos and music to a TV. Giving the Apple Device this functionality would cut into sales of the Apple TV. Since the Apple Device sells for $100 less than the Apple TV, this would be a bad move, even if Apple is sitting on Billions in cash.
Also, even though the Apple Device has a 40-pin header right on the board, there is no documentation anywhere of what these pins can be used for. The Raspberry Pi’s 40-pin header is well documented and can be used for everything from environmental sensors to VGA and audio output. Apple makes no mention of what these pins can do, although we do expect a few ‘shields’ to be released in short order.
Built around the Apple A8 chip, the Apple Device is extremely capable, especially compared to its assumed competitors, the Raspberry Pi and Intel Edison.
In terms of raw horsepower, the Apple Device handily beats out the Raspberry Pi 2 and the Intel Edison. This should be expected. The A8 chip in the Apple Device is extremely powerful and beats the other single board computers handily.
But what about graphics? The GPU in the Raspberry Pi is a huge reason why that board is popular, and being able to stream a few movies to the Apple Device would mean the Apple TV will be quickly taken out of production.
3D acceleration is better, but when it comes to h.264 encoding, the Apple Device falls a little short. Even compared to the rather sluggish Raspberry Pi Zero, the Apple Device is no match for the berry boards.
This is purely speculation, but I suspect h.264 encoding is disabled in the Apple Device. The reason is clear – Apple already sells a single board computer meant for streaming video to a TV. Giving the Apple Device the same capabilities as the Apple TV would cut into that market. Sadly, it looks like the video capabilities of the Apple Device are limited to digital signage. That’s disappointing, but given Apple’s strategy for the last twenty years, not unexpected. We do look forward to the eventual hack, root, or exploit that will unlock the powerful graphics capabilities the A8 chip already has.
Right off the bat, the Apple Device is an amazing piece of hardware. It’s incredibly small, has a lot of computational power, and works with all the HomeKit devices you already own. The ability to just plug it into a computer and have a tiny *nix device connected to the Internet is great, and comparing the user interface to the Raspberry Pi, Beaglebone, or any of the Intel offerings isn’t even a fair comparison. Apple has taken the best design from their entire product line that anyone – including engineers and the tech literati – would find useful.
However, there are a few glaring limitations of the Apple Device. h.264 decoding is a big one, as the most popular use case of the Raspberry Pi seems to be setting up retro game emulators and streaming video from a network. Apple does what Apple will do, and the Device would probably cut into the market for the Apple TV.
Another shortcoming is the issue of the 40-pin header. Right now, there is no documentation whatsoever for the very small pin header located on the board. I couldn’t find anything in the *nix system relating to peripherals that might be connected to those pins. In any event, the pins are on a 1.0 mm pitch, making it very hard to plug a scope or meter onto one of those pins if you don’t have the mating connector. If anyone has seen this connector in the wild, I’d love to hear about it in the comments.
What Apple has done here is no different from the Raspberry Pi or any of the other ARM-powered single board computers released in recent years. They’ve taken a CPU from a smartphone that is now a few years old, added a few peripherals, and slapped it on a board. By itself, this is nothing new. That’s exactly what the Raspberry Pi is, and what all of the Raspberry Pi ‘clones’ are, from the Banana Pi to the Odroid.
While the hardware is somewhat predictable, the software is where this really shines. It’s not built for iOS, given this device is designed to run headless most of the time. It can be used purely through a command line, making this the perfect device for the Internet of Things. It’s also a tiny desktop computer, and somewhat usable given the power of the A8 chip. Since the Apple Device sells for about $50, Apple really hit it out of the park with this one, despite the obvious and not so obvious shortcomings. We’re really looking forward to Apple taking the popularity of the Raspberry Pi and other single board computers to the next level, and this is the device that will do it.
As a quick aside, it should be noted the Apple Device is technically Apple’s second single board computer. The first Apple product, the Apple I, released in 1976, would today fall into the same market as the Raspberry Pis, Beaglebones, and now the Apple Device. If you take the launch of the Apple I to be the date Apple was founded (April 1, 1976), today is the 40th anniversary of the first Apple product. The Apple I is now a museum piece and the finest example of Apple’s innovation over the years. The Apple Device follows in this tradition, and is nearly guaranteed to be held in as high regard as the board that came out of the [Steve]s’ garage.
From time to time, we at Hackaday like to publish a few engineering war stories – the tales of bravery and intrigue in getting a product to market, getting a product cancelled, and why one technology won out over another. Today’s war story is from the most brutal and savage conflicts of our time, the console wars.
The thing most people don’t realize about the console wars is that it was never really about the consoles at all. While the war was divided along the Genesis / Mega Drive and the Super Nintendo fronts, the battles were between games. Mortal Kombat was a bloody battle, but in the end, Sega won that one. The 3D graphics campaign was hard, and the Starfox offensive would be compared to the Desert Fox’s success at the Kasserine Pass. In either case, only Sega’s 32X and the British 7th Armoured Division entering Tunis would bring hostilities to an end.
In any event, these pitched battles are consigned to be interpreted and reinterpreted by historians evermore. I can only offer my war story of the console wars, and that means a deconstruction of the hardware.
An Architectural Study of the Sega Genesis and Super Nintendo
The traditional comparison between two consoles is usually presented as a series of specs, a bunch of numbers, and tick marks indicating which system wins in each category. While this does illustrate the strengths and weaknesses of each console, it is a rhetorical technique that is grossly imprecise, given the different architectures. The usual benchmark comparison is as follows:
Conventional wisdom – and people arguing on the Internet – tells you that faster is better, and with the Sega console having a higher clock speed it’s capable of doing more calculations per second. Sure, it may not be able to draw as many sprites on the screen as the SNES, but the faster processor is what allowed the Genesis / Mega Drive to have ‘faster’ games – the Sonic series, for example, and the incredible library of sports games. It’s an argument wrapped up in specs so neatly this conventional wisdom has been largely unquestioned for nearly thirty years. Even the Internet’s best console experts fall victim to the trap of comparing specs between different architectures, and it’s complete and utter baloney.
Let’s take a look at one of these numbers – the CPU speed of the SNES and the Genesis/Mega Drive. The SNES CPU, a Ricoh 5A22 is based on the 65C816 core, an oft-forgotten 16-bit offshoot of the 6502 and related chips found in everything from the Apple II, Commodore 64, and even the original Nintendo NES. The 5A22 inside the SNES is clocked at around 2.68 MHz for most games. The Sega used a 68000 CPU clocked at 7.67 MHz. By comparing just these two numbers, the SNES wins, but this isn’t necessarily the truth.
In comparing the clock speed of two different CPUs, we’re merely looking at how frequently the bus is accessed, and not the number of instructions per second.
In the 68000, each instruction requires at least eight clock cycles to complete, whereas the 65C816 – like it’s younger 6502 brother – could execute an instruction every two or three clock cycles. This means the Sega could handle around 900,000 instructions per second, maximum. The SNES could compute around 1.7 Million instructions per second, despite it’s lower clock speed.
Even though the Sega console has a faster clock, it performs fewer instructions per second.
And so we come to the crux of the argument; the statistics of the great console wars, while not wrong, are frequently misinterpreted. How then do we decide an outcome?
The Architecture of the Sega Genesis / Mega Drive
While the Sega Genesis/Mega Drive is usually cited as having a 68000 CPU, this isn’t a complete picture of what’s going on inside the Sega console. In effect, the Genesis is a dual-processor computer with two CPUs dedicated to different tasks. The 68000 handles game logic and graphics, but surprisingly not much else. A Z80 — a CPU introduced a decade before the Genesis/Mega Drive — is used for reading the state of the game pads, and playing audio.
Interestingly, the Sega Genesis / Mega Drive contains most of the components of Sega’s earlier console, the Sega Master System. With the addition of a Power Base Converter, Master System games can be played while the 68000 CPU is in idle.
The Architecture of the Super Nintendo
The SNES is a different beast entirely. Everything is controlled through the 5A22 / 65816 CPU. The controllers are fed right into the data lines of the 5A22, and DMA instructions are able to shuttle data between the two slightly different Picture Processing Units.
An interesting difference between the two consoles are the connections between the cartridge slot and various peripheral chips. Nearly the entire cartridge connector of the Sega machine is dedicated to the address and data lines for the 68000 CPU. While there are a few control signals thrown in, it’s not enough to allow the cartridge direct access to the video display unit or the FM synthesis chip.
The cartridge connector for the SNES, on the other hand, has direct access to one picture processing unit and the audio processor. The exploitation of this capability was seen in games ranging from Star Fox with it’s SuperFX chip, to Mega Man X games with its math coprocessor, to Super Mario RPG: Legend of the Seven Stars and its Super Accelerator 1 chip that is basically an upgraded version of the main SNES CPU, the 5A22.
Comparative designs, and who won the console wars
Time to make a holistic analysis of each competing platform. By far, the SNES is a more capable console; its cartridges are able to send data directly to the PPUs and audio processors, it’s faster, and there’s more work RAM, vRAM, and audio RAM.
The Genesis / Mega Drive may be seen as more expandable thanks to the Sega CD (the first CD-ROM based game console, the Sega 32X), an upgraded coprocessor for the Genesis, backwards compatibility with a Master System Power Base converter, and a number of strange cartridges like Sonic and Knuckles with ‘lock-on’ technology. However, it’s actually the SNES that is more expandable. This is most certainly not the conventional wisdom, and the difference is due to how expandability was implemented in each console.
To add additional capabilities to the SNES, game designers would add new chips to the game cartridge. Star Fox famously exploited this with the SuperFX chip, and the list of SNES enhancement chips is deserving of its own entry in Wikipedia.
In comparison, the Genesis / Mega Drive could only be expanded through kludges – either through abusing the ASIC chip between the 68000 and Z80 CPUs, or in the case of the 32X add-on, bypassing the video display unit entirely.
In any event, this is purely an academic exercise. Games sell consoles, and Nintendo’s IP portfolio – even in the early 90s – included characters that had their own cartoons, live action movies, and cereals.
While this academic exercise is completely unimportant today – there probably won’t be a game console that ships with cartridges any more – it is an interesting case study on extendable computer design.