Brotikasten/BROTCD01.iso/atari/s2pc319.txt

Text File | 1995-07-03 | 100KB | 2,193 lines

SIO2PC: An Atari to PC Interface System

              by Nick Kennedy

            300 South Vancouver St
            Russellville, AR 72801
                501-967-3843

        D I S C L A I M E R

I have tried to ensure that my software is free of harmful
defects (bugs) and of viruses.  However, either could slip
through my defenses.  Use the software at your own risk.
Similarly, I believe my hardware design to be in
accordance with good practice, and I have a number of
satisfied users.  However, wiring errors, errors in my
design, and configuration differences are possible and I
cannot guarantee that these problems will not lead to
damage to your equipment or software or other unforeseen
damages. Use at your own risk.  Furthermore, if you choose
to construct my interface yourself, you must be
experienced with electronic building techniques.  Even if
you are experienced, you could burn or cut yourself or
experience other damage or injury, for which you must
assume responsibility.

I consider the SIO2PC system to be a service to the Atari
user's community. Although I accept shareware
contributions, and do make a charge for assembling
interfaces or kits, I still consider my efforts to be a
hobby and a service.  IF YOU HAVE SENT ME ANY PAYMENT FOR
ANY SOFTWARE, KIT, OR ASSEMBLED INTERFACE AND DO NOT WISH
TO ASSUME FULL RESPONSIBILITY FOR USE OF OR CONSTRUCTION
OF THESE ITEMS, YOU MAY RETURN THEM TO ME AND I WILL
REFUND YOUR MONEY.  IF YOU ARE CONSTRUCTING THE INTERFACE
AND CANNOT VERIFY THE ADEQUACY OF THE DESIGN ON YOUR OWN,
SEEK THE ADVICE OF ONE COMPETENT IN ELECTRONICS.
OTHERWISE, DO NOT ATTEMPT TO BUILD AND USE THE INTERFACE.
DON'T USE THE SIO2PC ON COMPUTER SYSTEMS USED FOR
COMMERCIAL PURPOSES OR FOR CRITICAL APPLICATIONS.

INTRODUCTION    1
FEATURES:       2
HARDWARE REQUIREMENTS:  2
HISTORY:        3
SHAREWARE INFO: 3
READ ALL ABOUT IT:      3
TECHNICAL INFORMATION ON SIO2PC 4
REMOTE CONTROL PROGRAM: 5
FILE2PC PROGRAM:        5
STRUCTURE OF AN SIO2PC ATARI DISK IMAGE:        6
USING RAMDISKS: 7
TIMING INFORMATION:     7
DOUBLE DENSITY: 9
FORMATS vs DISK SIZES:  9
FILE ACCESS: How it works & tips on efficiency  11
MORE DISK CONFIGURABILITY:      12
SIMULATED DISKS:        14
PRINT-THRU:     15
UNINSTALL DISK: 17
STATUS LINE INFO:       18
PC MEMORY USAGE:        19
DOS SHELL FEATURE:      19
VIRUS DETECTION:        19
REMOTE CONTROL PROGRAM USAGE    20
MAKADISK.EXE    21
FILE2PC USAGE INFORMATION       22
FUTURE PLANS, CURRENT PRICING   23
REVISION LOG:   25
PROBLEM DIAGNOSIS QUESTIONS     33
POSSIBLE PROBLEMS AND SOLUTIONS 33
USER'S QUESTIONS        36
WHO'S NICK KENNEDY?     39
OTHER PROGRAMS  39


INTRODUCTION

Greetings Atari and PC users! SIO2PC is now a "Shareware"
product.  If you know little or nothing about the system,
let me give you a rundown. A separate text file,
SIOINSTR.TXT, gives more detailed information on running
the system and describes its features.

SIO2PC is a hardware interface and software utility
package to allow storage of your Atari files on your PC's
hard and floppy disks, file conversions in both
directions, and Atari printer output redirection to your
PC's printer, screen, or file.

FEATURES:

Create 1 to 4 virtual Atari disks on your PC.

Virtual disks can be ramdisks or physical file access
disks; disk images can be up to 65525 sectors in
size.

Save Ramdisks to PC hard or floppy disks.

Boot from the PC. Real drive not needed to start-up.

Create Single or Double density ram-drives.

No special Atari software patches. Use your favorite
DOS.

Almost twice as fast as an Atari 810 drive.

Co-exists in the Atari daisy chain with "real"
drives.

Software written in assembler: Compact and Fast.

Compatible all the way down to the hardware level -
CIO, SIO, even direct hardware calls to drives will
work.

Print-Thru mode sends your Atari's printer bound
output to your PC's  Printer, Screen, or file.

File Conversion: Convert and transmit PC files to
Atari, or Atari files to PC files.

Won't endanger your PC's hard disk. Your Atari disk
images are stored as ordinary PC files. No direct
sector writes used.

Status line shows you exactly what your Atari is
telling your disk drives: drive number, command, and
sector number.

HARDWARE REQUIREMENTS:

SIO2PC connects any PC compatible computer to any of the
Atari 8 bit computers (400, 600, 800, 800XL 130XE).

The interface between your PC's serial port and your
Atari's SIO port requires a simple interface. It uses two
IC's and a few capacitors and can be built on a 2" X 3"
prototype board. If you are handy with a soldering iron,
read the BUILD_IT.DOC file on your disk. It gives complete
instructions, including addresses of parts suppliers. If
you wish, I'll build one for you, or provide you a kit of
all parts with drawings and detailed instructions. See
BUILD_IT.DOC.

HISTORY:

SIO2PC has been over 5 years in the making. Before I got
my PC, I considered my alternatives for my trusty Atari
800. Should I invest in an adapter and hard disk for the
Atari? I realized that the huge PC market made an entire
PC with hard drive almost as cheap as adding a drive to my
Atari. So why not do both? The PC could store my Atari
programs (get rid of that huge pile of floppies), and I'd
have a new computer to boot! The project has worked out
better than I could have imagined. The PC is a great
computer - in some areas. In areas where it is weak, the
Atari still shines. Curing the Atari's mass storage
weakness makes it even better.

SHAREWARE INFO:

As you no doubt know, Shareware is a system which allows
you to receive freely distributed software, and pay for it
if you find it useful. If you build the interface and find
that the system is useful, I request the modest sum of $10
for the design and software. If you choose to buy the kit
or assembled interface from me, no additional payment for
the software is expected. Either way, registered users may
upgrade to the latest revision by sending a disk sized
SASE and $5.00. Your suggestions will be considered for
future revisions. So far, I have always been able to
personally respond to questions and problem reports.

READ ALL ABOUT IT:

Don't you hate to write off for a shareware program that
looks good in the ad, only to find an endless README file
describing the limitless complexities of the package? Now
that I'm on the creating end of that particular method of
information overload, I can see how documentation files
just grow... But - SIO2PC is a simple menu driven program
which can, I believe, be mastered without instructions.
So, skim through the rest of this file and the other .DOC
files for tidbits, and return only if you have problems or
specific questions after you get your system going. Of
course, if you decide to build it yourself, you will want
to read BUILD_IT.DOC carefully. Also, go ahead and run
SIO2PC.COM and play with the menu options a bit, even
without the interface. It won't hurt anything. Note: This
DOC file gives some problem resolution information,
technical information, and more information on file
transfer features. For a more concise user's guide to the
program, see the SIOINSTR.DOC file.

        A NOTE ON A RELATED HARDWARE DEVELOPMENT

Recently, an SIO2PC user told me he was developing a
hardware project which would allow him to type on the PC
and have the keystrokes transmitted to the Atari via a PC
parallel port and custom Atari interface.  The system also
comminicated joystick positions, START, SELECT, OPTION,
and SYSTEM RESET button status to the Atari - AND allowed
turning the Atari on and off remotely, and turning the
Atari's cartridge on and off.  His idea was to tuck the
Atari away, into a desk drawer or something, and do
everything from the PC's keyboard.  He asked me to write
to software for this project and integrate it into SIO2PC,
which I have done.  The hardware is more complicated than
an SIO2PC, having 8 or 10 chips and requiring internal
installation in the Atari.  If this sounds interesting to
you, I'd be glad to send you the schematic and a version
of SIO2PC which includes the control functions for this
modification.  If you'd like to contact the designer of
the interface, he is Carl Mangaroni, 15764 Midwood Drive
Suite 5, Granada Hills CA 91344  phone [phone].

And another:

A programmer named Darek Mihocka recently (7/94) released
a freeware version of an Atari 800 emulator which runs on
the PC.  The faithfulness with which it emulates the Atari
is unbelievable.  It emulates a 6502 processer and the
Antic video microprocessor perfectly and includes the
actual Atari OS and BASIC code.  It doesn't yet have
sound, but he will add that and other features in a future
version for a modest price.  I mention this partly because
every serious Atari 8 bit fan with a PC must have it and
partly because it will read SIO2PC format disk images.  So
by having SIO2PC, you have the capability to transfer your
files to the PC for access by Darek's XF2 emulator.


TECHNICAL INFORMATION ON SIO2PC

SIO2PC is 100% written in PC assembly language. REMOTE.OBJ
and FILE2PC.OBJ are written in 6502 assembly language.
MAKADISK.EXE is written in 'C'.

SIO2PC recognizes the basic SIO bus commands: READ SECTOR,
WRITE SECTOR, PUT SECTOR, STATUS, FORMAT, FORMAT 1050 1.5
DENSITY.

Because it works at this elementary level, it should work
with any DOS and with non-DOS disk loader programs. You
can also make boot disks (without DOS) and boot them from
the PC.

SIO2PC uses only MS-DOS calls to do file I/O on the PC.
Because there are no direct sector writes, etc., SIO2PC
won't trash your PC disks. Just use the right
path/filename when doing writes.

SIO2PC uses file handles, so I assume it will require
MSDOS or PCDOS 2.0 or later.

SIO2PC redirects the timer 0 interrupt for it's timing
purposes. This is the timer which supplies the BIOS its
"timer tick", 18 times per second, 55 milliseconds per
tick. SIO2PC also directly reads the timer as it is
counting down in a routine for more fine timing (the
microsecond level). If your PC doesn't use the standard
timer chip (or compatible) with standard port addresses,
there could be problems. Note: Most PC Clones are HIGHLY
hardware compatible.

SIO2PC gets the port address for the specified COM port
from bios data area words at 040:0000, 040:0002, 040:0004,
040:0006 for COM  1,2,3, and 4. I've found out that the
POST routine typically doesn't set up the addresses for
ports 3 & 4. Therefore, version 1.01 will use default port
addresses 03F8, 02F8, 03E8, 02E8 for COM 1 - 4 if it finds
a zero in the BIOS data area word. If you know your port
addresses to be other than this, a third option is now
available. Use your computer's documentation to find the
base address, and use SIO2PC's  "E" command to enter the
addresses directly.

