Difference between revisions of "TI Disk format"

From Ninerpedia
Jump to navigation Jump to search
(Major article on the data layout on a 90k TI disk)
 
m (link File System and Basic program under heading TI Disk Format)
 
Line 1: Line 1:
This article shows how the data is actually stored on an original TI SSSD 90k disk.
See [[File systems]] for details of


==Detailed description of disc format==
the Floppy Disk File System
A single sided diskette used with the T.I. Disc Controller has the following specifications:
*Volume Information Block
*File Descriptor Index Record
*File Descriptor Records
*Allocation Bit Map
 
and the Hard Disk File System
*Volume Information Block (HFDC)
*Volume Information Block (SCSI)
*Directory Descriptor Records
*File Descriptor Index Records
*File Descriptor Records
*Allocation Bit Map
 
 
 
Detailed description of disc format
 
A single sided single density 90k  diskette used with the T.I. Disc Controller has the following specifications:
* Diskette type: SA 104 (ANSI standard 5.25")
* Diskette type: SA 104 (ANSI standard 5.25")
* Encoding method: FM single density
* Encoding method: FM single density
Line 11: Line 28:
* Sectors per track: 9 sectors
* Sectors per track: 9 sectors


==Volume information block (VIB), sector 0==
This block contains disc configuration data as required by the disc software. This includes available number of AUs (Allocation Units), Volume name, format information etc. Included in this block is the "Allocation Bit Map":
The allocation bit map is used to indicate to the disc software the availability of individual sectors on the disc. A "1" indicates that the sector associated with that "bit" has been allocated, and a "0" that the sector is available for use. The first bit in the map is for sector 0, the second for sector 1 and so forth. When the disc is initialised (with VERIFY = YES if using DM1000 or similar), then the bits for bad AUs are set to "1" along with the bits for non-existant AUs and the 2 system reserved AUs. All the remaining bits are of course set to zero.
{| class="wikitable" style="max-width: 50em"
|-
! byte (in hex)    !! item !! item  !! byte
|-
| 0      || colspan="2" rowspan="5" | DISK VOLUME NAME bytes 0-9
The volume name can be any combination of ten ASCII characters except for space, ‘.’ or NULL. It is space filled to the right, and must have at least one non-space character.
|                                                  1
|-
| 2      || 3
|-
| 4      || 5
|-
| 6      || 7
|-
| 8      || 9
|-
| >A      || colspan="2" |    Total number of allocation units (2 bytes)  || >B
|-
| >C      ||  SECTORS PER TRACK    ||        'D'        || >D
|-
| >E    || 'S'            ||        'K'      || >F
|-
| >10      || PROTECTION            || NUMBER OF TRACKS PER SIDE    || >11
|-
| >12      || QTY FORMATTED SIDES.  ||        DENSITY    || >13
|-
| >14 to >36 || colspan="2" | RESERVED AREA || >15 to >37
|-
| >38 to >FE || colspan="2" | ALLOCATION BIT MAP || >39 to >FF
|}
NOTES:
Bytes >A to >B show the total number of allocation units on the volume. This information should match the Allocation Bit Map data.
Bytes >D to >F contain the ASCII letters 'DSK'. These letters are checked by the T.I. disc managers to see if the disc has been initialised.
Byte >10 Contains the ASCII 'P' if the disc is Proprietary Protected. This byte will normally otherwise be an ASCII space.
Bytes >12 to >37 are reserved for what were intended to be future expansion. This could be date and time of creation etc. The T.I. controller will set all these to zero.
Bytes >3B to >FF contain the allocation bit map. The map can control up to 1600 256-byte sectors (=400K bytes) - this will allow double sided, double density diskettes without modification to the map layout.
Each bit in the map represents one sector on the disc. A logical one in the bit map means that the corresponding sector has been allocated, a logical aero means that the sector is available for use.
The Volume name can be used as an alternative to the drive name - that is to say the user can specify a disk drive in either of the following ways:
DSK.volname.filename or DSKl.filename
If the volume name is specified, then the system will look at each drive in sequence until it finds the specified volume. If more than one drive contains a volume with that name, then the lowest drive number will be assigned.
==File descriptor index record (sector 1)==
This sector contains up to 127 two-byte entries. Each of these points to a File Descriptor Record, and are alphabetically sorted according to the file name in the File Descriptor Record. The list starts at the beginning of the block, and ends with a zero entry.
As the file descriptors are alphabetically sorted, a binary search can be used to find any given filename. This limits the maximum number of searches to 7 if more than 63 files are defined. Generally if between 2**(n-1) and 2**n files are defined, a file search will take at the most N disc searches. To obtain faster directory response times, data blocks are normally allocated in the area above sector 222, the area below this being used for file descriptors and only used for file data when there are no more sectors available above >22.
==File Descriptor Records==
The File Descriptor Record (FDR) contains the general information for its associated file. In order for the system to function, all the information to access and update the file must be contained within this record.
Layout of an FDR is as follows:
{| class="wikitable" style="max-width: 50em"
|-
! byte (in hex)    !! item !! item  !! byte
|-
| 0      || colspan="2" rowspan="5" | FILE NAME
The file name can be up to ten characters in length.
|                                                  1
|-
| 2      || 3
|-
| 4      || 5
|-
| 6      || 7
|-
| 8      || 9
|-
| >A      || colspan="2" |    Reserved  || >B
|-
| >C      ||  File status flags    ||  Number records per AU      || >D
|-
| >E    || colspan="2" | Number of Level 2 records currently allocated || >F
|-
| >10      || End of file offset  || Logical record size    || >11
|-
| >12      || colspan="2" |  Number of Level 3 records currently allocated    || >13
|-
| >14 to >1A || colspan="2" | RESERVED  || >15 to >1B
|-
| >1C to >FE || colspan="2" | ALLOCATION BIT MAP || >1D to >FF
|}
Bytes >A and >B were reserved for an extension of the number of data chain pointers. As this was never implemented, these bytes are always 0.
Byte >C The file status flags are as follows, where Bit O is the LSB:
{| class="wikitable" style="max-width: 50em"
|-
! Bit Number:    !! item !! item 
|-
| 0      || File Type Indicator || 0= Data file
|-
|    ||    ||  1= Program file
|-
| 1 || Data Type Indicator || 0= ASCII (DISplay file)
|-
|  ||  || 1= Binary (INTernal or PROGRAM)
|-
| 2 || colspan="2" | This bit was reserved for expansion of the data type indicator.
|-
| 3 || Protect Flag || 0 =NOT protected
|-
|  ||  ||  1 =Protected
|-
| 4,5,6 || colspan="2" | Reserved for expansion
|-
| 7 || Fixed / Variable flag || 0 =Fixed Length Records
|-
|  ||  ||  1=Variable length records
|-
| >E and >F || colspan="2" | The number of 256 byte records allocated on level 2.
|-
| >10 || colspan="2" | Contains the EOF offset within the highest physical AU for variable length records and program files.
|-
| >11 ||  colspan="2" | Contains the logical record size in bytes. For variable length records this byte contains the          maximum permissible record size.
|-
| >12 and >13 || colspan="2" | Contain the number of records allocated on level 3. For variable length records these bytes    will contain the number of level 2 records actually used. NOTE: these bytes are in the reverse order.
|-
| >14 to 1B || colspan="2" | These bytes were reserved for future expansion, and will always be O.
|-
| >1C to >FF || colspan="2" | Contain blocks of three bytes which indicate the clusters which have been allocated for the file. 12 bits of each 3 byte block indicate the address of the first AU in the cluster, and the remaining l2 bits indicate the highest logical record offset in the cluster of contiguous records (This method of indication reduces the computation required for relative record file access).
|}
The layout of the data within the 3 byte blocks in >1C to >FF is shown below:
    Byte 1                Byte 2            Byte 3
  ------------            ----------      ------------
|  A2 | A1 |            | L1 | A3 |      | L3  | L2 |
  -----------+            ---------        ----------
Where A3 = AU's times >lO0        L3 = offset times >lOO
      A2 = AU’s times >1O        L2 = offset times >1O
      A1 = AU’s times 1          L1 = offset times 1
==Allocation for data files==
A Data file is built of clusters of contiguous data records, each date file can contain up to 76 of these data record clusters, with each cluster containing at least one data record. The DSR software will allocate as many contiguous records as possible upon request, - if a new record is requested and no more records can be added to the current cluster, then a new cluster of contiguous records is started. If 76 clusters have been allocated and a new cluster is requested then the write operation will be aborted. This will only occur when the data records on the disc have become too scattered (i.e. the file is badly segmented) - the problem can be corrected by copying the disc with the disc manager (or with DMIOOO in file mode), which will cause the records for the files to be allocated in l (or at the most 2) clusters on the new disc. Note that at worst case this scheme still allows for 19k bytes per file (76 * 256 bytes).
Because of the system used, each physical record within the file can be accessed at random, without any need for large areas of contiguous disc space. This means that so long as the logical records within a file have a fixed length, the file can be accessed either at random or sequentially, and therefore the disc software does not have to distinguish between relative record and sequential files. This has some implication for sequential fixed length record access, as now the record number is being used, rather than the current record number and offset.
For variable length records, the length of the logical record is stored at the start of the record itself. The result of this is that (since a record cannot cross an AU sector boundary), the maximum record length for variable length records is limited to 254 bytes, as the 'end of records on this sector' (>FF) has to be written too.
==Program file allocation==
Program file allocation is identical to data file allocation. The Program file (segment) is split into 256 byte records which are stored as a standard data file. As the disc software marks the file as a program file it can prevent data access to program files (and vice versa).
In order to prevent problems with VDP ram 'wrap round' (i.e. continuing to write to VDP ram after address >3FFF will write to >0000) the DSR software notes the actual number of bytes used in the last data record and will return exactly as many bytes as were originally written to the disc, even though this may not be a multiple of 256.
==Level 1, 2 and 3==
Above you will see references to Level 2 and Level 3.
The Device Service Routine (DSR) ROM in the 99/4a Disk peripheral is designed to give the user access to the disk by means of a system using three different 'levels', which, with the addition of some utility routines gives the user complete access to a normally formatted disk without the need for any knowledge as to how the actual disk controller works.
Each level uses those features implemented at a lower level to add new features, (a sort of 'building block' system).
===LEVEL 1 features===
* Communication with the FD1771 chip
* Record read/write functions
* Disk formatting functions
* Soft error corrections
This level is the only level which must know precisely what the disc hardware is. This allows higher levels to be independent of both the controller chip type, and the rest of the disc controller hardware.
Each of the higher levels sees the disc simply as a linear storage device, addressed by disc unit-number, a physical record number, and a read or write operation.
If the disc controller chip is changed (such as the Myarc card) then it should only be necessary to replace this part of the software.
All the higher levels are designed to be independent of the actual physical disc structure which this level deals with, except for sector size which is assumed to be 256 bytes. Smaller sector sizes could easily be supported by setting up the sectors in such a way that the total adds up to 256 bytes - for instance, if a sector size of 64 is used, each sector requested from a higher level would take up 4 sectors at level l.
===LEVEL 2 features===
* All level l features plus:
* Creation and deletion of files
* File allocation dynamically extendable
* Data accessed by filename and physical record displacement
* Mixed hybrid file format (see below)
The actual 'file' concept is created at this level, with each file being known by its name and the displacement of the physical record within the file — a physical record being defined as one disc sector (256 bytes).
On each disc is maintained a directory and bit-map of the sectors.  This allows for file and record management (i.e. deletion and creation).
The file format available is called the 'mixed hybrid' format, and is a mixture of contiguous and non—contiguous (fragmented) file formats. A lot of overhead has to be carried by fragmented files in the form of pointers - these pointers are required in case relative access is required to the file and point to each data record of the file.
The files on this level are allocated in 'clusters' of contiguous records in order to combine the advantage of the flexible allocation of non—contiguous files with the low overhead, and the easy access of contiguous files. Whenever new records are requested. the clusters are expanded if possible, if a cluster cannot be expanded then a new one is started.
===LEVEL 3 features===
* All level 2 features, plus:
* Program and data files
* Fixed and variable record formats
* Relative and sequential access
* Internal and ASCII data types
The disc management software is completed by the addition at this level, of the relative/sequential access and the fixed/variable record formats. This level takes care of the 'blocking’ of one or more logical records into a physical record (as with DIS/VAR format), when relative access is required, it computes the physical record in which the logical record is to be found, updates that record and passes the physical record back to the level 2 file update routines.
==Variable, Fixed, Program format==
Variable and Fixed format are really 'variations on a theme', in that, each sector, (or AU), contains as many records of either format as it is possible to write to that sector — without overflowing it (i.e without writing more than 256 bytes).
Program format is used to store an image of the data in memory on the diskette byte for byte, each byte in each sector being used (except for the last sector associated with the particular file, which may not be fully used due to the length of the file not being exactly divisible by 256).
==Sequential access==
When the data records in a file are accessed strictly in the order of increasing address on the medium. each record is said to be 'sequentia1ly' accessed. This is the access method used for accessing such things as magnetic and paper tapes etc, in which all the records up to and including the one required must be read in order to access the particular record required. In this mode of access, the parameters for the data transfer do not specify a physical record number, as it is implied that the logical record currently indicated by some data transfer pointer is the one which is required. Restore/rewind operations are either implicitly done or explicitly done prior to the first data transfer. As each logical record is transferred, the access pointer moves to the first byte of the next logical record (which in the case of this DSR is usually the length indicator).
Sequential access methods have the advantage that variable record lengths can be used (such as the well known "VAR 80") and so the number of records per sector can be increased by an amount dependent on the length of each particular record. For instance, ten 24 byte records could be written on a 256 byte sector, whereas if "FIXED 80" were to be used, then only 3 records (=240 bytes) could be written even though there are still only 24 bytes of usable data per record.
Variable format (sequential access) sectors are recorded on the disc with an extra byte added at the start of each record, and a final byte at the end of the last record of the sector. The first byte of each record indicates the length of the record in bytes, a negative number (usually >FF) indicating that there are no more records on that sector. The action of the computer when reading the sectors from the data buffer in VDP ram is to read the first byte (length of record), then read the required number of bytes as the record from VDP ram to a new location, read the next byte (length of record), etc etc until a negative number is found as the length. At this point another sector is read from the disc to VDP ram and the process repeated again until all the data for the appropriate file has been read.
==Relative (Random) access==
Relative access allows data in a file recorded in fixed format to be accessed by logical record number. The records may be accessed in any order regardless of the order in which they were written or the order in which they appear in the file.
As the DSR software must be able to locate a record solely by its number, relative access can only be supported on either Indexed Files or Fixed Length files. In this DSR, only "Fixed length" files are supported. (Indexed files are files for which an "index" is maintained on the diskette through which a particular record can be located by looking it up in the index.)
==Directory Organisation==
The directory organisation implemented within the DSR supports only a single level directory, that is to say that no FILE can be a directory containing pointers to other files. This means that each file on the disc can be readily identified by a single name, e.g.: DSKl.filename which would specify a file called "filename" on the diskette in drive 1.
This approach to the diskette file organisation prevents access to a catalog file as such on the disc, as no such file can physically exist. In order to overcome this problem, a semi-catalog file can be created by the DSR software and accessed by the user. The file which is created (and remember it is not physically on the disc, so don’t go looking for it with the Disc Manager), is of the Fixed format, relative access type. The file contains 128 records, each containing information about the associated catalog entry and is described in detail below. It can be accessed as: DSK1. or DSK.volname as a standard data file but without a name.


See the BASIC program [[Disk directory reader in BASIC]].
See the BASIC program [[Disk directory reader in BASIC]].

Latest revision as of 21:26, 19 April 2015

See File systems for details of

the Floppy Disk File System

  • Volume Information Block
  • File Descriptor Index Record
  • File Descriptor Records
  • Allocation Bit Map

and the Hard Disk File System

  • Volume Information Block (HFDC)
  • Volume Information Block (SCSI)
  • Directory Descriptor Records
  • File Descriptor Index Records
  • File Descriptor Records
  • Allocation Bit Map


Detailed description of disc format

A single sided single density 90k diskette used with the T.I. Disc Controller has the following specifications:

  • Diskette type: SA 104 (ANSI standard 5.25")
  • Encoding method: FM single density
  • Capacity: 92l6O bytes per disc
  • Track size: 2304 bytes
  • Sector size: 256 bytes
  • Tracks per side: 40 tracks
  • Sectors per track: 9 sectors


See the BASIC program Disk directory reader in BASIC.

Retrieved from "http://www.ninerpedia.org/index.php?title=TI_Disk_format&oldid=49311"