V2.25
OSIHFE is a Windows/Mac/Linux command-line utility used to convert between OSI Disk Dump images and HxC RAW FM disk images ( "HFE Files") used with Flash Floppy Disk emulator. It can also read SCP (SuperCopyPro) flux dumps and RAW OSI disk dumps saved as HEX downloads. 


OSIHFE recognizes "OSI" HFE image files and OSI disk dump files and will convert between them. You can now source or target the 2nd side of HFE images with the '-2' option.

It restores the timing delays lost when dumping files using the OSIDump utilities. 
It simulates the disk reading and writing process generating flux transitions used by the Flash Floppy Emulator. It can write OS65D and OS65U format images.  The target HFE files are created as double-sided RAW FM images which seem most compatible with HxC devices. Unless the 2nd side is specified, all operations on HFE files occur on the 1st side. 

OSIHFE can also test OSI disk images for errors and report specific file corruption for many known formats.


Usage: 
Usage: OSIHFE -[25bcdiklortv] infile [outfile]
       Converts between OSI disk dump and HxC floppy emulator file formats
       will also read SuperCopyPro (SCP) and HEX Dump OSI disk images.
       If [outfile] is not specified, a target file is automatically
          created based on input filetype
       -2 :Use 2nd side as source or destination when converting between HFE
       -5 :Write 8" image at 5.25" bit rate to allow mounting 8" image on 5.25"
           system
       -b65D5/-b65D8/-b65U/-bHEXDOS/-bDOS655 -b8/-b8z -b5/-b5z outfile :create blank OSI
           disk image of specified type or empty (-b8/-b5) or null (-b5z/-b8z)
       -c infile outfile :Clean OSI disk dump image (not HFE)
       -d infile :List directory contents
       -i infile :Identify type (OS65D5, OS65D8, OS65U, HEXDOS)
       -k<n> :Skip n tracks in scp source image (n=4: 160trk->40trk)
       -l<filename> :Specify verbose log output file name instead of stderr
       -o :Overwrite existing output file
       -r<n> :Specify source revolution to use in conversion from scp file (usually 1-3)
       -t infile :Test OSI disk dump/HFE/SCP image, report errors
       -v :Turn on verbose output
 (ver 2.25)


Since a target filename will be generated automatically based on input file, all you need to do is drag & drop the OSI disk image onto OSIHFE for it to generate the corresponding HFE file or vice versa.  SCP files will convert to HFE by default unless a target file extension is .65d or .65u is provided.  Converted HEX dump images are saved in their binary equivalent, unless a target filename ending in .hfe is supplied, in which case an HFE file is generated.  SCP target file generation is not supported.


The clean operation will correct the checksum on OS65U tracks, although any data corruption remains.


Flux Transitions Per Bit: the -s flag.
By default OSIHFE reads and writes HFE files expecting two flux transitions per bit or 500Kfps 8"/250Kfps 5.25", which is what was used in the disk flux images samples I received at creation. HFE files could be sampled at 250Kfps/125Kfps, which is perfectly legal for the media.  The -s flag forces OSIHFE to treat single bit flux transitions as data rather than the pair of flux transitions expected/generated with older versions.  The resulting track length is shorter and the data rate is halved.


Recognized OSI floppy and data formats include: HexDOS, PicoDos, OS65D 5.25/8", DOS/65, CPM, OS65U 8", UCSD P-System, and YEDOS


Notes on Test feature:
Files that are stored in SCP or HFE format can recreate the low level bit pattern written by the OSI disk controller's ACIA.  They can also record errors in the bit stream as well as timing gaps in the data.  This low level information is not available once the data has been read or converted to OSI raw disk dump format.
The OS65D format uses an 11-bit serial word formated as 8 bits, Even parity, One Stop-bit (and 1-start) or 8E1.  It is possible to detect some disk read/write errors for data stored in this format at the point of error.  
OS65U floppy track data uses 8N1 (with 8E1 track header), a 10-bit serial word format with a 16bit checksum for the 3584 byte track.  Although some framing errors can be detected in the bit stream, all you really know is that somewhere in the track there was an error.

Generally the 8E1 format is used throughout all known OSI disk formats except for OS65U, this includes all OS65D versions, HexDos, Dos/65, PicoDos, CP/M 1.4 & CP/M 2.2, UCSD p-System, Forth, FigForth, etc.
OSIHFE test function creates a map of file allocations from the entries listed in the directory of the various operating systems.  When reading HFE or SCP data and a Parity or Framing bitstream error is detected, it looks at the file allocations to map the error to the associated file.  OSI disks contain many such errors due to the disk head being switched on & off between index hole, track header, data, and between sectors. These glitches are not considered errors and OSIHFE will not flag these as error.

