c40889c0   
   From: uhclemLOSE.jan08@nemesis.lonestar.org   
      
   AaronB  wrote:   
   : > "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.   
      
   TRSDOS 2.0 was already in the field when I came along, but one   
   of my earliest tasks at Tandy was to work on software to compare   
   diskettes and duplicate them for the new TRSDOS-II, and while working   
   on that I got to look at some earlier code for TRSDOS 2.0/2.0a/2.0b.   
   (At that point in time, rows of TRS80s in a factory were recording the   
   8" media diskettes sold in stores, not duplicating machines.)   
      
   There were two stories that circulated as to why the sector 27 thing   
   existed in TRSDOS 2.x.   Probably at least one is true:   
      
   Story #1   
      
   This is the most believeable and I will put it under those words uttered   
   by Bill Wilson: "Software can always fix hardware."  (He believed this   
   probably because that expense would come out of the budget for the   
   software department and not his department.)   
      
   Constantly reading sector 27 provided a way to tell whether the media had   
   changed since the previous I/O.  The idea here was that each diskette   
   had a semi-randomly generated number stuck in sector 27 on every track,   
   and before the OS did anything with the disk, the OS would go read sector   
   27 and see if the number was still what it was earlier.  If so, keep   
   going.  If not, complain bitterly about the user not telling the OS that   
   diskettes were being changed, usually done via the INIT or some other   
   command.   
      
   To someone who got into computers in the IBM PC era, this probably   
   sounds really stupid but it is only slightly stupid and really cheap.   
   The earliest 8" drives, notably the CDCs ans possibly others that   
   Radio Shack used did not have a media change detection switch, even   
   though the floppy drive interface had the signal available for   
   reporting such events.  (5 1/4" drives had the same issue until   
   media-change was multiplexed onto the READY line, as is done on   
   IBM PCs and clones.)  Frequently having the switch was an option that   
   added a couple dollars to the cost of the given drive model, so it was   
   omitted on units that Tandy bought.   
      
   Subsequently the Model II OS of the day had no concept of if or when   
   the user had changed media and users did have a habit of doing it at   
   highly inappropriate times.  No doubt Scripsit users recall the penalty   
   of taking a floppy out without first closing the document and suddenly   
   finding that none of the documents on the diskette could be accessed   
   anymore, not without going through a process to clean things up, a   
   task sometimes beyond the skills of the customer.   
      
   So - as the story goes - this scan of the hidden sectors was there   
   to provide a simple way of figuring out if the media is still the same   
   as it was earlier.  Because the save value was written on every track,   
   there was no head movement so it seemed fast, but in reality the   
   worst-case access penalty was about two media revolutions.  That   
   is, almost one revolution to get to sector 27, and maybe almost one to   
   get to where you really wanted to be.  Combined, that could be anywhere   
   from 0 to 333 msec.   
      
   Of course, throwing in anything up to 1/3rd of a second of delay   
   on every single disk I/O made TRSDOS I/O SLOW.   Which it was.   
      
   This is a perfect example of why trying to hide hardware bugs,   
   deficiencies and cost-cutting may be cheap up front but may have other   
   issues, like having performance be terrible.  When people asked why   
   TRSDOS and TRSDOS-II were so slow  - no one asked about TRSDOS-16 as   
   everybody knew why it was slow - compared to XENIX or later to LS-DOS   
   that were running on the same hardware, the argument from the remaining   
   TRSDOSers was that those other systems were not following the rules and   
   so would not be as reliable, which of course was mostly a garbage   
   explanation.  (CP/M was also faster that TRSDOS, but most versions on   
   the Model II systems tended to be really unstable due to bugs in   
   interrupt and DMA programming, and this tended to support the   
   slower-means-more-reliable myth.)   
      
   By the time the Model 16 came out, the thinline floppy drives used   
   in the computer cases and in the new expansion boxes supported media   
   change detection, and TRSDOS 2.0A/B were created to not only use this   
   but deal with some quirks related to it, and to have a similar release   
   for the legacy systems or mixed systems that still had old drives in   
   addition to new.   
      
   A year or so later, when Tandon cost-reduced their thinline drives   
   (the ones with the round lights instead of square) by switching from   
   discrete logic to a microprocessor, they broke media-change detection   
   anyway, so you still had to be careful.  Now the new thinline drives only   
   reported disk changes if you happened to pop the diskette out and stick   
   a new one in WHILE the drive light was ON (selected), which even the   
   dumbest user had probably learned to never do.  If the drive was not   
   selected when the diskette was changed, the cost-reduced drives would   
   never say a thing.   
      
   TRSDOS-II continued some of the TRSDOS techniques of trying to cover   
   this hardware deficiency and detect unreported media changes, but not to   
   the extent of wasting an entire sector, possibly because they had no   
   space for a hidden sector in the 512 byte sector format.  That's why   
   they frequently stated in the manuals that you really should do an INIT   
   or DIR command if you change media unless you were prompted to do so   
   in a specific drive.  Fortunately, users were gradually learning to not   
   pull tapes out of their shiny new VCRs while recording shows, and some   
   of this concept seemed to rub off and improve their floppy changing   
   behavior.   
      
   XENIX used hardware media change detection, but made zero attempt to   
   test for changes that were not reported.  Because of the V7 and   
   System III filesystems used in XENIX, taking diskettes away before   
   they were dismounted was a really bad thing to do.   
      
      
   Story #2   
      
   Sector 27 was (or was also) a copy protection system.  As the user   
   could not read nor write (at least via documented calls) sector 27, the   
   user would not know it was there, and so applications that chose to do   
   so could store additional things in those undocumented sectors   
   (provided the first dozen bytes or so of the sectors were left unaltered)   
   which the OS would ignore but they could act on or detect the   
   absence of (as the standard copy utilities would make sector 27s with   
   a different random number).   
      
   This would be a bit stronger than security through obscurity, but   
   not much stronger, since a few disk editing tools did exist for   
   the Model II and they certainly knew about the extra sector.   
      
   I'm not sure how much of story #2 to believe.  Although it is   
   certainly possible, I don't know if any applications ever took   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)