Everyone remembers Battlebots, and those of us feeling the pains of nostalgia have tuned into the recent reboot on ABC. As with the golden age of Battlebots, all robot fighting competitions eventually become a war between machines perfectly designed for the task. In the original run of Battlebots, this meant a bracket full of wedge bots, with the very cool robots eliminated year after year.
You don’t watch NASCAR for the race, you watch it for the crashes, and professional robot fighting competitions will always devolve into a few hundred laps of left turns. Fire and sparks are great, but there is a better robot fighting competition, and this time anyone can get in the game without spending years working on a robot.
It’s called Hebocon, and it’s billed as, ‘a sumo wrestling tournament for those who don’t have the technical skills to actually make robots’. The best translation I’ve seen is, ‘shitty robot battles’, and it’s exactly what robot battles should be: technical mastery overcome by guile, and massive upsets through ingenious strategy. You won’t get fire and sparks, but one thing is certain: no robot will make it out of Hebocon fully functional, but that’s only because they weren’t fully functional to begin with.
Continue reading “Hebocons And Why They Matter”
Over the last few years, [Marcin] has been working on the building blocks of civilization. He’s busy creating the Global Village Construction Set, the fifty most useful machines ever created. Everything from bread ovens to combine harvesters is part of this Global Village Construction Set, and everything is open source, free for all to use and improve upon.
For this year’s Hackaday Prize, [Marcin] is working on an Open Source Bulldozer. The ability to create earthworks and move dirt around is actually one of humanity’s greatest achievements, and enables the creation of everything from foundations for homes to trans-oceanic canals.
This Open Source bulldozer is astonishingly modular, scaleable from a one-ton microtractor to a 13,000lb dozer, with attachment points for blades, drawbars, and everything else you can attach to a Bobcat earthmover. It’s 168 horses of opensource earthmoving capability, and a perfect addition to this year’s Hackaday Prize.
[Marcin] and his group Open Source Ecology posted a video of this micro bulldozer rolling around on their shop floor recently; you can check that out below. You can also see our coverage of the GLVCS from several years ago.
Continue reading “Hackaday Prize Entry: A Civilization Starter Kit”
[Chris] recently moved a vintage IBM 5150 – the original PC – into his living room. While this might sound odd to people who are not part of the Hackaday readership, it actually makes a lot of sense; this PC is a great distraction-free writing workstation, vintage gaming machine, and looks really, really cool. It sat unused for a while, simply because [Chris] didn’t want to swap out piles of floppies, and he doesn’t have a hard drive or controller card for this machine. After reviewing what other retrocomputer fans have done in this situation, he emulated a hard drive with a Raspberry Pi.
The traditional solution to the ‘old PC without a hard drive’ problem is the XTIDE project. XTIDE is a controller card that translates relatively new IDE cards (or an emulated drive on another computer) as a hard drive on the vintage PC, just like a controller card would. Since a drive can be emulated by another computer, [Chris] grabbed the closest single board computer he had on hand, in this case a Raspberry Pi.
After burning an EPROM with XTIDE to drive an old network card, [Chris] set to work making the XTIDE software function on the Raspberry Pi side of things. The hardware on the modern side of the is just a Pi and a USB to RS232 adapter, set to a very low bitrate. Although the emulated drive is slow, it is relatively huge for computer of this era: 500 Megabytes of free space. It makes your head spin to think of how many vintage games and apps you can fit on that thing!
[Radical Brad] has played around with FPGAs, video signals, and already has a few astonishing projects of bitbanged VGA on his resume. Now he’s gone insane. He’s documenting a build over on the 6502.org forums of a computer with Amiga-quality graphics built out of nothing but a 65C02, a few SRAM chips, and a whole pile of logic chips.
The design goals for this project are to build a video game system with circa 1980 parts and graphics a decade ahead of its time. The video output is VGA, with 400×300 resolution, in glorious eight-bit color. The only chips in this project more complex than a shift register are a single 65c02 and a few (modern) 15ns SRAMs. it’s not a build that would have been possible in the early 80s, but the only thing preventing that would be the slow RAM chips of the era.
So far, [Radical] has built a GPU entirely out of 74-series logic that reads a portion of RAM and translates that to XY positions, colors, pixels, and VGA signals. There’s support for alpha channels and multiple sprites. The plan is to add sound hardware with support for four independent digital channels and 1 Megabyte of sample memory. It’s an amazingly ambitious project, and becomes even more impressive when you realize he’s doing all of this on solderless breadboards.
[Brad] will keep updating the thread on 6502.org until he’s done or dies trying. So far, it’s looking promising. He already has a bunch of Boing balls bouncing around a display. You can check out a video of that below.
Continue reading “Vulcan 74: A Masterpiece of Retro Engineering”
A car from 1940 would have been an almost completely mechanical device. These days though, a car without electricity wouldn’t run. It’s not the engine – it’s the computers; the design details of which automotive manufacturers would love to keep out of the hands of hardware hackers like us. [Mastro Gippo] wanted to build a small and powerful CAN bus reverse engineering tool, and the Crunchtrack hits it out of the park. It’s a CAN bus transceiver, GPS receiver, and GSM modem all wrapped up into a single tiny device that fits under your dash.
[Mastro] has a slight fetish for efficiency and tiny, tiny devices, so he’s packaging everything inside the shell of a standard ELM327 Bluetooth adapter. This is a device that can fit in the palm of your hand, but still taps a CAN bus (with the help of a computer), receives GPS, and sends that data out over cell phone towers.
The device is based on the STM32 F3 ARM microcontroller (with mbed support), a ublox 7 GPS module, and an SIM800 GSM module, but the story doesn’t stop with hardware. [Mastro] is also working on a website where reverse engineering data can be shared between car hackers. That makes this an excellent Hackaday Prize entry, and we can’t wait to see where it goes from here.
For his Hackaday Prize entry, [MIPS ARMSTRONG] is working on an open-source terrarium that will be one of the fastest way to grow foodstuffs or other edible greens. He’s calling it Project EDEN, and it’s shaping up to be one of the most advanced homebrew horticultural devices ever made.
There are a few things that make this indoor greenhouse unique. The most obvious is the incredible number of LEDs used as grow lights. [MIPS] is using 900 Watts worth of Royal Blue and Deep Red LEDs. To water these plants, [MIPS] is taking a cue from NASA and building a High Pressure Aeroponics system – a device that shoots droplets of water only 50 microns in diameter directly onto the roots of the plants.
One of the more interesting aspects of EDEN is the CO2 system. The bulk of plant biomass – like humans – comes from carbon, and plants get their carbon from the atmosphere. Studies have shown that increasing the concentration of CO2 in a grow chamber can increase plant growth. There is a limit before CO2 becomes toxic to plants, so [MIPS] will have to keep a close eye on the CO2 levels with gas sensors.
With high-pressure watering, a CO2 system, and an amazing array of LEDs, this is one of the most advanced homebrew horticulture projects on the planet. It’s also a great fit for this year’s Hackaday prize theme of ‘build something that matters’, and we can’t wait to see [MIPS]’s future developments of his awesome aeroponic terrarium.
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.