Besides bitstream errors, OSIHFE can also detect many types of data corruption. This processing also works for files in OSI Raw Disk Dump format.  Missing track headers, missing sectors, misnumbered tracks are also flagged as error.

Not all disk errors are fatal. 
Not all files flagged as possibly corrupt are in fact corrupt. Not all files are known to OSIHFE.
The OS65D directory contains a list of files & allocations available to the operating system.  Files are generally allocated in whole track increments. Many programs do not fill the whole space allocated to them, so a data error on the last byte of the last track of a file may not cause any problems, however OSIHFE will still track this error and flag the file as possibly damaged. In addition, it is possible to store programs on partially filled tracks that do not show up in the directory. OSI used this technique to store disk utilities on the 2nd or higher sector on a track.  Also on may disks, the operating system is not listed in the directory. The OS uses the first 8 or 12 tracks (depending on disk size).  Errors in these areas are displayed but their impact is not known to OSIHFE. 

CP/M and Dos/65 use a 1K allocation unit on the disk. Files are stored in multiples of 128byte records. OSIHFE will flag the associated files when errors are encountered.

HEXDOS allocates disk space by track, OSIHFE will flag the associated files when errors are encountered.

OS65U stores data in 3584 byte long sectors, but allocates file usage by offset & length.  Files affected by errors encountered will be flagged.

Picodos has no directory and will therefor just show errors encounted by track and sector.

Support for UCSD p-System file mapping, has not been finished. OSIHFE will just show errors encountered by track & sector.

Using OSIHFE on multiple files
==============================
To test all *.img files in a folder, you can use the following code in a batch file under Windows Command Prompt. (Feel free to change the ".img" below to the file extension you are using!)

for /f "delims=|" %%f in ('dir /b *.img') do osihfe -t -l%%~nf.log %%f

Copy and paste the previous line into a file called test.bat.   When you run test.bat it will create a group of files named after the files processed with ".log" appended.  The log file will contain an OSI directory and disk test results for each file tested.

For Mac/Linux use the shell script that follows
#!/bin/sh



for i in `ls *.img`

do
    
	echo "Test $i ..."
   
	./osihfe -d -t -l$i.log $i

done




Mark Spankus 12/2020



OSIHFE versions
---------------
V1.0.0 * Initial Release *
V1.0.2 
	Correct decoding of OS65U HFE images
	Code changes to support build on Mac
V1.1.0 
        Allow 80 track input images
        Increase track length to more closely match kyroflux dump
        Add support for HexDos
        Add support for OS65D 14 character filenames
        Fix blank disk creation
V1.2.0 
        Change triggering of OS65D 14 character filename support 
V1.3.0  
        Recognize DOS/65 disks, add explicit 'clean' option
V1.4.0
        Correct OS65U sector length, determine OS65U checksum & verify on clean operations
V1.4a
        Increase gap after index hole for 8" on 5.25" conversion.

V1.4c   Correct detection of blank 65u disks, fix built-in help text

V1.4d   Increase 8" index gap, add -b5, -b8 options to create empty disk with only clock pulses

V1.4e   Verbose output shows number of FM zeros after data. Adjusted 8" timing & disk length - 
        longer delay between 0S65D sectors, slightly shorter HFE track length

V1.4f   Added detection & listing of OSI CPM 1.4 directory. Added optional -b8z -b5z to create an empty 
        disk with no FM data at all (Zeroed), to be filled in by a disk copy program of your choice!

V2.0    Added file read/conversion of SCP (super copy pro) flux dumps from GreaseWeasel etc.
        Added directory listing support for CPM 2.2
        Added disk error testing of flux dumps like SCP, HFE including parity errors, and RAW OSI Dumps
        which can only test for format problems such as missing track or sector headers, malfomed tracks
        etc.
V2.01   Fix crash in CP/M directory of HFE conversion. Add CP/M 2.24 dir support

V2.1    Add HEX OSI dump support, add additional CP/M variant detection, fix bugs.

V2.2    Rework CPM/Dos65 directory processing, accounting for record interweaving,
        restore DOS/65 detection.  Add skip track option for SCP files, be more forgiving of disk
        images with more than expected tracks/sides.

V2.21   Fix truncation of existing overwritten files that change size.
        Fix Test operation - damaged files not listed for extended directory OSI disks (12 char filenames)
        Added ability to decode other than 1st flux pattern per track in SCP files

V2.22   Fix incorrect bitrate in header of HFE files for non-OS65D 5.25" disks
	Add support for Th.Buescher's YEDOS disk format - pad HFE->OSI dump conversions to 40 tracks
	Now recognizes 8" floppy HFE images designed for 5.25" disk controllers.
	Probably added or broke something else.... we'll see.

V2.24   Rewrote a bunch of the internal source/target option code, fixed hexdos problem in 2.23
