TIFILES format - Revision history

Mizapf: /* Format deviations */

2019-03-28T21:02:22Z

Format deviations

← Older revision		Revision as of 21:02, 28 March 2019
Line 146:		Line 146:
	The unused part until 0x7f is padded with spaces (0x20), but has also been seen padded with other bytes. TELCO fills these bytes up to 0x7f with 0xca53.		The unused part until 0x7f is padded with spaces (0x20), but has also been seen padded with other bytes. TELCO fills these bytes up to 0x7f with 0xca53.

	== Format ~~deviations~~ ==		== Format variants ==

	* '''No filename''': Some programs like TELCO create incomplete TIFILES headers, omitting everything starting at byte 0x10 (filename). In that case, the filename must be manually set, especially when transferring to a TI-99 system.		* '''No filename''': Some programs like TELCO create incomplete TIFILES headers, omitting everything starting at byte 0x10 (filename). In that case, the filename must be manually set, especially when transferring to a TI-99 system. The Classic99 emulator uses the PC file name, not the name in the file name field.

	* '''Multiple files''': The first byte may be set to 0x08 for multi-file transfer using MXT YModem. Single files should only have 0x07 as the first byte. In that case, the MXT field is set to 0 if this is the last file in the file sequence, and non-null if there are more files.		* '''Multiple files''': The first byte may be set to 0x08 for multi-file transfer using MXT YModem. Single files should only have 0x07 as the first byte. In that case, the MXT field is set to 0 if this is the last file in the file sequence, and non-null if there are more files.

Mizapf: /* File name conventions */

2019-03-28T20:59:38Z

File name conventions

← Older revision		Revision as of 20:59, 28 March 2019
Line 11:		Line 11:
	== File name conventions ==		== File name conventions ==

	~~Currently there~~ is no real agreement on file names. In most cases, files that are stored in TIFILES format have a suffix like ".ARC" or ".ARK" to indicate that they were packed with [[Archiver]]. This has nothing to do with TIFILES, but most external files are packages anyway, and there is no other format for exporting but TIFILES.		There is no real agreement on file names. In most cases, files that are stored in TIFILES format have a suffix like ".ARC" or ".ARK" to indicate that they were packed with [[Archiver]]. This has nothing to do with TIFILES, but most external files are packages anyway, and there is no other format for exporting but TIFILES.

	~~However, with the increasing use of PC software like emulators, there should be a convention to properly indicate the format~~. ~~One suggestion is that files containing data in TIFILES format should have the extension '''tifile''', '''tifiles''', or '''~~tfi~~'''. The file name may be equal to the TI file name, lowercase or uppercase, or give an indication how to process the file on the TI system, like applying~~ a ~~dearchiving program~~.		TIImageTool uses ".tfi" as a default suffix.

	~~Examples: ''assm1~~.~~tifile''~~, ~~''MyLetter.tifile'', ''EDIT1.tifile'', ''telco.arc3.tfi''~~.		The Classic99 emulator uses the TIFILES format to access files and makes use of the PC file name. Accordingly, it does not make use of a specific file name suffix.

	== File structure ==		== File structure ==

Stefan Haubenthal at 17:49, 30 April 2018

2018-04-30T17:49:57Z

← Older revision		Revision as of 17:49, 30 April 2018
Line 154:		Line 154:
	* '''File length''': The file may show a total length which is not 128 plus a multiple of 256. In that case, the last sector is incomplete and assumed to be padded with zeros.		* '''File length''': The file may show a total length which is not 128 plus a multiple of 256. In that case, the last sector is incomplete and assumed to be padded with zeros.

	[[Category:Format]]		[[Category:File Format]]

Stefan Haubenthal: Category

2018-04-30T17:43:55Z

Mizapf: /* File structure */

2016-07-31T23:05:21Z

File structure

← Older revision		Revision as of 23:05, 31 July 2016
Line 26:		Line 26:
	! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7		! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7
	\|-		\|-
	\| 0x00 \|\| 0x07 \|\| ~~colspan="7" style="font-family:monospace; font-weight:bold; letter-spacing:1em"~~ \| ~~TIFILES~~		\| 0x00 \|\| 0x07 \|\| T \|\| I \|\| F \|\| I \|\| L \|\| E \|\| S
	\|-		\|-
	\| 0x08		\| 0x08

Stephen Shaw: /* File structure */ further minor change to link- added needed dash

2015-04-20T17:46:23Z

File structure: further minor change to link- added needed dash

← Older revision		Revision as of 17:46, 20 April 2015
Line 30:		Line 30:
	\| 0x08		\| 0x08
	\| colspan="2"\| Total number of sectors		\| colspan="2"\| Total number of sectors
	\| Flags \|\| #Rec/sect \|\| EOF offset \|\| Rec length \|\| colspan="2" \|[[#Level 3 records]]		\| Flags \|\| #Rec/sect \|\| EOF offset \|\| Rec length \|\| colspan="2" \|[[#Level-3 records]]
	\|-		\|-
	\| 0x10		\| 0x10

Stephen Shaw: /* File structure */ minor change to make link to Level 3 records work

2015-04-20T17:45:28Z

File structure: minor change to make link to Level 3 records work

