IFF24 Viewers Using ImageMaster or ADPro; Directory Opus or a Shell; and the Firecracker 24 Projects to Challenge Beginners by Merrill Callaway This month I want to share two utilities that I developed to ease the tedium when I'd rather be creating or viewing than messing around loading programs and processing files. My Amiga 3000 system has a Firecracker 24-bit display card (FC24 by Impulse), Art Department Professional (ADPRo by ASDG), Imagemaster (by Black Belt Systems), and Directory Opus (DOpus by INOVATronics). If you have a Firecracker board and either ADPro or Imagemaster, you may find my IFF24 viewer to be just what you need when you are in a hurry to see a 24-bit picture. If you also have Directory Opus, it's even easier, as you simply select a file and click on a gadget. We'll view IFF24 images on the Firecracker board using either ADPro or Imagemaster as the vehicle. You may launch the routines from a shell or you can highlight an IFF24 file in DOPus and then click on a gadget to view the picture. The automatic viewer in Directory Opus doesn't work with IFF24 files; and the "showiff24" program that comes with the FC24 board doesn't work properly if you use the Amiga Display overlay mode and two monitors. When you try to turn off the Amiga overlay with an "aoff" command, the display snaps to the wrong aspect. I wrote the routines so I can quickly show someone any IFF24 file on my RGB monitor. (The programs work on regular IFF files, too.) They start up ADPro or Imagemaster with that picture loaded and displayed on the Firecracker. The IFF24 viewers save time and tedium. I generate 24-bit IFF pictures in VistaPro (by Virtual Reality Laboratories), Scenery Animator (by Natural Graphics), DCTV (by Digital Creations), and Light24 (by Impulse). I alter and process these images in ADPro and Imagemaster. I save the IFF24 files in a variety of directories, and even with my best organization, I forget which picture is which. Before I went to 24 bit, I used Imagefinder (by Zardoz) to make little thumbnail pictures of my image directories, but alas, Imagefinder will not work with IFF24 either, so I "rolled my own" IFF24 viewer in ARexx. If you are new to ARexx, these are challenging programs to get you started, and if you are experienced, you may find that they give you ideas for different time saving macros. (Note: Only library names, ARexx port names or addresses, and the names of logical files are case sensitive in ARexx. I use uppercase for ARexx instructions for readability.) IFF24 Viewer Using ADPRo The program ShowIFF24.rexx is meant to launch from Directory Opus or a Shell. In Directory Opus, we need to set up a gadget to run this program. Open the DOpus config window and select "gadget" (or menu if you prefer). Choose an empty gadget, put in a gadget name such as "ShowIFF24" and set the following options. Type in only the string that comes after the ':' as the Function string. 1) Function: rx ShowIFF24.rexx {f} 2) Select "Executable" (not ARexx). 3) Select "Run asynchronously" 4) Leave rest of settings at default. The above settings accomplish several things. The most important is that the {f} in the function string allows us to pick up {as an argument} the path and file name of the first selected file in the active window. That is why it was necessary to make the function an "executable" and not an "ARexx" program. Note that the "executable" is really "rx" and that the actual ARexx program is simply the first "argument" for rx, while the path/filename represented by {f} is the argument for the ARexx program. The program would work if we specified it as "ARexx" in DOpus, but then we couldn't use {f} as a variable, containing the path/filename of the selected file. The {f} option only works with "executables". This demonstrates the correct way to introduce a variable argument into an ARexx routine launched from DOpus. In general, use "ARexx" as the option only when you are writing a DOpus macro (directly controlling DOpus only); and use "executable" when you are writing an interprocess control ARexx program and then launch it using "rx" in the function string. Always use "rx" and "executable" when you want to pass path/filename arguments to an ARexx program. Running it "asynchronously" means that you can still use DOpus after the program starts and before the program exits. If you don't choose this option, then you must wait for the program to finish before you can use DOpus again. Generally, macros should be synchronous and interprocess control (executable program launches) asynchronous. The first few instructions of ShowIFF24.rexx accomplish our set up. OPTIONS RESULTS asks for replies to all commands sent out. PARSE ARG filename is the way we transfer the path/filename represented in the DOpus variable {f}. This is known as "passing arguments", a concept you must be intimate with before you go very far with ARexx. Pretend that we selected a filename "bar.none" in a DOpus directory window called "Sys:foo/". Then {f} picks up the directory and the filename and puts it into a string as "Sys:foo/bar.none" and composes a command line: rx ShowIFF24.rexx "Sys:foo/bar.none" RX is an executable ARexx command utility that launches the ARexx program, ShowIFF24.rexx. The string after ShowIFF.rexx, "Sys:foo/bar.none", is the "argument" to the program. The line in the program PARSE ARG filename takes the argument string "Sys:foo/bar.none" and assigns its string value (its literal contents) to the variable filename. Note that ARexx doesn't require you to "type your variables". They are assigned their "type" at the time of assignment: filename starts out as type "character", a string. If later we put in a line filename=10.25 then suddenly filename becomes type "floating point". This is both a convenience and a liability! If you try for instance to do arithmetic on a string, you will get an error. The next two IF blocks test for a null filename string. The first block is for when the program is used from a Shell window, and prompts for the filename if we forgot to put it in. The second block is in case we do not select a file first in Directory Opus. It puts a message in the top bar, and then exits with a warning flag (which isn't used, but it demonstrates the correct way to set a return code). Next, we CALL an internal function to LOCATE_ADPro. The program skips to the label Locate_ADPro: and continues. Note that we don't need a PROCEDURE instruction, as we aren't building a new symbol table. The program checks with a SHOW() function to see if ADPro's ARexx port does NOT exist. If not, it uses some ADDRESS COMMAND instructions to launch ADPro, and a WAITFORPORT command to wait until the port comes on line before proceeding, as loading a big program like ADPro takes a few seconds. This block of instructions is a good template for code that checks to see if some program is running or not. If all goes well, this internal function RETURNs a 1 for true, ADPro is running. After the CALL gets a 1 RETURNed, it CALLs another internal function called MAKEIMAGE, otherwise (a 0 comes back) it exits with return code of 20. Assuming we safely CALL MAKEIMAGE, we pass it an argument, filename. The program skips to the label MAKEIMAGE: which is a PROCEDURE with a protected internal symbol table. The first thing to do is to PARSE ARG filename exactly as we did in the main program. This "program within a program" shares the same format as the main program. Note that this internal filename variable is completely different from the one in the main program, however, because it is protected by PROCEDURE. Now we ADDRESS 'ADPro', to make 'ADPro' the current host address--the address to which we send commands. 'ADPro' is case sensitive, hence the quotes. ARexx automatically makes strings UPPER case unless you quote them. The rest of the commands are internal to ADPro: we bring its screen to the front; change the LoadFORMAT to IFF, LOAD the file represented by the symbol token filename (a "symbol token" is a "variable" in ARexx-speak). Then ADPro performs an OPERATOR to DEFINE_PIXEL_ASPECT. This is the way ADPro gets information on the picture file. We simply need the image width and height, w and h. In the ADPro ARexx interface, ADPro_RESULT is a symbol token assigned the value of the RESULT string coming back from a command's operation. We directly PARSE VARiable ADPRO_RESULT and use periods (.) as placeholders because we don't care to use or assign the data in the other places. (See Page 344 of the ADPro Manual.) In other words, there are six values returned by the operator, and we are concerned with the 5th (w) and the 6th (h) only. So what is the last period for? This period forces "parsing by tokenization", which is a fancy way of saying, "All surrounding blanks are stripped off the values of the variables w and h." Beginners, parsing is not a trivial subject and we don't have space to explain its details here. For further reading, consult my book The ARexx Cookbook, Chapter Three, and you will soon be an expert at parsing. We use ADPRo's ability to put up a requester (page 378 of the ADPro 2.0 Manual) if it needs information, and we do that next, in case the picture width does not match one of the Firecracker's set widths. Note the logical operator &. Note the loop backwards to re-test input before proceeding. We use the ARexx SIGNAL instruction, which acts like a GO TO statement. This is a correct use of SIGNAL. You will get into trouble if you abuse SIGNAL as an escape from sloppy logic, however. We set up the SaveFORMAT to the FC24 and proceed to save the image we have loaded. The information w and h are used to set the width and height of the FC24. The first "SAVE" turns on the FC24 and/or CLEARS any image on it. We could have used one huge line for these SAVE instructions, but its easier to do several, to set up and then IMAGE. Note the proper way to continue an ARexx line with a comma. You generally don't need to continue a line except for publication or readabliity. The narrow columns of this magazine have made me an expert at line continuation. Breaking a line correctly is not always obvious, particularly if you are in the midst of a complex command string. Finally the program goes to the back or quits according to which line you "comment out" or leave in. The Same IFF24 Viewer Using Imagemaster The same process is easier to implement (but runs slower) using Imagemaster. ShowIFF24IM.rexx shows how. We start off much the same, and parse the filename. This time, however, we need to split the directory path off from the filename, because that's the kind of information Imagemaster is looking for, so we have two arguments this time, filepath and filename. If filepath is the null string, then we use some prompts and some compound symbol tokens (arrays) to handle our path strings. We use parsing on a pattern because we know that all valid paths will contain one colon (:) and the directories will be delimited by slashes '/'. The code shows the constructs for tearing down a string into an array and then building it up again. When tearing it down, the symbol token device stands for the system device name, and the compound symbols path.j for j=1,2,... are the directories (the strings in between the /'s). After we've torn apart the path/filename, we know that the last increment is the filename itself, so we build up the string again except for the last increment, and this becomes the path name. The last increment becomes the filename. Note that pattern parsing removes the pattern itself from the parse string, so during reconstruction, we add these characters back to the string using concatenation characters ||. We are planning to run from Directory Opus a little differently this time, and open an output (Shell) window on the WorkBench. We are also going to use separate path and file arguments directly from DOpus. In case we forgot to select a file name, we are not going to exit, but prompt the user for a filename in the source window. We should look at our DOpus set up now. If you're using a shell, then skip ahead. In Directory Opus, set the config screen as follows: 1) Function: rx ShowIFF24IM.rexx {s} {o} 2) Select "Executable" (not ARexx). 3) Select "Run asynchronously" 4) Select Close delay = "-1" (The user closes the window.) 5) Select "Output window" 6) Select "Workbench to front" 7) Leave other setting on default. The {s} argument is the source (active) directory path string and the {o} argument is the filename string without its directory path attached. Once these arguments are passed to the program, the Imagemaster commands are simpler than the ADPro commands. We merely need to bring Imagemaster to the front, set the image path, and load the file. An optional AOFF command will turn off the Amiga display on the picture, but so will a mouse click. If you use AOFF, the overlay stays off; and if not, you may toggle it. The last program is a very small utility A.rexx run from the shell, to find the addresses for all ports. I'm including it because I have yet to find in the Imagemaster documentation the name ('IM_Port') of the Imagemaster ARexx Port! It's often easier and far safer to find the port of a new program directly rather than trust the manual which may be outdated or even incorrect. Also, your version of Imagemaster may use a different port name. Now you have a way to view IFF24 files on your Firecracker by selecting and clicking in Directory Opus, and using either ADPro or Imagemaster to do it. File Formats and Captions for pictures File: Cats.24 Format: IFF24 "'Russian Blues' is a 24-bit painting done in DCTV. I have a limited edition of 11x14 custom printed photographic blowups at $55.00 each, postage paid." File: IMconfig.pic Format: IFF, 8 color, 640x200 hi-res/non-lace "The Directory Opus Config screen showing the settings to make for ShowIFF24IM.rexx which views IFF24 images in Imagemaster."