Tag Archives: 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

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.

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

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.

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.


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

I2C Hacks: How to Splice Clocks into Chip-Selects

via Hackaday » hardware

There comes a time when you need to wire up three, four, or more identical i2c devices to a common microcontroller. Maybe you’re thinking about driving a whopping 32 seven-segment displays with four of those MAX7219CNG 8-way digit drivers, or maybe you have a robot full of joints–each of which needs a BNO055 inertial sensor for angle estimation. (See above.) Crikey! In both of those cases, you’re best bet might be a schnazzy I²C device that can do most of the work for you. The problem? With a single I²C bus, there’s no standard way defined in the protocol for connecting two or more devices with the same address. Shoot! It would’ve been handy to wire up three BNO055 IMUs or four MAX7219CNGs and call it a day. Luckily, there’s a workaround.

We’ve seen some clever tricks in the past for solving this problem. [Marv G‘s] method involves toggling between a device’s default and alternate address with an external pin. This method, while clever, assumes that the device (a) has an alternate I²C address and (b) features an external pin for toggling that address.

I’ll introduce two additional methods for getting the conversation started between your micro’ and your suite of identical sensors. The first is “a neat trick,” but somewhat impractical for widespread use. The second is far more  production-worthy–something you could gloat over and show off to your boss! Without further ado, let’s get started with Method 1.

Lastly, if you’d like to follow along, feel free to check out the source code on Github.

The Test Setup:


In both methods, I’m using the same sensor setup to check that each circuit behaves correctly. I happened to have a bunch of extra BMA180s on the bench, so I rolled out an example based on these chips. Back in the day, the BMA180 was a pretty common three-axis digital accelerometer. It has an I²C interface with two optional addresses. For the purpose of this example, I’m fixing them all with the same address.  I’ve mounted three of these guys on mutually perpendicular axes of my acrylic “test cube,” and I’m reading each chip’s Z-axis. In this configuration I can easily pick out the gravity vector from the corresponding sensor as the data goes flying by my serial port window. If I can uniquely address each sensor and read the data, I’ve got a working circuit.

Method 1: Splicing Clocks into Chip-Selects

This method tips its hat towards SPI in that it behaves in an oddly similar fashion. If you’re feeling rusty on SPI, here’s a quick recap.

A Quick SPI Refreshment:

SPI, like I²C, is another protocol that shares both its clock and data lines with multiple slave devices. The difference, though, lies in the addressing scheme to talk to these devices that share the same bus. With SPI, while clock and data lines are shared, devices are addressed with separate chip-select (CS) lines.

Image Source: Wikipedia

The master microcontroller dedicates a unique output pin to each device (~SS1, ~SS2, and ~SS3 in this illustration). When the master micro’ wants to talk to a device, it asserts that device’s chip-select input pin by pulling it to logic LOW, and the conversation begins over the data bus. With the chip select LOW, the corresponding slave listens to the data on the bus. Meanwhile, all other devices ignore the conversation between the master and it’s chosen slave by keeping their bus pins in a high impedance state.

Giving I²C Its Own Chip-Selects:

With I²C, Clock (SCL) and Data (SDA) lines are still shared between all I2C slave devices, but the addressing scheme happens by sending a message heard by all devices on the bus. To single out one device on the shared bus, the master first passes down the address of the slave device it wants to talk to, after which that slave replies with an ACKnowledge, and all other slaves ignore the data that follows until both data transmission is complete and the bus is “released.”


Because we have the problem of multiple devices with shared addresses, in theory, all of these devices would reply when the master passes down their shared address, and there’s no way for the master to single out a single device. In reality, this behavior is undefined on the I²C protocol.


Yikes! Anything goes when we wander away from defined behavior, so we try to avoid these things in practice.

The solution?

According to the I²C spec, It just so happens that an I²C slave device will ignore changes on the data line (SDA) provided that the clock line (SCL) is held high. In this method, I’ll “split” the SCL line into multiple SCL lines such that each shared I²C device gets its own SCL. By selectively rerouting the clock to each I²C device one-at-a-time, I’ve essentially turned the SCL line into a “chip select.”

To chop up that clock line, I’ll need a demultiplexer. A demultiplexer (or decoder) takes a logical input and reroutes it to one of several outputs based on the binary select lines.

demux i2c_demultiplexing_demo

I’ve dropped in the 74AC11138 eight-way demultiplexer for this task. It’s fast, capable of switching at megahertz rates, and its outputs default to logic HIGH. That second note is handy since idle SCL lines also default to logic HIGH.

The setup is shown in a simplified schematic above. In it, I’m using a Teensy 3.0 posing as the I²C bus master. To the right of the Teensy is the collection of identical chips, BMA180 accelerometers in this case. In the middle is the 74AC11138 eight-way demultiplexer.

Cons of this Method:

There’s a minor drawback with this technique, though, in that it doesn’t support I²C’s clock-stretching feature. Taking a step back, this method assumes that the SCL line is inherently unidirectional, controlled by only the I²C bus master. In other words, we’re making the assumption that data on the SCL line is only sent from master to slave and never the other way around. If your I²C slave devices implement clock-stretching, however, this assumption breaks down.

What is Clock Stretching?

Clock stretching is a method defined by the I²C protocol where the chip needs to “buy itself more time” and holds the SCL line low, hence, signalling to the master that it’s not ready for the upcoming data. In this scenario, the slave actively controls the SCL line, and it happens to be the only case where data moves up the SCL line from slave to master. In a setup with our demultiplexer between the master and our set of identical slaves, these slaves won’t be able to send back the clock-stretching signal to the master to indicate that they aren’t ready for data, if they happen to implement clock stretching. That said, clock stretching is a pretty rare feature among I²C-compatible devices, so this method is likely to work among a number of chips out now.