← Older revision		Revision as of 17:45, 20 April 2015
Line 30:		Line 30:
	\| 0x08		\| 0x08
	\| colspan="2"\| Total number of sectors		\| colspan="2"\| Total number of sectors
	\| Flags \|\| #Rec/sect \|\| EOF offset \|\| Rec length \|\| colspan="2" \|#[[Level 3 records]]		\| Flags \|\| #Rec/sect \|\| EOF offset \|\| Rec length \|\| colspan="2" \|[[#Level 3 records]]
	\|-		\|-
	\| 0x10		\| 0x10

Stephen Shaw: /* The Flags field */ remove generic links leading to nowhere. Article can be clarified in the body if required.

2014-11-15T15:45:20Z

The Flags field: remove generic links leading to nowhere. Article can be clarified in the body if required.

← Older revision		Revision as of 15:45, 15 November 2014
Line 80:		Line 80:
	\|-		\|-
	\| 0		\| 0
	\| [[FIXED]]		\| FIXED
	\| rowspan="2" style="background-color:#eeeeee"\| Reserved		\| rowspan="2" style="background-color:#eeeeee"\| Reserved
	\| normal		\| normal
Line 86:		Line 86:
	\| Unprotected		\| Unprotected
	\| rowspan="2" style="background-color:#eeeeee" \| Reserved		\| rowspan="2" style="background-color:#eeeeee" \| Reserved
	\| [[DISPLAY]]		\| DISPLAY
	\| Data		\| Data
	\|-		\|-
	\| 1		\| 1
	\| [[VARIABLE]]		\| VARIABLE
	\| [[Emulate File format\|Emulate File]]		\| [[Emulate File format\|Emulate File]]
	\| Modified		\| Modified
	\| Protected		\| Protected
	\| [[INTERNAL]]		\| INTERNAL
	\| Program		\| Program
	\|}		\|}

Mizapf at 22:08, 12 November 2012

2012-11-12T22:08:25Z

← Older revision		Revision as of 22:08, 12 November 2012
Line 1:		Line 1:
	The TIFILES format is used to encode ~~filed~~ from a TI file system for ~~transport to~~ another system. Most other systems do not know specific file formats. For example, Unix and Windows systems handle all kinds of data files in the same way, leaving the processing up to the application.		== Overview ==

			The TIFILES format is used to encode files from a TI file system for transfer and storage on another system. Most other systems do not know specific file formats. For example, Unix and Windows systems handle all kinds of data files in the same way, leaving the processing up to the application.

			If you were to take a file and send it over to a PC or some other computer via a modem or serial cable it would arrive on the other end but lose some information. It would lose information like what kind of file it is, protection status, how large it is, etc. In order not to lose that information, proper communication programs on the TI prepend (stick on the front) a 128 byte header to the file that captures this information. So now when the file arrives on the other computer it is actaully a little bit larger.

			When the 128 byte header is prepended to the file it becomes a "TIFILES". So by definition, a TIFILES file is a regular file with a 128 byte header. Now if you were to send that same program back to the TI, the 128 byte header gets read so the file is created properly on the TI. Of course, the 128 byte header is removed when it is back on the TI. The 128 byte header is small set of information used to properly rebuild the file once sent back to the TI. If you send a NON-TIFILES file (one without the 128 byte header) to the TI it will get built but more than likely it won't work properly.

	Thus, when files shall be stored on a PC and probably later copied to another TI system, the file format information must be preserved. When the file is downloaded to a TI or Geneve (e.g. using the TELCO program), the file may be reconstructed in its original format.		Thus, when files shall be stored on a PC and probably later copied to another TI system, the file format information must be preserved. When the file is downloaded to a TI or Geneve (e.g. using the TELCO program), the file may be reconstructed in its original format.

Mizapf: /* Total number of sectors and EOF offset */

2011-04-11T15:48:59Z

Total number of sectors and EOF offset

← Older revision		Revision as of 15:48, 11 April 2011
Line 97:		Line 97:

	=== Total number of sectors and EOF offset ===		=== Total number of sectors and EOF offset ===

			The EOF offset is the location in the last sector where we find the EOF marker. Only variable length data files have an EOF marker (0xff). For program files and fixed length files this field points to the first byte after the file contents. If the EOF offset contains 0, the last sector is completely filled with data.

	The length of the complete TIFILE-encoded file is always a multiple of 128. To recreate the actual file length,		The length of the complete TIFILE-encoded file is always a multiple of 128. To recreate the actual file length,

	* the total number of sectors ~~minus 1~~ must be multiplied by 256		* the total number of sectors must be multiplied by 256
	* the EOF ~~offset~~ must be ~~added;~~ if 0~~, 256 is added~~.		* the number of bytes past the EOF marker must be subtracted (if the offset is not 0).

	That is, if the number of sectors is 10 and the EOF offset is 36, the file length is 9*256+36 = 2340. If the EOF offset is zero, we get the full 2560 bytes.		That is, if the number of sectors is 10 and the EOF offset is 36, the file length is (10*256) - (256-36) = 2340. If the EOF offset is zero, we get the full 2560 bytes.

	=== Level-3 records ===		=== Level-3 records ===

← Older revision		Revision as of 17:43, 30 April 2018
Line 153:		Line 153:

	* '''File length''': The file may show a total length which is not 128 plus a multiple of 256. In that case, the last sector is incomplete and assumed to be padded with zeros.		* '''File length''': The file may show a total length which is not 128 plus a multiple of 256. In that case, the last sector is incomplete and assumed to be padded with zeros.

			[[Category:Format]]