Quad Monitors: is it worth it?

I recently acquired four rather large and unwieldy CRT monitors that were otherwise destined to the trash heap, in addition to my regular LCD and a Sony TV that I was using to do dual screens in the past. It just so happens my video card supports up to six monitors. I have, therefore, attempted to accomplish every geek’s best dream come true: my very own monitor wall. Okay, maybe second best dream come true, but the first can’t be talked about with children present.

Now moving on, the shiny new Saphire HD5870 2GB GDDR5 Eyefinity 6 Edition video card in my desktop doesn’t actually have any sort of analog output. The outputs are all pure digital through six mini-display port connectors. The video card comes with 4 mini-display port to regular display port adapters, a mini-display port to HDMI adapter, and two mini-display port to DVI-d adapters. To support more than two monitors, the adapters have to be of the active variety, which actually have some sort of logic and clock signal generation build into the adapter. I picked up two Acell Displayport to VGA adapters from Fry’s electronics for $30 a piece to get my monitor wall started, and to decide if 4 monitors is enough or I really am crazy enough to want 6. It’s also easy to fit 4 on my desk without too much work. I did have to disassemble part of my desk to fit them, but nothing but a hack saw and a little bit of wood glue won’t fix up once I have the time.

The question still remains: is worth it? For everyday use, definitely overkill. For programming, maybe. It is useful to have a couple of sources of documentation up while coding in one or two screens.

Jacob’s Ladder

I wandered across a 15kv neon sign transformer when I was cleaning my room that I somehow lost. Yes, I somehow misplaced it years ago, despite it being rather large and heavy… things vanish in my room? Anyway, I wired on a plug off an old fan and some coat hangers and made a nice little Jacob’s Ladder. Video here, though not very good quality,

http://www.youtube.com/watch?v=HG1jrq5tj-0

EE101 Hummerbot Videos

Finally got around to posting some old videos of the robot I made back in EE101 a year ago.

The hummerbot (my team’s robot) on the ramp,

http://www.youtube.com/watch?v=IVMj-MIEGfM

http://www.youtube.com/watch?v=fBgCe5NAAxU

The hummerbot on the can course,

http://www.youtube.com/watch?v=UeFmm4FkRnU

http://www.youtube.com/watch?v=MrN54sZcY6A

One of our competitor robots (slow and steady wins the race?),

http://www.youtube.com/watch?v=VdETMfP_kmc

http://www.youtube.com/watch?v=_9wO-Xzdf_c

A blooper of a not so competitve robot,

http://www.youtube.com/watch?v=5NlHOx8KUh0

Aah good times. When we walked into the lab and saw the other robots, we said, “Well… we’re either going to get an A because our robot is the most awesome thing here, or we’re going to fail since we hacked a microcontroller on an RC hummer instead of building ours from scratch and duct tape.” We ended up getting an A.

Netbooks: 1024×600 too small

A long time ago, monitors were large in size and small in heart. The behemoths would reliably sit on the often waning and sagging desks of their owners with the standard VGA screen resolution of 640×480. As time went on, people found ways to cram more pixels into the same sized monitors, leading to SVGA (800×600) and then a subset of SVGA known as XGA (1024×768). As webpage and application users upgraded their systems, the webpage and application writers began making use of these extra pixels, putting larger and clearer images, better layouts, and more text without scrolling. The logic was sound: satisfy the base of customers that are the largest and try and deal with the rest, but the good of the many outweighs the good of the few. Try browsing the Internet today with a 640×480 monitor and you’ll realize how much has changed. You can’t even get rid of your good old VGA displays anymore, even the trash companies don’t want them.

Then LCDs came around, and got even worse. Once again people found more ways to cram pixels in, this time making wide screen and crazy resolutions like WSXGA (1600×1024) and all the way up to 2048×1152 and beyond. All along, the applications and webpages were slowly written to perform well on larger screen resolutions, usually keeping 1024×768 as a minimum, but not always.

The screen resolution trend gained momentum. Lots of it, for good reason. I love my 2048×1152 LCD at home, especially for programming. I can see more data at once, more code, more files, all viable and at the touch of my fingers and mouse. If I wasn’t so cheap, I’d probably have dual LCDs.

Then, somewhere and somewhen, people started trying to push the trend backwards. Computers got smaller, but they also got slower. People packed less pixels, but produced mobile devices. They went back to the old standards of 800×600 and a new widescreen 1024×600 and came out with netbooks.

And guess what happened? All those lovely applications that are designed and tested for 1024×768 or above, are now broken. You have no idea how many times I’ve found an application on my netbook where the “Okay” button is hidden underneath the view of my 600 vertical pixels on my netbook, or some important menu option is hiding. In fact, I’ve at times went down to 800×600, because sometimes that will trigger alternate layouts out in the applications that 1024×600 won’t due to the different aspect ratio.

The momentum of the screen resolution trend is unlikely to be reduced anytime soon. Netbooks and mobile devices are just a slight friction, pushing developers to test their applications on smaller screen resolutions, making the real world a little more complex than a perfect world of 1024×768 defaults. Right now it looks like the market of netbooks and 1024×600 screens is too small for many developers to spend the time to make layouts look nice on them, even in Linux. In fact, I’ve found Linux to be quite a bit worse with applications having the bottoms cut off than Windows. Even some Gnome system settings menus will display incorrectly, with the “okay” button just frustratingly out of reach.

