IsDOS?

ZXNet echo conference «real.speccy»

From Sergey Cherbynin To All 24 April 2002

Greetings, All!

* Also sent to ZX.SPECTRUM

An unpleasant incident happened, on the screw in the subject system there was coursework in
text form, and it so happened that I went through the disk with the Create program and
I am now interested in the question, how can I get information out of the screw?
Exhumer and fdir do not help.
I am also interested in 32 byte descriptors of the file and directory, describe
byte by byte what it (byte) is responsible for.
There is an idea to create a text file on this disk and write in its
descriptor the parameters of the killed file and extract it in this way.
Who is doing anything about this.
Also looking for the tt+.key keyboard driver.

All the best, All!
With best wishes *** Sergey ***

From Kirill Frolov To All 24 April 2002

Immediately click on RESET, Sergey!

24 Apr 02 22:17, Sergey Cherbynin wrote to All:

SC> An unpleasant incident happened, on the screw in the subject system there was
SC> coursework in text form, and it so happened that I went through the disk
SC> with the Create program and I am now interested in the question of how to
SC> information pull it out from the screw?

Is it even there? create probably wiped out the entire disk.
Demon look at what's on the disk?

SC> Exhumer and fdir don't help. I’m also interested in the 32-byte
SC> file and directory descriptors, write down byte-by-byte what it (byte)
SC> is responsible for.


Reference sheet on the iS-DOS file system. Version 1.1.

This file is compiled on the basis of widespread information about the iS-DOS system
and based on the analysis of *.img disk images. All kinds of additions and clarifications are welcome. This describes only the old disk structure used in
versions of the system released before 1998; in the new version of the system iS-DOS'98
the disk structure was changed, but I do not have complete information.

At the end there are sources of information, but sometimes they contain errors
and there is simply a lack of information, questions arise that are left unanswered.
There is generally more information here and some errors have been corrected.

The iS-DOS file system can exist on any blockdevice
which can have from 3 to 65535 blocks. The size of one block is always 256
bytes. Blocks are numbered from 0 to maximum. On block 0 of each device
there is a DEVICE DESCRIBER which contains the device size,
description of the physical media, disk name and other system parameters.
The device descriptor also contains the number of the initial block of the main directory.
There is always a main directory on the disk, it cannot be deleted. The main directory
always contains descriptors for two files: a descriptor for the
directory itself with the name "FF-dot" and a disk descriptor, which includes
DEVICE DESCRIBER (0 block) and DISK USE BITMAP (always
starts with 1 block). In the disk occupancy bitmap, each bit represents the occupancy of one device block. The disk descriptor file is always called
device.sys and has all the bits set in the attribute byte - it is an invisible
system directory and cannot be read, written, or deleted, and is
CONTINUOUS (other files may be segmented). After the disk occupancy map, the MAIN DIRECTORY usually begins, which can be segmented or continuous. In any case, its length cannot exceed 16 blocks or
128 file or directory descriptors. It is clear that any file or directory file
always occupies an integer or zero number of blocks.The main directory and the disk occupancy bitmap file cannot have a length of zero.
In addition to the above files, the main directory always contains a boot.sys file
if the DISK IS BOOT. The boot.sys file contains the system loader which loads the is_dos.sys file from the same disk into the computer memory and launches it. All bits in the attribute bytes of the boot.sys file are also
set. To make it easier to find the is_dos.sys file, its descriptor is duplicated in the DEVICE DESCRIBER on block 0. The system file with the system image may have a name different from is_dos.sys, but system utilities require ????_dos.sys. For a boot disk, the is_dos.sys file must be
CONTINUOUS! To boot from floppy disks via TR-DOS, a disk with kilobyte sectors is used. The numbers of sectors used are: 1,2,3,4 and 9.
In sector 9 there are 0 tracks and the boot.sys file is located, 4 blocks long.

