INTRODUCTION 4 FEATURES: 4 HARDWARE REQUIREMENTS: 6 HISTORY: 6 SHAREWARE INFO: 6 READ ALL ABOUT IT: 7 TECHNICAL INFORMATION ON SIO2PC 8 REMOTE CONTROL PROGRAM: 9 FILE2PC PROGRAM: 9 STRUCTURE OF AN SIO2PC ATARI DISK IMAGE: 10 USING RAMDISKS: 10 TIMING INFORMATION: 10 DOUBLE DENSITY: 12 FORMATS VS DISK SIZES: 13 FILE ACCESS: HOW IT WORKS & TIPS ON EFFICIENCY 15 MORE DISK CONFIGURABILITY: 16 SIMULATED DISKS: 18 PRINT-THRU: 19 UNINSTALL DISK: 21 STATUS LINE INFO: 21 PC MEMORY USAGE: 22 DOS SHELL FEATURE: 22 VIRUS DETECTION: 23 REMOTE CONTROL PROGRAM USAGE 24 MAKADISK.EXE 25 FILE2PC USAGE INFORMATION 26 COPY PROTECTED DISK SUPPORT 26 DIAGNOSTICS FEATURES 31 FUTURE PLANS, CURRENT PRICING 31 REVISION LOG: 33 PROBLEM DIAGNOSIS QUESTIONS 43 POSSIBLE PROBLEMS AND SOLUTIONS 44 USER'S QUESTIONS 47 WHO'S NICK KENNEDY? 50 OTHER PROGRAMS 51 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 detailed information on running the system and describes its features. SIO2PC is a hardware interface and software utility package to allow storage of your Atari files on your PC's hard and floppy disks, file conversions in both directions, and Atari printer output redirection to your PC's printer, screen, or file. FEATURES: Create 1 to 4 virtual Atari disks on your PC. Virtual disks can be ramdisks or physical file access disks; disk images can be up to 65525 sectors in size. Save Ramdisks to PC hard or floppy disks. Boot from the PC. Real drive not needed to start-up. Create Single or Double density ram-drives. No special Atari software patches. Use your favorite DOS. Almost twice as fast as an Atari 810 drive. Co-exists in the Atari daisy chain with "real" drives. Software written in assembler: Compact and Fast. Compatible all the way down to the hardware level - CIO, SIO, even direct hardware calls to drives will work. Print-Thru mode sends your Atari's printer bound output to your PC's Printer, Screen, or file. File Conversion: Convert and transmit PC files to Atari, or Atari files to PC files. Won't endanger your PC's hard disk. Your Atari disk images are stored as ordinary PC files. No direct sector writes used. Status line shows you exactly what your Atari is telling your disk drives: drive number, command, and sector number. 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 two IC's and a few capacitors and can be built on a 2" X 3" prototype board. If you are handy with a soldering iron, read the BUILD_IT.DOC file on your disk. It gives complete instructions, including addresses of parts suppliers. If you wish, I'll build one for you, or provide you a kit of all parts with drawings and detailed instructions. See BUILD_IT.DOC. HISTORY: SIO2PC has been over 7 years in the making. Before I got my PC, I considered my alternatives for my trusty Atari 800. Should I invest in an adapter and hard disk for the Atari? I realized that the huge PC market made an entire PC with hard drive almost as cheap as adding a drive to my Atari. So why not do both? The PC could store my Atari programs (get rid of that huge pile of floppies), and I'd have a new computer to boot! The project has worked out better than I could have imagined. The PC is a great computer - in some areas. In areas where it is weak, the Atari still shines. Curing the Atari's mass storage weakness makes it even better. SHAREWARE INFO: As you no doubt know, Shareware is a system which allows you to receive freely distributed software, and pay for it if you find it useful. If you build the interface and find that the system is useful, I request the modest sum of $10 for the design and software. If you choose to buy the kit or assembled interface from me, no additional payment for the software is expected. Either way, registered users may upgrade to the latest revision by sending a disk sized SASE and $5.00. Your suggestions will be considered for future revisions. So far, I have always been able to personally respond to questions and problem reports. READ ALL ABOUT IT: Don't you hate to write off for a shareware program that looks good in the ad, only to find an endless README file describing the limitless complexities of the package? Now that I'm on the creating end of that particular method of information overload, I can see how documentation files just grow... But - SIO2PC is a simple menu driven program which can, I believe, be mastered without instructions. So, skim through the rest of this file and the other .DOC files for tidbits, and return only if you have problems or specific questions after you get your system going. Of course, if you decide to build it yourself, you will want to read BUILD_IT.DOC carefully. Also, go ahead and run SIO2PC.COM and play with the menu options a bit, even without the interface. It won't hurt anything. Note: This DOC file gives some problem resolution information, technical information, and more information on file transfer features. For a more concise user's guide to the program, see the SIOINSTR.DOC file. A NOTE ON A RELATED HARDWARE DEVELOPMENT Recently, an SIO2PC user told me he was developing a hardware project which would allow him to type on the PC and have the keystrokes transmitted to the Atari via a PC parallel port and custom Atari interface. The system also comminicated joystick positions, START, SELECT, OPTION, and SYSTEM RESET button status to the Atari - AND allowed turning the Atari on and off remotely, and turning the Atari's cartridge on and off. His idea was to tuck the Atari away, into a desk drawer or something, and do everything from the PC's keyboard. He asked me to write to software for this project and integrate it into SIO2PC, which I have done. The hardware is more complicated than an SIO2PC, having 8 or 10 chips and requiring internal installation in the Atari. If this sounds interesting to you, I'd be glad to send you the schematic and a version of SIO2PC which includes the control functions for this modification. If you'd like to contact the designer of the interface, he is Carl Mangaroni, 15764 Midwood Drive Suite 5, Granada Hills CA 91344 phone 818-363-1037. And another: A programmer named Darek Mihocka recently (7/94) released a freeware version of an Atari 800 emulator which runs on the PC. The faithfulness with which it emulates the Atari is unbelievable. It emulates a 6502 processer and the Antic video microprocessor perfectly and includes the actual Atari OS and BASIC code. It doesn’t yet have sound, but he will add that and other features in a future version for a modest price. I mention this partly because every serious Atari 8 bit fan with a PC must have it and partly because it will read SIO2PC format disk images. So by having SIO2PC, you have the capability to transfer your files to the PC for access by Darek’s XF2 emulator. Note: current version has sound and additional features. TECHNICAL INFORMATION ON SIO2PC SIO2PC is 100% written in PC assembly language. REMOTE.OBJ and FILE2PC.OBJ are written in 6502 assembly language. MAKADISK.EXE is written in 'C'. SIO2PC recognizes the basic SIO bus commands: READ SECTOR, WRITE SECTOR, PUT SECTOR, STATUS, FORMAT, FORMAT 1050 1.5 DENSITY. Because it works at this elementary level, it should work with any DOS and with non-DOS disk loader programs. You can also make boot disks (without DOS) and boot them from the PC. SIO2PC uses only MS-DOS calls to do file I/O on the PC. Because there are no direct sector writes, etc., SIO2PC won't trash your PC disks. Just use the right path/filename when doing writes. SIO2PC uses file handles, so I assume it will require MSDOS or PCDOS 2.0 or later. SIO2PC redirects the timer 0 interrupt for it's timing purposes. This is the timer which supplies the BIOS its "timer tick", 18 times per second, 55 milliseconds per tick. SIO2PC also directly reads the timer as it is counting down in a routine for more fine timing (the microsecond level). If your PC doesn't use the standard timer chip (or compatible) with standard port addresses, there could be problems. Note: Most PC Clones are HIGHLY hardware compatible. SIO2PC gets the port address for the specified COM port from bios data area words at 040:0000, 040:0002, 040:0004, 040:0006 for COM 1,2,3, and 4. I've found out that the POST routine typically doesn't set up the addresses for ports 3 & 4. Therefore, version 1.01 will use default port addresses 03F8, 02F8, 03E8, 02E8 for COM 1 - 4 if it finds a zero in the BIOS data area word. If you know your port addresses to be other than this, a third option is now available. Use your computer's documentation to find the base address, and use SIO2PC's "E" command to enter the addresses directly. REMOTE CONTROL PROGRAM: The Atari serial bus reserves device ID's 31 - 38 hex for disk drives 1 thru 8. I have used ID #39h for the remote control function. When the SIO2PC program finds this ID # in a command frame, along with a Write Sector command, it expects to receive one sector (128 bytes) containing a command string. It then acts on the string as if it were a command tail from the DOS command line. Any error, or the Atari EOL character, will terminate command processing and flush the line of any further commands. It is best to end the string with a space as a delimiter, especially if your command ends in a pathname, else your PC may pause waiting for input or an ENTER keystroke. A REV 2.1 change added this function to the REMOTE process: When DEVID = 039h and DCOMND = 'R', the SIO2PC sends a 128 byte data frame to the Atari containing the DISK status information string shown on the screen. The string sent depends on the contents of DAUX1 which must contain 1 - 8 for disks 1 - 8. This function allows REMOTE.OBJ on the Atari to update the user as to the status of the ramdisks, before and after the execution of the remote function. In this way, the user can see if his remote command went to error free completion. In some cases, the PC may be busy carrying out the command when the data request is received. For example a command to write a ramdisk out to a floppy disk may take 10 seconds or so. Therefore, REMOTE.OBJ tries 3 times, pausing 4.25 seconds between retries, before giving up on getting the information. FILE2PC PROGRAM: The FILE2PC program also uses its own bus ID as a trigger for the FILE2PC program. ID# 03Ah puts the program into File Transfer mode. The Atari (running FILE2PC) always asks for Status of device 03Ah before putting a sector. (Only Status and Write are recognized by device 03Ah.) If the first status byte (of 4) is normal (010h), then the PC is ok for the transfer mode. If it is 0FFh, then the Atari will abort because the PC has encountered an error. The process works like this: The Atari gets Status, then, if OK, it sends a sector to the PC. The PC assumes that this sector contains the pathname of the destination file, terminated in an ATASCII EOL. The Atari pauses 4 seconds while the PC attempts to create the file. (Note, any existing file of the specified pathname will be overwritten.) After the Atari gets another good status, it starts sending sectors of file information. The AUX bytes, which usually carry sector # information, communicate the following to the PC: AUX1 = 0: Full sector, 128 bytes AUX1 = 1: Last sector, AUX2 contains the byte count AUX1 = 2: Atari encountered an error, abort process. As I said, the Atari asks the PC for Status after every write. STRUCTURE OF AN SIO2PC ATARI DISK IMAGE: It's extremely simple. There is first a 16 byte header with the following information: WORD = special code* indicating this is an Atari disk file WORD = size of this disk image, in paragraphs (size/16) WORD = sector size. (128 or 256) bytes/sector WORD = high part of size, in paragraphs (added by REV 3.00) 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. TIMING INFORMATION: The Atari SIO2PC bus protocol specifies minimum and maximum times between Atari commands and disk drive's responses. The minimums give the Atari time to get ready to take the data from the bus if it has to do some other work in the interim. The maximums let the Atari decide that the peripheral isn't ever going to answer and it will give a "time out" error. I have found that the system is very flexible and forgiving. I have used wide variations and still had a workable system. But for one guy (you know who you are, Joe!) or maybe two, I've made this menu to allow you to experiment with different values. The system goes through this little dance of command - acknowledge - data - acknowledge - complete, etc with timings in between. In addition to these times inside the bus frame, I've made a couple more (normally zero) time delays available. First: On a serial bus, data is normally sent continuously, with no time (except start and stop bits) between bytes. Now you can experiment by adding some time here. (My system slowed down but still ran normally.) Second: Some publications say that some UART (serial) chips can't stand to be addressed as fast as some PC's are capable of addressing them. I already had a bit of time delay in there, but now you can add some more. The time delays work like this: Each unit is 850 nano-seconds which is almost 1 micro-second. (Multiply units by .85 to get micro-sec.) (Exception: the value for the printer delay is in 1/18ths of a second.) Also, you must enter the units as a 4 digit hex number. Don't panic, it's easy. Here are some conversions: DECIMAL HEX 0005 0005 0010 000A 0050 0032 0100 0064 0250 00FA 0500 01F4 0750 02EE 1000 03E8 2000 07D0 The timing menu gives default values you can use as a starting point. If you want to see the menu updated with your choices, an item is available from the menu (choose #8). One problem with the TIMINGS menu is that it can't be addressed from the command line tail, so if your system does need non- standard timings, you have to set them up manually, each time you run the program. Not any more, Joe! Here's a procedure to permanantly alter your program: This procedure uses DOS's little utility "DEBUG," because everyone has it. But you could use NORTON or similar if you want. I moved the timing values to the front of the program and put an ASCII string in front of it to make it easy to spot. Try this: Get into the directory containing SIO2PC.COM. On the DOS command line, type DEBUG SIO2PC.COM . Now you see a hyphen, which is the DEBUG prompt. Now, type D . A table of hex numbers appears. On the left is the corresponding SEGMENT:OFFSET address for the first entry of each line. On the right is the corresponding ASCII (text) representation of the hex bytes. You notice that my little flag, "TIME DELAY VALUES: T1-T8, 2 BYTES PER ENTRY:" takes you up to the line starting with offset :0130. That line contains the timing values and looks like this: ????:0130 ?? ?? ?? 64 00 B0 04 2C-01 etc. Here's the slightly tricky part: Each of those 2 digit hex numbers is a byte. But each timing value is a WORD (2 bytes). And the PC stores words as lower part first. So the values are: T1 = 0064, T2 = 04B0, T3 = 012C, etc. The good part is, you don't need to worry about all this junk, we're gonna fix it in a very easy way. If you have been following me and are now in DEBUG, get out of it by typing Q . Now, I recommend that you copy SIO2PC.COM onto a floppy because it's a little scary using DEBUG to write to one's hard disk. Ok, you've done that and you have the floppy in drive A:. Get into A: by typing A: . 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. DOUBLE DENSITY: The Atari expects the first 3 sectors on a disk to be single density. This is necessary if you are to be able to boot from the disk. SIO2PC uses this format for its double density mode. FORMATS vs DISK SIZES: I generally haven't restricted these things, but recommend the following: Use 143K size only for "enhanced" or "1.5" or "DOS 2.5" density. The 183K size was created for double density. A lot depends on your DOS. Some DOS's can figure out the actual size of a disk, others may assume a default. MYDOS is pretty smart. SPARTADOS probably is also. As of REV 3.00, SIO2PC responds to "get" and "set" configuration commands, and also allows you to select any size disk you want by specifying the number of sectors. As a result of changes made in REV 3.00 and beyond which allow HUGE disk images, I now have additional information to present on disk sizes: File Access and BIG disks The biggest change is the addition of file access to disk images. Since this type of access doesn't require setting up ramdisks, the disk image size isn't limited by available ram. You may choose the size of your disk images using new size choice #5. You specify the size in sectors. If you're interested in what this means in kilobytes, you can figure it from the fact that a sector is 128 bytes for single density disks and 256 bytes for double density. Remember the status line field that shows 'W' if you've written to a ramdisk but not saved it? (And 'N' if the file has been saved.) For direct file access type disks, this field will contain an 'F'. Note that you can force the system to use file access, even when there is enough ram for a ramdisk. You do this by following the filename by "/P" for physical file access. Don't put a space between the filename and the "/P". The "P" will appear on your status line. (The "/" won't.) Concerns about Speed I was concerned that the overhead of using DOS and having physical disk accesses might slow the system down. On my two PCs, this hasn't been a problem when using hard drives. I use disk caches on both systems and can't tell any difference between "ramdisk" and "file access" speed. With a floppy disk, my fears were justified. Access was slow enough that the Atari would time out and generate errors. But, when I installed a disk cache, floppy disk access worked fine too. Some disk caches don't support floppies. Smartdrive (supplied with DOS 5 and WINDOWS) doesn't. I used one called LIGHTING. It worked fine using conventional memory while Smartdrive continued to run using extended memory. Get/Set Configuration Even after I first made some BIG disks, MYDOS 4.5 still couldn't figure out that they were bigger than a standard 810 or 1050 disk. The standard Atari SIO protocol doesn't include a means for the drive to tell the Atari what it is capable of (except in a very limited way). I found that I had to implement the extended SIO commands for Get and Set Configuration so MYDOS would realize the actual size of the disk. MYDOS does some of this automatically (reads configuration on bootup). But I found that I had to explicitly do this in sequence so MYDOS would realize the disk size: Create the new (blank) disk image. Use the Set Configuration command, answering questions as follows: Configurable? Yes. High Capacity? Yes. Number of Sector? xxxx. Do this before formatting. Format the new disk image. Actually, SIO2PC doesn't do anything with the Set Configuration command other than acknowledge it. But it lets MYDOS know that the disk is capable of more sectors than a standard disk. The program WAS going to also warn you if you tried to set the wrong density. But it turns out that MYDOS always tries to set high density when you answer "Yes" to "High Capacity Drive?". This doesn't cause a problem though: single density still works OK. I'm describing MYDOS because it's what I use. YOUR Atari DOS may have its own quirks with regard to large drives. MYDOS can become confused when you use the SIO2PC Swap Disk I.D.s command. MYDOS associates a certain disk number with a certain configuration. You may have to uninstall and reconfigure the drive with MYDOS when you swap disks of different types. Formatting With regard to formatting, it can take a long time with a BIG disk image, especially on a floppy. SIO2PC sets a flag when you first create the disk, to tell itself that the disk image is already blank. So, when you format it, the program doesn't bother clearing the disk. This saves a lot of time. After you write to the disk, the flag is cleared. Then, formatting includes clearing the entire disk image file. This could cause the Atari to time out and not realize the format was successful. So you may want to avoid formatting "used" disk images. I can't think of a reason you'd want to. (CREATING a new disk image can take a while too, but the Atari isn't involved in this process, so it won't get impatient.) I may improve the program to speed up this process if it's a problem. But creating new BIG disks will probably be an infrequent operation for most of us. *** NOTE: In a "rev 3.00 and 1/2" modification, I have taken a big step toward curing the slow formatting problem. Instead of writing blank sectors one at a time, I now write zeroes in blocks of 4K at a time, dividing the number of DOS calls by 32. This only works if there is at least 4K of free ram. Otherwise, formatting will still work slowly, as described above. Note that you need to be a bit more careful when formatting file access disks. With ramdisks, you could always choose to not save the formatted disk image, so your original was safe. With file access, formatting actually clears your disk image file. Another addition with this revision is that you can now number your disks as 1 - 8 instead of 1 - 4. Incidentally, you may wonder why your old 92K and 143K disks are now 90K and 140K. This has to do with the difference between a kilobyte as 1000 bytes and a kilobyte as 1024 (2^10) bytes. Revision 3.00 divides the disk size in bytes by 1024 to establish the disk size. FILE ACCESS: How it works & tips on efficiency It's pretty simple. MS-DOS maintains a pointer into open files which can be set by the program. SIO2PC maintains a corresponding pointer to the next Atari sector. When SIO2PC receives a read or write sector request from the Atari, it calculates the file offset from the sector number. It compares this to its record of where the pointer is now. If they differ, it asks DOS to point to the new location. Then it asks DOS to read or write 128 (or 256) bytes and increments its internal sector pointer by one, since DOS's pointer will now be at the next 128 or 256 block of the file. As you can see, if the Atari asks for sectors sequentially the pointer automatically moves along in step and no separate requests to reposition the pointer are needed. This is a good reason to try to keep your disk images unfragmented. Actually, it's possible to have things DOUBLY fragmented: fragmented Atari disk images and fragmented PC disks. To avoid Atari fragmenting, you should first put files on the disk which you won't be deleting or changing: DOS, games, application programs. Last, put on any stuff that will change: data files, text files, etc. If you suspect your disk is fragmented it's easy to undo. Just do a file copy (*.*) from the fragmented disk image to a newly created and formatted blank disk image. MORE DISK CONFIGURABILITY: I've heard lots of reports about the inability to format certain disk image sizes. My adding the "get configuration" and "send configuration" functions in Rev 3.00 in some cases seemed to make matters worse. I'm now getting into an area where the specific DOS one uses makes a difference. So my treasured concept of "DOS independence" of SIO2PC is going out the window. The problem is this: How can the system tell the Atari exactly what size and type of disk it is emulating? The 12 byte configuration table exchanged via the GET/SEND CONFIGURATION commands would seem to be the answer. Unfortunately, both MYDOS and SPARTADOS admit to ignoring most of the information exchanged. The variables are: SINGLE/DOUBLE DENSITY: 128 or 256 bytes/sector SINGLE/DOUBLE SIDED DISK NUMBER OF TRACKS/SIDE: TYP: 35, 40, 77, 80 expected NUMBER OF SECTORS/TRACK: TYP: 18 or 26 expected The MYDOS doc indicates that it likes to consider the disk to be one huge track containing all the sectors. This seems to work pretty well for SIO2PC. SPARTADOS evidently expects to receive information which matches its expectations about certain combinations. The sizes under the choice 6/Other are intended to give SPARTADOS what it expects. (As standards, they are probably good for other DOSes too.) One thing I've recently learned (I think it's true, anyway) is that SPARTADOS considers 26 sectors/track to be "1050 enhanced density" in all cases except for 77 track drives which always have 26 sectors/track. The bottom line is this: Even though you can choose a disk image of any size with the new SIO2PC option #5, you may have to adhere to certain standard sizes when using SPARTADOS. I've added a lookup table to the program. If the disk size matches a certain standard, it reports a combination of standard values to the Atari. Otherwise, it uses the MYDOS technique of 1 track holding all sectors. Note that this routine puts a tilde ( ~ ) in the ERR field of the status line if it finds a standard size. Note that when you choose double density, the basic 1, 2, 3, & 4 choices won't be seen as a standard size, but the equivalent chosen from sub option 6/More WILL, for technical reasons too boring to go into here. As I've said, this usually doesn't matter, because most DOSses don't use the GET/SEND configuration capabilities anyway. You could compute some standard sizes like this: Number of Sectors = (#TRACKS * #SIDES * # SECTORS/TRACK) Size in Bytes = (Number of Sectors) * (#Bytes/Sector) (For the Size in Bytes, subtract 384 for double density, because the first 3 sectors are always 128 bytes.) All YOU have to pay attention to is the density and the number of sectors. SIO2PC will report the other numbers to the Atari. For MYDOS, just randomly picking a number of sectors, without regard to standard sizes, seems to work fine. As I said before, the addition of the GET and SEND CONFIGURATION info commands in some cases did more harm than good. For this reason, I've added yet another feature. Now you can turn on or off the configuration transfer function. Since the main menu was getting full, I added this to the TIMINGS menu. Just hit 'A' to see the timings menu. Then hit 'C'. The status of the installed disks will be shown. 'Y' means they DO respond to configuration commands. Enter the disk's number to toggle its status with regard to this function. I believe this should only be necessary when getting ready to format, if at all. I realize this discussion of REV 3.01 isn't exactly simple. I hope you can glean the necessary info from it. It should be worth the effort to get ULTRA SPEED going and to cure formatting problems. Call or write if you have problems, bugs, or suggestions. I'd especially like any SPARTADOS experts to tell me how it tells me to go back to high speed. What is the '@' command SPARTA sends to device $4F? Also any info on how to get SPARTADOS to accept ANY size disk image would be useful. Rev. 3.05: I added many more choices to the standard disk sizes for the "create disk" option (option #6). The new choices are those which correspond the selections in the SPARTADOS format menu. This is to make your choices easier when using SPARTADOS. Internally, things still work the same. Again, with MYDOS, you shouldn't need to worry about certain prescribed sizes. Rev. 3.17 refined and corrected much of this. SIMULATED DISKS: The main event for 3.05 is the addition of what I call "simulated" disks. This allows you to install any PC file as an Atari disk, without the necessity of converting it to an Atari disk image.. This is more or less intended to replace the much despised MAKADISK.EXE. The features, theory of operation, and limitations are described below: The simulated disk is always single density (no size limit) and DOS 2.0/2.5/MYDOS compatible. It can't be written to, and can only be read sequentially (no random access). You CAN copy your executable files to the PC with FILE2PC and load (run) them directly using this new function. If you ask for a directory, you will see the PC file's filename on your Atari. (The length in sectors has no meaning.) Normally, after the end of file has been reached, the system automatically unloads the disk. If you don't want this, use the /N (no space) option after the filename and the file pointer will be reset to the start of the file after the end is reached - making the file available to read again. A new command has been added to install the simulated disk - the "I" command. It replaces the old "Z" command (create double) which is now a separate choice under the Create Disk option. The new function works like this: A simulated directory sector is given on demand (#361). (When read, it causes the file pointer to be reset to the start of the file.) There is also a simulated sector #1 and sector #360 because some DOSes read these sectors to get information about the disk. The simulated directory supplies a dummy sector pointer to sector 401 to start the file. Each simulated data sector increments the sector number for the "next sector" link. Thats why the status line will show you reading sector 401 thru 700. Then, it rolls down to number 401 again. So if it rolls over, you have read 300. (As of 3.10, trying to write doesn't return an error to the Atari, it "pretends" to write the sector.) Trying to read a sector out of sequence doesn't return an error either. The program would still just supply the next 125 file bytes if this happened. Note: if you need full functionality (READ, WRITE, RANDOM ACCESS) for your Atari- file-on-a-PC, just copy it to an Atari (SIO2PC) disk image. There are a lot of uses for this new feature. You can download Atari files to your PC and immediately load/run them on the Atari. You could program in 6502 on the PC using a cross assembler and load the files to the Atari with no translation required. You may choose to keep some favorite programs available under a "one Atari file per PC file" basis as an alternative to having files under Atari disk images. With rev. 3.11, boot files may also be simulated. To use this feature, just put /B after the file name. You can combine /B and /N if you want. The program will send the next sequential 128 bytes to the Atari each time it requests a sector, until the end of file is reached. PRINT-THRU: The serial bus ID for the Atari printer is 040h. With PRINT-THRU in effect, the program answers bus commands directed to the printer and routes the data to the PC's printer or screen, as selected. Note that the Atari uses an EOL character (09B hex) to mark the end of line, while the PC uses carriage return and line feed (CR/LF) characters. So SIO2PC gives you the option of making the translation. If you are printing text, you should translate. For graphics, probably don't translate. You can also strip the high bit if you want. The reason? ASCII is a 7 bit text code. Computers use 8 bit data. So, text with the high bit set is not defined under ASCII, and different computers use it differently. On the Atari, text with the high bit set is printed to the screen as inverse video. On the PC you may get graphics characters. So, when printing text, you usually want to clear the high bit. If you are printing 8 bit graphics data, you usually don't want to change it. For revision 2.6, I've made some changes to the PRINT_THRU function. The reasons, and other comments, are summarized below: PRINTER NOTES, REV. 2.6 Due to reports of problems with the PRINT-THRU mode in certain cases, I've reworked the print-thru routine. My basis for this feature is to try to provide 100% compatibility with the Atari 850 Printer/Serial interface, since it should be the standard for the Atari. I went back and reread the functional description in my 850 manual. Here is a summary: The Atari printer handler (in the computer's CIO, not in the 850) sends fixed length records (40 characters) to the printer. If an EOL (RETURN key) is encountered, it fills the rest of the buffer with spaces and sends it. Note that software on the Atari doesn't necessarily have to use CIO. It can send data directly to the serial port using SIO. Fixed length, 40 byte, records are still necessary because the interface expects them. Now, when the 850 receives a 40 byte record from the computer, it goes by these rules: 1) Send all bytes to the printer, as 8 bit data (no clearing the high bit) except, 2) If an EOL (9B hex) is encountered, convert it to a CR character, and ignore the rest of the buffer (assumed to be extraneous spaces supplied by CIO) except, 3) If several consecutive EOLs are found, translate them all to alternating CRs and spaces and send to the printer. NOTE: rev 2.8 took out the spaces. My version was adding a space even if there was only one EOL, causing alignment problems in the printout. My interface was designed to provide several modes of operation, one of which would emulate the 850 exactly. However, it wasn't doing some of the things above. It didn't ignore characters after the EOL. It didn't translate multiple EOLs to multiple CRs, only the first. It also translated EOLs only to CR plus LF, not CR only. Now you have the option of doing either. What do the 850 rules above mean to the Atari printer programmer? Well, as I see it, you can NEVER send a hex 9B to the printer, because the conversion is irrevocably hard coded into the 850's ROM. Since graphics data by nature can represent any dot pattern, it must include all possible combination of bits, including $9B. This really isn't a huge problem. The software would just have to detect EOLs and change one bit. One dot's worth of error out of every 256 * 8, on average, won't hurt anything. Another "cure" would be to have a printer which requires 7, not 8, bit data. Since $9B has its high bit set, it would never be required to send graphics data. (Just as it is not required to send standard ASCII text, a 7 bit system.) All this info is presented for your amusement only. Hopefully, if my emulation of the 850 is correct, your software will play just like it did on your Atari printer. Of course, the Atari software will have to be configured for the characteristics of your PCs printer, not your Atari's printer, assuming they are different. Rev 2.10 information: I added a value to the TIMINGS menu for the printer. This is experimental at this time. One guy has a problem with the system (PC) locking up after 3/4 page or so. I think maybe his printer isn't handshaking properly, so I've added this timing value, to keep from "overrunning" his printer. The normal value is 0. If you have problems, add a little time. This value is in units of 1/18th of a second, so keep your number small or you'll be in for a long wait. It is the value used between sending of 40 byte records to the printer. Figure out about how long it takes your printer to print a line and use about half this value in seconds. So if your printer printed a line in 1 second, the value used would be 0009 for 9/18 of a second. In 3.07, I added another translation to the PRINT-THRU function. Now, you can also change the ATASCII tab character to a standard ASCII TAB in the PRINT-THRU process. A 'T' on the PRINT-THRU status line shows that you have chosen this option. UNINSTALL DISK: Why is it important to be able to do this? Well, if you have already used up all your memory in defined ramdisks, you can't overlay them with new ones unless you remove the existing ones. This often would mean you had to quit SIO2PC and restart it to get the configuration you wanted. Now, you can delete ramdisks, and thanks to "garbage collection" performed by the program, all data moves down to fill in the hole. So, you now have free memory equal to the size of the deleted disk. Uninstalling "file access" disks doesn't free any ram, but it does free up one of your four allowed virtual disks. STATUS LINE INFO: I've created a special status line, which is displayed at the bottom of the screen, to help identify problems and to show that the SIO2PC program is actively doing something. It shows: LOC: An identifier for the subroutine being executed. CMND: SIO command from the Atari (Read, Write, etc.) LAST: Command received previous to the one above. DEV: Hex number for device being addressed by Atari. Note 31 - 38 = D1 - D8; 40 = Printer, 39 = Remote Control program 3A = FILE2PC program. COM: High/Low status of the Atari command line. ERR: An error code returned by one of SIO2PC's routines. A character here doesn't necessarily mean a problem. To aid me in debugging. SEC#: The sector # currently being written to or read from by the Atari. RAM: The amount of RAM you have free for use. It changes as you install and uninstall ramdisks. SPEED: N means normal speed 19.2K Baud, H means high speed, as in Sparta Dos' high speed I/O. Note that the status line is updated even when the device being accessed isn't an SIO2PC device. This allows you to use SIO2PC to eavesdrop on the SIO bus. PC MEMORY USAGE: The technically inclined may want to know how the program decides it has the right to RAM for its ramdisks. Well, I initially wrestled with this one. I was trying to use a DOS function for "Allocate Memory," but I got an error code meaning "no memory available." This was crazy, because SIO2PC is a very compact program. It turns out that when DOS runs a COM file, it allocates ALL available memory to the program. This is because DOS is intended to be a single tasking system. I took advantage of that fact. My program doesn't ask for memory, it just takes it, as though it's the only player (which it should be). (Note: TSRs loaded BEFORE SIO2PC are safe. SIO2PC only uses memory higher than that allocated to itself.) I use an internal DOS variable to decide if there is enough memory to load/create the ramdisk you request. DOS SHELL FEATURE: The main improvement added in rev. 3.08 is the ability to "shell out" to DOS. What this means is, you return to the DOS command line prompt "C:>" while SIO2PC is still resident. Then you can run DOS commands or programs, type EXIT, and be back in SIO2PC. You will of course be subject to limitations on the amount of memory available with SIO2PC and any ramdisks you have resident in memory. It's a good idea to avoid messing with (deleting, renaming) any files that SIO2PC has open, such as file access disks. (SIO2PC doesn't leave files open when ramdisks are loaded.) In order to make this function fit on the menu, I had to dump a function. So, I took "R" off the screen. This is the function which restores the screen (ESCAPE also works). Note that "R" still works, you just don't see it on the menu. Due to the way memory is managed, you shouldn't install any TSRs while in the DOS shell. VIRUS DETECTION: I got a rude introduction to the world of viruses a while back when I found that my system had been attacked by a virus. Since then, I've added the byte count on the sign off message as a small first step. Rev. 3.03 adds some more complex checks. As soon as SIO2PC gets control, it loads a second copy of itself into memory. Why? Because the virus may have already "done its thing" to the running copy, then fixed it to look unchanged. Anyway, SIO2PC loads a second copy, and checks to make sure it isn't any bigger than its supposed to be. You get a message if the size is wrong. It then does a CRC calculation on the copy. If the CRC result isn't as expected, you get another warning. The program will still run, however. I translated the CRC calculation algorithm from C code in a book on serial communications. My version may not be exactly right, but it does work. I've tried toggling a single bit and got the warning. Please note that no system is foolproof. Virus and counter-virus development is like the arms race. These additions don't seem to slow down program loading to any appreciable extent, but for those of you who can't tolerate ANY slowdown, I've included an override. Just put /v or /V on your command line somewhere after the program name and the virus checking will be skipped. (You should put the /v after the port # since the program comes up expecting a port #.) If you make changes to the program by interrupting it while it's running (as I showed you how to do elsewhere), it may make the CRC wrong. To fix this, I've had the program print out the calculated CRC with its sign off message. The idea was that you could patch in the correct CRC value with DEBUG. However, with rev 3.08, that's been automated: In 3.08, I changed the virus detection function (CRC check) so that the program will offer to fix SIO2PC's internal CRC value to that just calculated. This is mainly for me, so newly assembled versions can have their CRC set automatically. If you get the warning and haven't changed the program, better get out your virus checker and go over your files. Delete SIO2PC and install a healthy copy. REMOTE CONTROL PROGRAM USAGE This section is to tell you how to use the Atari program called REMOTE.OBJ. This program is found on your disk image file, ATARI.ATR. The program allows you to send commands to SIO2PC from the Atari, just as if you were typing them on the PC's keyboard. So, if your Atari and PC are in different rooms (or something), you can swap ramdisks, save and load, etc. without leaving the Atari. The file is fairly small, and if you plan to make use of it, you should copy it to as many ramdisk images as necessary to assure that it's accessible when you need it. When the program comes up, it shows a list of most of the SIO2PC commands. If you want to study this list, hold down the START key, or else it will scroll off after 3 seconds. The program next gets the status's of the 4 disks from the PC and puts them on the screen. Now you are ready to enter your command. Say you want to load a disk image from A:\ATARI.ATR into ramdisk #4. Just type L4A:\ATARI.ATR and RETURN. Note that some commands give you prompts which you must answer in your command string, so anticipate them. For instance, if you tell the PC to write back a file, you need to anticipate "USE EXISTING FILESPEC?" and "FILE EXISTS, OK TO OVERWRITE?". Note that if writing was successful, the "W" in the status line will have changed to "N" after completion. One person was using REMOTE.OBJ on the Atari as an AUTORUN.SYS, and feeding it with a batch script from SPARTADOS to automate setup of his MIO ramdisks. Because he couldn't simulate a character from the keyboard with SPARTADOS, my "Run another command (Y/N)" left him stranded. For this reason, you can now skip the command by starting your string with a space. When REMOTE.OBJ sees the space, it will send the command to the PC, then return to DOS automatically. Note: After transmitting a command, REMOTE.OBJ is allowing the PC a certain number of seconds to complete it before giving up on getting the ramdisk status. If you find that not enough time has been allowed, let me know so I can add some more. (If you choose to skip the rerun prompt, you won't be getting the ramdisk status after command completion.) MAKADISK.EXE As I stated earlier, the need for MAKADISK.EXE has been pretty much eliminated by the introduction of SIMULATED DISKS, which allow the Atari to load in a file which is in native PC DOS file format. However, you may still find a reason to use MAKADISK. The purpose of this program is to allow you to take a PC file and convert it into an Atari ramdisk image so your Atari can read it. For instance, you may have a modem on your PC only, and want to download Atari files. Or, you may want to write program source code on your PC, because it has an 80 column screen, and send it to the Atari for compiling. At present, this program is basic - it allows you to put only one file to a standard single density ramdisk image. You should then boot the Atari up with SIO2PC and copy the file to a real disk or a "full featured" disk image (one created by SIO2PC and your Atari DOS). Then you may as well delete the MAKADISK created ramdisk image, it has served its purpose. You can't write more files to it, the VTOC isn't correct. Note that another utility may be useful. I want to make one, but they are available in public domain (PC Magazine's utilities disk has one). The utility needed is to translate PC "end of line" codes (CR and LF) to the Atari EOL code, which is hex 9B. If you are translating text files, you will probably need this. Binary files (such as executable programs) shouldn't generally be translated. Note that MAKADISK asks for three things: 1. The name (or pathname) of the PC file to be converted to Atari. 2. The name of the PC's ramdisk image file. This is the name you will give SIO2PC when you load the ramdisk image. I use an .ATR extension for all my ramdisk images stored on the PC, but you can use what you want. Note, MAKADISK doesn't tell you if there's already a file by that name, so be careful, existing files will be overwritten. 3. The name of the Atari version of the file. This is the name you will see in the first position on your Atari screen when you ask DOS for a directory. FILE2PC USAGE INFORMATION FILE2PC.OBJ is an Atari program found on your ATARI.ATR disk image file located on the distribution diskette. If you run this program on your Atari, it will cause SIO2PC to go into the file transfer mode. Just follow the prompts on the Atari. You can read the technical details in the TECHNICAL INFORMATION section if you're interested. This file transfer function has been much requested. A lot of people seem to have text files on their Atari's and want to transfer them to their PC's so they can pick them up on the PC's word processor. I should tell you that the usual warnings apply to this: Different word processors use different formatting control codes. This is true even if you aren't going to a different computer. Plus, the Atari has its own method of ending a line. It uses an EOL (9B hex or 155 decimal) to tell its editor to drop the cursor down one and move to the left margin. The PC, on the other hand, uses two codes, CR & LF or carriage return and line feed. They are hex codes 0D and 0A (decimal 13 and 10). There are utilities available which translate codes like these. There was one called CHANGE on PC Magazine's utilities disk. Unfortunately, it only works with files up to 40K in size. I want to write one without this limit. A common denominator is the so called ASCII file, which is free of specific non-standard formatting commands. (Like this file.) If your Atari word processor will output a plain ASCII file, you may want to use the option before sending it to the PC. Some Atari programs will allow you to use an OS feature which lets you PRINT to a disk file. This should yield a plain ASCII file. Also, if you wanted to send it to your PC's printer, it should definitely be ready to go in this format. Anyway, you will probably want to use a filter program to change your 9Bh's to CR/LF's as a minimum. Note that 9Bh looks like a "cents" symbol on my PC. To see it, hold down ALT on the PC and type 155 on your numeric keypad. Rev 2.3 note: Now that the PRINT_THRU function allows you to "print" to a PC file, you have another method of transferring your Atari text files to PC files. And since the PRINT_THRU option has EOL to CR/LF and TAB conversion capabilities, it may be easier to use in some cases than FILE2PC. Remember, Atari DOS allows you to COPY a file to P:. 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. FUTURE PLANS, CURRENT PRICING I now feel that SIO2PC is becoming a pretty mature program. However, there seems to be no limit to the number of enhancements one can dream up. I would like to take a stab at making the system capable of copying copy protected disks, with the ability to run them from SIO2PC storage without the original disks. I don't really see SIO2PC as some sort of copy protection cracker, but it is a pain for users to have this system and still have to rely on an Atari drive to run some of their software. I'm not sure how effective this system will be, because I'm not up on all copy protection techniques, but ... we'll see. I also hope to soon try to implement the Lightspeed I/O feature you Spartados/U.S. doubler users know and love. DONE It also occurs to me that some sort of Auto-compaction should be possible. I could have the program keep track of the highest sector # written, and store only data to that point. The empty portions of partially written disks, in general, wouldn't take up any disk space. (DOSes generally use sectors sequentially, from low to high numbers.) On the hardware side, I am still trying to simplify the assembly of the interface. It takes far too much time for the price charged to wire one up. So, I may soon make the DB-9 connector mount on the board and protrude thru the case, just like the ones on your PC do. This will save a lot of time stripping cables and wiring/assembling connectors. It will also mean that the interface will need a DB9S to DB9P or DB25S to DB9P cable to interconnect it to the PC. I'll probably soon change the hardware so that the interface won't interfere with the SIO bus, even when the PC is turn off or not connected. 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: 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!! 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. 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 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 130 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. 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.