AVR Butterfly Part 2: Setting the BOOTRST Fuse with ISP Cable

With a little more research I decided to hack together an ISP programming cable using a computer parallel port to toggle the BOOTRST (Select Reset Vector) fuse on my AVR Butterfly, rather than send it to someone to fix it or back to Mouser. Schematic shown below,

NOTE: the 1K resistor going from pin 11 of the DB25 to the MISO is too high of resistance. When I tried to use this cable with AVRdude I got the following error,

avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

I just removed that MISO resistor entirely and got it working correctly. A lower value might be good to avoid accidentally damaging your LPT port; some schematics said 300 ohms. If you still get the above error without the resistor, check all your wires. Also, be careful and DO NOT plug in and turn on the AVR when the computer is off. This will possibly damage your LPT port from what I’ve read.

To get my male DB25 I cut off an end from an old printer cable, which also works well because it is shielded. The plans on the Internet recommended you keep the cable below 70cm in length to avoid interference problems. I forgot how many wires are in these things… If I ever make a bomb, I shall construct it with DB25 connectors.

“Cut the orange wire!”

“but.. WHICH ONE?!”

As far as I can tell there is no standard for the wire colors inside,  so you just have to strip each one and test it with a meter. If you’re following along with this, I hope you have a good pair of wire strippers. Either that, or I’ve found for this small of wire you can put an old tip on your soldering iron, crank the heat up all the way, and then just let it sit on the bit of exposed wire on the end. The insulation should peel enough to test it with a meter easily.

AVRdude is a command line utility that can easily toggle the fuse bits using this cable and the butterfly, and it comes with WinAVR. There is a great tutorial for how to set fuse bits here. The following is just a quick summary.

First, read the current configuration of the high fuse byte.

avrdude -c dapa -p m169 -U hfuse:r:hfuse.txt:b

This will create a file called hfuse.txt containing something like,

0b10011001

The #1 (last, LSB) bit of the high fuse byte is the BOOTRST bit which needs to be programmed to activate the bootloader.  In Atmel jargon, a bit is “programmed” if it is 0 and not programmed if it is 1. In my case, flipping (programming) the last bit will result in 0b10011000, or 0x98 hex. To write that to the fuse byte,

avrdude -c dapa -p m169 -U hfuse:w:0x98:m

Success! Going back to AVR Studio and writing a simple program to blink some LEDs in a Cylon eye pattern to the AVR worked fine.

RISE MY CYLON BRETHREN! Er.. maybe I’ve been sniffing the solder fumes a bit much.

AVR Butterfly: Part 1

After thinking about doing something interesting like making a robot for some time, I always end up getting bogged down in details and never get around to it. Instead of such a big project, I decided to just pick up an AVR Butterfly demonstration board to play with and learn more about programming micro-controllers. It’s got an d ATmega169PV with 512KB of memory; as well a handful of input/output pins with a built in clock, LCD, temperature sensor, buzzer, voltage sensor and analog to digital converter. It can also (in theory, see below) can be programmed with an RS232 port and no special hardware, and using all free software to compile C code or just program straight Assembly. And all this for only $20, hard to beat. I ordered it from Mouser and got it in the mail yesterday.

For assembly I found that I had a ton of male header connectors, but no females. A trip to radio shack came up with nothing, so I stripped apart an old computer and found what I needed. The cables that go to the serial and parallel port are 10 pin female and work well. Only downside is that they are stranded wire and will be a pain to push into a bread board.

The connectors are too wide for all 3 of the 10 pin headers, but the middle one I think is just JTAG stuff for the most part and won’t be used for now at least.

For the RS232 I used the female connector on the end of the power button,  along with a spare pin off a front LED connector.

The other end just goes to a DB9 I had laying around. Only downside to all this is that it’s quite easy to plug things in the wrong direction.

I hook it up to the RS232 and manage to make it say, “Hello”. After that when I try to actually program a simple C program into it though, I find that I happen to have one of the misprogrammed/recalled AVR butterflies which do not have the boot loader bit set correctly on them. Instead of starting instructions at the beginning of memory, it skips the bootloader and isn’t programmable through the RS232 until I toggle a bit using either JTAG or SPI.  The way to diagnose the problem is to note that when you apply power, instead of sleeping until you press up on the joystick, it will just start tickering AVR Butterfly across the screen right away. It also won’t send the series of question marks to the serial port on boot that are expected. The details on how to change the bit with SPI are elusive, since it’s something most people trying to program chips via JTAG or SPI should already know apparently, and the schematic link I found for using a parallel port to program the SPI was dead, so I’m currently waiting on some forum replies plus an email to Mouser to see if they will do anything about sending me a recalled product. They’ll probably tell me I can send it back and get a new one, but it’s really not worth the trouble, especially if they charge for shipping; and I also soldered on my header connectors already… Worse case I’ll make friends with some people at the lab at work and see if I can get ahold of a JTAG programmer during my lunch break.