I've been a little bit busy lately for the past week. I've had to move down to Cincinnati for my current Co-Op and it took much longer to prepare, move, and get settled in than I though it would. I've been a little bit delayed on making this post, but better late than never.

Early in my summer vacation I went down to D.C. on a small trip. While visiting the Smithsonian Institute and picked up one of those crystal growing kits. I remember playing with one when I was much younger (around ten or so) and thought it would be fun to grow another one. They didn't have the blue color anymore, so I opted to get a pack labeled “Emerald.” I thought it would be extra fun to do a timelapse of the crystal growing.

It took a few days to write a decent application to do this. My tools were C++, OpenCV, ffmpeg, and a very low resolution webcam. The app comes in two parts:

1. Capture softare
2. A script to compile images

Once everything was setup, I set the software to run for just five days, taking one picture per minute. The package said that it would only take that long for the crystal to grow, but that was a lie. I had to run the setup for two weeks and half a day. This resulted in 21,000+ images (totaling 1.5 GB of disk space).

I wanted to run the film at 30 fps, but 21,000+ images would result in something around fifteen minutes long, so I only used every fifth image for the final movie. You can it below:

I'm sorry that I don't have any other photographs of the crystal, or the “Magical Crystal Fun-Box,” that I grew it in. You'll just have to use your imagination for that last one. Source code for the application can be found here on my github.

During my spring break (sometime in March), I decided to revisit my old CHIP-8 emulator that I made in the beginning of the school year.

I consider both to be separate projects. There are quite a few differences between the new one and the older one.

 

Done in C++ instead of C

C is a lot of fun and this could have been done without the help of classes, but I felt using an object orient approach to this made a bit more sense and made components of the CHIP-8 machine a bit more reusable.

 

Uses the newer SDL2 library

This is not too much of an advancement, except that the emulator is a bit more future proof. I've been looking for an excuse to learn the differences between the newer and older SDL libraries and I think this gave a pretty good foundation. So far I really like the changes that have been made to the API.

 

Much better modularized and cleaned up

The older emulator was essentially a one source file behemoth. In this one, I looked at the CHIP-8 machine as a hole and split it up into smaller parts that would be interconnected. For instance, there are separate Display, CPU, Stack, Memory and Buzzer objects. One of the original ideas was to have a version that ran on SDL2 and another on Qt (but I decided not to do a Qt version), so I tried to make sure that most of these objects were not dependent upon a specific platform. Certain components, like the Buzzer, are. Most of the platform specific code is supposed to be put into the main program loop or separate source files

 

There are also variations of CHIP-8 out there and these objects are able to accommodate “non-standard,” CHIP-8 systems in case you wanted an emulator for their ROMs. It also wouldn't be as hard to add in Super CHIP-8 support, but I'm not doing that for a while.

 

Better interpretation of CHIP-8 and more ROMS working

While I don't have all of the ROMs complete working order I have much more than I did with the last emulator. I grabbed a copy Frédéric Devernay's SVision-8 emulator and used it as a reference since I don't have a real piece of CHIP-8 hardware with me. With the last emulator I just read the CHIP-8 manuals and online resources on how the op-codes are interpreted. For a few of them, there is some non-consensus for what they do. This of course was quite frustrating. I would say now though that I have a good 80-90% of ROMS working perfectly versus the older one that was more around 60-70%.

 

More features

Nothing too significant other than the addition of saves states. They seem a little complex at first, but they were actually quite easy to implement. Essentially it's either dump/load all of the registers, stack, and memory into/from a file. My emulator supports one thousand save states (though you could change the number if you wanted), but I doubt anyone will use that many for a measly CHIP-8 program.

I also added in step-by-step execution. This was mainly done for my purposes of debugging, but the code is still in there in case someone wants to run through a ROM step-by-step. They would need to edit a boolean value in the source to turn it on.

 

Final Thoughts