REMOTE CONTROL PROGRAM:

The Atari serial bus reserves device ID's 31 - 38 hex for
disk drives 1 thru 8. I have used ID #39h for the remote
control function. When the SIO2PC program finds this ID #
in a command frame, along with a Write Sector command, it
expects to receive one sector (128 bytes) containing a
command string. It then acts on the string as
if it were a command tail from the DOS command line. Any
error, or the Atari EOL character, will terminate command
processing and flush the line of any further commands. It
is best to end the string with a space as a delimiter,
especially if your command ends in a pathname, else your
PC may pause waiting for input or an ENTER keystroke. A
REV 2.1 change added this function to the REMOTE process:
When DEVID = 039h and DCOMND = 'R', the SIO2PC sends a 128
byte data frame to the Atari containing the DISK status
information string shown on the screen. The string sent
depends on the contents of DAUX1 which must contain 1 - 8
for disks 1 - 8. This function allows REMOTE.OBJ on the
Atari to update the user as to the status of the ramdisks,
before and after the execution of the remote function. In
this way, the user can see if his remote command went to
error free completion. In some cases, the PC may be busy
carrying out the command when the data request is
received. For example a command to write a ramdisk out to
a floppy disk may take 10 seconds or so. Therefore,
REMOTE.OBJ tries 3 times, pausing 4.25 seconds between
retries, before giving up on getting the information.

FILE2PC PROGRAM:

The FILE2PC program also uses its own bus ID as a trigger
for the FILE2PC program. ID# 03Ah puts the  program into
File Transfer mode. The Atari (running FILE2PC) always
asks for Status of device 03Ah before putting a sector.
(Only Status and Write are recognized by device 03Ah.) If
the first status byte (of 4) is normal (010h), then the PC
is ok for the transfer mode. If it is 0FFh, then the Atari
will abort because the PC has encountered an error. The
process works like this: The Atari gets Status, then, if
OK, it sends a sector to the PC. The PC assumes that this
sector contains the pathname of the destination file,
terminated in an ATASCII EOL. The Atari pauses 4 seconds
while the PC attempts to create the file. (Note, any
existing file of the specified pathname will be
overwritten.) After the Atari gets another good status, it
starts sending sectors of file information.

The AUX bytes, which usually carry  sector # information,
communicate the following to the PC:

AUX1 = 0:       Full sector, 128 bytes AUX1 = 1:        Last
sector, AUX2 contains the byte count
AUX1 = 2:       Atari encountered an error, abort process.

As I said, the Atari asks the PC for Status after every
write.


STRUCTURE OF AN SIO2PC ATARI DISK IMAGE:

It's extremely simple. There is first a 16 byte header
with the following information:

WORD = special code* indicating this is an Atari disk file
WORD = size of this disk image, in paragraphs (size/16)
WORD = sector size. (128 or 256) bytes/sector
WORD = high part of size, in paragraphs (added by REV
3.00)
SPARES 8 (ten) unused (spare) header bytes (contain
zeroes)

After the header comes the disk image. This is just a
continuous string of bytes, with the first 128 bytes being
the contents of disk sector 1, the second being sector 2,
etc.

* The "code" is the 16 bit sum of the individual ASCII
values of the string of bytes: "NICKATARI". If you try to
load a file without this first WORD, you get a "THIS FILE
IS NOT AN ATARI DISK FILE" error message. Try it.

USING RAMDISKS:

SIO2PC uses, or can use, the PC's hard or floppy disks to
store Atari disk information. However, to give maximum
speed, the disk information can be buffered via a ramdisk
set up in the PC's ram space. When the Atari reads/writes
its SIO2PC "disks", it is actually communicating with the
ramdisks in the PC's memory. The user can choose to load a
ramdisk image or save one back to physical disk at any
time via menu selection.  For files too large to be
installed as ramdisks, file access to the disk image is
used.

TIMING INFORMATION:

The Atari SIO2PC bus protocol specifies minimum and
maximum times between Atari commands and disk drive's
responses. The minimums give the Atari time to get ready
to take the data from the bus if it has to do some other
work in the interim. The maximums let the Atari decide
that the peripheral isn't ever going to answer and it will
give a "time out" error. I have found that the system is
very flexible and forgiving. I have used wide variations
and still had a workable system. But for one guy (you know
who you are, Joe!) or maybe two, I've made this menu to
allow you to experiment with different values. The system
goes through this little dance of command - acknowledge -
data - acknowledge - complete, etc with timings in
between. In addition to these times inside the bus frame,
I've made a couple more (normally zero) time delays
available.

First: On a serial bus, data is normally sent
continuously, with no time (except start and stop bits)
between bytes. Now you can experiment by adding some time
here. (My system slowed down but still ran normally.)

Second: Some publications say that some UART (serial)
chips can't stand to be addressed as fast as some PC's are
capable of addressing them. I already had a bit of time
delay in there, but now you can add some more. The time
delays work like this: Each unit is 850 nano-seconds which
is almost 1 micro-second. (Multiply units by .85 to get
micro-sec.) (Exception: the value for the printer delay is
in 1/18ths of a second.) Also, you must enter the units as
a 4 digit hex number. Don't panic, it's easy. Here are
some conversions:

        DECIMAL         HEX

        0005                    0005
        0010                    000A
        0050                    0032
        0100                    0064
        0250                    00FA
        0500                    01F4
        0750                    02EE
        1000                    03E8
        2000                    07D0

The timing menu gives default values you can use as a
starting point. If you want to see the menu updated with
your choices, an item is available from the menu (choose
#8).
One problem with the TIMINGS menu is that it can't be
addressed from the command line tail, so if your system
does need non- standard timings, you have to set them up
manually, each time you run the program. Not any more,
Joe! Here's a procedure to permanantly alter your program:

This procedure uses DOS's little utility "DEBUG," because
everyone has it. But you could use NORTON or similar if
you want. I moved the timing values to the front of the
program and put an ASCII string in front of it to make it
easy to spot. Try this:

Get into the directory containing SIO2PC.COM. On the DOS
command line, type DEBUG SIO2PC.COM <ENTER>. Now you see a
hyphen, which is the DEBUG prompt. Now, type D <ENTER>. A
table of hex numbers appears. On the left is the
corresponding SEGMENT:OFFSET address for the first entry
of each line. On the right is the corresponding ASCII
(text) representation of the hex bytes. You notice that my
little flag, "TIME DELAY VALUES: T1-T8, 2 BYTES PER
ENTRY:" takes you up to the line starting with offset
:0130. That line contains the timing values and looks like
this:

????:0130 ?? ?? ?? 64 00 B0 04 2C-01 etc.
Here's the slightly tricky part: Each of those 2 digit hex
numbers is a byte. But each timing value is a WORD (2
bytes). And the PC stores words as lower part first. So
the values are: T1 = 0064, T2 = 04B0, T3 = 012C, etc.

The good part is, you don't need to worry about all this
junk, we're gonna fix it in a very easy way. If you have
been following me and are now in DEBUG, get out of it by
typing Q <ENTER>. Now, I recommend that you copy
SIO2PC.COM onto a floppy because it's a little scary using
DEBUG to write to one's hard disk. Ok, you've done that
and you have the floppy in drive A:. Get into A: by typing
A: <ENTER>. Now, type DEBUG SIO2PC.COM <ENTER>. Give the
"GO" (run) command by typing G <ENTER>. SIO2PC runs from
the floppy. First give it a port number, then go to the
"A" menu and change the timings values to those you have
found to work on your system. Now, leave the timings menu
and QUIT SIO2PC. You will see by the hyphen that you are
back in DEBUG. Type W <ENTER> and the program will be
written back to the disk file. Quit DEBUG with Q <ENTER>.
Now run SIO2PC without DEBUG, and call up the timings menu
again. You will see that the DEFAULT column stayed the
same but the CURRENT values are now permanently altered.
Hey, I didn't know that DEBUG could be so useful, did you?
NOTE: You should get a message saying program changed,
possible virus.  Just choose to write a new CRC and the
program will be fixed.

DOUBLE DENSITY:
The Atari expects the first 3 sectors on a disk to be
single density. This is necessary if you are to be able to
boot from the disk. SIO2PC uses this format for its double
density mode.

FORMATS vs DISK SIZES:

I generally haven't restricted these things, but recommend
the following: Use 143K size only for "enhanced" or "1.5"
or "DOS 2.5" density. The 183K size was created for double
density. A lot depends on your DOS. Some DOS's can figure
out the actual size of a disk, others may assume a
default. MYDOS is pretty smart. SPARTADOS probably is
also. As of REV 3.00, SIO2PC responds to "get" and "set"
configuration commands, and also allows you to select any
size disk you want by specifying the number of sectors.

As a result of changes made in REV 3.00 and beyond which
allow HUGE disk images, I now have additional information
to present on disk sizes:

File Access and BIG disks

The biggest change is the addition of file access to disk
images.  Since this type of access doesn't require setting
up ramdisks, the disk image size isn't limited by
available ram.  You may choose the size of your disk
images using new size choice #5.  You specify the size in
sectors.  If you're interested in what this means in
kilobytes, you can figure it from the fact that a sector
is 128 bytes for single density disks and 256 bytes for
double density.  Remember the status line field that shows
'W' if you've written to a ramdisk but not saved it?  (And
'N' if the file has been saved.)  For direct file access
type disks, this field will contain an 'F'.

