Synchronet v3.19b-Win32 (install) has been released (Jan-2022).

You can donate to the Synchronet project using PayPal.

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
ref:xbin [2018/02/02 19:22] – [History] Added screen shot examples of XBimages digital manref:xbin [2020/05/28 19:33] (current) – [XBin] .bin files usually contain CP437 chars digital man
Line 1: Line 1:
 ====== XBin ====== ====== XBin ======
  
-XBin (''.xb'') is an ANSI/block art file format created by Tasmaniac of [[http://www.acid.org|ACiD]]. The main "image data" portion of the file is identical in format to that of a BIN (''.bin'') file: an IBM CGA text mode memory dump consisting of pairs of 8-bit character (e.g. alphanumeric or symbolic/graphic) data accompanied by 8-bit attribute (e.g. color) data.+XBin (''.xb'') is an ANSI/block art file format created by Tasmaniac of [[http://www.acid.org|ACiD]]. The main "image data" portion of the file is identical in format to that of a "Binary Text" (''.bin'') file: an IBM CGA text mode memory dump consisting of pairs of 8-bit character (e.g. CP437 alphanumeric or symbolic/graphic) data accompanied by 8-bit attribute (e.g. color) data.
  
 In addition to the "image data", the file may optionally contain: In addition to the "image data", the file may optionally contain:
   - A custom color palette definition   - A custom color palette definition
   - One or two font (character set) definitions   - One or two font (character set) definitions
 +
 +===== Examples =====
 +==== CT-XBIN.XB ====
 +{{:ref:xbin.png?400|An ACiD XBin demonstration file (CT-XBIN.XB) displayed in SyncTERM v1.1b}}
 +
 +==== The same file displayed without embedded font or palette data ====
 +{{:ref:xbin_without_font_or_palette.png?400|Does your terminal display XBin's like this?}}
 +
 +==== cx-unnamed.xb ====
 +{{:ref:unnamed.png?400|A spectacular XBin demonstration displayed in SyncTERM v1.1b (in development)}}
 +
 +==== tcf - 22 - amidala.XB ====
 +{{:ref:amidala.png?400|Another outrageous example of the art possible through the XBin format}}
  
 ===== Fonts ===== ===== Fonts =====
Line 12: Line 25:
 When one or more fonts are specified in the file, the file becomes tied to a specific //character height// (or what they call "FontSize" in the XBin specs). Meaning, the viewer must be using a display mode which matches the character height in the file or else the font(s) cannot be used during the display and the file likely will not appear as intended. When one or more fonts are specified in the file, the file becomes tied to a specific //character height// (or what they call "FontSize" in the XBin specs). Meaning, the viewer must be using a display mode which matches the character height in the file or else the font(s) cannot be used during the display and the file likely will not appear as intended.
  
-For example, in the typical 80x25 video mode, an 8x16 character (font) is used. While in 80x43 video mode, an 8x8 character is used. So a character height of 16 pixels is most common with character heights of 8 pixels and 14 pixels being less common, but still included in the IBM CGA/EGA/VGA display standard text modes.+For example, in the typical 80x25 VGA video mode, an 8x16 character (font) is used. While in the 80x43 EGA/VGA video mode, an 8x8 character is used. So a character height of 16 pixels is most common, while character heights of 8 pixels and 14 pixels are less common, but still included in the IBM CGA/EGA/VGA display standard text modes.
  
 There is no provision in the XBin file format for a single file to apply to multiple character heights (video modes). There is no provision in the XBin file format for a single file to apply to multiple character heights (video modes).
Line 34: Line 47:
  
 ==== History ==== ==== History ====
- 
-{{:xbin_sync_disks.png?400|}} 
-{{:xbin_einstein.png?400|}} 
-{{:xbin_marilyn.png?400|}} 
-{{:xbin_starman.png?400|}} 
- 
  
 While experimenting with SyncTERM's loadable fonts feature (see [[config:fonts.ini]] for more details), I decided to try converting some VGA-resolution monochrome images into BIN-like files along with custom fonts which replicate the original image's pixel pattern and loading and activating the fonts in SyncTERM while displaying a character matrix using those fonts to reproduce the original bitmap image. While experimenting with SyncTERM's loadable fonts feature (see [[config:fonts.ini]] for more details), I decided to try converting some VGA-resolution monochrome images into BIN-like files along with custom fonts which replicate the original image's pixel pattern and loading and activating the fonts in SyncTERM while displaying a character matrix using those fonts to reproduce the original bitmap image.
Line 45: Line 52:
 SyncTERM supports up to **4 active fonts** simultaneously (selected by the 4 possible combinations of bits 3 and 7 of each displayed character's attribute byte). And depending on the size and complexity of the original image and the target character height, 1-4 custom fonts might be needed to replicate the original bitmap image (and in some cases, 4 fonts isn't even enough). SyncTERM supports up to **4 active fonts** simultaneously (selected by the 4 possible combinations of bits 3 and 7 of each displayed character's attribute byte). And depending on the size and complexity of the original image and the target character height, 1-4 custom fonts might be needed to replicate the original bitmap image (and in some cases, 4 fonts isn't even enough).
  
-In any case, initial experiments using an ad hoc file format were encouraging. I was using SAUCE fields for most of the additional data needed (character height, number of fonts, etc.) and basic BIN file format with additional data defining the font characters/glyphs. At the same time I was discussing the possibility of custom palette definitions with [[person:Deuce]] (the BBS could dynamically control the SyncTERM display palette), so I was considering adding that as well.+In any case, initial experiments using an ad hoc file format were encouraging. I was using SAUCE fields for most of the additional data needed (character height, number of fonts, etc.) and the basic BIN file format with additional data defining the font characters/glyphs. At the same time I was discussing the possibility of custom palette definitions with [[person:Deuce]] (the BBS could dynamically control the SyncTERM display palette), so I was considering adding an alternate/custom palette to the file format as well.
  
-I don't like reinventing the wheel, so I looked through the existing BIN file format variants (Artworx/ADF, IceDraw/IDF, etc.) and the only format which supported multiple custom font definitions was: XBin. XBin also supports a custom palette definition, so that was a plus as well.+I don't like reinventing wheels, so I looked through the existing "Binary Text" file format variants (Artworx/ADF, IceDraw/IDF, etc.) and the only format which supported multiple custom font definitions was: XBin. XBin also supports a custom palette definition, so that was a plus as well.
  
 However, XBin only supports a maximum of 2 fonts (the so-called "512 char" mode detailed earlier). Some of my experimental XBin images required more than 2 custom font definitions (especially in 8-pixel character height video modes), even 4 custom fonts could be required at times. However, XBin only supports a maximum of 2 fonts (the so-called "512 char" mode detailed earlier). Some of my experimental XBin images required more than 2 custom font definitions (especially in 8-pixel character height video modes), even 4 custom fonts could be required at times.
  
-So rather than create another file format that many useful software tools may never full support, I decided to move forward using XBin but add the functionality that I needed for my "XBin Image" demonstration project.+So rather than create yet another file format that many useful software tools may never fully support, I decided to move forward using the XBin format, but add the functionality that I needed for my XBin Image ("XBimage") [[ftp://vert.synchro.net/main/bbs/xbimgs01.zip|demonstration project]]: 
 + 
 +{{:ref:xbin_sync_disks_bright.png?400|}} 
 +{{:xbin_einstein.png?400|}} 
 +{{:ref:xbin_marilyn_bright.png?400|}} 
 +{{:xbin_starman.png?400|}} 
  
 ==== Fonts ==== ==== Fonts ====
Line 63: Line 76:
 ==== Illegal Characters ==== ==== Illegal Characters ====
  
-Although still defined in the font sets (256 character definitions each), the following characters must never be used in the //Image Data// to avoid problems with terminal programs that treat byte received with these ASCII values with special meaning:+Although still defined in the font sets (256 character definitions each), the following characters must **never** be used as character values in the //Image Data// to avoid problems with terminal programs that treat bytes received with these ASCII values, specially:
   - 0 (NUL)   - 0 (NUL)
   - 7 (BEL)   - 7 (BEL)
Line 85: Line 98:
 The usage of the low 5 bits (0-4) remains unchanged from the original XBin definition, so long as the upper most 3 bits (5-7) are set to ''0''. One exception: bit 4 may now be set independently of bit 1. The usage of the low 5 bits (0-4) remains unchanged from the original XBin definition, so long as the upper most 3 bits (5-7) are set to ''0''. One exception: bit 4 may now be set independently of bit 1.
  
-I renamed the ''512chars'' bit position to ''HighFont'' because its being set does not necessarily mean that there are 512 character definitions (2 font sets of 256 glyphs) - there may be more or fewer than 2 font sets when this flag is set.+I renamed the //512chars// flag to //HighFont// because its being set does not necessarily mean that there are 512 character definitions (2 font sets of 256 glyphs) - there may now be more or //fewer// than 2 font sets when this flag is set.
  
-In the original XBin definition, bit 4 (//512Chars//) should not have be set without the //Font// flag (bit 1) also being set. In the extended definition, you may have a custom font definition **only** for the characters with the high-intensity attribute flag set, without having to include a font set for the normal-intensity characters. i.e. These 2 Flags are now independent of each other.+In the original XBin definition, the //512Chars// flag (bit 4) should not have be set without the //Font// flag (bit 1) //also// being set. In the extended definition, you may have a custom font definition **only** for the characters with the high-intensity attribute flag set, without having to include a font set for the normal-intensity characters. i.e. These 2 Flags are now independent of each other.
  
-The //Font// flag was re-defined as //NormalFont// since it being set indicates that a font set for the normal-attribute characters has  been included in the file and the //512Chars// flag has been redefined as //HighFont// since its being set indicates that a custom high-intensity font definition has been included in the file. Additionally, these 2 flags are now independent: you may have the //HighFont// flag set without the //NormaFont// flag being set.+The //Font// flag was re-defined as //NormalFont// since its being set only indicates that a font set for the //normal-attribute// characters has  been included in the file.
  
 === New Flags === === New Flags ===
Line 95: Line 108:
 The originally //unused// flags (bit positions 5 and 6) have been redefined to indicate the presence of font definitions for the normal-intensity-blinking (//BlinkFont//) characters and/or the high-intensity-blinking characters (//HighBlinkFont//). The originally //unused// flags (bit positions 5 and 6) have been redefined to indicate the presence of font definitions for the normal-intensity-blinking (//BlinkFont//) characters and/or the high-intensity-blinking characters (//HighBlinkFont//).
  
-The originally //unused// flag (bit position 7) is now redefined (as //NonHigh//) to indicate that the high-intensity attribute flag (bit 3) in the //Image Data// should **not** be used to select the color for the character cell (presumably, the attribute flag is being used to select the font set instead and the desired color is expressed only in the low 3 bits of each character's attribute value).+The originally //unused// flag (bit position 7) is now redefined (as //NonHigh//) to indicate that the high-intensity attribute flag (bit 3) in the //Image Data// should **not** be used to select the color for the character cell (presumably, the attribute flag is being used to select the font set instead and the effective desired color of the character is expressed **only** in the low 3 bits of each character's attribute value).
  
 === Parsing === === Parsing ===
Line 101: Line 114:
 In the extended Xbin definition you have from 0 (none) to 4 (the maximum) custom font definitions included in the file. Each font definition's size is the character height multiplied by 256 bytes (e.g. a 16 pixel character height means 4096 bytes per font definition as 16 * 256 = 4096). In the extended Xbin definition you have from 0 (none) to 4 (the maximum) custom font definitions included in the file. Each font definition's size is the character height multiplied by 256 bytes (e.g. a 16 pixel character height means 4096 bytes per font definition as 16 * 256 = 4096).
  
-To determine the total number of font definitions included in the file (following the optional //Palette// and preceding any //Image Data//), you must count number of set bits from the //Flags// field from the set of bit positions: 1, 4, 5 and 6. If all 4 of these Flags are set, then there are 4 font definitions included in the file. If none of them are set, then there are no font definitions included in the file.+To determine the total number of font definitions included in the file (following the optional //Palette// and preceding any //Image Data//), you must count the number of set bits from the //Flags// field from the set of bit positions: 1, 4, 5 and 6. If all 4 of these Flags are set, then there are 4 font definitions included in the file. If none of them are set, there are no font definitions included in the file.
  
 == Font Priority == == Font Priority ==
  
-So now that we know the number of font definitions, we need to determine **which** font definition (character set) is to be applied to which character attribute combinations. When there are **multiple font sets** included in the file, the priority order of the font definitions is thus:+So now that we know the number of font definitions based on the //Flags// field, we need to determine **which** font definition (character set) is to be applied to which character attribute combinations. When there are **multiple font sets** included in the file, the priority order of the font definitions is thus (from lowest file offset to highest):
  
   - BlinkFont   - BlinkFont
Line 112: Line 125:
   - HighFont   - HighFont
  
-So if, for example, flags 6 (HighBlinkFont) and 1 (NormalFont) are set, and the other 2 Font flags are unset/OFF, then the first font definition would be for the HighBlinkFont and the second/last font definition would be for the NormalFont.+So if, for example, flags 6 (//HighBlinkFont//) and 1 (//NormalFont//) are set, and the other 2 Font flags are unset/OFF, then the first font definition would be for the //HighBlinkFont// and the second/last font definition would be for the //NormalFont//.
  
 ===== See Also ===== ===== See Also =====
   * [[https://web.archive.org/web/20120212201856/http://www.acid.org/info/xbin/xbin.htm|Archived copy of The Official XBIN Homepage]]   * [[https://web.archive.org/web/20120212201856/http://www.acid.org/info/xbin/xbin.htm|Archived copy of The Official XBIN Homepage]]
   * [[module:xbimage]]   * [[module:xbimage]]
 +  * [[ftp://vert.synchro.net/main/BBS/xbimgs01.zip|XBimages Demo Pack #1]]
   * [[:ref:|Reference Library]]   * [[:ref:|Reference Library]]
  
-{{tag>ansi syncterm sauce}}+{{tag>ansi syncterm sauce xbin graphics fonts}}
  

Trace: