Friday, May 17, 2013

11 Digit, 7 Segment Display

An early test result, showing text and millseconds since power-on.

About a year ago, I bought a few 11 digit, 7 segment red LED displays from Active Surplus up on Queen Street in Toronto. (Excellent store.  If you're into hacking stuff at all, it's well worth the trip. Look for the monkey on Queen street to find their entrance.)

This past week, I wasn't sure what to do at Interlock on Tuesday night, but I had recently re-found these displays, so I figured I would finally get them working.  I hit Radio Shack to get a Seeed Studio Arduino Shield ($10 with a mess of components, probably the best deal in all of Radio Shack.)

The display with a header soldered on, and the shield with its assorted parts.

I was all set to figure out how to reverse-engineer the pinout on the bottom of the display; I googled for the LED module, and found specs on those, and then on a whim, decided to check on the entire module board, a Rohm LU-3011, and found the jackpot, this post about figuring out the pinout.  It suddenly became very easy to do this project.

The two key things gleaned from that above post, which I have mirrored here, are this table of enables for each of the 11 digits:

Digit1234567891011
Pin1234681012141618

and this image, showing the pin mappings of the segments:
Mapping of the segments to the pins on the header.

The basic way these displays work is that all of the 7 segments (plus one decimal point) are all tied together to the pins specified above.  Then the anodes for each of the displays are broken out to the pins in the table above.  So to draw a '7', you would set all of the segments to LOW, except for pins 11, 19, and 7 which you set HIGH.  Then to turn on a specific digit, let's say digit 11 (rightmost), you set the digit enable pin 18 to be an output, and set it LOW.  Set all of the other digit enables to be inputs (tri-state, not low or high), and only position 11 will show a "7".  You repeat this for all of the 11 digits in the display, and you can display 11 full digits from just those 19 pins. 

In my code (available below) I start at digit 1, and work down to digit 11, enabling each one, in turn, showing its segments, waiting 1 millisecond, then disable that digit, move on to the next one.  Because of this quick display time, and to preserve brightness, I did not put any current limiting resistors in the mix.  Perhaps this was a bad idea, but it works great for now. ;)

I soldered a pin header on the display, and built up a shield to plug it into.

All of the digit enables wired up.  The top ones are a bit messy. Sorry about that.

I wired it up such that the digit enables and segments are wired directly to IO lines on my Arduino.  This used all of the IO lines, minus the D13 pin, which has an on-board LED.

The code that I wrote (available below) lets you do arbitrary digits per character, so that i can do (primitive) alphanumerics, or do animation patterns, etc.  I also store the decimal point as a separate character going in to the display code, so "3.141" is five ascii characters going in, but a flag is set on the '3' position saying that this digit should also display its decimal point, so it only consumes four digits in the display.

just testing out all of the segments and digits

For now, it displays a nice clock and some animations on my desk, but I plan on changing it around a little in the near future.  I want to use the D13 line as one of the segment enables (probably decimal point) and move the segment enables off of the Serial Receive line.  That way i will be able to control it via serial to display patterns, animations or text content.  Since the hardware serial port is hardwired to 0 and 1, and I will be using the TX line for the LED displays, I'll have to instead use the Software Serial, with only its Receive line mapped to an IO pin, and its Transmit line mapped to junk. I've done this before and it works well.



This project was constructed and started at the Interlock Rochester hackerspace.

Monday, April 22, 2013

Barcamp Rochester Spring 2013 - Ridiculous use of Video Tech

On display at Barcamp Rochester this year was my Amiga-Genlock autotumblr setup.  It's a mix of technologies that span from 1985 to 2013.  It's fun, ridiculous and here's what's happening with it.  (Note: the complete list of technologies used is at the bottom of this post.)

Here's the basic workflow as it was planned:

And here's the slide I made to describe the system in Deluxe Paint 3, which is close to the same thing, but a little more (less?) informative: (Note: the color cycling is not available for this display, sadly.)

And here's a snapshot of it from the system itself, with some MST3K overlay goodness:



The Amiga 1000 is running Deluxe Paint 3.  You draw on a color 0-backed canvas.  The Amiga has an 8 meg ram expansion board attached to it via DataFlyer expansion module, and was running two floppy drives.

