@L}5 _$% l0$)$$Hȱ$ UhL" `e$$%`$%`  R@W!( L(1   Y I`  d  Ld M * @  $ % CC$$)%1 Udߥ$9%: !0 S$% DD˙`  }J)Lr  --- STAR TREK III --- by Lance Micklus and David Simmons Atari version by Mike Burton Modifications and documentation by P}at Lancaster [72637,225] STAR TREK is a trademark of Paramount Pictures Corporation ---------------------------------- If yo}u have downloaded the additional lines for the program, follow this procedure: 1) With both programs SAVEd on the same disk,} go into BASIC and LOAD the additional lines. 2) Next type: LIST"D:filename", using the same filename you loaded it with. 3) }Type NEW to clear the memory, then LOAD the Star Trek game. 4) Type ENTER"D:filename" to bring in the additional lines. This }will take a few seconds. 5) You can either SAVE the entire game again with the new lines, or test it first to see if you like } it or not. Most books on Atari computers will give you more information about the above procedures. ----------------------- }----------- Your mission is to wipe out all of the Klingon ships, while finding and orbiting Class M planets. Star Fleet will } notify you when your mission is completed, after which you'll return to Star Fleet HQ for a mission analysis. MAIN MENU DES }CRIPTION --------------------- 0: STATUS This will give you a readout of the ship's current status, with information such as} energy, stardate, etc. Pay careful attention to the energy amount! (More on this later) 1: DAMAGE CONTROL A listing of ship} functions and their conditions will appear onscreen. If something is damaged, the damage level will appear--this will decrea}se as time goes on, until the function is operational. 2: SCIENCE COMPUTER This is used to scan the objects in the quadrant.} Use this to find Class M planets, as well as how much energy enemy vessels have. 3: SHIP'S COMPUTER This has several useful} functions: >DATA BASE SCAN will give coordinates of Klingons, planets, star bases, stars, and unexplored areas. Coordinates }will not be given if you haven't explored the area yet. >LONG RANGE SCAN FROM DATA BASE will give a long range scan from any }coordinate that you input. >QUADRANT DETAILED DISPLAY will give you information about a particular quadrant that you input, p}rovided you have "seen" it with a regular long range scan. If you have explored a quadrant with a Class M planet, this functi}on will tell you if the planet is explored or unexplored. >NO ACTION will return you to the main menu. 4: LONG RANGE SENSORS} This will provide you with a nine-square, 27-quadrant scan of the surrounding area. The "playfield" is an 8x8 grid, with eac}h square of the grid broken down into three quadrants. At the top you'll see the letters K,B,S, and P--these stand for Klingo}ns, Bases, Stars, and Planets. Look underneath these in the quadrants to see if there's anything interesting. If you see "1" }under S, for example, there is 1 star in that quadrant, which has a specific coordinate. The game starts from quadrant 7,7,2:} 7 across, 7 down, quadrant 2. The first two digits of the coordinates range from 0 to 7, and the last digit from 0 to 2. }X - (0-7) across Y - (0-7) down Z - (0-2) quadrant in square X,Y The X and Y values are displayed in inverse video. Coo}rdinate numbers are displayed along the top and right sides of the screen, and your position is always the center quadrant. }5: SHORT RANGE SENSORS This will allow you to see the stuff that's in the quadrant you are in. 6: IMPULSE ENGINES This is ho}w you move about inside the quadrant. When selected, this function will first provide you with a short range scan (if the sen }sors are not damaged!). Next you will be asked for a heading. The heading ranges from 0 to 7, with each number representing a!} direction: 3 2 1 \|/ 4-X-0 X=your current position /|\ 5 6 7 After selecting a heading, you will be asked "}for a speed. The number you enter will move you that many squares. For example, if you input "2" for the heading and "3" for #}the speed, you will move UP 3 squares. To explore (orbit) a planet or dock with a star base, move into the SAME square as the$} planet or base. 7: WARP DRIVE This is how you move about the galaxy. You must first enter a destination quadrant, then a wa%}rp factor (speed). As stated earlier, the first two digits of the coordinates can range from 0 to 7, and the last digit from &}0 to 2. Enter what square of the 8x8 grid you wish to go to and which quadrant (x,y,z). To travel to quadrant 4,3,1, simply '}enter "4,3,1" for the destination prompt. Warp factor is the speed, and your energy and the stardate will change according to(} how far and how fast you travel. If you are about to enter a Klingon-infested quadrant, using a higher speed will kind of su)}rprise them, giving you an advantage when the fighting begins. For exploring, though, it's best to use "1" for the warp facto*}r. 8: PHASERS This will allow you to fire your phaser banks at the enemy. Chekov will ask you for an energy level--the numbe+}r you enter will be used for EACH Klingon! So if there are 2 Klingons and you enter 200 for the phaser energy, a total of 400,} energy units will be drained from the ship. If the Klingons are far away, more energy is needed to reach them. The advantage-} of using phasers is that the Klingons you are firing at need not be directly in the line of fire. You can get an estimate of.} how much energy to use by using the Science Computer to find out how much each Klingon has. Occasionally the phasers will mi/}ss, and the computer may fire again to try and hit the target(s). 9: PHOTON TORPEDOES These will almost always destroy a Kli0}ngon ship. You will be given a short range scan (if possible) and then be asked for DIRECTION. The direction format is exactl1}y the same as the impulse engine direction format. Therefore the Klingon must be in the line of fire--up, down, left, right, 2}or any of the four diagonal directions. Be careful when using these; you will be relieved of your command if you hit a star, 3}planet, or star base!! And yes, it IS possible for the torpedo to miss the target. 10: ALERT This is to change the condition4} of the ship: green, yellow, or red. ALWAYS go into red alert before entering a quadrant containing Klingons! One hit while i5}n green alert will result in HEAVY damage. Use green alert while exploring. 11: REPAIR Choosing this will reduce the damage 6}level of damaged functions. This is faster than waiting for the function to "fix itself." You might have to choose this more 7}than once if something is badly damaged. 12: SAVE/LOAD (not on menu) This will take you to a save/load screen. You can use a8} cassette drive or disk drive to store the present game conditions. This way you don't have to start all over again later if 9}you can't finish a game. If you have ENTERed the additional lines, you will NOT be able to save the game on cassette. -------:}--------------------------- A FEW HINTS ... * To replenish (somewhat) your energy and get more torpedoes, dock at a star bas;}e. These can be found using the ship's computer. * Avoid entering a quadrant containing any strange objects! * Class M planet<}s are usually alone, so explore each quadrant that has one planet. You get more rating points for each M planet explored. * W=}arping blindly around the galaxy not only drains energy, but also could land you in a black hole! But sometimes it's the only>} way to find those boneheaded Klingons. * Use photon torpedoes on Klingons with high energy levels, but make sure you are lin?}ed up properly. * You don't have to get to the main menu to enter commands. You can enter commands from any screen; the compu@}ter "remembers" when you do this, and executes it when possible. * To exit the game, enter a number GREATER than 12. To resumA}e, type GOTO 500. The program should catch any errors that might occur; you might have to re-enter something if it wasn't doB}ne correctly the first time. If something goes wrong, however, clear the screen and type "GOTO 500". This will take you back C}to the main menu. If the problem continues, try re-running the program. If you have any questions, please leave me a message D}with E-Mail. Also leave any comments you might have! If enough of us Trekkies got together and petitioned CompuServe, perhapsE} an official STAR TREK forum could be started!!! Would that be logical? Live long and prosper, and be sure to go see "STAR TRF}EK IV: The Voyage Home" a couple of times ... -- Pat Lancaster computing from the sunny campus of the University of Arizona!G} `8}``|* ? ɛ,`|:-)| / 1L!`DESTINATION CANT BE DOSb: #Trackball InfoFm: Frank Hausman 71251,2002Atari TRAKBALL: In TRAKBALL mode. Here's what I've learned about thedata fI}rom TRAKBALL mode: Bit Function 3 Clock for vertical motion 2 Direction: 0=up, 1=down 1 Clock J}for horizontal motion 0 Direction: 0=left, 1=rightIt's a good idea to sample the trackball VERY FREQUENTLY to avoid K}missingclock transitions, and causing non-linear responses. L} 轤{NAMEnDOC FOR TTT3DCOMPILED WITH THE MMG COMPILERBASIC VERSION ?The game rules are the same as Tic Tac Toe only you have 3DN}. You can go up down across in any direction (watch the upper left to lower right etc.)The moves are given in BOARD-SQUARE oO}rder. The boards are A to D left to right and the squares are 01 to 16 bottom left to upper right. So a move may be A04 OR D1P}4 etc.Just paly awhile and you'll catch on.ANY GAMES YOU'D LIKE TO SEE COMPILED LEAVE ME A NOTERICK VEGA 75116.3267ppppQ}pppppppppppp  B JKIHiDiELV`L8 8 BLV`Lx BY MATTHEW RATCLIFF (synopsis) This look inside the Atari XE Game System includes two programs. XEGS Manager S}is a utility for convenient control of all the Game System's built-in features, but many of its options can also be used on t T}he other Atari XL/XE computers. The second BASIC program is a short "spray-painting" routine for testing light guns. Ata U}ri executives asked the heads of several major toy store chains which product they'd rather sell -- the powerful 65XE home co V}mputer for about $80, or a fancy new game system for about $150. The answer was, "You can keep the computer, give us that ga W}me machine!" This "game machine" is what we now know as the Atari XEGS, the XL-compatible Extended memory Game System. X}It's simply an enhanced 65XE in a game machine package. It's also a brilliant idea. The XEGS has been selling out almost as Y} fast as toy stores can get them in. The XEGS may not seem like such a hot idea to serious Atari computer users. But ju Z}st think about it. If you were afraid of computers or don't have the foggiest idea what to do with one, you'd have absolutel [}y no interest in an Atari 65XE -- even if it could play great games. However, you'd probably have no compunction about buyin \}g a great video game system, the XEGS, as a new addition to the family entertainment center. Now we'll take a close tech ]}nical look at the Atari XEGS. I'll explain how some of its changes in physical design have affected the operating system soft ^}ware. I'll also present the XEGS Manager, a utility for controlling all the built-in features of the XEGS. KEYBOARD _} The keyboard of the XEGS is detachable. When not connected, the XEGS console looks (and acts) like just a tame little gam `}e console. In fact, Missile Command is turned on automatically. Plug in the keyboard and turn on the machine without an a} external cartridge, and you're running Atari BASIC, Revision C. The keyboard is virtually identical to the one found on the b} 130XE. It's mushy, but you can get used to it. The cable on the XEGS keyboard is quite short. There are two brackets c}at the top of the keyboard case which lock neatly under the front of the console. The keyboard connector is a standard DB15 d}female. My first XEGS project was to construct an extension cable for the keyboard. I find it far more comfortable to type e}for a long time with the keyboard on my lap than on a desk. Inside the XEGS keyboard case is a small circuit board. On i f}t you will find some resistors, capacitors and two CD4051 chips, which decode the keypresses and send an internal keycode bac g}k to the POKEY chip in the XEGS. I already made an adapter cable to connect the XEGS keyboard to the 800XL joystick ports. h} So far my efforts at "scanning" the external keyboard manually have failed -- the POKEY chip does this automatically in t i}he XEGS -- but I hope to bring you a laptop keyboard utility program that lets you use the XEGS keyboard on any other Atari c j}omputer with minimal hardware hacking -- just a cable. MEMORY There are only two RAM chips in the XEGS, which deli k}ver a full 64K of RAM. They're Texas Instruments TMS4464-12 64K-by-4-bit chips. In the XL/XE computers, eight 64K-by-1-bit l}chips are used. Fewer chips improves reliability and generally reduces the cost of producing the machine. In fact, the XEGS m} contains a total of only 17 chips. ICD has indicated that it is working on a RAM upgrade kit for the XEGS similar to th n}e RAMBO XL for the Atari 800XL. I've already received a 128K RAM upgrade kit from Innovative Concepts for my XEGS, making it o}fully 130XE-compatible. I'll review this in a future issue. Using higher-density ROM chips, the updated XEGS operating p}system had 8K of spare ROM. Atari decided to use that extra ROM for the Missile Command game, which is bank-switched in and q}out much like how Atari BASIC is toggled on and off. Missile Command can be enabled by holding the [SELECT] key during power r}-up when a keyboard is connected. When in BASIC, you can enter BYE to get to the Self Test. From there, pressing [RESET] whil s}e holding the [SELECT] sends control to Missile Command. Press [RESET] in Missile Command, while holding [OPTION], to return t} to the Self Test. Press [RESET] by itself to return to BASIC. (Reboot if a disk drive is connected.) LIGHT GUN T u}he XEGS comes with a light gun called the XG-1. The Nintendo light gun is more accurate -- if something is lined up in its s v}ights, that's exactly what you hit. Not so with the XG-1. You'll find that it often shoots to the left or right, depending w}on the software you're running. The XG-1 is simply a specialized light pen. Light pen support was built into the earlie x}st Atari computers, but it never really caught on. In the shape of a gun, the light pen has brought a whole new dimension to y} video games applications. The light pen horizontal position, LPENH, can be PEEKed at memory location 564, and the vertical z}position, LPENV, is found at location 565. Light gun values range from 0 to 227. You will notice that your horizontal r {}eadings are quite odd. Try the sample program below, and notice how the GUN-X readings vary as you sweep the gun across the |}screen, left to right. 10 LPENH=564 20 LPENV=565 30 GRAPHICS 0:POKE 752,1:POKE 712,15 40 POSITION 0,0:FO }}R I=1 TO 4:? "0123456789";:NEXT I 50 ? "GUN-X=";PEEK(LPENH);" " 60 ? "GUN-Y=";PEEK(LPENV);" " 70 ? "TRIG ~}R=";STICK(0) 80 GOTO 50 Point the gun to the far left of the display and GUN-X will read about 88. Moving from le }ft to right, the reading will reach 227 at about column 34. Then suddenly it drops to 0 and increases again to about 30 at c }olumn 39. This offset is due to the delay between when a pixel is actually lit on the display and when the information is re }layed from the light gun sensor to the POKEY chip, which latches an internal scan counter for the pen reading. The old A }tari 400/800 Hardware Technical Reference recommends a "calibration procedure" each time the light pen is used, so that the s }oftware can compensate for this offset. A calibration procedure would improve the accuracy of the light gun. But Atari's Bug } Hunt and Barnyard Blaster games both have "hard-coded" values -- different ones in fact. While Bug Hunt appears to shoot sli }ghtly to the left, Barnyard Blaster seems to shoot a tad to the right. The Y readings for the gun are more predictable, equa }l to half the number of the currently displayed scan line. You'll notice with your test program that GUN-Y only varies from }about 17 to 115. Note that you get much better performance out of the light gun near the screen edges, when you use a light }colored border achieved with the POKE 712,15 above. You'll need to perform some computations to adjust for these unusual } readings, to convert gun coordinates to screen coordinates. Different conversion factors are required for each graphics mod }e (and P/M graphics). The gun won't return reliable readings at all if the intensity of the display is too low. That's }why the screens for Atari light gun games may be brighter than usual. The game screen will momentarily flash white whenever }you press the trigger in either Bug Hunt or Barnyard Blaster. While the screen is all white, the software reads the gun posi }tion and provides the most accurate values. Listing 1 presents a simple Graphics mode 8 "spray-painting" program for tes }ting the XG-1. Dots are drawn whenever the fire button is pressed. Try holding the gun very steady to see how much jitter y }ou get in the readings. These inaccuracies are reflected in your games as well. I feel that, at the higher levels of play, }Bug Hunt and Barnyard Blaster both require more accuracy for continued play than the XG-1 can deliver. Atari has informe }d me, however, that the XG-1 and a revised Bug Hunt will be released as a separate package. If you're tired of waiting, you }may wish to pick up the Sega light gun, for about $25 (when on sale) and modify it for the Atari. To modify the Sega gun } for the Atari, you'll have to cut off the incompatible connector. The wires must be stripped back and soldered into an Atar }i joystick connector as follows: SEGA GUN ATARI JOYSTICK PORT Blue wire Pin 1 stick FWD Gray wire }Pin 6 trigger Green wire Pin 7 +5 volts Black wire Pin 8 Ground Because of the close-fitting connectio }ns for the XEGS ports, don't wire in a DB9 female connector that has "ears." Most joysticks don't have wires for unused signa }ls, so cutting up an old joystick cable may not work. Specifically, an Atari joystick does not need the +5 volts, so there i }sn't likely to be a wire connected to Pin 7. However, you can find joystick extension cables at Radio Shack, which have all }nine pins wired from male to female. ANTIC disclaims responsibility for any damages that might occur during improper impleme }ntaton of this, or any, hardware modification project we publish. Once it's all hooked up, you'll notice that gun fires }when you release the trigger, which is annoying. The Sega trigger wiring is the opposite of what the Atari light gun uses. }To rewire the trigger switch, remove the five screws (one is under the Sega logo on the side). Find the trigger micro switch } with three connections. Wire to the normally closed contacts instead of normally open. XEGS MANAGER Listing 2, X }EGSMGR.BAS, is a BASIC loader that lets you create a machine language file on disk. Type it in, check it with TYPO II and SA }VE a copy before you RUN it. The file XEGSMGR.EXE can then be loaded from DOS or renamed AUTORUN.SYS. Many of the program's } features also can be applied to Atari XL/XE computers. Normally you must press the [OPTION] key at boot time to disable } BASIC and go directly to DOS. And once BASIC is off, the only way to get it back on is rebooting. Option 1 of XEGS Manager } is to turn internal BASIC on, and option 2 turns it off. Disabling BASIC while in DOS provides an additional 8K buffer }for file copying. This is an important feature for owners of a single drive. Quite often, BASIC must be off before certain }machine language files can be loaded and run. The XEGS Manager eliminates the need of rebooting every time that BASIC must be } re-enabled. SELF TEST The XEGS Self Test lets you test the computer's sound registers, keyboard, and memory. How }ever, BASIC is not turned off automatically when Self Test is run from the BYE command. This means that the 8K of RAM under }BASIC isn't tested. Option 3 from the XEGS Manager lets you run the Self Test with BASIC off, so that the maximum ammount of } RAM is tested. RAM OS All of the operating system of the XEGS (and 64K or more XL/XE machines) is "shadowed" by R }AM. Some disk operating systems, such as DOS XL and SpartaDOS, use hidden RAM for many of their own functions. However, if }you're using Atari DOS 2.0 or 2.5, then there is a lot of RAM going to waste in your machine. Option 4 of the XEGS Manag }er lets you enable a RAm-based operating system so you can do some real "hacking" -- disassembling and adjusting parts of the } XEGS operating system to suit your needs. Even if you're not a hacker, there are other practical features of a RAM OS. } Once the RAM operating system is enabled, you are prompted for a disk drive number, 1-8 or 0 to exit. A custom font can be }loaded in place of the standard one in the OS ROMs: enter the drive number to display a directory of all .FNT files. Then e }nter the name of the font file to load, or simply press [RETURN] to change drives or disks. You needn't enter the drive }specifier or extender -- the XEGS Manager will take care of that for you. The font file is loaded into memory at $E000 (5734 }4). Then you're prompted to (1) repeat the process and try a different font, or (2) exit. (You will find some font files on } this month's disk as a bonus.) Your RAM OS and font are reset-proof, too. Pressing the [RESET] key causes the XEGS to }re-enable the ROM-based operating system, but a special handler in Page 6 of memory takes control after that. The handler co }nverts the ROM back to RAM, recopying all the essential parts of the ROM OS, in case part of this RAM area got clobbered whil }e you were hacking about. The handler does not recopy the ROM OS font, however, leaving yours intact. Should your RAM font }get garbled somehow, press [RESET] while holding the [START] console key to return to the ROM font. Each time that [RESET] i }s pressed, a RAM OS prompt is displayed at the top of the screen as a reminder. If you enable a RAM OS while running Spa }rtaDOS, the XEGS Manager detects it and prevents the installation and subsequent system crash. The Manager does not automati }cally detect any other DOS, such as DOS XL, which may crash when a RAM OS is enabled. MISSILE COMMAND Again, if yo }u turn on your XEGS without the keyboard connected (or hold down the [SELECT] key at power-up), Missile Command fires up auto }matically. Option 6 of the XEGS Manager will get you into Missile Command without having to mess with any console keys or po }wer switches. CONCLUSIONS The XEGS is a superb little computer. It's still a hacker's system too. I've found tha }t the PBI ROM routines are intact, which means that you should be able to hack in your own custom PBI connector and use the X }EGS with ICD's MIO board, if you're a real solder jockey. The XEGS has brought along a lot of new software too, somethin }g Atari was counting on. Much of it includes repackaged classics or cartridge conversions from disk-based software, but ther }e are a few new titles such as Battle Zone. Atari's new 256K bank-switch cartridges are not likely to be pirated. This means } that the piracy threat for 8-bit Atari software should be minimal, thus attracting more new software vendors from the tradit }ional Apple and Commodore markets. If Atari can provide a responsive cartridge production service for third party softwa }re vendors (something the old Atari never would have done), then we're likely to see the software base for the 8-bit Ataris g }row with the popularity of the game industry, which is definitely on the rise again. (bio) Matt Ratcliff is a St. L }ouis aerospace engineer and a longtime ANTIC contributing writer.  }Pee`/eeL>(ee 2XIO41.BIN can be loaded with option L of the DOS 2 menu, or renamed AUTORUN.SYS so that it boots up when the computer is t}urned on. This file will alter DOS 2 so that it will accept the XIO 41 (binary load) command found in DOS 3. The synta}x for the command is: XIO 41,#n,a1,a2,"D:filename.ext" n is the channel number. If the user specifies a1<>0, the star}ting address will be displayed. If a2 is specified as 100, the program will be run at the starting address. If a2 is sp}ecified as 200, the program will be run at the RUN or INIT address found in the loaded file. Please note that BASIC pro}gram files, LIST files, and text files will be rejected by this command. In addition, when XIO41.BIN is run, DUP.SYS is }loaded and the bottom of memory reset, so that when the DOS menu is called up, the menu appears right away, and any BASIC }program in memory is not erased. A second version of this program will be uploaded soon. The 2nd version will not load} DUP.SYS, and the DOS menu cannot be called up so that there is more memory available for users. This program is for us}e only with DOS 2. If it is run with DOS 3 in memory, it will probably lock up. For reference, the following memory lo}cations are altered during inititalization: (HEX) (DEC) $0A,$0B 10,11 $0C,$0D 12,13 } $80,$81 128,129 $02E7,$02E8 743,744 The following memory locations are used during the XIO process: (H}EX) (DEC) $CB-$D1 203-209 $0238,$0239 568,569 Enjoy this program. If you have any questions or }comments, drop me a line via the SIG or through E-MAIL. Rich Whitsell [75056,1527] .7@ term}inal program doesn't work with CompuServe's XMODEM, but it works just fine with} everybody else! What are you doing wrong???? Answer: The XMODEM protocol was never }designed with the idea of communicating over a packet switching network to }large time sharing computers. The biggest problem comes from the fact that the } network introduces delays between the host and the micro and that the host may not be able to res}pond quickly to the micro's communications. Most terminal programs do work with} CompuServe, and many that do not can be patched to work with CompuServe (e.g., }Crosstalk) by simply relaxing the timing parameters in the program. See: Section 3.1 } Question: Does your XMODEM implementation handle CRC checking as well as checksummi}ng? Answer: Yes. See: Section 2 Question: Where can I find documentation on th}e XMODEM protocol? Answer: The closest thing to an official document } specifying the XMODEM protocol is a small notes file Ward Christensen wrote describing the } basic protocol. This file can be found in many of the SIGs on CompuServe. } See: Reference [1]. - 2 - } XMODEM on CompuServe October 1984 0. Abstract C}ompuServe has implemented a version of the XMODEM protocol that allows most XMODEM users to successfully transfer} files securely between their micros and CompuServe's hosts. This implementation was not and cannot b}e 100% faithful to the original XMODEM specification (see reference [1]), and the differences betw}een micro to micro XMODEM and micro to host XMODEM has caused some people problems. The purpose of this } short article is to describe, in detail, the most frequent problems people have with micro to host XMODEM, an}d to offer some suggestions on how to overcome these problems. 1. XMODEM's origins } The XMODEM (aka MODEM7) protocol was originally devised by Ward Christensen as a protocol for communicato}ns between microcomputers. As it was originally devised, the user runs a program called "MODEM", and } dials up another computer. The user then instructs the remote computer to run a program called "XMO}DEM". XMODEM and MODEM then use the XMODEM protocol to transfer files between the two computers. } The XMODEM protocol has several assumptions implicit in its design, and these assumptions are the source of th}e problems people have in using XMODEM protocol on CompuServe. Some of these assumptions are: } o File lengths are exact multiples of 128 bytes. o Word size is 8 bits on both computers. } o Data is transmitted 8 bits, no parity, one stop bit. o Both computers are dedicated (single  } user) microcomputers. o Both computers are talking to each other directly  } over a phone line. 2. The XMODEM protocol The XMODEM protocol is a half duplex pro }tocol -- infomation travels in only one direction at once. The basic protocol works something like  }this: 1. When the receiver is ready to start receiving data, it transmits a  }(negative acknowledgment) - 3 - XMODEM on CompuServe} October 1984 character to the sender, and continues to do s}o every 10 seconds until: 2. The sender sends a block. Each block contains the } block number (modulo 256), 128 bytes of data, and a checksum. Once the block is sent, the} sender waits while: 3. The receiver verifies that he received the block } correctly; if the received checksum matches, then the receiver sends an character, }and the sender sends the next 128 bytes of the file (step 2). If the block was no}t received correctly -- or if 10 seconds expires before a complete block is recei}ved, the receiver sends a character to the sender. When the sender receives a , it } re-transmits the last block. 4. Steps 2 & 3 are repeated until the end of the file. } At the end of the file, the sender sends an character instead of a block of data. } 5. When the receiver sees the , it sends an to the sender, and then the f}ile transmission process is complete. There is a variant of the XMODEM protocol that C}ompuServe also supports, called the CRC option. In the original XMODEM protocol, the checksum of} each block was only one byte long. This small of a checksum (along with the algorithm use}d to generate it) allows errors to easily sneak into a supposedly error free protocol. The CRC option} works roughly like this: Instead of the receiver sending out s at the very beginning, it sends } out the letter "C". If the sender has the CRC option, it treats this just like a , but knows to }compute the two-byte CCITT CRC-16 and add it to the end of all blocks instead of the one byte check }sum. If the sender does not have the CRC option, then the "C" character has no meaning to it and !}is ignored. The receiver may try about three "C"s before deciding that the sender will not handle CRCs, and "} then the receiver transmits a to start a checksum-XMODEM file transfer. #}3. XMODEM Problems on CompuServe - 4 - XMODEM $}on CompuServe October 1984 Because of the assumptions made in the XMO%}DEM protocol, various difficulties arise in using XMODEM over CompuServe. Here are some major classes&} of problems: 3.1 XMODEM Timing Since XMODEM was originally devised for micro-to-micro '} communications, it has some problems fitting into an environment where one of the computers ha(}ppens to be a mainframe and the two computers are not connected over a simple phone line but )}via a packet switching network. CompuServe's network can often introduce long delays in what should*} be continuous communications, as can a very busy host. When these delays arise, the microcompu+}ter running XMODEM may mistake them for a breakdown in communications. If a long delay occurs in ,}the middle of a packet -- in the middle of the data -- many XMODEM implementations see that as me-}aning there has been data lost. These delays result in the following symptoms: o The receive.}r cannot successfully receive even the first block of data. o The receiver consistently/} s blocks or s a majority of blocks, although eventually receives the file. 0} o The receiver just suddenly gives up in the middle of a seemingly successful file transfe1}r. o The receiver has great difficultly in receiving the file, and gives up anywhere fr2}om 5 to 20 blocks through the transfer. o The file transfer proceeds very smoothly wit3}h several successfully transfered blocks when all of a sudden every block transmitted i4}s rejected (ed) by the host. Note that all of these problems are indistinguishable f5}rom other communications problems (e.g., noisy phone lines, bad parity settings). A key question to 6} ask people who are having XMODEM problems is "Have you ever successfully done a XMODEM transfer to 7}CompuServe?" If the answer is yes, then the following problems may be at fault. 3.1.1 Delays with8}in blocks The XMODEM documentation [1] recomends that a gap of more 9} - 5 - XMODEM on CompuServe October 1984 th:}an 1 second be treated as a breakdown of communications. On a microcomputer, this makes sense -- there is no r;}eason for a dedicated micro computer to suddenly stop transmitting and then resume. But on CompuServe<}'s systems and network, a 1 second delay is not only possible, but happens frequently! =} If the microcomputer decides that this delay is a breakdown of some sort, it will send a to CompuSe>}rve, requesting that the block be retransmitted. Unfortunately, the rest of the first block is still "?}in the pipe" -- and when the receiver gets this block the receiver may do anything from abort t@}he transfer to ignore it. Assuming the receiver handles the rest of the block gracefully (and the rest ofA} the block doesn't look like the start of another block), the host will see the the receiver sentB} and retransmit the block. If there's a delay in the middle of that transmission, the receC}iver will it too, and so on forever. Thus, when the receiver is too sensitive to delays D}in the middle of transmissions, either the receiver gives up very quickly or the receiver s eveE}ry block transmitted. 3.1.2 Delays between blocks Fortunately, most implementations of the XMOF}DEM protocol aren't that sensitive to delays in the middle of blocks. But other delays can cause pG}roblems too. When a block is received by the microcomputer, for example, the micro will almost imH}mediately or the block and wait for the next block to be sent. The XMODEM specification [1] states I} that if the next block does not arrive within 10 seconds, the receiver should send its or J} again. Ten seconds is not a very long time, however, when the network and/or mainframe is heaK}vily loaded. Often, what will happen is that the or will arrive at the host, the hosL}t will begin transmission of the next block, but the block won't make it to the micro in time. Then, the M} micro transmits a , even though the host has correctly received the first /. WhN}at happens, then, is that a enters the network, even though the host has seen and responded to the O}first or . After that, things can easily degrade. The host may find itself one block aP}head of the receiver, causing the receiver to give up on the spot. The host may Q} - 6 - XMODEM on CompuServe October 1984 R} find itself stuck one or behind the receiver, which could result in a successful, althouS}gh very difficult, file transfer. And the network problems could be severe enough -- or the micro T}sensitive enough -- that the micro goes through about 6 or so blocks (mostly s with a few s) and gives up. 3.1.3 Network Flow Control When the user is sending data to CompuServe, the noV}de will send an XOFF (^S) character to the micro if the micro is transmitting faster than the nodeW} can send the data to the host. This happens even during an XMODEM transfer (although very infrequenX}tly). If the micro misinterprets the ^S as a , it will immediately retransmit the block -- causing Y} the network to send even more ^Ses and the micro to see even more naks. Usually what happens is that the mZ}icro thinks that every block it transmits is being ed, and the micro gives up almost immedia[}tely. This problem can strike anytime during an upload to the host, and things can be proceeding\} very smoothly upto that point. 3.1.4 Timing suggestions and hints To overcome and avoid these p]}roblems, an XMODEM protocol implementation should wait 20 seconds before sending a on a lost b^}lock, wait at least 10 seconds during delays in the middle of a block, and honor (or at least ignore) flow _} control from the node during uploading of files. Many programs which have timing problems with CompuServ`}e can be patched to relax their timing restrictions. A typical place to look is for calls to a "tima}ed input" routine (where the routine will only wait so long for a character to arrive). Either b}patching that routine (make it wait twice as long, perhaps) or patching the code that calls the c} routine (to use a longer time out value) would help to make the XMODEM work on CompuServe. 3.2 d} Host file Format Concerns 3.2.1 The Host file format problems While almost all microcomputers he}ave an 8 bit word (or multiple of 8 bits), CompuServe has a 36 bit word. Text files are storef}d with 7 bit bytes (5 of them per word). While this poses no problems for pure text files (as the g} ASCII character set is defined for only 7 bits of data), - 7 - q}BDTREK2 DOCBHTRKBLL TXTBMTTT DOCBuRXEGS DOCBXIO41 DOCBXMODEM DOC XMODEM on CompuServe October 1984 "binary" files cannotr} be stored as is on our host systems (an example of binary data would be an executable program, ors} a WordStar file). Files in which 8 bits of data per byte must be preserved -- binary files -- are stored in a spt}ecial file format (currently Intel hex format). Thus, when people upload or download to CompuServeu} using XMODEM, they are asked: Transfer types available, 1 - ASCII (7v} - bit) 2 - Binary (8 - bit) Please make a selection: People often pickw} the wrong answer, the results are either an unsuccessful or useless upload or download. 3.2.2 Thx}e correct approach For uploading, the choice of a transfer type can be as simple as: "If it's ay} text file, use ASCII. If it's not, use binary." For downloading, the correct transfer type is thz}e same one that was used to upload the file, i.e., if the file was uploaded with an ASCII transf{}er it must be downloaded with an ASCII transfer; if the file was uploaded with a binary transfer i|}t must be downloaded with a binary transfer. At the moment, it is a problem for users to determine which }} type the file was uploaded in. Many SYSOPs have the file's description specify the correct approach for ~}downloading. Other SYSOPs enforce the convention that files with a ".BIN" extension should be download}ed with the binary transfer while other files should use the ASCII transfer. It is best to as}k what policy is in use if there is some doubt. In the future, the SIG program will be improved so that the } choice of which transfer type won't be asked during a download. 3.2.3 What happens i}f... The user downloads a binary file with ASCII mode? The user gets the Intel hex format of }the file. The - 8 - XMODEM on CompuServe } October 1984 downloaded file can be salvaged by use of a program to } convert Intel hex format back to binary. Currently, the IBM Novice forum (PCS-129) has such }a program available. The user downloads an ASCII file in binary mode? The use}r usually receives one or two blocks of garbage data, at best. The user uploads a binary file i}n ASCII mode? The file transfer will not succeed, and any files left over after the upload} will be useless. The user uploads an ASCII file in binary mode? The file transfer will succee}d, but the uploaded file will be encoded into Intel hex format. Thus, any people who} download the file in ASCII mode or use the Read command will receive a hex representation of the } file. People who download the file in Binary mode, however, will be able to receive the file co}rrectly. 4. XMODEM and .... 4.1 CROSSTALK (XTALK), version 3.4 Crosstalk ha}s its timing parameters set too sensitively. Thus, it is virutually impossible to perform transfers using } Crosstalk. MicroStuff, the creators of Crosstalk, have provided a patch to their software which allow}s it work with CompuServe. This patch can be found in the IBM PC SIG's database (see reference [2]}). - 9 - XMODEM on CompuSer}ve October 1984 4.2 PC-TALK III PC-Talk will work fine w}ith CompuServe, so long as the user is running PC-Talk in 8 bits / no partiy mode. The most recen}t version(s) of PC-Talk are set up to switch to 8 bits / no parity automatically on an XMODEM transfer, but the}se versions are still rare in the user community. By default, CompuServe communicates in 7 bits, ev}en parity. Thus, before PC-Talk can be thrown into 8 bits no partiy, the user must tell CompuServe }to talk 8 bits no parity. The steps involved in making this change are as follows: 1. The u}ser must log into CompuServe as usual (i.e., 7 bits even parity). 2. The user must the}n run the Default program. This program can be reached either by typing "R DEFALT" } from command mode in the personal file area (the "OK" prompt), or by typing "GO DEFALT" from any "}!" prompt. 3. In Default, the user should select option #5, "View }or Change current terminal parameters." Then, he should select option #8, "Parity is", change } parity to ZERO, and then exit the default program, making all changes permanent. } 4. At this point, PC-Talk can be switched into 8 bits no parity. On some modems (but no}t most of the Hayes line of modems), doing this switch will cause the modem to han}g up. Thus, it may be advisible to log off CompuServe before switching to 8 bits no } parity. 5. Once PC-Talk is running in 8 bit mode, it is possible to easily} upload and download using XMODEM. The next time the user dials into CompuServe (wi}th PC Talk set to 8 bits no parity) and types control-c to catch the system's attention, the "User} ID:" prompt will be garbled. Once the system recognizes the User ID, however, the } - 10 - XMODEM on CompuServe October 1}984 password prompt will be presented in clear text. Thus, users should just muddle through t}he garbled User ID prompt and everything will work well after that. If the user's modem does not h}ang up when the parity setting is changed, it is also possible to change to 8 bits no parity just} before performing an XMODEM transfer, and change back to 7 bits even parity when it completes. This is a } rather involved, manual process, though, and is not recomended. Note: Putting PC-Tal}k into 8 bits no parity is necessary even to upload or download ASCII files. } - 11 - XMODEM on C}ompuServe October 1984 References } ---------- [1] "Modem Protocol Overview" by Ward Christensen. Found }various places throughout the system, including the Programmer's SIG's XA2 database in the fi}le "PROTO1.DOC". This document is the starting point for anyone desiring to implement t}he XMODEM protocol, although the changes and suggestions presented here should be kept }in mind. [2] Crosstalk XVI 3.4 patch. Found in the IBM SIG's XA5 database in the file CISXT}K.TXT. This requires some sophistication on the part of the user, as it involves patchin}g Crosstalk using the PC-DOS debug program. } - 12 - 6.+67,.467,.7$!-&@ ( !$*@A-'B7tA*$9@K-A@d9AAdAU$Q6-@69}-6-!6-'6-66. quarterB6-@Q:6.BBT76.:$L#9}6-C:.9/5 >Z#( -?!6*,7%@@4L좠!!ΠТ" 6-R:,""@9})A07"@!@#6-&- A7 A7"@ @#6-%- A7 A9}O6-F:Ad,AU0AdAUE6-?:<<@"<,O A`(T:,A & A9}0(A:AAAA A0A@APA`ApAAA9}AA0AAAAAAAA CD! 6-6. whole! A9}MNa 6-6- A%6-%7-@@"M(chord off W A a A%X 9}Aab 6-6. half Akl(6-@6. quarter( Au۸9}v'6-@6. eighth' A۶囀)6-@6. sixteenth) A۳ݲ囊*9}6-@2 6. thirty sec* Aۮݧ囔 6-( A回6-+(*(, A9}ۣݠ 6- Aݠ 6-6 A웼 6- A  6-9}6- Ac 6-6.#@A/6-@A6-%+"@,G6-M6-S6-Y6-c A 9} AI)6-?::,67,.>:,*67,.6"@ B6-@;67,.>:,;67,.>:@:7,,%A(%@r$+",,9} 6-%(6- A 6.7%+(,, A'6-%%+,!@' AP A9} AK۪LN A (*( enter chord D( then press returnN A%VS A9}PA6-+6. G6-C: *~abcdefgmj+-#67,SAU`i )-6-?:<<@%@$+!,<,[%9}A APA`A`Api"A j;!@6./6-@:7&@,,;t=67<9},.>:,!-&%@ +(>:,36-%= A ~!A% 6- A  A0%㛒> !67&,.9} '-&@ .(66-&> A V6-@:,&@"6.%#! 06-%@:7,,<6-@H6-@9}V"A> -&%7<,46)7<,47>6-@ %+7<,47,M  6-6-@:7,,56-+"@,&+"@59},=6-%AM6-@7<,46-@(7<,4d6-@(6-@7<,46-@9}7<,0mA,7%<%,4  6-@,6-@,B:,!% 7%<%,4aj,6-@ ,7%<9}%,4 6-@,6-@,7%<%,4 6-@,6-@ G 6- A!67%,.7,167%,.7&,9}G67%@,.7&,(!6-%@6-!67,.2QA@dQ6-?:46-@6-@h% )"AU% ArS"A&!@#6-&1-%@9};( I-%@S A@|C#!@) @e)!@C%+"@',A@A@467,.>:,"(9}>:%A(,*6-%4 A@ 4D:6.C:L A@ &@,"@3:B6-%L A9} 6-&((?6-?:<<-@PB 1 6- Ap AP' A1 A 9}W-@"&(press to exit0 AP7)C@M AW A6-?:B, 9}J-@-2@@@5-9 C2G J$ , A%-@ ) A,$ 9} / +@AY%AV/ A@ 4Ap(%6-F:A`,46-F:Aa, A6-6+9},((} the musician ll:-@@"A( i)6-?: 1>lx 1>lx9}xI6-$AV6.(67A%,.167,.I6-?:}5/<5yQ@@yfD@DUQUHHl`[HHrLHL`[`lQyff[̭lfUHl[}-}}    ԏ  >}   ԋ  ԏ  <5VDATMOVPMBASSPABARBhdBh@@$ KKӢB}󬠠à묠àH;A,H6-C:.hhhhhhh`,"B }AF:A@,"+@(s=6.3h ! ԍЌнн н#LU67@4,.>:@4,s6-?:',A@P'/A0F+}@P@9/A0@`'/A@`9/A@PD$F @H',@P@U'/A@UF,}J$P-@R-@T0@U!!2@ @@&V X w$xF-} +@.-@@.(HOW ABOUT THIS...$ +@0@0F.}@@-@A@@#,@ #/@$A@ -@0@F/}"-@ , .-@0-@@20@&3-@ 4 6F0} ;0@?$@J +@O 0T#-@@#(SOUND!Y-@P F1}^-@c2@@%@h 0m-@ r |-@62@ F2}-@  $ +@(-@((YOU HAVE A CHOICE%-@%(F3}OF 8 DIFFERENT-@('VOICES'-A (-@((HIT IT MAESTRO...$F4}Š 6-@ A   6- A   6- A -@P  6-Q:,2@&F5}(S:,)(T:,A0 Ab 2k$lv +@" -"(YOU CAN EVEN HAVE+F6}-@@+(UP TO 4 VOICES(-@((AT THE SAME TIME!-A 2AP@F7}-A 2@@@@-A 2@@@-A F8}%%2@A@@-A -@ %%2AP%@%'@!!2@@F9}&@@!!2@@ %@//2@A%@$@@(S:,)(T:,AF:}  AR 2 22@2@$+-F;}@( ( THANK YOU( ( ((,)(! ANOTHER WRIGHT-ON PRODUCTION,(-@6 F<}2@ @-@@   "-@@6$ 0& * 6-3$ D:F=}SLIDSHOW@-@@   "-@@6$ 0& * 6-3$ D:D DISK CONTENTS - Front Side of Disk1. DISSOLVER CRE. Creates BASIC sub-routines for spiral or sweep dissolvesof any graJ?}phics mode screen. Excellent!Refer to magazine for "how to use".(Fred Pinho, ANTIC 1/86, p18)2. DISSOLVER DEM. A clever J@}demo of the"Dandy Dissolver". (Fred Pinho, ANTIC,1/86, S*P*A*C*E mods)3. FACE. "Face of the Galaxy" - Musicwith graphicJA}s. (Gary Gilbertson)4. FADER II. An enhanced ML Hi-Res picloader with dot-by-dot "lapse-dissolve"effects. To use: TransfJB}er to a picturedisk & rename AUTORUN.SYS. Compressedpictures (ie, KoalaPad, Micro Illustr.)must use a ".PIC" fn extender. JC}Normalpictures (ie, Micro Painter, any 62sector pic) use ".*IC" fn extenders.Reboot with this pic disk to view your"slideJD} show". Press OPTION to hold apicture on the screen; START to skipthe pause between pics; or SELECT to goto DOS. (PatrickJE} Dell'Era, ANTIC 5/85)5. FADER MOD. Use to change FADER II'spausing rate. Self prompting. BASIC.(Patrick Dell'Era, ANTICJF} 5/85)6. 3D GRAPHICS. A 3-D graphics editor.(Paul Chabot, ANTIC 10/85, JC mods)7. G.U.P. The Graphics Utility PackageJG}is a ML program which will speedup yourBASIC graphic commands & adds ten newones: circles, squares, patterned fills& more!JH} Read the magazine article forfull tutorial/instructions. For bestresults rename to AUTORUN.SYS & rebootto load. If loadedJI} from this menu, youmust press RESET upon load completion.(Darek Mihocka, ANTIC, 6/85, p45)8. G.U.P. DMO. A demonstratioJJ}n of someof G.U.P.'s capabilities. Load G.U.P.(per above) prior to running this demo.(Darek Mihocka, ANTIC, 6/85)9. HORSJK}E. A galloping horse demo usingcharacter graphics. (B.R.A.C.E.)10. MILOADER. Loads/displays Micro-Illustrator (KoalaPadJL}) pics. (ANTIC&JC)11. MUSICIAN. A "Music construction"program. Integral command list. Allowsediting of last note only! TJM}his versionis not compatable with the original!(A.Giambra, ANTIC, 6/85, pg37, JC mods)12. LAURA. Demo tune for The MusicJN}ianabove. Load "LAURA" to hear it play orto edit. (ANTIC disk, 6/85, JC mods)13. PENCILS. A sharp GTIA demo! (GreggTravJO}ares, ANTIC disk, 6/85, JC mods)14. SLIDE SHOW. A BASIC demo using theAtari to present computer "slides".(Steve Wright, JP}from B.R.A.C.E. disk) DISK CONTENTS - Back Side of Disk(NOTE: These programs should be loadedw/o BASIC to insure propeJQ}r operation.)1. FUJIBOINK. Famous Atari demo with abouncing multi-color "Fuji" logo.(Park '86)2. MCP. Multi-Colored PJR}layers demo.Brilliant colors. ML. (ANTIC 2/86)3. SPLASH. Splash colors on a Gr.7+screen. ACTION. (ANTIC, 4/85)4. SWAN.JS} Another sharp Atari demo withflying swan & twirling Fuji. (Park '86)5. VIEW 3D. Create 3-D wire frame picsin Gr 8/7+. JT}Magnify, shrink, rotate, &shift viewing position fairly fast. Seemagazine article for details. ACTION.(Paul Chabot, ANTIC JU}6/85, p37)6. HOUSE.V3D. A sample VIEW 3D image.(Paul Chabot, ANTIC 6/85)rticle for details. ACTION.(Paul Chabot, ANTIC HM