I have a sensor module constructed, and that’s about it. There are chunks of a power module and a prototype command module, but chunks don’t make a satellite and I’ve got to present in less than a month! Hardware development is slow, and finishing a physical ersat in the time remaining is now hopeless. So instead of giving up I’m fighting back with software. In the next month I’m going to concoct an amalgam of the hardware I’ve already got and pieces of software that I’ve been cooking for parallel projects over the past year. The end result will be a strange, fully interactive simulation of a live ersat network (which itself is an approximation of a real satellite network).

It’s all just now coming together, so I’ll end here for now with a picture that will hopefully convey the essence:

I’ve made my TI-84+ bluetooth-capable using an RN-42 module and an Attiny85. It now shows up as an bluetooth SPP to any nearby bluetooth-capable devices, but looks completely normal (at least on the outside). The system allows the calculator to be communicated with over bluetooth as if there was a normal direct wired connection to it. The calculator just sees data coming in as if it were being sent from another calculator or a PC. It still allows the calculator’s link port to be used normally.

I plan on using my calculator’s new wireless linking ability to give it super-powers. So far I’ve only used it in a simple chat program, but eventually it will give my calculator the ability to explore complicated 3D graphs and have integrated WolframAlpha access, among many other useful things. It’s great advantage lies in its ability to turn my calculator, which by now is almost an extension of my own body, into an interface to any other bluetooth-capable device I want to use it with.

The Hardware

The Attiny85 that serves as the brain of the project has been put into a rather odd configuration. I bent half of its pins across its bottom so that it could be soldered to a 2×4 male header. Doing this makes it into a plug that can be disconnected for programming and then easily plugged back into the female header inside the calculator. Through that header the Attiny85 is connected to the ring and tip lines heading to the TI link port on my calculator, to the reset and serial lines of the bluetooth module, to 3.3v and to ground.

Power is a trick in this design, for two reasons. The first is that the Attiny85 is a 5v device, but I’m connecting it to a 3.3v bluetooth module directly. That’s workable because I’m running the Attiny85 at 3.3v instead of 5v. Reducing the voltage like this does not seem to cause problems, even though it is at the edge of the spec for the chip.

The second problem is that the power supply never shuts off. The calculator is always ‘running’, but it goes to sleep when the user presses the off button. Right now I don’t have any method to deal with that implemented, so my added hardware will suck the calculator dry of power much faster than the time it would have taken the calculator to run dry on its own. However, there is a relatively easy solution. The Attiny85 just needs to figure out when the calc is asleep and then go into a sleep mode itself. This should reduce power consumption very substantially, but I haven’t yet figured out a good way for the microcontroller to know when the calculator is asleep.

Implementing the TI Link Protocol

I’ve made many attempts at reverse-engineering the TI Link protocol over the past few years, and none have been totally successful until now. Communication was so bothersome with the built-in protocol when I made those other attempts that I went as far as to implement UART to use instead (see this project for that code).

However, as I’ve been encountering a lot lately, things I’ve failed at before are now easily accomplished because of all the knowledge I’ve gained in the interim. I can’t pin down exactly what I didn’t understand before about the TILP, but this time I had no trouble implementing it. The Attiny85 can talk easily with the calculator’s operating system directly, without needing software modification on the calculator.

Creating a Transparent Link

Once I had the Attiny85 talking to the calculator and talking to the bluetooth module separately, I tried to combine them so that the Attiny85 would be the invisible translator in-between the two. It turned out to be fairly easy to pull off, although it required one bothersome trade-off.

With nothing happening the Attiny85 is actively listening for communication from the calculator. If it receives data from the calculator it passes it straight onto the bluetooth module at 115200 baud serial (implemented in software since the Attiny85 does not have UART hardware). I set up an interrupt for incoming serial communications from the bluetooth module. UART is a timing-critical protocol so I couldn’t really get around this. The interrupt writes whatever the incoming data is to a FIFO buffer as quickly as possible for later processing. As long as the Attiny85 sees nothing from the calculator it empties the FIFO buffer over to the calculator.

