Author Archives: Brian Benchoff

Winning the Console Wars – An In-Depth Architectural Study

via Hackaday » hardware

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:

Specs

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

genesis_block_diagram
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

SNES-BLOCK-DIAGRAM

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 Sega 'Tower of Power'. Image credit /u/bluenfee
The Sega ‘Tower of Power’. Image credit /u/bluenfee

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.


Filed under: computer hacks, Featured, hardware

Becoming A Zombie with the Hackable Electronic Badge

via Hackaday » hardware

Last week, Parallax released an open hackable electronic badge that will eventually be used at dozens of conferences. It’s a great idea that allows badge hacks developed during one conference to be used at a later conference.

[Mark] was at the Hackable Electronics Badge premier at the 2015 Open Hardware Summit last weekend, and he just finished up the first interactive hack for this badge. It’s the zombie apocalypse in badge form, pitting humans and zombies against each other at your next con.

The zombie survival game works with the IR transmitter and receiver on the badge normally used to exchange contact information. Upon receiving the badge, the user chooses to be either a zombie or survivor. Pressing the resistive buttons attacks, heals, or infects others over IR. The game is your standard zombie apocalypse affair: zombies infect survivors, survivors attack zombies and heal the infected, and the infected turn into zombies.

Yes, a zombie apocalypse is a simple game for a wearable with IR communications, but for the Hackable Electronics Badge, it’s a great development. There will eventually be tens of thousands of these badges floating around at cons, and having this game available on day-one of a conference will make for a lot of fun.


Filed under: cons, hardware, wearable hacks

DEF CON: HDMI CEC Fuzzing

via Hackaday » hardware

HDMI is implemented on just about every piece of sufficiently advanced consumer electronics. You can find it in low-end cellphones, and a single board Linux computer without HDMI is considered crippled. There’s some interesting stuff lurking around in the HDMI spec, and at DEF CON, [Joshua Smith] laid the Consumer Electronics Control (CEC) part of HDMI out on the line, and exposed a few vulnerabilities in this protocol that’s in everything with an HDMI port.

CEC is designed to control multiple devices over an HDMI connection; it allows your TV to be controlled from your set top box, your DVD player from your TV, and passing text from one device to another for an On Screen Display. It’s a 1-wire bidirectional bus with 500bits/second of bandwidth. There are a few open source implementations like libCEC, Android HDMI-CEC, and even an Arduino implementation. The circuit to interface a microcontroller with the single CEC pin is very simple – just a handful of jellybean parts.

[Joshua]’s work is based off a talk by [Andy Davis] from Blackhat 2012 (PDF), but greatly expands on this work. After looking at a ton of devices, [Joshua] was able to find some very cool vulnerabilities in a specific Panasonic TV and a Samsung Blu-ray player.

A certain CEC command directed towards the Panasonic TV sent a command to upload new firmware from an SD card. This is somewhat odd, as you would think firmware would be automagically downloaded from an SD card, just like thousands of other consumer electronics devices. For the Samsung Blu-Ray player, a few memcpy() calls were found to be accessed by CEC commands, but they’re not easily exploitable yet.

As far as vulnerabilities go, [Joshua] has a few ideas. Game consoles and BluRay players are ubiquitous, and the holy grail – setting up a network connection over HDMI Ethernet Channel (HEC) – are the keys to the castle in a device no one  would ever think of taking a close look at.

Future work includes a refactor of the current code, and digging into more devices. There are millions of CEC-capable devices out on the market right now, and the CEC commands themselves are not standardized. The only way for HDMI CEC to be a reliable tool is to figure out commands for these devices. It’s a lot of work, but makes for a great call to action to get more people investigating this very interesting and versatile protocol.


Filed under: cons, hardware

BeagleBone Green Hands-On: Lower Price, Same Horsepower

via Hackaday » hardware

Although the BeagleBone Green was announced at the Bay Area Maker Faire last May, there hasn’t been much said about it on the usual forums and IRC channels. Now, it’s finally out and I got my hands on one of them. Through a cooperation between the BeagleBoard foundation and Seeed Studios, the best small Linux board for doing real work with small Linux boards is now cheaper, a little more modern, and green.

The BeagleBone Green is an update to the venerable BeagleBone Black, the dev board based on a TI ARM Cortex-A8. It’s an extremely capable machine with a few interesting features that make it the perfect device for embedded applications. With the BeagleBone Green, the BB Black gets a small hardware refresh and a drastic reduction in price. If you want to do real work on a Linux board, this is the one to get. Check out the review below for everything that’s been updated, everything that’s the same, and why this is one of the most interesting developments in small Linux boards in recent memory.

The Differences From The BeagleBone Black

BlackVGreen
The BeagleBone Black and BeagleBone Green back to back

