INTRODUCTION	4
FEATURES:	4
HARDWARE REQUIREMENTS:	6
HISTORY:	6
SHAREWARE INFO:	6
READ ALL ABOUT IT:	7
TECHNICAL INFORMATION ON SIO2PC	7
REMOTE CONTROL PROGRAM:	9
FILE2PC PROGRAM:	9
STRUCTURE OF AN SIO2PC ATARI DISK IMAGE:	10
USING RAMDISKS:	10
TIMING INFORMATION:	11
DOUBLE DENSITY:	13
FORMATS VS DISK SIZES:	13
FILE ACCESS: HOW IT WORKS & TIPS ON EFFICIENCY	16
MORE DISK CONFIGURABILITY:	17
SIMULATED DISKS:	19
PRINT-THRU:	20
UNINSTALL DISK:	22
STATUS LINE INFO:	22
PC MEMORY USAGE:	23
DOS SHELL FEATURE:	23
VIRUS DETECTION:	25
REMOTE CONTROL PROGRAM USAGE	26
MAKADISK.EXE	27
FILE2PC USAGE INFORMATION	28
COPY PROTECTED DISK SUPPORT	28
DIAGNOSTICS FEATURES	33
FUTURE PLANS, CURRENT PRICING	34
REVISION LOG:	36
PROBLEM DIAGNOSIS QUESTIONS	48
POSSIBLE PROBLEMS AND SOLUTIONS	49
USER'S QUESTIONS	53
WHO'S NICK KENNEDY?	56
OTHER PROGRAMS	58


SIO2PC: An Atari to PC  Interface System 
	
by Nick Kennedy

 
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, 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

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 concise 
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.

1050-2-PC Feature allows connecting PC directly to 
Atari drives and copying or writing data.  
(Separate interface hardware required)



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 
an integrated circuit and a few capacitors and other 
components 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 about 10 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 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. Upgrades are free. Your 
suggestions will be considered for future revisions. I 
will try to answer 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. 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.TXT file.

	A NOTE ON A RELATED SOFTWARE DEVELOPMENT

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 very impressive.  It emulates a 
6502 processer and the Antic video microprocessor 
perfectly and includes the actual Atari OS and BASIC 
code. 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 XF3 
(Xformer) 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). 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)
BYTE = disk flags such as copy protection and write 
protect; see copy protection chapter.
WORD=1st (or typical) bad sector; see copy protection 
chapter.
SPARES 5 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.  
(Actually, with modern PC's, there isn't any speed 
advantage of a ramdisk over file access.  The speed of 
the SIO bus is the limiting factor)

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 420 nano-
seconds which is almost 1 micro-second. (Multiply 
units by .42 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.
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:

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.

NOTE:  Per Bo and Ernest Schruers, if you have a fast 
Pentium and are having timing problems, try making T4 
and T5 equal 0010.

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 130K 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 & SOUND:

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:

HDL: File handle #: for debugging - making sure 
files get closed.

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.

Rev. 4.16 added some sounds to help you detect what's 
going on, similar to the way an Atari 800 gives aural 
feedback when reading & writing sectors.  Clicks of 
slightly different sound character indicate reading or 
writing a sector successfully.  Also, in the 1050-2-PC 
function, a beep tone indicates that an error 
occurred.  Since unwanted sounds can be irritating, 
you can use the Z (not on the menu but it works) 
command to turn sounds off and on.

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:.

COPY PROTECTED DISK SUPPORT

Revision 4.05 introduces copy protection support for 
SIO2PC.  As I've said before, SIO2PC isn't intended to 
be a copy protection cracker.  However, the people who 
are still using Atari software want to be able to run 
it from modern hardware_including SIO2PC and XFORMER 
for instance.

There's no way I can address all copy protection 
schemes used on the Atari, and I won't venture a guess 
on what percentage of copy protected programs will run 
from SIO2PC under my current scheme. I'm not an expert 
on copy protection, but I'll attempt a simple 
overview:  Copy protection relies on the fact that 
Atari disk drives contain a microprocessor with drive 
"intelligence" on board.  So the computer just sends 
the drives very simple commands, such as format, read 
sector, get status, and write sector.  There's no way 
to get a standard drive to accept any other commands 
such as - create bad sector, omit sector # from 
formatting, or format sector #n with special 
formatting.  Now the Atari drive will report back that 
it has encountered bad sectors and it will give some 
detailed information about what's wrong.  It will also 
tell about "good" sectors formatted by some non-
standard means. The software producer would format his 
disks on a drive specially equipped to produce bad 
and/or non-standard sectors.  The software would be 
programmed to ask to read those sectors.  If it got 
back a "normal" sector status, it would assume it was 
on a copied disk and terminate.  If it got back the 
expected bad sector status, it would run.

SIO2PC now includes the ability to emulate bad sectors 
by using a special code to flag them, and also by 
embedding the expected bad (and good) sector status in 
the sector data.  I wanted to make transferring your 
copy protected disks to SIO2PC images a pushbutton 
simple process, and it might be if you have the 1050-
2-PC hardware which allows the PC to talk directly to 
an Atari drive.  It can also be done without the 
special hardware if you don't mind a little hacking 
with other tools.

The format of a "bad sector" on the SIO2PC disk image 
is as follows:

1st 4 bytes (bytes 0 - 3): C2 1C 3D 1E (hex):  Special 
32 bit identifier

Bytes 4 - 7:  nn nn nn nn ; where the nn's are the 
status bytes to be sent to the Atari in response to a 
"get status" request following a read attempt of this 
bad sector.  Note that they are in reverse order - 
sent last first.

Bytes 8, 9, 10:  Contain up to three characters, which 
would be A, C, G for a good sector.  In the SIO 
protocol, devices are supposed to respond to the 
Atari's commands with single character information 
such as A for acknowledge (ACK) and C for complete 
(CPT) if the command is recognized and completes error 
free.  If it's not OK, the device may send an N (NAK 
or Not-Acknowledge) instead of an A and/or an E 
(Error) instead C.  The G means the checksum calc was 
good (B for bad).  This isn't used in my current 
scheme.  Typically a NAK wouldn't be followed by any 
more responses, so these characters would be N__, with 
two underscores being placeholders for letters which 
are N/A.  Another possible character for the A and C 
is T.  This means time out.  Here, the device is 
expected to not respond at all and the computer will 
eventually time out and abort the attempt.  So, when 
SIO2PC gets a response from the Atari for this bad 
sector, it looks at the three (actually two) 
characters to decide how (or if) to respond.  It never 
sends any sector data, but might send a NAK or ERROR 
code.  Then, if the Atari sends a request for STATUS 
after the attempted read of the bad sector, SIO2PC 
responds by sending the 4 bytes stored in sector data 
bytes 4 - 7.  In a nutshell, this is how it works.

