c40889c0   
   From: joe@user.com   
      
   "AaronB"  wrote in message   
   news:4d5c3a35-8b86-48c7-85a9-32873b561178@i29g2000prf.googlegroups.com...   
   > > "Mike Y"  wrote:   
   > > P&T CP/M was protected.  However, there used to be a sysgene program   
   > > floating around that would copy it...   
   >   
   > Mike Y, perhaps you or FDIV could answer this:   
   > Why does TRSDOS 2.0x need to read the first 7 bytes of the last sector   
   > on the current track on each revolution of the disk? It doesn't even   
   > seem to be compared to anything - that's frustrating and puzzling.   
   > It's also slowing the emulator for no apparent gain with it's constant   
   > need to interrupt.   
      
   You have to know a bit of the early history.   
      
   First off, the ORIGINAL OS for the Model II was single density the whole   
   disk.  No, that was not planned to be released, but just the way things   
   worked in developement.  When it finally went to double density with   
   the 1st track single density, there were problems with checking the media   
   for a change.  Fingers were pointed, but at least at one point there was   
   a finger pointed at some of the early CDC drives for the expansion bay.   
      
   Since the original TRSDOS was set up as 5 groups of 5 sectors with one   
   'extra', they put a 'tag' in that extra sector.  And that extra tagged   
   sector   
   was always the first sector read after the disk index.  After the tag, then   
   any group of 5 sectors could be read on one revolution of the media.   
   Unfortunately, that also meant that to read a whole track took 5   
   revolutions...   
      
   As to it's use, the only track it really was read on was the directory track   
   after the disk was in use, and then only for certain OS functions.  All the   
   taks on all the other tracks were unused.  At least in 2.0.   
      
   It was never really used for 'protection' except in one case.  Tech Support   
   put together a disk with EVERYTHING on it for the shops.  One of the   
   programs on this diskette was an alignment program that would write to   
   the diskette, trashing it.  Some shops just never seemed to get it through   
   their heads to take the diskette out and put in a blank to align the drives.   
   There were shops that would order 5 or more of these diskettes to keep   
   around, at almost $100 a pop, from National Parts.  Huh?  Excuse me,   
   but were they that stupid?  I guess some were.  Shops could just duplicate   
   the disk whenever they needed to, backup worked fine.  What eventually   
   was done was the master diskette was 'modified' with reverse protection.   
   the 'tag' was tampered with at one spot on the diskette, and the diskette   
   would refuse to run, UNLESS it was backed up and the tags matched,   
   which happened after a normal backup of the diskette.  I forget what   
   was actually in the tag, but I think I used my name.   
      
   > I also have code in the emulator for Arcnet, but lack a version of   
   > TRSDOS that supports this so that I can verify the code. Does anyone   
   > have a disk for Arcnet?   
      
   If you can get hold of the 'diag' diskette mentioned above, there were   
   a few neat little utilities on it.  Things like Terminbl which was the same   
   thing as Terminal except it was set up for Com port B instead of A.   
   There was also a program that I think I called TermArc.  It was a   
   look-alike / work-alike to the Terminal program except that instead of   
   using one of the serial ports, it used the ArcNet.  The only catch with   
   ArcNet was that the chip on reset did things that could NOT be done   
   after init, and there was no way to reset it in software.  (Can the   
   hardware designer of the ArcNet board say opps?  To be fair, there   
   were a lot of 'constraints' put on the ArcNet design which I really   
   won't go into here.)  Anyway, after a hardware reset of the Model II,   
   you could read the dipswitch of the ArcNet board and set the chip   
   to that address.  Then the TermArc program would use that to talk   
   between any two Model II's on the ArcNet.  Unfortunately you had   
   to reset the system to put the chip back into a mode were the ArcNet   
   software would work later, as there was no way in the chip itself to   
   know what's it address was if you tried to access it after the fact.   
   (Can the chip designer say OOPS at this point?  They have NO   
   excuse!)   
      
   Anyway, the only reason I suggest this would be that the TermArc   
   program might be a pretty simple program to look at to see how the   
   part operated if you need to disassemble the code.   
      
   By the way, don't trust the databooks on the ArcNet chip!  There   
   were serious reasons why data sizes were chosen to be what they   
   were!   
      
   Mike   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)