Note that you can force the system to use file access,
even when there is enough ram for a ramdisk.  You do this
by following the filename by "/P" for physical file
access. Don't put a space between the filename and the
"/P".  The "P" will appear on your status line. (The "/"
won't.)

Concerns about Speed

I was concerned that the overhead of using DOS and having
physical disk accesses might slow the system down.  On my
two PCs, this hasn't been a problem when using hard
drives.  I use disk caches on both systems and can't tell
any difference between "ramdisk" and "file access" speed.
With a floppy disk, my fears were justified.  Access was
slow enough that the Atari would time out and generate
errors.  But, when I installed a disk cache, floppy disk
access worked fine too.  Some disk caches don't support
floppies.  Smartdrive (supplied with DOS 5 and WINDOWS)
doesn't.  I used one called LIGHTING.  It worked fine
using conventional memory while Smartdrive continued to
run using extended memory.

Get/Set Configuration

Even after I first made some BIG disks, MYDOS 4.5 still
couldn't figure out that they were bigger than a standard
810 or 1050 disk.  The standard Atari SIO protocol doesn't
include a means for the drive to tell the Atari what it is
capable of (except in a very limited way).  I found that I
had to implement the extended SIO commands for Get and Set
Configuration so MYDOS would realize the actual size of
the disk.  MYDOS does some of this automatically (reads
configuration on bootup).  But I found that I had to
explicitly do this in sequence so MYDOS would realize the
disk size:

Create the new (blank) disk image.

Use the Set Configuration command, answering
questions as follows:  Configurable? Yes.  High
Capacity? Yes.  Number of Sector? xxxx.  Do this
before formatting.

Format the new disk image.

Actually, SIO2PC doesn't do anything with the Set
Configuration command other than acknowledge it.  But it
lets MYDOS know that the disk is capable of more sectors
than a standard disk.  The program WAS going to also warn
you if you tried to set the wrong density.  But it turns
out that MYDOS always tries to set high density when you
answer "Yes" to "High Capacity Drive?".  This doesn't
cause a problem though: single density still works OK.
I'm describing MYDOS because it's what I use.  YOUR Atari
DOS may have its own quirks with regard to large drives.
MYDOS can become confused when you use the SIO2PC Swap
Disk I.D.s command.  MYDOS associates a certain disk
number with a certain configuration.  You may have to
uninstall and reconfigure the drive with MYDOS when you
swap disks of different types.

Formatting

With regard to formatting, it can take a long time with a
BIG disk image, especially on a floppy.  SIO2PC sets a
flag when you first create the disk, to tell itself that
the disk image is already blank.  So, when you format it,
the program doesn't bother clearing the disk.  This saves
a lot of time.  After you write to the disk, the flag is
cleared.  Then, formatting includes clearing the entire
disk image file.  This could cause the Atari to time out
and not realize the format was successful.  So you may
want to avoid formatting "used" disk images.  I can't
think of a reason you'd want to.  (CREATING a new disk
image can take a while too, but the Atari isn't involved
in this process, so it won't get impatient.)  I may
improve the program to speed up this process if it's a
problem.  But creating new BIG disks will probably be an
infrequent operation for most of us.

*** NOTE: In a "rev 3.00 and 1/2" modification, I have
taken a big step toward curing the slow formatting
problem.  Instead of writing blank sectors one at a time,
I now write zeroes in blocks of 4K at a time, dividing the
number of DOS calls by 32.  This only works if there is at
least 4K of free ram. Otherwise, formatting will still
work slowly, as described above.

Note that you need to be a bit more careful when
formatting file access disks.  With ramdisks, you could
always choose to not save the formatted disk image, so
your original was safe.  With file access, formatting
actually clears your disk image file.

Another addition with this revision is that you can now
number your disks as 1 - 8 instead of 1 - 4.

Incidentally, you may wonder why your old 92K and 143K
disks are now 90K and 140K.  This has to do with the
difference between a kilobyte as 1000 bytes and a kilobyte
as 1024 (2^10) bytes.  Revision 3.00 divides the disk size
in bytes by 1024 to establish the disk size.

FILE ACCESS: How it works & tips on efficiency

It's pretty simple.  MS-DOS maintains a pointer into open
files which can be set by the program. SIO2PC maintains a
corresponding pointer to the next Atari sector. When
SIO2PC receives a read or write sector request from the
Atari, it calculates the file offset from the sector
number.  It compares this to its record of where the
pointer is now. If they differ, it asks DOS to point to
the new location.  Then it asks DOS to read or write 128
(or 256) bytes and increments its internal sector pointer
by one, since DOS's pointer will now be at the next 128 or
256 block of the file.  As you can see, if the Atari asks
for sectors sequentially the pointer automatically moves
along in step and no separate requests to reposition the
pointer are needed.  This is a good reason to try to keep
your disk images unfragmented.  Actually, it's possible to
have things DOUBLY fragmented: fragmented Atari disk
images and fragmented PC disks.  To avoid Atari
fragmenting, you should first put files on the disk which
you won't be deleting or changing: DOS, games, application
programs.  Last, put on any stuff that will change: data
files, text files, etc.  If you suspect your disk is
fragmented it's easy to undo.  Just do a file copy (*.*)
from the fragmented disk image to a newly created and
formatted blank disk image.

MORE DISK CONFIGURABILITY:

I've heard lots of reports about the inability to format
certain disk image sizes.  My adding the "get
configuration" and "send configuration" functions in Rev
3.00 in some cases seemed to make matters worse.

I'm now getting into an area where the specific DOS one
uses makes a difference.  So my treasured concept of "DOS
independence" of SIO2PC is going out the window.  The
problem is this:  How can the system tell the Atari
exactly what size and type of disk it is emulating?  The
12 byte configuration table exchanged via the GET/SEND
CONFIGURATION commands would seem to be the answer.
Unfortunately, both MYDOS and SPARTADOS admit to ignoring
most of the information exchanged.  The variables are:

SINGLE/DOUBLE DENSITY: 128 or 256 bytes/sector
SINGLE/DOUBLE SIDED DISK
NUMBER OF TRACKS/SIDE: TYP: 35, 40, 77, 80 expected
NUMBER OF SECTORS/TRACK: TYP: 18 or 26 expected


The MYDOS doc indicates that it likes to consider the disk
to be one huge track containing all the sectors.  This
seems to work pretty well for SIO2PC.

SPARTADOS evidently expects to receive information which
matches its expectations about certain combinations.  The
sizes under the choice 6/Other are intended to give
SPARTADOS what it expects.  (As standards, they are
probably good for other DOSes too.)

One thing I've recently learned (I think it's true,
anyway) is that SPARTADOS considers 26 sectors/track to be
"1050 enhanced density" in all cases except for 77 track
drives which always have 26 sectors/track.

The bottom line is this:  Even though you can choose a
disk image of any size with the new SIO2PC option #5, you
may have to adhere to certain standard sizes when using
SPARTADOS.  I've added a lookup table to the program.  If
the disk size matches a  certain standard, it reports a
combination of standard values to the Atari.  Otherwise,
it uses the MYDOS technique of 1 track holding all
sectors.  Note that this routine puts a tilde ( ~ ) in the
ERR field of the status line if it finds a standard size.

Note that when you choose double density, the basic 1, 2,
3, & 4 choices won't be seen as a standard size, but the
equivalent chosen from sub option 6/More WILL, for
technical reasons too boring to go into here.  As I've
said, this usually doesn't matter, because most DOSses
don't use the GET/SEND configuration capabilities anyway.

You could compute some standard sizes like this:

Number of Sectors = (#TRACKS * #SIDES * # SECTORS/TRACK)

Size in Bytes = (Number of Sectors) * (#Bytes/Sector)

(For the Size in Bytes, subtract 384 for double density,
because the first 3 sectors are always 128 bytes.)


All YOU have to pay attention to is the density and the
number of sectors. SIO2PC will report the other numbers to
the Atari. For MYDOS, just randomly picking a number of
sectors, without regard to standard sizes, seems to work
fine.

As I said before, the addition of the GET and SEND
CONFIGURATION info commands in some cases did more harm
than good.  For this reason, I've added yet another
feature.  Now you can turn on or off the configuration
transfer function.  Since the main menu was getting full,
I added this to the TIMINGS menu.  Just hit 'A' to see the
timings menu.  Then hit 'C'.  The status of the installed
disks will be shown.  'Y' means they DO respond to
configuration commands.  Enter the disk's number to toggle
its status with regard to this function.  I believe this
should only be necessary when getting ready to format, if
at all.

I realize this discussion of REV 3.01 isn't exactly
simple.  I hope you can glean the necessary info from it.
It should be worth the effort to get ULTRA SPEED going and
to cure formatting problems.  Call or write if you have
problems, bugs, or suggestions.  I'd especially like any
SPARTADOS experts to tell me how it tells me to go back to
high speed.

What is the '@' command SPARTA sends to device $4F?  Also
any info on how to get SPARTADOS to accept ANY size disk
image would be useful.

Rev. 3.05:

I added many more choices to the standard disk sizes for
the "create disk" option (option #6).  The new choices are
those which correspond the selections in the SPARTADOS
format menu.  This is to make your choices easier when
using SPARTADOS. Internally, things still work the same.
Again, with MYDOS, you shouldn't need to worry about
certain prescribed sizes.  Rev. 3.17 refined and corrected
much of this.

SIMULATED DISKS:

The main event for 3.05 is the addition of what I call
"simulated" disks.  This allows you to install any PC file
as an Atari disk, without the necessity of converting it
to an Atari disk image..  This is more or less intended to
replace the much despised MAKADISK.EXE.  The features,
theory of operation, and limitations are described below:

The simulated disk is always single density (no size
limit) and DOS 2.0/2.5/MYDOS compatible.  It can't be
written to, and can only be read sequentially (no random
access).  You CAN copy your executable files to the PC
with FILE2PC and load (run) them directly using this new
function.  If you ask for a directory, you will see the PC
file's filename on your Atari. (The length in sectors has
no meaning.) Normally, after the end of file has been
reached, the system automatically unloads the disk.  If
you don't want this, use the /N (no space) option after
the filename and the file pointer will be reset to the
start of the file after the end is reached - making the
file available to read again.  A new command has been
added to install the simulated disk - the "I" command.  It
replaces the old "Z" command (create double) which is now
a separate choice under the Create Disk option.

The new function works like this:  A simulated directory
sector is given on demand (#361). (When read, it causes
the file pointer to be reset to the start of the file.)
There is also a simulated sector #1 and sector #360
because some DOSes read these sectors to get information
about the disk. The simulated directory supplies a dummy
sector pointer to sector 401 to start the file. Each
simulated data sector increments the sector number for the
"next sector" link.  Thats why the status line will show
you reading sector 401 thru 700. Then, it rolls down to
number 401 again.  So if it rolls over, you have read 300.
(As of 3.10, trying to write doesn't return an error to
the Atari, it "pretends" to write the  sector.) Trying to
read a sector out of sequence doesn't return an error
either.  The program would still just supply the next 125
file bytes if this happened.  Note: if you need full
functionality (READ, WRITE, RANDOM ACCESS) for your Atari-
file-on-a-PC, just copy it to an Atari (SIO2PC) disk
image.

There are a lot of uses for this new feature.  You can
download Atari files to your PC and immediately load/run
them on the Atari.  You could program in 6502 on the PC
using a cross assembler and load the files to the Atari
with no translation required. You may choose to keep some
favorite programs available under a "one Atari file per PC
file" basis as an alternative to having files under Atari
disk images.

With rev. 3.11, boot files may also be simulated.  To use
this feature, just put /B after the file name.  You can
combine /B and /N if you want.  The program will send the
next sequential 128 bytes to the Atari each time it
requests a sector, until the end of file is reached.


PRINT-THRU:

The serial bus ID for the Atari printer is 040h. With
PRINT-THRU in effect, the program answers bus commands
directed to the printer and routes the data to the PC's
printer or screen, as selected. Note that the Atari uses
an EOL character (09B hex) to mark the end of line, while
the PC uses carriage return and line feed (CR/LF)
characters. So SIO2PC gives you the option of making the
translation. If you are printing text, you should
translate. For graphics, probably don't translate. You can
also strip the high bit if you want. The reason?  ASCII is
a 7 bit text code. Computers use 8 bit data. So, text with
the high bit set is not defined under ASCII, and different
computers use it differently. On the Atari, text with the
high bit set is printed to the screen as inverse video. On
the PC you may get graphics characters. So, when printing
text, you usually want to clear the high bit. If you are
printing 8 bit graphics data, you usually don't want to
change it.

For revision 2.6, I've made some changes to the PRINT_THRU
function. The reasons, and other comments, are summarized
below:

PRINTER NOTES, REV. 2.6

Due to reports of problems with the PRINT-THRU mode in
certain cases, I've reworked the print-thru routine.

My basis for this feature is to try to provide 100%
compatibility with the Atari 850 Printer/Serial interface,
since it should be the standard for the Atari. I went back
and reread the functional description in my 850 manual.
Here is a summary:

The Atari printer handler (in the computer's CIO, not in
the 850) sends fixed length records (40 characters) to the
printer. If an EOL (RETURN key) is encountered, it fills
the rest of the buffer with spaces and sends it. Note that
software on the Atari doesn't necessarily have to use CIO.
It can send data directly to the serial port using SIO.
Fixed length, 40 byte, records are still necessary because
the interface expects them. Now, when the 850 receives a
40 byte record from the computer, it goes by these rules:

1) Send all bytes to the printer, as 8 bit data (no
clearing the high bit) except,

2) If an EOL (9B hex) is encountered, convert it to a CR
character, and ignore the rest of the buffer (assumed to
be extraneous spaces supplied by CIO) except,

