Archive for the ‘Digital’ Category

Malware blamed for plane crash

Sunday, August 22nd, 2010

A recent article notes that apparently the crash of Spanair flight 5022 had as a major contributing factor a compromised warning system computer, which resulted in no audible alarm when the pilots attempted to take off with the flaps and slats retracted. (This is a Bad Thing.)

Here’s the scary part: The computer had apparently been compromised due to malware that had somehow been installed (suggesting to me that it was likely running Windows or another popular consumer operating system.)

I’m all for the use of modern technology in aircraft; engine management computers and other systems can make aircraft safer, more reliable, and much more efficient. Of course, as with all aviation systems, they ought to be thoroughly checked out before being allowed to control critical aircraft functions. One corollary to this is that large, complex, unverified operating systems should *not* be used to run systems in charge of essential functions. I sincerely hope that there has been a misunderstanding in this case. We don’t yet know all there is to know about aviation safety, of course — but not using consumer-grade software in critical systems should be as big a no-brainer as making sure that the wings are bolted on securely.

Party (or program) like it’s 1981!

Saturday, July 24th, 2010

Probably every computer geek has fond memories of his or her first computer. I know I do. I’ve had many computers over the years, including many which I’ve built — but your first computer is always special; it opens the door to the magical world of programming.

My first encounter (as far as I can remember) with a computer was through a teletype terminal that my uncle (a Ph.D student at the time) had set up in his apartment. After dialing in to the school mainframe, it played a mean game of Tic-Tac-Toe.

A few years later, my parents bought me a Timex-Sinclair 1000 for my birthday. I might have been dimly aware of the TS1000’s existence, but was surprised to actually have one. After hooking it up to the TV and reading a few pages of the manual, I had written my first BASIC program. I don’t remember the exact listing, but it was essentially a version of the ubiquitous “Hello, World!” program — writing text to the screen in an endless loop.

Flash forward to 2010; my homebuilt Core i7 is far faster and more capable — not to mention connected to the Internet — but sometimes I still miss the Sinclair.

Apparently, though, I’m not the only one. I recently came across “EightyOne” — an amazing freeware Sinclair emulator from chuntey.com. It was done right, too. All of the Sinclair quirkiness is there — the oooold-school BASIC, complete with line numbers and LET statements; the multipurpose keys on the keyboard (what you get depends on which mode you’re in); the “Fast” and “Slow” video modes (more like “slow” and “slower,” but hey.) There’s even a whole set of NTSC TV signal options so it *really* looks like the real deal — video degradation and all — even on a modern LCD monitor. (Non-purists fear not; these effects can be disabled — but they really do add to the ambiance.)

The EightyOne Sinclair emulator

The EightyOne Sinclair emulator (click for larger).
(The background is my Win7 desktop: Parc Jacques-Cartier, QC)

If you, like me, discovered programming (and all of the really bad-but-fun programming habits that old-school BASIC fosters) on a Sinclair, go download yourself a copy. It’s like stepping thirty years back in time. (…and yes, it *does* have the capability to save and load programs to a .wav-based “tape drive.” I’m sure someone out there has a collection of Sinclair tape programs…)

Here, too, is a great example of geek humor: it has a “RAM pack wobble” option! Many Sinclair programs required a memory expansion pack that would increase the default 2K memory to 16K. The problem was that this (relatively heavy) memory pack was attached to the computer via a flimsy card-edge connector in the back. It had an absolutely uncanny habit of wobbling (causing the system to freeze) at the worst possible times, like thirty minutes into a great Chess game. I swear that connector was designed by Murphy himself.

This isn’t just an emulator; it’s a work of art. Add a Sinclair mock-up keyboard and put the LCD into an old TV set, and it could easily pass for the real deal.

112 cylinders of Paleotechnology!

Monday, June 14th, 2010

Along with old computers, I feel a special affinity for classic airplanes. Modern planes are interesting, too — but when you take the time to look at the technology behind the classics, you can’t help but feel that they are perfectly-balanced combinations of art and science.

The Boeing 377 (click for larger): one of the finest three-engine planes ever made!

The Boeing 377 Stratocruiser is a good example of such a classic. As one of the last great propliners, it represented the pinnacle of radial reciprocating (piston) engine technology. Four Pratt & Whitney Wasp Major R-4360 engines provided a total of 14,000 horsepower*at full power (with ADI on).

