Jump to content
IGNORED

The TRAK track buffer?


Larry

Recommended Posts

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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... (!!!) ;)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

 

INDUS_GT-ROM12X-Intel2732A_3-Main.bin

INDUS_GT-ROM12X-HitachiHN462732G-1.bin

Cheers!

  • Like 1
Link to comment
Share on other sites

  • 1 year later...
On 6/19/2018 at 8:50 PM, Faicuai said:

 

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

 

INDUS_GT-ROM12X-Intel2732A_3-Main.bin 4 kB · 12 downloads

INDUS_GT-ROM12X-HitachiHN462732G-1.bin 4 kB · 13 downloads

Cheers!

What are these dumps supposed to be actually? They don't match the v1.1 or v1.2 firmware that I have.

 

BTW, the two ROM's above are identical.

 

Link to comment
Share on other sites

5 hours ago, MrFish said:

What are these dumps supposed to be actually? They don't match the v1.1 or v1.2 firmware that I have.

 

BTW, the two ROM's above are identical.

 

Yes, as I mentioned they could be identical. They are 100% safe to try and reliable, as well.

 

These ones are either the standard 1.2 ROM or the same 1.2 but with timing-tweaks for disk-spin, stepping, etc.

 

This image has been installed on my programmable ndusGT, for a long time, now.

Edited by Faicuai
Link to comment
Share on other sites

1 hour ago, Faicuai said:

Yes, as I mentioned they could be identical. They are 100% safe to try and reliable, as well.

 

Right, I was just confirming that they were indeed a match. I used file compare -- after getting a CRC32 match to start with.

  

 

1 hour ago, Faicuai said:

These ones are either the standard 1.2 ROM or the same 1.2 but with timing-tweaks for disk-spin, stepping, etc.

 

I found out exactly what ROM it is you've posted here. It's the Richard Andrews - Indus Upgrade ROM 1.2X. It's sold by Best Electronics and discussed in detail here:

Nezgar - Indus GT 1.2X Upgrade ROM

 

Edited by MrFish
  • Like 2
Link to comment
Share on other sites

25 minutes ago, MrFish said:

 

Right, I was just confirming that they were indeed a match. I used file compare -- after getting a CRC32 match to start with.

  

 

 

I found out exactly what ROM it is you've posted here. It's the Richard Andrews - Indus Upgrade ROM 1.2X. It's sold by Best Electronics and discussed in detail here:

Nezgar - Indus GT 1.2X Upgrade ROM

 

Correct, that is the one!

 

But modifications go a bit beyond what is described, though...

 

There are time where pre-spin (when inserting or extracting) does not take place, at all. Probably reaching 0s may have been an obsession... ;-)

 

As for the "faster sector", I am not really sure, and it is not clear what sector-interleave pattern is magically supported, though. Throughput wise, I can't detect any difference between OEM v1.2 and v1.2x.

 

Cheers!

 

Link to comment
Share on other sites

6 minutes ago, Faicuai said:

As for the "faster sector", I am not really sure, and it is not clear what sector-interleave pattern is magically supported, though. Throughput wise, I can't detect any difference between OEM v1.2 and v1.2x.

That's advertising for you: 100% better on paper and negligible in actual use. :D

 

Link to comment
Share on other sites

  • 1 year later...
  • 4 weeks later...

I dumped this v1.12 firmware (from the previous post) from an 2732 eprom manufactured by AMD. The problem is that all 2732 I got to try other firmware need >=21Vdc to program and I have a TL866 II which does not reach that voltage.

I tried slowing down the programming process, and also "injecting" 25Vdc to the programming pin, but it did not work. I will need to pay for the more expensive 2732s that accept lower programming voltages.

I also have a question: which program do you use to disassemble the firmware. I searched but I found some programs for MS-DOS. I have some basic knowledge of assembly and I would like to compare the different firmware versions.

 

Link to comment
Share on other sites

On 8/25/2021 at 8:12 AM, manterola said:

I dumped this v1.12 firmware (from the previous post) from an 2732 eprom manufactured by AMD. The problem is that all 2732 I got to try other firmware need >=21Vdc to program and I have a TL866 II which does not reach that voltage.

I tried slowing down the programming process, and also "injecting" 25Vdc to the programming pin, but it did not work. I will need to pay for the more expensive 2732s that accept lower programming voltages.

I feel the pain - I get about a 70% success rate programming 21/25V chips on a version 1 TL866... It claims max 21V but in reality it maxes out about 18V, so its borderline. I often have to use the tricks you mentioned... Slow down, repeat programming, etc...

 

Interesting if injecting an external voltage boost didn't work for you. I have been planning to try this using this doohickey I picked up from aliexpress that can step up any variable voltage from 3-25V :

https://www.aliexpress.com/item/1005001417851839.html?spm=a2g0s.9042311.0.0.792f4c4dkzidmK

 

I guess if your 2732's aren't working for you maybe you'd be interested in a trade for some blank and or programmed chips for your high voltage ones... although your postage costs to Canada may negate the worth. Here is an eBay seller of 12.75V 2732's that worked well for me - $13USD and free shipping (from China) for 10:

https://www.ebay.com/itm/123248646835

Link to comment
Share on other sites