3) If several consecutive EOLs are found, translate them
all to alternating CRs and spaces and send to the printer.
NOTE: rev 2.8 took out the spaces. My version was adding a
space even if there was only one EOL, causing alignment
problems in the printout.

My interface was designed to provide several modes of
operation, one of which would emulate the 850 exactly.
However, it wasn't doing some of the things above. It
didn't ignore characters after the EOL. It didn't
translate multiple EOLs to multiple CRs, only the first.
It also translated EOLs only to CR plus LF, not CR only.
Now you have the option of doing either.

What do the 850 rules above mean to the Atari printer
programmer? Well, as I see it, you can NEVER send a hex 9B
to the printer, because the conversion is irrevocably hard
coded into the 850's ROM. Since graphics data by nature
can represent any dot pattern, it must include all
possible combination of bits, including $9B. This really
isn't a huge problem. The software would just have to
detect EOLs and change one bit. One dot's worth of error
out of every 256 * 8, on average, won't hurt anything.
Another "cure" would be to have a printer which requires
7, not 8, bit data. Since $9B has its high bit set, it
would never be required to send graphics data. (Just as it
is not required to send standard ASCII text, a 7 bit
system.)

All this info is presented for your amusement only.
Hopefully, if my emulation of the 850 is correct, your
software will play just like it did on your Atari printer.
Of course, the Atari software will have to be configured
for the characteristics of your PCs printer, not your
Atari's printer, assuming they are different.
Rev 2.10 information: I added a value to the TIMINGS menu
for the printer. This is experimental at this time. One
guy has a problem with the system (PC) locking up after
3/4 page or so. I think maybe his printer isn't
handshaking properly, so I've added this timing value, to
keep from "overrunning" his printer. The normal value is
0. If you have problems, add a little time. This value is
in units of 1/18th of a second, so keep your number small
or you'll be in for a long wait. It is the value used
between sending of 40 byte records to the printer. Figure
out about how long it takes your printer to print a line
and use about half this value in seconds. So if your
printer printed a line in 1 second, the value used would
be 0009 for 9/18 of a second.

In 3.07, I added another translation to the PRINT-THRU
function.  Now, you can also change the ATASCII tab
character to a standard ASCII TAB in the PRINT-THRU
process.  A 'T' on the PRINT-THRU status line shows that
you have chosen this option.

UNINSTALL DISK:

Why is it important to be able to do this?  Well, if you
have already used up all your memory in defined ramdisks,
you can't overlay them with new ones unless you remove the
existing ones. This often would mean you had to quit
SIO2PC and restart it to get the configuration you wanted.
Now, you can delete ramdisks, and thanks to "garbage
collection" performed by the program, all data moves down
to fill in the hole. So, you now have free memory equal to
the size of the deleted disk.  Uninstalling "file access"
disks doesn't free any ram, but it does free up one of
your four allowed virtual disks.

STATUS LINE INFO:

I've  created  a special status line, which is displayed
at  the bottom of the screen, to help identify problems
and to show  that the SIO2PC program is actively doing
something. It shows:

LOC: An identifier for the subroutine being executed.

CMND: SIO command from the Atari (Read, Write, etc.)

LAST: Command received previous to the one above.

DEV: Hex number for device being addressed by Atari.
Note
31 - 38 = D1 - D8; 40 = Printer, 39 = Remote Control
program
3A = FILE2PC program.

COM: High/Low status of the Atari command line.

ERR: An error code returned by one of SIO2PC's
routines.
A character here doesn't necessarily mean a problem.
To aid
me in debugging.

SEC#: The sector # currently being written to or read
from    by the Atari.

RAM: The amount of RAM you have free for use.  It
changes as
you install and uninstall ramdisks.

SPEED: N means normal speed 19.2K Baud, H means high
speed,
as in Sparta Dos' high speed I/O.

Note that the status line is updated even when the device
being accessed isn't an SIO2PC device.  This allows you to
use SIO2PC to eavesdrop on the SIO bus.

PC MEMORY USAGE:

The technically inclined may want to know how the program
decides it has the right to RAM for its ramdisks.  Well, I
initially wrestled with this one. I was trying to use a
DOS function for "Allocate Memory," but I got an error
code meaning "no memory available."  This was crazy,
because SIO2PC is a very compact program. It turns out
that when DOS runs a COM file, it allocates ALL available
memory to the program. This is because DOS is intended to
be a single tasking system.  I took advantage of that
fact. My program doesn't ask for memory, it just takes it,
as though it's the only player (which it should be).
(Note: TSRs loaded BEFORE SIO2PC are safe. SIO2PC only
uses memory higher than that allocated to itself.)  I use
an internal DOS variable to decide if there is enough
memory to load/create the ramdisk you request.

DOS SHELL FEATURE:

The main improvement added in rev. 3.08 is the ability to
"shell out" to DOS. What this means is, you return to the
DOS command line prompt "C:>" while SIO2PC is still
resident.  Then you can run DOS commands or programs, type
EXIT, and be back in SIO2PC. You will of course be subject
to limitations on the amount of memory available with
SIO2PC and any ramdisks you have resident in memory. It's
a good idea to avoid messing with (deleting, renaming) any
files that SIO2PC has open, such as file access disks.
(SIO2PC doesn't leave files open when ramdisks are
loaded.)  In order to make this function fit on the menu,
I had to dump a function.  So, I took "R" off the screen.
This is the function which restores the screen (ESCAPE
also works).  Note that "R" still works, you just don't
see it on the menu.  Due to the way memory is managed, you
shouldn't install any TSRs while in the DOS shell.

VIRUS DETECTION:

I got a rude introduction to the world of viruses a while
back when I found that my system had been attacked by a
virus.  Since then, I've added the byte count on the sign
off message as a small first step. Rev. 3.03 adds some
more complex checks.  As soon as SIO2PC gets control, it
loads a second copy of itself into memory. Why?  Because
the virus may have already "done its thing" to the running
copy, then fixed it to look unchanged.  Anyway, SIO2PC
loads a second copy, and checks to make sure it isn't any
bigger than its supposed to be. You get a message if the
size is wrong.  It then does a CRC calculation on the
copy. If the CRC result isn't as expected, you get another
warning.  The program will still run, however.

I translated the CRC calculation algorithm from C code in
a book on serial communications.  My version may not be
exactly right, but it does work.  I've tried toggling a
single bit and got the warning.  Please note that no
system is foolproof.  Virus and counter-virus development
is like the arms race.