This allows two-way asynchronous communication to occur. It works fairly well because the TI link protocol is not a timing-critical protocol (to an extent), so it isn’t usually bothered when the UART interrupt slows down receiving or transmitting. However, I have noticed that it fails if delayed more than a certain amount. This is a problem if a long continuous message comes in over bluetooth. It causes only the first part of the message to get through.

The only way I see to resolve this problem is by creating packets with a length field for the incoming data so that the microcontroller knows when there is a contiguous transmission and how long it will be, so it won’t start talking to the calculator until all of the data is received. This should prevent communications with the calculator from being interrupted as badly.

Next Steps

I’ve got to make the communications more reliable and fix the power issue. Then I can move onto developing software that makes good use of the wireless connection. The principal device that I will be using my bluetooth calculator with is my tablet computer (running Android). I carry it with me everywhere. including school, so it would be the best device to use to wirelessly extend the capabilities of my calculator. I’m most interested in getting my tablet to perform intensive 3D graphing and to allow my calculator access to WolframAlpha. It should turn in a very useful tool for college.

Here is a backup file containing what I’ve currently got on my TI-84+. It’s nowhere near everything I’ve ever done (I’ll post the rest when/if I find them), but it’s a large chunk of what I’ve done on it this year and last year.

Download calculator backup

I’ve been working very hard on my ersat project this past week. In particular I am trying to finish the sensor module for Ersat 1 (the first working prototype for my demonstration). It has an entire suite of sensors, but the central one is a Gameboy Camera. I want the module to be able to take low-res pictures to send over the ersat network, mostly to give it the feel of a Cold-War era spy satellite, and after some research I decided that the odd Gameboy Camera peripheral would work perfectly. It is cheap and easy to buy online, and it has a fairly simple interface. As an awesome bonus, the very odd “Artificial Retina” sensor chip used in the Gameboy Camera can do some simple image processing on its own, reducing the computational load for the guts of Ersat 1.

I thought that getting pictures of of it would be a snap and take at most a few days. As usual, that was an optimistic guess. It has taken a little over a week of days working maybe 1-2 hours each to get it up and running. I took 2 other stabs at it during that time before settling on what I have now.

Surprisingly, the challenging aspect wasn’t software or hardware. The solution I came up with is simple on both counts. The challenge was overcoming laziness. There is a straightforward datasheet freely available for the artificial retina chip in the Gameboy Camera, but I didn’t want to delve into that if I didn’t have to, so at first I scoured the web for projects that other people have  already done with it. That search turned up a lot of results, so I thought I was set. Unfortunately it led to a crazy looping path of madness as I tried to get code written by other people to work with my hardware (and a really pitiful spiral of depression as I fought to not spend time completely reformatting/rewriting some horrifically ugly code that one of them wrote).

I attempted to make sense of two projects done by other people before I gave up and made my own solution from scratch using just the information in the datasheet. It has taken 3 days and been a straightforward process. I wish I had started from scratch to begin with. For newbies (like me) out there who want to take some of the pain out of this kind of thing, here’s an outline of the process to get something like this up and running:

1. Read the datasheet. It’s some of the most boring reading material in the world (just a bit more exciting than EULAs I think), but reading it will give you a sense of what needs to be made and forewarning of gotchas that might lead to days of frustration if missed. Skimming works well for me. I make a list of the basic requirements that must be fulfilled to talk to whatever device it is while I read.
2. Implement the communication and test it! Sometimes writing custom code is not required here and a library will suffice, but if that’s the case make sure to test it before continuing. I used my logic analyzer to verify without doubt that the signals were being shuffled around correctly, but often requesting a specific response from the target works just as well.
3. Incrementally build up the functionality. Don’t shoot for the full prize right away. In the past I had a lot of trouble with this. I often spent a long time writing ambitious code and then found out that it was fundamentally wrong and had to be rewritten. Even if it takes a significant amount of time, come up with incremental goals to complete before attempting the big end one.

The Solution

