Apr
05
2010
0

The Challenge

Its hard to truly understand a problem until you’ve tried to solve it once or twice. Towards this end, I’m going to stop speculating why engineering software is trapped in a quagmire, roll up my sleeves and start hacking.
I’m going to attempt modernizing an open source aerospace software package called xFoil. I decided to work with existing code rather than starting from scratch for several reasons, the strongest being that the project needs work and is widely used. I’m also somewhat familar with it from using it for UAV simulation work in college.
For those who have never heard of xFoil – here’s a brief overview:
XFoil 1.0 was written by Mark Drela at MIT in 1986 as an interactive replacement for batch mode computational fluid dynamics programs that were popular at the time, while at the same time employing new algorithms he had developed. XFoil is a Fortran77 app that uses plotting libraries written for the X Window System, which means its intended for Unix systems – but the developers seem to have gotten around this and distribute windows binaries. A quick google search will show that just about every aerospace engineering school on the planet uses this program for coursework, which makes this an especially good candidate for modernization – especially when you take a look at the interface:
Interaction is done via four letter commands in a console window, and plotting in a second window.
(Image lifted from the homepage of the OS X distribution)

According to the documentation the last changes were made in 2008, and the project is frozen pending a next generation application. As this was two years ago at this point, I’m not holding my breath. So that being said, here’s the rough plan of attack:

Phase 0: Do some exploratory surgery on the code, make a spec, come up with rough estimates, generally standard prep work best practices.

Phase 1: Straight port to language ‘X.’ (Language to be determined, the goal here is just make it work). Test the shit out of it. Release early, release often – first usable code ships replicating what already exists.

Phase 2: Refactor core architecture and design into something much more maintainable. Start building a community around it, pull in domain specific experts to help steer the project and help validate output.

Phase 3: Experiment with interface and modern concepts (Cloud, mobile, touch, GPU acceleration)

This will probably be a much more difficult project than I currently estimate, but will be an awesome exercise in taming legacy code as well. Next time, updates on Phase 0 and preproduction work!

Written by mluebbe in: Projects,Software |
Feb
27
2009
1

Installing Apache Thrift on Ubuntu 8.04

In a recent post, I explained how to install the Thrift RPC framework on OS X 10.5. Another scenario that doesn’t install as advertised out of the box is building Thrift on Ubuntu server. Again, an issue with pkg.m4 is to blame – follow the steps below to get Thrift built on your Ubuntu system:

As in the previous guide start by getting the latest revision of the Thrift library, and extract the archive.

Install the necessary prerequisites, which is much easier than on OS X thanks to apt. Fire up a terminal, and use apt-get to pull everything. Substitute java5 with your favorite jdk, if you’re not a fan of the Sun implementation.

apt-get install libboost-dev libevent-dev build-essential
python-dev automake pkg-config libtool flex bison sun-java5-jdk

Now, for the pkg.m4 workaround!

cd [thrift root]
cp /usr/share/aclocal/pkg.m4 aclocal/

At this point, all that remains is to build Thrift. (If you want Ruby support, add ruby-dev to the apt-get list above, and get rid of the ruby flag below.)

./bootstrap.sh
./configure --with-ruby=no
make
sudo make install

Enjoy!

Aug
22
2008
1

Plans for an NES DevKit Using 2008 Technology

In a recent post I discussed the viability of developing new games for old platforms as a vehicle to liberate the gaming from the repetitive titles that currently plague the industry.

 

In order to get started on such a campaign, developers would need to be armed with the proper tools to do start writing a new generation of titles efficiently and at minimum cost.

1) Development Environment

The NES games would likely be programmed in 6502 assembly, and there should be no reason why a modern computer couldn’t be used to test the games via an emulator. For this task, I would propose developing a plugin for the popular Eclipse development environment which would include all the required tools in one convenient place.

 

Eclipse Logo 

 