These additions don't seem to slow down program loading to
any appreciable extent, but for those of you who can't
tolerate ANY slowdown, I've included an override.  Just
put /v or /V on your command line somewhere after the
program name and the virus checking will be skipped.  (You
should put the /v after the port # since the program comes
up expecting a port #.)

If you make changes to the program by interrupting it
while it's running (as I showed you how to do elsewhere),
it may make the CRC wrong.  To fix this, I've had the
program print out the  calculated CRC with its sign off
message. The idea was that you could patch in the correct
CRC value with DEBUG.  However, with rev 3.08, that's been
automated:

In 3.08, I changed the virus detection function (CRC
check) so that the program will offer to fix SIO2PC's
internal CRC value to that just calculated.  This is
mainly for me, so newly assembled versions can have their
CRC set automatically.  If you get the warning and haven't
changed the program, better get out your virus checker and
go over your files.  Delete SIO2PC and install a healthy
copy.

REMOTE CONTROL PROGRAM USAGE

This section is to tell you how to use the Atari program
called REMOTE.OBJ. This program is found on your disk
image file, ATARI.ATR.

The program allows you to send commands to SIO2PC from the
Atari, just as if you were typing them on the PC's
keyboard. So, if your Atari and PC are in different rooms
(or something), you can swap ramdisks, save and load, etc.
without leaving the Atari. The file is fairly small, and
if you plan to make use of it, you should copy it to as
many ramdisk images as necessary to assure that it's
accessible when you need it.

When the program comes up, it shows a list of most of the
SIO2PC commands. If you want to study this list, hold down
the START key, or else it will scroll off after 3 seconds.
The program next gets the status's of the 4 disks from the
PC and puts them on the screen. Now you are ready to enter
your command. Say you want to load a disk image from
A:\ATARI.ATR into ramdisk #4. Just type L4A:\ATARI.ATR and
RETURN. Note that some commands give you prompts which you
must answer in your command string, so anticipate them.
For instance, if you tell the PC to write back a file, you
need to anticipate "USE EXISTING FILESPEC?" and "FILE
EXISTS, OK TO OVERWRITE?". Note that if writing was
successful, the "W" in the status line will have changed
to "N" after completion. One person was using REMOTE.OBJ
on the Atari as an AUTORUN.SYS, and feeding it with a
batch script from SPARTADOS to automate setup of his MIO
ramdisks. Because he couldn't simulate a character from
the keyboard with SPARTADOS, my "Run another command
(Y/N)" left him stranded. For this reason, you can now
skip the command by starting your string with a space.
When REMOTE.OBJ sees the space, it will send the command
to the PC, then return to DOS automatically.

Note: After transmitting a command, REMOTE.OBJ is allowing
the PC a certain number of seconds to complete it before
giving up on getting the ramdisk status. If you find that
not enough time has been allowed, let me know so I can add
some more. (If you choose to skip the rerun prompt, you
won't be getting the ramdisk status after command
completion.)

MAKADISK.EXE

As I stated earlier, the need for MAKADISK.EXE has been
pretty much eliminated by the introduction of SIMULATED
DISKS, which allow the Atari to load in a file which is in
native PC DOS file format.  However, you may still find a
reason to use MAKADISK.

The purpose of this program is to allow you to take a PC
file and convert it into an Atari ramdisk image so your
Atari can read it. For instance, you may have a modem on
your PC only, and want to download Atari files. Or, you
may want to write program source code on your PC, because
it has an 80 column screen, and send it to the Atari for
compiling.

At present, this program is basic - it allows you to put
only one file to a standard single density ramdisk image.
You should then boot the Atari up with SIO2PC and copy the
file to a real disk or a "full featured" disk image (one
created by SIO2PC and your Atari DOS). Then you may as
well delete the MAKADISK created ramdisk image, it has
served its purpose. You can't write more files to it, the
VTOC isn't correct.

Note that another utility may be useful. I want to make
one, but they are available in public domain (PC
Magazine's utilities disk has one). The utility needed is
to translate PC "end of line" codes (CR and LF) to the
Atari EOL code, which is hex 9B. If you are translating
text files, you will probably need this. Binary files
(such as executable programs) shouldn't generally be
translated.
Note that MAKADISK asks for three things:

1. The name (or pathname) of the PC file to be converted
to Atari.

2. The name of the PC's ramdisk image file. This is the
name you will give SIO2PC when you load the ramdisk image.
I use an .ATR extension for all my ramdisk images stored
on the PC, but you can use what you want. Note, MAKADISK
doesn't tell you if there's already a file by that name,
so be careful, existing files will be overwritten.

3. The name of the Atari version of the file. This is the
name you will see in the first position on your Atari
screen when you ask DOS for a directory.


FILE2PC USAGE INFORMATION


FILE2PC.OBJ is an Atari program found on your ATARI.ATR
disk image file located on the distribution diskette. If
you run this program on your Atari, it will cause SIO2PC
to go into the file transfer mode. Just follow the prompts
on the Atari. You can read the technical details in the
TECHNICAL INFORMATION section if you're interested. This
file transfer function has been much requested. A lot of
people seem to have text files on their Atari's and want
to transfer them to their PC's so they can pick them up on
the PC's word processor. I should tell you that the usual
warnings apply to this: Different word processors use
different formatting control codes. This is true even if
you aren't going to a different computer. Plus, the Atari
has its own method of ending a line. It uses an EOL (9B
hex or 155 decimal) to tell its editor to drop the cursor
down one and move to the left margin. The PC, on the other
hand, uses two codes, CR & LF or carriage return and line
feed. They are hex codes 0D and 0A (decimal 13 and 10).
There are utilities available which translate codes like
these. There was one called CHANGE on PC Magazine's
utilities disk. Unfortunately, it only works with files up
to 40K in size. I want to write one without this limit. A
common denominator is the so called ASCII file, which is
free of specific non-standard formatting commands. (Like
this file.) If your Atari word processor will output a
plain ASCII file, you may want to use the option before
sending it to the PC. Some Atari programs will allow you
to use an OS feature which lets you PRINT to a disk file.
This should yield a plain ASCII file. Also, if you wanted
to send it to your PC's printer, it should definitely be
ready to go in this format. Anyway, you will probably want
to use a filter program to change your 9Bh's to CR/LF's as
a minimum. Note that 9Bh looks like a "cents" symbol on my
PC. To see it, hold down ALT on the PC and type 155 on
your numeric keypad.

Rev 2.3 note:  Now that the PRINT_THRU function allows you
to "print" to a PC file, you have another method of
transferring your Atari text files to PC files. And since
the PRINT_THRU option has EOL to CR/LF and TAB conversion
capabilities, it may be easier to use in some cases than
FILE2PC. Remember, Atari DOS allows you to COPY a file to
P:.

FUTURE PLANS, CURRENT PRICING

I now feel that SIO2PC is becoming a pretty mature
program. However, there seems to be no limit to the number
of enhancements one can dream up. I would like to take a
stab at making the system capable of copying copy
protected disks, with the ability to run them from SIO2PC
storage without the original disks. I don't really see
SIO2PC as some sort of copy protection cracker, but it is
a pain for users to have this system and still have to
rely on an Atari drive to run some of their software. I'm
not sure how effective this system will be, because I'm
not up on all copy protection techniques, but ... we'll
see.

I also hope to soon try to implement the Lightspeed I/O
feature you Spartados/U.S. doubler users know and love.
DONE

It also occurs to me that some sort of Auto-compaction
should be possible.  I could have the program keep track
of the highest sector # written, and store only data to
that point.  The empty portions of partially written
disks, in general, wouldn't take up any disk space.
(DOSes generally use sectors sequentially, from low to
high numbers.)


On the hardware side, I am still trying to simplify the
assembly of the interface. It takes far too much time for
the price charged to wire one up. So, I may soon make the
DB-9 connector mount on the board and protrude thru the
case, just like the ones on your PC do. This will save a
lot of time stripping cables and wiring/assembling
connectors. It will also mean that the interface will need
a DB9S to DB9P or DB25S to DB9P cable to interconnect it
to the PC.  I'll probably soon change the hardware so that
the interface won't interfere with the SIO bus, even when
the PC is turn off or not connected.

Please see BUILD_IT.DOC for the current prices. I had
hoped (and still do) to hold the price as low as possible.
Shortly after  receiving mention in Antic, I discovered a
hardware problem which made it necessary to double the
complexity and cost of the interface. SIO2PC is still just
a hobby to me. I don't hope to recover my programming time
(about 3 years). But I seriously underestimated the time
needed to assemble the interface, and do hope to get some
reward for that time. (Since soldering isn't fun*, like
programming.) Since I've sold only a few interfaces so far
(about 50 as of Jan, 1992), I haven't had a custom circuit
board built. Therefore, I have to hand wire the circuit on
prototype boards, with quite a few jumpers required.
What's the bottom line of all this whining? I expect to
have to either streamline assembly, raise my price, or
both. I've also considered making the software "shareware"
and publishing the schematic so users could pay me for the
software and build their own interface from scratch or
optionally order from me. Any advice?    ***  DONE!!!


*Building one is fun. Building 10 or 20 is drudgery.


REVISION LOG:

1.00:  First release

1.01:  Now uses default addresses for COM 3 & 4 if BIOS
data doesn't give addresses. Added option menu item "O",
sub option "I" to allow ignoring CTS, "I" is now the
default. If your status line will show "H" in the Atari
field with the Atari "on", you can toggle this function. I
believe the program functions fine while ignoring CTS,
however, and may eventually delete the input entirely.

1.02:  Changed the stack pointer to be 256 bytes at the
program end. This means the program now only uses about 8K
instead of a full 64K segment. Now, on my system with only
DOS and a 10K Mouse driver installed, I can get 3 - 143K
ramdisks (as usual) plus an extra 92K ramdisk. Killed a
bug which caused the program to not recognize SIO bus
command 022h, which is "format in DOS 2.5  1.5 density".
Added clear of all disk info lines every update when I
noticed that garbage sometimes remained from old
filenames. This change is cosmetic only. Reduced the
timeout value which the disk returns to SIO. This should
reduce the time the atari waits when it is given an
invalid format command. Changed the method used to put
command codes to the status line. Now even invalid command
codes will get listed, adding to ease of de-bugging. Got
rid of a bug which could cause an invalid error report
when writing a ramdisk back to an existing filename.
Changed the method used to control the RTS line. Now the
other lines of the MCR aren't affected. Note: These errors
are primarily the result of switching from one assembler
to another. (now on QUICK ASSEMBLER).

1.03  4/3/90 Rewrote the routine for generating time
delays. I had been reading the refresh timer. Now, I'm
reading the system timer and using a different method
which should be more reliable and compatible.

1.0  4/10/90 Added option "E" under Options. Now, the user
can manually input port addresses.  The program also now
puts to the screen the actual address used, whether manual
or automatic.  Put the address in Hex format.  The
standard addresses for COM 1, 2, 3, & 4 are: 03F8, 02F8,
03E8, & 02E8.

1.05  Added some diagnostics. Now, on initialization of a
PORT, the software reads back register LCR and gives a
warning message if doesn't read as programmed. Then, the
port is tested by sending a byte in the  loopback mode. A
warning is given if it fails. If these warnings occur,
your program will probably fail. Either you have an
incompatible COM PORT, or the program is using the wrong
PORT addresses. Check your documentation and use "E",
described above to set the PORT addresses. Also, the
program now always sets up the UART chip (serial port
chip) directly, instead of using BIOS. Also in this rev,
the timer chip, timer #0, is now programmed in mode 2,
count = 0 for a period of 55 milliseconds. This is the way
it should already be, but now I'll take no chances. I
replaced my "long time" timer routine, the one I use for
keeping warning messages on the screen for 2 to 3 seconds.
The old routine would occasionally lock up, or take far
too long. Now, I have redirected the timer 0 interrupt for
this purpose. Rev. 1.05 fixes a small bug which could
result in extra characters on the filename line. It also
fixes a bigger bug - the program used to write to a random
address (Segment Register wasn't initialized) when it
thought it was putting the default port address into the
BIOS data area, after it had been found to contain 0. Now
it just leaves the 0 alone.

1.06  Quite a few changes. Added the FILE2PC subroutine,
which works with the FILE2PC.OBJ Atari program. This gives
you the capability      of sending Atari files to the PC to
become PC files, rather than Atari disk images. This means
you can read the files with your PC's word processor. Rev.
1.06 also changed the logic on switching the PC's data out
line to tri-state (off line) level when it is not in use.
Some people were having trouble with erratic and slow
operation, and the switching of this line was believed to
be causing spurious pulses. Now it only turns off when a
non-SIO2PC device is addressed, less that 1% as often as
before. Another addition to rev 1.06 is the addition of
double density.         Now you can choose 183K ramdisks and
double density sectors. Note that sectors 1,2, & 3 are
single density, so the ramdisk can be a bootable disk.
Currently, you can only specify a double density ramdisk
by choosing "Z" instead of "C" for the "Create Ramdisk"
function. Then use a DOS that recognizes double density,
such as MYDOS. I also made some changes to the LOOPBACK
test performed on the UART (serial chip) upon
initialization. I found I was getting occasional "failed
loopback test" messages when everything was really OK. I
did some fine tuning and  haven't gotten a bogus message
recently.  I also added a function ("R"), which allows you
to restore a trashed screen. Despite my best efforts, DOS
will sometimes manage to sneak in one of its messages,
causing a scroll and messing up the screen. Use this
feature to fix it. (As of rev 2.8, ESCAPE does the same
thing.)

1.07  I added a directory display function, under Options.
You can just give it a filename, including wildcards to
search the current directory, or a complete pathname to
search other directories. Now, when you're in SIO2PC and
can't remember the filenames of your disk images, you
don't have to quit the program to find them. I name all my
Atari disk images with the      extension ".ATR" and so I
search for "*.ATR". Also in this release, when you choose
"Quit", the program warns you if you have written to any
ramdisks but not yet saved them back to disk.

        Rev. 1.07 was to include the "PRINT THRU" option, but
it's not
        quite done. Rev. 1.08 will have it soon.

1.08  PRINT-THRU mode incorporated. Now, you PC can serve
as an Atari to printer interface. You can have your
Atari's printer output go to either the PC's printer or
screen. You can also choose  whether to convert EOL's to
CR/LF. Also in this rev, I added an Author credits screen.
This screen goes away as soon as you give the port #. I
moved the "Restore Screen" function from the Options menu
to the Main menu. After having Atari output printed to
your screen just press 'R' to restore the menu.

1.09  Added feature to allow choice of stripping high bit
on PRINT-THRU data. This way, Atari inverse video text
will come out as normal text. (Without, it would print as
garbage.)

2.0  Added function to allow deletion of a ramdisk. This
function fills  in the hole created in memory by the
deletion  and allows the freed memory to be used in
creating other ramdisks.

2.1  Changed the Atari program REMOTE.OBJ and changed
SIO2PC to correspond. REMOTE.OBJ now asks for ramdisk info
from SIO2PC at program start and after each command.
SIO2PC sends that info to the Atari. Now, the remote user
can get a fair idea of whether his command was successful
or not. Also, now a leading space in the command string
will cause REMOTE.OBJ to go back to DOS after completion
of the command without asking if the user wants to send
another command string.

2.2  Changed the point at which the program looks at the
device number in the command frame and disables the data
out line if a non-SIO2PC device is being addressed. This
is in hopes of  curing an interference problem some
users have experienced when using real drives and SIO2PC
together. 08/05/90

2.3     AARGH!!  Rev. 2.2 still didn't take care of the
elusive "problem". So, this version adds a switch which
allows the user to lock SIO2PC's data out line into the
"enabled" state. This was  verified earlier to work. Also,
I finally did away with the old CTS or "Atari" line, which
didn't seem to have any advantage. The idea was to carry
the 12 volt line from the Atari to the PC to tell the PC
it was on. It turned out that some PC's didn't recognize
it, or some Atari's didn't have the 12 volts out. But,
anyway the program worked fine without it. Another big
change is the redesign of the user interface screen. It
has become obvious to me that the separate "Options"
screen was cumbersome and unnecessary. So I've combined
all choices onto one screen. This means there are some
functional changes, for those of you using batch and
remote script files. First, option "O" is no more. Also,
the "D" display status line choice is now "T", toggle
status line. Another enhancement added with this revision:
Now, you have a  third option with PRINT_THRU: You can
specify that the Atari's printer bound output be sent to a
PC file.

Still another change is to the Status Line. Replacing the
"Atari" line status is the DEVID identifier. This is the
SIO bus ID of the device being addressed. Elsewhere in
this README file are the ID's of various bus devices.
Also, as of this revision, the program updates the Command
and DEVID fields even when a non-SIO2PC device is being
addressed. Now you can see what your Atari is telling
other devices, if it's trying to address non existent
devices, etc.

2.4  Changed the directory print-out from 2 to 4 entries
per line.  Now your directory can have more than 90
entries without scrolling off the screen. Wrote handlers
for the Critical Error Vector and the Control - C vector.
The Critical handler is the one which gives you the Abort,
Retry, Fail message if your drive door is open, the
printer is out of paper, etc. It turned out that this
would let you bail out of the program without going
through my normal "Quit" routine. This restores the timer
interrupt, for one thing. Anyway, now you get plain
English messages and can still bail out if you want, but
won't lock up your computer anymore if you do! Also added
some obscure functions to Print-Thru that used to work
with the original Atari 40  column printer, the one that
plugged right into the SIO port. I don't know if any
software out there sends these commands or not. Also added
the SHAREWARE message at the end of the program.

2.5   Adding user command "A" to adjust timing values.
Allows user to set critical time delays used in the bus
data transfers, to try to iron out differences between
different systems. This addition is menu choice "A" and
adds the TIMING menu. This shouldn't be necessary in 99%
of cases, but here it is in case. See the "timing" section
or the TECHNICAL INFO part of this DOC for more info.

2.6  Worked over the PRINT_THRU routine to make it more
flexible and more compatible with the 850 interface. Also
moved the default "timings" value to the front of the
program to make it easier to find and change with DEBUG or
NORTON's utilities.

2.7  Changed the PRINT_THRU routine so it will detect a
"disk full" error when printing to a file, alert the user,
terminate the PRINT_THRU process. This need was pointed
out in Bob Wooley's AIM review.

2.8  Fixed a bad printer bug caused by rev 2.6 in which
lock up of the PC would occur if you were converting EOL's
to CR/LF's and an EOL occurred at byte 40 of the printer
buffer. I also got rid of the space added after CR/LF
because it was causing problems. Also fixed so the ESCAPE
key works the same as 'R' to restore the screen. Most
people jab the ESC key when they get confused.


2.9  Did a little more work on the "disk full" problem so
it gets addressed anytime you are writing to a disk:
PRINT_THRU, FILE2PC, or WRITE DISK FILE.

2.10  More work on Print-thru. Added more LOCATION and
ERROR  codes to help in trapping errors.  Also added a
time value to the TIMINGS menu to be used when printing to
a real printer. It causes a wait between records sent to
the printer.

2.11  Added a byte count to the sign off message so the
user can check if a virus has changed the program size.

2.12  Added directory function to extract the Atari disk
directory from a disk image file.  Now working for Atari
DOS 2 & 2.5 compatible DOSes only.


3.00  Added "file access" disks.  Now the user can have
disks up to 16 megabytes in size.  Increased allowable
disk numbers from "1 thru 4" to "1 thru 8".  Added the
color interface screen and color coded key fields and
statuses.  Added fields to show the status of the
PRINT_THRU function.  Added support for "get
configuration" and "set configuration" commands.  Added
the "sector #" and "free ram" fields to the status line.
Fixed the status line so it's updated even when not being
displayed.  Fixed a bug which caused return of incorrect
status for double density disk images.  Warns before
uninstalling a ramdisk which hasn't been saved.
Formatting now clears the disk image to zeroes so it can
be compacted better.  Killed a small bug on the REMOTE
CONTROL program which may have appended one spurious
character onto the command string.  Split source file into
3 parts.

3.01  Corrected some bugs from 3.00;  Added ULTRA SPEED
I/O (SPARTADOS compatible).  I don't have all the
difficulties worked out yet, but it is working.  The bit
rates available on the Atari don't exactly match those
available on the PC, so I had to pick a rate where they
were practically the same: 38 KB.  This isn't as fast as
the US Doubler can go, but it IS twice as fast as SIO2PC
usually goes.  A few cautions are in order.  I couldn't
fully understand all the stuff SPARTA DOS is doing.  It
goes to high speed, then back to regular, and again to
high. I get lost somewhere in the middle as to what is the
signal to go back to high speed.  As a patch, I put in the
"J" command, for Jump to Ultra-speed. It actully toggles
between the two speeds. (There's also a new field on the
status line for speed: "N" for normal, "H" for High.)
We'll find other complications as we go along.  For
instance, trying to mix high speed stuff with functions
which work in regular speed (PRINT_THRU, REMOTE, FILE2PC)
will probably cause problems. We should probably limit the
high speed stuff to loading, saving, and copying files.
But that's most of what we do anyway, right? Also did a
lot more work on disk configurations.  I'd especially like
any SPARTADOS experts to tell me how it tells me to go
back to high speed. What is the '@' command SPARTA sends
to device $4F?  Also any info on how to get SPARTADOS to
accept ANY size disk image would be useful.

3.02  Fixed a bug which was keeping the DATA out line on
too long.

3.03  Added virus check routines for file length and CRC.
Fixed a bug in FILE2PC.OBJ.

3.04   I did some work on the directory functions. First,
a minor fix.  The separator between a filename and its
extension was supposed be a period (.) for a normal file
and a star (*) for a subdirectory. This logic was reversed
until now. Second, I've added SPARTADOS awareness to the
function which extracts directories from Atari disk
images.  For the program to know that the file is a SPARTA
image, its name must end in an 'S'.  I use an 'ATS'
extension for SPARTA images and 'ATR' for others.  A nice
feature I added for this function is the ability to
automatically expand subdirectories in addition to the
Main directory.  I don't even have this working for MYDOS
yet.  You can view all your Atari files with a request to
see '*.AT?' if you use a naming convention like mine. OK,
SPARTADOS users, are you happy now? I'm also doing some
hardware changes.  I'm now going to a hardware version
which is simpler, but should work better.  It doesn't use
Tri-state logic.  Instead, it uses an open collector type
logic to keep from interfering with other bus devices.
This design should be better capable of not interferring
when the PC is off.  Since there is no Tri-state
switching, the RTS line is not used, and the "Lock Data
Line" function has no meaning.  Also, the status of the
command line to the PC is inverted.  This necessitated a
change in software. For the new hardware, the revision
number at the top of the screen ends in a lower case 'i'.
I'm putting this information out in case I get the wrong
version to anyone.  It will ususlly work, but sputter
along.  Whichever version you have, just let me know if
you want the other one and I'll send it.  I would send out
both versions now, but there's not enough room on a 360K
distribution disk. (Also, ACOMINIT.COM is not needed with
the new hardware.)

3.5  I added many more choices to the standard disk sizes
for the "create disk" option.  The new choices are those
which correspond the selections in the SPARTADOS format
menu.  This is to make your choices easier when using
SPARTADOS.  Internally, things still work the same.
Again, with MYDOS, you shouldn't need to worry about
certain prescribed sizes. I did a lot of tweaking on the
"main loop" (the one which monitors the bus for commands
and dispatches the various SIO command functions).  I
think I found one error.  One user (at least) was having
major problems with revision 3.03.

The main event for 3.05 is the addition of what I call
"simulated" disks, described earlier.  I also added a
feature to get rid of the character in the ERR field of
the status line when you use the "R" command or just press
ESCAPE. This gets you back to a clean slate.  To be
honest, even I don't know why some of these errors occur,
but most are harmless.  For instance, your Atari DOS may
be polling non-existent devices to see what's there.
There's another thing the "R"/ESC command does for you:
It bugs some people that the cursor ends up at the right
end of the screen after some functions are completed.
They think this means the system is "hung up."  The
"restore screen" command will put the cursor  back on the
left, where it belongs.

3.07: I added another translation to the PRINT-THRU
function.  Now, you can also change the ATASCII tab
character to a standard ASCII TAB in the PRINT-THRU
process.  A 'T' on the PRINT-THRU status line shows that
you have chosen this option.

3.08:  The main improvement added in rev. 3.08 is the
ability to "shell out" to DOS. This is described in the
Technical Notes section. Added automatic (user's choice)
correction of the internal CRC if legitimate changes
caused a false virus warning (The user must verify this.)

3.09:  Fixed a small bug which caused numbers in the
filenames of simulated disks show up as graphics symbols
in the Atari directory of the disk.  It was in the
"convert to uppercase" routine: numbers don't need
converting!

3.10:  Made some changes to the "simulated" disk function:
First, it no longer returns an error (just an 'S' in the
ERR field) if the Atari tries to write to the disk.
Second, it now gives the simulated disk a "normal" status
- not "locked" and not "in use."  Why did I do such a
crazy thing?  Well, some programs (such as my assembler,
AMAC) want to open the file for write access, even though
they don't intend to write to it.  Don't ask me why.
Opening the file in this way includes writing to the
directory sector.  It could be that others have
encountered this problem.  Anyway, now I can write my
source code on the PC, filter it through a utility to
convert it from ASCII to ATASCII, and assemble my program
without ever copying it to an Atari disk or disk image.
Another change is to the sector number reported by the
simulated disk.  It's pretty boring and not very
informative watching all those sector # 100s go by on the
status line.  So now, the program now starts with sector
401 and counts up to 700, then again cycles to 401.
(Note: it's still sending sequential data, it just reuses
the sector number.  DOS isn't smart enough to realize it's
seen the sector number before, and some DOSs might get
confused by sector nunbers > 720.)

3.11 - More changes to simulated disks: now you can
install a simulated BOOT disk, by using /B after the file
name on the 'I' menu choice.  I also did a little human
engineering on the virus/CRC warning message.  I want
people to realize that  something's potentially not right.
So now the warning is in flashing green.  Also, to fix the
CRC (after assuring oneself that there isn't really a
virus at fault), the user must type 'OK' instead of just
'Y'.

3.12  Found a bug in the extract Atari directory function
which caused improper action on SPARTADOS files.  Also
added an Escape Key bailout from that function.

3.13  A user complained that he gets printer timeout
errors  when  using PRINT-THRU, so I experimentally
increased some timing values.

3.14 - I found that the speed of "simulated" disk accesses
had  slowed  for unknown reasons.  Turns out I had
duplicated a variable name with a local code label, so a
timing value was greatly increased.  Fixed it by assigning
a new label in my source code.

3.15 - Added screen blanking.  Press "B" to blank the
screen and ESC to restore.  Note: didn't add this feature
to the Menu.  I want to make it automatic in the future.

3.16 - Worked on the GET_DIR and GET_DRIVE subroutines, to
cure a problem resulting in an INT 024h hardware error on
startup.  It seems that DOS function 019h (get default
drive #) returns the number based on 0 = A, 1 = B, etc.
But function 047h askes for a drive number code based on 0
= default, 1 = A, etc.  This difference caused drive 2 (C
from function 19) to translate to drive 2, B, for function
047h; and a hardware error resulted if no disk in drive B.

3.17 - Fixed many inconsistencies and bugs and added
enhancements in response to a letter from Dr. Terry
Chamberlain of Cheshire, England.  He sent me a one page
letter of praise for SIO2PC plus a 16 page text file
listing bugs and desired improvements.  The changes are
briefly:

Lengthened bus timing values.

Major changes to standard disk formats:  What a hassle!  I
can't believe that all these years I thought a 1050
enhanced disk had 1120 sectors (28 sectors/track) and no
one else straightened me out!  My main excuse is that I
never had a 1050 drive until I was around the version 3.0
stage of SIO2PC.  Anyway, I have completely redone my
option 6(More) selections to include all of what he gave
me.  I also made choice 3 of the initial list be 133K
instead of 143K to correctly give the 1050 drive standard
size.  Through all of this I found one or two other minor
bugs and fixed them.  I hope this makes formatting easier
for SpartaDos users and users of other DOSes as well.

Fixed a minor irritant:  When you press ESC to abort your
input under Create Disk option 5 (input # of sectors) you
instead get a linefeed and a "/".  This caused me to
rewrite my "line input" handler, so now backspace works as
expected in this function and other functions requiring
input as well.  And ESC will now get you out of sub-option
C-5.

When using /P to force a file access disk, subsequent
requests were also treated as if /P had been chosen.
Fixed that.  Hope I also fixed some other glitches in file
access disk operation so it will be more robust.

Now when you shell out to DOS, it doesn't default to
C:\COMMAND.COM for its comspec.  It gets the comspec from
the environment string, which should make the DOS SHELL
feature usable for more users.  For instance, if you boot
from A: or if you use another command processor, like
4DOS.

The Extract SpartaDos directory function was messed up!
It didn't get all files and didn't expand subdirectories.
This was a real shock after all the work I put in on this
feature.  Anyway, now it's fixed.

These fixes and enhancements should make SIO2PC work more
smoothly for everyone.  Thanks to Terry for his careful
research.



PROBLEM DIAGNOSIS QUESTIONS

If you have trouble, I would like some information about
your system. (Actually, I'm interested even if you don't
have problems. Please send your comments.)

What kind of Atari? 800? 400? XE? XL? 1200? 600?

What Atari DOS? What type of formatting?

What kind and class of PC? XT? AT? '386? Original PC?
Clock Speed?

Has your port been verified functional with other
equipment?

What version of PC/MS DOS?

What does the status line at the bottom of the program
show?

How long does TESTIME1.EXE take to run? (Should be close
to10 seconds.)

Any detailed information from your PC's tech manual about
your serial ports and port addresses in general will be
useful.

If you only have problems part of the time, what specific
steps lead to the problem?

Please read the REV_LOG and TECHINFO sections of this for
some more information which may help with problems. Read
also any other .DOC files you find on the disk - there are
tidbits of information scattered through various files
which may be of use to you.


POSSIBLE PROBLEMS AND SOLUTIONS

Can't address certain drives

If you are unable to address certain drives,  such as  3,
4, 5, 6, 7, 8 (error 160 results), it may be that your DOS
isn't  set up to include these drives. On Atari DOS 2 and
2.5, you can  find out  by booting in BASIC and giving a
PRINT PEEK (1802)  command. The resulting number is the
sum of the following: 1 for drive  1; 2  for drive 2; 4
for drive 3, and 8 for drive 4. So if  you  get "3," your
DOS is set up for drives 1 and 2 only. To fix your DOS,
you  simply  execute a POKE 1802,15 command. Then go to
DOS  and execute  the "H" WRITE DOS FILES command.
Finally, turn  off  the computer and reboot.

Another  error that has plagued me from time to time is
this:  I "create" a ramdisk, then try to write to it
without formatting it first.  Remember, if you create a
ramdisk from scratch, you  have to format it. If you load
up a stored ramdisk, you don't have  to format (or create)
the ramdisk.  Another  problem which isn't the fault of
SIO2PC, comes when  you try  to format a 92K ramdisk with
DOS 2.5's normal  command.  You must  use  the "format
single" command here.  The  normal  format command  of
DOS 2.5 only works with the 143K ramdisks.  On  some
format  related  errors, the Atari will  retry  "forever"
before giving  up and reporting the error. So you may
think  the  system has locked up.

Note that on the 64K ramdisk, the program doesn't report
back  to the  Atari  that  the full set of 720  sectors
isn't  available. You'll  get an error 138 on the Atari if
you try to put too  much data to this ramdisk. A utility
is needed to mark the unavailable sectors  as "used" on
your DOS's VTOC. If this all sounds  pretty intimidating,
you may want to steer clear of the 64K ramdisk. (As of rev
3.00, the program DOES report the number of sectors
available - if the DOS is smart enough to ask.  But with
some disk image configurations, it may now be MANDATORY to
configure your Atari DOS to recognize the disk.)

Here's a problem I had recently (1993):  I was using
SIO2PC, which had been working fine before, and it started
sputtering along and returning errors (on the Atari) when
disk transfers were attempted.  After much brainstorming
and fearing a hardware problem, I found out that the
problem stemmed from "shelling out" to DOS from WINDOWS.
Evidently, WINDOWS keeps "checking up" on DOS programs to
the extent that it can interfere with high speed data
transfers.

Noise, especially from Printer:

One user told me that his SIO2PC was susceptible to noise
pickup from power cords, etc. (I have been able to run 75'
of unshielded cable near power cords, over air
conditioning units, etc, without problems, so you never
know.) Anyway, he said he wrapped the box in foil and
fixed it. I don't know if I'd go that far, but if you have
intermittent problems, you might look at the cable
routing. Yet another potential pitfall: You will usually
remember when you have a real disk installed, you must not
have an SIO2PC ramdisk of the same number, since a
collision will occur. But sometimes you (I) will boot up a
DOS which automatically installs a ramdisk handler on the
Atari, forgetting that there is an SIO2PC ramdisk of the
same number. When I try to access this disk #, I get
strange results not immediately identifiable as to the
cause. So, if you use Atari ramdisks, watch out for this.

Along this same line: I just got a letter from a user who
was having trouble with the PRINT_THRU function. It would
stop printing at unpredictable places. Then he noticed
that the Atari was plugged into a surge suppressor, but
the PC and printer weren't. When he plugged those items
into a surge suppressor, the problem was fixed. So this is
a major Ah-Ha! for anyone having random problems in this
area. Printers generate a lot of electrical noise. I never
have this problem on my system, but no wonder: My Atari
and PC aren't on the same desk, they are powered from
separate wall receptacles, and each has its own
surge/noise suppressor. Let me suggest a couple of other
things: Make sure your SIO2PC cable and your printer cable
are kept separate. If your printer and serial cables have
thumbscrews, tighten them up. I noticed this made a big
improvement on the amount of noise my computer outputs to
my ham radio.

If you can't get rid of the noise, here's another
solution, but not quite as clean: Set up SIO2PC to capture
the Atari's printout to a file. Then leave SIO2PC and use
the PC DOS COPY command to copy the file to the printer
(PRN). Use the MS DOS "binary switch" option, or your
printer control codes won't make it thru the copy process.
Here's another reason to use the "binary switch" option,
discovered recently.  A guy was using this method and it
worked fine except that the process would stop short
before the data was completely transferred to the printer.
When MSDOS is copying files and isn't in the binary mode
(/B switch), it looks for the 1A hex character as an end
of file marker.  If a 1A byte is in your printer data, the
transfer will stop at that point unless you use the binary
switch.



Lock Data Line

Rev. 2.3 added a switch (function "K") to allow locking
the data out line into the enabled state. This is for a
user or two who had a specific problem which occurred when
the data line went to the inactive state automatically.
You should leave this switch in the Auto state. Otherwise,
when you try to address non-SIO2PC devices, interference
will result. However, if you note that when you address an
SIO2PC drive and experience hesitation, sputtering, etc.,
try locking the data line on and see if it helps. (I now
believe the TIMINGS MENU modification is the real cure for
this type problem.)

Copy protection problems

Some people have told me that some copy protected programs
which have been "broken" will run from a real drive but
not from SIO2PC. Recently, one guy told me of a solution:
He uses the TIMINGS menu of SIO2PC to slow down SIO2PC's
I/O rate so it looks like a real drive. Appapently, some
protected programs time the "sector get" and "sector put"
processes to make sure they aren't running out of a ram
drive (indicating that the protection has been broken).
Since SIO2PC is a small program, one could have customized
versions which are slowed down just for use on these
problem programs. (Elsewhere in this DOC is info on how to
permanently alter SIO2PC's timings.)

Interference from real drive

In my operating instructions, I tell you to turn off your
real drive #1 and then boot from the SIO2PC disk #1. I
haven't heard any complaints about this, but I recently
borrowed a 1050 drive, which, when I turned it off,
interfered with the serial bus and I couldn't read the
SIO2PC drive. The solution was to turn the front lever on
the 1050 to the EJECT position but leave the 1050 on.
Apparently this told the 1050 not to answer the call,
which then went through to SIO2PC OK.

Extract Directory Note

Note that the Extract Atari Directory function can't work
on disk images currently in use as "file access" disks on
the system.  This is because SIO2PC already has these
files open for read/write and can't open them again to
extract the directory.

Status Line Note

You may notice that under certain conditions your status
line is not being updated.  This occurs when you have
PRINT_THRU enabled with the screen selected as the output
device.  To keep the status field characters from messing
up your screen print, the status line update is inhibited
until you turn off PRINT_THRU.

USER'S QUESTIONS

1) Does the program reformat my PC's hard disk?

No! Your Atari disk images are stored on your PC as
ordinary PC files.

2) Could I use the hardware part of the SIO2PC system as a
general purpose RS-232 interface? Like, to connect my
Atari to a modem?

Hmmm... This is a good question, and the answer is sort
of, "yes and no."  Electrically, yes you have a true RS-
232 connection coming out of the interface. However, note
the following:

RS-232 includes several handshaking lines in both
directions. But, most communications setups only use a
few, and optionally can be told by software to disregard
those they do have. I've seen computer to computer PC data
links that had just Data in, Data out, and ground (via
RS232 serial port). My system has one handshaking line
from the Atari to the PC, the COMMAND line which goes to
RI on the PC. You can often "dummy up" inputs to fool one
end of a link into thinking the other end is saying,
"ready." A null modem cable is usually made up this way.

Bit rate (BAUD) and software on the Atari end: On the
Atari, the SIO subsystem of the OS always works at a fixed
rate: 19.2 Kilo- baud, except for the cassette: 300 baud.
Also, it uses a strict protocol to send data: command
frame, acknowledge, data frame, acknowledge, complete. But
if you want to write your own software (or you have some
already written), you can directly program the Atari's
POKEY chip (UART) to any baud you want, and you can
directly put data into its transmitter for sending, and
can directly read incoming data from the receiver. (My
notes under ATARICOM.DOC talk about how I did this once.)
When you do this, you are completely bypassing SIO and
running the whole show yourself. You can also control the
handshaking lines yourself. To get into something this
serious, you need the Atari Technical User's Notes. It's
fun to learn, but takes some time.

Actually, since writing the above response, I HAVE written
a specialized terminal program for my Atari using SIO (no
850 interface) configured for 9600 baud and connected to a
Packet Radio terminal controller which uses the RS-232
standard.

3) How come SIO2PC is a dead end - no extra port for
adding another device?

I'm finding out this bothers some people. I figured, you
could alway make this the last device in your chain. But I
guess other manufacturers figured the same. It would be
vastly more complicated for  me to build a box with a
receptacle or two for SIO in it. They generally come as PC
board mounted connectors, not as "in line" types like the
plug I do use. So my board would be much bigger, I would
be hand cutting rectangular cutouts in the box, etc.
However, someone had a suggestion, if you are building
your own: He said the "newer" cassette recorder (the
1010?) had two SIO2PC jacks in it. You could get a surplus
1010 junker for a few bucks, gut it except for the
connectors, and build your SIO2PC in this box.
Alternately, you could just buy a couple of the jacks from
your friendly Atari parts supplier and design them onto
your board.

Here's another idea:  build the interface into your Atari.
Mount a DB-9 in the Atari's case. (I've done this.)  Then,
your SIO port would still be free, and you just use a
standard serial cable to connect your Atari to any PC.


4)  Will SIO2PC run on an Atari ST running PC ditto?

From what I've heard so far, no. SIO2PC does a lot of
direct to the chip I/O, bypassing both MS-DOS and the PC's
built in BIOS routines. I suspect that PC ditto doesn't
emulate the PC down to this level. However, if there are
any ST experts out there who want to work with me on it, I
think we could modify the program to make it work. I
configure the serial chip (UART) directly because the PC
BIOS doesn't have 19.2 kilobaud as an option, although the
chip will do it. I input and output data from/to the UART
directly for speed. I have also reprogramed the PC's timer
chip and have a timer driven interrupt running. I think
all this could be worked out if we had the right info. How
about it, ST users?

5) Will you give out your source code for SIO2PC?

I don't routinely give it out. But if you would like to
have the source code just to see how it's done, or to make
some modifications, or even to "borrow" the basic I/O
routines for use in your own non-commercial programs -
write and let me know. SIO2PC is written entirely in
assembly language for the MICROSOFT QUICK ASSEMBLER.  I
also have a version which will assemble under A86, the
excellent shareware assembler.

6) How about a default path?

