The recent change to check that the IMD file track header record is 5
bytes introduced a problem with the end-of-file triggering an open file
error - instead of the previous behaviour where the number of bytes in
the track header was ignored and end-of-file was checked.
I noticed this after fetching and compiling the latest simh altairz80 - it
was refusing to my mount floppy disk IMD image files (which I had made
from 8-inch floppies back in 2006).
```
maxi:s100 tony$ altairz80 cpm3bk.ini
Altair 8800 (Z80) simulator V4.0-0 Current simh git commit id: d3f1ee09
Console escape is CTRL-\
I8272: IMD disk corrupt.
/Users/tony/s100/cpm3bk.ini-58> att disk1a0 /Users/tony/s100/C3BKSIMH.IMD
File open error
```
Looking at the commit history, I saw the change by Howard Harte to
sim_imd.c to "Resolve CID 1502448, 1502460" - presumably to fix the
call to sim_fread() that was not checking the returned result.
Howard's "fix" broke the parsing of the IMD file sector headers by
not checking for an end-of-file condition (at the end of file it
would read 0 bytes and this was now treated as a fatal error - whereas
the old code had a check for end-of-file after the call to sim_fread()).
This commit now detects end-of-file correctly, as well as verifying
the track header is 5 bytes.
The ImageDisk sectsize field was incorrectly set to the number of
bytes in the sector, when it should be an index as follows:
00 = 128 bytes/sector
01 = 256 bytes/sector
02 = 512 bytes/sector
03 = 1024 bytes/sector
04 = 2048 bytes/sector
05 = 4096 bytes/sector
06 = 8192 bytes/sector
Tested disk formatting on MS-DOS 1.25, Cromemco CP/M 2.2,
Cromemco CDOS, OASIS 5.6.
These changes facilitate more robust parameter type checking and helps
to identify unexpected coding errors.
Most simulators can now also be compiled with a C++ compiler without
warnings.
Additionally, these changes have also been configured to facilitate easier
backporting of simulator and device simulation modules to run under the
simh v3.9+ SCP framework.
