Let us begin with a description of the record layouts used. The record layouts and code examples are in a variated pascal pseudo code, and should be transferrable enough to implement in most other programming languages. For ease of reading, the examples assume that the file is correct and that no error- checking need be included. How rigorous you check for errors is completely up to you, and will most likely depend on the file type you are describing.
A File with SAUCE added to it, will look like this:
| File Data | Actual file data as it would be without SAUCE. |
| EOF Marker | End Of File marker. This will assure character files like ANSi files (the main reason why SAUCE was made) can easily determine the end of the file. |
| SAUCE Comment block | Optional SAUCE comment block. |
| SAUCE Record | The SAUCE record. |
The SAUCE record describes the file in short, and provides other information not included in the SAUCE record itself. A sauce record is EXACTLY 128 bytes in size.
| FieldName | Size | Type | Version | Description |
| ID | 5 | Character | 00 | SAUCE identification. This should be equal to 'SAUCE' or the record is not a valid SAUCE record. |
| SAUCE Version | 2 | Character | 00 | Version number of SAUCE. Current version is '00'. As new features are added to the specifications of SAUCE, this version may change. Future versions SHOULD remain compatible with version 00, adding to the specifications only. It is however not unlikely that this compatibility is impossible to maintain. |
| Title | 35 | Character | 00 | Title of the file |
| Author | 20 | Character | 00 | Name or 'handle' of the creator of the file. |
| Group | 20 | Character | 00 | Name of the group/company the creator is employed by. |
| Date | 8 | Character | 00 | Date the file was created. This date is in the format CCYYMMDD (century, year, month, day). |
| FileSize | 4 | Long | 00 | Original filesize NOT including any information of SAUCE. |
| DateType | 1 | Byte | 00 | Type of data. See Datatypes. |
| FileType | 1 | Byte | 00 | Type of file. See Filetypes. |
| TInfo1 | 2 | Word | 00 | Numeric information field 1 (See Datatypes). When used, this field holds informative values. Any program using SAUCE should NOT rely on these values being correct or filled in. |
| TInfo2 | 2 | Word | 00 | Numeric information field 2 (See Datatypes). |
| TInfo3 | 2 | Word | 00 | Numeric information field 3 (See Datatypes). |
| TInfo4 | 2 | Word | 00 | Numeric information field 4 (See Datatypes). |
| Comments | 1 | Byte | 00 | Number of comment lines (See Comments ) |
| Flags | 1 | Byte | 00 | Flags indicating optional settings/switches. These flags have different meaning depending on the datatypes & filetypes. |
| Filler | 22 | Byte | 00 | Padding bytes to make record 128 in size. All bytes should be binary zero. |
An example PASCAL record looks like this:
TYPE SAUCERec = RECORD
ID :
Array[1..5] of Char;
Version :
Array[1..2] of Char;
Title :
Array[1..35] of Char;
Author :
Array[1..20] of Char;
Group :
Array[1..20] of Char;
Date :
Array[1..8] of Char;
FileSize :
Longint;
DataType :
Byte;
FileType :
Byte;
TInfo1 :
Word;
TInfo2 :
Word;
TInfo3 :
Word;
TInfo4 :
Word;
Comments :
Byte;
Flags :
Byte;
Filler :
Array[1..22] of Char;
END;
An Example C record looks like this:
typedef SAUCEREC {
char ID[5];
char Version[2];
char Title[35];
char Author[20];
char Group[20];
char Date[8];
signed long FileSize;
unsigned char DataType;
unsigned char FileType;
unsigned short TInfo1;
unsigned short TInfo2;
unsigned short TInfo3;
unsigned short TInfo4;
unsigned char Comments;
unsigned char Flags;
char Filler[22];
} SAUCEREC;
Datatype and filetype hold the information needed to determine what type of file it is. There are currently 9 DataTypes, these are (with their respective numeric values) :
Given a certain datatype, a file can be classified even further. The following is a list of all the currently defined filetypes for each datatype.
When using the 'None' datatype, you should have FileType set to zero also. This is a compatibility issue as it's not unlikely, the 'None' datatype will have filetypes in the future.
When using the 'Character' datatype, you have following filetypes available :
Flags for the Character datatype.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | A |
A) Non-Blink mode (iCE Color). When this bit is SET (equal to 1) The
ANSi is created using iCE color codes. This is a special mode where the
blinking is disabled, and you have 16 background colors available. Basically,
you have the same choice for background colors as for foreground colors.
Please note: When the picture does not make specific use of the iCE color,
you should NOT have this bit set. When you do not support the iCE color
mode, you should probably not display the file as it could look pretty
weird in normal mode
| WARNING: Adding SAUCE to some of the graphic file formats will make them invalid. |
For all graphics types :
Following Graphics filetypes are available :
Flags for the graphics datatype:
Not used, should be all zeroes.
| WARNING: Adding SAUCE to some of the vector file formats will make them invalid. |
Following Vector filetypes are available :
Flags for the vector datatype
Not used, should be all zeroes.
| WARNING: Adding SAUCE to some of the sound file formats will make them invalid. |
Following sound filetypes are available :
Flags for the sound datatype
Not used, should be all zeroes.
The binary text format, basically has no Filetype, since the datatype has already defined how the file will look. The filetype however specifies the width of the binary text screen. Only the width is required, as the height can be calculated by dividing the filesize by the width. In an attempt to provide as much width as possible in a possible 256 values of the byte-sized filetype. The width is specified in multiples of 2. The fact that the width is specified in multiples of 2 isn't really a problem, since you also need to define the effective screen size in multiples of 2.
An example : For normal 80*25 binary images as made with TheDraw the filetype value would be 40 (since 2*40 equals 80). All you need to do is divide the width of the binary text image by 2. This gives a maximum width of 510 characters. Although currently not supported, should there be a need for even bigger images, this can be arranged.
Please note. BinaryText expects the character-attribute pairs to be stored one row at a time. If you wanted to create a 80*100 Image, you could do this by just copying 4 80*25 or 2 80*50 together to form one bigger image. If for example you wanted to create a 160*25 image from 2 80*25 images, you would need to write a little program which would copy line 1 from image 1, line 1 from image 2, Line 2 from Image 1, Line 2 from Image 2 and so on. Basically, you should have all character-attribute pairs from one line of the complete image one after the other, followed by all char-attribute pairs from the next row, and so on. If the picture does not fit this format. You should use the None datatype. Besides, you'd probably want to have it in this format anyway, as it seems to be the most logical approach to have these kind of images.
Flags for the BinaryText datatype.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | A |
A) Non-Blink mode (iCE Color). This bit has exactly the same meaning as for the Character datatype. It indicates whether the picture uses iCE color or not.
The XBin datatype has no other filetypes. Further specifications on the XBin format are available in the XBin archive or on the XBin web-page. The filetype should be zero. TInfo1 holds width of the image, TInfo2 holds the Height of the image. Flags are not used
| WARNING: Adding SAUCE to some of the archive file formats will make them invalid. |
Following archive filetypes are available :
Flags for the sound datatype
Not used, should be all zeroes.
| WARNING: Adding SAUCE to some of the archive file formats will make them invalid. |
The executable datatype has no other filetypes. Executables usually have any of the following file extentions : BAT, COM, EXE, OVL, OVR, DLL, ... The filetype and flags should be zero.
The comment block is an addition to the SAUCE record. It holds up to 255 lines of additional information. Each line 64 characters wide. When the Comments field (in the SAUCE record) is not zero, it holds the number of additional comment lines available. A single comment line is 64 characters long. Like the character fields in the SAUCE record, it is padded with spaces, and has no leading length byte or trailing null-byte. The comment block is preceded with a 5 character identification mark. This identification mark is 'COMNT'.
| ID ('COMNT') | Comment block identification bytes. |
| Comment Line 1 | First comment line. |
| Comment Line 2 | Second comment line |
| ... | |
| Comment Line X | X-th comment line, X equals the Comments field in the SAUCE record |
Variables:
Byte : Count;
Long : FileSize;
file : F;
Code:
Open_File(F); |
Open the file for read access
FileSize = Size_of_file(F); |
Determine filesize
Seek_file (F, FileSize-128); |
Seek to start of SAUCE (Eof-128)
Read_File (F, SAUCE); |
Read the SAUCE record
IF SAUCE.ID="SAUCE" THEN |
ID bytes match "SAUCE" ?
IF SAUCE.Comments>0 THEN |
Is there a comment block ?
Seek_File(F, FileSize-128-(SAUCE.Comments*64)-5);
| Seek to start of Comment block.
Read_File(F, CommentID); |
Read Comment ID.
IF CommentID="COMNT"
THEN | Comment ID matches "COMNT"
?
For
Count=1 to SAUCE.Comments | \ Read all comment lines.
Read_File(F,
CommentLine) | /
ENDFOR
ELSE
Invalid_Comment;
|
Non fatal, No comment present.
ENDIF
ENDIF
ELSE
Invalid_SAUCE; | No valid SAUCE record
was found.
ENDIF
You can also download a fully working implementation for SAUCE extraction as a Turbo Pascal unit. The extraction code itself is implemented in built-in Assembly. It should be fairly easy to port the sourcecode to C. Download SAUCE_.PAS.
If you have a need for additional information on SAUCE, or want to see some modifications, you can email me at Tasmaniac@acid.org
This page is being maintained by
Tasmaniac@acid.org