One person asked to be able to have a default path so he
wouldn't have to tell SIO2PC where to find his disk
images.  I usually run SIO2PC out of the directory where
my files are stored, so I don't need to specify a path.
However, I just recently realized that DOS has a command
built (SUBST) in which allows you to specify a virtual
"drive" letter for any path.  For instance, from the DOS
prompt, type SUBST E: C:\ATARI\DISKS.  After this, you can
substitute drive E: for the full pathname, even from
within SIO2PC.  A pretty convenient feature.

7) Direct access to hard disks / HUGE Atari disk images.

I am getting a lot of requests from people wanting to have
HUGE Atari disk images and direct access to the PC's
disks.  I'm opposed to using direct sector writes on PC
disks. The possibility of inadvertent destruction of PC
files is too great and I'm afraid of the risk.  However,
I'm thinking of having random sized disk images stored as
PC files which would not be moved into PC ram.  I would
have to use MS DOS's file pointing features to read in the
correct "sector" directly from the file.  The DOS overhead
would slow things down a bit, but I have an idea that it
wouldn't be too bad. **** DONE ***

WHO'S NICK KENNEDY?

I'm an electrical engineer, but I don't work with
computers professionally. That part is a hobby. I got the
Atari 800 in 1982, mostly so I could play Asteriods.

