All About SIXELs Chris_F_Chiesa@cup.portal.com 4:24 pm Sep 29, 1990 Well, all, it's been several months since I first agreed to write something about Sixel graphics. Sorry it's taken so long, but that's life when you're a busy computer jockey! :-) (I've actually written another couple of Sixel-generating programs since then, too. How time flies...!) I'm going to try to condense three years' worth of gleanings from manuals, experiments, programming, and other investigations, into one document, while trying to remain coherent. Please bear with me if I don't quite pull it off. Feel free to write me back and ask questions. Having said that, let the ramblings commence! ----- I. GETTING "INTO SIXEL MODE" Putting a device into Sixel interpretation mode is performed, not surprisingly, by means of an escape sequence. The particular escape sequence which tells a terminal (or printer, or Sixel interpretation software!) "sixel information follows," is DCS p1; p2; p3; q ... where DCS is EITHER the eight-bit "Device Control Sequence" character (decimal value 144), OR the two seven-bit characters "Escape, capital P" (Escape having the decimal value 27). "P1, p2," and "p3" are OPTIONAL parameters, separated by semicolons (;) IF they appear at all. The "q" is a literal, lower-case letter Q. There are, of course, no spaces in the sequence; I've used them here for clarity in your reading. The VT340 Programmer's Reference Guide (not the Manual -- I'm referring to the short summary thingie) describes these parameters this way: P1 is the macro parameter. This parameter indicates the pixel aspect ratio used by the application or terminal. The pixel aspect ratio defines the shape of the pixel dots the terminal uses to draw images. For example, a pixel that is twice as high as it is wide has an aspect ratio of 2:1. NOTE: The macro parameter is provided for compatibility with existing Digital software. New applications should set P1 to 0 and use the set raster attributes control, described later in this chapter. P1 Pixel Aspect Ratio (Vertical:Horizontal) Omitted 2:1 0 or 1 5:1 2 3:1 3 or 4 2:1 5 or 6 2:1 7,8, or 9 1:1 P2 selects how the terminal draws the background color. You can 3$ use one of three values. P2 Meaning 0 or 2 Pixel positions specified as 0 are set to the current background color. 1 Pixel positions specified as 0 remain at their current color. P3 is the horizontal grid size parameter. The horizontal grid size is the horizontal distance between two pixel dots. The VT300 ignores this parameter because the horizontal grid size is fixed at 0.0195 cm (0.0075 in). Keep in mind that the above description is somewhat specific to the VT340 graphics terminal; the general idea of "what the parameters represent" is more important than the specifics of how the VT340 happens to do things. (The "default" pixel aspect ratio of the VT340 and VT240, for instance, is 2:1, but for other devices or applications it might be different.) II. GETTING "OUT OF SIXEL MODE" Officially, one exits Sixel interpretation mode by following one's Sixel image data with the sequence ST ... where ST is either the eight-bit "String Terminator" character (ASCII 156 decimal), OR the sequence "Escape, backslash" (ESC \). In practice, for example when using the VT240 terminal, ANY escape sequence or eight-bit control character will cause Sixel interpretation mode to terminate. It's still a good idea to use the recommended sequence, though, in case someday a particular device, or program, depends on it. III. SIXEL DATA REPRESENTATION Now that you know how to put a device, or program, into Sixel interpretation mode, it's time to tell you what Sixel data IS! The word "sixel" actually means six pixels ("six" + "pixel" = "sixel") stacked atop each other, like this: * * * * * * Each pixel in the sixel can be either ON or OFF, in a single color (you'll see how multiple colors are handled, shortly). Each pixel position is assigned a numeric power-of-two value, from 1 at the top to 32 at the bottom; thus, for any given combination of on and off pixels, one can add up the values of the "on" pixels and obtain a unique number in the range 0 to 63 decimal. An offset of 63 decimal is added to this numeric value to obtain an ASCII character in the "printable" range, 63 to 126 decimal, and it is these characters which appear in a "Sixel image file." You can see that the MINIMUM numeric sixel value 0 gives ASCII code 63, the "?" character, and that numeric sixel value 63 gives ASCII code 126, the "~" character. Now you know why Sixel graphics files have so many "?"'s in them! Sixel data display begins at the "upper left corner" of whatever device or imaging area is being used; successive sixels display consecutively from left to right, building up a horizontal six-pixel-high "band" of imagery. You now know all you need to know in order to produce, in Sixel, a single "band" of monochrome graphics. The Sixel graphics format also includes several "control" characters -- in the printable ASCII range, but outside the range of 63-to 126 decimal used for image data -- which allow you to change the position where new Sixels will be displayed, and to set and use a particular "color map. I'll get to these shortly. Before that, though, there's one more thing to say about the ordinary "data" portion of the Sixel format. In the interest of efficiency, the Sixel format implements a run-length encoding scheme. The "!" character is used as a "repeat count introducer." A "!" followed by a string of digit characters "0" through "9," preceding any valid sixel-data character (63 to 126 decimal), causes that sixel to be repeated the number of times represented by the decimal string. For example, seven repetitions of the sixel represented by the letter "A" could be transmitted either as AAAAAAA or, using a repeat count, as !7A Obviously, the latter form is shorter; note that there is a tradeoff at 3 or 4 repetitions of a character: sending "!3A" doesn't gain any advantage over sending "AAA", and sending "!2A" would actually LOSE ground. I usually try to implement some sort of "optimization" of this factor, myself, although I've never run into any Sixel-eating device or program that cared WHICH way any of this was sent to it! (Another interesting side note: when the VT240 is commanded to do a "print screen," in ReGIS graphics mode, the resulting dump is in Sixel. Furthermore, the VT240 never specifies a repeat-count greater than 255: if it wants to send 600 repetitions of the "empty" sixel ("?" character), it will send !255?!255?!90 to "build up to" the full 600. I do not know whether this is a limitation of the Sixel format itself, or whether it's just an internal register-size limitation of the VT240...) IV. SIXEL "CONTROL" CHARACTERS The material presented so far covers the serial interpretation of a single horizontal band of sixels: each consecutive sixel is placed to the right of the last, indefinitely. If image data extends to the right (or down, when we get to that) beyond the physical range of the output device (e.g., a band of more than 640 sixels is sent to a VT240 terminal), data that is "out of range" is NOT displayed. Although I've never seen it described in such terms, one can think of a sixel "cursor" - the position where the NEXT sixel will be displayed, analogous to the usual text cursor. What I've described so far is equivalent to a text stream containing no Carriage Return or Linefeed characters: the "cursor" simply keeps moving "linearly" from left to right. But the Sixel format includes two "cursor repositioning" control characters, one which behaves analogous to a carriage return, and another which behaves like a "carriage return, linefeed" pair. The "-" (hyphen or minus sign) character moves the sixel "cursor" to the "beginning of the next line (or band)" of image data. In short, it acts like a "new line" (*NIX lingo) character or, more precisely, like a CR/LF pair would in text mode. The "$" (dollar sign) character moves the sixel "cursor" to the "beginning of the current (same) line (or band)," analogous to a plain CR in text mode. This allows new sixel data to "overstrike" what has already been displayed, a necessity for rendering multiple-color imagery. (Data of a single color is laid down, then a $ character returns the "cursor" to the left, then data for a new color is laid down "on top of" what's already there.) You now know everything you need in order to produce a monochrome, or single-bitplane, Sixel image. You can enter Sixel mode, format image pixels into sixel text characters, reposition the "Sixel cursor" to build up an image, and exit Sixel mode when you're finished. All there is left to cover is COLOR! Color Sixel graphics operate in "color map" fashion: color-selection sequences in the Sixel data stream tell the output device (or program) which of a set of "color map registers" is to be used to display subsequent data; the CONTENTS OF that color map register determine the color actually used for display of the data. The VT240, for instance, offers four color- map registers designated by the numbers 0 through 3; Sixel data can thus be displayed in four colors (including the background color). I read somewhere that the Sixel format imposes a limit of 256 colors (color map registers 0 through 255), but this seems unnecessary: the nature of the format is such that, with appropriate coding, ANY number of color map registers could be supported. On real devices, it appears (in my experience) that if Sixel data specifies a color register beyond the range available on a particular device, the color map number "wraps around," modulo N, where N is the number of available color map registers. (On the VT240, for instance, colors 0 through 3 are available. If Sixel data specifies color 4, color 0 is used; if color 5 is specified, color 1 is used, and so on.) In the Sixel format, the "#" character is the "color sequence introducer." It is followed by a decimal string (string of digit characters in the range "0" through "9") specifying a color-map register, and optionally by four semicolon-separated color-selection parameters. Without parameters, e.g. #3 the sequence means "USE color-map register" (in this example, "use color- map register 3") to display subsequent sixels. WITH parameters, e.g. #3;1;30;40;50 the sequence means "SET color-map register contents." The meaning of the parameters in the "SET" form of the sequence is as follows: Designating the syntax of the sequence as "#n;p1;p2;p3;p4", n = color-map register number to be set p1 = color space to be used: 1 = HLS (Hue, Lightness, Saturation) 2 = RGB (Red, Green, Blue) p2,p3,p4 = color to be used, in the notation specified by p1: HLS: p2 = Hue, as an angle in the range 0 to 360 degrees p3 = Lightness, as a percentage from 0 to 100 p4 = Saturation, as a percentage from 0 to 100 RGB: p2 = Red content, as a percentage from 0 to 100 p3 = Green content, as a percentage from 0 to 100 p4 = Blue content, as a percentage from 0 to 100 A few pointers from my practical experience: 1) On the VT240 at least, color-map numbers as used in Sixel mode appear NOT to bear a fixed relationship to the color-map numbers as used in ReGIS mode. I haven't been able to characterize this, but I CAN say that if I generate a color image in ReGIS graphics, then request a screen dump (which the VT240 performs in Sixel format), then type out that screen dump back to the terminal, the displayed color scheme is often DIFFERENT than the original image: the same COLORS are present, but they are assigned to color MAP REGISTERS in a different order. (If this color-rotated image is then dumped a second time, then this second dumpfile typed out, the colors rotate yet again.) There are also some discrepancies between WHICH color-map registers (as designated in ReGIS) actually receive the particular colors requested in a Sixel data stream. Play with this yourself and see if you can characterize it better than I've been able to; if anyone at DEC reads this who knows the innards of the VT240, I'd be very interested in hearing what the heck goes on. 2) Before you even ask, no, I DON'T know how to convert between "HLS" and "RGB" color representations. So far, I've only made use of the RGB mode in my own programs. 3) Characters outside the recognized range of Sixel data (e.g. characters other than "data" (ASCII 63-126 dec), "#", "!", "-" and "$", are IGNORED if they appear in the Sixel data stream. V. EXAMPLE SIXEL IMAGE Let's look at one very simple Sixel example. Suppose we have a very short Sixel image file that contains the following: Pq #0;2;0;0;0#1;2;100;100;0#2;2;0;100;0 #1~~@@vv@@~~@@~~$ #2??}}GG}}??}}??- #1!14@ \ First we see that the introductory and termination sequences (lines 1 and 6) are in seven-bit form, and that no parameters are explicitly specified in the introductory sequence. (The absence of parameters means that your device, or software, will use its "default" behavior, whatever that is.) Line 2 sets color-map registers 0, 1, and 2, all in RGB notation. Color 0 is set to the RGB triplet (0,0,0) -- BLACK. Color 1 is set to (100,100,0) -- YELLOW. Color 2 is set to (0,100,0) -- GREEN. Color 3 is unspecified, so will retain whatever setting it had previously. Line 3 supplies, first, the command to "use color (map register) 1," then 14 sixels' worth of image data, then the "$" character which causes a "carriage-return" to the beginning of this SAME line -- meaning that the next data will OVERSTRIKE this line's data. Line 4 performs much as did line 3, except that it specifies color 2, and that it ends with the "-" character, meaning that line 5's data will appear on a new line, rather than being overstruck again. Line 5 specifies 14 sixels of value 1 ("@" = ASCII 64; 64 - 63 = 1), by using a repeat-count rather than 14 individual instances of the same character. If you haven't figured it out yet, this image produces a 14-by-7-pixel yellow rectangle with the word "HI" picked out on it in green! On the VT240, with its pixel aspect ratio of 1:2, this rectangle should appear as a SQUARE, if I haven't screwed up somewhere. Like this: .............. ..**..**..**.. ..**..**..**.. . = color 1, yellow ..******..**.. * = color 2, green ..**..**..**.. ..**..**..**.. .............. This should appear on a black background. I'm afraid it'll be almost too small to see on a VT240 or 340, but you should be at least able to tell that it's there... That about does it for the theory end of it; I'll tack on some source code for your enlightenment and edification, and see if it makes sense to you now... ----- EXAMPLE 1 -- VAX FORTRAN. This example is VAX FORTRAN code to generate a single-bitplane (i.e. mono- chrome) Sixel image data file. An array of 800 by 51 bytes is used as a bitplane for drawing; each byte in this array is treated as a SIX-bit rather than EIGHT-bit quantity, so that no bit-shuffling is needed in order to convert the bitmap to Sixel: that is, each byte's two most-significant bits are unused, leaving each byte to contain only valid-Sixel values (0 to 63 decimal) which can be converted DIRECTLY to Sixel. (If all eight bits of each byte were used, the code to convert to Sixel would have to reorganize the bits into length-six units, taking time and effort I didn't feel like expending.) This fact makes the Sixel-output routine almost trivially simple. For the sake of brevity, I've omitted the code which actually generates the image -- sets bits in the IMAGE array -- but I can send it to anyone who would like to see it. I'm afraid the architecture of this example is pretty poor: the Sixel-output routine receives the "bitmap" array not as an explicit argument, but impli- citly through a COMMON block; the explicit argument to the Sixel-output routine is a buffer that isn't used ANYWHERE else in the main program, and could have been declared locally in the subroutine. Looking back now, so long after writing this, I can only assume that with my limited knowledge of FORTRAN I went for "anything that would WORK," rather than for elegance and efficiency. And now the code: C C IMAGE array is the bitmap (800 horizontal pixels by 51x6=306 vertical C pixels) in which the image is "drawn"; if this bitmap were "display C memory" on a microcomputer or VT240 terminal, the image would appear C immediately as the bits were set... C C BUFFER is a contiguous area of storage big enough to hold the longest C Sixel band that could ever be produced from the IMAGE array. C BYTE IMAGE(0:799,0:50) CHARACTER*800 BUFFER C C For obscure reasons, IMAGE is passed to the DUMPBUFFER Sixel-output C subroutine only by virtue of this COMMON block; BUFFER is the explicit C argument to DUMPBUFFER. Weird. C COMMON /SIXEL/ IMAGE C C ***** C * C * IMAGE-GENERATION AND BIT-SETTING CODE WOULD APPEAR HERE. C * OMITTED FOR BREVITY. C * C ***** C C The following call, although it's hardly obvious, causes the contents of C the bitplane array IMAGE to be output to a data file in Sixel format. C CALL DUMPFILE(BUFFER) C STOP END C C---------------------------------------------------------------------- C Finally, what you've all been waiting for: the Sixel output subroutine! C C Note again that A) the argument architecture here is kind of screwy: C BUFFER is passed explicitly, but IMAGE is passed in a COMMON block, C and B) only SIX bits are used of each byte in IMAGE. C C Output goes to a sequential output file whose name is hardcoded as C "SIXEL.DAT". The file is explicitly given a "record length" capable C of containing in ONE record the longest Sixel band the IMAGE array C could possibly give rise to: 800 characters. C SUBROUTINE DUMPFILE(BUFFER) C CHARACTER*1 BUFFER(0:799) C C TC is a "temporary character" I found necessary for moving data from C the IMAGES array to the BUFFER output buffer. C C X and Y are horizontal and vertical indices, respectively, for retrieval C of data from the IMAGE array. C INTEGER*2 TC INTEGER*2 X,Y C BYTE IMAGE(0:799,0:50) C COMMON /SIXEL/ IMAGE C C Create the output file... C OPEN(UNIT=10,FILE='SIXEL.DAT',RECL=800,ORGANIZATION='SEQUENTIAL', * TYPE='UNKNOWN') C C Sixel output starts with the introducer sequence, as documented 'way back C earlier in this posting: C write (10,*) char(27),'P9q' C C For each BAND (horizontal strip of sixels) in the image -- er, bitmap... C do y=0,50 C C ... and for each SIXEL within each band... C do x=0,799 C C ... do the following: C C Grab the sixel value stored at (X,Y) in the array IMAGE; this is raw C sixel data so we have to add 63 decimal to it to get an ASCII code for C the data file: C tc = image(x,y)+63 C C Stick the resulting ASCII code into the buffer C buffer(x) = char(tc) end do C C ... and when all Sixels of a band have been stuffed there, write out C the buffer! C C NOTE that I made NO attempt to optimize this output: no "color" infor- C mation is written, and NO "REPEAT COUNT" information! This leads to a C VERY INEFFICIENT Sixel data file! I didn't feel like implementing these C features at the time I wrote this code, but if YOU implement it I would C appreciate a copy! C write (10,*) (buffer(x), x=0,799),'-' end do C C Believe it or not, that's all there is to writing the file. A Sixel C data stream ends with the "string terminator" sequence or, in this C case, its seven-bit equivalent: C write (10,*) char(27),'\' close (unit=10) return end ----- EXAMPLE 2 -- AMIGA BASIC. ' (In Amiga BASIC, lines beginning with single quotes (') are COMMENTS.) ' ' The following is a Sixel image viewer written in AmigaBASIC, ' which is Microsoft BASIC with Amiga extensions. It should be ' trivial to port this to the PC, by replacing Amiga-specific ' statements (e.g. MOUSE, SCREEN, and WINDOW) with the equiva- ' lent PC-environment statements. I'll point out statements ' that do particular things, but won't go into detail about what ' they do in the Amiga environment. ' ' This program has been VERY heavily commented for this presentation, ' with the result that it may be almost impossible to read. I suggest ' you edit out all comment-only lines if you just want to read CODE... ' INPUT "File to display: ",fil$ MOUSE OFF ON MOUSE GOSUB quit MOUSE ON OPEN fil$ FOR INPUT AS #1 ' fil$ = fil$ + " -- Left-Click to exit!" ' ' Set up a four-color graphics screen/window ' SCREEN 1,640,240,2,2 WINDOW 2,fil$,,0,1 ' ' Set default colors, corresponding to the VT240 ' immediately after reset ' PALETTE 0,0,0,0 ' color 0 = black PALETTE 1,0,0,1 ' color 1 = blue PALETTE 2,1,0,0 ' color 2 = red PALETTE 3,0,1,0 ' color 3 = green ' ' This version of the program, as-is, will override ' the default colors above if it finds RGB color- ' specification data in the Sixel file. If you want ' an intermediate stage where you, the user, can ' "manually" specify colors, un-comment the following ' section of code. ' 'WINDOW 3,"color setup",(300,20)-(600,80),0,1 'WINDOW OUTPUT 3 'PRINT "Color range = 0 to 100" 'FOR k = 0 TO 3 ' PRINT "Color ";k; : INPUT " (R,G,B) ";r,g,b ' PALETTE k,r/100,g/100,b/100 'NEXT k 'WINDOW CLOSE 3 ' WINDOW OUTPUT 2 ' '==== ' The Sixel-interpretation process can be considered as ' a series of general operations repeated over and over: ' - read a data stream, ignoring record/line boundaries. ' While there is data, do the following. ' - Wait for the Sixel introducer sequence; after ' you have seen it, read the rest of the data ' stream, acting as follows while doing so: ' - if you encounter a Sixel control character -- ' "$" => carriage-return-like ' "-" => newline-like ' "!" => numeric "repeat-count" follows ' "#" => color USE or SET command follows ' ";" => one command-parameter is ended, and ' another follows ' -- perform the defined control operation ' - if you encounter a valid Sixel data character, ' convert it to pixels and plot them in the current ' color at the current position ' - if a character is invalid or out of range, ignore ' it. '==== ' ' Here's where Sixel interpretation starts! I'll note the ' use of variables where they first occur. ' ' X and Y represent the horizontal and vertical position where ' the uppermost pixel of the next sixel (stack of six pixels) will ' be plotted, measured in PIXELS. Since the VT240 begins displaying ' Sixel graphics in its upper left corner, so do we: initialize X and ' Y both to 0. ' x=0 y=0 ' sixelprocess: ' ' The string SIX$ and the index PT are used by the subroutine GETCHAR to ' transparently ignore record/line boundaries in the Sixel input file. ' More on that below... ' pt = 1 six$ = "" ' ' This first data-fetch primes the pump for the main loop. ' GOSUB GETCHAR ' ' C is the number of the color to be used for setting pixels. I don't ' recall just what the VT240 does, but I default to color 1 here. ' c=1 ' ' REPEAT is the "repeat count" used by Sixel to achieve a sort of run- ' length encoding for data-compression. ' repeat = 1 ' ' The following ten statements comprise the main program loop! ' xloop: ' ' I should actually recode this to ignore characters UNTIL an ' ESC P (or DCS) q is seen; for now, the file should START ' with the 7-bit form of the Sixel introducer sequence. When ' the initial ESC is seen, we ignore everything until the ' terminating "q". ' ' BYTE is the character most recently returned by the GETCHAR subroutine. ' IF byte = 27 THEN GOSUB header ' ' If the data is "out of range" for Sixel, ignore it and repeat the loop. ' IF byte < 33 OR byte > 126 THEN GOSUB GETCHAR: GOTO xloop ' ' Since this is the "outermost" level of interpretation, a semicolon is ' not valid here, so we ignore it. ' IF char$ = ";" THEN GOSUB GETCHAR : GOTO xloop ' ' The "#" character indicates color specification or selection to follow, ' so we go into a a subroutine to handle it. Every subroutine invoked ' like this must invoke GETCHAR at least once beyond the data it handles, ' so that the next character will kbe available at this level. ' IF char$ = "#" THEN GOSUB processcolor : GOTO xloop ' ' In exactly the same manner, the "!" indicates that we must go process ' a repeat-count specification. ' IF char$ = "!" THEN GOSUB getrepeat : GOTO xloop ' ' The "-" character says "reposition to the beginning of the NEXT line..." ' IF char$ = "-" THEN GOSUB linefeed : GOTO xloop ' ' The "$" character says "reposition to the beginning of the CURRENT line" ' IF char$ = "$" THEN GOSUB carret : GOTO xloop ' ' If the character is neither "out of range," "out of context," nor a ' "control" character, it must be data -- so we go plot it! ' GOSUB plotbyte GOTO xloop ' '==== ' The rest of the program consists of support routines. '==== ' plotbyte: ' ' This routine plots the current sixel data as a stack of six pixels ' repeated as many times as the immediately preceding repeat-count says, ' or just ONCE if NO repeat-count preceded the data. ' '--- ' First, remove the +63 "bias" that shifts Sixel data into the ' printable character range... this turns the byte into raw binary data. ' byte = byte - 63 ' ' In BASIC, we have to painstakingly loop-and-shift to pick bits out ' of the data byte; this would be easier in almost ANY other language. ' FOR offset = 5 TO 0 STEP -1 ' ' If the high bit was clear, we don't have to set anything and can ' skip some processing ' byte = byte * 2 IF byte < 64 THEN GOTO ploop ' ' The high bit was SET, so we chop it off to prepare for the next iter- ' ation of the loop ' byte = byte - 64 ' ' A pixel multiplied by a repeat-count equals a LINE; note that the Y ' coordinate of the LOWERMOST pixel is offset by the loop counter, so ' that the bits end up stacked. (You could exchange X and Y in this ' program, and display Sixel data SIDEWAYS! Other variations are just ' as easy...) ' LINE(x,y+offset)-(x+repeat-1,y+offset),c ploop: NEXT offset ' ' Horizontal position must advance by the number of pixels just drawn ' x=x+repeat ' ' The repeat-count applies only to the Sixel character immediately ' following it, so we reset it to 1 after using it. ' repeat = 1 ' ' As mentioned in the main loop comments, each subroutine called from ' there must read one character BEYOND what it uses. ' GOSUB GETCHAR RETURN ' '==== ' header: ' ' This routine waits for the Sixel introducer sequence. ' This is pretty naive, but it works. It relies on the ' assumption that we already KNOW we are dealing with a ' Sixel data file, and it just waits til the Sixel intro- ' ducer sequence termination character ("q") is seen. ' GOSUB GETCHAR IF char$ <> "q" THEN GOTO header GOSUB GETCHAR RETURN ' '==== ' processcolor: ' ' This procedure processes the two varieties of color control ' command sequence. ' cloop: ' ' The GETNUM procedure is a jacket routine that comes in ' handy: it calls GETCHAR repeatedly when a numeric string ' is expected, returning the numeric value in NN and the ' first non-numeric character in BYTE. ' ' Here, we're getting the first parameter after the "#" ' control character, which represents "color number:" ' GOSUB getnum c = nn ' ' Just like the VT240, we treat our colors "MODULO 4" ' WHILE c>3 c = c-4 WEND ' ' The "#" character can introduce a color SPECIFICATION or ' color SELECTION command. The former has multiple para- ' meters, the latter does not, so we can tell which is ' which by whether or not we see a parameter separator ' (semicolon (;) ). ' IF char$ = ";" THEN ' ' Arguments mean this is a command to SET the color. ' GOSUB getnum ' Param. 1 ==> color space (RGB or HLS) colorspace = nn ' GOSUB getnum ' Param. 2 ==> RED (channel 1) value chan1 = nn GOSUB getnum ' Param. 3 ==> GREEN (channel 2) value chan2 = nn GOSUB getnum ' Param. 4 ==> BLUE (channel 3) value chan3 = nn ' ' COLORSPACE will be either 1 for HLS, or 2 for RGB. The Amiga, ' fortunately, operates directly in RGB. Ideally, there would be ' code in the "ELSE" clause here to convert HLS to RGB, but I ' don't know how to do it! If anyone reading this knows how, write ' me at Chris_F_Chiesa@cup.portal.com and explain it to me. ' IF colorspace=2 THEN ' ' Comment out the PALETTE statement here to disable interpretation of ' color information fro the sixel file. Useful if file info is WRONG. ' PALETTE c,chan1/100,chan2/100,chan3/100 END IF END IF RETURN ' '==== ' getrepeat: ' ' This procedure reads the numeric string following a "repeat count ' introducer" character ("!"), and converts it to the numeric value of ' REPEAT for use in the PLOTBYTE routine. ' ' R$ is a starter string that we can fall back on if the repeat-count ' turns up damaged or missing ' r$ = "0" ' ' Tack characters onto the end of CHAR$, which is the ASCII string ' form of the character returned by GETCHAR, until we hit a non- ' numeric character which terminates the read. (I apparently wrote ' this routine before implementing the GETNUM routine, and never ' converted it to use GETNUM.) ' gloop: GOSUB GETCHAR n$ = char$ IF n$>="0" AND n$<="9" THEN r$=r$+n$ : GOTO gloop ' ' Once we have a numeric string, BASIC makes it easy to convert it to ' a truly numeric value... ' repeat = VAL(r$) ' ' If no numeric characters were seen, or if the repeat-count was ' specified as 0, we assume it should really be 1. ' IF repeat = 0 THEN repeat = 1 RETURN linefeed: ' ' This procedure performs a "graphic linefeed" -- repositions us to ' the "beginning of the next Sixel band." Simple - just hack X and Y. ' x=0 y=y+6 ' ' I apparently had in mind to disable plotting when I went off the ' bottom of the screen, but I don't think I use this anywhere... ' IF y>ymax THEN plotenable = 0 GOSUB GETCHAR RETURN ' '==== ' carret: ' ' This procedure performs a "graphic carriage-return" -- repositions us ' to the "beginning of the current Sixel band." Simple - just hack X. ' Note that the "plot enable" flag shows up here too! ' x=0 : IF y<= ymax THEN plotenable=1 GOSUB GETCHAR RETURN getnum: ' ' Read a number from the string data stream ' n$ = "" ' return numeric string value n$, nn = 0 ' numeric value nn, & terminator char$/byte GOSUB GETCHAR ' get new "char$" and "byte" WHILE char$ <= "9" AND char$ >= "0" n$ = n$ + char$ GOSUB GETCHAR WEND IF n$ <> "" THEN nn = VAL(n$) RETURN GETCHAR: ' ' Read a character from the string data stream ' ' Have we run out of data in the most-recently-read record/line? ' IF pt > LEN(six$) THEN ' ' Yes: reset the index and try to read another line -- ' pt = 1 IF EOF(1) THEN ' -- unless we're at end of file GOTO done ELSE six$="" ' ' If NOT at end-of-file, read until we get a non-empty record. ' WHILE LEN(six$)<1 INPUT #1,six$ WEND END IF END IF ' ' We get here with valid data at position PT in string SIX$. ' char$= MID$(six$,pt,1) ' Extract ASCII character, byte = ASC(char$) ' return it also as an integer pt = pt+1 ' and advance the index ' RETURN PRINT "This should never be printed!" ' ' The origins of the following tidbits are lost in the mists of ' time... ' done: CLOSE #1 ' waitpt: SLEEP GOTO waitpt ' ' We come here when the left mouse button is pressed, closing ' and shutting stuff down. ' quit: PRINT "Closing!" WINDOW CLOSE 2 SCREEN CLOSE 1 ' END /* ---------- */