This evening I managed to put together a very beta version of my disk dumping rig that uses a way faster sector-transfer protocol from the drive to the C64.
In order to compare the performance improvement, here are some numbers to work with. Transferring a whole sector from disk with my previous setup used to take CPU cycles in excess of 35k. For reference, WarpCopy64 takes cycles in excess of 19k during the data transfer (324 bytes in total counting a few extra bytes, some of which are for sector number and check byte). If I am not making any gross mistake here, after my code changes transferring a single sector takes around 12k CPU cycles, which means a 65% performance increase 🙂
Now the bad news is that this still seems to be too many cycles for a two-revolution-only dumping experience.
In fact, I’ve monitored dumping of track 1 and I can see that I am fetching sectors in three revolutions. Example of the sectors I am able to fetch: 4, 7, 10, etc.
The whole disk dumping time has only fallen to about 22 seconds, from 25 with my previous code, despite the 65% performance increase: if the code is too late to fetch each other sector, then there isn’t much it can do but waste the extra time that was made available by the performance increase 😦
I am afraid that it’s pretty much impossible to gain further cycles at this point, even if I might now be quite close to the threshold that would allow two-revolution-only dumping.
What I plan to do is to package the functionality of my test rig into IECHost and make it available to those who still have a box of random disks in the attic/garage but not the budget for more expensive dumping hardware 🙂