Older blog entries for gwossum (starting at number 4)

Project AKO
Added support for the immediate success extension (ISE) of the AKONET into the send side of the AKOI2C and the receive side of the components.  This makes the data link of the AKONET a whole lot better.  Plus, it's implemented in a way that's fully backwards compatible with non-ISE components.  I need to add it going the other way (components to AKOI2C) now, but that requires a large bit of modifications to the AKOI2C code. 

I got an idea today that the AKOI2C should be implemented as a component.  This is a really cool idea.  The CIF would need some modifications to it to make it more flexible, though.  The way the CIF handles the receive buffer works great for components, but it probably needs to be handled differently for the AKOI2C, since it is connected to the main contoller.

I also think it would be nice for a AKOI2C command to send a packet on an AKONET.  It's not really necessary, but it would vastly simplify the device driver.  I don't want to drop raw I2C functionallity from the chip or device driver, though.  I see a /dev/ako in the future ^_^

cccl
A while back, I wrote a wrapper around MSVC's cl.exe and link.exe, to make them accept more Unixish command lines.  I created it for a cross-platform commercial application that was using autoconf/automake/libtool for the build process.  The problem was that libtool always wanted to give the Windows compiler Unix command line options.  I couldn't find a pre-existing wrapper utility (at least not on fm, sf, or google), and so cccl.  I finally released it to the public under the GPL a couple of weeks ago.  It's at http://cccl.sourceforge.net.  It's a stupid program, but it proved incredibly useful for me.

Project AKO
In the past couple of days, I've made some fixes to the AKOI2C firmware and device drivers, and Chris made a mod to the PC-AKO reset circuitry.  Thanks to these changes, the AKOI2C is now working exceptionally well.  I was banging on it as hard as I could for over 36 hours without even a hiccup.  I also fixed a bug in the component's I2C stack, so they actually send their initializations properly all the time now.  With the low level stuff seeming to work nicely now, I can move onto the higher level AKOLIB and AKOAPI.

On a non-technical side, I got most of the Project AKO stuff checked into CVS on Sourceforge.  There's still a couple of schmatics and board layouts missing, but all the firmware is there.  I also just finished rolling a release of it.  And I also created two mailing lists on Sourceforge for Project AKO development.  One is for general Project AKO development, and the other is specifically for the AKOI2C.

Internet Imperialists
Internet Imperialists was a web-based game I started way back in March of 1997.  I modelled it after Amit Patel's Solar Realms Elite (SRE) BBS door game.  I really enjoyed playing SRE back when I was in junior high and high school.  There's now two code bases of it, an older one in C using flat files for storage, and a newer in Perl using PostgreSQL for storage.  Unfortantely, I haven't actively developed it in about a year, due to a lack of time.  This is a shame, because it was mostly complete, and it was a fun little game.

I had hoped that at someone would take over the development from me, but that never happened.  I've gotten emails inquring about its status, but never from anyone who could take over developing.  I eventually threw it into the attic of my brain.  Then, last week, I got an email from someone who said he might actually be interested in developing it, but I haven't heard back from him.  But his email did server to pull Internet Imperialists down from the attic.  I figured, hey, maybe someone here would be interested in taking over development.  The webpage is at http://inetimperial.sourceforge.net.   If you'd be interested in doing some development, or have any questions, you can contact me at gwossum at acm dot org.

I just fixed the reset problem the AKOI2C has had ever since its beginning. It turned out to be an uninitialized state variable. On a POR, the register file gets cleared with 0's. But on an MCLR reset, the user registers in the register file are untouched. The uninitailized variable caused the AKOI2C to sometimes reset into an indeterminant state, which would cause the chip to lock up and quit responding. I'm annoyed it took me this long to find it.

AKOI2C
Got the AKOI2C firmware, device drivers, schematics, and board layout into CVS over at SourceForge. Also released an AKOI2C tarball with the stuff in it. Go to http://ako.sourceforge.net/akoi2c.html to see it.

Nathan Brown's R'n'B
Played a strange show out in Denton last night (I play violin in a band called "Nathan Brown's R'n'B"). We showed up at Rubber Gloves in Denton, and they told us we were going on second. So we left to go get something to eat. We got back about 10:10 or so and the first band was setting up on stage. At about 10:35, they tell us we're going on first, and the other band has taken their stuff off the stage. So we tried to setup really fast, but it still took us untio 10:50 to get ready. The sound guy comes out and tells us we can play until 11:05, which doesn't make any sense because the delay is their fault. We play three songs, and then they tell us we have time for a "quick" song. So we played the longest song in our set. ^_^ We only got to play half the set, which is a shame because it was sounding really good. It was the first performance I had used my new effects processor, and the violin sounded really nice.

Finally got a web page up for Project AKO over at SourceForge, with lot's of pictures. No source code yet, though. It's going to take another day or so to get that in order to put up there.