I love having microcontrollers, the Internet, digital audio, GPS, and other technology available — but sometimes I wish I had been able to work as a propliner captain (or Flight Engineer) back in the day.

Not too long ago, though, I found the next best thing. A2A Simulations has created a highly accurate Boeing 377 simulation for Flight Simulator X — and they did it right. With many simulator aircraft, the emphasis is on making a product that looks good. Great attention is paid to aircraft markings and paint schemes, and then the default DC-3 panel and flight model is slapped on, with a few modifications as a grudging nod to the fact that this is actually a four-engine plane. Not so in this case! A2A’s Stratocruiser is truly a work of art worthy of the Stratocruiser name. Nearly all of the systems of the aircraft have been modeled in great detail; A2A’s intent was to produce a true simulation of the B377; not just something that looks the same.

Part of the Flight Engineer's panel on the 377 (click for larger). Note the cowl settings to keep #3 cool...

A bit of aircraft history is in order to set the stage. Back when the 377 was designed, jet engines were still experimental designs existing mostly on drawing boards and in military test labs. The dominant technology of the day was the reciprocating, air-cooled radial engine. These had been getting larger, more powerful, and more complex for years, culminating in the 28-cylinder Pratt & Whitney R-4360.

The Pratt & Whitney R-4360 Wasp Major engine (click for larger).

These were not your turn-it-on-and-forget-it, computer-controlled modern jet engines; a 28-cylinder air-cooled reciprocating radial engine required the full-time attention of a Flight Engineer to keep it operating efficiently without causing damage to its many parts. With 56 spark plugs (two per cylinder), 56 adjustable valves,  seven rows of four cylinders, supercharger and turbocharger, it was a formidable, demanding beast. The Flight Engineer needed to not only monitor fuel consumption, cabin pressurization, and electrical systems — he had to “think like an engine” and keep these four engines working efficiently through all the phases of flight.