With all that, I'm fairly happy with how it turned out. The only things that frustate me are the ROMs that still don't work. I haven't touched most of the source code since, just the README file to document it a bit better. If you want to checkout the source, the repo is right here.

While I'm at home for a month, I figured I was going to be pretty bored unless I find something to do.   So I decided to start a new project that I hope to get done before I get back from break.  So I would like to announce:

I am going to take a coffee machine, modify it, and then link it up with the Internet so I can order coffee remotely.  Whether or not I actually end up using this in the future is a question left to time, but for now I think it will be pretty something fun to do.  Below is my work area.

Currently there are three main components of this project that I'm looking at:

1. Augmenting the coffee machineAdding a servo motor to control the flow of coffee
   • Adding water level sensors
   • Hacking in extra controls to the existing electronics
   • Some method to detect there is a cup underneath the coffee nozzle
2. Developing “barista software,” to manage all of the above, as well as process orders
3. Drafting the “Buzz Protocol,” an XML interface for ordering coffee

For modifying the machine, the most difficult parts will be figuring out how to control the built in circuitry and figuring out if there is an empty cup below the dispenser.  I'm thinking that I might be able to do that with via acoustic distance sensing.  I bought one of those ultrasonic ping sensors/transmitters over the summer, but never did anything with it.  I've also never worked with servos before, so that might be another spot of difficulty.

The barista software shouldn't bee too much of a challenge.  I plan on making a Django application that will be the web interface for the system.  I was originally going to write this software targeting an Arduino with an Ethernet shield, but using a BeagleBoard is much cheaper and gives me some extra power/functionality that an Atmel chip wouldn't.

The last thing might be a bit more of a postmortem component, and I'm not entirely sure if the barista software will implement the protocol.  In case though I ever want to network another machine, having a common interface for controlling machines would be useful, and I could move the barista software over to the client.  The original idea of this project was to draft the protocol, create a client program to send XML payloads, and have the barista software interpret those messages.  Though thinking it over a bit I'm not sure if that is best for the small project that this is.  I still want to have the protocol ready on the side if I ever get any other machines up and running.

 

 

Cheers!I hope this project goes well, and I'll be sure to document it as I go along.  I am going to post everything related in the github repo.

I meant to post this about a month ago, but I've been quite busy.  Anyways...

I mentioned in the last post that I was working on a Chip-8 Emulator.  While it was a quite interesting project and I learned a lot from it, I decided to discontinue the project a month ago.  My reasons were that I hadn't spend time on it in a bit (it was supposed to be a short 2-3 week project), but school work caught up with me and interrupted any progress.  I did a fair amount of reasearch on the Chip-8 architecture and got some (but not all ROMs to work).

For the project, I wrote a small python utility to print out the data of a ROM (insanely useful for implementing op-codes).  The brunt of the code was made with C and SDL.  It started out using the 1.2 version of SDL, then SDL2 came out right after development began.  In the late stages of the project, I thought it would be interesting to switch to the new API.  It went smoothly.  Sound/Audio (which is just a "beep," noise) isn't implemented.

But in retrospect, I got out of it what I wanted to learn; "How does an emulator work?"  It was a worthwhile experience for the time I put into it.  I'd love to acutally work on a different (more purposeful) type of emulator.  But for now, I've got some other stuff that I need to get done.

If anyone wants to see it, I posted it to my Github page under c8_sdl. It's released under the GNU GPL v3 license.

So I haven't posted anything in a while, but I'm finally done with my internship this Summer and I now am back at school!  It's only been a week so far, so nothing interesting has happened.  In the time that I didn't post though, I was able to get the first public version of my Arduino Serial "library," pushed onto github.  So if you want to take a look at it, it's right here.

As for a next one, I'm working on a Chip 8 Emulator.  I've been able to get some stuff for it done, but I haven't implemented all of the inputs/outputs for it yet.  The "CPU," is done, but not fully tested.  So far it can run a few demos.