A Computer In The Game Of Life

We often hear the term “Turing-complete” without giving much thought as to what the implications might be. Technically Microsoft PowerPoint, Portal 2, and Magic: the Gathering all are Turing-complete, what of it? Yet, each time someone embarks on an incredible quest of perseverance and creates a computer in one of these mediums, we stand back in awe.

[Nicolas Loizeau] is one such individual who has created a computer in Conway’s Game of Life. Unlike electricity, the Game of Life uses gliders as signals. Because two orthogonal gliders can cancel each other out or form a glider eater if they intersect with a good phase shift, the basic logic gates can be formed from these interactions. This means the space between gates is crucial as signals need to be in phase alignment. The basic building blocks are a period-60 gun, a 90-degree glider reflector, a glider duplicator, and a glider eater.

All the Python code that generates these structures is on GitHub as the sheer size of the machine couldn’t possibly be placed by hand. The Python includes scripts to assemble the basic programs as a bank of selectable glider generators. It’s all based on Golly, which is an excellent program for simulating Conway’s Game of Life, among other things. While this isn’t the first computer in the Game of Life as [Paul Rendell] published a design in 2000 and [Adam Goucher] published a Spartan universal computer constructor in 2009, we think this is a particularly beautiful one.

The actual architecture has an 8-bit data bus, a 64-byte memory with two read ports, a ROM with 21 bits per line, and a one-hot encoded ALU supporting 8 different operations. Instructions have a 4-bit opcode which is decoding in a few different instructions. The clock is four loops, formed by the glider reflectors as the glider beams rotate. This gives the computer four stages: execution, writing, increment PC, and write PC to memory.

The Game of Life is an excellent example of Cellular Automaton (CA). There are several other types of CA’s and the history behind them is fascinating. We’ve covered this field before and delved into this beautiful fringe of computer science. Check out the video below to truly get a sense of the scale of the machine that [Nicolas] has devised.

Continue reading “A Computer In The Game Of Life”

Reverse Engineering A PokeWalker

The PokeWalker is part of Nintendo’s long quest to get children (and likely some adults) walking and exercising. There’s the PokeWalker, Pokemon Pikachu, PokeBall Plus, Pokemon Pikachu 2, Pokemon mini, and of course Pokemon Go. Despite being out a decade, there wasn’t a ROM dump for the device and there was minimal documentation on the communication protocol. [Dmitry Grinberg] took it upon himself to change all that and crack the PokeWalker open.

At its heart, the PokeWalker is just a pedometer with an IR port and a 96×64 grayscale screen. It came out in 2009 to accompany the new Pokemon release for the Nintendo DS. Cracking open the device revealed a 64KB EEPROM, a Renesas H8/38606R CPU, a Bosch BMA150 accelerometer, and a generic IR transceiver. The CPU is particularly interesting as in addition to being quite rare, it has a mix of 8, 16, and 32 bits with 24-bit pointers. This gives it a 64K address space. While the CPU is programmable, any attempt to do so erases the onboard flash. The communication protocol packets have an 8-bit header that precedes each packet. The header has a checksum, a command byte, and four bytes of session id, and an unused byte. Curiously enough, every byte is XOR’d with 0xAA before being broadcast.

One command is an EEPROM write, which uses back-referencing compression. Each chunk of data to be written is packaged into 128-byte chunks, though 128 bytes likely won’t be sent thanks to the compression. The command can theoretically reference 4k bytes back, but in practice, it can only reference 256 bytes back. It was this command that laid the foundation for the exploit. By carefully crafting the command to send, the command can overflow the decompression buffer and into executable code. Only a few bytes can be overflowed so the payload needs to be carefully crafted. This allowed for an exploit that reads the system ROM and broadcasts it out the IR port. Only 22k bytes can be dumped before the watchdog reboots the device. By changing the starting address, it was easy to do multiple passes.