I wrote some simple code in C for an Atmega328p to communicate with the Gameboy Camera. In my demonstration application (the source code can be downloaded below) it uses this code to ask the Gameboy Camera for a picture when prompted over serial by a Java (Processing environment) application running on a PC. The cam then takes a picture and sends it pixel by pixel to the Atmega328p, which in turn sends the pixels over serial to the Java application to be drawn. Within the Java application a mouse click will take a picture, the o, v, and g keys switch modes, and the x position of the mouse sets a camera value denoted by the mode (offset, vref, and gain). The serial communication is very slow, so even though the picture is only 128×128 pixels in 256 level grayscale it takes a few seconds for it to get scanned onto the computer.

Download source code:

I put this code out there to help others like me who want to use this cool device, and anyone else who is interested.

AVR GB Camera Interface

In particular it was the word “mutagen” that did it. A mutagen is simply any chemical that can change the genetics of a form of life. It creates mutations. The word immediately brought back strong memories of projects I have done relating to genetics from long ago to the present. The subject fascinates me and has inspired many of my favorite creations (ironically though, the greater subject of biology bores me to death). I started thinking along the same lines that led to those creations, but in the context of the things that I am creating now. The lines of thought quickly converged on the hazy outline of a new project.

Unfortunately it is little different than most of my other projects inspired by genetics, and unfortunately I have no time to work on a new project. But that’s no fun! It’s always that state of things. Where has my sense of ambition gone? I’m taking this new project and running with it. The time needed to nourish it will either manifest itself as ooze from between the activities currently stacked tightly in my days, or it will assert its life and exert force enough to make room.

So this marks the taking-hold of a new seed of obsession. The details of the project are irrelevant for now (although their future disclosure is a sure thing). My intention here is to capture some inkling of the form my creativity takes. The urge to write this came out of the joy that burst out of that inspiration I happened upon while reading. I do enjoy that book, but when I remembered my old ideas and started churning them anew it was like something colorful finally bloomed out of the dead and colorless weight of it.

This intensity is born of contrast. Lately my inspiration and ambition have been sapped by work done for the sake of others. My schoolwork does not challenge me, but it does not disagree with me either. I’ve just sat complacent in the comfy chair in my room every day for hours obediently evaluating calculus expressions and writing essays, and generally being a good student, but going through the motions for the sake of my teachers and parents and not myself. I argue with myself that it’s doing me good. It is doing me good. But I don’t feel that it is and I know why. Making my obsessions settle for the scraps of time left by these other activities, foisted on me, makes me feel like I’m running in place. This homework and schoolwork is definitely giving me new tools. But these are tools other people think I will need. These are tools other people think they need to give to me; force onto me.

I don’t like others helping me against my will. Everything I do that is worthwhile starts with me. I take an interest. I conceive my creations. I figure out how to accomplish them. I savor the meaning that goes along with them. I burn my own fuel, have my own motivation, and I don’t want a transplant from anyone else – however kindly it is offered. The only successes I have had that count have fed on only my own energy from happy birth to timely death.

The intensity with which I feel this, whether due to legitimacy or my youth, explains for me my current dissatisfaction with school. For you I hope it explains why, and how, I am able to create the things that I show here. It’s why I describe my projects as a reason for living and my true passion. With luck I will keep the ability to love them this strongly, but steps must be taken to protect it into the future. Especially now as I ready myself for the first big transition towards independence that I will experience in my life. So I’ll keep up a frenzy of building my machines and writing down my ideas – creating – and everything else can feed on the ooze from that.

The insight I’ve had involves making the computer ‘understand’ the notes, giving it the capability to make inferences about meaning that speed up the collection of information. To give a concrete example, my system would be able to recognize and properly respond to synonyms, so if Bob the butcher killed someone then a reference to “Bob” or “the butcher” would be understood to mean the same thing by the computer. This has been attempted by many people over the years, but I think I might be onto something with the way I’m planning on making it work. I think the trick is to take the fullest advantage of the human note-taker possible, and get them to do the tricky categorization on the fly. That way the problem turns into figuring out how to store the information and relationships within it, and having a user interface that is efficient.

