 |
The
Fitting Room
A ThousANd WoRds |
 |
Mike
Jewison, AC Staff Columnist
Best Laid Plans...
I have a philosophy of life that goes something like, "Life is grand until it starts to interfere with the things you really want to do." Such was the case with the December issue of AC. When the Grand Exalted Poohbah, our beloved Managing Editor (who also doubles as that Great Analog Wizard, the 8-Bit Alchemist) initially suggested the video theme for last issue, I was delighted. [Dear me, such extravagant flattery! Sorry Mike, AC still only pays $25 for articles! -BP] My chosen field is astronomy which, perhaps more than any other natural science, excites the imagination of John (or Jane) Q. Public. The mere mention of the word, astronomy, conjures up visions of planets, galaxies, exotic quasars and more. Call it personal bias, but I don't get the same tingly sensation when I hear the word "chemistry". [Editor's comment. Hrummmph!] Needless to say, life caught up with me and here we are in February (or later, if this Killer Winter doesn't end soon). Ah well, better late than never...
Images "R" Us
I have three part-time jobs. I had one full-time job until about two years ago when the Canadian federal government decided to lop huge amounts from the grants which were paying my salary. No salary, no job. (Well, I suppose I could have worked for nothing, but that wasn't my first choice!) I was lucky to find another job in only a couple of weeks, in my chosen field, about a 40 minute drive from home. The place where I spend the bulk of my time now is pretty exciting. I'm working with a group of astronomers who analyze, among other things, images of the outer planets (primarily Jupiter and Saturn) and a number of asteroids. These images originate from a variety of spacecraft, including Voyager 1 and 2, Galileo, and the muchmaligned (and now repaired) Hubble Space Telescope.
An important facet of this work is the necessity of being able to access to these images as soon as possible after they're downloaded from the spacecraft. When someone gets observing time with one of these instruments, there's a period afterwards during which they have proprietary use of the data, typically one year from the observation date. After that the data goes into the public domain.
Because of the wide diversity of computer platforms used to analyze these images they have to be stored in a machine-independent format. When we copy files over the Internet, we don't know if they're coming from another Sun, a VAX, or even, (God forbid), an IBM mainframe. And to be honest, we don't really care. All we worry about is whether or not we can read the images once we get them to our machine.
I started thinking (I know, I know, a dangerous pastime) that if I can move machine-independent images between different platforms at work, why couldn't I do the same thing between our Sun workstations and my 8-bit Atari? After all, astronomical images are often among the most beautiful and awe-inspiring available: what better way to show off the video capabilities of the Classic Atari computer?
Spiffy GIFfy
To the best of my knowledge, there isn't any software available for the 8-bits to allow reading of the images we get from the Jet Propulsion Lab, which means I'd either have to write software to read in the images or else find images in some other format. Fortunately, there exists a defacto standard among microcomputer platforms to enable the exchange of graphics images, the Graphics Interchange Format, or GIF, developed by CompuServe. There are literally thousands of GIF files available online. Not just on CompuServe, GEnie, or Delphi but also on a variety of anonymous ftp servers on the Internet and likely on your local BBS as well.
Fortunately for me, many of the sites which contain the images we use at work have taken the time to convert a large number of them into GIF files. So I took one each of Saturn and Jupiter, copied them over to our Sun workstation and wrote them out to a 3.5-inch MSDOS-format floppy to take home. Once there, I fired up my IBM-clone, copied the files from the 3.5-inch floppy to a 1.2MB 5.25inch floppy, and headed down to the Atari.
I have both a 360K and a 1.2MB 5.25-inch floppy drive for my 800XL. They're connected to the computer via the Black Box/Floppy Board combination from Computer Software Services. The BBXFER software supplied with my Floppy Board flawlessly copied the image files from the IBM floppy to a SpartaDOS 3.2 floppy. (Once I get a highdensity 3.5-inch drive for my BB/FB I won't even need to use the PC; I'll be able to bring a floppy home from the Sun workstation at work and read it right on the Atari.)
The most widely known (and certainly the most readily available) package for reading and displaying GIF files on the 8-bits is Jeff Potter's APACVIEW routine. This is distributed as shareware (for which Jeff has set the shareware fee incredibly low) and is available on most of the major online services. What I needed to do initially, then, was to use APACVIEW to read in my planetary GIF images and display them in APAC mode on my monitor. (For more details on APAC, see Jeffs article in the June 1993 issue of AC.)
When I finally got the images up on my monitor I was, to say the least, somewhat disappointed. Although there was no mistaking the content of the images (I mean, after all, who could mistake Saturn for anything else?), the rich colors present in the original GIF files, particularly in the image of Jupiter, were conspicuously absent. I tweaked the monitor controls for hours (well, maybe it just seemed like hours), but could never get the images to display anything but the palest of colors.
Read the Manual
Undaunted, I loaded the test pattern included with APACVIEW (COLORS.GIF) to my monitor and attempted to adjust the on-screen colors to match those in the table in the APACVIEW manual. (It's just like adjusting the color on your TV with a test pattern displayed). The APACVIEW test pattern consists of sixteen different colors, but I could only get one or two of them to even come close to what they should have looked like. One weird thing I did notice was that when I was adjusting the hue and colour controls on the monitor there wasn't a smooth change on the screen. As I fiddled with the hue control the on-screen tint would "stick" for a bit and then change rather abruptly. I started thinking, "Great. Now my monitor's acting up."
While pondering what to do next, I did what any normal person would do: I pulled out a back issue of AC and started reading. In his article in the June '93 AC, Jeff mentions that certain types of monitors would produce only pale shades of red and blue-even those which otherwise behave perfectly normally. Well, since my monitor seemed to be one of those which didn't behave with APACVIEW, and since Jeff created COLRVIEW to improve upon APAC, I decided to try my luck displaying the images using COLRVIEW.
I used APACVIEW to convert my GIF images into COLRVIEW format files, fired up COLRVIEW, and pulled the image of Jupiter up onto my monitor. Now I was doubly disappointed, because the colors COLRVIEW was displaying were no better than those APACVIEW showed earlier. And loading the COLORS file yielded the same results as it did with APACVIEW. Argh!
Time For An SOS!
Thoroughly perplexed, I fired an email SOS off to Jeff. We corresponded for a while and finally came to the conclusion that, for whatever reason, my monitor was screwy. Not completely, mind you, because the monitor appeared to work normally at any other time. It just wouldn't work with Jeff s software.
Although it seemed real easy to blame the software, I couldn't do that because Jeff reported that other users with the same monitor type (a Technika MJ-10) have reported no problems. I started thinking that maybe the problem lay with the images I was using. It states in the APACVIEW manual that the software works best with GIF files that have fairly saturated colors. Although the image of Jupiter was very colorful, the colors tended to be pastel shades rather than saturated. This was especially true of the image of Saturn. "OK", I thought to myself, "why don't we go and grab some other images, maybe some already converted to COLRVIEW format?" "Self", I said, "that's a great idea!" (Believe me, by this time I really was talking to myself!)
I fired up the modem and connected to GEnie. I then headed straight to Library 20 in the Atari 8-bit area. Library 20 contains nothing but graphics images, many of which are already in COLRVIEW format. I downloaded a couple of likely-looking files (the starship Enterprise and a Klingon Bird of Prey) and copied them over to the Atari.
When I used COLRVIEW to load the images they came up predominantly green. Nice, sharp looking images of the Enterprise, but monochrome images nonetheless. I tried playing with the RGB color registers in COLRVIEW but could only get a single color on the screen at any one time. I couldn't believe someone would upload monochrome graphics images when the software was capable of handling a full 4096 colours, so I figured the problem must lie somewhere else.
Swap Meet
When I troubleshoot a problem like this I try to do so logically; if that doesn't work I then fling everything off the table. There were four variables in the equation here: software (which couldn't be changed), images (which had already been changed), monitor (which couldn't be changed since I had only one), and computer. Since the only component left to experiment with was the computer, I decided it was time for a CPU swap.
I took my trusty old 800 and plugged it into my monitor. I had to copy the software and images from a 1.2MB floppy to a 360kB floppy because my 800 can't access the drives connected to the Floppy Board. I booted up the new SpartaDOS disk, loaded COLRVIEW, and brought up the image of the Klingon ship.
Initially, I couldn't get results any better than with my 800XL. I recalled reading in the APACVIEW docs that monitors offering split video (such as the Technika) work best when the separate luma/chroma inputs are used. Although I was using COLRVIEW, I flipped the monitor into composite mode, adjusted the color registers, and ended up with a decent looking picture: some color (not a lot), but certainly better than the monochrome image I had been getting. I loaded the COLORS test pattern in an attempt to fine tune everything and eventually gave up in frustration. My old 800 was a step up from the 800XL, but it was still giving far from ideal results.
Confusion Reigns
I really don't pretend to understand what's going on here, but I can make a number of guesses. My problems in viewing GIF images with my 800XL appear to be twofold: the colors being produced by the computer are deficient, and the monitor may have some problems in displaying colors properly. Put the two of them together and it's a recipe for disappointment.
All of this has, needless to say, made me somewhat paranoid. I'm beginning to wonder if the Great TKFreeze Explosion I discussed back in October is manifesting itself here. When my TKFreeze board got zapped it had the GTIA plugged into it at the time. And, of course, the "G" in GTIA stands for graphics. Maybe my GTIA suffered some damage which only shows up when I try to run COLRVIEW. [Editor's Comment. I think it unlikely. My experience with funky GTIA's suggests a bad one will misbehave all the time. I have no personal experience with the Teknika monitor, but I know any number of people who have one and swear by it. A marginal component in the clock/color circuit (as described in "Color and the Clock" in the Dec. '93 AC) could be the culprit. I'd want to monitor the bias on pin 17 of the GTIA to see if it changes during normal color putput vs. when a COLRVIEW file is being displayed. -BP]
There are a number of other things I could try (and would have if there'd been more time before copy deadline). I could try running the software on my 130XE and see what happens. As I suspect the major source of problems is my monitor, I could try displaying the output on another monitor or even my TV, using the RF jack. I'm certainly going to look at implementing some of the hardware hacks that appeared in the December '93 AC. The truth of the matter, though, is that I am all videoed out. I need a nice long vacation from all this before I hack on it again.
Even with all the problems I encountered, I'm very impressed with both APACVIEW and COLRVIEW. The ability to load and display GIF images in up to 4096 colours on the Classic Atari is something not to be sneezed at. And the shareware fees for both these packages are so low ($10.00 for APACVIEW, $8.50 for COLRVIEW) it really is criminal not to register your copy. The shareware fees also enable Jeff to continue developing software (and I know he's got new, improved stuff in the works). What annoys me most about all this is that my souped-up hardware wasn't up to the task. >Sigh<
[Next time: back to hardware adventures. If you thought I had problems this month, wait till April. There's some scuzzy happenings in the of Fitting Room.]
