This project is to build a standalone retro emulation station using the Cubieboard 2 (Arm A20) inside a modified N64 console
Already have an account? Log in.
To make the experience fit your profile, pick a username and tell us what interests you.
While looking around at the local electronics recycler, an N64 caught my eye. I realized that it looked an awful lot like an old radio. So, creativity struck.
The Nintendo 64 logo on the front looks a radio dial, and the controller ports look like knobs. So this is where I begin.
So, I have been trying to experiment a little to get a more bakelite like appearance. While playing with some scrap, I stumbled on a combo that actually works pretty good and is pretty easy.
What I did was go over it with a flat black spray from a great distance. Then I very lightly sprayed gold metal flake. I did both of these steps while both layers were wet. Then I let it dry and also from a distance, hit is with the leather brown paint.
It shows up not so great in this photo, but in person you find black and and light specks appearing to float in the leather brown. The gold is showing up a bit too much, so I will likely hit it with another light layer of the brown. When I am satisfied I will give it a layer of clear gloss to make it pop.
True bakelite (at least the products I have laying around for examples) usually has some heavier dark streaks inside it. I have done some reading and this could be done with acrylic paints and some brushes, but I am not artist. lol. So I am satisfied with my spray approach. It looks close enough for me.
I haven't abandoned this project, just set it on the side-burner for a bit while I was designing and building some furniture. I ended up buying an Android TV box with an A20 in it to develop on. I also wanted a box for my bedroom TV to stream off my WDTV Live Hub downstairs.
One of my reasons is that cross-compiling is a long learning curve when you are starting from the bottomish part of the hill. It seems so much easier to develop on the hardware.
Anyway, I have gotten Linux to run on it so far and have been able to compile a few things. The nice thing about the A20 is that it is pretty much unbrickable, so great for a newbie like me. I have messed things up so many times now trying to learn. Also nice is the Sunxi support wiki. There are a lot of resources for this processor on that site. Granted, it is not really organized well for a complete beginner, but I am learning.
It was always planned that this was going to be the hardest part for me. I have now reached the part of the project that I am the weakest in. However, I am enjoying the process. Along the way, I am also learning quite a bit about Android.
I did give up on expecting to 3D print my parts on the Cube printer. The printer is junk in my opinion. I was at first using Sketchup and thought that was my problem, so I taught myself inventor and tried that. Same result. It's the printer. Don't get the cubie if you want to design anything with any kind of precision. /rant off
I'll have some more updates soon.
I've had to take a pause again from working on this due to the day job, but quite a bit of progress has been made which I will detail in a later post. Just wanted to throw in an update of one part:
I want the USB ports to float in the controller ports like the original. So I designed and 3D printed some inserts. The printer I used was a Cube 2 printer (I don't recommend it - thankfully my work paid for it, not me!) They required quite a bit of trimming to fit properly even though I triple checked my measurements due to the inaccuracy of the printer. They are designed to snap into the slots on the sides of the controller port for a tight friction fit.
I am going to be redesigning these to have more of a floating look and hopefully a better fit. I plan to accomplish that by having only three points the length of the USB connector. I will post up the files for it once I get them just right for anyone wanting to do the same.
I am also planning to design and print a bezel for the lens on the front, but I am actually considering doing a chemical etch of some copper sheet for that instead.
Several other custom 3D printed parts are also in the works.
Stay tuned...
Things are still slow going for me. But I have made some progress on the enclosure. This is the color scheme I am shooting for. I removed any extra plastic from the inside to make room. I also cut out the front bezel leaving just a lip for the plastic lens. I need to find a good way of smoothing out that lip, since I am expecting it to show through the clear lens. I am planning to mask things off and paint just the lip in gold like the other parts.
I ruined the lenses trying to sand and polish them (I still haven't found a reliable way to do this with clear plastic), so I made molds and am in the process of casting new ones in clear resin.
I also cleared out the grill in front of the cartridge port from the inside. I will be installing a fine copper screen beneath that and the cartridge port. I have debated cutting some features out on the top on either side of the cart port as well and putting screen behind them (to simulate speakers), but that might be too much.
Of course, these pictures are missing the feet which were also painted gold. I need to update the pics, I guess. That white stuff is from the buffing compound I used to smooth out the paint. That's all been cleaned off of course.
The memory expansion port was cut down from the inside but left enough so that the lid can still snap in. I am thinking of putting my uSD extender and the OTG usb mini port inside there so I will have access to them externally.
That little oval beneath the bezel was the power light for the N64. From the inside, it was a plastic light pipe. I painted this with chrome paint (masking off the very tip) to increase reflection. I ordered some amber LEDs to simulate incancescent light.
A feature that I thought would be neat is to give the vent openings a "tube glow." But I would want to be able to turn that off since it isn't something I would need to be on all the time.
I have also modded the 1.5" OLED screen to be able to install it in the front bezel. I haven't finalized exactly how I am going to implement it. Brainstorming has gone from modifying U-boot to show a logo while booting, system health, or maybe even different emulated system logos when an emulator is chosen.
Displaying stats from games would be cool as well, but I think something would have to be programmed for each individual game in order to do that.
Right now, the plan is to put the IR receiver beside the screen in the same bezel. But I am also thinking it might be better to move that to another spot. Any ideas (as if anyone is actually reading this...)?
And of course, I am trying to think of ideas to simulate a radio dial. But the OLED screens are blue on black, so unless I switch to a full color LCD screen that would cover the entire lens area, I am not sure how that would work out. If someone has any ideas, I would love to hear them. With the uGFX library, it appears that I can make the screen a standard output from linux, so once that is all set up, I should be able to display pretty much anything (in 128x64 resolution, of course.) I am open to getting a different screen, of course. Just need some ideas beyond "hey that sounds cool" which is about as far as I had put into it so far.
Thinking about the back panel, it appears the only connections back there are going to be power in, HDMI, and LAN. The wifi and bluetooth will be connected to a hub internally. There will be two ports left over, so perhaps I will bring those out to the back.
The controller ports will be on another 4 port USB hub. 2 for controllers and the other two for a keyboard and mouse (though I will be using a bluetooth keyboard and mouse in normal use.)
Been a few days since I have posted anything due to a family emergency. I have been trying to brush up on the cubieboard, build environment, and working on the case.
The learning curve to the Cubieboard is a bit steep. Especially coming from very little experience with Linux in general. This is further complicated by the fact that the Cubieboard community is young still and the support is not the best. Even trying to follow the toolchain instructions at Linux-Sunxi seems to assume you have alot of other stuff already set up and it is bit cryptic what that stuff is. And for whatever reason, the forums will not send me an activation email. Grr...
But I plug along. If anything, I am persistent and patient.
Once I get the hang of this, I will definitely be putting something together to help others along. And since I am planning to go from u-boot, dual boot, kernel, and package development from scratch from a complete newbie perspective, my hope is that this will give us all the tools to build our own systems with this board.
On to the case:
I have disassembled the final enlclosure and started moving my work over to that. I used JB Kwik-weld to fill the nintendo logo and and any chips and dents that I found. I had tried to use bondo before, but it just crumbles away. The two-part epoxy holds up much better. After filling and sanding, I added two coats of flat gray primer to the top and bottom halves of the enclosure. I plan to let this sit for several days to allow the primer to fully set.
I drilled and ground out the front controller connectors leaving just the shells. I then sanded and primered these. I then went over them with a chrome metallic paint. I then used a copper-ing spray to give it a nice copper finish. Basically it is just a tint over the chrome. Once all this has settled, it will be sealed with a clear coat for luster.
I originally planned to use some panel mount USB cables to mold into the controller ports, but they didn't quite fit like I wanted. So I have ordered some DIY USB Female A connectors and shells. I will be setting these within the controller shells with epoxy.
I installed the HDMI extender cable into the video out panel. It required some filing to fit. Then I used non-hardening modeling clay shoved into the connector and carefully trimmed to mask off the connector. Then again the two part epoxy was used to bond and fill the two parts together. The mask will stay in place until after painting. Then I will simply pull it out. The same will be done with the front USB controller ports.
The cartridge port and top grill will have a fine copper screen installed. The grill will need to be modified to remove the inside grill parts allowing the screen to show better. Two part epoxy will then hold the mesh screen in place. The goal is for this to look like speaker grills.
For the buttons, I am experimenting. I plan to paint them the same bakelite brown color as the rest of the chassis, but I want the letter to show up in chrome. So the idea is to paint them brown, spray them with the chrome paint and give it about 5 minutes and wipe the chrome paint off leaving it in the recessed letters. This will be helped by masking off the areas around the letters.
I managed to mess up both of the lenses trying to polish them and tint them. I plan to order some tinted plexiglass and just make new ones. I wish I could figure out the right process to sand and then polish these things to crystal clear again because the shape of the lens is rounded and I am going to lose that by using flat acrylic unless I can sand it to the shape I want.
I received the 1.3" OLED display and have started looking at what's out there to control the SSD1306 controller on ARM over I2C. Adafruit has some code for the Raspberry Pi that can be ported. I also found uGFX library which has advanced GUI stuff. Once I can get a toolchain up and running properly, I can get these ported and incorporated.
In summary, some progress has been made on the case. It's slow going...
Read more »I believe I mentioned that I am completely new to embedded Linux development. Well, I'm also fairly new to linux, period. I've wanted to learn it for a long time, but never really had a need to. As an electrical engineer, my tools have been all windows based.
I mean, I know linux as a user. I can install a pre-made distro and navigate my way around it. But really understanding how it works? No.
I believe that I also mentioned that the community for the Cubieboard is not very large. In many cases, I am going to need to start almost from scratch in building this. There has been talk about gaming on it, but I have been unable to find any real serious efforts. Now, of course, being an ARM system, there is tons of code out there already. But it needs to be compiled for our particular kernel and using the board support packages for our particular hardware. Not much of what I am trying to do here has already had this done.
So, for what I am wanting to accomplish, I have a very large and steep learning curve ahead of me. One of the barriers to entry I have found whenever I have tried to wrap my mind around embedded linux is that examples and tutorials seem to go one of two ways. Either they just flat out tell you what commands to enter without really explaining why, or they make a lot of assumptions about what you already know. I am going to assume that I know nothing. Because what I know already could barely fit in a lunch box.
So, one advantage to following along with me, is that if you are also a novice, you can get a chance to learn with me nearly from the ground up.
Let's start with the basics with a small recap of what I am hoping to accomplish. I would like a multiboot system running Android and Linux. I would like to choose which OS I am running using a GPIO input on the processor. Here is a diagram I threw together to show a typical boot sequence, a typical multi-boot sequence, and a modified version to support what I am looking to do:
The very first piece of (user) code run on the embedded linux system will be a bootloader. The most popular and widely supported is uBoot. At this level, it is assembly level bare-metal code intended to set up the hardware to the point of being able to load the kernel from some storage device. In a computer, the bootloader would be your BIOS. It has the basic drivers for the hard drive, keyboard, monitor, etc... At the completion of the BIOS, it looks for a boot sector on the storage device (HDD in that case) the boot sector on the hard drive begins the process of loading the OS. The embedded linux system is very similar to this.
uBoot has already been compiled for the Cubieboard. So, in most cases you could just download it, flash it over to the board and not think much about it (actually, it is already installed.)
In order to support checking a GPIO pin at power up, we actually have two options. We can modify uBoot to include drivers for the GPIO pins and incoporate a check to determine which kernel to load, or we could modify a boot manager (which normally throws up a menu which the user then selects the OS using a keyboard or mouse) to accept input from the GPIO pins. When I drew up the above diagram, I initially felt it made sense to insert my code at the point of uBoot. But as you will see in the upcoming posts, it would be much more flexible to do this at a boot manager level. One reason being that uBoot is not easily modified by the system itself. With a higher level boot manager, you can have a nice config file to make changes whenever you like. Also, moving to this level means you could boot from other storage with a different set of multi-boot partitions.
I am planning to attempt both. For one, to learn and understand uBoot at that level of detail, and also to determine which provides the fastest boot time.
When I build something, I want to fully understand it from the ground up. So, in that sense, I am happy that there isn't an easy way out for me here. I had originally planned to use the Raspberry...
Read more »I didn't have much time to work on this tonight, but I managed to set up a little dedicated work bench to start work on the software. Some might appreciate that most of this stuff in the picture was either free, salvaged, or bought very cheaply from the electronics recylcer (and repaired.)
We have an old 15" Dell monitor that was given to me and had bad caps. This is eventually going into an iMac enclosure with Commodore 64 and disk drive installed. But for now, it is connected to my $20 Compaq Ultraslim desktop that also had bad caps in the power supply. Upgraded it to 3GB of RAM, 400GB HDD, and a dual core 3.4GHZ Pentium D. I had all the parts lying around. It is set up to dual boot Linux and Windows 7.
The local electronics recycler also had a decent 19" HDMI LCD TV for $7.50 with a bad backlight inverter. 1 hour of troubleshooting and repair and now it serves to connect to the cubieboard. An old 10/100 ethernet switch brings a single cable from my router to these two machines.
I'm used to working on my 24" Dual monitors, so this might be a challenge working on a little 15" monitor. But I think I'll survive. lol
Eventually, a keyboard and mouse will be supported over bluetooth. But for now, we just have an old pair of USB peripherals plugged in.
The Cubieboard2 comes preloaded with Android 4.2.2 loaded in the 4GB NAND flash. The launcher of which you can see displayed.
My goal is to support dual boot of Android and Debian Wheezy on the Cubie. Ideally, I would like to install a switch that would be detected at power up and choose the OS. "Super Ideally" would be able to switch from a remote. That will require a little board to be thrown together to generate signals on the GPIO pins and trigger the power up. But first, I need to get the GPIO idea working.
Pressing power on the cubieboard will initiate a proper shutdown and it also kills the SATA power port at the end. I will be powering the SATA drive separately, but I realized this feature will come in very handy for controlling the power to the USB hubs and drive.
Today I also picked up a specialty spray paint meant for blacking out headlights. I am going to try to tint the front lens with this.
BTW, The chemicals you see off to the side are to make home-made Sugru (cornstarch, Silicone caulk, and Naptha.)
Digging into the schematics for the Cubieboard tonight and focused on the power management IC. It is an AXP209, which has an integrated push on/off function which is controlled through linux. In fact, the power switch on the board is just a push button. So nothing special needed for this.
The AXP209 also has a lithium ion charger built in, as well as outputs to control point of load supplies to peripherals. These don't appear to be used, but hacking into these may be useful to shut down the supplies to the hard drive and USB hubs.
The datasheet is in Chinese and my Chinese is a bit rusty (ok, it's non-existant.) But I am determined now to figure it out.
There is plenty of English information at the link below, however.
I received some of the parts today, including the Cubieboard 2 (wow, that was fast. Just ordered it Friday), adafruit smart power switch, the SATA caddy, and 6" HDMI cable.
I started playing around with layout and realized for optimal positioning, I need a longer HDMI. The hardware is going to need quite a few mods done, and I don't have all the parts in yet to do it. So I have put them aside for now. Just thought I would post some eye candy and talk about the Cubieboard and the planned mods a bit.
I decided on using a HDD caddy because it makes things easy to mount. So I looked for one with flanges. It came with the screws for the drive as a bonus. It was intended as replacement parts for a dell laptop.
The Cubieboard 2 comes with the custom SATA cable, which has a 2 pin header to plug into the Cubieboard for power. I will connecting that separately to the 5V bus. Also coming with the cubieboard is a USB to barrel jack cable for powering the board from USB. It can also be powered from the micro-usb port much like the raspberry pi. But unlike the raspberry pi, that port is also an OTG port.
You can also see in this picture the 6" HDMI cable and the adafruit smart power switch. I didn't have enough light to get great pictures, so I'll borrow some from the respective sites...
The Adafruit power switch is push on/push off switch that can switch a 3A load between 3 and 14V. It also has a kill pin integrated which can be used by your system to kill power as part of the power down script. The project has had a bit of scope creep since first conception, so I am rethinking the 3A limitation. According to the adafruit datasheet even at 3A, the FET gets pretty toasty. Thanks to the schematic, I could easily whip together my own version with a bigger FET. Also, I'd like it not to kill power right away when the switch is pressed, but instead initiate a proper shutdown and have the Cubieboard kill the power. So some redesign is going to be necessary. Really all that is needed is to switch to a stable latch which can be reset by a GPIO line. Still a nifty part at $5. For the power switch itself, the N64 used a slide switch. I will be modifying the switch so that it has a ramp that presses on a push button, and spring returns.
The cubieboard is great for hacking. There are through holes on the board for nearly all the connections. This makes it great for hardwiring into a device. The USB jack needs to be removed to access the header connections, but the rest are accessible without removing anything. The ethernet jack includes LEDs and integrated magnetics, so I will be building an extension cable rather than wiring directly to the board.
The cubieboard also has two 48 pin headers with multiplexed pins for GPIO and special purpose applications. Lots of expansion possibilities. The pins are 2mm pitch.
Currently I have planned to use the I2C bus for the front OLED display, and 2 of the GPIO pins. One for the power switch and the other as an output to kill power.
That's it for today.
With a few failed experiments in tinting the lens (and not having the display yet anyway) I decided to start working on the rest of the enclosure. I want my console to look like bakelite. So I browsed the local hardware store for paints and found a rich brown gloss paint that looked just like bakelite. I tested it out on the top half of the guinea pig enclosure.
It came out really nice. But the texture of the N64 showed through. I might need to sand all the texture down to enhance the gloss and look more bakelite-like.
Also, I bondoed the nintendo logo in the back, but it still showed up. I am planning to fill it with 2 part epoxy instead as soon as I can figure out how to build a little pressure tool to push the epoxy flat into the logo. Brainstorming a syringe and a custom shaped box made airtight. The epoxy sets up in 5 minutes, which is actually a long time to apply pressure to a syringe. Maybe I am just impatient.
I also removed the controller ports which are soldered onto the main board of the N64. I had to unsolder them, pull out the pins and then used a drill to gut the centers of them. I will be installing USB ports inside them and will fill around the port. Not sure if I will be using sugru or epoxy putty to do this. I need to do some thinking because I intend to chrome these. If I mold in the USB ports first, I will need a way to mask them off when I paint.
The feet, power and reset buttons will also be chromed. Previously when using chrome spray paint, I didn't have much luck. So it will take some experimentation to get it to work. I could have them actually chrome plated, but this is pretty costly.
Finally, I ordered some nice brass mesh with a high copper content which will be installed in all the vents as well as the cartridge opening. The idea is to simulate speaker grills. I had considered drywall patch screen and electroplating it, as well as looked around for nice patterned screens, but didn't really find anything affordable or desirable.
Sigh... I have access to a 3D Printer (It's a Cube, so don't get too excited) at work but do not have enough experience to design 3D parts yet. So I will be sticking to all the old methods of fabrication that I am used to. I can't help but think how much easier this would be using the 3D printer though.
Anyway, the parts will be arriving throughout this week, so I will be taking plenty of pictures and updating this project as I go. My intention is log everything, including my failures, all the way up to connecting up the finished product and demoing it. I also expect to have many questions along the way and would really appreciate any suggestions, feedback, or help in the comments.
Retroplayer
Tom Nardi
Magic Robots
x86 FanBoy
Andrew Bills
I am just learning linux and realize there is a steep learning curve here since there aren't currently any of these compiled for the cubieboard hardware and kernels yet. So a ton of work will be needed. However, most SW intended for the Raspberry Pi should run on this with some tweaking.