flexfs - File systems supported by flexemu


DESCRIPTION

Flexemu supports three different file systems to be used as disk drive:

DSK Disk image files
DSK disk image files (with file extension *.DSK or *.WTA) are commonly used by emulators running the TSC FLEX operating system, see: ReFLEX by Ben Williams, SWTPC 6800/6809 Emulator by Evenson Consulting Services or 6809 FPGA design by Neal Crook. Also FLEX software archives use DSK disk image files, see: FLEX User Group by Ian P. Blythe or FLEX Software Archive by Simon Wynn Consulting.

A *.DSK file contains all sectors of a disk. A wide range of track/sector combinations is supported. Following table shows typical used disk formats:

Disk size
[inch]
SidesDensity
*)
TracksSectorsFile size
[KByte]
5 1/41SD351087.5
5 1/42SD3520175
5 1/41SD4010100
5 1/41DD4018180
5 1/42SD4020200
5 1/42DD4036360
5 1/41DD8018360
5 1/42SD8020400
5 1/42DD8036720
5 1/42QD80721440
81SD7715288.75
81DD7726500.5
82SD7730577.5
82DD77521001
**)--25525516256.25
**)--25625516320

*) SD = single density, DS = double density, QD = quad density
**) Harddisk

The sector size is always 256 Byte. The size of the file can simply be computed with <nr_of_tracks> * <nr_of_sectors> * 256 Byte. If the DSK-file is write protected the drive within flexemu is write protected too.

Optionally a JVC file header is supported. The header can contain 1 up to 5 bytes. flexemu supports the following JVC header values:

Byte offsetDescriptionDefaultSupported
values
0Sectors per track-5-255
1Side count11,2
2Sector size code1 *)1
3First sector ID1 **)1
4Sector attr. flag0 ***)0

*) A sector size code of 1 means a sector size of 256 Byte
**) For FLEX compatibility the first sector ID always should be 1
***) Sector attribute flag should be 0 (A sector attribute byte is unsupported)

FLX Disk image files
FLX disk image files (with file extension *.FLX) have the same structure as a *.DSK file with an additional 16-byte header at the beginning of the file. The header describes the disk format:

bytesnamedescription
4magic_numberalways 0x485C9A33
1write_protectflag for write protection
1size code128 * 2 ^ n Bytes/sector
1sides0nr of sides on track 0
1sectors0nr of sect. on track 0
1sidesnr of sides on track != 0
1sectorsnr of sect. on track != 0
1tracksnr of tracks total
5dummy1 - dummy 5for stuffing

The header allows to have a different number of sectors on track 0 as on other tracks. For the actual format look at struct s_flex_header.

Virtual disk images
A vitual disk image is a directory on the host file system which will be mapped as a disk drive within the emulation. So it also could be called a directory disk. Each file in the directory will be visible as a file contained on the disk.

The boot sector (on track 0, sector 1 and optionally sector 2) is contained in the file boot. If there is no such file the disk can't be booted. The link to FLEX.SYS will be generated dynamically by flexemu. The user does not have to care about it.

Random files on virtual disks
The detection of random files on a virtual disk depends on the flexemu version. The following table gives a detailed description of how random files are identified. It is used by flexemu and flexplorer.

VersionRandom file detection
< V3.22 On a read-write directory disk random files are identified by the user execute attribute set (UNIX) or the hidden attribute set (Windows). On a read-only filesystem like a CDFS these attributes may not be available. So for any read-only directory disk a file random can be created containing the lowercase filenames of all random files.
V3.22 The bahaviour is the same as in older versions. Additionaly, to avoid crashes in flexemu in addition to the file attributes a file only is detected as random file if it has a size of three sectors minimum. FLEX does not support random files with one or two sectors. In addition the sector map of a random file is verified and has to be valid.
≥ V3.25 The detection of random files used in older flexemu versions has some downsides. It depends on file system capabilities, is a kind of misuse of filesystem attributes and error phrone. For this reason a completly new strategy is introduced.

To decide which strategy to use the following checks are done in this order:

  • File .random exists => Use strategy A
  • File random exists => Use strategy B
  • A file with user execute attribute set (UNIX) or hidden attribute set (Windows) exists => Use strategy C

Strategy A
Files listed in file .random are identified as random files. A check is executed if the file exists and has the minimum size of a random file which is three sectors. This .random file is automatically updated when creating a new, deleting or renaming an existing random file. The files listed in file .random are always sorted alphabetically with lowercase filenames. If it can not be written the whole disk is marked as read-only. This is the preferred strategy.
Strategy B
This strategy only exists for downward compatibility.
Files listed in file random are identified as random files. A check is executed if the file exists and has the minimum size of a random file which is three sectors. The files listed in file random are unsorted with lowercase filename. When creating a new, deleting or renaming an existing random file the updated random file list is written to the file .random while deleting file random. The files listed in file .random are always sorted alphabetically with lowercase filenames. If either file random or .random can not be written the whole disk is marked as read-only.
Strategy C
This strategy only exists for downward compatibility.
A file with user execute attribute (UNIX) or the hidden attribute (Windows) set is identified as random file if it has the minimum size of a random file which is three sectors and also has a valid sector map. When creating a new, deleting or renaming an existing random file the updated random file list is written to the file .random. The files listed in file .random are always sorted alphabetically with lowercase filenames. If it can not be written the whole disk is marked as read-only.

In flexplorer and dsktool also the directories used for injecting or extracting files a file .random is created and updated to support random file detection in these directories.

Restrictions
There are some restrictions the user should be aware of:

  • When first time mounting a virtual disk image the track and sector count is used from the flexemu preferences. The number of tracks and sectors are stored in the disk directory in file .flexdiskrc to be reused when mounting again. If the size of all files in the directory won't fit to the virtual disk image size some of them are silently ignored. A read-only directory always uses the default track and sector count as defined in the flexemu preferences.
  • All filenames must conform to FLEX file naming conventions otherwise they are silently ignored.
  • A virtual disk image is only accessible using FMS calls. Direct reading/writing sectors is not supported an may result in undefined behaviour.
  • New files have a name tmpXX (XX = two digit number) and are renamed to their real name after closing them within the emulation.
  • If the directory of a virtual disk image drive is full it will automatically be extended. So no directory extend utility should be used.
  • During emulation modifying files on the host is not supported and may result in undefined behaviour.

SEE ALSO

Documents on the behalf of the FLEX User Group

Related Links