HyPer_HST Manual This is fairly "long-winded". If you don't understand the basic internals of your HST, skip to PART III and then come back to PART I-II OOhhh....I'm sure there are "typos/mis-statement" somewhere even after re-checking and passing by Spazm and TarHeel. I didn't write this for "THEM".........it is for people that don't know DOS/OS so we didn't want 50 pages of jargon. So if you want "perfect", you shoulda done it!! POINT IS THAT IT WORKS GREAT!!!! "Snob Mob" that helped me with this now think 17xxcps is "snail-bait" [or was that "jail" :^) in messages??]. With a "GOOD" line, and both ends "set-up"..... 1810-1880 is normal. =========================================================================== PART I - The History of the HyPer_HST Idea First, let me explain that "Hyper_HST" is not some magical program you can just plug-in and instantly expect to get 1900cps from you HST 14.4 V.42 bis modem. Over the last 2 years, I worked on re-doing a number of device codes such as "serial.device" and also borrowed, begged, and plagarized source codes to optimize my OS. I also found additional utils written by other good coders dealing with killing multi-tasking, turning off audio.device, and other tricks which we experimented with for months and months. After months of re-writing serial.device, mathtrans.library, and other things under V1.33 DOS/ARP (I use ARP C: as C= C: commands suck sump water!!) a couple of things became painfully apparent: 1. The CIA/B chips (8520s) were absolutely critical to using a modem. a. These chips are notorious for "failures", "noise", and other problems. b. CBM designed the Amiga to work via 8520s so that 19,200 was the practical limit under V1.3 as 31,250 was something no modem supported c. This would always be a "weak-link" on the Amiga. 2. I bought an ASDG dual serial card. a. Why CBM only gave us one serial port.....damn if I know??? b. The one port they did give us.......was a "weak link" and using the ASDG I had two "fast" serials. 3. The HST technology works via RTS/CTS handshaking. Essentially the data goes into a buffer in the HST and then must either be received or sent to the computer (depending on whether it is [up/down]load. a. This buffer is designed to be fairly small......meaning it is painfully obvious that the computer must be able to move it, check it for CRC, and clear it VERY QUICKLY. b. If the computer can not keep up it will drop the RTS signal to the HST to quit passing data...... .....this is what is called the infamous "4-14K BLINK" 4. To solve the "BLINK" problem poses two distict thoughts: a. Each "blink" represents approximate 1K of data. Therefore, if you have this "pause" every 10K and are averaging say 96 blocks per minute (@ 1638cps)......the lost 10K in "blinks" is the difference between 106 blocks per minute (1810cps). b. AS A PRACTICAL SOLUTION: getting the "taskpris" to the BBS/TERM, the I/O DEVICE, and the I/O DRIVER is critical to making it fast enough so that the data is continuous between the modem and HST without the RTS/CTS pauses occuring. It was also "critical" to keep other tasks from "stealing" CPU time at these high speeds. The Amiga is working darn hard at read/write, checking CRC, and tasks specific to getting max transfers [BLUNTLY: you can type your background letter later!!] It is also very apparent that things which really ate at the CPU such as "intuition" or tasks that were running with high "taskpris" should be lowered. The darn thing only has 19,200 between the HST <---> computer so any delay whatsoever would likely cause a pause because of overflow or underflow. [BLAME C= !!! Had they had 38.4K and 76.8K serial this would not be such a critical issue with your Amiga. ] 5. TERMINAL PACKAGE/BBS PACKAGE a. THIS IS CRITICAL. Obviously with so many BBS/TERMS the trick is finding a BBS/TERM that can go at full speed under Amiga's 3 bitplane, 8 color ANSI [remember I did this under 1.3x DOS] and run at FULL SPEED!!!! b. Packages such as C-NET, JRjunk, BBS-PC!, or NComm could get perhaps 1650 if you killed the "color" or basically totally "stripped" them to an old phosphor screen XT IBM view. This destroyed 70% of the joy of modeming and the cosmetics of graphics, online games, IFF-ANSI, and other programs so I was STUBBORN AS HELL.....my BBS and TERM had to be fast enough in Z-Modem to handle color w/ full transfers. PART II- The Solution to Ultra High-Speed Modeming 1. I started developing the package as separate little tasks which I eventually could tie together. It would be a "package" of patches, serial.device, '.library', and other files which would be user installed to optimize the environment. 2. We tested over 25 BBS packages and some 40 odd terminal packages. EVERY TEST SHOWED THAT: AZcomm and AmiEXpress were the fastest. 3. We then started experimenting with every conceivable combination of "buffers", taskpris, bitplanes, HD interleaves, and everything else humanly conceivable to get the absolute "MAXED" speed possible under V1.3x DOS. Months of "coding" and "trial-n-error" produced BULLETIN #7 which worked for me with my ASDG Dual and Kronos V3.0 SCSI Controller. 4. I was able to routinely get 1660cps mostly w/out pauses to many boards error free.......and on 20-40% to hit 1700-1800. THAT WAS THE NEXT "$64,000 Question". Why could I sometimes get the 1760s and sometimes not???? Any why did some still "pause"?? 5. BRIDGECARD AND "MA BELL" TIME a. I had an AT 286 bridgecard and bought an inexpensive XT serial for $39.00 that I had tested crystal clean at 38.4K. This got hooked into the phone line. b. I called engineering (Ameritech is a client of mine) and got a complete engineering loop test of our slick which is rated at 1.5megs. I even bought a darn good line monitor. c. Armed with my new tools I started calling myself 1400 times using every route possible thru the CO and switch networking. We even used call forwarding, cellular phone lines, and a few clients' offices with Dimension/other switches to make loops. SURPRISE OF SURPRISES!!!!!!!! I was able to routinely get the 1500-1660 no matter what. Even lines which I would technically call "dirt balls" that met 2400bps specs would work. [In other words....US Robotics had done a tremendous design job to 'specs' of 1650cps even on bad lines]. However, when we got a very good line we started getting rates over 1800cps.....supposedly IMPOSSIBLE!!!! Even worst we started getting "dms" "wrp" rates over 1900 and routinely in the 1860-1885 range when we used good known TESTING LOOPS. OK, what the heck is going on here???????? 6. "Good Lines".....or what really is "GOOD!!" a. Boy what a surprise!!!! It seemed that there is a really wide range of what was considered "good" 2400bps. These variations were not enough to affect normal 1650cps transfers. It seems each TELECO/LD translated the "2400 standards" to Swahili, Pig-Latin, Greek, and Orkian. Don't bet "clean" is "clean"!!!! b. About 5 phone calls the US Robotics to Sue, Bruce, and tech engineering later and we finally get an explanation. [IT WOULD TAKE 6-7 PAGES TO EXPLAIN ALL THE "TECHY STUFF".....] [.....if you want it you can call them or write to engineering] c. The essence is this: 1. When the modem is in continuous mode (no "blink") the HST "training" process steps up it's max rate. OK...logical. BUT, internally HST gets quicker as many circuits can speed up with less strain on QAM, MNP, etc. Hmmmm.....did I just hear that 14.4/1650cps isn't the maximum and they built-in a "MARGIN OF SAFETY" to say 1600-1800????? How to use it?? 2. When you get to 14.4 and a super clean line....due to this "over-engineering", QAM design, MNP5, HST protocoling, and a great design job, chip max, etc.....it CAN GO FASTER!!!! Simply, HSTs can "speed-up" on super clean conditions. Beyond that, you write them directly for how it works. 3. I am told the "MAXIMUM MAXIMUM'S MAXIMUM" testing under "zip" is 1960 and that under "lzh/lha" it is about the same. 7. "BLINK" VS "PHONE LINE QUALITY" a. Well, I had assumed that the "blink" was always a Modem<-->CPU problem. I AM WRONG!!!!!! US Robotics tells me that poor phone lines or interconnects can also cause this effect rarely due to data coming in and their QAM cleaning it which will cause the buffer to fill quicker or slower at any given timeframe causing occasional "blinks" you wouldn't expect. They verified that really serious ones cause ARQ drops but that occasionally you can have a LOCKED ARQ and still get "blinks" unrelated to the Modem<--->Computer due to the speed being variable in actually getting to the 3.25K buffer. They also verified your "232" cable can cause this same effect as the phone line or in causing CRC or other errors. b. I also had assumed that once you were in "continuous" mode that you not only had the Modem<--->Computer correct.....but also you had a GOOD LINE!!!! DO NOT MAKE THAT ASSUMPTION!!!! THIS IS WHAT USR TAUGHT ME!!!! You can have a setup good enough to get continuous which they state will give you 1600-1750cps under most compressions (per their manual). If you want 1750-1900CPS then you have to have both a darn good setup and CLEAN, CLEAR LINES. It is not a "one-or-other" scene. PART III- A practical example of how it all works Let's compare what is going on to an old fashioned fire-fighting team before the days of modern fire trucks. 1. The men start a "bucket brigade" taking buckets (1024bytes=1K) and passing them man to man toward the fire. 2. If any of the men "drop" a bucket then the water is lost. (In our case this is an "ERROR BLOCK" and you get a resend request from the modem or terminal slowing things up). HOWEVER>>>HERE'S THE TRICK!!! Supposing they pass an empty bucket with no water in it. (In our case this is the "pause" times or "blinks"). They've wasted precious time and energy and didn't get one drop on the fire for all that effort. 3. Obviously, everyone is working as fast as possible. But if anyone slows down, then everyone else must slow down or stop until they catch up. (This is equivalent to your HST buffer of 3.25K. If the computer can't keep up taking the buckets then you will get a drop in the RTS to wait.......seen as the "sender" as a temporary "blink" in the SD/CS lights). If one man is "exhausted" totally and must slow down without a replacement, then everyone else must also slow down to keep his pace. (In severe cases this is what we call "down-training" from 14.4K-->12K---->2400bps. If they replace this gent with a fresh firefigher, then obviously they can go the other way and start passing faster again. 4. The "best case" is obviously if everyone works very quickly at the same pace so that everything flows smoothly rapidly moving the buckets in unison from person to person without any pauses or delays and they are able to increase the speed in unison. (This is what HST "retraining" is to higher rater of 9.6, 12.0, & 14.4 in the data pump. In your Amiga, this is the balance between all your "TASKPRIS", buffers, and choice of term/bbs so that everything runs extremely quick and smoothly without other tasks or a hardware chip being "tied up" causing a delay. 5. If everything works our men should be able to quickly put out the fire as other men will return the buckets at the same rate delivered for refilling...so we don't run out of buckets. (In our case this is the 450 "back-channel" on the HST and the computer sending back signals that the CRCs are correct without errors.) PART IV- WHERE THE ACTUAL "INCREASES" COME FROM. 1. The basic HST/computer design is 1600-1800cps at 14.4, and allows for certain time loss due to initial "training", EOF, and other factors. IT ALLOWS FOR CERTAIN SLIGHT "PAUSES" for HD read/writes as the HST was designed knowing most "PCs" would need these. 2. Over 60% of HyPer_HST is based on eliminating the "BLINKS"...... a. These 4-12K "blinks" represent delays as in my "fire brigade".. ......simply they are "lost buckets" of water. b. PRACTICALLY: Each "blink" takes about 1K (same time as a block) meaning "blinking" at 10K costs you 10 blocks/minute transmitted. 1600cps [95 blocks] with 10K "blinks".........is equal to: 1700-1730cps [102-105 blocks WITHOUT THE "PAUSES". This makes perfect sense. If you think of each "blink" as a dropped bucket, then if there were NO DROPS you'd have 10 more to throw on the fire to put it out. 3. HIGH-SPEED SENDING Obviously if everyone gets working in unison, then the possibility exists to increase the rate....something like in competitive rowing where they increase their stroke rate. This is where a REALLY GOOD PHONE LINE COMES IN!!!! a. The HST will "retrain" up and link both modems to the best rate. Internally QAM, retraining, and a ton of "techy" electronics is trying to go as fast as possible with the existing lines, and your setup from HST<---->computer. b. Assuming that the HST<---->Computer is 19.2/38.4K (well above what we need "well-tuned") then the HST<--->HST can start this special high-speed sending if everything is SUPER CLEAN!!! 1760-1900 is based on the 0-9blocks/minutes [17.07cps/block] which can be realized by HST circuitry w/ continuous flow rate smoothly in concert with continously error-free flow without blinking. c. AGAIN...THIS IS A "NON_TECHY" EXPLANATION!!!!!!! 1. The "blinks" cause each HST to have to "talk to each other" as well as the lost time (or buckets). 2. IN ADDITION...it is very hard to hold a very fast pace not only when there are "bucket droppers"....... BUT LET'S CALL IT the "psychological strain" of trying to watch in advance and keep your mind in tune to going this fast without error. Consider it "metal fatigue", "mental circuit exhaustion", "nervous breakdown", "heat chip fail", or whatever term you are technically comfortable relating to based on you technical background and employment. PART V- DIFFERENT HD/CONTROLLER and AMIGA MODELS 1. Suffice it to say........you can see why building a "Universal" plug-in program is extremely difficult if not impossible??? a. Startup-codes with all the possible tasks and priorities b. Type HD, Controller....boths relative speed, taskpri, interleave c. Models from 7MH Ami 1000 to 33MH 3500-T under 1.2/2.0x DOS d. Numerous "3rd party" accelerators, graphics, genlocks, etcitera which use CPU and DOS environment resources e. .......WELL, I THINK YOU GET THE IDEA....OR I HOPE SO????? SUMMARY: I hope this has explained the "project" and the process of testing by which we here at Doc's House have come up with 1700-1900cps rates routinely amongst some of our members and some of their BBS boards. Yes, some of the information herein has changed. Sorry, I am not GOD... .....and he was too busy to do this project!!! I think we now have 97% of all the information needed on how and why it works as we're consulted the telecos, US Robotics, and my most trusted friends and mentors to double-check and reverify everything. SADLY, I can see that writin a "PROGRAM" now appears impractical if not "impossible". There are just too many variables of machines, DOS, HDs, Controllers, and other factors. I will keep a list on my BBS as people write me giving the EXACT SETUPS USED for various combinations. .....if you have a question or problem please call us and we'll try to supply the "setup" or work out what should work based on all our experience, "trial-n-error", and every note we can compile from our members and people I know and respect on my friends' BBS. Doc 614-855-3114 "The Thinking Mans' BBS" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ HST 14.4 V.42b Setting for High Speed Transmission THIS BULLETIN ASSUMES: 1. You have the NEW serial.device and use either ANSIcomm or AZcomm. Online, JRcomm or other packages have not proven to date to be either as fast or reliable. HST 14.4 (without V.42bis use following except use &K0) HST settings for 14.4 V.42bis atz >ok atB1C1E1F1M1Q0V1X4&W >ok at&A0&B1&C1&D2&G0&H1&I0&J0&K3&L0&M4&W >ok at&P0&R2&S0&X1&Y1S11=38S21=001S26=000S15=008&W >ok INTERNATIONAL SETTINGS: atb0&W This is to accept the guard tones from European, Canadian and other V.32 except Bell...uses CCITT standards. AMI-EXPRESS NOTINGS: SYSOPS: In modem setup string on CONFIG1 Screen 3, set G2 at the end. This is necessary with Great Britain and other European systems that use different guard tones. CHANGES FOR AMI-EXPRESS V1.0(j) AND ABOVE!!!!!!!!!!!! 1. For HST V.42bis change the following parameters: ATZ >OK AT&A3S27=000&W 2. May find that S28=013 needed to answer both US/EUROPEAN calls. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ PREFERENCES: 1. RATE 19,200 baud 2. ***NOTE*** DOS V2.0 may "try" 38.4K AFTER (REPEAT AFTER) 19.2K setup. ...expect various "individual results" with 38.4K.... 2. F8N1 3. RTS/CTS handshaking (MANDATORY!!!!) 4. Buffering 4K (EVERYONE SHOULD START HERE...then experiment!!!) a. Kronos SCSI- 4K b. GVP Series II- 2K reported best c. Amiga 3000/25- 2K reported best d. Slow >28ms HD- 8-16K reported and MAX 1710cps e. "Flop-no HD" - 512-1K reported best TASKPRIS: BBS/TERM HD/UD_DEVICE [RAM: VDK: DF0:] CONTROLLER 1. KRONOS SCSI- 12 (68020/030) 15 (68000) 2. Flop-no HD - 12 (no improvement remove all other "user-started" tasks) 3. Slow >28ms - 17 (lower input.device to 5) 4. GVP II - 16 AZcomm (**See special file re: HD/CONTROL TASKPRIS) 5. 3000 16-25 - 16 BITPLANES: 1. There is ABSOLUTELY NO REASON with AZcomm not to use 3 bitplane/8 color 2. There is ABSOLUTELY NO REASON to bother with JRjunk, PERIOD!!! Any term which has to be "killed" to 2 color is a poor design and you can quote me to Jack Radigan. Nor do I need 500 knobs/whistles when 95% of the BBSs are AMI: AmiEX/TemPest MS-DOS: PCBoard/WildCat. Maybe a simple AmiANSI/MS-ANSI. Everything else is the same of F8N1, Z-Modem, RTS/CTS, etcitera. You want "wierd" protocols, Y-G, or other things which are slow.....call an Amiga "Tag" BBS and use X-Modem 1200. SPECIAL NOTES FOR PARTICULAR CONTROLLER/HD ARRANGEMENTS: 1. GVP SERIES II a. Many GVP Controllers come with the "Taskpri" built into the ROMS at 5. Use taskpri in your startup-sequence and address your GVP device as: 'Taskpri gvpscsi.device 16' b. Do the same for your partitions such as DH0: DH1: which need the priorities changes. NOTE: Do not use the (':') when addressing your partitions!!!! Ex: taskpri DH0 16...NOT...taskpri DH0: 16 [ED. NOTE]- Remember devices or names with " " [spaces] must be done as: taskpri "this device.2" 16 c. SETTINGS (Courtesy The PathFinder) RAM 16 gvpscsi.device 16 AZcomm 16 DH2 16 (the device from which he U/Ds File System 5 File System 5 WorkBench 1 trackdisk.dev 5 trackdisk.dev 5 input.device 5 DH0 - DH1 10 1. This should be very similar for most GVP Series II. Lower than 16 results in slower CPS; higher setings result in CRC errors and ARQ losses. 2. BOOT UP- with the minimum you need by ";" out tasks which are unnecessary during U/D sessions or remote BBS operations. 3. As of this "update", I am getting 1780-1894cps with HyPer-HST modified systems depending on phone line quality and their internal DOS. 4. CAVEAT: Remember that this is a "WHOLE PROCESS" as I learned the very hard way. If you have outdated commands in your dirs (C: L: LIBS: DEVS:) you will have poor luck trying to reach 1900cps. This whole process is very dependant on having all the latest and fastest C/ASM codes dir updates, libraries, and devices.......a proper setup of the HyPer......and a high-quality phone connection. 5. If you have problems with GVP Controllers please leave me a message at Doc's 614-855-3114 or Rosco's 203-448-6782 THINGS TO "TRY" IF STILL EXPERIENCING PROBLEMS: 1. Remove "user-tasks" from startup-sequence with ";" 2. Remove loadwb/loadwb -debug from startup-sequence with ";" 3. CUSS, SCREAM, CRY, YELL....or call me, Spazm, Mike, Tarheel for help!!!! CAVEATS: 1. Some modems which are non-HST which have MNP Level 5 9600 will be unable to properly connect with the &M4&K3. These you can only call at 2400 and are likely to be university sites, businesses or other 9600 MNP-5 users. From your terminal issue: AT&K0&M4 -this should establish a clear 2400 connection. *******Don't forget to reset to AT&K3&M4 upon DISCONNECTING******* :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::: DEVIL'S TRIANGLE 4 0 7 - 5 7 1 - 1 0 7 5 :::::::::::::::: :::::::::::::::::::::::: INDEPENDENTLY FAST !! ::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::