The BeagleBone Black has been around for more than two years now, but it’s still an extremely capable machine. The BeagleBone Green borrows heavily from the Black, with a few changes to satisfy the cost-reduction goal, and to make the BB Green slightly more accessible.

By far the largest change is the removal of the microHDMI connector. This is accompanied by a large bare spot on the board where the NXP HDMI Framer chip once was on the BB Black. When I talked to [Jason Kridner] his justification for the removal of the HDMI capability of the Green was that ‘nobody used it.’ This is fair and true; if you want a media server, you get a Raspberry Pi, and if you want a tiny Linux box to toggle pins very quickly, you get a BeagleBone. The removal of HDMI plays to the BeagleBone’s strengths, and makes it a less expensive board. You can’t argue with that.

Also on the list of changes are the addition of two Grove connectors. These connectors are part of a modular system of electronics that put a UART or I2C bus on a single connector. With these connectors and a few modules from the Grove System, building simple projects is a snap. The addition of two Grove connectors – one UART, one I2C – is Seeed’s largest contribution to the BeagleBone Green, and with a large catalog of parts ranging from simple logic gates to OLED displays and GPS modules, it’s pretty handy.

oled
Grove modules, like this OLED display, are plug and play with the BeagleBone Green

Aside from those changes, the BeagleBone Green is pretty much exactly the same as the BeagleBone Black. It has the same amount of RAM, the same processor, the same amount of eMMC Flash, and the same pinout as the BB Black. The Green moves to a USB micro connector for the power and serial connection. This had been USB mini on the BeagleBone Black. That’s a welcome change that’s long overdue. The barrel jack for power has been removed from the BeagleBone Green, and the larger USB port has been moved right next to the Ethernet socket.

As is the case with the BeagleBone Black, the Green comes with the Cloud 9 IDE already installed on the Linux image on the eMMC. This is a cloud-based IDE, but is hosted on the BeagleBone. For a device that really isn’t meant to be a desktop computer, this is the easiest way to get code up and running on a tiny Linux box. Combine this with a serial terminal, and it’s really all you need.

Why It’s Great

Although the BeagleBone Black has been around for a while now, and the BeagleBoard even longer, the Beagles have been playing second fiddle to the Raspberry Pi forever. This is a shame. The Raspberry Pi is not the ideal tool if you want real-time control of a lot of pins, and the GPIO expansion on the Pi is more of a kludge than something it was designed for.

In contrast, the BeagleBone – with its fancy PRUs – is designed for futzing around with GPIOs under Linux very fast. It’s been used as a video card for an old Mac, and to drive an awe-inspiring, blinding amount of RGB LEDs, among thousands of other interesting and hardcore projects.

The removal of the HDMI port in the BeagleBone Green doesn’t make this board any less capable. Like I mentioned above, nobody used it anyway. Add to that the fact you can buy an LCD cape for the BBG – and have it work with the 3D accelerator – and you’re really not losing any capability, just shaving sixteen bucks off the price. The BBG will launch with a $39 price tag, or about the same price as a Raspberry Pi. While it won’t impress many people that want a cheap Linux box for retro video game emulation, it is a great board for anyone who wants to get real work done.


Filed under: hardware, reviews

Learning From Transparent Microchips

via Hackaday » hardware

Microchips and integrated circuits are usually treated as black boxes; a signal goes in, and a signal goes out, and everything between those two events can be predicted and accurately modeled from a datasheet. Of course, the reality is much more complex, as any picture of a decapped IC will tell you.

[Jim Conner] got his hands on a set of four ‘teaching’ microchips made by Motorola in 1992 that elucidates the complexities of integrated circuitry perfectly: instead of being clad in opaque epoxy, these chips are encased in transparent plastic.

The four transparent chips are beautiful works of engineering art, with the chip carriers, the bond wires, and the tiny square of silicon all visible to the naked eye. The educational set covers everything from resistors, n-channel and p-channel MOSFETS, diodes, and a ring oscillator circuit.

[Jim] has the chips and the datasheets, but doesn’t have the teaching materials and lab books that also came as a kit. In lieu of proper pedagogical technique, [Jim] ended up doing what any of us would: looking at it with a microscope and poking it with a multimeter and oscilloscope.

While the video below only goes over the first chip packed full of resistors, there are some interesting tidbits. One of the last experiments for this chip includes a hall effect sensor, in this case just a large, square resistor with multiple contacts around the perimeter. When a magnetic field is applied, some of the electrons are deflected, and with a careful experimental setup this magnetic field can be detected on an oscilloscope.

[Jim]’s video is a wonderful introduction to the black box of integrated circuits, but the existence of clear ICs leaves us wondering why these aren’t being made now. It’s too much to ask for Motorola to do a new run of these extremely educational chips, but why these chips are relegated to a closet in an engineering lab or the rare eBay auction is anyone’s guess.