I’m thinking about putting together some kind of prototype of this idea in the near future.

Tiny Miasmata is the first demo that I have created for my new demo platform, the Demomite.The platform is a handheld game device like the Gameboy, and as such it has game controls (an N.E.S. controller), a screen, and sound output. The hardware is very basic. I designed with the sole purpose of providing a very challenging plaform for writing software demos. The hardware itself is a demo, showing what I can do with some spare parts and a day of hard work (see a timelapse of that day here).

Purpose

This game I’ve made for the Demomite is designed to give a taste of the capabilities of the hardware (much greater than would appear at first), but more importantly to show the colleges I have applied to that I know my stuff. With that latter goal in mind some of my more restrictive design choices make sense, like limiting myself artificially to 1 bit sound and only the internal 128 bytes of RAM when the Attiny2313 brain of the Demomite is actually capable of much more with the help of a few outside parts.

The Game

Tiny Miasmata takes advantage of what is available within those strict limits. The game is a stripped down version of a PC game that I’ve been working on in Ruby, simply called Miasmata. It was very challenging to manage the basic aspects of the game within the limited hardware and the limited development time available to me, but also lots of fun.

It is a side-scroller. The player can walk around and jump in order to navigate the world, which is composed of 8×8 pixel tiles. Only one tool is available to the player to use to interact with the world: corruption. By hitting the B button the space in front of the player is blasted with random data, giving uncertain results. Sometimes it will change the world in a way that the player wants (cutting through the tree in the picture above), and sometimes it will cause problems. Because of that it makes for an interesting game mechanic, forcing the player to be conservative with its use. The only goal to the game is finding The Enemy wherever he is out in the world and killing him by through corruption.

A lot of work went into making this demonstration of my software skills. Several challenging problems had to be overcome in order to get it working, and it had to be done very quickly. Demomite was built in a Sunday and Tiny Miasmata was finished by the end of the following week. This description covers the most significant challenges I encountered during this project, but I encourage you to take a look at the code yourself to see its full complexity (link at the bottom of this post).

Sound

The black and white graphics are very basic, but a little bit of sound adds some richness and color to the world. I managed both music and sound effects by taking advantage of two very useful features of the Attiny2313 MCU: hardware pulse-width modulation (PWM) and timer interrupts. The PWM allows me to output nearly any audible frequency continuously without wasting any CPU time. That means that I can play a tone while doing other stuff in the game, but a solid tone would get annoying very fast and is not very interesting, so I used the other feature, timer interrupts, to add some variation. An interrupt allows an external event, in this case a timer, to pause execution of the current code to execute it’s own code associated with it and then resume execution of the original code. The interrupt code I wrote for Tiny Miasmata simply updates the tone playing via PWM from a series of values stored in memory that constitute a “song” (quotes because I am not a musician, so it sounds fairly horrible). This all means that I can easily play some music in the background without worrying about dividing CPU time between the game and the music.

Music: song

However, the sound effects are handled in a slightly different way because of their nature. The two sound effects I have included are one for when the player attacks, and one for when the player dies. In both cases I found the best strategy was to modify the PWM by both the timer interrupt and the CPU at the same time, because for both I was going for a random sound that would give the sense of corruption, the theme of the game (and it was easiest and took up the least space).

Effect #1: corruption

Effect #2: death

World

In terms of complexity, the system that handles the map for Tiny Miasmata is the most impressive part of the project. A key aspect of the full game is a nearly limitless world. On the PC I accomplish that through procedural generation using a random seed, but that approach is much more difficult on the Demomite because of the limited resources. I tried a few approaches that would generate a map from the program data itself as the seed, but the results were never satisfactory and took up a very large space. I settled on a simpler strategy that actually proved to be much more flexible – simply loading a pregenerated map from memory. To tell the truth it was a bit of a disappointment to have to change course (I really love the concept of procedural generation), but it provided fun new challenges to surmount.

Storage problem

Compressing the map

