Star Wars: Yoda Stories was released by LucasArts in 1997 to minimal critical acclaim. As IGN said, “like Phantom Menace proved, just because it’s Star Wars doesn’t mean it’s good.” This didn’t stop [Zach] from playing it, and years later, taking an interest in reverse engineering the game.
[Zach]’s reverse engineering of Star Wars: Yoda Stories (google cache) takes a look at the game’s data file. This binary file is parsed by the game at run time to extract sound effects, sprites, and map tiles. Perhaps the best known game data file type was Doom’s WAD file, which had purpose built editing programs from third parties.
After a quick look at the data file in HxD, [Zach] began writing scripts in C# to extract different sections of the data file. Once the sections were found, more code was used to apply a color palette and generate bitmaps.
In the end, [Zach] managed to get a couple thousand tiles of the game’s data. He found some interesting ones, such as the sports car that he replaced the X-Wing with in his mod. The engine for an earlier Lucasarts game, Indiana Jones and His Desktop Adventures, should be very similar, and once we find the Mac install disk and a copy of ResEdit, we’ll post something on Hackaday.io.
There were two LA hackerspaces represented at our 10th anniversary party, and members from both of them were able to give a talk on the projects coming out of their labs. [Arko] from null space labs showed up with a few of his creations including CUBEX, his high altitude balloon payload and a demoscene board he’s been working on. [Tod] from Crashspace showed up with the rest of the Crash crew and helped out with the morning build-offs and labs.
A Demoscene Board
Demoscenes, for one reason or another, aren’t extremely popular in the US. In Europe, you can find teams working on programatically generated music videos year-round, coded for Commodore 64s, Amigas, even stranger computers, and x86 assembly. There’s an art to the whole thing, but for those of us on this side of the pond, there aren’t many venues to demonstrate impeccable graphics programming skill.
[Arko] wants to change this. He’s designed a demoscene board around a PIC micro with hardware graphics acceleration, USB OTG, VGA out at 640×480, and an audio out port. It’s meant to be a platform to create demos on, and already [Arko] has ported the famous Craft demo from [lft] to his platform. Edit: the Craft demo was playing on the older ATmega88 version of the board. The PIC board is a little more capable.
Being that there are so few Demo parties in the US, only building a board to play demos would be just a bit shortsighted. [Arko]’s main reason for giving this talk was to tell everyone about the LayerOne Demoparty next year just a few miles from the Hackaday Hackaspace. It coincides with the LayerOne conference, and the board itself will soon be available for sale in the Hackaday store.
Blink(1) and How To Kickstarter
When it comes to electronics and tech Kickstarters, Blink(1) defines what it means to have a minimum viable product. It’s a USB plug, a small microcontroller, and an RGB LED. That’s it. [Tod] wanted to take this simple project and learn how to turn it into a product. [Tod] emphasised the ‘learn’ part of his plan; the alternate title for this talk was, “How to Fail Multiple Times and Still Ship 20,000 Units.”
The Blink(1) started as a standard My First Arduino Sketch, blinking three LEDs, quickly moving over to a USB LED device. This rather large USB dongle sat there for a few years until he decided to turn this into a product. It turned out building a product is a lot more involved than building a kit, with considerations to the enclosure, the packaging, and the inevitable CNC mold fails. Assembly – and the success of his first Kickstarter – was also an issue. [Tod]’s friends ended up assembling most of the kits.
Despite these problems, [Tod] was still able to ship a few thousand units and is now working on another production run with SeeedStudio. It’s a remarkable story, with the Blink(1) used by Google, Disney, Microsoft, Facebook, and a whole bunch of other huge companies. The Blink(1) is also in the mainline Linux kernel, something you can’t say about a lot of Kickstarters out there.
You’ve seen amazing shots of water spouts and milk crowns. You’ve seen shots of bullets piercing glass ornaments, playing cards, and poor, defenseless pieces of fruit. Maybe you’ve even seen that holy grail of shots—a bullet piercing a water spout. But how is it done? How do photographers capture this two-headed mythical beast of high-speed photography? [Maurice] has cracked the code and shared it for all to see.
He uses a Camera Axe to trigger the camera, a device he came up with years ago that’s on its fifth version. His setup uses a 100mm macro lens, a key flash, and two fill flashes that sit behind a diffusing wall of whiteness. All three flashes are connected to a multi-flash board which feeds into Camera Axe. [Maurice] explains how he gets nice, tall water spouts by thickening it with xanthan gum. He adds Jet Dry to reduce the surface tension and some food coloring to keep things interesting.
[Maurice] also runs through his pellet shooting rig, which he made with some polyethylene tubing and an air compressor. He ended up shooting the pellets at 20psi, which sends them traveling at 75 feet per second. They move slowly enough that he can use his own stomach to stop them in the demonstration. Dialing in just the right settings to get the pellet to intersect the spout at the right time took some finagling, and that will hold true for anyone who attempts to recreate this setup. He gives a link to his code files in the video description to get you started. Video is after the break.
Brushless motors are ubiquitous in RC applications and robotics, but are usually driven with low-cost motor controllers that have to be controlled with RC-style PWM signals and don’t allow for much customization. While there are a couple of open-source brushless drivers already available, [neuromancer2701] created his own brushless motor controller on an Arduino shield.
[neuromancer2701]’s shield is a sensorless design, which means it uses the back-EMF of the motor for feedback rather than hall effect sensors mounted on the motor. It may seem strange to leave those sensors unused but this allows for less expensive sensorless motors to work with the system. It also uses discrete FETs instead of integrated driver ICs, similar to other designs we have covered. Although he is still working on the back-EMF sensing in his firmware, the shield successfully drives a motor in open-loop mode.
The motor controller is commanded over the Arduino’s serial interface, and will support a serial interface to ROS (Robot Operating System) in the future. This shield could be a good alternative to hobby RC controllers for robots that need a customizable open-source motor controller. The PCB design and source code are available on GitHub.
A few months ago Hackaday covered the xNT crowdfunding campaign which aimed at making an NTAG216 based NFC implant for different purposes. I actually backed it, found that standard NFC readers don’t perform well and therefore decided to try using a standard coil as an antenna for better reading performances.
Most NFC readers typically only have a small sweet spot where implant reading is possible. This is due to what we call coupling factor which depends on the reading distance and reader & NFC tag antenna geometries. Having a smaller antenna diameter increases the coupling factor and makes implant positioning easier.
In my detailed write-up you’ll find a good introduction to impedance matching, a process where a few passive components are added in series/parallel with an antenna to bring its complex impedance close to a RF signal transmitter’s. This usually requires expensive tools but allows optimal power transmission at a given frequency.
Two students at Cornell University have put together a rather curious sound tracking device called an Acoustic Impulse Marker.
[Adam Wrobel] and [Michael Grisanti] study electrical and computer science, and for their final microcontroller class they decided to build this device using the venerable ATmega 1284p.
The system uses a three-microphone array to accurately position sharp noises within 5 degrees of accuracy. The microcontroller detects the “acoustic delay” between the microphones which allows it to identify the location of the sound’s source vector. It does this using an 8-stage analog system which converts the sounds from each microphone into a binary signal, which identifies when each microphone heard the noise. The resultant 3 binary signals are then compared for their time delay, it selects the two closest microphones, and then does a simple angle calculation based on the magnitudes of each to determine the sounds position. Continue reading “Acoustic Impulse Marker Tracks Sounds With A Pencil”→
For the musically challenged, electric guitars often have several sets of electromagnetic pickups that detect vibrations in the strings at different points along the strings. Selecting different pickup combinations with a built-in switch changes the sound that the guitar makes. [Richard] wired the pickups in his Fender Stratocaster to the microcontroller and programmed it to switch the pickups according to various patterns. The effect is somewhat like a chorus pedal at times and it sounds very unique.
The volume and tone knobs on the guitar are used to select the programmed patterns to switch various pickups at varying speeds. This has the added bonus of keeping the stock look of the guitar in tact, unlike some other guitars we’ve seen before. The Anubis preamp, as it is called, is a very well polished project and the code and wiring schematic are available on the project site along with some audio samples.
