Difference between revisions of "FutureOS Header"

From CPCWiki - THE Amstrad CPC encyclopedia!
Jump to: navigation, search
(Created page with "Like in AMSDOS in FutureOS it's possible to store files in two ways: headerless and with a file-header. Headerless files are often files which need to fit into an 16 K...")
 
 
Line 1: Line 1:
Like in [[AMSDOS]] in [[FutureOS]] it's possible to store files in two ways: headerless and with a file-header. Headerless files are often files which need to fit into an 16 KB block, but don't need to be located in a specific RAM block. Applications and Executables normally have a file header. The file-header for FutureOS is strongly expanded compared to Amsdos, but fully compatible. It consists of 128 bytes and contain the following data:
+
[[Image:HERO-HED.JPG|thumb|192px|Example of FutureOS file header]]
 +
Like in [[AMSDOS]] in [[FutureOS]] it's possible to store files in two ways: headerless and with a file-header:
 +
* Headerless files or relocateable files are often files which need to fit exactly into an 16 KB block (f. e. expansion RAM), but don't need to be located in a specific RAM block.
 +
* Applications and Executables normally have a file header.
 +
 
 +
The file-header for FutureOS is strongly expanded compared to Amsdos, but fully compatible. It consists of 128 bytes and contain the following data:
  
 
  Byte(s) ! meaning, function
 
  Byte(s) ! meaning, function
  --------!----------------------------
+
  --------!------------------------------------------------------------------
       00 ! Usernumber of file &00..&FE, &E5 for deleted entry. Don't use &FF!
+
       00 ! Usernumber of file &00-&FE, &E5 for deleted entry. Don't use &FF!
 
  01 - 08 ! Filename (8 bytes) (fill unused char with spaces)
 
  01 - 08 ! Filename (8 bytes) (fill unused char with spaces)
 
  09 - 0B ! Extent (3 bytes) (fill unused char with spaces)
 
  09 - 0B ! Extent (3 bytes) (fill unused char with spaces)
Line 32: Line 37:
 
* Therefore a graphic-icon uses only 4 * 3 * 8 = 96 bytes from the 99. The remaining three bytes can be used freely.
 
* Therefore a graphic-icon uses only 4 * 3 * 8 = 96 bytes from the 99. The remaining three bytes can be used freely.
  
To calculate the checksum just add all bytes from 00 up to and including byte 66 together. The checksum is then placed to bytes 67 and 68, LSB first.
+
 
 +
To calculate the checksum just add all bytes from 00 up to and including byte 66 together. The checksum is then placed to bytes 67 and 68, LSB first. This way there is compatibility to Amsdos.
 +
 
  
 
This is only a summary. All details are in the FutureOS manual, page 41-42.
 
This is only a summary. All details are in the FutureOS manual, page 41-42.

Latest revision as of 12:29, 20 December 2017

Example of FutureOS file header

Like in AMSDOS in FutureOS it's possible to store files in two ways: headerless and with a file-header:

  • Headerless files or relocateable files are often files which need to fit exactly into an 16 KB block (f. e. expansion RAM), but don't need to be located in a specific RAM block.
  • Applications and Executables normally have a file header.

The file-header for FutureOS is strongly expanded compared to Amsdos, but fully compatible. It consists of 128 bytes and contain the following data:

Byte(s) ! meaning, function
--------!------------------------------------------------------------------
     00 ! Usernumber of file &00-&FE, &E5 for deleted entry. Don't use &FF!
01 - 08 ! Filename (8 bytes) (fill unused char with spaces)
09 - 0B ! Extent (3 bytes) (fill unused char with spaces)
0C - 11 ! I00 to I05 (6 bytes) icon-data
     12 ! Filetype: &00 = basic, &02 = binary, &0A = Prowort
        ! Protected files: add &01, example: &01 = protected basic
        ! FutureOS files: add &80, 8. bit is set
     13 ! Horizontal range or X-width for semi-graphic-icon
     14 ! Vertical range or Y-lines for semi-graphic-icon
15 - 16 ! Low, High-byte start/load-address of file LSB first
     17 ! Physical RAM-block of start/load address: &C0, &C4, &C5-&FF
18 - 19 ! Low, High-byte file-length LSB first (first 16 bit)
1A - 1B ! Low, High-byte execution / auto-start-address LSB first, else &0000 if not used
     1C ! Over-byte of file-length ==> file-length up to 16 MB
     1D ! Physical RAM-block of auto-start-address: &C0,&C4,&C5-&FF
1E - 3F ! I06 to I27 (34 bytes) icon-data
40 - 41 ! Repeat of L, H-byte file-length, but NOT USED!
     42 ! Icon-type: text-, graphic- or semi-graphic icon
43 - 44 ! Low, High-byte checksum of this file-header LSB first
45 - 7F ! I28 to I62 (59 bytes) icon-data
  • Such a header contains &63 = 99 byte icon-data.
  • The icon-type-byte (&42) decides which kind of icon the file-header contains. This can be a graphic icon with 4 * 3 or 6 * 2 chars, a semi-graphic-icon or a text-icon.
  • There are four different icon-types. All icons are made for MODE 1 (32 characters, 32 lines usually).
  • If the icon is a text-icon (icon-type is &00), the text can give information about the contents of the file or whatever.
  • A semi-graphic-icon (type &02) contains text in its icon-data too. These chars are displayed as an ASCII-rectangle. The header-bytes &13 and &14 contain the rectangles X and Y range. But X * Y must be < &64. Text and semi-graphic icons can contain all 256 characters. All control codes are displayed as characters. The difference is that the text of a text-icon is displayed as one string, whereas a semigraphic icon is a rectangle made out of characters.
  • The true graphic icons contain only screen mode 1 graphic-data. They can have the format of 2 * 3 (type &01) or 3 * 2 (type &03) characters.
  • Therefore a graphic-icon uses only 4 * 3 * 8 = 96 bytes from the 99. The remaining three bytes can be used freely.


To calculate the checksum just add all bytes from 00 up to and including byte 66 together. The checksum is then placed to bytes 67 and 68, LSB first. This way there is compatibility to Amsdos.


This is only a summary. All details are in the FutureOS manual, page 41-42.