SIO2PC.txt

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.  Paul Hozak told
me that he had to set T7 equal to 0190H (normally 0008H) on his 133 MHz
Pentium with 16550 UART.

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 T5 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. Also, Paul Hozak told me that he had to set T7 
equal to 0190H (normally 0008H) on his 133 MHz Pentium with 16550 UART.



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.