The iS-DOS file system for the user is similar to the MS-DOS file system,
from the inside there are significant differences. There is a developed system of subdirectories - each directory can contain subdirectories, which in turn may contain other directories. But the nesting level of directories cannot exceed 6. The main directory has nesting level 0, its subdirectories have level 1... The total number of files or directories in one
directory is limited to128 file descriptors INCLUDING THE DIRECTORY DESCRIBER ITSELF.
Each directory has a descriptor for itself - the very first file descriptor
in the directory having the name of that directory. Files, like directories, can be
contiguous or segmented. Only the files device.sys (device occupancy bit-map) and boot.sys (system bootloader) are always continuous. Some
programs also impose restrictions on the type of files and work only with
continuous or only with segmented ones. Continuous files occupy one continuous area on the disk equal to their length (rounded up to a block) and can be read at high speed. Segmented
files can contain from 0 (a zero-length file) to 85 segments of size from
0 to 255 blocks of 256 bytes, they can take a long time to read,
but it is possible to add or remove blocks from anywhere in the file
(for example, you can insert several blocks in the middle of the file). The file length in its descriptor is limited to 16 MB, and the maximum size of an iS-DOS disk can be the same. But if the file is segmented, then its size is limited to only
5548800 bytes (try multiplying 256 bytes by 255 blocks in 85 segments).
The contiguous file descriptor directly specifies the number of the file's starting block
on disk. A segmented file descriptor points to a block of segment
descriptors,three bytes per segment (starting block number and length), hence
85 segments. For a segmented file of zero length, the block of descriptors
segments is filled with zeros.


CHARACTER ENCODING IN THE NAMES OF FILES, DISKS AND DIRECTORIES.

In the iS-DOS system, for characters with codes 0x00..0x7F, ASCII encoding
of characters is accepted, for characters with codes 0x80..0xFF 866-alternative
encoding accepted. The names of files, disks and directories can use numbers, lowercase and capital letters of the Russian and Latin alphabet, as well as symbols with codes 0x23, 0x24, 0x26, 0x2B, 0x2D, ​​0x3D, 0x5F, 0x60. The remaining characters
cannot be used - this may lead to inaccessibility of files and directories.


DEVICE DESCRIBER STRUCTURE.

Offset from Size Description
beginning of block

0x00 2 reserve
0x02 8 disk name
0x0A 3 0x44, 0x53, 0x4b -- iS-DOS disk attribute.
0x0D 5 reserves
0x12 2 device size in blocks
0x14 2 number of the starting block of the main directory
0x16 1 * number of tracks on the disk
0x17 1 * disk type
0x18 1 * size sectors
0x19 1 * number of sectors on track
0x1A 1reserve
0x1B 1 checksum descriptor ????_dos.sys
0x1C 1 reserve
0x1E 2 device creation date
0x20 0x20 descriptor ????_dos.sys
0x40 0x10 * table of sector numbers on track

Data fields in the device descriptor structure marked with an "*" asterisk are used only for floppy magnetic disks. Fields marked
as "reserve" and the undescribed data area after the table of sector numbers
are not recommended to be used.

The sector size is indicated in blocks and can be 1, 2 or 4 blocks (256, 512 or
1024 bytes, respectively). Only two bits are used in the disk type byte:
bit0=0 40 tracks, otherwise 80, bit1=0 I side, otherwise 2. Sector numbers in the table with offset 0x40 are indicated in the form that TR-DOS understands them, i.e.
reduced by one, in reality they are located in the sector header on the disk values are greater by
one. In the table, the sectors are located in the order in which
they are located on the track. The file descriptor field is_dos.sys contains a copy
of the descriptor of such a file located on disk in some directory (any)
and is only necessary for loading the system image into memory from the boot disk.
The descriptor checksum field is the sum of all 32 bytes of the descriptor
modulo 2(this is XOR).


DISK USE BITMAP STRUCTURE.

The disk busy bitmap file has one bit for each block
of the device. The length of this file is 8 times less than the size of the device in blocks.
If the byte number in the file is designated by the letter F, the bit number by the letter B, and the block number on the device by the letter N, then each bit in the file can be put in
correspondence to the block numbers on the disk using the following formulas:

F = N div 8 and B = 7 - (N mod 8).

The operation div is an integer division, and mod is the remainder of the division.
For occupied blocks, the bits are set, for free blocks they are reset (containing zeros).


STRUCTURE OF THE SEGMENT DESCRIPTOR BLOCK.

In the directory, the segmented file descriptor contains a link not on
the initial block of the file (as in a continuous file), and on the block of descriptors
segments, which determines the location of the files on the disk. The segment descriptor block is one block of the iS-DOS device and has a size of 256 bytes. The very first byte in the segment descriptor block contains the total number of segments in the file and can be in the range from 0 to 85. The remaining bytes are divided
into records of 3 bytes, the first two from which indicate the starting block of a segment on the disk, and the third indicates the length of the segment, which can range from 1 to 255 blocks. For zero-length files, a block of descriptors
segmentsmust be filled with zeros, but whether this is always so unknown
it is better to focus on the file descriptor in the directory.