The Amiga 1300 genlock (which is hidden underneath the Amiga) replaces anything that is color 0 on the screen with the video input.  The video input in this case is connected to the old-school Minolta vidicon-tube video camera.  This gives us the Amiga graphics over top of the video coming in. I should note that all of this happens external to the computer itself, in the anlog video path.  The only thing going into the computer is the sync signal.  This means that if you were to "save" an image in Deluxe Paint, you will get only the mustache you drew, not it on your friend's face as well.

It's that overlayed image that we want here, so we feed that output video signal into the DV camcorder, which is acting like an AV-DV bridge in this case, only that we're ignoring the Firewire DV output from it.   Instead, we use a feature on this particular camera, in which it saves a screenshot of the current video to the SD card you have installed with it.

I should note that this camera came with an 8 meg SD card.  This should give you a sense of scale for the vintage of this thing.  I have instead replaced this with a 2 gig EyeFi card.  This EyeFi card is linked to my Macbook Pro via the wifi access point on the table.  The Eye-Fi software saves its content into a  Dropbox folder.  When a picture comes in, it then magically gets copied up into the cloud.

Once saved there, a script at IFTTT.com (If This Then That) takes the photo, and puts it into a tumblr post, which is then viewable by all in a standard way.


Here's a list of all of the hardware and technologies used to make this happen.
  • Amiga 1000 (Spring 1986 vintage)
    • AmigaDOS 1.3 (1988)
    • 7.16 MHz 68000 processor
    • 512k byte RAM (graphics, cpu ram)
    • Deluxe Paint III software (1983)
    • Commodore 1300 Genlock
    • Dataflyer 8 megabyte RAM expansion (1991)
    • Sony Trinitron 9" monitor
  • Minolta K-520 Tube Video camera (1985)
    • "VHS" connector, with custom power supply and AV interface connector
  • Canon Optura XI DV Camcorder (2003)
  • Eye-Fi Share (2007) 2 gig SD card
  • WiFi Access Point
  • Dropbox folder syncing software (current)
  • Linux Laptop running Ubuntu and Dropbox software (current)
  • IFTTT script to post new Dropbox items to Tumblr (current)
  • Images posted to http://amigapics.tumblr.com (current)
So... what happened?

In practice at home, this all worked well, both going through my home access point, as well as through the extra access point, connected to my laptop directly (whose wifi-based internet access was shared through the AP).  But once I got it all at RIT, that's where things started to break.

First of all, I forgot my Amiga floppy disks at home, so I had to run home to grab those.  Oops.

Next, there was a sync/color issue with the genlock when i got it all connected.  I'm pretty sure this is because of two things.  First, the Amiga doesn't sync with the genlock before the Kickstart disk is loaded... and without this disk on-hand, I couldn't fix this until I had gone home to get them.  Secondly, I think the RGB connector on the genlock is faulty, causing it to make a poor connection with the system.  I need to examine this more.

Next, the wireless network at RIT prevented me from re-sharing its network on my Mac.  It claimed some sort of 802.1x protection or somesuch. Next up was to get the Eyefi and macbook directly onto the RIT network. The Eyefi card I have (not sure if modern cards are like this) would not connecto to the RIT networks since the network required username/password, whereas the Eyefi software only supported a password for the network settings.  The Barcamp network dude helped me get both onto the unprotected RIT network (unlocked to the devices via MAC address, rather than user/password).  Unfortunately for some reason this didn't quite work with the card and laptop either.  I'm not entirely sure why.   I then had a friend with a linux laptop to share his wireless connection out through his wired ethernet, which then was re-shared via the access point I brought.  This kinda worked. but at rediculously slow bitrates to be useless.

It was pretty much at this point that I just gave up on the wireless aspect of the Eyefi card, and would just plug the SD card into my laptop occasionally and manually copy the files into the Dropbox folder.  Oh well.

Other than that, It worked pretty well.  All of the images captured are available on the tumblr site at least for now.

Here's some of them as well:

Brian and Skip at the Interlock table

Chorn talking with someone

Me, testing out the system

Dennis being frightened by a deadite.

Some Deluxe Paint fun


Just like old times, the Amiga crashed a few times.

Video feedback

Chris

Wednesday, March 6, 2013

Anamatronic Avian: Skeleton Experiments

I'm about to start making the skeleton for my animatronic Tiki-Room Macaw.  Rather than futzing with drawing up detailed plans in some cad program, Iv'e decided to instead get the basic shape made, and then just build one out of foam core.  My thought was that once I have the shape worked out, I'll disassemble it and come up with plans for 3d printable parts that can be attached together, and eventually some vacuum formed parts as well for the head and beak, which need to be lightweight... although I'm starting to think that they could all be 3D printed, with a skin stretched over them for feathers and fur, after seeing the posts on Hack-A-Day about using acetone vapor to smooth out parts... anyway..