Byte 11 contains is the amount of time, in jiffy's 
(18.2 jiffy's = one second) SIO2PC is to delay after 
responding to a good sector read or write.  The intent 
is to emulate time factors seen in real drives in case 
the copy protection looks at this.  NOTE:  Rev. 4.05 
is currently not using this info.

Byte 12 contains the amount of time (jiffy's) to delay 
after a bad sector read attempt.  (Probably longer 
than the good sector read attempt.)  Also not yet 
used.

Bytes 13 - 16 contain nn nn nn nn, where the nn's are 
the GOOD sector status to be returned.  As I said, I 
think it's also possible to format disks which have 
good sectors, but the sectors return a status which 
isn't like that returned by the standard Atari disk 
drive formatted disk.  Each bad sector contains 
exactly the same data in these bytes.  Different bad 
sectors might return different statuses, but all good 
sectors are expected to be the same.

Recall that an SIO2PC disk image has a 16 byte header.  
There are a few bytes now used to tell SIO2PC about 
the good/bad status of the disk.  The 9th byte of the 
header contains information in individual bits.  Bit 4 
= 1 means the disk image is treated as copy protected 
(has bad sectors).  Bit 5 = 1 means the disk is write 
protected.  The 10th and 11th bytes of the header are 
a word which contains the number of the first (or of a 
typical) bad sector.  What I mean by typical is that 
it does contain both bad sector status and good sector 
status.

OK, how can you, the user, set up a disk image 
containing bad sector data?  First, lets talk about 
doing it without the 1050-2-PC hardware.  You need 
some method of scanning your disk to find the bad 
sectors, and hopefully their status.  There are 
utilities in the public domain, debuggers, and 
commercial programs like Scanalyzer which ought to 
help.  You would need to create and format a disk 
image on the PC with SIO2PC, then use some kind of 
sector copy utility which could copy the disk but 
ignore the bad sectors.  Save the disk image.  Now you 
need to embed the bad sector information.  Some type 
of debugger which lets you update individual bytes of 
a file in hex is needed.  Hexcaliber or D86 or 
Norton's utilities ought to work.  I'll talk about 
using DEBUG, though, since everyone has it as part of 
DOS.  Start DEBUG with the command DEBUG MYFILE.ATR, 
to load your file.  The prompt is a minus sign.  Enter 
the D (display) command and you see the first 256 
bytes of the disk image, loaded in at offset 0100h.  
The first line is all header information.  The next 
line, at offset 0110h is sector #1.  Now, how to get 
to your desired sector...  You need a calculator or 
program that can do hex math. There are 80h bytes in a 
single density sector.  So take your sector number 
minus one times 080h and add that to 110h for the 
address of the sector data.  Example:  I want the 
address of sector 100, which is 64h.  So 63h * 80h = 
3180h; add 110h = 3290h.  You could see what's there 
now with the command D 3290.  But most importantly, 
you can edit with the command E 3290.  The screen 
shows the current byte and a period.  Enter your 
desired two digit byte and press the space bar.  The 
screen now shows the next byte.  Start with C2 1C 3D 
1E, then your status bytes, then the 3 characters.  
You'll have to look up their byte equivalents in an 
ASCII table.  Continue. After you've entered all 
changes in the current series, press Enter.  After 
you've made ALL changes, give the W command and the 
edited file will be written back to the disk.  Be sure 
to make the word at the 10th byte of the header point 
to a bad sector.  If you have a LOT of bad sectors, 
you need some way to block copy them so you don't have 
to enter them all by hand.  That's really beyond the 
scope of this primer.  Note that in DEBUG, you can 
press ? and Enter for a menu of commands.

If you can't uncover the status of your bad (and good) 
sectors, here are a couple with bytes given in the 
order that they go in the disk image file:

00 E0 EF 00 - BAD SECTOR

00 E0 F7 10 - BAD SECTOR

00 E0 FF 10 - GOOD SECTOR

Now for copying a bad sectored disk using the 1050-2-
PC hardware.  The software is already part of SIO2PC.  
From the main menu, press A then D to get to the 1050-
2-PC sub-menu.  The first option is to copy a 720 
sector disk to an SIO2PC disk image.  You are then 
asked if you want to emulate copy protection.  Answer 
yes and things are supposed to be pretty well 
automatic, but there will be more prompts when bad 
sectors are found.  I'm going to just tell about some 
of my observations using the system.

I've found out that the Atari disk drives are a bit 
cantankerous and might not respond correctly (or at 
all) to the first command.  [Or maybe it's just my 
specific drive?  I don't know.] After they warm up 
(initialize), everything's OK.  Hence, the retries 
built into the logic.  Anyway, if it acts weird, you 
may want to cycle the power switch to reinitialize.  
Also, use the Scan Sectors command to see the status 
and ACG information and compare to what's in the disk 
image (with DEBUG) if you have problems.  Like I said, 
I've tried to make it automatic, but it's not totally 
foolproof.  

I've done two copy protected disks (the only two I've 
been able to find so far) and they work.  The first 
had bad sectors from #199 up thru 720.  The program 
reads in sectors smoothly until a bad sector is found.  
Then the drive growls several times as it tries to 
read the sector.  This growling drives me crazy, and I 
didn't want the drive to have to do it for each of 520 
bad sectors, so I designed in some bail out options.  
One lets you skip the rest of the track.  (A regular 
track has 18 sectors, a 1050 1.5 density disk has 26 
sectors/track.)  Another lets you skip the rest of the 
disk.  Whatever you skip, the same bad sector data 
will be written for the skipped sectors.  In this case 
I skipped the rest of the disk.  The program ran fine, 
so this was an example of a fairly simple copy 
protection scheme.

The next disk I tried had (known from previous 
examination) an entire track of bad sectors, starting 
with sector #19.  At first, I tried the option to skip 
the rest of the track.  The program wouldn't run.  
Several experiments later, I realized that the track 
had two kinds of bad sectors (they returned different 
status bytes), and also had one good sector in the 
track.  So I ran the copy disk function again and let 
it grind through all 18 sectors of the track.  Then 
things worked fine.

You may want to make some observations while booting 
your real copy protected disk.  Have SIO2PC in the 
chain so you can watch the sector numbers go by.  A 
boot always starts with sector 1, but then it can skip 
around.  Jot down the 1st and last sector number of 
each series that loads properly.  Jot down the sector 
numbers of bad sectors (evidenced by the process 
stopping and the drive growling).  Some programs may 
load completely, then look at bad sectors, others my 
look for bad ones in the middle of the process.  
Sectors never accessed could be safely skipped, but be 
careful because some programs might randomly check 
different bad sectors at different times.

Despite your best efforts, some things aren't going to 
run.  I've heard of some copy protection methods that 
I don't currently emulate.  There are bound to be 
others that I haven't heard of.  (One method is double 
tracks having the same sector numbers.  The same track 
exists twice.  Stepping from inside of the disk toward 
the outside will find one track; from the outside 
toward the inside would find the other.)

I should note that there's no way for XFORMER (XF3) to 
recognize SIO2PC's bad sector scheme.  I'm going to 
pass the information along to Darek Mihocka but I 
don't know if he'll be interested in using it in his 
system or not.

DIAGNOSTICS FEATURES

Revision 4.09 added hardware diagnostics functions to 
SIO2PC and a companion diagnostic program DIAGS.OBJ 
which runs on the Atari.  These programs allow testing 
individual hardware lines, performing simple serial 
I/O tests, and performing sector I/O tests in both 
directions.  Complete instructions and program 
descriptions are included in the file DIAGS.TXT.

FILE LIST BOX

Revision 4.11 added a scrolling file list box for 
selection of disk image and PC files to load.  This 
should make loading files a lot easier since you no 
longer have to remember the file name.  This section 
gives a little information about use of the file list 
box.  

The current drive, directory, and search spec are 
listed on the top line.

All files and directories matching the search spec are 
listed.  So *.* would list everything in the current 
directory, but *.ATR would list only files with the 
extension .ATR, and wouldn't likely find any 
directories.  Press Enter on a file and it is selected 
for loading.  Press Enter on a directory and it 
becomes the new current directory and a new file list 
is shown.  Note that ..\ means the directory one level 
higher.  So if you are in C:\ATARI\GAMES and you press 
..\, you will be in C:\ATARI.

[ CANCEL ] is self explanatory.  (Escape also works.)  
[ TYPE SPEC ] allows you to manually enter a new 
drive, path, search spec, or any combination of the 
three.  Note that B: would take you to the current 
directory of the B: drive, but B:\ would take you to 
the root directory of B:.  Use a backslash after a 
pathname to indicate that it is a directory and not a 
file name.  For instance, ATARI\ will take you to the 
ATARI directory, but just ATARI will search for a file 
named ATARI in the current directory.  Examples of the 
effect of typing a search spec:

A:			Go to drive A:, current directory
A:\			Go to drive A:, root directory
A:*.*			Go to A and change search spec to *.*
*.AT?			Change search spec to *.AT?, current 
drive/path
C:\ATARI\		Change to C drive and ATARI directory
C:\ATARI\GAMES.*	Change drive, directory, and search 
spec.


 
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.  
DONE

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.

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 5 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!!!
PRICE UPDATE FROM JULY 1995 - I have recently cut my 
prices from $55/$35 to $40/$30 postpaid.  So: $40 
wired; $30 kit; or $10 for shareware fee for do-it-
yourselfers.  If you send the shareware fee and 
haven't built it yet, request a better drawing from me 
at the same time.  


*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.

3.18 changed a timing routine to use better 
programming practice.  Unfortunately, it also 
introduced an error which caused halting operation 
while writing sectors.

3.19 fixed the bug introduced by 3.18.

4.0  Adding the 1050-2-PC functions to allow reading 
and writing from/to an Atari drive directly from the 
PC.  This requires a separate interface.  The new 
function is a sub-menu choice under the Alter Timings 
menu.

4.01  First release of the above.

4.02  Enhance the 1050-2-PC routines - retry logic for 
disk copy; user bailout by ESCAPE key.  Also worked on 
the SIM DISK routines some, but I'm not sure what I 
may have fixed (?)

4.03 Hmmm ... now what did 4.03 do?

4.04 User Ernest Schreurs pointed out that SIO2PC will 
accept a request to write to sector zero.  This causes 
the program to write to an incorrect ram area and 
crash.  Most programs and/or DOS's won't try to write 
to sector zero, because it's not a valid sector 
number.  But it has happened that a program with a bug 
tried to write to sector zero.  Anyway, now SIO2PC 
returns an error to any program trying to access 
sector zero.

4.05 - More enhancements to 1050-2-PC:

When copying a real disk to a disk image; if an error 
is encountered, the user now has the option of 
continuing.  Maybe he can get most of his important 
stuff if just a sector or two is bad.

Added the ability to format a real atari disk - option 
of standard or 1.5 density.

Added the capability to display sector data.  I 
patched in a neat looking HEX/ASCII screen dump 
routine from an EPROM burner program I had written.  
One use for this:  Look at sectors 361 - 368 of DOS 2 
compatible disks and you can see the directory of the 
disk.

Added the option of writing a disk image back to a 
real Atari disk.  Now you can use 1050-2-PC to copy 
Atari disks.  It starts with an option to format the 
new disk.  You can do all sectors or just selected 
ones.

Added the ability to emulate bad sectors in an effort 
to allow running some copy protected programs from 
SIO2PC.  This also included changes to the 1050-2-PC 
part of the program such that it would scan copy 
protected disks and put the bad sector information as 
required to the disk image.

4.06  I've recently been hearing disturbing reports of 
erratic operation from users who have the latest and 
fastest computers - Pentium 90's and 100's.  I think 
(I hope) the problem is a crude timing routine which 
is clock speed (and processor efficiency) dependent.  
I've eliminated that routine and replaced it with one 
which relies on one of the PC's internals, all of 
which time the same way independent of processor.

4.07 & 4.08 made some more changes similar to the 
above.  Also, the program now selects video mode 3 for 
color screens.  Previously, after ending SIO2PC, you 
might end up in a strange video mode - 43 lines or 
monochrome, in your next DOS program.

4.09 Added diagnostic routines to SIO2PC and a 
companion DIAGS.OBJ program for the Atari - for 
hardware troubleshooting.  See DIAGS.TXT for more 
info. I'm also getting rid of PUT_LOC calls which put 
a location character in the LOC field of the status 
line.  This feature has outlived its usefullness.

Rev 4.10:  Fixed two major bugs/technical problems!

I discovered that adding some time to T7 (time between 
UART accesses) completely cured the halting behavior I 
see on my '486.  I started with 000A (4.5 us) but went 
to 0005 and it worked too.  Settled
on 0008 as a permanent change to the program.  12/4/95

Also, fixed a bug where the MCR wasn't being 
initialized.  This isn't
usually a problem, but some computers apparently come 
up with LOOPBACK turned ON!!  This is the problem 
which made SIO2PC not work with "high performance" 
computers.  Apparently, newer computers have BIOS's or 
COM drivers which put serial ports into the loopback 
mode and leave them that way.

Changed TIMER_0 routine so it actually uses timer #2.  
This is because two nested timing routines were both 
using timer 0 and interfering with each other.  Caused 
lock-up when the command line was low continuously, 
which can happen when configured for two chip logic.

I changed the programming of the BAUD rate from a 16 
bit out to two
8 bit OUT's with delay between, because I'm not sure I 
trust that 16 bit OUT.

Added a "hidden" menu function M, which is temporary 
to allow setting the MCR's lower 4 bits.  I'll remove 
this later.  I also found that if you set bit 3 of 
MCR, you interfere with the function of the COM port 
separated by two.  (1 & 3, 2 & 4)  I saw it disable my 
mouse, even in Windows.  I had never seen anything 
before to say that a register on one port could affect 
another, but it does - at least on my hardware.

Rev. 4.11 - Killed one more technical problem.  A user 
told me that after a number of loads/unloads of disk 
images, no more could be loaded.  I discovered that in 
some cases files weren't being closed so all file 
handles would be used up.  This has been corrected.  
Also at this time, I started putting the file handle 
in the former LOC: field on the status line so I could 
keep an eye on my file handles and make sure files 
were getting closed.

The main change for 4.11 is the addition of the 
scrollable directory box.  It allows choosing files 
from a list so you don't have to remember them, and 
also navigating the tree by choosing directories 
and/or entering new drive ID's.  You are returned to 
the original directory when you finish.

Rev. 4.12 mainly incorporates a number of bug fixes.  
Some more time was added between IN's and OUT's 
(opcodes).  Fixed a problem with multiple disk loads 
from the command line (or batch file).  After DOS 
directory or DOS Shell, the file selector box didn't 
work - fixed that.  Some other problems with the file 
selector box - error in page down function was fixed 
and an error caused by a bad path specification 
couldn't be corrected - fixed that.  Also, an older 
error, the program would accept a request to create a 
disk zero which would lead to other problems - fixed 
that.  Thanks Bo and Ernest Schreurs and Charlie Allen 
for bug reports.

Rev. 4.13 fixed a couple more ID'd by the same three 
guys.  Another problem with the file selector box, if 
you're on the last entry in the list and press an 
invalid key - lockup!!  Fixed.  Also, the simulated 
disk feature wasn't reporting the file name to the 
Atari DOS when a directory was requested.  Fixed.  
Also for the file selector box, instead of needing to 
select the [TYPE SPEC] entry and hit Enter to do a 
manual search spec, you can now just hit the space 
bar.  I wanted a "fingers on the home row" way to do 
this. 5/15/96

Rev. 4.14 - In 1050-2-PC, fixed the "Press any Key" 
prompt so it doesn't occur if there are still 
characters in the command tail.  Also, fixed the drop-
down DIR box so extended characters are handled 
correctly.

 4.15 - Fixed formatting error in 1050-2-PC.  It 
didn't work; now it does.  Also added the Beep 
function and beeps now occur when errors are 
encountered in sector I/O.  9/96

4.16 - Added click sounds:  Low click for read sector 
and high click for write sector.  Also, command Z now 
turns sounds on and off.

4.17, 4.18, 4.19 - 10/5/98 ... Bo and Ernest reported 
that the file selector blows up when > 255 files exist 
in a directory.  Fixed that.. 
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 does the status line at the bottom of the program 
show?

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.

See DIAGS.TXT for information on how to use built in 
hardware troubleshooting software.




POSSIBLE PROBLEMS AND SOLUTIONS

Timings problems:

As computers have gotten faster and faster since the 
12 Mhz 286 I started SIO2PC on, some timing problems 
have cropped up.  I added the Timings menu, accesed by 
menu command D.  You can experiment with these 
settings, but I have heard a report from reliable 
sources that making T4 and T4 equal 0010 insetead of 
the default 0300 can help on fast computers.  I'm not 
changing the program at this time because it seems to 
work fine on most PCs.


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 140 K 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.  But here's 
an update on this problem which should fix it.  
Instead of just going to the "DOS Box" from Windows 
and then running SIO2PC from the command line, install 
an icon for SIO2PC and create a PIF (program 
information file) to tell Windows how to run SIO2PC.  
It's easy.  Windows comes with a PIF EDITOR icon.  Run 
it and tell it you want to create a new PIF called 
SIO2PC.PIF.   When you create a PIF, you just 
essentially fill in a bunch of blanks or check off 
boxes about the program.  What you want to do here is 
choose Full Screen and choose Exclusive for the 
Execution option.  You might also push the Advanced 
button and give a very high foreground priority number 
(I used 10000).  Of course, put SIO2PC.COM in as the 
filename, SIO2PC for the window title, and the 
appropriate DRIVE:\Directory in Start-Up Directory.  
Save the PIF.  Then select (click on) the program 
group you want SIO2PC in,  Select the Program 
Manager's FILE menu, choose New, Program Item, enter 
SIO2PC.PIF in the Command Line box and the appropriate 
directory in the Working Directory box.  This seems to 
make SIO2PC run OK out of Windows on my 486DX-2-50 and 
probably will work for any computer running Windows.


From what I've seen of Windows 95 so far, the above 
doesn't work, because you can't give a DOS application 
exclusive priority (except if you restart in the DOS 
mode).  I found that "pumping" an unused key during 
I/O would make the program work.  Not that I recommend 
this, it just illustrates that Windows 95 leaves 
SIO2PC idle (even though it's on the screen) and 
doesn't come back until it detects a keypress.

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.

MYDOS NOTE

I recently created a big MYDOS disk (1.5 MEG) to hold 
all my games.  After about 56 files were copied to it, 
I started getting an error 130 message which didn't 
make any sense.  I thought the problem was with 
SIO2PC, but found that it was related to the number of 
files, even though I was well under the 64 file limit.  
The solution was to delete one file which allowed me 
to create a subdirectory, which in turn could hold 
more files.



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 A86 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.  Note that as of 4.11's 
drop down file selector box, the last directory 
selected is persistent.

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.
