The good news - The TRAK dirve using the Trubo 1.13 does seem to have an active track buffer with 4K Ram. (with no additional TRAK software.)
The bad news - It appears to ONLY work with single density disks formatted with a normal sector skew.
The worse news - It's actually slower with the track buffer than without!
I was running some speed comparisons on several disk drives to see how they compare and to see if and how well the track buffers on them work with different densities and sector skews and SIO drivers. When I started testing the TRAK drive, something odd happened. When reading from the drive, it would spin up, but then there would be a long pause before any data was actually read. After the pause the data for a complete track came through pretty quickly, then this would repeat for every track being read. At first I though it was having problems reading the disk, but it had no problem reading the same disk with a different firmware. So I ran a test that read just one track. The first time a track is read, the drive spins up, pauses for a while, then reads quickly. On subsequent reads of the same track, the drive still spins up for some reason, but there is no pause, before the data is read, again quickly as if coming from the buffer. Unfortunately the lack of data transfer while the buffer is being filled makes the whole process slower than reading the same number of tracks without a buffer, except when a single track is read multiple times! This only occurs with a single density disk formatted with the normal sector skew. Double density disk and single density disks formatted with a USD skew do not exhibit this behavior and do not appear to be doing track buffering at all.
On a more positive note. The same drive using MrMartian's US Doubler ROM seems to make the drive act like a USD 1050, and actually outperforms my homebrew USDouble drive on USD skewed Double density disks by about 25% (I double checked this test).
Here's the raw data. The times are the number of seconds to read 100 sectors from each disk. Timing was done by hand. The Stock OS Tests had no high speed drivers loaded, and the other tests were using Hias's 13. patch.
Nice compilation of results!
I actually ran your test (also hand-timed and verified) reading a full 6x18 = 108 sectors, in both 128bytes and 256bytes variants, on the IndusGT, with just the RamCharger-64K memory board, and DOS XL 2.35 // SuperSynchro Disk... Any O/S seems to work:
108 Sectors, SD, from disk-surface:
8.50s (UPDATE: 6.6s re-timed with DOS-XL SD disk formatted under SyperSynchro)
108 Sectors, DD, from disk-surface: 9.10s (disk format / readout seems optimized for DD)
108 Sectors, SD, from RamCharger track-buffer: 3.80s
108 Sectors, DD, from RamCharger track-buffer: 6.50s (DD seems to work with less overhead)
It becomes clear that even without Track-Buffering, the Indus-GT already leaves every other drive in its wake... Bring RamCharger's Track-Buffer, and it is (in relative terms) ridiculous...
But, wait! there is more (!): what about a FULL system-reboot @ DOS-XL prompt?:
Full DOS XL reboot, SD, from RamCharger track-buffer: 9.0s
(yes, NO DISK-SPIN while rebooting! )
From the above, I just noticed that, in the Indus-GT domain, [transfer-speed acceleration] and [Track-Buffering] seem to be two DIFFERENT, independent features... When re-booting the Atari, track-buffering operation survives at standard SIO speeds, and continues at accelerated speed, as soon as re-boot completes with SuperSynchro final loading...
Moreover, the above suggests that RamCharger "track buffering" may be actually much more than a buffer... it seems that it is more of a data-cache server, with its own replenishing and memory allocation logic, down to individual sectors (?), and capable of surviving host-computer reboots (e.g. can work with plain O/S SIO calls).