One of the things I was unsure of was the control linkages, and how the articulation points can be made.  It needs to have a few points of articulation to match the birds in the Enchanted Tiki Room:

  • Perch rotation - 270 degrees, spins the bird around (not shown)
  • Lean - +20, -20 degrees, to lean forward and backward at the point where the legs connect
  • Head yaw - +45, -45 degrees back and forth
  • Head tilt - +15, -15 degrees up and down
  • Beak - 30 degrees, could be all open or all closed (shown in the diagram as 15 degrees)

I was thinking that after I constructed the foam version, I could figure things out from there, but after seeing this post on Hack-A-Day with a "HOG Drive", I realized I could leverage off of this design for the head linkages.

I chatted with Skip at Interlock, and by the end of this past Tuesday evening, I had two 3-D printed versions of this, using ABS, rather than the PLA material I am more familiar with. (Here's the Thingiverse link for the design.) Since I wasn't going to be mounting a motor, we (and by "we" I mean "he") replaced the motor space with a flat plate with a mounting screw hole.  He also replaced the back control arm with just a peg, since the bridge-like shape wouldn't hold up properly on his printer.


The first print (on the left) has a failed control peg on the center disk.  It was adding material onto printed material that didn't cool yet, so it just kinda globbed up.  This was improved by Skip by adding a second post, seen in the second version on the right.  He also added some material around the screw holes in the frame, to improve durability.

After printing and having this in my hand, I'm realizing that it won't quite work for me, although it does give me an excellent starting point.  The center disk is too small to mount the head on.  It's only about 1 1/2 inches in diameter. I think I'd want something about 2-3" in diameter, with plenty of mounting points and space for securing the head ,as well as space for wiring for the beak servo (or linear motor, or solenoid, or whatever).  It really showed me the design considerations for actually constructing something, not to mention it really emphasized that whatever design I can think of, I can print... which is pretty futuristically awesome.

But the important thing is that I know have ideas to build on for the final version.  I'll still be constructing a foam core model, and I'll be using this above design as a kick-off point.

(This post is cross-posted to the Interlock blog as well.)

Monday, March 4, 2013

Arduino EEProm Explorer

NOTE: there would be a screenshot right here, but there's really no point. It'd just be a terminal window showing something like this:
Anyway... while working on the BL-238 uComputer, I wanted to add EEProm support to load and save programs. One of the things I needed was a way to probe into the EEProm to see if everything in there looked correct, or if things were going awry, a way to reformat it and so on.  In the process, I created this EEProm Explorer which is available on github.

It presents a shell interface over the serial connection, that has a few commands that can be typed in.  Perhaps some of you out there can use it to help snoop at the data for your own programs, or whatever.  I may be adding in functionality to this (along with in TinyBasicPlus) to load and save EEProm data directly to SD Cards as well, but that's in the future.

Commands are:

  • format - clear the EEProm - fill it with 0x00 (zeroes)
  • dump - display a fancy hexdump of the EEProm contents, hex values and ascii equivalents
  • print - display the contents as though they were a text file (ascii only)
  • record - capture user input until a "." starts a line.  Great for filling with textual content.
  • poke A D - poke the data value "D" into address "A".   Both values are decimal numbers.
  • ? - display the help message, along with RAM/EEProm sizes.

So, download this sketch to your Arduino, and connect via the serial monitor, and just type in the commands to use them.

Be aware that different micros have different amounts of EEProm storage.  The 168-based devices have 512 bytes, while the 328-based devices have 1024 bytes.  Arduino DUE (Arm CPU) devices have no EEProm (so far.)

Future versions of this may change the builtin commands, or add to them.  (Current version as of this post is v002.)

Hope y'all have use for this little tool!

Setting up and using Arduino as a Programmer


One of the things that I've had to do for my re-purposing of the DB15 Stepper Motor controllers is to be able to reliably reprogram them.  The early versions of the programmer consisted of just a wire harness with a DB-15 connector on one end, and leads that plugged into the headers on a standard Arduino board. It eventually progressed into an octopus-like wire harness that used another DB15 as the "host" Arduino.  This worked well, but is cumbersome.  In this post, I'll highlight the basic circuit used, and the procedure for using it, specifically for this controller board, but the techniques are applicable to other ATmega based micros as well.

The reason for doing all of this work.  About 30 or so DB-15 widgets which can be repurposed as Arduino-compatible microcontroller boards.  They don't have all of the IO that a stock Arduino board has, but if your device only needs 6 IO (one of which is analog input), with a potential for another analog input, and 4 more digital outputs with a little work, they're an excellent free resource at Interlock!


The ICSP (In-Circuit Serial Programmer) is basically a device that takes in a firmware image from a host computer, and uses SPI-based communications with a target device to shove that firmware image into place.  For general Arduino use, you can shove the Arduino serial bootloader into place. This is about 1k (for the optimized bootloader aka "Optiboot") of program space that sits on your micro, next to any sketch that you download to it.  When the Arduino powers up or gets reset, this small bit of code will check for a new sketch to download.  If it sees something, it will accept it, shove it into program memory and then run it.  If it doesn't, it simply skips over and runs whatever sketch has already been downloaded there.

The ICSP allows you to program in that bootloader.  You can also use it to program in your sketch, if you need to reclaim that 1kbyte of space.  I'll get into that later on.

Okay.  Let's get into the hardware for a moment.

Host Connection.
Showing the basic construction for the Arduino-ICSP Host.

Target connection.
Showing how to hook up the D15 to the programming header above.  These 6 lines can also be arranged in the 2x3 layout standard on Arduino boards as well, or wired directly to ATMega chips for other applications.

On the Arduino, the pins are mapped as such:
  • Digital 13: SCLK (Orange)
  • Digital 12: MISO (Yellow)
  • Digital 11: MOSI (Violet)
  • Digital 10: SS (Green) (Wired to RESET for the programmer, DB15 pin 4)


The circuit to wire up is pretty easy.  On the host, there are three status LEDs that the packed-in "ArduinoISP" uses.  Heartbeat shows you it's alive, Programming shows you when it's programming a target device, and Error tells you when something went wrong -- which is also displayed on the host computer.

These three output should be wired through a 220 ohm resistor, to a LED, and tied to ground.

One other thing that may be necessary is to disable the reset circuit on the host Arduino.  This is necessary because when the computer connects to the host Arduino-programmer, that micro will reset, and then quickly hop into the "check for new firmware over serial for itself" routine, as explained above.  This may often cause failures with the host computer connecting and communicating with the programmer properly.  If you disable the reset circuit here, it will never fall into this state, and will remain perfectly stable.  The easiest way to disable it, if you're building it up from scratch, is to disconnect the DTR/Serial based reset trigger completely, leaving the 10k pullup resistor tied to the arduino's reset line.  However, if you're using a pre-constructed Arduino as the host, you can simply tie the reset line to +5v through a 120 ohm resistor.

Connecting the host to the target is also easy.  The target device should be hooked up as a basic arduino -- power, crystal clock, etc. Be sure that even if they're on separate power supplies, that they at least have their grounds tied together.  For ease of use, just power the target from the host completely. Past that, simply connect up pins 11, 12, 13 from the host to the target device.  This will put both on the same SPI bus.  This is how the data will get sent to the target device.  Basically, this maps out as SPI-MISO, SPI-MOSI, and SPI-CLOCK.  The only other connection you need to do is to hook up pin 10 from the host computer through to the RESET line of the target.

Step 1: hook up power, ground, serial IO, and reset circuitry.
The reset circuit is a 10k pullup resistor to +5v, and a .1uF cap to the reset line.
Next up will be putting a jumper to disable the reset line as explained above.
(Note: this picture is from a different build but shows the same first step)

The DB15 as seen here has pin 1 on the right.  The pins are basically: 1) TX,  2) RX, 4) RESET, then +5 and ground on the bottom pins.