FILE AND DIRECTORY DESCRIBER STRUCTURES.

Files and subdirectories are described in the directory in a 32-byte descriptor.

The purpose of the file descriptor fields is as follows:

Offset Size Description

0x00 8 file name
0x08 3 file extension
0x0B 1 file attributes
0x0C 2 download address for COM files
0x0E 3 file length in bytes
0x11 2 segment descriptor block number
for segmented files or
file starting block number for
continuous files
0x13 1 special purpose byte
0x14 6 reserve
0x1A 2 file checksum
0x1C 2 file last modification time
0x1E 2 file last modification date

The checksum word is simply the arithmetic sum of all bytes
subtracted from zero. The checksum is used by the system when loading and running executable COM files. Special purpose byte
for boot.sys anddevice.sys is always set to 0xFF, for other
files it can be used for various purposes, usually 0 is written there.
The data field designated as reserve is actually used by various
application programs.

Purpose of directory descriptor fields:

Offset Size Description

0x00 8 directory name
0x08 3 directory extension
0x0B 1 directory attributes
0x0C 2 starting block number
of parent directory
0x0E 2 directory size in bytes
0x10 1 * subdirectory nesting level
0x11 2 segment descriptor block number
for segmented directory
0x13 2 number of the starting block of the directory
0x15 1 * total number of used
handles to files and subdirectories
in the directory, including the handle to the
directory itself and deleted files
0x16 1 * number of files in the directory without
the handle to the directory itself and
deleted files
0x17 7 reserve
0x1E2 date of creation of the directory


Fields marked with the symbol "*" asterisk in the structure of the directory descriptor
contain correct information only in the directory descriptor located in the same
directory. In the descriptor for this directory in its parent directory, these fields
may contain incorrect information. The date for all directories except
the parent
is indicated in the descriptor. For the parent directory, you should look at the creation date
of the disk in the device descriptor.

Structure of the file or directory descriptor attribute byte:

Bit Description If cleared (0) If set (1)

0 file deleted file exists
1 reserve
2 file is read-protected
3 file is write-protected
4 file invisible
5 descriptor type file directory
6 file type segmented continuous
7 file protected from deletion

Bit 0 determines whether the descriptor is used or not. Bit 5 allows
to distinguish files from directories; it MUST be set for all directories.

Since when creating a file, filling out the file descriptor fields is the responsibility of those responsible
for the date and time in the systemIf there is an application program, then there is no
unambiguous determination of the date of creation or last modification. These fields are responsible. The system also does not itself modify these fields when accessing the file
both for writing and reading.


DIRECTORY STRUCTURE.

A directory is simply a file containing descriptors for other files and directories and
it can also be segmented or contiguous. If the directory is contiguous,
a situation may arise where it will be impossible to create new files or
subdirectories in this directory. Regardless of whether a directory is contiguous or
segmented, it cannot contain more than 128 file or subdirectory handles of 32 bytes each. The directory length is limited to 4096 bytes. The very
first file descriptor in a directory contains a descriptor for the same directory and
a link to the parent directory. More complete information is contained in the directory descriptor within the same directory than in the parent directory - this is worth paying attention to. The main directory of the disk (the root directory or the 0-level directory) does not have a parent directory. The name of the main directory as written in its descriptor is defined as "FF-dot": 0xFF, 0x2E, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20 and a 3-space extension. The attribute of this
descriptor is always equal to 0xE1.


That's all for now. But it seems to me that this is enough to understandmoreover
how the files are on the disk. All information is available in "notes for a programmer" written by Leontyev. And no one canceled the disassembler...


SC> There is an idea to create a text file on this
SC> disk and write the parameters of the killed
SC> file into its descriptor and extract it in this way. Who is doing what about this
SC> about this.

Do you want to pull out the text or what? If you need to get it out, then the demon can probably
help.

From Sergey Cherbynin To All 5 May 2002

KF> Is she even there? create probably erased the entire disk.
Not the whole one, but only the one where the information about directories and files is contained, and all
the rest of the information remained.
KF> With the demon, look at what's on the disk?
So I established with them that the course code remained on the screw.

KF> Do you want to pull out the text or what? If you need to pull it out, then demon
KF> can probably help.
I had to sweat a lot, but I couldn’t get everything out because of the segmentation
of the files, it’s difficult to piece together :-(((
Thank you for providing detailed information.

KF> -+- [ZX]
KF> + Origin: Rectals lived on the planet Rens for 2 million years. (2:5030/827.2)

All the best, Kirill!