MESS 0.98 file system bug

From Ninerpedia
Revision as of 13:27, 1 June 2007 by Mizapf (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Diagnosis

Disk test (sector read using the "Disk Manager II command module"):

v9t9 format (sector size: 256 byte)

40 tracks, 9 sectors, 1 side, single density = 90K: works up to 0.97: all sectors readable

since 0.98:

  • 0-179 Good
  • 180-359 Bad

40 tracks, 18 sectors, 2 side, double density = 360K: works up to 0.97: all sectors readable

since 0.98:

  • 0-359 Good (360)
  • 360-1079 Bad (720)
  • 1080-1439 Good (360)

40 tracks, 9 sectors, 2 side, sd = 180K: works up to 0.97: all sectors readable

since 0.98:

  • 0 - 179 Good (180)
  • 180 - 539 Bad (360)
  • 540 - 719 Good (180)


40 tracks, 18 sectors, 1 side, dd = 180K: works up to 0.97: all sectors readable

since 0.98:

  • 0 - 359 Good (360)
  • 360 - 719 Bad (360)

By the way, formatting the media from within the emulation is completely broken from the very beginning:

Trying to format the drive (since 0.70): 

Exception at EIP=6170965B: ACCESS VIOLATION
While attempting to read memory at 00000008
-----------------------------------------------------
EAX=61ABB700 EBX=00000000 ECX=00000001 EDX=FFFFFFC4
ESI=6170AFB0 EDI=00000000 EBP=00000000 ESP=0022FCC0

The above observations are the same for disk controller emulations TI FDC and Myarc HFDC.


Bug report of June 1, 2007

Submitted to MESS bugzilla

Since MESS 0.98, the floppy emulation for the TI-99/4A is broken, and people have kept on using 0.97 since then. The original contributor seems to be unavailable. I spent some time investigating the problem, and I think I found a bug in the generic floppy code.

It is in mess/devices/mflopimg.c, lines 281 following. This code was inserted with version 0.98. Since then, the floppy emulation is broken: 

if (floppy_callbacks(flopimg->floppy)->get_heads_per_disk
     && floppy_callbacks(flopimg->floppy)->get_tracks_per_disk)
  {
   floppy_drive_set_geometry_absolute(image,
         floppy_get_tracks_per_disk(flopimg->floppy),
         floppy_get_heads_per_disk(flopimg->floppy));
  }

Detailed symptoms and my diagnosis:

The TI emulation offers four different disk controllers. One of them, the Myarc HFDC, is capable of handling 80-track drives, the other three only handle 40 tracks. HFDC is set as default. The real card has dip switches which determine the tracks of the connected drives. These dip switches are properly emulated (except that you can only choose between using 80 tracks for all or for none of the connected drives). The 80-track setting is default for HFDC.

The standard TI disk medium is 40 tracks (since the other controllers can only handle 40 tracks). When such a disk is used in an 80-track drive, the BIOS of the HFDC double-steps the tracks, i.e. it steps 0-2-4-6-...-78. There is some code in the emulation which translates this for accessing the image by division by 2. So far, the real behaviour is perfectly emulated. This double-stepping is necessary and cannot be prevented (because it comes from the original ROM).

Now, the above-mentioned block of code breaks the emulation: It sets the maximum track of the drive to the track count of the medium. This track count is determined by reading sector 0.

What happens now is that the medium image is read properly - until track 20 is reached. From there, the emulated drive (which has actually been stepped 40 times) refuses to step any further even though it just points to the middle of the image file (for single-sided disks). I did some more tests: Setting the use_80_track_drives=FALSE in mess/machine/99_dsk.c, the HFDC correctly reads the complete medium. However, this prevents us from using HD floppies; not a solution.

My suggestion is to remove this portion of code again. I can't make any sense of setting the drive parameters to the track count of the medium, especially when using 40-track media in 80-track drives.

If this portion of code serves some other specific purpose (I guess this was not inserted by accident), then we need to inversely translate the track count. That is, when the medium reports 40 tracks, the drive track count must be doubled if it is an 80-track drive. This can probably be done in the machine-specific part.

Please note that this is a severe bug which prevents us from using any newer version than 0.97, including SDLMESS.

Additional comment: As for remedy, the lines may probably not be removed, because of the opposite case when using 40-track drives. Currently there seems to be missing a way to determine the drive capabilities. There should be a callback to the machine emulation code (here, 99_dsk.c) to determine the drive geometry from emulated hardware settings.

Retrieved from "http://www.ninerpedia.org/index.php?title=MESS_0.98_file_system_bug&oldid=1372"