The Red LED is the power indicator.  The resistor and cap for the reset circuit are visible, as is the jumper for disabling reset on the ICSP widget.

Above you can see the version of this board that I fabbed up for Interlock.  It has the FTDI header for connecting to the host computer, and used a pre-programmed DB-15 widget with the ICSP firmware on it.  I know this sounds like a chicken-and-egg thing, but once you program your first device using a standard Arduino as the host, it makes sense to program one of these, and use it to replace that board  instead. (especially when you have ~100 of them to spare. hehe)

The blue/white/red/white lines from the ICSP widget are equivalent to pins 10,11,12,13 on a standard host Arduino, and those go right into the cable down to the target device. Since pins 9, 8, and 7 were not all able to be broken out to the LEDs, I had to tweak the sketch a little.  8 is the LED on the ICSP widget itself, which is Yellow.  The Yellow and Green LEDs on the board (along with their current limiting resistors) are wired up to Analog 2 and Digital 3 (pwm), and these ports are changed accordingly.  8 remains as the error LED, 3 became the green Heartbeat light, and A2 became the new yellow program light.

Ready to roll, with a target device plugged in!
Note the extra prototyping area.  This can be for a ZIF socket in the future for other devices, etc.



The full circuit diagram for the D15-hosted programmer, connected to a D15 target.
(The wire colors are the same as the above for reference.)

