mattd@Apple.COM (Matt Deatherage) (02/19/90)
In article <1557@crash.cts.com> tsouth@pro-pac.cts.com (System Administrator) writes: > >I whole-heartedly agree with the opinion, Mark. What I don't agree with is >that the majority of the spectrum of work for CD-ROM (even if read/write/ >erase drives do hit the market at a price that WE the consumer can afford) >appears to be done in anticipation of Mac sales. WHAT can WE (the Apple // >enthusiasts) expect in the future of the Apple // when it comes to CD-ROM >technology? Will ProDOS ever break the 32 meg limitation (with or w/o a >major re-write)? Will GS/OS formats be interchangeable using ProDOS to >High Sierra FSTs? Can Apple folks answer these questions and give US the >foresight to know how to structure the expenditure of OUR future dollars? :) > >Todd South > I don't know why people keep asking this because the answer is NOT going to change. PRODOS 8 IS NOT GOING TO SEE BEYOND 32 MB PER VOLUME OR 2 DEVICES PER LOGICAL SLOT. It CAN'T. The data structure that every program has to use only allow for 64K 512-byte blocks per volume and they only allow one bit to distinguish which device in a slot you want to access. This can NOT be changed without breaking about 60% of the P8 applications ever written, which makes the new software not exactly ProDOS 8. If P8 didn't have these design limitations, ProDOS 16 (and GS/OS beyond it) wouldn't have been necessary. I don't understand what you mean by "Will GS/OS formats be interchangeable using ProDOS to High Sierra FSTs?" You can copy a file from a High Sierra disk to a ProDOS disk under GS/OS now, and you've always been able to do so. If you're inquring about the future, I see absolutely no reason for this capability to go away. -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================
aj0@sage.cc.purdue.edu (Eric Mulholland) (02/19/90)
>In article <1557@crash.cts.com> tsouth@pro-pac.cts.com writes: >>technology? Will ProDOS ever break the 32 meg limitation (with or w/o a In article <38736@apple.Apple.COM> mattd@Apple.COM (Matt Deatherage) writes: >I don't know why people keep asking this because the answer is NOT going to >PRODOS 8 IS NOT GOING TO SEE BEYOND 32 MB PER VOLUME OR 2 DEVICES PER LOGICAL >If P8 didn't have these design limitations, ProDOS 16 (and GS/OS beyond it) >wouldn't have been necessary. As I understand it, ProDOS 16 was merely a shell around ProDOS 8 and in effect has the same limitations as ProDOS 8, including 32M max limit. GS/OS on the other hand is a complete rewrite and thus CAPIBLE of larger volume sizes. Take a closer look at GS/OS and see that it uses FSTs to do all the low level work with the hardware. In knowing this, it's easy to see that volume size for GS/OS is limited by its FSTs. So what FSTs are there? There is a ProDOS FST, this is what must of us are use to, because it is so simular to ProDOS 8, but has a few extentions, like forks. There's a Sierra-Online FST. This allows those who have expensive CD drives to READ CDs. If and when CDs become writeable, this FST will not allow you to take advantage of that since the FST is READ ONLY. Now there's an AppleTalk FST. This gives us read/write access on AppleTalk networks. What percentage of GS users are hooked up to networks? I would say not many. And who is going to run out and buy a Mac, hard drive and the networking software just so they can have a large storage device to run there GS files from? I suspect none. There is also a Character FST. I don't know about you, but I don't see any acceptible way of storing/retrieving files from there. So Matt, you say ProDOS 16 and GS/OS were written to get around the limitations of ProDOS 8? The only storage capicaty limit that I see as being removed is the number of volumes per slot. With the size of hard drives getting larger, we still CANNOT make good use of them without having to resort to defining many partions to fill the space. This is another main reason why we want a mac FST, so we can format the hard drive to one big volume! Some will even settle for a FST of a new file system, one that will permit GS/OS to live up to its fullest protentials! -- ____ Y_,_|[]| Eric Mulholland {|_|_|__| aj0@sage.cc.purdue.edu //oo--OO ...!pur-ee!sage.cc!aj0
dlyons@Apple.COM (David A. Lyons) (02/19/90)
In article <3637@sage.cc.purdue.edu> aj0@sage.cc.purdue.edu (Eric Mulholland) writes: >[...] GS/OS on the other hand is a complete rewrite and thus CAPIBLE of >larger volume sizes. Take a closer look at GS/OS and see that it uses >FSTs to do all the low level work with the hardware. To be a little picky, the FSTs do all the medium-level file-system work, and the FSTs ask the device drivers to do all the device-level work. >[...] There's a Sierra-Online FST. This allows those who have expensive >CD drives to READ CDs. If and when CDs become writeable, this FST will >not allow you to take advantage of that since the FST is READ ONLY. The file systems that FST reads are "High Sierra" and "ISO 9660." (Sierra- Online is a software company, last time I checked.) If and when CDs become writeable, the FST could be updated to support it. At this point it would be a waste of engineering time. >[...] Now there's an AppleTalk FST. This gives us read/write access on >AppleTalk networks. What percentage of GS users are hooked up to >networks? I would say not many. And who is going to run out and buy >a Mac, hard drive and the networking software just so they can have a >large storage device to run there GS files from? I suspect none. I don't have the numbers, but the AppleShare FST was not intended as a way for an individual user to get at a large hard drive. Where a network with AppleShare file servers is appropriate, the AppleShare FST does a needed job well. >[...] With the size of hard >drives getting larger, we still CANNOT make good use of them without >having to resort to defining many partions to fill the space. This is >another main reason why we want a mac FST, so we can format the hard >drive to one big volume! [...] You don't have to convince me! I already think having an HFS FST would be a good idea. (Do you see anybody arguing against it?) -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
mattd@Apple.COM (Matt Deatherage) (02/20/90)
In article <3637@sage.cc.purdue.edu> aj0@sage.cc.purdue.edu (Eric Mulholland) writes: > > GS/OS on the other hand is a complete rewrite and thus CAPIBLE of >larger volume sizes. Take a closer look at GS/OS and see that it uses >FSTs to do all the low level work with the hardware. In knowing this, >it's easy to see that volume size for GS/OS is limited by its FSTs. So >what FSTs are there? > Dave has already addressed some of this, but to repeat, drivers talk to the hardware, FSTs talk to the drivers, GS/OS talks to the FSTs, applications talk to GS/OS. The volume size for "GS/OS" is limited by the data structures used by GS/OS's abstract file system. GS/OS uses a four-byte field for number of blocks on a volume, and a two-byte field to indicate how many bytes per block. Theoretically, that gives $FFFF * $FFFFFFFF bytes per volume, or a limit of 2.8E14 bytes per volume. Most file systems (the method used to organize bytes on a disk into files and directories) have smaller limitations than this. > There is a ProDOS FST, this is what must of us are use to, because >it is so simular to ProDOS 8, but has a few extentions, like forks. > Again, an application makes GS/OS calls, not "ProDOS FST calls" (with some very minor FST-specific exceptions). The ProDOS FST allows GS/OS to use ProDOS disks. The FST has all the limitations of the native (in this case, ProDOS) file system, including that on ProDOS disks, you have two bytes that indicate how many 512-byte blocks are on the disk, for a total of 32 MB. Changing this means that any ProDOS 8 software that works with these disk structures directly will not work with these disks (not just with some files on the disk, but with the disk itself). That makes it not exactly a ProDOS disk. ProDOS's file system has fortunately always supported storage types, so other programs or operating systems (Pascal, GS/OS) can create files on ProDOS disks that ProDOS 8 won't try to mess with. That's how Pascal Volumes and Extended Files can fit on those disks without ProDOS 8's knowledge. Changing the whole disk so ProDOS 8 can't use it is an entirely different matter. > There's a Sierra-Online FST. This allows those who have expensive >CD drives to READ CDs. If and when CDs become writeable, this FST will >not allow you to take advantage of that since the FST is READ ONLY. > There's a "High Sierra" FST; Sierra On-line has nothing to do with this international standard for CD-ROM disks which was created at a conference at the High Sierra resort in Nevada. The FST doesn't support writing because CD-ROM is currently not a writeable technology. If this changes, the FST can change. That's why it's not in ROM. > Now there's an AppleTalk FST. This gives us read/write access on >AppleTalk networks. What percentage of GS users are hooked up to >networks? I would say not many. And who is going to run out and buy >a Mac, hard drive and the networking software just so they can have a >large storage device to run there GS files from? I suspect none. > You would be incorrect. Schools were crying for AppleShare access under GS/OS ever since GS/OS was released. We listened, we created. As Dave says, AppleShare (it's not an "AppleTalk FST"; AppleTalk is not a file system) is a complete networking solution, not a method for individual people to use larger hard drives (although it does work for that as well). > There is also a Character FST. I don't know about you, but I don't >see any acceptible way of storing/retrieving files from there. > The Character FST is essential to the I/O model of GS/OS. It's not SUPPOSED to be a way to access a file system; it deals with the character side of the I/O model (other FSTs deal with the block side). > So Matt, you say ProDOS 16 and GS/OS were written to get around the >limitations of ProDOS 8? The only storage capicaty limit that I see as >being removed is the number of volumes per slot. With the size of hard >drives getting larger, we still CANNOT make good use of them without >having to resort to defining many partions to fill the space. This is >another main reason why we want a mac FST, so we can format the hard >drive to one big volume! Some will even settle for a FST of a new file >system, one that will permit GS/OS to live up to its fullest protentials! > >-- > ____ > Y_,_|[]| Eric Mulholland >{|_|_|__| aj0@sage.cc.purdue.edu >//oo--OO ...!pur-ee!sage.cc!aj0 ProDOS 8 can't read data into banks other than zero. GS/OS can. PrODOS 8 can't deal with multiple file systems. GS/OS can. ProDOS 8 forces you to interpret directories yourself. GS/OS doesn't. ProDOS 8 has 15-character file name limitations. GS/OS doesn't. ProDOS 8 has one prefix. GS/OS has 34 (counting *: and @:). ProDOS 8 has a 128-character pathname limit. GS/OS's is 8,000 characters. ProDOS 8 can only have two devices per slot. GS/OS is not limited here. ProDOS 8 has file system limitations. GS/OS's are much larger. Etc., etc., etc. What you want is a newer FST (like HFS) to address the file system problems associated with ProDOS. No one is arguing against that. What I was saying is that ProDOS 8 (the 8-bit disk operating system) isn't going to deal with volumes greater than 32 MB. That stands. -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================
cwilson@NISC.SRI.COM (Chan Wilson) (02/20/90)
>>In article <1557@crash.cts.com> tsouth@pro-pac.cts.com writes: >>> [much ado over 32meg limitation of Prodos8] > There's a Sierra-Online FST. This allows those who have expensive ^^^^^^^^^^^^^ Hmm, that's an amusing typo. ;-) [Description of various FSTs] > So Matt, you say ProDOS 16 and GS/OS were written to get around the >limitations of ProDOS 8? The only storage capicaty limit that I see as >being removed is the number of volumes per slot. With the size of hard >drives getting larger, we still CANNOT make good use of them without >having to resort to defining many partions to fill the space. This is >another main reason why we want a mac FST, so we can format the hard >drive to one big volume! Some will even settle for a FST of a new file >system, one that will permit GS/OS to live up to its fullest protentials! Ever realize that HFS is limited to 32 MB volumes? Betcha you didn't know that. :) HFS gets around the limitation by using allocation blocks in conjunction with logical blocks to achieve the larger volume size. Catch is, there's a tradeoff. The larger the drive is, the larger the allocation blocks are. This means that every time you cross a multiple of 32 in size, your a-block size goes up by another 512 bytes. The extreme end of this sees you with a volume 256 Terrabytes long, with a minimum file size of 4 gigabytes. I wonder what the access time of a drive that big would be? ;-) Now, I'm not that familiar with GS/OS (yet), but it seems that some possible variation in this theme would be possible. Question is, when? > Y_,_|[]| Eric Mulholland --Chan ................ Chan Wilson -- cwilson@nisc.sri.com <or> radius!cwilson@apple.com Janitor/Architect of comp.binaries.apple2 archive on wuarchive.wustl.edu I don't speak for SRI, someone else does. ................
dlyons@Apple.COM (David A. Lyons) (02/20/90)
In article <13373@fs2.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson) writes: >[...] >Ever realize that HFS is limited to 32 MB volumes? Betcha you didn't >know that. :) HFS gets around the limitation by using allocation >blocks in conjunction with logical blocks to achieve the larger volume >size. Catch is, there's a tradeoff. The larger the drive is, the >larger the allocation blocks are. Considering that you've just explained HFS *isn't* limited to 32M volumes (you're correct, it *isn't* limited), how did you manage to start out by claiming it was? If you're saying HFS is limited to 65536 allocation blocks, I'm willing to believe that (I haven't tried to look it up). That's not the same as being limited to 32M volumes. The ProDOS file system *is* limited to 32M volumes, because there is no such allocation block scheme. (Trying to introduce one now would kill all utilities that do block-level access, of course.) -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
tsouth@pro-pac.cts.com (System Administrator) (02/20/90)
In-Reply-To: message from mattd@Apple.COM
Matt,
I know that ProDOS will never be changed to break the 32 meg limit, but I can
still keep wishing! Maybe I should have been a little more definitive on the
other question. What I mean is will we be able to have CD's literally packed
with programs (even if in packed LZW format) in which the programs can be
copied into a ProDOS volume and used immediately? The possibilities for
storage of Appleworks data files, old utilities, PD software bonanzas, etc...
are tremendous under this circumstance. Also, I can imagine things like
archives of USENET traffic from my proline site for the past 6 months!!!
These are the things I'm looking at. Will GS programs simply need to use the
High Sierra FST to store and retrieve files as normal? Will there be some
special translation between ProDOS and High Sierra that the programmer must
take care of or is this built-in? I have archives on 3.5's of years of text
and Appleworks files that I would LOVE to fit on one single CD!
Todd...
--
UUCP: {nosc, uunet!cacilj, sdcsvax, hplabs!hp-sdd, sun.COM, apple} /\
...!crash!pnet01!pro-sol!pro-pac!tsouth /\ /^^\
ARPA: crash!pnet01!pro-sol!pro-pac!tsouth@nosc.MIL /^^\ Tigard
INET: tsouth@pro-pac.cts.com / \ Oregon
BITNET: pro-pac.UUCP!tsouth@PSUVAX1 / \ \cwilson@NISC.SRI.COM (Chan Wilson) (02/20/90)
In article <38782@apple.Apple.COM> dlyons@Apple.COM (David A. Lyons) writes: >In article<13373@fs2.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson) writes: >>[...] >>Ever realize that HFS is limited to 32 MB volumes? Betcha you didn't >>know that. :) HFS gets around the limitation by using allocation >>blocks in conjunction with logical blocks to achieve the larger volume >>size. Catch is, there's a tradeoff. The larger the drive is, the >>larger the allocation blocks are. > >Considering that you've just explained HFS *isn't* limited to 32M volumes >(you're correct, it *isn't* limited), how did you manage to start out by >claiming it was? Oops, I figured someone would catch me on that. -) >If you're saying HFS is limited to 65536 allocation blocks, I'm willing >to believe that (I haven't tried to look it up). That's not the same >as being limited to 32M volumes. Yea, that's what I meant. >The ProDOS file system *is* limited to 32M volumes, because there is no >such allocation block scheme. (Trying to introduce one now would kill >all utilities that do block-level access, of course.) Speaking of such, would there happen to be a new filesystem definition in the works? Granted, HFS can access the larger volumes, but it does seem to have it's weak points. Is this why we haven't seen an HFS FST? <hint, hint, nudge, nudge, know-what-I-mean?> >David A. Lyons, Apple Computer, Inc. | DAL Systems --Chan ................ Chan Wilson -- cwilson@nisc.sri.com <or> radius!cwilson@apple.com Janitor/Architect of comp.binaries.apple2 archive on wuarchive.wustl.edu I don't speak for SRI, someone else does. ................
aj0@sage.cc.purdue.edu (Eric Mulholland) (02/26/90)
>In article aj0@sage.cc.purdue.edu (Eric Mulholland) writes: >> GS/OS on the other hand is a complete rewrite and thus CAPIBLE of >>larger volume sizes. Take a closer look at GS/OS and see that it uses The point of my article is what SIZE volumnes I can currently use in gs/os. Yes gs/os can handle very large volumes, but with system 5.0.2, with all that comes with it, you cannot use a very large drive. (speaking about a local hard drive here) Don't get me wrong, gs/os is a great operating system, makes prodos 8 look like a homework assignment. Here I'm only looking at the aspect of volume size. In article <38762@apple.Apple.COM> mattd@Apple.COM (Matt Deatherage) writes: >Dave has already addressed some of this, but to repeat, drivers talk to the >hardware, FSTs talk to the drivers, GS/OS talks to the FSTs, applications talk >to GS/OS. True. My errors there have been pointed out. >Again, an application makes GS/OS calls, not "ProDOS FST calls" (with some very >minor FST-specific exceptions). The ProDOS FST allows GS/OS to use ProDOS >disks. The FST has all the limitations of the native (in this case, ProDOS) I don't think I mentioned anywhere of trying to make direct calls to the fst. Even making calls to gs/os, I'm not going to get a 100meg file on a directly connected hard drive with the current system software. >ProDOS's file system has fortunately always supported storage types, so other >programs or operating systems (Pascal, GS/OS) can create files on ProDOS disks >that ProDOS 8 won't try to mess with. That's how Pascal Volumes and Extended >Files can fit on those disks without ProDOS 8's knowledge. Changing the whole >disk so ProDOS 8 can't use it is an entirely different matter. Like I was saying, adding more to the definition of prodos disks, or should say changing reserved values into known values. Nothing wrong there. A prodos disk bigger than 32meg is not a prodos disk. That's my point in that the prodos fst cannot be used for making a huge volume. >> There's a Sierra-Online FST. This allows those who have expensive >>CD drives to READ CDs. If and when CDs become writeable, this FST will >>not allow you to take advantage of that since the FST is READ ONLY. >There's a "High Sierra" FST; Sierra On-line has nothing to do with this >international standard for CD-ROM disks which was created at a conference at >the High Sierra resort in Nevada. The FST doesn't support writing because >CD-ROM is currently not a writeable technology. If this changes, the FST >can change. That's why it's not in ROM. I'm embarresed I called that fst by the wrong name. I don't know if CD drives can be hooked up to a scsi card or uses a different interface. This is showing how little I know about the details of scsi and of cd disk format. So it is probibly inposible to trick gs/os into thinking a hard drive is just a small, slow cd. >You would be incorrect. Schools were crying for AppleShare access under GS/OS >ever since GS/OS was released. We listened, we created. As Dave says, >AppleShare (it's not an "AppleTalk FST"; AppleTalk is not a file system) is a >complete networking solution, not a method for individual people to use larger >hard drives (although it does work for that as well). I haven't seen satistics, so, what percentage of Apple //gs owners are schools? I don't think many private (non-school) owners are hooked up to a network. Now that schools got their appleshare fst, may we home users get a super size hard drive fst? >> There is also a Character FST. I don't know about you, but I don't >>see any acceptible way of storing/retrieving files from there. >The Character FST is essential to the I/O model of GS/OS. It's not SUPPOSED >to be a way to access a file system; it deals with the character side of the >I/O model (other FSTs deal with the block side). I included it mainly for completeness. I never expected an answer different then the above one. >> So Matt, you say ProDOS 16 and GS/OS were written to get around the >>limitations of ProDOS 8? The only storage capicaty limit that I see as >>being removed is the number of volumes per slot. With the size of hard >(long list of advantages of gs/os over prodos 8) >What you want is a newer FST (like HFS) to address the file system problems >associated with ProDOS. No one is arguing against that. What I was saying is >that ProDOS 8 (the 8-bit disk operating system) isn't going to deal with >volumes greater than 32 MB. That stands. The way prodos 8 is defined, it cannot be extended. This is why I'd like to see a new fst to make use of super size hard drives. If I want to store prodos 8 and gs/os programs on the same disk, that's what the prodos fst is for. I just don't want to be limit to it! No one is arguing against another fst, we just don't see it. -- ____ Y_,_|[]| Eric Mulholland {|_|_|__| aj0@sage.cc.purdue.edu //oo--OO ...!pur-ee!sage.cc!aj0