Jump to content

Photo

The TRAK track buffer?


32 replies to this topic

#26 Faicuai OFFLINE  

Faicuai

    Dragonstomper

  • 812 posts
  • Location:Florida, U.S.A.

Posted Mon Jun 18, 2018 10:22 PM

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).



#27 Nezgar ONLINE  

Nezgar

    Stargunner

  • 1,090 posts
  • Location:Regina SK Canada

Posted Tue Jun 19, 2018 12:02 AM

Yep sounds like not just a track buffer, but a full sector read cache. Ie continuous read of sector 19 and 720 would have no head seeking from end to end of disk. A full 64K cache of the most recent read sectors is pretty powerful.

It would make sense for standard sio calls to continue to read from cache after computer reboot, as the drive is still running on the uploaded code. Would have been nice if all indus drives came with ramcharger and this code in ROM from the beginning. Most people have never seen the drive operate at this level!

Curious if writes are buffered?

#28 JR> OFFLINE  

JR>

    Moonsweeper

  • 277 posts

Posted Tue Jun 19, 2018 11:05 AM

 

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

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).

Good stuff....my ramcharger equipped INDUS did not perform nearly so well as yours in the synchro modes.  It has random pauses (hard to read sectors?) and occasional read errors, even on disks formatted by it.  Probably needs a good cleaning.  What High Speed SIO were you using on the Atari side?  The HIAS patched OS didn't seem to be making full use of the super synchro speeds.....it seems a lot faster under DOS XL 2.35 with GTSYNC than it is after booting another DOS on the drive (already GTSYNC'ed) and running the test from that DOS.



#29 Faicuai OFFLINE  

Faicuai

    Dragonstomper

  • 812 posts
  • Location:Florida, U.S.A.

Posted Tue Jun 19, 2018 1:23 PM

Yep sounds like not just a track buffer, but a full sector read cache. Ie continuous read of sector 19 and 720 would have no head seeking from end to end of disk. A full 64K cache of the most recent read sectors is pretty powerful.

It would make sense for standard sio calls to continue to read from cache after computer reboot, as the drive is still running on the uploaded code. Would have been nice if all indus drives came with ramcharger and this code in ROM from the beginning. Most people have never seen the drive operate at this level!

Curious if writes are buffered?

 

Great question!

 

Under DOS-XL, it seems that writes are "flow-through", direct/IO type, and pretty sLoOoOoW, by-the-way (relative to the pretty fast read-speeds). Under SDX 4.49c, they (write-ops) also seem to be write-through, but definitely A LOT faster than DOS XL.

 

Caching writes (like Windows excellent / integrated disk-caching routines) may be another ball-game, all-together, and it will involve some degree of local multi-tasking on the Indus-GT, because you may receive a read-operation, while the drive has not yet finishing a write-cache flush... If no multitasking, then RamCharger memory-space will have to be dynamically allocated / resized for Write and Read operations (separately), and then have the Z80 vet the order and sequence of its responses.



#30 Faicuai OFFLINE  

Faicuai

    Dragonstomper

  • 812 posts
  • Location:Florida, U.S.A.

Posted Tue Jun 19, 2018 1:47 PM

Good stuff....my ramcharger equipped INDUS did not perform nearly so well as yours in the synchro modes.  It has random pauses (hard to read sectors?) and occasional read errors, even on disks formatted by it.  Probably needs a good cleaning.  What High Speed SIO were you using on the Atari side?  The HIAS patched OS didn't seem to be making full use of the super synchro speeds.....it seems a lot faster under DOS XL 2.35 with GTSYNC than it is after booting another DOS on the drive (already GTSYNC'ed) and running the test from that DOS.

 

If you are experiencing random-pauses, you probably don't have the right format-skew on your test-disk, or you simply have the wrong test-disk, altogether. There should not be ABSOLUTELY any errors, of any kind whatsosever.

 

