06665: All drivers in coco12.cpp, coco3.cpp: Very slow load times when accessing the floppy drive

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
06665	Timing	Minor	Always	Aug 19, 2017, 22:26	May 19, 2021, 03:01

Tester	MrGW	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	Open	OS	Linux (64-bit)
Status [?]	Confirmed			Driver	trs/coco3.cpp
Version	0.188	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	06665: All drivers in coco12.cpp, coco3.cpp: Very slow load times when accessing the floppy drive
Description	I'm not sure when this started, but the floppy drive load times are extremely slow when using various Coco drivers when using MAME's built-in floppy drive support. A good example of this would be to mount and load John Kowalski's Donkey Kong (or Donkey Kong Remix) DSK image. Granted, it is one the largest files to load (at 68 granules) it takes over twice as long to load in MAME as it does on real Coco 3 hardware with a Tandy floppy drive and Tandy FDC controller. I've noticed this behavior on my Linux workstation, Windows workstation and even the Raspberry Pi 3. Please keep in mind that the emulated system speed is spot on. No issues there. Just floppy drive I/O speed. If you use DriveWire to load the DSK images, I/O is noticeably faster. That being said, I don't know if DriveWire (with the Becker port) is emulating real floppy disk I/O speed.
Steps To Reproduce	Load MAME using the 'coco3' driver. Mount John Kowalski's Donkey Kong (or Donkey Kong Remix) DSK image from MAME's UI or from the command line. LOADM "DKREMIX" (if you have the Donkey Kong Remix DSK image). Use a stop watch and record the total time it takes until you get the flashing color prompt back again. Compare this time to a real Coco 3, loading Donkey Kong Remix from a real 5 1/14" floppy disk.
Additional Information
Github Commit

Flags
Regression Version	0.163
Affected Sets / Systems	All drivers in coco12.cpp, coco3.cpp

Attached Files

No.14121 Robbbert Senior Tester Aug 19, 2017, 23:45	You'll have to give us times, as none of us have the real hardware.
No.14122 Tafoid Administrator Aug 20, 2017, 00:30 edited on: Aug 20, 2017, 00:31	Regression appears to be from 0.162 to 0.163 - 0.163 being the new WD Floppy driver code. 0.162 takes about 35 emulated seconds to load the game to prompt 0.163 takes about 135 emulated seconds to load the game to prompt > mame64 coco3 dkremix -autoboot_delay 1 -autoboot_command loadm"""dkremix\n -ui_active This will start the game, issue the command and start loading ASAP It would be nice to get an accurate reading from actual hardware.
No.14123 Tafoid Administrator Aug 20, 2017, 00:33	To OP, this is not a critical bug. Only bugs which crash/hang/freeze the emulation are considered critical.
No.14125 MrGW Tester Aug 20, 2017, 18:44	I just tested loading DKREMIX from a real FD 501 disk drive unit and controller on a Coco 3. 42.38 seconds. To confirm, the binary file is 68 granules in size. Thanks.
No.14131 MrGW Tester Aug 21, 2017, 23:23	I can perform more testing, like DSKINI, loading other games, etc., on real hardware if you would like. It sure sounds like disk I/O speed was more accurate prior to MAME 0.163.
No.14136 drencorxeen Tester Aug 24, 2017, 23:45	I did some testing of my own. I decided to create a new disk image using MAME in drive 0, but I chose the disk image format of "HxCFloppyEmulator floppy disk image mfm" I then did a DSKINI 0 I then mounted the DKREXMIX.DSK image in drive 1. I then did a BACKUP 1 TO 0 I then did a LOADM"DKREMIX My load time off of the MFM disk image was 42.78 seconds. So my guess at this moment is the JVC routines that load the JVC disk image in as it is building the mfm track image is not using a interleave that is best suited for Disk Basic. Which I assume at this point this is probably a problem in the coco_fdc.cpp
No.14137 drencorxeen Tester Aug 25, 2017, 01:16	Looking through the sources for coco_fd.cpp and going down this rabbit hole of routines I found in formats folder a source file called jvc_dsk.cpp and looking through that saw no option for a interleave in there. I went further down the chain to flopimg.cpp and am now looking at how the routines work in there. I believe a interleave option would be something good to add to these routines so it would be possible to set on a per system setting the best interleave that was used for those computer systems. If I understand these routines correctly the interleave is a 1. For example. NitrOS-9 L2 & OS-9 L2 on real floppy disks the interleave was 3. I believe Disk Basic was a interleave of 4. On some older information this is also known as SKIP factor. I know this would be a lot of work, but in my opinion some form of extra variable needs to be passed so these routines can build the track in such a way so there is a more realistic interleave based on the original system that might have called it.
No.18857 tlindner Moderator May 19, 2021, 03:01	I few years ago I implemented the proper interleave for JVC disk images. I just tested DKREMIX today and got these times: MAME 0.231: 87 seconds Real H/W: 43 seconds