Decompressed in RAM

Map editor

So this compression stuff is all well and good from the point of view of the game, but what about from the perspective of the guy who has to generate the maps (namely, me)?  I could not practically create a table of values by hand to express a map in a way that could be assembled into the binary and decompressed by my map routines, I needed a way to easily edit maps and compress them automatically. To accomplish that I wrote an ugly Ruby script (included with source-code) that takes an image as input and outputs a text file with the group table and a series of tables for each screenful. From there I can just include it into the project within my assembler and it ends up in the binary while being easily pointed to by the rest of my code. I also took advantage of the Ruby game library I’ve been using for the PC version of Miasmata, called Gosu, to give the option of displaying a scrollable preview of the compressed map (seen above).

Collision Detection

Strangely enough this is where I had the most challenging code to write. The techniques for collision detection I used at first broke later on and I had to take another shot at the problem. Those early attempts were based on the positions of the tiles, only checking to see if something was in a given tile location. The later collision detection code is not at all complicated, just a little subtraction to check for collisions between squares, but for some reason it took a lot of effort to produce. I think that it might just be due to my poor ability to imagine how the overlapping objects corresponded to the math. In the end the solution I came up with works reliably, but it’s fairly clutsy. If I had the time to fully rewrite it I would expand its capabilities to objects that can move faster than 1 pixel per frame and do pixel-perfect collision or collision with bodies that can rotate. That would greatly improve the feel of the game, because the physics could be more natural, but would be much more challenging to code.

The Enemy

I dug myself so deeply into the challenges associated with the game world and bringing the player to life within it that I neglected one of the most important part of any story, whether it is told by a game or not – the conflict. The player could move and jump and explore the world, but had nothing to do. I’ll admit that this part was almost an afterthought. When I reached the point of adding an enemy for the player to fight I was almost out of time to work. I basically copied the player’s code exactly and added a tiny bit of intelligence.

To simplify things there is only one enemy. He looks exactly like the player. If the enemy sees the player it will move towards the player and kill him or her on contact. Even though there is only one enemy, to the player it seems like there are many, although only one at a time. When the enemy dies he is recycled and spawned anew in another section of the world.

As a matter of necessity the player needs a way to fight the enemy. To that end I created the tool of corruption, which is the central theme of Miasmata. The world that the player inhabits is corrupted by the Miasma, but the player can do corrupting as well. In the PC version of the game this ability can be used to destroy as well as create, although which one is left up to chance. In that sense the power of corruption in Tiny Miasmata is much more blunt. The player can use corruption to randomly change the map nearby or kill the enemy. The changes are not saved and the enemy is never truly dead. Any use of corruption messes up the image on the screen and therefore makes it harder to tell what is going on.

Conclusion

This is the most difficult software project I have ever taken on (or at least that I have gotten to some semblance of a finished state). It was a really great challenge, fun and intense. I wish I could have put more of myself into it, but the usual anchors of responsibility to school and living held me back as usual. I’m going to keep exploring what I can do with this fun little platform of mine, there is a lot of potential hiding in its diminutive hardware.

Source code

Now mid-way through my senior year of high school, it has been a while since I finished applying to colleges. In fact, it’s almost time to start receiving their possibly life-altering decisions. However, before that happens there is one last hurdle to cross: the mid-year report, a list of my current grades and midterm exam results sent to the academic institutions I’ve applied to so that they can be assured that I really am the high-achieving student that I tried to present myself as in my application. Besides the obvious gift of stress, this report also presents an opportunity. Some schools allow “additional materials” to be submitted along with the report. This project is my additional material, designed to demonstrate the extent of my abilities – and more importantly, show that I am serious about taking advantage of my potential when I get to college.

A Tiny (2313) Demo (Dyna)Mite

