





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