After the ROM was stitched together from the different passes, the different IR commands were analyzed. In particular, a command was found that allows direct writes into RAM. This makes for a much easier exploit as you can write your exploit, then override a pointer in the event table, then have the exploit revert the event table once the system naturally jumps to your exploit.

[Dmitry] finishes off this amazing exploit by writing a PalmOS app to dump the ROM from a PokeWalker as well as modify the system state. PalmOS was chosen as it is an easy and cheap way to have a programmable IR transciever. All in all, a gorgeous hack with a meticulous writeup. This isn’t the first video game accessory that’s been reverse engineered with a scrupulous writeup, and we’re sure it won’t be the last.

Continue reading “Reverse Engineering A PokeWalker”

Procedurally Generated Trees

As the leaves fall from the trees here in the Northern Hemisphere, we are greeted with a clear view of the branches and limbs that make up the skeleton of the tree. [Nicolas McDonald] made a simple observation while looking at trees, that the sum of the cross-sectional area is conserved when a branch splits. This observation was also made by Leonardo Da Vinci (according to Pamela Taylor’s Da Vinci’s Notebooks). Inspired by the observation, [Nicolas] decided to model a tree growing for his own curiosity.

The simulation tries to approximate how trees spread nutrients. The nutrients travel from the roots to the limbs, splitting proportionally to the area. [Nicolas’] model only allows for binary splits but some plants split three ways rather than just two ways. The decision on where to split is somewhat arbitrary as [Nicolas] hasn’t found any sort of rule or method that nature uses. It ended up just being a hardcoded value that’s multiplied by an exponential decay based on the depth of the branch. The direction of the split is determined by the density of the leaves, the size of the branch, and the direction of the parent branch. To top it off, a particle cloud was attached at the end of each branch past a certain depth.

By tweaking different parameters, the model can generate different species like evergreens and bonsai-like trees. The code is hosted on GitHub and we’re impressed by how small the actual tree model code is (about 250 lines of C++). The power of making an observation and incorporating it into a project is clear here and the results are just beautiful. If you’re looking for a bit more procedurally generation in your life, check out this medieval city generator.

E-Ink Calendar Paves A Path For All

[Martin Fasani] has set out to build a beautiful low power E-Ink Calendar he can hang on his wall. But perhaps more importantly, the work he has done makes it easier for everyone in the future to have a e-ink display. Many battery-powered e-ink projects connect to some server, download a bitmap image, display the new image, and then go into a deep sleep power mode. [Martin’s] project is no different, but it uses a handy microservice that does the conversion and rendering for you.

The firmware for this ESP32/ESP32S2 based calendar is open sourced on GitHub, with a version based on the Arduino framework as well as the native ESP-IDF framework. One particularly fantastic part of the firmware is a C++ component called CalEPD that drives e-paper displays. CalEPD extends the Adafruit_GFX class and is broken out in a separate repo, making it easy to consume on other projects. Since this supports dozens of different e-paper displays, this simplifies the process of building a calendar with different screens. The firmware includes a Bluetooth setup flow from a smartphone or tablet. This means you can quickly configure how often it wakes up, what it queries, and other important features.

The hardware shown in the demo video has a 7.5″ Waveshare screen with 800 x 400 resolution nestled inside a 3D-printed shell. There is also a 5,000 mAh battery with an ESP32 TinyPICO powering the whole system. The TinyPICO was picked for its incredible deep sleep power consumption. All this fits into a frame just 11 mm thick, for which STL files are available. [Martin] continues to work on this calendar display and has recently added support for FocalTech touch panel controllers. We’re excited to see where he takes it next!

This isn’t the first e-ink display project we’ve seen but this is a great reference to build your own. If you need another good starting point, this weather display might give you that little bit of inspiration you need.

Continue reading “E-Ink Calendar Paves A Path For All”

Meticulous Bionic Hand