Data communications interests me. I have written a Morse
code program to interface the Atari with my Ham Radio
station. Later, as a sort of evolutionary forerunner to
SIO2PC, I wrote programs linking my two Atari 800's
together, first via their serial (SIO) ports, and later
via their joystick ports. The Atari equipped with a disk
drive would send files to the one without.

I thoroughly enjoy programming in assembly language, and
may attempt "C", if threatened at gunpoint.

To me, the hardest part of programming is finding a worthy
cause. There are so many programs out there, commercial,
free, and shareware - all good, that it's hard to find a
niche that hasn't been filled. I think SIO2PC fits the
bill.

As I've said before, I'm very interested in your comments,
suggestions, questions, praise and condemnations. So, if
you built it yourself and have a comment, let me hear from
you, even if you weren't moved enough to pay a shareware
fee. I won't harangue you about it.

Nick Kennedy


OTHER PROGRAMS

I thought I'd tell about other programs I've written, on
the off chance someone may find one of them useful.
Everything I've done involves interfacing a computer to
another computer or to other external devices.  All of my
programs address some oddball specific need I had at one
time or other.  These programs fulfill a function, but
some of them lack polish:

PINEWOOD.EXE - Written to time external events (in my
case, pinewood derby cars) to millisecond accuracy.  You
hook a START switch to one serial input line and STOP
switches to two others. (Only one serial port is
required.)  I used phototransistors for the stop switches.
The program starts timing when the START switch changes
state, gives the time that each car (event) activates its
STOP switch, and proclaims the winner!

