Notes on 1050-2-PC: I've had a few people ask me about making a device which would allow the PC to plug directly into an Atari drive. After considering whether there would actually be any advantages, I've started work on a variation on SIO2PC I've cleverly named 1050-2- PC. (No, it's not limited to just 1050 drives. 810's and any other Atari drives which accept the standard SIO commands can be accessed.) Hardware Considerations: 1050-2-PC requires a different hardware interface, or at least a configurable version of SIO2PC. The reason is that the DATA IN and DATA OUT pins on the Atari computer are swapped on the disk drives (and other peripherals). This is so DATA IN on the computer will go to DATA OUT on the peripherals, etc. Also, the COMMAND line is an output from the Atari computer, but it is an input to the disk drive. So, what do we have to do to make an SIO2PC type device properly connect to an Atari drive? Well, first you just swap the DATA IN and DATA OUT wire connection points inside the blue box for the Atari (SIO) cable only. The COMMAND line is a bit more complicated. In SIO2PC it uses a gate which converts TTL to RS-232. It will now need an opposite conversion, RS-232 to TTL. (Such a gate now exists within SIO2PC as a spare, if you have the "onechip'' hardware.) And, a different handshaking line from the PC is needed. Currently the RI (ring indicator) line, which is an input, is used. The new hardware will use the RTS line, which is an output. That pretty well takes care of switching the signal lines, but there's another problem. SIO2PC is powered by the 5 volt line coming out of the computer. The disk drive doesn't put out 5 volts. So, a separate power supply is needed. Keep in mind that the PC will be playing the role of an Atari computer in controlling the SIO bus. So a real Atari computer can't be plugged in to the daisy chain while all this is going on. It's strictly one-to-one. My unit will be powered from a 9 volt battery, regulated down to 5 volts. As I've said before, I'm strictly a hobbyist and am not about to sell, give, or otherwise convey anything to people which they are going to plug into a 120 volt wall outlet! (If you do decide to build something yourself on your own and run it off of a 5 volt "wall charger" type adaptor, here's something to consider: Most of these units put out rated voltage at rated load (current), but much higher voltage with low current draw. So unless you're sure you have a regulated adaptor, put a 5 volt regulator on your board. The MAX-232 gives 5 volts as the nominal supply voltage and only 6 volts as the maximum allowable (more may cause damage). Not very forgiving! Also, most of these little supplies aren't filtered either. Put an electrolytic capacitor across the adaptor's output (say 50 to 100 uF, 25 volt) and a 0.1 uF disk and 10 uF or so electrolytic across the output of the regulator. Again, attempt only what is within your range of competence. Get professional advice or assistance if necessary. I am not advising anyone to build anything!) (If you are adding a power supply to a unit I built, note that I already put a 5 V regulator in it. So use something that puts out in the 9 to 15 Volt range.) Another note: On a 1050-2-PC, there should be no need for the blocking diode and pull-up resistor simulating open collector or Tri-State, since multiple devices won't exist on the bus during use of this function. Implementating the hardware: I've considered a number of methods. Currently, I'm working with an entirely separate device. One could also modify SIO2PC using a 3-pole, double throw switch and adding a 5 volt supply. Another method would involve having a "two headed" SIO2PC. It would have one SIO connector coming out for connection to an Atari computer and another for connection to an Atari drive (not both simultaneously). Software: The intent is to make some software which will allow copying specific sectors or entire disks directly to PC disk image files. I don't know whether I will get around to "file-at-a-time" extractions or not. That practically requires writing one's own Atari DOS, or a number of DOSses, if you want SPARTA and other types of extractions. It almost seems to be not worth the effort to do all this, since files and/or complete disk images can already be transferred using SIO2PC and an Atari computer as an intermediary. However, I've gotten interested again in trying to provide a method of emulating copy protection, so copy protected files can be copied and run "un-cracked." The 1050-2-PC can be very useful to analyze disks for copy protection methods. My intent isn't to encourage piracy, but to allow owners of Atari software to run it using modern hardware. I am building the 1050-2-PC functions into a sub-menu of SIO2PC. Select main menu choice A followed by sub-menu choice D. Currently, it will copy complete 720 or 1040 sector disks or copy any number of consecutive sectors the user asks for. I will be adding "analysis" of sector status and other stuff in the near future. Also, writing sectors or entire disks will be included. If you're interested: As I said, routines to copy disk images and sectors are already in version 4.0 of SIO2PC. If you want the hardware, or want to know more about modifying what you have ... contact me. Version 4.05 can also write back disk images and read and report the status of sectors as well as display a HEX/ASCII dump of selected sectors, and do formatting. Here's some other stuff it can do, pasted in from the README.TXT file: 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 this 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. Nick Kennedy