home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / alt / cdrom / 5200 < prev    next >
Encoding:
Text File  |  1992-12-16  |  2.8 KB  |  60 lines
  1. Newsgroups: alt.cd-rom
  2. Path: sparky!uunet!cs.utexas.edu!usc!news.service.uci.edu!ucivax!megatek!max
  3. From: max@megatek.com (Max Elliot)
  4. Subject: Re: multi-session - what's different?
  5. Message-ID: <1992Dec16.205620.12193@megatek.com>
  6. Organization: Megatek Corporation, San Diego, California
  7. References: <1992Dec14.182303.18272@eng.umd.edu>
  8. Date: Wed, 16 Dec 1992 20:56:20 GMT
  9. Lines: 49
  10.  
  11. From article <1992Dec14.182303.18272@eng.umd.edu>, by chuck@eng.umd.edu (Chuck Harris - WA3UQV):
  12. > In article <1992Dec14.090229.883@ica.philips.nl> adrie@ica.philips.nl (Adrie Koolen) writes:
  13. > ...
  14. > 
  15. >>The problem is that all the CDROM drives I've tested scan the TOC when a new
  16. >>disc is inserted and know where the lead-out area starts. When a request to
  17. >>read a block beyond the program area is given, the drive rejects it. If the
  18. >>drive doesn't check the block number, you should be able to read all the
  19. >>blocks from the CDROM, so also the other sessions, but...
  20. > 
  21. > My problem here is that you are telling me why most drives can't handle the
  22. > multi-session "standard".  I already understand, and appreciate that problem.
  23. > The question I would like an answer to is: Why didn't the people who made the
  24. > multisession "standard" just store the additional adjustable pointers in a
  25. > hidden file of some sort in the normal program area?  This would have required
  26. > a small change to the software drivers in order to handle multisession, but
  27. > would require no changes to the CDROM drives.
  28. > 
  29. > For instance, they could have defined a hidden file named (for lack of a better
  30. > name) multipch.ptr.  Made the file big enough to hold as many "modifications"
  31. > to the disk as you are willing to allow, and just let the laser "blot" over the
  32. > old pointers that don't apply after the new session to the CDROM.  The software
  33. > driver would have to look at this file on startup, skip over the old pointers
  34. > that have been "blotted" out, and make a table in memory that has the
  35. > pointer adjustments necessary to map the directory to the new session's files.
  36. > 
  37. > This seems to me to be plenty simple, and much more desirable than obsoleting
  38. > everyone's CDROM drive.
  39. > 
  40. > Chuck Harris - WA3UQV
  41. > chuck@eng.umd.edu
  42.  
  43.   Yeah, why couldn't ISO9660 just specify a place to put a single #@$*&
  44.   link to the *next* volume header!!! It's soooo simple.  But, then again
  45.   if they did intelligent things, they would not be a standards org.
  46.  
  47.   I propose that the ISO9660 CD standard volume header be modified to 
  48.   include a pointer to the *next* volume header, should one exist. Just
  49.   use one of the more useless fields like 'reserved3' or 'abstract_id'
  50.   for something useful, like 'next_session' !! This 'next_session' 
  51.   would be another ISO9660 *or* HSF primary descriptor. No sweat!
  52.  
  53.   Geesh, how easy. Old 9660 disks still work, and software updates to
  54.   drivers handle the new multi session.
  55.  
  56. -Max
  57.  
  58. > 
  59. > 
  60.