Z*Magazine: 6-Nov-88 #130
From: Atari SIG (xx004@cleveland.Freenet.Edu)
Date: 09/18/93-04:39:38 PM Z
From: xx004@cleveland.Freenet.Edu (Atari SIG)
Subject: Z*Magazine: 6-Nov-88 #130
Date: Sat Sep 18 16:39:38 1993
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
SYNDICATE ZMAGAZINE Issue #130 November 6, 1988
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Publisher/Editor: Ron Kovacs
Post Office Box 74
Middlesex, NJ 08846-0074
CONTENTS
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
(#) Editors Desk.......................Ron Kovacs
(#) ZMag Newswire................................
(#) Zmods (1200XL Modification)....Charles Koontz
(#) Notes on Programming..........Ctsy Atari8*SIG
(#) ZMag Newswire Part 2.........................
(#) ST Section...................................
(#) PC Pursuit Recommendations...................
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
This issue conveyed via Paybax BBS. 302-731-5558. All bauds.
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Editors Desk
-----------------------------------------------------------------------
We are back on GENie in the Atari 8 Bit RT. Our NEW GEnie Mail address is
ZMAG. Please make a note of this if you want to contact us in the future.
November 8th is here and it is your RIGHT and NEED to vote. The ritual of
elections cannot be complete if we DO NOT take advantage of this right.
Please attend the Formal Conference on CompuServe November 9th at 9pm EST.
The guests for this CO will be Ralph Mariano, Editor of our sister
publication ST-REPORT. I will also be there to field your comments and
questions. Enter GO CONVENTION at any CompuServe prompt to enter this CO
area.
Please give the SELECT BBS a call at (916) 392-7279!
November 8: Election Day
November 10: Day of Founding of the Marines 1775
November 11: Veterans Days
November 13 - 19: American Education Week!
Thanks for reading ZMAGAZINE!
ZMag Newswire
-----------------------------------------------------------------------
SUNNYVALE (NOV 1) USA Today: Atari reported they will be giving credit for
purchasing Atari cartridges. They are sold presently at a cost of $10 to
$30 each. Also stated in the article, Atari will give prizes and give
away a two week vacation. If this expirement works, they will continue
this promotion as a way of luring more people to purchase Atari products.
COMDEX UPDATE: (NOV 6): Atari failed to register on-time for the Comdex
preview. (Ed. Hope this isn't s sign of things to come.) The Laptop seems
to be the highlight scheduled along with desktop publishing displays.
Z-Mods
-----------------------------------------------------------------------
Atari 1200XL Split Chroma Modification
by Charles D. Koontz
This easy modification to the 1200XL provides a true chroma output to the
1200XL monitor jack. It allows the use of "split video" monitors for
sharper images and truer color.
This modification involves installation of one wire to the foil side of
the 1200XL main circuit board (motherboard). Now to get the usual
tiresome, but necessary, warnings out of the way:
This modification is installed at the risk of the user. Any warranty on
the 1200XL will be invalidated. The author assumes no responsibility for
damage done during, or by, the modification.
EQUIPMENT REQUIRED:
(1) Screwdriver - Phillips head
(1) Screwdriver - blade
(1) Soldering iron & solder
(1) Wire cutter or knife
THE MODIFICATION
1. Disconnect all power, TV, stick, paddle, drive, MIO, etc. from the
1200XL.
2. Turn the 1200XL upside down on your work surface.
3. Remove the six Phillips head screws securing the bottom of the 1200XL
to its top.
4. Carefully holding top and bottom together, turn the unit upright.
Move the top away from you, exposing the keyboard ribbon cable
connectors.
5. Make a note of the mating polarities of the keyboard ribbon cable and
its connector.
6. Push the keyboard connectors away from you, disconnecting the top and
keyboard from the motherboard.
7. Remove the top (and keyboard) assembly and lay it aside.
8. Remove six Phillips head screws which secure the motherboard to the
bottom shell.
9. Remove the left plastic cartridge and joystick frame and lay it aside.
10. Remove the motherboard from the plastic bottom shell. Lay the bottom
shell aside.
11. Using a flat blade screwdriver, gently pry up eleven "pop" fasteners
that secure the top and bottom shields to the motherboard.
12. Position the motherboard in front of you just as it would be if it
were still in the 1200XL.
13. Find transistor Q19 in front of, and slightly to the right of, the
large upright cylindrical electrolytic capacitor (C39) at the right
rear of the motherboard.
14. Just to the left of Q19 is capacitor C118. The left lead of C118 is
where the chroma signal appears. Find its connector on the foil side
of the circuit board and solder one end of an insulated hookup wire
to it.
15. Before cutting the other end of the wire to length, carefully route
it so it will fall under one of the elevated areas of the bottom
shield edge when the shield is replaced. The other end of the wire
must reach pin 5 of the monitor output jack J2.
16. Solder the other end of the hookup wire to pin 5 (the unused
connector) of the monitor output jack J2.
17. Carefully re-position the top and bottom shields on the motherboard,
making sure the new wire is not pinched by the shield edge and the
insulating sheet is in place under the bottom shield.
18. Fasten the shields to the motherboard by pressing the eleven "pop"
fasteners into place. WARNING - BE CAREFUL NOT TO CUT YOURSELF ON
THE SHIELD EDGES.
19. Position the motherboard in the plastic bottom shell. Position the
left plastic cartridge and joystick frame in place.
20. Fasten the motherboard to the bottom shell with six Phillips head
screws.
21. Position the keyboard and top unit on top of, and slightly to the
rear of, the bottom.
22. Reconnect the two ribbon connectors from the keyboard to the
motherboard.
a. Large black connector is fastened without twisting its short ribbon
cable.
b. Small black connector is fastened with the red stripe on its small
grey ribbon cable to your left.
23. Move the top unit into position over the bottom.
24. Holding the top and bottom together, turn the unit upside down.
25. Fasten the top and bottom together with the remaining six Phillips
head screws.
26. You're done!!! Find a monitor cable terminated with four phono plugs
and you're in business.
Radio Shack has such a cable. (If it's the same as mine the plugs are:
black-audio, red-luminance, yellow-chrominance, white-composite but unused
with a split video monitor like the Commodore 1702.)
On the chance that your cable is wired differently, some experimenting
will be necessary to find the right hookup. Plug the din connector end
into the 1200XL monitor jack. Turn on the 1200XL and run a disk or
cartridge program that uses sound. (Donkey Kong?)
a. Find the audio plug by sequentially plugging each plug into your
monitor's audio input jack. MARK IT!
b. Find the luminance plug by sequentially plugging the remaining three
plugs into your monitor's COMPOSITE VIDEO jack (not the luminance
jack). You'll know you have the right plug when you get a monochrome
picture. MARK THE PLUG and move it to the monitor's luminance jack.
c. Find the Chrominance plug by sequentially plugging the remaining two
plugs into your monitor's COMPOSITE VIDEO jack (not the Chrominance
jack). When you get a fine color picture, MARK THE PLUG. That is the
composite video plug. It remains unconnected.
d. The remaining plug carries the chrominance signal. MARK IT. Connect
it to the monitor's chrominance input jack.
e. Why are you reading this step? The modification is done and your
1200XL is properly connected to the monitor. Play DONKEY KONG.
Seriously, if you have trouble, leave electronic mail for me at:
GEnie - CHARLEKOONTZ CompuServe - 74206,3444
Notes on Programming
-----------------------------------------------------------------------
Ctsy: CompuServe Atari 8 Bit SIG
Sb: #PROGRAMMING
Fm: ROBERT ABRAMS 73547,1552
To: KEITH JOINS 72347,75
Keith, I would like to ask you a few questions with regard to binary
files. If I am wrong, please correct me.
Binary files are either created with the Atari Assembler Editor or the
MAC/65. Is this correct? Now, if a Basic program is compiled with a
compiler, is it turned into a machine language file?
According to my DOS 2.5 manual and some other texts on Atari basic, with
regard to "Option K" in DOS, to save a file using the "Binary Save"
option, the format is as follows:
SAVE-GIVEFILE,START,END(,INIT,RUN)
Now, the START= the beginning of the program's address and the END=the
end of the program's address--both of which are given in hexadecimal
numbers. INIT and RUN, respectively, are used if one wants the program to
automatically execute on loading. Does this mean that if a binary file is
saved without the INIT and RUN addresses, when it loads it will not run?
If this is the case and if someone saved a file without INIT and RUN
addressses, would they then use Option M -RUN AT ADDRESS from the DOS
menu to get the binary program to run?
Now, the format to save a binary file (and to get it to run (execute) on
loading is:
FILENAME,START,END(,INTI,RUN)
Question, how does one find out what the START,END, INIT and RUN addresses
are? Does the Atari Assembler Editor/MAC/65 provide this information? Is
it correct to say that one can't save a Basic file as a binary file unless
it is compiled? After compiling, how does one find out where these
respective addresses are? Does the compiler provide this?
Lastly, with regard to the USR statement in Basic.
Format: USR(memadr[,numexpr...])
Example:
A=USR(1536),ADR(A$),ADR(B$)),
How does one find the "memadr," i.e., the starting address of the machine
language program?
In the above, the ",numexpr" is also called an "argument." Below is a
hardware stack. Please explain this to me. I am lost
USR COUNT
----------------
1ST USR Argument
----------------
2nd USR Argument
----------------
.
.
.
.
.
.
-----------------
Final USR Argument
-------------------
Basic Program's
Return Address
-------------------
Stack Contents
Prior to USR
---------------------------------------
How does one know what the Basic program's return address is? Now I
understand that that a machine language program can return to Basic by
executing the assembly language RTS instruction. I am kind of lost here,
I guess for anyone to get Basic to use the USR one must have a background
in assembly. Is that correct. However, there is a commercial product that
has many Basic subroutines that perhaps I could use to apply the USR/RTS
statements. I am really interested in this stuff. I tell, this just
fanscinates me. Getting back to what I was saying, I believe the software
is called "QuickCode". Have you heard of this. If yes, what do you think
of it? Perhaps you could help me with this stuff.
Should only a person who is into assembly use the Basic USR/RTS
statements? Are there machine language subroutines avilable to the Basic
programmer to help this person do things with Basic that can't be done
otherwise. Perhaps this "QuickCode" is what I am looking for. It could
certainly help me with Basic and Assembly. I understand it works with the
MAC/65. Phew!!!!!! I'm done now and I am still lost.
Bob
Fm: Keith Joins/Sec. Leader 72347,75
To: ROBERT ABRAMS 73547,1552
Bob...
Just a couple of questions, eh? Whew! <grin>
OK--Mac/65 and the Atari Assem/Editor do produce binary files. However so
do such things as Action, a 'C' compiler, Lisp and any other language that
produces a machine lanuage (binary) type object file. Basic is a kind of
interpreted language. What that means is that the basic code or actually
the basic tokens are changed to machine language instructions as the
program is run. That is why it is so much slower than a binary file. A
basic compiler changes the basic code to the machine language instructions
prior to running and saves them as a binary file of sorts.
Your next question requires a little understanding of how a binary file is
created or stored. It will always begin with a header of 255 255 which is
FF FF in hex. Next are four bytes that indicate the start and end address
of the file, or the first segment of the file. This is the memory address
that the file will load into. Then you will have the actual data, the
total number of bytes here being equal to the number of bytes between the
start and end address.
Now you are either at the end of the file or you could have a second
segment of the same program. If you have a second segment, then the next
four bytes will again be the load addresses, start and end. FF FF could
be repeated, but is not necessary. This can be repeated as often as you
want.
The INIT address is used to cause an immediate execution at the address
specified when THAT segment is loaded before the rest of the program is
loaded in. (sound familiar from your question about screens being
loaded?) The RUN address is used when the entire program has loaded. An
INIT address is not required to have a program run automatically but a RUN
address is. If no RUN address is specified in a program, then you have to
use option 'M' from DOS to execute the program after loading it.
In assembly, you specify the start, run, and init addresses. The end
pretty much takes care of itself. The start address is determined by
where you assemble the program in memory. The RUN address is where your
program begins execution. These two are not necessarily the same.
To set up your run address you simply place the address your program
begins execution at in memory locations 2E0-2E1. After the program is
loaded, the computer will jump to the address contained in these two
locations.
Most assemblers allow you to assemble directly to disk. However you can
assemble your program to memory and then use the DOS option 'K' to binary
save it, specifing the RUN address and the INIT address if needed. Again
these are addresses that you have set up in your program. The start and
end addresses are still based on where you assembled your program to in
memory.
You can't really binary save a basic program since the tokens will not
mean anything to the computer until they have been translated into ML
instructions.
With a USR call from Basic, the address of the routine is either a
specific address such as 1536 that you mentioned, or the address of a
string that contains the ML routine. If the ML routine is in a string
then you really don't need to know what it's address is since Basic
handles that for you with the ADR command.
The stack is 256 bytes of memory (page one) that is reserved for keeping
track of a bunch of values your computer needs to navigate with. It is a
last in-first out type of operation. In other words, the last value
placed there will normally be the first one removed.
When you do a USR call, the return address of your basic program is first
placed on the stack. You don't really know or care what it is, much
different from an assembly program where you might want to change the
return address of your JSR.
The next thing placed on the stack are any parameters passed with the USR
call, such as ADR(A$) and ADR(B$) in your example. Finally the number of
parameters passed is placed on the stack. If there are no parameters then
this would be a zero, but it is ALWAYS placed there.
Now your ML routine takes over. The first instruction of a ML subroutine
used by a Basic USR call is PLA or 104 decimal. If you look at basic
programs that have the routine in data statements, you will always see
this 104 as the first number. This is because you have to do something
with the first value coming off the stack--the number of parameters
passed. Even if you don't want it for anything, you have to get it off
the stack or your program will crash. You then use the PLA instruction to
get the parameters themselves from the stack and do whatever you want with
them, according to the function of the ML subroutine.
The stack is then untouched until your subroutine encounters an RTS when
it is finished. The RTS will pull the return address of your basic
program off the stack and that is where execution resumes. Again note
that each value on the stack was used in the reverse order that they were
placed there. Also remember that parameters are optional.
To write your own USR routines you do need to know assembly. I am familiar
with QuickCode and in fact own the product. I have used it some and it
does it's intended function well. It is a collection of Macros for Mac/65.
A Macro is a series of instructions that are stored together with a name.
When the assembler encounters the macro name, it substitutes the stored
lines in place of the name in your code. This lets you define new commands
or operatives.
The macros in QuickCode are used to establish these commands, such as
COLOR, GR., OPEN, CLOSE, etc that are not valid assembly instructions.
Using the output of these routines for basic USR routines would be of
limited value.
QuickCode does not produce relocatable code so any routines created with
it would have to be placed in a specific memory area where it was
assembled at. There are very few places in memory that are protected and
that would be of the size needed. Macros produce large object files since
the actual macro code replaces the macro name every time it is encountered.
Page six would normally not be big enough.
QuickCode could be of use to you in writing a totally ML program as it
does help with things that you would normally have to write yourself. The
macros can also be turned into subroutines for use in your programs.
There are some ready-to-use subroutines that can be used in your Basic
programs, depending on what you want to do. I think I recall seeing an ad
recently for a disk of such. I am not at home right now so I can't check
for sure. Let me know if you are interested and I'll see if I can find
it.
Bottom line--if you want to use USR for what YOU want, learn assembly.
Keith
ZMag Newswire -- Part 2
-----------------------------------------------------------------------
**Press Release**
Innovative Concepts (I.C.)
31172 Shawn Drive
Warren, MI 48093
CompuServe: 76004,1764
Phone: (313) 293-0730
Note: The following NEW products, will be available for sale, starting
November 11, 1988 (advance orders are welcomed).
The XF35 Kit
------------
For Atari XF551 owners, now it's EASY to upgrade your set-up, to use the
newer 3.5" drive! Allows you to store up to 720K on each disk! Fully
tested, to work with: MyDOS, SpartaDOS (ICD), and the new SpartaDOS X
cartridge (ICD), in the 720K (80 tracks/side) format. And, 40 track
formats are still available, for use with most other DOS's. Also, the
high speed skewing is still available to use, in the upgrade ROM.
Kit includes: Installation/User instructions, Upgrade ROM, and all
required connecting cables. Note: To allow for easier access, the XF551's
- 34 pin connector (J4), is desoldered, and replaced with a 34 pin header
connector. NO other soldering/desoldering is required. And, NO trace
cutting to perform. Everything else, is "just plug ins"! Note: The 3.5"
drive mechanism, and it's mounting bracket, are not included in this kit.
(see below)
Price: $34.95 (+ $3.00 S&H)
Note: A COMPLETE conversion kit, including all of the above, PLUS: A High
Quality - 3.5" 720K drive mechanism, mounting bracket, with the SpartaDOS
Construction Set (ICD), are also available. Call or write, for more
details.
The IC Chip
-----------
Now, Atari 1050 owners with the Happy Board installed (original or clone),
can now boot-up SpartaDOS skewed disks, WITHOUT having to go into the U.S.
Emulation Mode anyore! A REAL time-saver! Automatically adjusts to U.S.
Emulation mode, when a program or utility, is "looking" for a U.S. Doubler
(ICD), such as SpartaDOS or CopyMate 4.4 (an excellent sector copier).
Includes: Instructions, Upgrade ROM, and 2 disks (both sides), full of
Happy-type programs and utilities.
Note: Just as before, you still CANNOT format U.S. sector skewed disks.
However, you can still read and write to them. All other Happy functions,
are still available.
Installation, is just a matter of unplugging the Happy 1050 Board's ROM,
and installing this new one. NO soldering, desoldering, or trace cutting
required!
Price: $29.95
Also, see our current catalog, for our Immitator Controllor, which is
another great add-on, for the Happy 1050 Board (original only).
Ramdrive + 192K
---------------
Due to the current high cost of 41256 DRAMS, we at I.C. now have a low-
cost, 192K memory upgrade (total), for the Atari 130XE. Best of all,
unlike other memory upgrades, you do NOT loose the 130XE's Extended Antic
modes! ALL 130XE type software (like Typesetter and Planetarium) run as
normal! With the extra 64K of RAM, you can:
Use Basic XE, and still have an additional 64K ramdisk!
With the included instructions, you can set-up Atariwriter + (under
SpartaDOS 2.3x/3.2x), for it's 3 main programs (AtariWriter+, Proof Reader,
and Mail merge) to run from a ramdisk!
Includes ramdisk handlers, to set-up a 707 sector (single density) ramdisk
for Atari DOS 2.0S/2.5, source code, and other utilities. Also includes
instructions for setting up ramdisk(s) with: MyDOS, TopDOS, SpartaDOS 2.3x
/3.2x, and the new SpartaDOS X Cartridge.
Price: $34.95 (+ $3.00 S&H)
Note: Installation is required, by a person experienced in soldering and
desoldering. NO trace cutting required!
ST Section
-----------------------------------------------------------------------
ST Filename Extender definitions
Executable programs
.PRG (GEM program)
.TOS (TOS program)
.TTP (Program which requires input)
.RSC (Resource file)
.DAT (Data file)
.PIC (Picture file)
.TXT (Text file)
.DOC (Documentation file}
.C -----
.MOD |
.SRC |
.PAS ^
.ASM (Source Code files)
.BAS (BASIC program)
.LOG (LOGO program)
.SNG (Music Studio file)
.NEO (NEOchrome drawing)
.PI1 --------
.PI2 |
.PI3 (Degas drawings)
.PC1 --------
.PC2 |
.PC3 (Compressed DEGAS Elite drawing)
.TNY (Compressed TINY format picture)
.TN1 --------
.TN2 |
.TN3 (Compressed TINY2 format picture)
.ARC (ARChived file)
.PQ1 --------
.TQT |
.PQG (SQUeezed files)
.LBR (LIBraried files)
.LQR (SQUeezed LIBrary files)
.MSA (Magic Shadow Archived)
PC Pursuit Recommendations Report
-----------------------------------------------------------------------
Telenet Communication Corporation
Field Operations HQ Tech Support
Reston, Virginia
Introduction
Because of many customer complaints concerning PC Pursuit's inability to
allow file transfers, Field Operations was requested to provide
recommendations for file transfer via PC Pursuit. In compliance with this
request, this document provides the following:
* Recommendation on the best file transfer protocols to be used with PC
Pursuit.
* Recommendation on the hunt-confirm sequence and line parameters which
provide optimum performance of various protocols.
* The average transfer rates which can be expected using the correct hunt
-confirm sequence and optional parameter settings.
Recommendations
This recommendation outlines the most common file transfer protocols used
with PC Pursuit. The performance of the protocols in the direct connect
and PC Pursuit environments are also indicated.
The following protocols were tested via the Chicago in-dial to the
Washington DC out-dial; the observations are summarized below.
PC Pursuit XMODEM file transfers performed at an average throughput of 30
when the correct hunt-confirm and terminal type was utilized.
XMODEM does not support flow control, therefore it is suggested that the
"relaxed" mode be invoked if the user's communications software permits
this feature.
The performance of YMODEM file transfers VIA PC Pursuit was found to have
an average throughput of 56 when the correct hunt confirm and terminal
type is employed. Although YMODEM does not support flow control, it uses
large 1024 byte packets which the network PAD handles quite readily under
normal conditions. As a result, YMODEM is rated one of the faster
protocols for file transfer via PC Pursuit.
WXMODEM file transfers utilizing the correct hunt-confirm and terminal
type performed well with an average transfer rate of 52. This protocol
is capable of handling flow control which enables it to perform with
better reliability in the PC Pursuit environment. Users should be aware
that an early version of PROCOMM is known to have a software problem which
can affect the performance of WXMODEM file transfers.
An optimum average throughput of 47 was obtained by KERMIT file transfers
via PC Pursuit. The throughput was optimized by modifying the packet size
to 90 and adjusting the (host) window size to 16 (for uploads). KERMIT
software which supports the sliding window feature performs with optimum
efficiency in the PC Pursuit environment.
SEALINK file transfers via PC Pursuit performed exceptionally well with
an average throughput of 74 with the correct hunt-confirm and terminal
type. SEALINK supports flow control and was specifically designed to
operate in the networking environment.
File transfers utilizing ZMODEM protocol via PC Pursuit yielded an
average transfer rate of 61. ZMODEM performs well in the PC Pursuit
environment, however; the local configuration for ZMODEM file transfers
proved to be cumbersome and difficult for the user. ZMODEM requires
several parameters to be set locally and on the local pad. These parameter
settings can vary depending on the type of machine and the type of
communications software. The X.3 PAD parameters which should be employed
are 1:0,4:10,5:1,7:8,12:1. In addition, flow control (XON/XOFF) should be
enabled at the user PC. Because of the difficulty in configuring ZMODEM
for file transfer, it is recommended that only seasoned computer users
attempt ZMODEM file transfers via PC Pursuit.
The following text summarizes file transfer performance of the protocols
tested. The protocols are listed in order (PCP best to worst) in two
categories: 1) performance via direct connect, 2) performance via PC
Pursuit utilizing the recommended hunt confirm and parameter settings
shown. It should be noted that the optional parameters need only be
employed if a user experiences problems with transferring a particular
file.
File Transfer Procedures
This section outlines the step by step procedure for executing file
transfers via PC Pursuit. These procedures must be followed exactly to
achieve optimum transfer rates. The optional X.3 parameters shown above
indicates the parameters which provide the best transfer rate.
STEP 1
Set PC communications software to 8 bits, no parity, 1 stop bit, full
duplex. Depending on the type of protocol to be used, disable or enable
local (XON/XOFF) flow control.
STEP 2
Dial local rotary with the communications software set at the desired
speed.
STEP 3
Upon answer use the correct hunt confirm sequence:
At 300/1200bps use - <CR D CR>
At 2400bps - <@ D CR>
NOTE: "D" MUST BE UPPER CASE.
STEP 4
At prompt "TERMINAL = " enter <D1> and return.
STEP 5
At the "@" prompt enter the destination mnemonic, out-dial speed, ID and
password. It is important that out-dial speed matches in-dial speed. DO
NOT MIX IN-DIAL AND OUT-DIAL SPEEDS.
STEP 6
If pad X.3 parameters are to be changed, do so at this point by entering
<@ CR>. Set parameters as prescribed. Return to out-dial port by entering
<CONT>.
An example of the proper syntax for modifying X.3 PAD parameters would be
"SET 7:8,1:0." To display the current PAD parameter settings, the user
should enter "PAR?."
These are only two of many user commands available. Many of the user
commands are clearly defined in the Telenet document "How to Use Telenet's
Asynchronous Dial Service."
STEP 7
Upon connecting to the destination pad, insure communication with the
out-dial modem by entering <ATZ>. The destination modem will respond with
"OK".
STEP 8
Enter <ATD> and the local number you wish to dial.
STEP 9
Queue host file transfer and start file transfer.
Please note that these are the basic steps needed to achieve successful
file transfers. Since communications software may vary from package to
package, additional steps may be needed to initiate the start of the file
transfer at the user software level.
Summary
Extensive testing has resulted in identifying the expected performance of
six file transfer protocols when used with PC Pursuit. These protocols
have been determined to perform satisfactorily with PC Pursuit when the
correct hunt-confirm, terminal type and parameters are employed.
It is the recommendation of Field Operations that customers be informed
of the correct logon procedures and the protocols which provide the most
reliable file transfers. Customers should also be reminded that PCP users
can expect a small degree of network delay which is considered a common
characteristic of packet switched networks. In addition, users should
also be informed that poor quality voice grade telephone lines can
adversely affect file transfer sessions.
Field Operations is one of many Telenet groups dedicated to providing
customers with complete support for PC Pursuit. Field Operations will
offer assistance with file transfer problems providing the customer is
willing to release a copy of the problem software as well as provide the
pertinent information necessary to resolve the problem.
Because problems can vary in nature, the information required to resolve
problems can differ from one problem to the next. But at the very least
the following information will be required:
* Type of communication software * Type of PC, make, model
* Type of modem * Call origin
* Call destination * Speed in
* Speed out * Type of session
* Time of failure * Date of Failure
* Point of failure in session * Out-dial number
* Network Address (if possible) * Copy of PC Software
Additional information may be required depending on the nature of the
problem.
FILE TRANSFER--PERFORMANCE STATISTICS
PERFORMANCE STATISTICS DIRECT CONNECT
General Communication Parameters = 8 bits 1 stop bit N no parity
Terminal Type = D1
PERFORMANCE STATISTICS DIRECT CONNECT
| XFR |
| PROTOCOL SPEED SECONDS CPS BPS RATE |
|======================================================|
| |
| SEALINK UP 1200 ***517 87.15 871.49 73|
| SEALINK UP 2400 ***270 166.87 1668.74 70|
| SEALINK DN 1200 ***428 105.27 1052.71 88|
| SEALINK DN 2400 ***230 195.90 1958.96 82|
| ZMODEM UP 1200 ***408 110.43 1104.31 92|
| ZMODEM UP 2400 ***201 224.16 2241.59 93|
| ZMODEM DN 1200 ***391 115.23 1152.33 96|
| ZMODEM DN 2400 ***195 231.06 2310.56 96|
| YMODEM UP 1200 **259 102.80 1027.95 86|
| YMODEM UP 2400 **126 211.30 2113.02 88|
| YMODEM DN 1200 **244 109.11 1091.15 91|
| YMODEM DN 2400 **130 204.80 2048.00 85|
| WXMODEM UP 1200 **277 96.12 961.16 80|
| WXMODEM UP 2400 **159 167.45 1674.47 70|
| WXMODEM DN 1200 **405 65.74 657.38 55|
| WXMODEM DN 2400 **131 203.24 2032.37 85|
| KERMIT UP 1200 **356 74.79 747.87 62|
| KERMIT UP 2400 **211 126.18 1261.80 53|
| KERMIT DN 1200 **322 82.68 826.83 69|
| KERMIT DN 2400 **178 149.57 1495.73 62|
| XMODEM UP 1200 **259 102.80 1027.95 86|
| XMODEM UP 2400 **140 190.17 1901.71 79|
| XMODEM DN 1200 **268 99.34 993.43 83|
| XMODEM DN 2400 **146 182.36 1823.56 76|
======================================================
**File size = 26624 ***File size = 45056
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Syndicate ZMagazine is Copyright (C)1988 by APEinc, Syndicate Pubishing.
All Rights Reserved. Reprint permission granted in User Group Newsletters
providing Syndicate ZMagazine and Issue #130 are credited.
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
-----------------------------------------
Return to message index
