by Richard F. Drushel (drushel@apk.net)
This weekend I finally had a chance to start working on the new boot picture for the ADAMserve version of PowerPaint. My starting version was the picture I had modified (dated 2 September 1991!!!) for the Mini Wini hard disk version of PowerPaint. This in turn was based upon a special boot picture done by Tony Patterson and obtained from Tony in the summer of 1991, when he happened to be in town (he was a travelling children's photographer then) and we held our B.A.S.I.C. users group meeting in his motel room. (Boy was it crowded in there.)
I wanted to change the design so it was crystal-clear that this was the ADAMserve version of PowerPaint. To that end, I decided to replace the lower-right picture of a Mini Wini HD setup with something more appropriate: a bare ADAM and and an IBM PC-XT, linked by ADAMserve. I loaded the picture into PowerPaint and started to work.
It's been about 3 years since I did any serious drawing with PowerPaint, and when I did, I was using a 19-inch TV set as the monitor. My current monitor, a Commodore 1701, has beautiful color and resolution, but I was having a really hard time editing bitmaps on a 13-inch screen. My thoughts immediately turned to, "How can I export this picture to my 486 so I can edit the picture with Canvas?" Canvas is a fine product of Deneba Software, originally developed for the Macintosh, which I have used nearly every day in my job for image analysis and production of publication graphics. It's easy to edit bitmaps in Canvas, it has a zoom or "fatbits" mode so you can see what you're doing, and importantly, you can move parts of your bitmap to arbitrary locations on the screen--you're not limited to 8-pixel boundaries like you are in PowerPaint.
So, using ADAMlink V, I XMODEMed over the PowerPaint 10K binary file and took a look at it with Norton Disk Editor on my 486. After a brief inspection, and knowing something about the internal architecture of the TMS9928A video display processor, I had figured out the format of the file. Here's a brief description:
A PowerPaint 10K binary file has 5120 bytes of pattern information, followed by 5120 bytes of color information. Each bit in the pattern bytes is a pixel, 1 for on, 0 for off. Each pattern byte represents a stretch of 8 consecutive pixels. Each group of 8 pattern bytes represents an 8x8 graphic cell--it's *not* continuous raster image data. There are 640 such 8x8 cells, 32 across, 20 down. (Note that the physical screen is 24 cells down, but PowerPaint uses the bottom 4 for its own SmartKey menus, and this area is not available for user pictures.) The color bytes specify a 4-bit foreground color (pixel on) in the high nibble, and a 4-bit background color (pixel off) in the low nibble. The color bytes have the same spatial arrangement as the pattern bytes, i.e., 8x8 cells, 32x20. Because there is only 1 color byte for each pattern byte, each group of 8 pixels (corresponding to the horizontal boundaries of pattern cells) must have the same foreground/background colors. This is a well-documented hardware limitation of the TMS9928A, and is responsible for the "color bleeding" effect seen if you try to set adjacent pixels within the same 8-pixel group to different foreground colors.
Fortunately for me, most of the boot picture was with a black foreground color. Thus, simply exporting the pattern bytes as a black-and-white raster image wouldn't lose much information. Besides, I was confident that I could do small touchups in PowerPaint itself after I had the majority of the image done under Canvas.
Most modern image file formats don't store their information in such a hardware-specific form as the PowerPaint 10K binary file. Usually the image is stored in some form of raster array--i.e., a continuous left-to- right sequence of pixels, starting at the upper left corner and going to the lower right corner, wrapping to the next line at the right margin. To convert the PowerPaint pattern information to a raster array, I wrote a QuickBASIC 4.5 program which decoded the file according to the above description, and wrote the pixels out to an intermediate file format which I developed myself for use in my research. I call it IMG; it's simply the first 2 bytes are the number of rows (lobyte, hibyte), the second 2 bytes are the number of columns (lobyte, hibyte), and the remaining bytes are the array of pixels, one byte per pixel. The encoding of the pixel bytes (i.e., what color they correspond to) can be anything you like. It can be grey levels 0-255, it can be an indexed color palette, etc. Usually I use it as an indexed color palette with colors 0-15, with the palette being that used by the IBM VGA display in 640x480x16 color mode.
The reason for making an IMG intermediate file is that I also had available a program I wrote to convert IMG files into greyscale TIFF files. TIFF (Tagged Image File Format) was one of the first image formats to be developed, and is very useful for moving greyscale and true-color images between different computer systems. My Canvas drawing program could read TIFF files, so I converted the IMG file to a greyscale TIFF and loaded it in. Now I could edit it to my heart's content :-)
When I was finished, I saved the final version as a greyscale TIFF. Since the drawing was still in black and white, I didn't need to worry about colors--yet. I still needed to convert the TIFF file's internal raster array of 1 byte per pixel into the encoded format required by the PowerPaint 10K binary file. I wrote another QuickBASIC program to perform this task. "Final" PowerPaint file in hand, I XMODEMed it back to the ADAM, and opened it up with PowerPaint.
The image pattern transfers had worked perfectly. Some of the background coloring was now no longer in the right place to match the foreground image, but that was easily cleaned up using DRAW BACKGROUND. As I had stated above, most but not all of the original picture had been with a black foreground color; it was now that I had to deal with the parts that had other foreground colors. A picture of a paintbrush with splotches of colored paint had been moved slightly to make room for additional artwork; when I moved the foreground patterns, I had *not* moved the color bytes. So, I had to retrace some of the picture in black (where new artwork had spilled into the old color information, causing it to appear in the old foreground colors), and re-color some things which were now black which should have been in color (the paint splotches). All in all, I was pretty happy with the result--and despite all the file transfers, new programming, etc., I'm convinced I did it faster than I would have had I slogged it out with PowerPaint. Not that PowerPaint is a bad tool; I just needed to be able to use it at the expert level, and I was very rusty--so I moved to where *I* could use *my* expert tools.
Now that I've seen how this has all turned out, it's trivial to modify the PowerPaint-to-IMG export program to
write greyscale TIFF files directly (I wrote library routines to read/write TIFFs, but the code was at work and all I had were the .EXE files so I went with what I had), and
write RGB color TIFF files, using the foreground/background color information.
It's also not too bad to
import a greyscale TIFF file into PowerPaint format to yield black&white images.
But the real problem would be
importing an RGB color TIFF into PowerPaint.
I'm not sure how I'd make it choose what colors to use if it ran into the "color bleeding" problem.
If there is any interest in (1), (2), (3), or even (4), please let me know and I'll put them on my "to do" list. Others are free to jump in if they like.
This section of TWWMCA will be rather short, because the project is still in progress, and I don't want to make a report until everything is complete.
Those of you who have "surfed the Web" know that there are several sites from which you can search for keywords on *any* web page that's been up for the last year or so. These "search engines" provide you with the URL (Uniform Resource Locator) of any matches, so you can go to the actual web page and check it out. My favorite of these is the Altavista Search Engine at http://www.altavista.com/. It has an Advanced mode in which you can combine your keywords with AND, OR, NOT, etc., group terms with parentheses, search for words which are NEAR one another (within 10 words forward or back). It's very powerful.
In my tinkering with Altavista, I've managed to locate a person who was very important in the history of the ADAM. I'm currently conducting an interview by E-mail; he's been gracious enough to consent to this. When I have written my summary, and he has had a chance to approve it, I'll post it to the mailing list.
To keep you on the edges of your seats, and to keep my contact from being flooded with well-intentioned E-mail requests, I'm not going to tell you who he is right now. Suffice it to say that, without this man, the Coleco ADAM as we know it would not exist. His story is fascinating, and he seems prepared to tell it now.
You are free to speculate, but I ain't tellin' yet. Keep reading the mailing list! :-)
Pat Williams mailed me the disk with her report of our B.A.S.I.C. meeting on Sunday 13 October 1996, but I haven't had a chance to convert it to plaintext and post it to the mailing list. I hope to do this in the next couple of days.
Ron Mitchell (ronaldm@mars.ark.com) sent me a lengthy E-mail this morning in which he exposes all the warts in the current version of ADAMserve. I knew they were there, and some aren't "bugs", they're "features" :-) He's writing a review for A.N.N. and wanted some info from the horse's mouth before the horse is sent off to the glue factory. I spent this morning replying to his questions. The horse hopes that he has managed to forestall his appointment with the knacker-man :-)
See you again next week!
*Rich*
Next Article
Previous Article
TWWMCA Archive Main Page