Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|06665||Timing||Minor||Always||Aug 19, 2017, 22:26||Aug 25, 2017, 01:16|
|Tester||MrGW||View Status||Public||Platform||MAME (Self-compiled)|
|Assigned To||Resolution||Open||OS||Linux (64-bit)|
|Version||0.188||Fixed in Version||Build||Normal|
|Summary||06665: All drivers in coco12.cpp, coco3.cpp: Very slow load times when accessing the floppy drive|
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.
|Affected Sets / Systems||All drivers in coco12.cpp, coco3.cpp|
|There are no relationsihp linked to this issue.|
Aug 19, 2017, 23:45
|You'll have to give us times, as none of us have the real hardware.|
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.
Aug 20, 2017, 00:33
|To OP, this is not a critical bug. Only bugs which crash/hang/freeze the emulation are considered critical.|
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.|
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.|
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
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.