Once this is all wired up, we can get some firmware down onto that thing.  In our case, we have a device that isn't directly supported by the Arduino IDE, so we need to configure that first.

Two things need to be installed. First is the board definition, second is the optiboot hex file. Both of these content files can be grabbed from my Geodesic Sphere repository.  Full instructions are also there as for specific directories on Windows and Mac for doing this installation. The "readme" there shows the text block to drop into your "Boards.txt" file, and where to find that file.  You will also need to drop the optiboot.hex file into the "optiboot" folder as well.  Once these two steps are done, you can start up the Arduino IDE and you're ready to program.  Let's also assume that we've already externally kickstarted this, and the "Arduino ISP" sketch is already on the host device, and is running properly.

Here's where it gets confusing.  What? You're not already confused?  HERE WE GO!

Fire up the Arduino IDE, and let's set it for the D15 device.  From the "Tools" menu, select "Serial Port" and select your FTDI interface's serial port name.  Next, from the "Tools" menu, select "ATmega168 at 7372800Hz (D15)" from the "Board" menu.  This will tell the IDE what our target device is.  Now, from the "Tools" menu, select "Arduino as ISP" from the "Programmer" menu. This is all one-time configuration stuff.  Now, you can plug in a target D15 widget to the end of the cable seen above, and then select "Burn Bootloader" from the "Tools" menu.  A bunch of lights should flash, and you'll end up with the Arduino bootloader on the target widget!

On the above setup, it's wired such that you can also use it to test the target.  Disconnect the FTDI cable, disconnect the ICSP widget, and move the newly programmed device into the DB15 connector on the board.  Adjust the jumper so that "RESET" is enabled.  Now plug the DB15 cable back in.  This is now the equivalent to using the DB15 as a barebones Arduino.  Load up the D15_Test sketch included in the github repository mentioned above.  Click the "upload" arrow button, wait a moment, and the LED on the target widget should be blinking.  That's it!

One alternate way you can use this is to program your Arduino code onto the target widget without installing the bootloader.  These widgets use an ATMega 168, which has very constrained space, so this might be preferred for larger programs.

Hook it back up in the programmer configuration, with the ICSP widget on the board, the target on the cable, and the jumper set to disable RESET.

From the Arduino IDE, instead of just clicking the "upload" arrow button, hold down the [SHIFT] key, and the text will change from "upload" to "upload using programmer".  It may take a moment longer, but the end result is that you will see the LED blinking on the target widget.

You can use this to program other Arduino-like devices too (ATMega, ATTiny, etc).  You will just need to breakout the 6 lines (MOSI, MISO, CLOCK, RESET, +5v, GROUND) to whatever pin header configuration or socket is necessary.  Then you can just select the target device from the menu as appropriate (ATmega 168, 328, 5v, 3.3v, etc) and then select "Burn Bootloader" from the menus as above, and it will put the appropriate serial bootloader onto the device for you.

Saturday, February 2, 2013

Tron Arcade Lighting Effects 1: New Hardware

As seen in a previous post, I have a Tron Mini/Cabaret arcade machine.  I used to have a Tron full-sized (FS) machine, but sold it many years ago.  One thing that the FS had over the mini was lots of extra lighting.

It had artwork beyond the monitor lit with a regular light, it had a blacklight above the control panel to make the traces glow, and make the joystick glow.  There's also a second blacklight below the control panel to backlight the bottom portion as well.  All of these lights are always lit, making the machine extra awesome.  On the mini, there is glow artwork, but no light to illuminate them.  Ever since the late 90s, I've had a plan to change this, so I bought a pack of UV LEDs, but they've sat dormant in my parts bin until now!

