victor9k: Fix very slow floppy disk performance #13583
Conversation
|
I think we’d rather have the 8048 emulation fixed properly rather than removed altogether. We prefer to emulate stuff in more detail where possible, and this should be within MAME’s current capabilities. |
|
I agree, it oughta be possible to get it to work while actually running the 8048. I can probably be convinced to merge this as-is if you'd agree to make another attempt with the 8048 though. We can help you with the MAME-specific details there. I have way more experience syncing things with 8-bit microcontrollers in MAME than anyone ought to, and Vas is good at that sort of thing too. |
|
I did disassemble the 8048 ROM code (that's how I discovered that some of the signals could be either inputs or outputs), but when it comes to understanding and debugging the servo algorithm, I think I'm in over my head. TBH there's also a motivation issue, since getting the 8048 working properly won't lead to any discernible change in the behavior of the emulated machine :-) What I'd be willing to do however is see if I can come up with a more targeted fix for the slowness issue by addressing the register reading of the problematic signals, without touching anything related to the 8048. |
donohoe00
force-pushed
the
victor9k_fdc_perf
branch
from
697b2fb to
80f33d4
Compare
|
I've pushed a new, more minimal set of changes, which are functionally equivalent to the old ones, but do not remove any 8048 related code. This leaves the door open to debugging and fixing the drive control algorithm in the future. |
|
Converted to draft since I'm making progress on the 8048-related issues. |
- Polarity of the reset signal was incorrect - Hold the 8048 in reset as long as the reset signal is asserted, instead of doing a one-shot reset and letting it run. - Due to all the mirroring in the IO register map, register writes while probing for the hard disk controller were hitting the registers of the VIA chips in the FDC controller, resulting in SCP resets and whatnot. - The RDY0/RDY1 and Motor Speed signals can be either inputs or outputs. During initialization, these signals are used for things like loading speed tables into the SCP. Look at the direction of the signals from the VIA's point of view to determine who should be driving the lines. - Generate the tach signals going to the SCP correctly. - After all of the above fixes, we can now use the Ready signals from the SCP, and no longer need to bypass it.
donohoe00
force-pushed
the
victor9k_fdc_perf
branch
from
287521e to
a3a1573
Compare
|
This has been working great for me - tested with lots of file copying with DOS and DOS utilities, making bootable disks, and general use with single and double-sided images. |
|
Agree this current iteration mimics the timing on the vintage hardware more accurately. I've also tested it over several days and is working reliably for me. |
|
I completely missed that this was ready for review, sorry. Could you sync up and fix the conflict? |
Result is a big speedup: retries/timeouts that were happening previously do not occur, and the system now seems to perform as expected.