[Will Cogley] is slowly but surely crafting a beautiful bionic hand. (Video, embedded below.) The sheer amount of engineering and thought that went into the design is incredible. Those who take their hands for granted often don’t consider the different ways that their digits can move. There is lateral movement, rotation, flexion, and extension. Generally, [Will] tries to design mechanisms with parts that can be 3D printed or sourced easily. This constrains the hand to things like servos, cable actuation, or direct drive.

However, the thumb has a particularly tricky range of motion. So for the thumb [Will] designed to use a worm geared approach to produce the flexing and extension motion of the thumb. These gears need to be machined in order to stand up to the load. A small side 3d printed gear that connects to the main worm gear is connected to a potentiometer to form the feedback loop. Since it isn’t bearing any load, it can be 3d printed. While there are hundreds of little tiny problems still left to fix, the big problems left are wire management, finalizing the IP (Interphalangeal) joints, and attaching the whole assembly to the forearm.

All the step files, significants amounts of research, and definitions are all on [Will’s] GitHub. If you’re looking into creating any sort of hand prosthetic, the research and attention [Will] has put into this is work incorporating into your project. We’ve seen bionic hands before as well as aluminum finger replacements, but this is a whole hand with fantastic range and fidelity.

Continue reading “Meticulous Bionic Hand”

Hello From The NearSpace

A key challenge for any system headed up into the upper-atmosphere region sometimes called near space is communicating back down to the ground. The sensors and cameras onboard many high altitude balloons and satellites aren’t useful if the data they collect can’t be retrieved. Often times, custom antennas or beacons are added to help. Looking at the cost and difficulty of the problem, [arko] and [upaut] teamed up to try and make a turn-key solution for any near-space enthusiast by building CUBEX, a wonderful little module with sensors and clever radio that can be easily reused and repurposed.

CUBEX is meant as a payload for a high-altitude balloon with a camera, GPS, small battery, solar cell, and the accompanying power management circuits. The clever bit comes in the radio back down. By using the 434.460 Mhz band, it can broadcast around a hundred miles at 10mW. The only hardware to receive is a radio listener (a cheap RTL USB stick works nicely). Pictures and GPS coordinates stream down at 300 baud.

Their launch was quite successful and while they didn’t catch a solar eclipse, their balloon reached an impressive 33698m (110,560ft) while taking pictures. Even though it did eventually splashdown in the Pacific Ocean, they were able to enjoy a plethora of gorgeous photos thanks to their easy and cost-effective data link.

Continue reading “Hello From The NearSpace”

Robots Can Finally Answer, Are You Talking To Me?

Voice Assistants, love them, or hate them, are becoming more and more commonplace. One problem for voice assistants is the situation of multiple devices listening in the same place. When a command is given, which device should answer? Researchers at CMU’s Future Interfaces Group [Karan Ahuja], [Andy Kong], [Mayank Goel], and [Chris Harrison] have an answer; smart assistants should try to infer if the user is facing the device they want to talk to. They call it direction-of-voice or DoV.

Currently, smart assistants use a simple race to see who heard it first. The reasoning is that the device you are closest to will likely hear it first. However, in situations with echos or when you’re equidistant from multiple devices, the outcome can seem arbitrary to a user.

The implementation of DoV uses an Extra-Trees Classifier from the python sklearn toolkit. Several other machine learning algorithms were considered, but ultimately efficiency won out and Extra-Trees was selected. Another interesting facet of the research was determining what facing really means. The team had humans ‘listeners’ stand in for smart assistants.  A ‘talker’ would speak the key phrase while the ‘listener’ determined if the talker was facing them or not. Based on their definition of facing, the system can determine if someone is facing the device with 90% accuracy that rises to 93% with per-room calibration.

Their algorithm as well as the data they collected has been open-sourced on GitHub. Perhaps when you’re building your own voice assistant, you can incorporate DoV to improve wake-word accuracy.

Continue reading “Robots Can Finally Answer, Are You Talking To Me?”