TIMER.COM - A variation on the above.  This timer just
monitors one line.  It starts timing when the line changes
state and stops when it returns to its resting state.  I
used it to time a "one shot" device (a 555) to make sure
it was giving exactly the 50 milliseconds I needed.  This
program would probably be called an interval timer.

PACKET.OBJ - A packet radio controller for the Atari 800.
This version is specifically set up to send control
strings to an MFJ-1278 controller.  Note: this is a ham
radio thing.  Essentially, this is a terminal program
similar to what one uses with a modem.  It doesn't have
advanced features such as file capture, etc.

EPROM.COM - Interested in burning your own EPROMs?  Make
your own Atari cartridges?  I built Steve Ciarcia's Serial
EPROM Programmer from the Circuit Cellar, volume VI book.
The companion BASIC controller program left much to be
desired, so I wrote a faster and more flexible one in
assembler.

FREQ.COM & SYNTH.OBJ - Another ham/experimenter thing.
This program - which I have written for the PC, the Atari
800, and for a 6502 single board computer - is a
controller for a Direct Digital Frequency Synthesizer.
The synthesizer works from 0 to about 7 MHz, and has 1
hertz resolution.  The controller gives the many fancy
features of modern ham transceivers:  split
transmit/receive frequencies, memories, memory scan, band
scan, etc.

In the "EXTRAS" directory of the distribution disk, I've
already told you about my programs linking two Atari's,
and about my ham program KEYER.OBJ - the morse code keyer
program which took almost as much programming time as
SIO2PC.

If any of these things meets a need, let me know.
  NOTE: SAVE THIS FILE AS PLAIN TEXT /W LINE BREAKS ... *.TXT, WITH MARGIN
AT 4 7/8.