More Next Week

That’s all for Method 1. Thanks for tuning in, and check back next week for a slightly-more-professional method of tackling this same problem.

Filed under: Featured, hardware

Robot Control Ties RC Receiver to Motor Controller

via Hackaday » hardware

[Andrey Nechypurenko] has posted the second part of his robotics ground vehicle design guide. In his first post [Andrey] detailed the mechanical design decisions he faced. [Andrey] now begins covering the electrical components, starting with manual control using a standard radio control system. To accomplish this an RC system was used with an MD22 h-bridge driver and a picoUPS.

The MD22 is a neat motor control board which can take the PWM signals from the radio controller and use this to drive the DC motors. Optionally it can also use an I2C interface, giving a nice migration path to integrate with a microcontroller. Until that happens this can’t really be called a robot — its more of an RC vehicle. But the iterative design and build process he’s using is a good one!

The picoUPS provides on-board battery charging. Due to its UPS heritage it also allows the vehicle to be powered from an external supply, which has proved useful during development. Finally, a 5v regulator was required to supply the on-board digital logic. [Andrey] wanted a quick drop in solution with a budget large enough to allow for future expansion and went with the Pololu D15V35F5S3 which can supply 3.5 amps in a small and easy to use module.

After breadboarding the system [Andrey] fabricated a PCB to integrate all the components. The next step is to add sensors and and embedded computer to the platform.

Filed under: hardware, robots hacks

Get Your Kicks With this New PIC Development board

via Hackaday » hardware

While development boards for micro controllers are nothing ground breaking, they can be expensive, and often times overkill for what you’re doing when they try to put everything you might use … including the kitchen sink. when [Brian] noticed his projects were starting to use Microchip PIC24 more and more, the time came to have a dev board on hand. 

top-viewThe result is a small board with breakouts for USB, UART (via FTDI), of course tons of GPIO pins, and a socket which mates with a daughter board to swap out either a PIC24FJ128GC006, or a DSPIC33EP256MU806, with the potential for more. Also packed on the board is a power regulator system and dual crystals allowing full speed operation or power sipping modes.

Schematics and PCB layout are available (in Diptrace format) along with a board template file to use with MPLAB on github.com. Once you have everything together you will need a PIC programmer, [Brian] is using a trusty Microchip MPLAB ICD 3 programmer, but naturally, others are available.

Microchip recently announced a new development board of their own for the PIC16F series. The Curiosity board has built-in support for programming and debugging (no chipKIT needed). The engineer who designed that board, [John Mouton] is going to join us on July 30th for a live chat about the design process. We’re also going to be giving away some of the first boards to come off the production line… more about that this coming week.

Filed under: hardware

Building a giant Iron Man suit you can actually wear!

via Arduino Blog


If you are a fan of cosplay, props and hand built creations you can’t miss the work of  James Bruton. Based in Uk he’s got a personal project YouTube channel with a new video every week describing his work in details. At the end of June he posted the 34th “episode” of the project started nearly a year ago about  building an Iron Man Hulkbuster giant suit you can actually wear!

In the video below you can follow how he’s sorting out the arm mechatronics for the elbow, hand and cuff weapon with some 3D printing with Lulzbot and controlling the interaction with  Arduino Uno (electronic part starting around minute 10):

Explore the playlist of the project for other cool videos.

Android-based Reflow Brings Solder Profiles to Your Lab

via Hackaday » hardware

[Andy Brown] is a prolific hacker and ends up building a lot of hardware. About a year back, he built a reflow oven controller. The board he designed used a large number of surface mount parts. This made it seem like a chicken or egg first problem. So he designed a new, easy to build, Android based reflow controller. The new version uses just one, easy to solder surface mount part. By putting in a cheap bluetooth module on the controller, he was able to write an app which could control the oven using any bluetooth enabled Android phone or tablet.

The single PCB is divided into the high voltage, mains powered section separated from the low power control electronics with cutout slots to take care of creepage issues. A BTA312-600B triac is used to switch the oven (load) on and off. The triac is controlled by a MOC3020M optically isolated triac driver, which in turn is driven by a micro controller via a transistor. The beefy 12Amp T0220 package triac is expected to get hot when switching the 1300W load, and [Andy] works through the math to show how he arrived at the heat sink selection. To ensure safety, he uses an isolated, fully encased step down transformer to provide power to the low voltage, control section. One of his requirements was to detect the zero cross over of the mains waveform. Using this signal allows him to turn on the triac for specific angle which can be varied by the micro controller depending on how much current the load requires. The rectified, but unfiltered ac signal is fed to the base of a transistor, which switches every time its base-emitter voltage threshold is reached.

For temperature measurement, [Andy] was using a type-k thermocouple and a Maxim MAX31855 thermocouple to digital converter. This part caused him quite some grief due to a bad production batch, and he found that out via the eevblog forum – eventually sorted out by ordering a replacement. Bluetooth functions are handled by the popular, and cheap, HC-06 module, which allows easy, automatic pairing. He prototyped the code on an ATmega328P, and then transferred it to an ATmega8 after optimising and whittling it down to under 7.5kb using the gcc optimiser. In order to make the board stand-alone, he also added a header for a cheap, Nokia 5110 display and a rotary encoder selector with switch. This allows local control without requiring an Android device.

Gerbers (zip file) for the board are available from his blog, and the ATmega code and Android app from his Github repo. The BoM list on his blog makes it easy to order out all the parts. In the hour long video after the break, [Andy] walks you through solder tip selection, tips for soldering SMD parts, the whole assembly process for the board and a demo. He then wraps it up by connecting the board to his oven, and showing it in action. He still needs to polish his PID tuning and algorithm, so add in your tips in the comments below.

Filed under: hardware