I have two IndusGT units, one with red-white dip switch-panel, and the other with blue-white dip panel. The first is fairly quiet and has a SRAM (single-chip) RamCharger board, manufactured by Tregare, here. The second one is UNBELIEVABLY quiet, has the pin-header for RamCharger, but it is vacant). Both units have been serviced and verified with GT-DIAGS, and checked for zero-track sensor, RPM speed (both methods), ROM version, read & write in all formats, cross-compatibility with my 1050, and RamCharger-tested, too (where it applies).  They will perform optimally when warmed-up a bit, though. The ram-charged unit, has a v1.20 ROM version that is DIFFERENT than the non-ram-charger unit, which ALSO reports v1.20 ROM in GT-DIAGS (!) You can tell this, because upon power-up of RamCharger-equipped unit, there is no classical SIO "bell" as well as much shorter disk spin when sliding floppy in, among other things.

 

As for the "high speed SIO" on the Atari, it does not apply with IndusGT, as all the tests above were performed with my A800 + Incognito, booted in plain / old OS/B and RAM set to 52Kbytes :)

 

The master boot disk is a DOS-XL (2.35) based disk from INDUS that runs the SUPER SYNCHROMESH loader, automatically, as a "batch" script. It just calls a small .com on the disk, and that's it. The disk, however, has been pre-formatted with Indus own INIT utility (in SD, with SuperSynchro loaded), and the first three tracks re-formatted with same utility's option specially designed for such purpose, so DOS sub-system loads a bit faster when SuperSynchro has not yet been loaded on drive. After that, first three tracks load slower, but everything else FLIES during disk-surface readout tests. A differential-skew format, in essence.

 

For double-density tests, a separate disk pre-formatted with Indus INITDBL utility with SuperSynchro loaded, and any bunch of large files on it will suffice. The maximum sustained throughput I have been able to extract out of the [ IndusGT / RamCharger / Super Synchro] combo is 4,500 Bytes/sec under DOS XL 2.35.

 

I have to say that seeing the IndusGT running on SuperSynchro (+ RamCharger) is something that draws respect out of me, even today, where my HP Z840 sequentially reads its NVME drive at speeds in excess of 2,100,000 Kbytes / sec with ZERO CPU usage... (!!!)  ;)



#31 JR> OFFLINE  

JR>

    Moonsweeper

  • 277 posts

Posted Tue Jun 19, 2018 5:42 PM

I got pretty poor performance even with a SD disk formatted with INIT with SuperSychromesh loaded.  I think the drive just needs some needs work. I'll have to pull out my other indus drives and find the one in the best shape.

 

I believe Incognito uses Hias's high speed SIO drivers even when using an unpatched OS ROM.

 

Can you post a copy of the 1.20 rom from your ramcharged unit?



#32 kheller2 OFFLINE  

kheller2

    Stargunner

  • 1,220 posts
  • Location:PA, USA

Posted Tue Jun 19, 2018 6:24 PM

Here is the 1.11 code, for historical purposes.

 

Attached File  ATARITRAK111.bin   4KB   12 downloads



#33 Faicuai OFFLINE  

Faicuai

    Dragonstomper

  • 812 posts
  • Location:Florida, U.S.A.

Posted Tue Jun 19, 2018 6:50 PM

I got pretty poor performance even with a SD disk formatted with INIT with SuperSychromesh loaded.  I think the drive just needs some needs work. I'll have to pull out my other indus drives and find the one in the best shape.

 

I believe Incognito uses Hias's high speed SIO drivers even when using an unpatched OS ROM.

 

Can you post a copy of the 1.20 rom from your ramcharged unit?

 

No, No, Incognito DOES NOT use HIAS SIO optimizations when booting on legacy OS/B, because these require PBI-Bios extensions available, and that is only possible with XL / XE OS code (or with a full O/S replacement, like Q-Meg). Furthermore, the presence of OS-based SIO optimizations is easily verifiable by simply booting my Nuxx Drive image-initialization routine. It goes slow when fast-SIO is absent, and FLIES with fast-SIO... With OS/B it goes slow.

 

Attached are the ROM-dumps that (most likely) I have loaded in my RamCharged IndusGT. They may (or may not) be the same, but I am sure it is one of these two... IIRC, I think it is the Intel2732A image. It's been a few years, already, since prepping-up my drives...

 

Attached File  INDUS_GT-ROM12X-Intel2732A_3-Main.bin   4KB   11 downloads

Attached File  INDUS_GT-ROM12X-HitachiHN462732G-1.bin   4KB   12 downloads

Cheers!






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users