On 8/26/2021 at 12:41 PM, Nezgar said:

Interesting if injecting an external voltage boost didn't work for you. I have been planning to try this using this doohickey I picked up from aliexpress that can step up any variable voltage from 3-25V :

https://www.aliexpress.com/item/1005001417851839.html?spm=a2g0s.9042311.0.0.792f4c4dkzidmK

Not sure, but maybe injection does not work on 2732 because the programming pin is also OE. Maybe injection works in the 2764 eproms. Interesting device you linked, BTW. I might get one, it could become handy in the future.

On 8/26/2021 at 12:41 PM, Nezgar said:

I guess if your 2732's aren't working for you maybe you'd be interested in a trade for some blank and or programmed chips for your high voltage ones... although your postage costs to Canada may negate the worth. Here is an eBay seller of 12.75V 2732's that worked well for me - $13USD and free shipping (from China) for 10:

https://www.ebay.com/itm/123248646835

Thanks for this tip. I got these National Semiconductors branded eproms from other seller to test. 

Regarding sending eproms to Canada, I think it worth the try. I can put a couple in a regular envelop and see if they get to you. You can experiment with them and then we see if you can send eprom in the opposite direction.

I have sent PCBs to Europe this way and they arrived within 2 weeks.

Link to comment
Share on other sites

I found this picture in Flickr which I think is interesting. It is a picture of an addendum (to the latest firmware?). it seems that they reassigned the conf switches from the back to en/dis the turbo mode and en/dis the printer port, and the auto diagnostics it always on. There is no much to read as it is only 1/4 of the paper. I will try playing with the switches once I got the v1.13 in an eprom (I am waiting to arrive).

1676208703_trakdriveset.thumb.PNG.cd3ac19b7ab8a6fa265a1a4fa094f2d9.PNGAddendum.PNG.f4d4925a02b2ae6467e5af5c2e6c3678.PNG

Link to comment
Share on other sites

  • 1 month later...
On 8/29/2021 at 3:10 PM, manterola said:
On 8/26/2021 at 12:41 PM, Nezgar said:

Interesting if injecting an external voltage boost didn't work for you. I have been planning to try this using this doohickey I picked up from aliexpress that can step up any variable voltage from 3-25V :

https://www.aliexpress.com/item/1005001417851839.html?spm=a2g0s.9042311.0.0.792f4c4dkzidmK

Not sure, but maybe injection does not work on 2732 because the programming pin is also OE. Maybe injection works in the 2764 eproms. Interesting device you linked, BTW. I might get one, it could become handy in the future.

I bought a USB variable voltage power supply, and I can confirm that the "voltage injection" method works with old 2764 and 27129 EPROMS. I tried with several Mitsubishi and TMS I had (+21 Volts), and I was able to program them by disabling the Pin Check Option and the Verify Option in the TL-866 windows app and lifting the VPP pin. 

Then I reinserted the VPP pin to the programmer and did a Verify to compare the content of the EPROM with memory content.

So it looks like 2732 would require a more complex "voltage injection" than the larger EPROMs with independent VPP pin.

 

Link to comment
Share on other sites

  • 2 months later...
On 8/2/2021 at 1:14 PM, manterola said:

And attached here is the "1.12 T" firmware, for historical purposes:

TRAK_Atari_1.12T.BIN 4 kB · 13 downloads

 

-----------------------

ATARI 1.12 T

TRAK MICRO CORP.

COPYRIGHT 1983

-----------------------

 

Is the "T" supposed to designate "Turbo", the company name, or just a revision of the 1.12 firmware?

 

Link to comment
Share on other sites

4 minutes ago, manterola said:

No idea, I just copied what the label on top of the EPROM says. My guess is that T is for Turbo.

Alright, I was guessing the same (given the 1.13 Turbo label).

 

Too bad none of the software that's supposed to exist for these things has ever surfaced...

 

Link to comment
Share on other sites

  • 1 year later...
On 12/10/2021 at 11:31 PM, manterola said:

No idea, I just copied what the label on top of the EPROM says. My guess is that T is for Turbo.

Hi Maurico,

 

you recently asked me in this thread about the firmware on my TRAK AT.

 

The Trak arrived yesterday and I took a few pictures.
The label is unfortunately extremely faded, but comparing it to another TRAK label, I would say it says:

 

ATARI 1.13 T
TRAK Micro Corp.
COPYRIGHT 1983

 

(The second photo is for comparation)

 

Cheers,

andY

IMG_20230113_180725.jpg

TRAK EPROM 1.11.JPG

  • Like 1
Link to comment
Share on other sites

10 hours ago, andymanone said:

Hi Maurico,

 

you recently asked me in this thread about the firmware on my TRAK AT.

 

The Trak arrived yesterday and I took a few pictures.
The label is unfortunately extremely faded, but comparing it to another TRAK label, I would say it says:

 

ATARI 1.13 T
TRAK Micro Corp.
COPYRIGHT 1983

 

(The second photo is for comparation)

 

Cheers,

andY

IMG_20230113_180725.jpg

TRAK EPROM 1.11.JPG

I was corious about the label, just toy with the levels a little: 

 

image.png.f915a1cbdb30a362eb42ce84830dc389.png

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...