It must have been one of the most interesting jobs, ever — and A2A’s simulated B377 does a good job at capturing the flavor of the Flight Engineer’s job. Here are some examples.

  • Starting the engines must be done in a specific sequence: Configure fuel flow to the engine including setting the engine fuel valve, boost pump, and mixture control; turn on the ignition switch; set the cowl flaps, intercooler flaps, and oil coolant flaps; prime the engine with five or six shots of primer; crack the throttle; spin up the engine with the starter motor; engage the ignition boost — and watch to see if the engine decides whether or not it’s going to start. If not, double-check your settings and try again — perhaps with less primer so as not to flood it.
  • The engines tend to run hot. When on the ground, the cowl flaps can be opened all the way, allowing the engines to stay relatively cool. In flight, though, these can be safely opened no more than 3″ (per the manual, anyway — I’ve been running the #3 engine at 3.5″ inches since it likes it better that way and haven’t had any parts fall off yet.) During takeoff and initial climb, the engines need all the cooling they can get, but at altitude, the cowl flaps can be partially closed.
  • The engines are carbureted, not fuel-injected — and the intake air temperature must be kept within the operating limits. In practice, this isn’t very difficult, since the intercooler flaps do a good job of cooling the air — and they can be closed and/or the heater turned on if more warmth is needed. When you’re the only one flying the plane, though, it’s hard to remember. (A2A does helpfully provide a copilot, who will warn you about such things.)
  • There are very specific power setting limits for the engines — and if you exceed them, the engines will be quickly damaged. (I actually experienced an engine fire on my second flight, before I knew what I was doing.) The 377 was made to be flown by-the-book, and running the engines at too high a torque and/or manifold pressure setting is a recipe for a premature engine overhaul — if not a complete in-flight engine failure and/or fire.
  • As precise and exquisitely made as the R4360s were, no two were ever quite alike. In most simulated aircraft, the engines are carbon copies of each other. Push all four engines on the default 747 to full throttle, and the flight computer will show exactly the same N1, N2, EPR, vibration, and temperature readings for each. Not so on the B377; each engine is a unique individual. The #3 engine I’m currently flying with, for example, always runs hot; I’ve learned to open its cowl flaps that extra half-inch before I even look at the temperature gauge. #1 might produce a bit more torque than #2 at the same MP and RPM settings — but that’s not a problem, that’s just how it is. Maybe the gauge is a bit off; maybe the engine actually does produce a bit more power — who knows.

* Yes, I would use kilowatts instead of horsepower these days — but that would be an anachronism here. The use of traditional units is part of the beauty and mystique of classic aircraft; discussing them in SI units would be blasphemy.

Digital Swiss Army Knife

Monday, June 7th, 2010

HTC Mogul

(An HTC Mogul smartphone)

The modern smartphone is (this week, anyway) the poster child of the Information Age. When certain technologies combine, the whole really is greater than the sum of the parts. Cell-based 3G/4G Internet connectivity, the GPS infrastructure, local device programmability and storage, the ability to take pictures and record and playback video and audio, and new features like accelerometers all add up to a device that is approaching the ideal Portable Information Appliance. You’re always just a few clicks away from all the information available on the Internet.

It’s impressive how many things such a small device can do, when you think about it. Here are just some of the uses that I’ve found for my phone (an HTC Mogul), so far:

  • Browsing websites,
  • Navigation via Google Maps Mobile,
  • Recording lectures for later study,
  • Remote desktop access via Terminal Services and VNC,
  • Website and email administration over SSH,
  • Listening to audiobooks,
  • Listening to mp3s,
  • Playing games (where there’s Windows, there’s Solitaire),
  • Watching YouTube videos,
  • Updating Facebook, Twitter etc,
  • Logging GPS tracks of my walks around the area,
  • Taking the occasional (crappy) picture or video,
  • Functioning as a makeshift flashlight,
  • Reminding me of appointments,
  • Creating and viewing small Excel spreadsheets, including charts,
  • Creating and viewing notes and Word documents,
  • Acting as an alarm clock,
  • Synchronizing Outlook contacts with my desktop and laptop,
  • Providing Internet connectivity to my laptop,
  • Searching for Geocaches,
  • Managing shopping lists (emailed to it via SMS gateway),
  • …and oh, yeah — apparently it’s a telephone, too.
  • About the only thing I haven’t found for it yet is a good version of portable BASIC. That’s kind of a shame, too, since I had *that* functionality in a pocket-size device way back in 1986!

WUBI

Sunday, June 6th, 2010

WUBI logo

What’s a WUBI? Good question. It’s a Windows-based installer for Ubuntu Linux. Download it, run it, click the Next button a few times, and suddenly you have a Linux installation — without running the risk of hosing your Windows setup. Ubuntu gets set up in two virtual filesystems stored as regular (if large) files on a Windows partition of your choice (they can go in an \Ubuntu folder in the C: drive, for example.)
It’s a painless, easy way to check out Linux or to set up a dual-boot system without causing a bunch of headaches. Go try it out!

Desktop Supercomputing

Wednesday, May 19th, 2010

Sometimes modern technology is fun, too. Especially when it involves GPGPU video cards with 128 processor cores, which can be used for parallel-computing tasks. Even more so, when modern systems support up to three of them. The combination of an interesting course on parallel computer architectures (including nVidia’s CUDA) and the availability of good deals on eBay for two additional video cards of the same make and model as the one I already had turns out to be the perfect recipe for getting started in homebrew supercomputing.

So far, I have them running the SETI@home BOINC client. At first, there was some kind of configuration problem — the work units hardly seemed to progress at all (much slower than the CPU version of the code). Since the initial estimated time for the CUDA version was much less, I figured something was wrong.

A quick Google search came up with a possible solution — disable SLI (gotta remember to switch it back on for Oblivion and Flight Sim), add “dummy plugs” to the two secondary GPUs, and extend the desktop — with Aero disabled — across the two dummy monitors.

It worked — and now the three GPUs are each crunching SETI work units roughly 20x faster than the CPU version of the code. (Overall, the relative system throughput just went from ~8 to ~70 or so.) I’m starting to see what nVidia means about the benefits of manycore computing, on problems like this.

Quick iPad review

Friday, April 23rd, 2010

Two of my colleagues from IT and I stopped by the Apple Store today; several faculty members have requested iPads, and we received authorization to get one for ourselves, to become familiar with it. We weren’t able to take delivery today, though. (The Apple sales rep at the store actually said that “because of the demand” it “didn’t make sense to stock product.” I kid you not.)

I’m glad I’m not from Planet Cupertino.

We did, however, get to try the iPad, since they did have a couple dozen or so demonstrator units on display for people to play with. As with everything Apple, there’s a lot of good, but mixed in with some bad and some downright ugly.

First of all, hardware-wise, I think Apple has a winner. Apple’s engineering has nearly always been quite good (we’ll forgive them the original iMac, since they seem to have learned their lesson.) The iPad feels solid and professionally made, while still being light and usable. Apple claims that the battery life is ten hours. I’m guessing that they mean ten hours reading a single page of an eBook with brightness set to minimum and WiFi off — more like four or five hours, the way I’d probably use it.

The good:

  • The display is gorgeous. Bright, crisp, and (mostly) easy to see. The glossy screen does mean that if you’re viewing dark images, you will tend to see a distinct reflection, which hurts the experience. It’s generally pretty dark in my Geek Cave, though, so this isn’t a big deal.
  • It has an accelerometer, and puts it to good use just like the iPhone does; most apps will rotate around to follow the way the iPad is being held, switching smoothly from portrait to landscape mode and back within a few seconds. The demonstrators at the Apple Store included a really fun ball-in-the-maze game, complete with all kinds of obstacles and puzzles only possible in a computer game.
  • Pinch-zoom and scroll are generally very snappy; the Google-powered Maps app that it comes with makes a great demonstration. Whatever Apple has under the hood, it gets the job done nicely.
  • As with most Apple offerings these days, it feels like a solid, quality product. Apple’s hardware engineers do tend to “do it right.”

Some drawbacks:

  • 3G isn’t available until a few weeks from now; the iPads available now (well, “now” being “in a few business days since we at the Apple store can’t be bothered to stock product”) are WiFi-only.
  • There’s no real keyboard (unless perhaps a Bluetooth one will work), and the onscreen keyboard is about on par with the iPhone’s — that is to say, slightly south of a “meh” in my book. I had expected faster, more accurate response, especially since there is so much more screen real estate to work with.
  • As mentioned above, the screen is glossy and therefore very reflective. This made it difficult to see at times, when darker content was being viewed. (The environment was the Apple Store, lit similarly to a modern office.)
  • The sound was just barely audible in the (admittedly somewhat noisy) store. The (very cool if a bit unresponsive) Piano app that I tried (a great use of multitouch if I ever saw one) was very difficult to hear, even with the app and system volume controls set to max.
  • It runs Apple iPhone OS. This does make it easy and fairly intuitive to use, but to someone used to “real” computers (Linux, and even Windows), it has the distinct Apple mindset of “you’re-not-supposed-to-be-using-this-for-things-that-Apple-doesn’t-want-you-to.”
  • It’s too big to put in your pocket — even in cargo pants. Size-wise, it’s definitely in netbook territory, only a lot thinner.
  • The screen could possibly be a bit larger (but that’s personal preference). This would allow more touchscreen apps like a full-size, playable piano, or a much easier-to-use onscreen keyboard.

Showstoppers (for me):

  • The Apple-way-or-no-way-at-all groupthink is in full force here. I was curious as to how well the iPad would work as a Remote Desktop client, and tried downloading a free RD client from the App Store. Unfortunately, you need to register with Apple, even to download free content. Contrast this with Linux or Windows, where you can download a tarball, zipfile, msi or exe installer, or Linux installation package of your choice from anywhere, anonymously. Registering shouldn’t even be required for payware content (other than to pay the developer) — let alone for free apps.
  • The lack of a keyboard would relegate the iPad to use as a eBook reader (which it admittedly is great at), casual game device (which it does okay at, especially with the accelerometer), and/or map device (which it also is great at.) Unless it were an emergency, though, I wouldn’t want to write code, documents, or emails, on it. Typing anything more than a very occasional search phrase was very aggravating (even typing in an address into the Maps app was painfully slow compared to using a real keyboard.)
  • The iPhone OS means, to me, that it isn’t a “real” computer — and therefore could never replace a laptop. If I had a laptop with me, I just don’t see using an iPad all that much.
  • Most importantly, Apple hasn’t seen fit to change their totalitarian ways. Guys, you build some awesome hardware — if the iPad ran Linux, I would seriously consider buying one at some point. By all means, make it available as it is with the iPhone OS or any other proprietary OS — but throw us hardcore geeks a bone and make a Linux distro for it (with proprietary hardware drivers, if you must.)

Finally, an idea — why not make a portable docking station for the iPad — where it could be used as a semi-intelligent monitor for a laptop platform, detachable to work on its own as a slate computer when needed? You would have the functionality of a netbook with a great touchscreen display, with the ability to disconnect it and use it as a native iPad whenever you wanted? This would seem to be the ideal way to bridge both worlds.

Superscalar — The Easy Way!

Wednesday, April 14th, 2010

I really enjoy taking courses with useful, practical content. It doesn’t happen all the time, but I’ve had a good run of luck recently. Tuesday’s lecture in the ECEC622 Parallel Computer Architecture course I’m taking was about OpenMP — a very easy-to-use, open-source API for C/C++ and Fortran.

OpenMP is what an API should be — both useful and very easy to incorporate into an application, even for programmers encountering it for the first time. Within a few minutes of learning the fundamentals, I was able to write a multithreaded version of the ubiquitous “Hello, World!” program.

Of course, whenever I want to really start to learn a language, architecture, or API, I use it to write a Mandelbrot Set program. Mandelbrot Set calculation lends itself extremely well to parallelization APIs like OpenMP — it’s what programmers refer to as “embarrassingly parallel.”

Here is the Mandelbrot Set calculation code. The OpenMP modifications are shown in blue. Omit them, and the code does exactly the same thing, but without the parallelization.

#include <stdio.h>
#include <omp.h>

//Mandelbrot Set calculation routine, to test
//speedup obtained from using OpenMP

//M. Eric Carr
//mec(eighty-two) .at. drexel (dot...) edu

int main(){
	const double rmin = -2.2;
	const double rmax = 1.4;
	const double imin = -1.8;
	const double imax = 1.8;
	const unsigned long long maxiter = 20000;
	const unsigned long long xres = 2000;
	const unsigned long long yres = 2000;

	double a, b, r, i, h;	//Private variables for threads

	unsigned long long totalcount=0;
	unsigned long long count=0;
	unsigned long long x,y;
	unsigned long long iter;

	double dx, dy;
	dx = (rmax-rmin)/xres;
	dy = (imax-imin)/yres;

	#pragma omp parallel for private(a,b,r,i,h,x,y,iter) reduction(+:count)
	for(y=0;y<yres;y++){
		b = imax-y*dy;
		for(x=0;x<xres;x++){
			r=0;
			i=0;
			a = rmin + x*dx;
			iter=0;
			while(iter<maxiter && r*r+i*i<=4.0){
				h=(r+i)*(r-i)+a;
				i=2*r*i+b;
				r=h;
				iter++;
				}
			if(iter>=maxiter-1){
				count++;}
			} //for x
		} //for y

	#pragma omp barrier

	printf("dx is: %F\n",dx);
	printf("dy is: %F\n",dy);
	printf("Total count is: %lld\n",count);

	dx=count*dx*dy;

	printf("Total area is: %F\n",dx);

	return(0);

	} //main

Three extra lines of code, to share the workload among however many CPU cores your system has (eight virtual cores, on a Core i7 CPU). Talk about a good return on your coding time!

Computer Art

Wednesday, April 14th, 2010

Take a rectangular field of arbitrary size (pick something nice like 800×600), fill it with random pixels, then iterate the following code:

* Choose a pixel and one of its neighbors
* Make the neighboring pixel the same color as the first pixel
* Repeat as desired

As an algorithm, it isn’t much to look at — but it produces interesting psychedelic pictures, and it’s fun to watch it in action.

True 8-bit computing!

Friday, April 2nd, 2010

A while ago, I realized that the DrACo/Z80 was actually quite a bit more complex than it needed to be, to suit the purposes of the EET325 class. Since it is programmed in machine code, the programs written for it tend to be very small, both in terms of code size and memory usage.

Since wire-wrapping all of the connections is by far the most time-consuming part of the build process, this suggested a possible shortcut. Instead of wiring up all sixteen address lines, why not make it a true 8-bit computer — with only eight address lines? Sure, it will only be able to access the first 256 bytes of its memory, but nobody ever uses more than that in the class, anyway. (…and if any students get that ambitious, it can still be upgraded to 16-bit easily enough.)

Here are the updated schematics (including a few bug fixes and annotations). The 74LS245s between the Z80 and the bus have been removed, as well, since even the original 16-bit prototype runs well enough without them.

DrACo/Z80 Control Panel (8-bit version)

DrACo/Z80 Core (8-bit version)