One thing that I'd like to bring to this, is to go an extra step, and bring some ideas over from the "Environmental Discs Of Tron" (EDOT) machine.  On the EDOT, you walk inside of it... one of the few, if not the only, games where you can do this.  Around the monitor and control panel are lights, similar to the FS Tron. However, on EDOT, they're controlled by the game.  They will flash and such when certain game events happen. I can make this happen with Tron, using an interface to the game, and a ROM hack.

Above all, the modifications made must be reversible.  I do not want to inflict any permanent damage or changes to the cabinet.  I will simply add lighting, make a ROM hack to control the lights, and mount an additional board inside the cabinet.

To start with, I need a secondary micro to control the lights. I'll use one of my stepper motor controller/Arduino devices. I made the FTDI programming and power interface seen above in about 30 minutes on the piece of strip board at Interlock this past Tuesday.  You can see the resistor/capacitor pair to handle the programmer's reset, power, and TX/RX lines, and a red power indicator LED for the heck of it.

After a bit more work, I had the 3 LED driver chips wired up, with their 8 outputs, along with the 5 pin header which I'll be using to interface it with the arcade machine.  The pinout there is two bits of input, 5v power input, and ground.  I'll add in SPI-like (clock+data) communications from the TRON game.  I figure that the first version will just send down a packet stating the lighting effect, but in the future I can use this to send down high scores as well, which can be sent out via serial to a host PC and post them on the net or something like that.

At first it didn't power on properly, and the LED driver chips got VERY hot.  Then I remembered that the circuit diagram I was referring to while soldering this up was incorrect and had power and ground reversed to the chip.  I also had + and - wired backwards for the LEDs as well. I forgot that these driver chips sink current, rather than sourcing it.  After a little bit of emergency soldering, all of that got worked out.

I've since cleaned up the wiring a bit, adding some insulation.

I decided to wire up the LEDs such that the current limiting resistor was wired up with the LEDs, rather than on the main board.  I'm glad I did this, as the resistance I picked (220 ohms) was way too high.

Enhanced image. It sadly doesn't look quite this intense in person.

Experimenting with how it will look to have LEDs inside of the joystick to illuminate it.

The output from these LEDs was much dimmer than I was hoping for. I will be experimenting with lower-valued resistors, as well as possibly doubling-up LEDs for lighting the various artwork elements.  I also need to figure out how to mount the LEDs without damaging the machine at all.

Next up is the ROM hack to talk with this!

(NOTE: This article has also been published to the Interlock blog.)

Monday, January 28, 2013

Inverted Colors Cube

Back in October, I first posted about my Inverted Color Cube.  It's basically a stickerless DaYan Guhong, which has colored plastic instead of black with colored vinyl stickers on it.  In this case, I put black stickers on it.  So rather than getting squares of color, each framed in black, you end up with squares of black, framed in a color.  I had run out of black stickers when I originally made it, and only recently placed an order with Cubesmith, including a bunch of black stickers.  I was finally able to finish this sticker-mod!


I think it looks awesome, and it's a lot of fun to play!  It's not too much of a challenge, but it's certainly a nice change!

Here are some of the sticker sets I just got from Cubesmith.  Each of the sets was only $2.50, and arrived in about two weeks.  If you plan on doing this with your cube, be sure to get the plastic scraper tool thing.  It's essentially a plastic razor blade, perfect for removing stickers.


Also in the order were a few sets of other stickers.  The top set is the vinyl "Studio" color set.  The colors don't really translate well here, but the blue is a dark blue, the green is a regular green.  Also, in person, the difference between the red and orange is a lot more obvious.

The bottom row is the vinyl "Half-Bright plus Bright Blue".  The green is more fluorescent, and the blue is noticeably brighter than the above.


Here's the vinyl mosaic set.  There's no green, but there's a pink set instead.  The red and orange are about as similar as they appear here.  Also the white/silver is prismatic, while the gold is just circular-brushed.  I'm not sure I like this set all that much.


I also got some extra white/silver prismatic vinyl stickers, the stack of black stickers, one set of which I used on the cube at the top of this post.  Then the bottom six are the vinyl "Chrome" set.  Silver, Orange, Green, Gold, Red, Blue.  They look really pretty in person, nice and metallic shiny looking.


And here is my Zhanchi restickered with those chrome stickers.  The thing is brilliant.  The funny thing is that in person the red and orange are very distinct, and the silver/gold are difficult to see... the opposite of this image.  But man...SHINY!  I'll have to be sure to always put it in a carry bag so that it doesn't get scratched to hell. hehe.