From ec99d1d6deea9c65fbcebdd5e0958dd9c27754bf Mon Sep 17 00:00:00 2001 From: Natalia Portillo Date: Wed, 25 Mar 2015 02:20:01 +0000 Subject: [PATCH] Added information about Atari disk images --- docs/SIO2PC.txt | 2285 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2285 insertions(+) create mode 100644 docs/SIO2PC.txt diff --git a/docs/SIO2PC.txt b/docs/SIO2PC.txt new file mode 100644 index 00000000..126858c2 --- /dev/null +++ b/docs/SIO2PC.txt @@ -0,0 +1,2285 @@ +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: +. Now, type DEBUG SIO2PC.COM . Give the +"GO" (run) command by typing G . 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 and the +program will be written back to the disk file. Quit DEBUG with Q +. 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.