Jump to content
IGNORED

SuperSynch for SDX.


Kyle22

Recommended Posts

Back in the day, while @ FTe, I made an INDUS.SYS for SDX that worked PERFECTLY with the Super Synch Track Buffer. Sadly, that is long gone. We never officially released it. I made exactly one copy of SDX 4.23 which included this. I remember it was a simple timing change in the Z80 bit-banging code. IIRC, I just added a NOP or 2 to fix the SIO timing issue.

 

The way it was before, if you programmed the Indus with SuperSync, booted into SDX, it worked for a little while. You must press break to skip the SIO hangup. It usually fails.

I had BEATEN this with my INDUS.SYS code, but I LOST IT.

 

If any good Z80 programmers are out there (I love that chip), please look at this again. My brain is too rattled right now because I must take the Indian Idiot's abuse on a daily basis.

:)

 

Link to comment
Share on other sites

@Kyle22 Because I'm not well versed with IndusGT specifics yet, can you clarify/verify the SyncroMesh variations for me? Here's what I've gathered so far:

  • SynchroMesh: 38,400bps, POKEY divisor 10, 6:1 interleave for single density, 9:1 interleave for double density. (non buffered)
  • SuperSynchromesh: 69,000bps, POKEY divisor 6, 5:1 interleave for single density, 7:1 interleave for double density (non buffered)
  • Super Synchromesh with RamCharger: SIO speeds same as SuperSynchromesh, but adds 64K of read Buffering/Caching, more like an intelligent read cache utilizing the additional 64K RAM, not limited to single track buffering, significantly reduces read latency. (Does not accelerate writes?)

I have not tried the SDX INDUS.SYS on an IndusGT with RAMcharger (yet) but from what I've read from others the track buffering function does not function even with a RAMCharger present. The only way to see the RAMCharger buffering in action (today) is via the DOS XL GTSYNC.COM.

 

So... I gather the INDUS.SYS patch you're talking about would allow RAMCharger buffering to the existing 69,000bps capability of the SDX INDUS.SYS.

 

Reading your post again, I guess you mean running GTSYNC.COM first in another DOS so that the SuperSychromesh+RamCharger code is uploaded to the drive from there, and then use it from SDX. Does the code that SDX uploads NOT support RAMCharger/buffered reads at all?


Thanks

Link to comment
Share on other sites

Well, sorry for replying late to a nonetheless really interesting topic, here.

 

I happen to have done quite a good deal of research / testing on this matter, including some VERY informative one-on-one talks with author of Indus-Doubler emulation.

 

Here's the bottom-line (and a quick guide) on how to get up-and-running GTSYNC at maximum speed under DOS XL 2.35-I2, as well as SDX 4.49c:

 

  1. First, make sure that your SDX CONFIG.SYS does NOT call for "DEVICE INDUS", and than "DEVICE SIO" is called WITHOUT the /A switch.
  2. Grab an empty floppy and format with INITSYNC utility from master DosXL 2.35-I2 disk). When doing so, specify DOUBLE DENSITY format on the IndusGT drive where you hold the empty floppy. 
  3. Proceed and BOOT this disk immediately. You will end up in DOS XL 2.35-I2 prompt.
  4. Proceed and BOOT SDX with the CONFIG.SYS prepared in #1 above. Make SURE that "DEVICE INDUS" is NOT issued during CONFIG.SYS processing.
  5. For a test-file, make a copy of your favorite RastaConverter sample (with ability to return to DOS) and copy to your new-formatted floppy.
  6. That's all. 

 

You can now test (surface-to-Host) and Synchromesh (buffer-to-host) transfer speeds, with the sample file provided on #5, above. Just load-and-exit, load-and-exit a couple of times, and watch how track-buffering kicks in (!). You can repeat these exact tests by DIRECTLY booting from the floppy, and loading sample file directly on DOS XL 2.35-I2, and hand-timing as well the time spent on I/O during track-buffered reads.

 

After performing the above tests, you will invariable reach the following conclusions:

 

  1. (buffer-to-host) transfer speeds when booting DOS XL 2.35-I2 and loading sample file from track-buffer, will yield in approx. 4,600 Bytes/sec, net-net.
  2. (buffer-to-host) transfer speeds when botting SDX per above procedure, will yield in 3,600 Bytes/sec. net-net.

 

Conclusion is that you will NEVER be able to reach IndustGT / RamCharger full potential with INDUS.SYS driver in SDX 4.49c (even with Track-Buffering and GTSYNC enabled on Indus). HOWEVER, SDX will give you the HIGHEST possible read+write speeds (combined), especially if you use GTSYNC / INITDBL.COM format-interleave for double-density (pre-format on DOS XL 2.35I2 and then write directory-only under SDX format utility).

 

Have fun!

Edited by Faicuai
  • Like 2
  • Thanks 1
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...