Filed under: hardware

Review: Single Board 65C02 and 65C816 Computers

via Hackaday » hardware

The 6502 is a classic piece of computing history. Versions of this CPU were found in everything from the Apple ][, to the Nintendo Entertainment System, and the Commodore 64. The history of the 6502 doesn’t end with video games; for the last forty years, this CPU has found its way into industrial equipment, medical devices, and everything else that doesn’t need to be redesigned every two years. Combine the longevity of the 6502 with the fact an entire generation of developers first cut their teeth on 6502 assembly, and you have the makings of a classic microprocessor that will, I’m sure, still be relevant in another forty years.

The cathedral of The 6502 is Western Design Center. For more than 35 years, WDC has been the home of 6502-related designs. Recently, WDC has been interested in the educational aspects of the 6502, with one of the VPs, [David Cramer], lending his time to an after-school club teaching opcodes.

The folks at WDC recently contacted me to see if I would give their hardware a close look, and after providing a few boards, this hardware proved to be both excellent. They’re great for educators adventurous enough to deviate from the Arduino, Processing, and Fritzing zeitgeist, and for anyone who wants to dip their toes into the world of 65xx development.

The Single Board Computers

WDC sent me the W65C02SXB and the W65c816SXB, two single board computers based on the 65C02 and the 65C816, respectively.

SBCThere are hundreds of very well-documented designs floating around the Internet for 65xx-based computers, but most of these designs have a lot in common. If you’re looking to build your own 6502-based computer, you’ll need a CPU, some RAM, and an EEPROM or Flash chip. For peripherals, you’ll be looking at the 6520 PIA, a chip that provides two eight-bit ports of I/O, the 6522 VIA a more advanced I/O chip with timers and a shift register, and maybe an 6551 ACIA communications/serial chip if you’re a purist. This is the standard compliment of chips for a 6502-based computer, and if you believe [Chuck Peddle], the 6502 wasn’t that useful without these support chips.

Both the ’02 and ‘816-based single board computers from WDC feature an ACIA, a PIA, and two VIAs – the second VIA is connected to a microUSB interface designed for WDC’s Terbium IDE (TIDE). More on TIDE in a bit. Each board also has 32kB of SRAM and a 128kB Flash chip mapped into the top 32k of memory. This is a fairly standard layout for just about every homebrew 6502 computer, but there are a few features that make this board special. Every pin you would ever need – data, address, control, and some chip selects – are available on a header running the entire length of the board. This is great if you’d like to interface an SXB with some old hardware, but the potential for creating new hardware is interesting. When I talked to [David Cramer] and [David Gray] at WDC, we speculated on what interesting hardware could be made that supports this gigantic header. The board might be too big and cumbersome for a quadcopter, but a 3D printer controller board is entirely reasonable, and would probably work very well.

The 65C816

The Western Design Center doesn’t just deal with the 6502 and its support chips. It remains the only place where you can get the 65C816, a greatly expanded CPU built on the 6502 ISA.

816The ‘816 is a very interesting chip, most famous for its use in the Apple IIgs and the Super Nintendo. With a 24-bit address bus, it supports 16 Megabytes of RAM, has 16-bit registers, and a few new instructions over the 6502. Most impressively, when you first turn a 65C816 on, it starts up in a 6502 emulation mode that is 100% compatible with the 6502 until you flip a bit in a ‘hidden’ register.

With new stack instructions and compatibility with the 65C02, you have to wonder what would have happened if the 65C816 were introduced a few years earlier. The chip was finished in 1984 in time for Apple to use it in the IIgs, and for [Bil Herd] to realize, ‘the reason to use it is because the competition is using it wasn’t going to be a successful pitch.’ A few years earlier, and this chip would have at least been considered in the initial designs of the Apple Lisa, Macintosh, the Atari ST line, and possibly even the IBM PC. It’s the greatest ‘what-ifs’ of computing history.

For the last 30 years, WDC have been the keepers of the 65C816 flame, and of course their educational offerings include a single board computer based around this chip. It is more or less identical to the W65C02SXB with PIA breakouts, VIA breakouts, and an ACIA breakout. The larger set of connectors contains all the data, address, and control lines of the XBus02 connector of the W65C02SXB, save for additional pins for the extra address lines.

Best of all, with a 65C816 development board, there’s no need to deal with the multiplexed data and address lines. Writing ‘816 code is as simple as plugging the board into your computer and mashing the keyboard; the Western Design Center has the only modern ‘816 C compiler, after all.

Terbium IDE

WDCGIF
The Sample Project for the SXBs blink a seven-segment display in a pleasing pattern

All of the WDC boards work with the Terbium IDE, the IDE packaged with the WDCTool suite. This is the interface for the compiler, linker, the editor of your choice, and a simulator. Truth be told, it’s not exactly a modern IDE – it’s Windows only, and my battle station (Win 8.1) saw the best results running in WinXP Sp2 compatibility mode.

Although TIDE is a little rough around the edges, it’s not really fair to compare this to Visual Studio or Eclipse; these high-end IDEs will always have more features and more polish than an IDE built for a single platform. Also, it’s an IDE, and being rough around the edges is the default, not an exception.

Aside from compiling and linking, TIDE also has another neat feature that’s directly applicable to the SXB boards: a simulator and debugger.

65sim
The TIDE simulator/debugger running the sample project with a seven-segment display

The addition of a simulator and debugger in TIDE is something you’re not going to get if you build your own 6502 single board computer. With the simulator and debugger, you can step into code, set breakpoints, and generally do everything you would expect to be able to do with an embedded IDE.

The sample project for the W65C02SXB was a ‘light up a seven segment display with a VIA’ tutorial, and this demonstrates the potential of the debugger; it even simulates the seven segment display with the help of a little code.

There are a few extra features in TIDE that tie into FPGA-related stuff for WDC’s soft cores for the ’02 and ‘816, but since that’s far beyond the boards I have, those buttons were left alone.

The Microcontroller Development Boards

265
The W65C265SXB – A microcontroller board based on the 65C816

WDC has not been resting on their laurels for 40 years. Their educational tools also include microcontrollers based on the 65c02 and 65c816. These are the 65C134SXB (based on the ’02, and was originally designed for life support), and the W65C265SXB (based on the 65c816).

Each of these boards feature the W65C134S or W65C256S microcontroller with 32kB of SRAM, a socket for a 32PLLC Flash ROM, one large connector that is more or less the same as their ‘full microprocessor’ counterparts, and three 10-pin connectors that are used for basic I/O, the Serial Interface Bus, and UART signals.

Although these microcontroller development boards appear very minimal – there are only four chips, a hand full of passives, and a bunch of pin headers, after all – appearances are deceiving. The microcontrollers are actually incredible pieces of engineering that really aren’t comparable to anything else on the market.

CoolTerm
The W65C265SXB ROM Monitor running in a terminal emulator

Inside both of these microcontrollers is a ROM monitor that functions just like any monitor program you’d find in an ancient computer. With this monitor, you can read and write to memory addresses, jump to addresses, and run code. All that’s needed is a USB cable, a terminal emulator (CoolTerm, Putty, a neat little Python script, or anything else that can connect to something over a serial port, 9600, 8N1) [Rod Biresch] has a great tutorial for entering opcodes into the ‘265SXB to blink an LED. Yes, it’s the most basic thing you can do with a microcontroller, but it does work, and can serve as the first stepping stone to more complex applications of an embedded 65xx ISA microcontroller.

Like their bigger brothers, they are also supported by the WDC’s own development environment, TIDE. With this, you can throw assembly or C at these little boards and they’ll chug right along.

Conclusion

There is one fairly large drawback to the single board computers from WDC – the price. The W65C02SXB and W65C816SXB go for a little under $200 USD. The microcontroller variants – the W65C134 and W65C265 knock $100 off the price of their bigger brothers. When you can get an Arduino Nano clone for $2 with free shipping, this looks insane at first glance. After thinking about it, I’m not convinced the price actually is insane.

While you can pull a 6502 out of any old computer, you’re not going to find new chips from anyone but WDC. Being in the 6502 game is a comparatively low-volume business, and for every classic microprocessor, there are thousands of ARM chips.

That being said, if you were to build a 6502 or 65816 single board computer, you’ll also need those VIAs and PIAs; again, not chips you can pick up for a dollar a piece. I’ve built a 6502-based computer, and in terms of cost, my build wasn’t very far off. If you consider the effort that goes into building your own SBC… well, what do you value your time at?

The microcontroller variants of WDC’s boards are by far their most interesting offerings. There’s a common trope in modern 6502 builds that offload nearly everything to a microcontroller, but keep the 6502 in it’s classic 40-pin DIP format. You’ve seen it done with the Propeller, with an ATMega, and with the Propeller again. The 65C134 and ~265 do this job exceptionally well, and they have a built-in monitor to get you typing in machine code fast. That’s the goal of every homebrew computer, really.

For an educational offering, WDC’s single board computers do exactly what they’re designed to do: get people learning assembly and opcodes and machine codes. There’s still a value in this, especially if you’re going to continue hacking on Arduinos and ARMs. The microcontroller boards are a great introduction to some seriously interesting hardware, and I can’t wait to see the retro/homebrew scene dig into some serious tinkering with these machines.


Filed under: hardware, reviews