FANGS file extension format specifications v0 Beta Specs
by SiDS
Why another file format?
Recently I have become aware of ACiDs SAUCE Standard Architecture
for Universal Comment Extensions. Unfortunatly, their format was far from
perfect and required the reader to open every file in a directory to find
out if a SAUCE record even exists! Therefore, I put together this format.
FANGS Fast Architecture for Nfo in Gothics Stuff will be
implemented by BLOODVU and I encourage other groups to support this format.
BiTE is currently being coded by The Prince of Thieves and myself and should
be avaible shortly. We also plan to release source code in assist other
developers in its implementation and a SAUCE to FANGS conversion utility to
asist users. There is no need to support a poor format, just because a large
group supports it.
Lets go into more detail about what SAUCE did wrong. As I already
mentioned, SAUCE requires a reader to open a file just to find out if it has
SAUCE. This is clearly visible in ACiDViEW. Go into a directory with a 100+
files within the mask and youll be sitting there for 5 minutes. Another
problem is an unflexable and limited comment format that could never support
variable length lines or an MCi system. Finally, the format of the SAUCE
record is inefficent and too often charactor based. Its faster and smaller
to record numbers as binary. In addition, the original file size could be
easily calculated and with a good tagging system a long ID field is no longer
needed.
However, SAUCE did introduce some ingenious concepts that should be
recognised. These include the basic concept of storing information after the
EOF marker, the basic 128 byte record as the last 128 bytes and their format
for recording file formats and file format information. I have used their
better ideas, but have improved, revised and added enough to justify a
different name. Tasmaniac, still deserves praise for what he did right, it
just needed to be made more functional.
The FANGS tagging system
A file is tagged as having FANGS by having a seconds value in its
time stamp of 62. Since the seconds field of the DOS time stamp supports
values from 0..31 x 2 0..62, this is a valid yet unused value. Because
files are tagged in this manor, programs that support FANGS will not open a
ton of files that dont have FANGS. This dramiticly reduces the amout of
disk access and CPU use.
The Basic FANGS Record and Layout
An EOF marker is used seperate the FANGS from the rest of the file
ASCII 26. After the EOF is the comment section to be explained later.
Then the last 128 bits is the basic FANGS record.
Here is the basic layout:
FILE DATA Regular file data.
EOF MARKER EOF marker. ASCII: 26
COMMENT BLOCK Optional Comment area.
FANGS MFANGS information record
RECORD
The FANGS information record is defined as follows:
all numerical values are unsigned
FieldName Type Description
ID 1 Word Used to verify legitimate FANGS. Value must
be 43690 AAAAh, 1010101010101010b
Version 1 Byte Version number ext. was written with. First ver
should be 0, then 1, etc.
Title 35 Character Title/short description of the file
Author 20 Character Authors Name/Handle
Group 20 Character Group Affilation of the author
Date 4 Byte Date of completion in the format Century, Year,
Month, Day
DataType 1 Byte General Type of Data Explained later
FileType 1 Byte Specific File Type Explained later
Finfo 4 Word Information fields. Definition varies by file type
Comments 1 Word Size of comment area with ID word set to 0 if
there is none
The remaining 34 bytes are reserved for future versions and should be
set to 0.
The Comment Area
The comment area consists of an id word followed by a series of
characters. A CR ASCII 13 should be used to seperate lines. Lines
should be no more than 80 printing charators long.
id word id Word, must be 26985 6969h
COMMENT BLOCK Comment area.
Color Codes
In the comment area colors are changed by a ESC charactor ASCII: 27
followed by a byte in the same format as an atribute byte in video
memory with bit 7 is used for blinking. Because of the cryptic, yet
compact efficent nature of color coders a writer should use a pipe
color system or allow
DataTypes
The DataType field contains a numberical value describing the basic
type of data the file contains. This data is viatal to interputing the
FileType field, and geting format specific information. The following is a
list of data types currently supported:
Name Description
0 Other Used to add FANGS to any datatype not defined below
1 Character Character based file, such as ASCII, ANSi and RIP.
2 Graphix Bitmap graphix file, such as GIF, LBM, and PCX.
3 Vector Vector based graphix file, such as DXF and CAD files.
4 Sound Sound related file, such as samples MOD and MIDI.
5 Executable File that can run independently, such as EXE, demos, intros,
loaders, etc.
FileTypes
Other
When using the Other datatype, the FileType should also be set to 0.
There are currently no filetypes, but they might be added in the future.
Character
0 Other Undefined Charactor data type.
1 ASCII Plain text file with no formatting codes or color codes.
FInfo 1: width of the file
FInfo 2: number of lines
2 ANSi Text file with ANSi color codes and cursor positioning.
FInfo 1: width of the file
FInfo 2: number of screen lines
FInfo 3: use of bit 7 0blinking, 1background.
3 ANSiMation Animation via ANSi codes
FInfo 1: width of the file
FInfo 2: number of screen lines needed
FInfo 3: use of bit 7 0blinking, 1background.
4 RIP Remote Imaging Protocol RIP script file.
FInfo 1: width should be 640
FInfo 2: height should be 350
FInfo 3: bits per pixel should be 4
5 PCBoard Text file with PCBoard @ codes and ANSi codes.
FInfo 1: is used for the width of the file
FInfo 2: number of screen lines
FInfo 3: use of bit 7 0blinking, 1background
6 AVATAR Text file with AVATAR and ANSi codes.
FInfo 1: width of the file
FInfo 2: number of screen lines
FInfo 3: use of bit 7 0blinking, 1background
7 Pipe Text file containing the color codes used by Renegade,
Obv/2, etc.
FInfo 1: width of the file
FInfo 2: number of screen lines
FInfo 3: use of bit 7 0blinking,1background
Graphix
For all graphics types, FInfo 1 holds width of the image, FInfo 2 holds
the Height of the image and FInfo 3 holds the number of bits per pixel
a 256 colour image would have 8 bits per pixel, a TrueColor image
would have 24
0 Other Undefined
1 GIF CompuServ Graphics Interchange format
2 PCX ZSoft Paintbrush PCX format
3 LBM/IFF DeluxePaint LBM/IFF format
4 TGA Targa Truecolor
5 FLI Autodesk FLI animation file
6 FLC Autodesk FLC animation file
7 BMP Windows Bitmap
8 GL Grasp GL Animation
9 DL DL Animation
10 WPG Wordperfect Bitmap
Vector
None of the FInfo fields are currently defined.
0 Other Undefined
1 DXF CAD Data eXchange File
2 DWG AutoCAD Drawing file
3 WPG WordPerfect/DrawPerfect vector graphics
Sound
0 Other Undefined
1 MOD 4, 6 or 8 channel MOD/NST file
2 669 Renaissance 8 channel 669 format
3 STM Future Crew 4 channel ScreamTracker format
4 S3M Future Crew variable channel ScreamTracker3 format
5 MTM Renaissance variable channel MultiTracker Module
6 FAR Farandole composer module
7 ULT UltraTracker module
8 AMF DMP/DSMI Advanced Module Format
9 DMF Delusion Digital Music Format XTracker
10 OKT Oktalyser module
11 ROL AdLib ROL file FM
12 CMF Creative Labs FM
13 MIDI MIDI file
14 SADT SAdT composer FM Module
15 VOC Creative Labs Sample
16 WAV Windows Wave file
17 SMP8 8 Bit Sample, FInfo 1 holds sampling rate
18 SMP8S 8 Bit sample stereo, FInfo 1 holds sampling rate
19 SMP16 16 Bit sample, FInfo 1 holds sampling rate
20 SMP16S 16 Bit sample stereo, FInfo 1 holds sampling rate
Executable
FInfo 1 : if a memory manager, such as QEMM or EMM386 can be present
0 No
1 Yes
2 Must be present
FInfo 2: Required Graphix
0 None
1 Color Text
2 CGA
3 EGA
4 VGA
5 SVGA no VESA support
5 SVGA only VESA supported
6 SVGA VESA and others supported
255 Better than SVGA
Summery
So what have we gained by using FANGS instead of SAUCE?
1 With the use of an unique seconds value in the DOS time stamp
useless disk access and CPU work is reduced without majorly
hacking DOS seconds field isnt shown via the DIR command.
2 A more efficent base record format that has more expansive file types
and has more room for additions 34 bytes vs 23 bytes.
3 A flexable, commpact comment area up to 65,533 characters vs up to
256 lines 64 charactors wide for a max of 16,384 characters that
is capable of supporting an MCi system in the future.
In addition because the two formats are parelell in many aspects, it
shouldnt be hard to write a conversion utility.
Thanx goes out to:
The Prince of Thieves - for working with me on this
Tasmaniac - for the original concept
GOTHiC - Like what you see?
Comments, suggestions, death threats, confessions, need a apathic
shoulder or psycotic reading?
Extreme Prejudice 6O3598-34O3
ex-MAGiC EHQ
CoRRoSioN SiTE
PHART SiTE
C-ya Laid Her,
SiDS
by SiDS
Why another file format?
Recently I have become aware of ACiDs SAUCE Standard Architecture
for Universal Comment Extensions. Unfortunatly, their format was far from
perfect and required the reader to open every file in a directory to find
out if a SAUCE record even exists! Therefore, I put together this format.
FANGS Fast Architecture for Nfo in Gothics Stuff will be
implemented by BLOODVU and I encourage other groups to support this format.
BiTE is currently being coded by The Prince of Thieves and myself and should
be avaible shortly. We also plan to release source code in assist other
developers in its implementation and a SAUCE to FANGS conversion utility to
asist users. There is no need to support a poor format, just because a large
group supports it.
Lets go into more detail about what SAUCE did wrong. As I already
mentioned, SAUCE requires a reader to open a file just to find out if it has
SAUCE. This is clearly visible in ACiDViEW. Go into a directory with a 100+
files within the mask and youll be sitting there for 5 minutes. Another
problem is an unflexable and limited comment format that could never support
variable length lines or an MCi system. Finally, the format of the SAUCE
record is inefficent and too often charactor based. Its faster and smaller
to record numbers as binary. In addition, the original file size could be
easily calculated and with a good tagging system a long ID field is no longer
needed.
However, SAUCE did introduce some ingenious concepts that should be
recognised. These include the basic concept of storing information after the
EOF marker, the basic 128 byte record as the last 128 bytes and their format
for recording file formats and file format information. I have used their
better ideas, but have improved, revised and added enough to justify a
different name. Tasmaniac, still deserves praise for what he did right, it
just needed to be made more functional.
The FANGS tagging system
A file is tagged as having FANGS by having a seconds value in its
time stamp of 62. Since the seconds field of the DOS time stamp supports
values from 0..31 x 2 0..62, this is a valid yet unused value. Because
files are tagged in this manor, programs that support FANGS will not open a
ton of files that dont have FANGS. This dramiticly reduces the amout of
disk access and CPU use.
The Basic FANGS Record and Layout
An EOF marker is used seperate the FANGS from the rest of the file
ASCII 26. After the EOF is the comment section to be explained later.
Then the last 128 bits is the basic FANGS record.
Here is the basic layout:
FILE DATA Regular file data.
EOF MARKER EOF marker. ASCII: 26
COMMENT BLOCK Optional Comment area.
FANGS MFANGS information record
RECORD
The FANGS information record is defined as follows:
all numerical values are unsigned
FieldName Type Description
ID 1 Word Used to verify legitimate FANGS. Value must
be 43690 AAAAh, 1010101010101010b
Version 1 Byte Version number ext. was written with. First ver
should be 0, then 1, etc.
Title 35 Character Title/short description of the file
Author 20 Character Authors Name/Handle
Group 20 Character Group Affilation of the author
Date 4 Byte Date of completion in the format Century, Year,
Month, Day
DataType 1 Byte General Type of Data Explained later
FileType 1 Byte Specific File Type Explained later
Finfo 4 Word Information fields. Definition varies by file type
Comments 1 Word Size of comment area with ID word set to 0 if
there is none
The remaining 34 bytes are reserved for future versions and should be
set to 0.
The Comment Area
The comment area consists of an id word followed by a series of
characters. A CR ASCII 13 should be used to seperate lines. Lines
should be no more than 80 printing charators long.
id word id Word, must be 26985 6969h
COMMENT BLOCK Comment area.
Color Codes
In the comment area colors are changed by a ESC charactor ASCII: 27
followed by a byte in the same format as an atribute byte in video
memory with bit 7 is used for blinking. Because of the cryptic, yet
compact efficent nature of color coders a writer should use a pipe
color system or allow
DataTypes
The DataType field contains a numberical value describing the basic
type of data the file contains. This data is viatal to interputing the
FileType field, and geting format specific information. The following is a
list of data types currently supported:
Name Description
0 Other Used to add FANGS to any datatype not defined below
1 Character Character based file, such as ASCII, ANSi and RIP.
2 Graphix Bitmap graphix file, such as GIF, LBM, and PCX.
3 Vector Vector based graphix file, such as DXF and CAD files.
4 Sound Sound related file, such as samples MOD and MIDI.
5 Executable File that can run independently, such as EXE, demos, intros,
loaders, etc.
FileTypes
Other
When using the Other datatype, the FileType should also be set to 0.
There are currently no filetypes, but they might be added in the future.
Character
0 Other Undefined Charactor data type.
1 ASCII Plain text file with no formatting codes or color codes.
FInfo 1: width of the file
FInfo 2: number of lines
2 ANSi Text file with ANSi color codes and cursor positioning.
FInfo 1: width of the file
FInfo 2: number of screen lines
FInfo 3: use of bit 7 0blinking, 1background.
3 ANSiMation Animation via ANSi codes
FInfo 1: width of the file
FInfo 2: number of screen lines needed
FInfo 3: use of bit 7 0blinking, 1background.
4 RIP Remote Imaging Protocol RIP script file.
FInfo 1: width should be 640
FInfo 2: height should be 350
FInfo 3: bits per pixel should be 4
5 PCBoard Text file with PCBoard @ codes and ANSi codes.
FInfo 1: is used for the width of the file
FInfo 2: number of screen lines
FInfo 3: use of bit 7 0blinking, 1background
6 AVATAR Text file with AVATAR and ANSi codes.
FInfo 1: width of the file
FInfo 2: number of screen lines
FInfo 3: use of bit 7 0blinking, 1background
7 Pipe Text file containing the color codes used by Renegade,
Obv/2, etc.
FInfo 1: width of the file
FInfo 2: number of screen lines
FInfo 3: use of bit 7 0blinking,1background
Graphix
For all graphics types, FInfo 1 holds width of the image, FInfo 2 holds
the Height of the image and FInfo 3 holds the number of bits per pixel
a 256 colour image would have 8 bits per pixel, a TrueColor image
would have 24
0 Other Undefined
1 GIF CompuServ Graphics Interchange format
2 PCX ZSoft Paintbrush PCX format
3 LBM/IFF DeluxePaint LBM/IFF format
4 TGA Targa Truecolor
5 FLI Autodesk FLI animation file
6 FLC Autodesk FLC animation file
7 BMP Windows Bitmap
8 GL Grasp GL Animation
9 DL DL Animation
10 WPG Wordperfect Bitmap
Vector
None of the FInfo fields are currently defined.
0 Other Undefined
1 DXF CAD Data eXchange File
2 DWG AutoCAD Drawing file
3 WPG WordPerfect/DrawPerfect vector graphics
Sound
0 Other Undefined
1 MOD 4, 6 or 8 channel MOD/NST file
2 669 Renaissance 8 channel 669 format
3 STM Future Crew 4 channel ScreamTracker format
4 S3M Future Crew variable channel ScreamTracker3 format
5 MTM Renaissance variable channel MultiTracker Module
6 FAR Farandole composer module
7 ULT UltraTracker module
8 AMF DMP/DSMI Advanced Module Format
9 DMF Delusion Digital Music Format XTracker
10 OKT Oktalyser module
11 ROL AdLib ROL file FM
12 CMF Creative Labs FM
13 MIDI MIDI file
14 SADT SAdT composer FM Module
15 VOC Creative Labs Sample
16 WAV Windows Wave file
17 SMP8 8 Bit Sample, FInfo 1 holds sampling rate
18 SMP8S 8 Bit sample stereo, FInfo 1 holds sampling rate
19 SMP16 16 Bit sample, FInfo 1 holds sampling rate
20 SMP16S 16 Bit sample stereo, FInfo 1 holds sampling rate
Executable
FInfo 1 : if a memory manager, such as QEMM or EMM386 can be present
0 No
1 Yes
2 Must be present
FInfo 2: Required Graphix
0 None
1 Color Text
2 CGA
3 EGA
4 VGA
5 SVGA no VESA support
5 SVGA only VESA supported
6 SVGA VESA and others supported
255 Better than SVGA
Summery
So what have we gained by using FANGS instead of SAUCE?
1 With the use of an unique seconds value in the DOS time stamp
useless disk access and CPU work is reduced without majorly
hacking DOS seconds field isnt shown via the DIR command.
2 A more efficent base record format that has more expansive file types
and has more room for additions 34 bytes vs 23 bytes.
3 A flexable, commpact comment area up to 65,533 characters vs up to
256 lines 64 charactors wide for a max of 16,384 characters that
is capable of supporting an MCi system in the future.
In addition because the two formats are parelell in many aspects, it
shouldnt be hard to write a conversion utility.
Thanx goes out to:
The Prince of Thieves - for working with me on this
Tasmaniac - for the original concept
GOTHiC - Like what you see?
Comments, suggestions, death threats, confessions, need a apathic
shoulder or psycotic reading?
Extreme Prejudice 6O3598-34O3
ex-MAGiC EHQ
CoRRoSioN SiTE
PHART SiTE
C-ya Laid Her,
SiDS
log in to add a comment.