The plugin would include tools to do syntax highlighting and checking of the assembly code, an Emulator tied to the compile/run command that would launch windowed inside of eclipse, and also most likely rudimentary sound and image editors for composing the media aspects of the game. Powerful modern software development tools already compatible with eclipse would be of great assistance here such as source control, static analysis and performance profiling. Another valuable feature found in some plugins would be code assist, to provide code snippets for common tasks such as probing the controller buttons. An Eclipse plugin with these features would be a godsend to any potential NES developer, especially because these tools would ideally be open source and free – providing for community improvements and widespread usage (Not to mention inherently cross platform, supporting Windows, Linux and OS X!). 

2) Development Cartridge

After testing in the development environment, a game would need to be tested on native hardware as well. For this task I propose the construction of a development cartridge that includes the basic functionality of a NES cartridge but uses cheap modern microcontrollers and flash ram in order to have reprogrammable ROM and Mapper components. The cartridge would feature a speedy USB link for dumping new software to the cartridge and also possibly for in-circuit debugging, both of course in conjunction with the Eclipse plugin. Having a cartridge like this would also be handy in transporting games in progress to demo for others, being playable in any Nintendo system in the world. One major technical hurdle would be in defeating the 10NES authentication system present in all licensed Nintendo cartridges.

 

10NES 

 

As these development carts would initially be fairly limited in production, a quick solution could be to harvest 10NES chips from existing NES cartridges – an ideal candidate for this being the dime a dozen Super Mario / Duck Hunt cartridge which came with almost every NES every made (wikipedia says that about 40 million of them exist). Better methods for handling this will be the topic of a future post!

3) Test controllers

In order to test on a PC as authentically as possible, real NES hardware must be interfaced with the computer. Around the internet, tons of people have taken the lazy route in doing this via a parallel port conversion. However, this is 2008 and a more ideal solution is to create a NES to USB adapter that would probably require the the connectors off the front of a NES system, a microcontroller for usb encoding and a female usb jack to connect to the computer using a standard usb cable. This solution would be ideal because the microcontroller could be powered over USB, and almost every modern machine has usb ports, whereas classic printer/parallel ports are beginning to be phased out. In particular, this would allow for portable development on laptops.

4) Production Cartridge

In order to distribute finished games in manners other than rom files, assuming the Nintendo and other heavyweights have not seen the light and allowed for digital distribution – is to produce homebrew cartridges. The first thought to come to mind would be to use a cheap modern microcontroller with decent storage capacity to reproduce the cartridge’s internal functionality. These could be programmed using traditional techniques, most likely with some eclipse automation again. The cartridge board itself would be designed via a publicly distributed eagle pcb schematic file so that 3rd party vendors such as freepcbs.com could mass produce them with professional results at minimal cost. The cartridge shells themselves would be created via homebrew vacuum forming techniques, and lack the obnoxious security bits holding them together featured by every original cartridge on the planet. Additionally, in game saves would be accomplished via modern flash ram, as opposed to the CR2032 batteries found in games like Dragon Warrior and Legend of Zelda, that die and then need to be replaced periodically with tedious soldering. Again, the authentication system would create a problem and this initial solution would include a socket on the pcb to drop in a 10NES chip harvested from another cartridge.

With these four bullet points taken care of, the major technical hurdles in launching a new wave of 8-bit games would be complete and all that would remain would be traditional simple ones such as packaging and marketing. Stores that specialize in classic gaming that are starting to popup would probably happily carry these new games on consignment until significant momentum could be gained for traditional distribution.

I intend to begin work on this plan shortly, and welcome any questions, comments or suggestions you may have!

Written by mluebbe in: Gaming,Projects |
May
23
2007
1

Enabling Fn Keys on Sony FS Series Laptops

As many of you may know, Sony laptops don’t always play nicely with Linux due to a bunch of closed hardware. One major annoyance is the Fn keys not working out of the box, and not being able to adjust volume or brightness with them.

Doing some research, I found a solution on the Ubuntu forums here.

Reading through the posts and doing the command line work can be frustrating if you’re new to Linux and aren’t comfortable yet with the terminal – or if you’re just lazy.

I’ve put together a convienience script that will pull everything in, install a patched sony_acpi kernel module to control brightness programmatically, and enable the Fn keys.

Let me know if this helps you out!
(Ubuntu 7.04 / Feisty Users Only!)

Download: feisty-fsfn.sh

Written by mluebbe in: Computing,Projects,Software |

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com