[Phil] uses both his computer’s speakers and a set of headphones while working at his desk, but he was growing tired of constantly having to remove the headset from his sound card in order to insert the speaker plug. He’s been meaning to rig something up to make it easier to switch outputs, but never seemed to get around to it until he recently saw this LAN-enabled audio switcher we featured.

His USB-controlled switch features a single audio input and two audio outputs, which he mounted on a nicely done homemade double-sided PCB. The switch can be toggled using any terminal program, sending commands to the on-board ATtiny13A via an FT232R USB to serial UART chip.

The switch’s operation is really quite simple, merely requiring [Phil] to type in the desired audio channel into the terminal. The ATiny and a small relay do the rest, directing the audio to the proper output.

[Quinn Dunki] keeps rolling with her 6502 based computer build. This time around she’s added some memory to store the programs, but needed a way to get that code into the device. Above is her solution, a bank of hex switches used to program the 8-bit command and 16-bit address for each line of machine code.

This is a continuation of her Veronica project. The last time we saw it she had hardwired the logic levels for the data bus, but that’s no fun since nothing can actually be computed. [Quinn] picked up an SRAM chip which will store the program. It’s compatible with the 6502′s memory bus, but needs a bit of extra circuitry for her to be able to hand program it with this switch bank. She used some tri-state buffers to switch between connections to the processor, and to the hex switches. This way, she disconnects the RAM from the processor using the buffers, uses the switches and push button to clock in the program, then patches the RAM back into the computer.

Seeing this process in the video after the break certainly gives you an appreciation for what an improvement the punch-card system was over this technique. Still, seeing this is a delight that we’d like to try! Read the rest of this entry »

[Hamster] wanted to take a look at division operations when the chip you’re using doesn’t have a divide instruction. He makes the point that the divide instruction takes a lot of space on the die, and that’s why it’s sometimes excluded from a chip’s instruction set. For instance, he tells us the ARM processor used on the Raspberry Pi doesn’t have a divide instruction.

Without hardware division you’re left to implement a binary division algorithm. Eventually [Hamster] plans to do this in an FPGA, but started researching the project by comparing division algorithms in C on an AMD processor.

His test uses all 16-bit possibilities for dividend and divisor. He was shocked to find that binary division doesn’t take much longer than using the hardware instruction for the same tests. A bit of poking around in his code and he manages to beat the AMD hardware divide instruciton by 175%. When testing with an Intel chip the hardware beats his code by about 62%.

He’s got some theories on why he’s seeing these performance differences which we’ll let you check out on your own.

For years, [Rasmus] has left his computer connected directly to the mains power so that he can turn it on via Wake on Lan. While powered down, it would still continuously consume about 6W of electricity, but now that he didn’t need it to be on standby so often, he wanted to make it more energy efficient.

In Denmark, where he lives, many people use power strips that have an onboard USB cable. These strips are meant to reduce the standby power consumption of PC peripherals such as monitors by powering on the mains sockets only when the computer is active. He decided the easiest way to cut his standby energy consumption to 0W would be to power his computer via this strip as well.

While it sounds great in theory, it presented a sort of chicken/egg problem. If the computer needs to be turned on for the power strip to recognize it, then how could he also supply power to the computer from the same strip? His solution was a small circuit that would charge up while the computer was running, and still hold enough juice to kickstart the PC’s boot process, thus turning on the power strip.

It really is an ingenious way to go about things, nice job!

If you happen to do a lot of video encoding, you know that your computer can really drag while the process is carried out. Our own [Mike Szczys] transcodes videos at home fairly often, and because the process is automated, he doesn’t always know if a conversion is taking place in the background.

He has been tinkering with Larson Scanners recently and thought he could put everything he’s learned along the way to good use by using the scanner as a “busy” indicator for his PC. He hooked the scanner up to the computer’s parallel port, and took a few minutes to bang out some Python code that would alert him when his PC was busy.

He set his notifier script to launch along with FFMPEG, whenever his MythTV setup had something ready to convert. The Python script drives a pin on the parallel port high, triggering the Larson Scanner’s animation. Every minute, the script checks the status of FFMPEG and continues to hold the pin high until the application exits. Once the conversion is done, the scanner goes back to sleep, letting [Mike] know that the coast is clear.

Continue reading to see a video of his parallel port trigger in action.

Read the rest of this entry »

[Richard] wanted to create a color profile for his computer monitor, but he wasn’t thrilled with the existing color calibration offerings he found for sale. Color calibration tools can be somewhat costly, but even more troubling to [Richard] was the fact that they are all closed source. Closed hardware and closed software can be a drag, especially when manufacturers drop support for a product, so he set off to design his own open-source monitor calibration tool.

Once his ColorHug sensor is placed against a monitor, it begins sampling colors from the screen, creating an ICC color profile from the data it gathers. The sensor is a Linux-only tool at the moment, but he has created a live CD from which a color profile can be created, then subsequently used in Windows or OSX.

While ColorHug doesn’t sport all the features of its commercial competitors, its color sampling rate is second to none, and since the software is open, anyone is free to implement any sort of functionality they wish.

[Richard] is currently selling finished ColorHug modules to anyone interested in giving them a test drive, but you can always build your own from the plans found at ColorHug’s Github repository.

[via Adafruit blog]

[Oliver] had an old NES controller laying around, and without any other use for it, he decided to repurpose it as a portable storage device.

He gutted most of the controller, removing the plastic standoffs, leaving the D-pad and remaining buttons intact. He crammed a 32 GB flash drive inside, along with the guts from an SD card reader. Using a Dremel he cut several openings into the controller, one for the flash drive and SD card reader’s USB ports, as well as for the SD card itself. When the physical modifications were finished, he installed a small Linux distro on the flash drive, which can be run by any PC that supports booting from USB.

While some might argue, we think it’s a neat way to reuse an old gaming peripheral that he might have otherwise thrown out. The portable OS is something that would certainly come in handy, though we can’t wait until the Raspberry Pi is finished – it would be awesome to have a complete computer packed in there too.

[Jeremy] had an ASUS EEE PC 1000HE netbook on his hands which had succumbed to a corrupted BIOS. In most situations, people replace a motherboard when the BIOS is damaged beyond repair, but considering the price of motherboards, especially those built for portable devices, he simply refused to go that route.

Instead, he took it apart and did a little investigation to find out what SPI flash chip ASUS used in the netbook. With that information in hand, he put together an SPI flash programmer using a breadboard and a DLP-USB1232H USB to UART module. He couldn’t program the flash chip in-circuit, so he had to desolder it and deadbugged it onto his programmer. Using a few Linux-based flashing tools, he was able to reprogram the chip with a functioning BIOS in short order, saving him from a costly motherboard replacement.

While some motherboard manufacturers have built in secondary BIOS chips to prevent the need for this sort of recovery, it’s nice to know that the process is relatively straightforward, provided you have some basic soldering and Linux skills.

This also isn’t the first time we’ve seen someone recover an EEE PC from the brink – if you’re looking for an Arduino-based alternative, be sure to check this out.