I had planned to do a project to send with my mid-year report, but I didn’t know what form it would take. Last weekend I finally had the first chance to take a shot at actually creating something for it, because that weekend marked the end of midterms at my school, and with them the end of intense studying and stress. Unfortunately that Friday and Saturday my inspiration failed me. I piddled around with various experiments I’ve been working on hoping that one would spark a brilliant idea for a project, but none managed any success towards that goal. As a result, late Saturday night I was pretty fed-up with myself and frankly a little depressed.  ”How dare my brain choose this time to quit creating”, I was thinking to myself. Fortunately my frustration led me to muse about attempting ideas I had previously thrown out for perceived lack of genius/complexity, and Demomite was born.

 Ignore the snazzy portmanteau (it’s really quite simple)

The idea for this project was incepted by my previous TinyAsmCopter project. Demomite is a tiny handheld game device designed to provide a platform for software demos. In the computing world a demo is a demonstration of programming/artistic/musical ability. It’s specs are severely limited on purpose to make programming for it more challenging:

Computing power:

• attiny2313 microcontroller
• 8 MHz CPU w/ ~8 MIPS
• 2 kilobytes of program memory
• 128 bytes of RAM
• 128 bytes of EEPROM

Graphics:

Controls:

According to popular opinion a hacker is an evil person. It seems like there is a new story every day about a hacker breaking through some corporation’s security and stealing the private information of millions of people. With every new crime there is a wave of fresh hate towards hackers and their ilk. With all of the invective directed towards hackers one would think that they represent the super-villains of this millennium.
 
And yet ‘hacker’ is my favorite word for describing who I am. It is a good guess that I am not an evil information thief. So why do I choose ‘hacker’ if I am asked to pick one word to use to describe myself? I choose it because everything that it represents, except for law-breaking, also represents me perfectly. The spirit of hacking is beautiful, and something that has survived its new popular association with the most modern of crimes. That spirit is what I believe describes why I do what I do most accurately.
 
Hacking is about freeing things from their original purposes. A hacker works with what he has. A hacker’s raw material is not the substance of what is before him, it’s the invisible connections within it. With careful study the connections can be dissected and repurposed. That spirit of careful discovery and artfully applied skill is what is so beautiful about hacking, and what I most strongly identify with.
 
I do not endeavor to break into the databases of corporations or the private files on people’s computers, but I am still passionately a hacker at heart. I strive to gaze deeply into the connections between the materials I have to work with, and by doing so get the material to exert the force that I want to apply, rather than applying the force wastefully myself. By using the system to my advantage I make the most of my efforts, and extend my creative reach further as a result. My ability to create is not as special as the hacker spirit that guides my application of it.

I wanted to make myself a watch a few months ago, so I rifled through all the parts I had on hand and picked out my favorites. Then I spent a day enjoying the painstaking process of making this mess.

It’s an infrared temperature sensor (left side above middle), infrared TV remote receiver (on top left), infrared LED (legged thing on right), and surface-mount Atmega168 attached to a Nokia 3310 B&W graphical LCD. I also had an EEPROM chip and accelerometer picked out for it, as well as a lithium ion battery to power it all, but I never got far enough in the project to add them in. The wire hoops on the lower left were designed as a minimalistic programming interface.

As its biggest plus, it shows how finely I can solder. The magnet wire (just normal solid wire with thin coating) was soldered to the surface-mount Atmega168 by hand with no magnification. Maybe I am a decent surgeon in another life…

The wiring was only completed to the programming interface and the LCD. Once I was able to power it up and get code into it I saw that the LCD connection was flaky. It required pressure in a very particular spot and in a very particular direction for anything to show up on the screen. I tried using glue to secure it and fix that problem, but it only made everything worse. Eventually my frustration with the LCD killed the project.

It was an interesting attempt, but I think it was doomed from the start because I focused purely on the fun of it and held nothing back to spend on making a solid structure. I jumped right into building it without any kind of design stage beforehand, just a few sketches to get a sense of what pins were where. Many of my best projects have progressed like that (notably Tiny Miasmata), but it requires a very fine balance to pull of correctly. Fluidity is hugely useful in creative pursuits, because it links the mind more closely to the work, but it’s also dangerous in the engineering world. Complex systems are often not forgiving. But this is what I like to do.