paul@athertn.Atherton.COM (Paul Sander) (09/27/89)
In article <7834@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes: [stuff about a bug in BASIC.SYSTEM v1.3 omitted] > One caveat, I do make it a habit of modifying each version of ProDOS I > get so that it will access 40 track 5.25 disks. But I always keep the > original, unmodified ProDOS around in case bugs show up. As I mentioned > above, the errors were indepandant of the ProDOS version, but went away > when BASIC.SYSTEM v1.2 was used. BTW, why don't you Apple II ProDOS > developers just support 40 track 5.25 drives in the standard release > ProDOS? Probably because there are still lots of 35 track 5.25" floppy drives out there. Many of them are even DISK ][s! > That is the only occasion that even tempts me to delve into the > dark expanses of ProDOS machine code. (DOS 3.3 had many factors which > demanded modification!) What does DOS 3.3 have to do with it? This is a hardware limitation for some drives and a media compatibility problem in general. As I understand it (it's been a while, so this might have changed), 35 tracks were defined as the standard size for 5.25" floppies, though some manufacturers discovered that stretching things to 40 tracks worked okay. This was before 77 track 5.25" floppies came out, but they never really caught on anywhere but AT class IBM machines and clones (and maybe on Commodore machines). A better solution would be to write installable drivers for 40-track floppies, and distribute software on 35-track floppies. > Brian Willoughby > UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw > InterNet: microsoft!brianw@uunet.UU.NET > or: microsoft!brianw@Sun.COM > Bitnet brianw@microsoft.UUCP -- Paul Sander (408) 734-9822 | If you must describe both quantity and paul@Atherton.COM | quality of someone else's code, try {decwrl,pyramid,sun}!athertn!paul | "awful lot." -- independent discovery
brianw@microsoft.UUCP (Brian Willoughby) (09/28/89)
In article <12994@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes: >In article <7834@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes: >> One caveat, I do make it a habit of modifying each version of ProDOS I >> get so that it will access 40 track 5.25 disks. [...] >> BTW, why don't you Apple II ProDOS >> developers just support 40 track 5.25 drives in the standard release >> ProDOS? > >Probably because there are still lots of 35 track 5.25" floppy drives out >there. Many of them are even DISK ][s! Yes, but supporting 40 tracks does not force all disks to become 40 track disks. If I'm running Pascal, DOS 3.3 or my modified ProDOS, and I stick in a 35 track disk, then the OS will not write beyond track 35 on that disk. That's because DOS 3.3 has a VTOC which would mark those sectors as not available, and Pascal and ProDOS have a 'total number of blocks on this disk' value in the directory which will not allow the OS to allocate blocks greater than the maximum. The hard problem is not *preventing* an erroneous 40 track write to a 35 track disk, but *allowing* a write to the entended blocks/sectors by indicating that there is free space out there beyond track 35. That necessitates a custom formatter to produce disks with 40 track directory sizes, but you do not need to modify Pascal or DOS 3.3 to use these 40 track disks, just ProDOS. >> That is the only occasion that even tempts me to delve into the >> dark expanses of ProDOS machine code. (DOS 3.3 had many factors which >> demanded modification!) > >What does DOS 3.3 have to do with it? This is a hardware limitation for some >drives and a media compatibility problem in general. There is no compatibility problem, and it has everything to do with DOS (IMHO) because DOS broke the 'rules' and hard-coded specific information about the Disk ][ which prevented attaching any other drive (3.5", hard disk, etc.). ProDOS improved on DOS by not hard-coding limits of any particular drive. In case you didn't know why I'm complaining, ProDOS returns an I/O ERROR *before* it even *attempts* to access blocks greater than 280. That is the ONLY hard-coded limitation within the ProDOS code (i.e. my modification changes *1* byte to allow accessing 320 blocks, if I can find that byte in each new version of ProDOS). If you have a 35 track disk, then ProDOS should never seek beyond track 35 because each and every disk has the total number of blocks encoded into the directory, and that controls where ProDOS puts new files. All I am asking is that if a 5.25 disk directory indicates to ProDOS that a file has blocks beyond 280, then ProDOS should at least *attempt* to read it before returning an incorrect I/O ERROR message. In fact, I don't think there should be any hard-coded limit, ProDOS should always use the value read from the volume currently online for the number of blocks on that volume. One caveat (there goes another) with my modified ProDOS, if you accidently place a 40-track disk in a drive only capable of 35 (which I often do because my drive 2 is a 35er), the ProDOS track seek function will enter an endless loop trying to move the head to an impossible track. In my opinion, the track seek routine doesn't have to be coded with such limiting assumptions. I also don't think that to be a serious drawback because 40 track disks shouldn't be in the drives of people who only own 35 track disks (for the most part). >As I understand it (it's been a while, so this might have changed), 35 tracks >were defined as the standard size for 5.25" floppies, though some manufacturers >discovered that stretching things to 40 tracks worked okay. This was before >77 track 5.25" floppies came out, but they never really caught on anywhere but >AT class IBM machines and clones (and maybe on Commodore machines). In my admittedly limited experience, no other drive (except the TI-99) is limited to less than 40 tracks. If you pop the lid on your drive and look at the size of the 'window' compared to the position of the head while formatting a disk, you will notice that the 35th track is nowhere near the limit. Why did they make the window for the drive head so large if 35 tracks was the standard? Also, according to one source, there were two drives made by Shugart which were used in Disk ][ units. The first one used by Apple was 35 track, and the second was the SA-490 mechanics version (I'm not absolutely sure about that number) which accesses 40 tracks and handles half-tracks better. I found this out before I purchased my first drive, because Apple Disk ][ drives were >$550. I wanted a Shugart drive, for the same quality as Apple's, but I only paid $199. That was many years ago, and the few people I know with genuine Apple Disk ]['s seem to all have the 35 track version. BTW, I can actually get 41 tracks, but since I've never read about anyone using that many, I've never tried to *use* a 41 track disk. >A better solution would be to write installable drivers for 40-track floppies, >and distribute software on 35-track floppies. Great idea! But I think that ProDOS 8 checks the slot ROMs for the driver addresses on booting, so these drivers would have to be loaded in on every ProDOS startup. They would also take up memory, when a simple change in one byte would make them unnecessary. Regarding distribution, 35-track is the only way. Microsoft still distributes non-OS/2 software on 360K floppies, which is a real pain, but the only way to support everyone. Nothing prevents you from copying them onto larger capacity disks (we don't use copy protection). Written correctly, I don't see how a 40-track ProDOS would cause any difficulties for 35-track drive owners. I don't know why I'm trying to convince you, though, because Apple is who I need to convince :-) >-- >Paul Sander (408) 734-9822 | If you must describe both quantity and >paul@Atherton.COM | quality of someone else's code, try >{decwrl,pyramid,sun}!athertn!paul | "awful lot." -- independent discovery Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP
bh1e+@ANDREW.CMU.EDU (Brendan Gallagher Hoar) (09/29/89)
I really don't see the problem with ProDOS supporting 40 tracks for reads and writes. Any disk formatted at 35 tracks will always act the same. Only people that have 40 track drives are going to have to worry about it, or people that receive disks from others that have been formatted with 40 tracks, which would probably cause problems anyway...
paul@athertn.Atherton.COM (Paul Sander) (09/29/89)
In article <7865@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes: > In article <12994@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes: > >In article <7834@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes: [Brian says that he tweeks ProDOS, changing the 5.25" floppy seek limit from 35 tracks to 40. He then asks why Apple's ProDOS developers don't support 40 track drives. I replied that 35 track drives are still around, and that they should continue to be supported.] > Yes, but supporting 40 tracks does not force all disks to become 40 track > disks. It may or it may not. It depends on how the limit is lifted. Simply raising the capacity changes who the special cases are. Somebody (e.g. mass-producers of software) has to format the media to 35 tracks. Making 40 tracks the norm causes everyone who formats a diskette which is to be given to a 35 track user to take the special case. This is not an improvement. > If I'm running Pascal, DOS 3.3 or my modified ProDOS, and I stick > in a 35 track disk, then the OS will not write beyond track 35 on that > disk. That's because DOS 3.3 has a VTOC which would mark those sectors > as not available, and Pascal and ProDOS have a 'total number of blocks on > this disk' value in the directory which will not allow the OS to allocate > blocks greater than the maximum. This is true. > The hard problem is not *preventing* an > erroneous 40 track write to a 35 track disk, but *allowing* a write to > the entended blocks/sectors by indicating that there is free space out > there beyond track 35. That necessitates a custom formatter to produce > disks with 40 track directory sizes, but you do not need to modify Pascal > or DOS 3.3 to use these 40 track disks, just ProDOS. Using installable drivers (as I suggest in a later quote) eliminates the need for custom formatters. The driver should know the capacity of the device it drives, as well as the maximum capacity of the medium. I'll discuss the ProDOS mod later in this article. > >> That is the only occasion that even tempts me to delve into the > >> dark expanses of ProDOS machine code. (DOS 3.3 had many factors which > >> demanded modification!) > > > >What does DOS 3.3 have to do with it? This is a hardware limitation for some > >drives and a media compatibility problem in general. > > There is no compatibility problem, and it has everything to do with DOS > (IMHO) because DOS broke the 'rules' and hard-coded specific information > about the Disk ][ which prevented attaching any other drive (3.5", hard > disk, etc.). There is a compatibility problem: Diskettes formatted on a 40-track drive cannot be read in full by 35-track drives. (Compatibility works two ways.) > ProDOS improved on DOS by not hard-coding limits of any > particular drive. In case you didn't know why I'm complaining, ProDOS > returns an I/O ERROR *before* it even *attempts* to access blocks greater > than 280. That is the ONLY hard-coded limitation within the ProDOS code > (i.e. my modification changes *1* byte to allow accessing 320 blocks, if > I can find that byte in each new version of ProDOS). This suggests a problem with ProDOS that perhaps should be repaired. This sort of thing can be changed by an installable driver. > If you have a 35 > track disk, then ProDOS should never seek beyond track 35 because each > and every disk has the total number of blocks encoded into the directory, > and that controls where ProDOS puts new files. All I am asking is that > if a 5.25 disk directory indicates to ProDOS that a file has blocks > beyond 280, then ProDOS should at least *attempt* to read it before > returning an incorrect I/O ERROR message. In fact, I don't think there > should be any hard-coded limit, ProDOS should always use the value read > from the volume currently online for the number of blocks on that volume. I totally agree. > One caveat (there goes another) with my modified ProDOS, if you > accidently place a 40-track disk in a drive only capable of 35 (which I > often do because my drive 2 is a 35er), the ProDOS track seek function > will enter an endless loop trying to move the head to an impossible > track. In my opinion, the track seek routine doesn't have to be coded > with such limiting assumptions. I also don't think that to be a serious > drawback because 40 track disks shouldn't be in the drives of people who > only own 35 track disks (for the most part). This exposes a bug/feature of ProDOS where the seek routine doesn't give up if it can't find the track it seeks. But even this can be worked around given an installable driver, because the erroneous seek operation can be trapped. [Evolution of 5.25" floppies omitted] > In my admittedly limited experience, no other drive (except the TI-99) is > limited to less than 40 tracks. For the record, so were the TRS-80, Altair, Imsai, and a number of others that are hard to find nowadays. > If you pop the lid on your drive and > look at the size of the 'window' compared to the position of the head > while formatting a disk, you will notice that the 35th track is nowhere > near the limit. Why did they make the window for the drive head so large > if 35 tracks was the standard? This limitation came about from the density of flux changes on the surface of the medium of the day. As the head moves closer to the center of the diskette, the density of the bits increases. At track 35, the specified limit was reached. [History of Apple Disk ][ omitted, along with price incentives to go elsewhere and also a mention of a 41st track.] > >A better solution would be to write installable drivers for 40-track floppies, > >and distribute software on 35-track floppies. > > Great idea! But I think that ProDOS 8 checks the slot ROMs for the > driver addresses on booting, so these drivers would have to be loaded in > on every ProDOS startup. They would also take up memory, when a simple > change in one byte would make them unnecessary. The boot ROMs on the controller contain only an IWM and a bootstrap loader. They give no indication to the capacity of the drive. They do assume 16 sectors, though. The loader does not contain adequate error detection, so it is not used as a driver, even in DOS 3.3. Installable drivers can actually be very small, if they can make use of another installed driver. I'm not up on the innards of ProDOS in particular, but a typical driver should include routines for reading and writing a sector, seeking a track, and formatting a medium, along with some device-specific data (like "block_structured_device" flag and "number_of_tracks" limit). If a 35-track driver is shipped with stock ProDOS, a 40-track driver could simply be a device characteristics table and jump instructions to the 35-track driver routines (assuming all of the limits are coded in the table and pre-checked by ProDOS rather than by the driver). [Brian says that Microsoft distributes on least-common-denominator media.] > Written correctly, I don't see how a 40-track ProDOS would cause any > difficulties for 35-track drive owners. I agree in principle, but I seem to disagree in detail. In order to share data media, the 40-trackers must have the ability to generate 35-track media. Patching ProDOS in the way you have been suggesting makes this hard; at best, a program must be run which hacks the limit that is hard-coded in ProDOS whenever the capacity of the medium changes. At worst, inappropriate media are produced by the higher-capacity systems. In the middle, permanent hacks to ProDOS and customized software (e.g. formatters) must be written. > I don't know why I'm trying to > convince you, though, because Apple is who I need to convince :-) Hear-hear! Dave and friends, are you out there? What do you think? -- Paul Sander (408) 734-9822 | If you must describe both quantity and paul@Atherton.COM | quality of someone else's code, try {decwrl,pyramid,sun}!athertn!paul | "awful lot."
brianw@microsoft.UUCP (Brian Willoughby) (10/02/89)
(I sure hope that Apple is listening to my mumbling and grumbling...) Paul, I'm not being critical, but I wanted to point out a few things. BTW, I don't know everything about ProDOS, either... In article <13132@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes: >In article <7865@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes: >> Yes, but supporting 40 tracks does not force all disks to become 40 track >> disks. > >It may or it may not. It depends on how the limit is lifted. Simply raising >the capacity changes who the special cases are. Somebody (e.g. mass-producers >of software) has to format the media to 35 tracks. Making 40 tracks the norm >causes everyone who formats a diskette which is to be given to a 35 track user >to take the special case. This is not an improvement. I agree that 40 tracks should not become the norm. I'm quite glad that ProDOS still runs on my ][ Plus, and if Apple ever requires an Enhanced //e or better to use a new ProDOS, you'll hear much more grumbling from my corner. The 8 bit Operating Systems from Apple should always support the entire line, or why not just require GS/OS exclusively? I don't want 40 tracks to become the standard, I merely suggest support for their access without having to resort to modifying ProDOS. >Using installable drivers (as I suggest in a later quote) eliminates the >need for custom formatters. The driver should know the capacity of the >device it drives, as well as the maximum capacity of the medium. I'll >discuss the ProDOS mod later in this article. But who wants to lug around all that unused code after the driver is installed? I explain in detail further on, but there is already a great deal of language card memory devoted to the Disk ][ whenever ProDOS is active. It should be improved/corrected and used without being circumvented by a loaded driver. >There is a compatibility problem: Diskettes formatted on a 40-track drive >cannot be read in full by 35-track drives. (Compatibility works two ways.) True, but ProDOS does not include formatting code. >> ProDOS improved on DOS by not hard-coding limits of any >> particular drive. In case you didn't know why I'm complaining, ProDOS >> returns an I/O ERROR *before* it even *attempts* to access blocks greater >> than 280. That is the ONLY hard-coded limitation within the ProDOS code >> (i.e. my modification changes *1* byte to allow accessing 320 blocks, if >> I can find that byte in each new version of ProDOS). > >This suggests a problem with ProDOS that perhaps should be repaired. This >sort of thing can be changed by an installable driver. We agree that it should be repaired. That's all I need. An installable driver would not be needed after that simple change, but an installed driver would have the positive feature of enabling ProDOS to format a Disk ][ floppy without running a special program. >>[I explain how placing a disk formatted with 40 tracks in a drive >>limited by it's hardware to only reach 35 tracks causes ProDOS to >>infinately loop whenever seeking the extra tracks.] > >This exposes a bug/feature of ProDOS where the seek routine doesn't give up >if it can't find the track it seeks. But even this can be worked around >given an installable driver, because the erroneous seek operation can be >trapped. I suggest that the Disk ][ driver inside the ProDOS code (the ONLY driver within ProDOS other than the clock card support, all other drivers are in ROM) allow access to floppies of ANY block size, but that the track access be limited in how long it will try to seek. [discussion of 35 track limit] >This limitation came about from the density of flux changes on the surface >of the medium of the day. As the head moves closer to the center of the >diskette, the density of the bits increases. At track 35, the specified >limit was reached. (This is just an aside on my part) I have been told that the Disk ][ format is called GCR (group code recording?) and that only single-density is actually required, but double-density is recommended. I have asked this question of the UseNet before, but does anyone know if accessing tracks 35-39 goes beyond the Apple Disk ][ density limits? And if so, which limits (i.e. SD or DD) have been exceeded? I have only had intermittant (largely ignorable) trouble with the extra 5 tracks on ONE brand of disks, so there seem to be two possibilities: A) The extra tracks only require double-density bit patterns, instead of single, but my faulty disks were actually below DD criteria (even though labelled as DD). This seems most likely, given my assumption that it is true that the Disk ][ only need SD - and I don't see how a few tracks away could more than double, thus exceeding DD. It could be that that company gets away with their DD claims because the disks are normally used with FM or MFM (whichever is DD), not with GCR. B) The extra tracks exceed DD specs, and the only reason that I have no trouble with other brands of disks is that - in our modern age of low cost media - my other disks surpass the actual DD specs by just enough of a percentage to handle the slightly higher density. I find this unlikely, but it is a possibility. >The boot ROMs on the controller contain only an IWM and a bootstrap loader. >They give no indication to the capacity of the drive. They do assume 16 >sectors, though. The loader does not contain adequate error detection, so >it is not used as a driver, even in DOS 3.3. BTW, the IWM is made up of logic gates, and therefore cannot be contained within a ROM. The boot ROM does indicate the capacity, all except the old Disk ][ which is recognised by ProDOS and the size is assumed. You are correct about the loader and why it is not used as a driver. One is loaded with ProDOS, even if you don't have 5.25 drives. >Installable drivers can actually be very small, if they can make use of >another installed driver. I'm not up on the innards of ProDOS in >particular, but a typical driver should include routines for reading and >writing a sector, seeking a track, and formatting a medium, along with some >device-specific data (like "block_structured_device" flag and >"number_of_tracks" limit). > >If a 35-track driver is shipped with stock ProDOS, a 40-track driver could >simply be a device characteristics table and jump instructions to the 35-track >driver routines (assuming all of the limits are coded in the table and >pre-checked by ProDOS rather than by the driver). I don't think that the approach of using jump instructions within a Disk ][ driver (40-track or otherwise) would be allowed, since the internal addresses within ProDOS of the existing Disk ][ code are not published or guaranteed to remain unchanged. Based on that, an external 40-track disk driver would not be so small after all, because it would need to duplicate all of the existing Disk ][ code already present in ProDOS. Especially large considering that ProDOS has no built-in Disk ][ formatting code. Again, I think that since it has already been established as a standard that ProDOS will have drivers for the Disk ][ within the memory resident routines loaded into the language card, that these routines (which do not include formatting) should support accesses to all 5.25 disk drives - INCLUDING THE 40-TRACK DRIVES. You've got the right approach, though. If ProDOS were "fixed" so that a theoretical 40-track Disk ][ driver could make use of the existing driver (i.e. NOT returning an error when you ask for blocks >280), then this theoretical driver wouldn't be needed. I'm just trying to drive my point into the ground so that Apple will see what I mean about this. >> Written correctly, I don't see how a 40-track ProDOS would cause any >> difficulties for 35-track drive owners. > >I agree in principle, but I seem to disagree in detail. In order to share >data media, the 40-trackers must have the ability to generate 35-track >media. Patching ProDOS in the way you have been suggesting makes this hard; >at best, a program must be run which hacks the limit that is hard-coded in >ProDOS whenever the capacity of the medium changes. At worst, inappropriate >media are produced by the higher-capacity systems. In the middle, permanent >hacks to ProDOS and customized software (e.g. formatters) must be written. I'm probably being redundant, but my ProDOS patch does not make any of your nightmares come true. I use my modified ProDOS at all times and still have no trouble supporting all the 35-track-based software that I purchase. Since I always back up my software and use the backups as working disks, I make my working copies as 40-track disks. You mention the difficulty of producing 35-track floppies: well, I am forced to do this all the time if the working disk in intended for drive 2. Anyone who is only working with developing on a two 5.25 Apple ][ system must carefully place the needed files on a pair of working disks. I merely have to create two different sized disks, but the extra on-line memory for drive 1 is welcome. I can only boot one ProDOS at any time, so I boot my custom one and have no trouble producing 35-track compatible floppies. In closing: Before I wrote this posting, I tried to back up and look at the big picture from Apple's point of view. My first thought was that Apple might deem that it would be inconsistent to support access to 5.25 Disk ][ volumes larger than 280 blocks, when all of their (external to ProDOS) formatting utilities only create 280 block (35 track) disks. But then I thought that here is an opportunity for Apple to support the 5.25 even better. Since the FILER utilities are an external program, and not severely limited by code size concerns, it would be a simple task to provide one extra prompt during formatting which could easily support 35 OR 40 track disks. ProDOS would be modified to allow accesses beyond the 280th block without wimping out too early, and the head seek algorithm could be improved. Then the end-user could be properly warned about possible incompatibilities before the FILER creates a 320 block disk. (There are much more dangerous things a person can do during formatting) >-- >Paul Sander (408) 734-9822 Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP
paul@athertn.Atherton.COM (Paul Sander) (10/03/89)
In article <7922@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes: brianw@microsoft.UUCP (Brian Willoughby) writes: >In article <13132@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes: >>In article <7865@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes: [Discussion about 40-track floppy drives omitted. In summary, 40-track drives should be supported by ProDOS, though 35-track drives should remain the "norm."] >>Using installable drivers (as I suggest in a later quote) eliminates the >>need for custom formatters. The driver should know the capacity of the >>device it drives, as well as the maximum capacity of the medium. >>[stuff omitted] > >But who wants to lug around all that unused code after the driver is >installed? I explain in detail further on, but there is already a great >deal of language card memory devoted to the Disk ][ whenever ProDOS is >active. It should be improved/corrected and used without being >circumvented by a loaded driver. I've suggested in a later quote a way to reduce the amount of luggage needed in order to support both formats. >>There is a compatibility problem: Diskettes formatted on a 40-track drive >>cannot be read in full by 35-track drives. (Compatibility works two ways.) > >True, but ProDOS does not include formatting code. Really? This is a surprise to me. I had assumed all of the code needed to support a device (in this case a floppy drive) was included in the driver, and that interfaces to all of the functions (including formatting a diskette) were provided in the MLI. I will check on this further. In any case, access to such functions must be available to to application programs, because BASIC.SYSTEM does it; of course, the disk formatting functionality may be encoded into BASIC.SYSTEM somewhere, but I digress. [Discussion about ProDOS I/O ERROR when seeking past block 280 omitted] >We agree that it should be repaired. That's all I need. An installable >driver would not be needed after that simple change, but an installed >driver would have the positive feature of enabling ProDOS to format a >Disk ][ floppy without running a special program. Simply defeating the range checking of the seek routine opens up opportunities for other kinds of errors, like seeking to track 77 on drives that don't support it. Extending the range of blocks accepted by the range check works for individual cases, but is not a complete solution to the problem, as shown in the discussion about formatting 40 track diskettes and then reading them by 35 track drives. [Discussion of problem where, after ProDOS is hacked to permit 40-track seeks, ProDOS enters an infinite loop if a 35-track drive tries to seek past track 35 omitted] >I suggest that the Disk ][ driver inside the ProDOS code (the ONLY driver >within ProDOS other than the clock card support, all other drivers are in >ROM) allow access to floppies of ANY block size, but that the track >access be limited in how long it will try to seek. This may be a viable compromise, but it breaks down if the drive is a 40-track drive but the head actuator is sticky enough (dust, soda, age, whatever) that the amount of time (or number of retries) is exceeded before the seek routine gives up. >[discussion of 35 track limit] >>This limitation came about from the density of flux changes on the surface >>of the medium of the day. As the head moves closer to the center of the >>diskette, the density of the bits increases. At track 35, the specified >>limit was reached. > >(This is just an aside on my part) >I have been told that the Disk ][ format is called GCR (group code >recording?) and that only single-density is actually required, but >double-density is recommended. I have asked this question of the UseNet >before, but does anyone know if accessing tracks 35-39 goes beyond the >Apple Disk ][ density limits? And if so, which limits (i.e. SD or DD) >have been exceeded? Probably both. Believe it or not, the peak flux change densities of SD and DD are the same. DD usually needs better hardware to compensate for bit shift, however. It seems that, although the peak flux change densities are the same for SD and DD, the average flux change density is higher for DD. (If anyone wants more info on this, let's discuss it via email as it is getting too far away from comp.sys.apple.) > I have only had intermittant (largely ignorable) >trouble with the extra 5 tracks on ONE brand of disks, so there seem to >be two possibilities: > >A) The extra tracks only require double-density bit patterns, instead of >single, but my faulty disks were actually below DD criteria (even though >labelled as DD). This seems most likely, given my assumption that it is >true that the Disk ][ only need SD - and I don't see how a few tracks >away could more than double, thus exceeding DD. It could be that that >company gets away with their DD claims because the disks are normally >used with FM or MFM (whichever is DD), not with GCR. > >B) The extra tracks exceed DD specs, and the only reason that I have no >trouble with other brands of disks is that - in our modern age of low cost >media - my other disks surpass the actual DD specs by just enough of a >percentage to handle the slightly higher density. I find this unlikely, >but it is a possibility. I suspect the latter. "Low cost media" come about by reducing manufacturing costs. Sometimes manufacturers cut the wrong corners. If the diskettes you mention were bought before 1983 or so, then I might suspect that the diskettes were made closer to spec than other brands. >>The boot ROMs on the controller contain only an IWM and a bootstrap loader. >>They give no indication to the capacity of the drive. They do assume 16 >>sectors, though. The loader does not contain adequate error detection, so >>it is not used as a driver, even in DOS 3.3. > >BTW, the IWM is made up of logic gates, and therefore cannot be contained >within a ROM. For the record, ROMs _are_ logic gates. Replace the diodes that define the 1-bits with nicrome fuses, you get a PROM. Reduce the number of inputs to the gates, you get an FPLA. Add feedback from the logic gate outputs to their inputs, and maybe some registers, you get a PAL. By the way, the DISK ][ controller contains two identically numbered PROMs, with different stickers on them; one contains executable code, the other contains (with the help of a register) a finite state machine. More than one computer manufacturer has used PROMs as a way of increasing the flexibility of a circuit when timing requirements are not so tight that dedicated logic was needed. (If anyone wants to discuss this further, please use email, this is getting too far away from comp.sys.apple.) [stuff omitted] [I suggest that installable drivers can be small, if they can reuse code already installed by other drivers. This can reduce some drivers to a data table and a jump table.] >I don't think that the approach of using jump instructions within a Disk >][ driver (40-track or otherwise) would be allowed, since the internal >addresses within ProDOS of the existing Disk ][ code are not published >or guaranteed to remain unchanged. Then maybe Apple should write the drivers and require that the 35-track driver be installed before the 40-track driver. Or maybe each driver can register a "skeleton" driver along with the proposed data and jump tables. Library routine registration might make ProDOS more complicated than some might like, however. > Based on that, an external 40-track >disk driver would not be so small after all, because it would need to >duplicate all of the existing Disk ][ code already present in ProDOS. >Especially large considering that ProDOS has no built-in Disk ][ >formatting code. Again, I assumed all of the needed routines were included in the driver. I will check on that. I still disagree that the driver need be large, as there are alternatives copying all of the code, as I've suggested. > Again, I think that since it has already been >established as a standard that ProDOS will have drivers for the Disk ][ >within the memory resident routines loaded into the language card, that >these routines (which do not include formatting) should support accesses >to all 5.25 disk drives - INCLUDING THE 40-TRACK DRIVES. > >You've got the right approach, though. If ProDOS were "fixed" so that a >theoretical 40-track Disk ][ driver could make use of the existing driver >(i.e. NOT returning an error when you ask for blocks >280), then this >theoretical driver wouldn't be needed. I'm just trying to drive my point >into the ground so that Apple will see what I mean about this. I agree. :-) >>> Written correctly, I don't see how a 40-track ProDOS would cause any >>> difficulties for 35-track drive owners. [I list a number of problems that arise by simply patching ProDOS to support 40-track drives.] >I'm probably being redundant, but my ProDOS patch does not make any of >your nightmares come true. I use my modified ProDOS at all times and >still have no trouble supporting all the 35-track-based software that I >purchase. Since I always back up my software and use the backups as >working disks, I make my working copies as 40-track disks. You mention >the difficulty of producing 35-track floppies: well, I am forced to do >this all the time if the working disk in intended for drive 2. Anyone >who is only working with developing on a two 5.25 Apple ][ system must >carefully place the needed files on a pair of working disks. I merely >have to create two different sized disks, but the extra on-line memory >for drive 1 is welcome. I can only boot one ProDOS at any time, so I >boot my custom one and have no trouble producing 35-track compatible >floppies. I must be missing something. You can produce 40-track diskettes for your own use, AND produce 35-track diskettes that I can read, with NO special steps (e.g. rebooting) in either process? Or do you need to hack a special formatter for one of the formats? Or is there something else I've missed? >In closing: > >Before I wrote this posting, I tried to back up and look at the big >picture from Apple's point of view. My first thought was that Apple >might deem that it would be inconsistent to support access to 5.25 >Disk ][ volumes larger than 280 blocks, when all of their (external to >ProDOS) formatting utilities only create 280 block (35 track) disks. >But then I thought that here is an opportunity for Apple to support >the 5.25 even better. Since the FILER utilities are an external >program, and not severely limited by code size concerns, it would be a >simple task to provide one extra prompt during formatting which could >easily support 35 OR 40 track disks. ProDOS would be modified to allow >accesses beyond the 280th block without wimping out too early, and the >head seek algorithm could be improved. Then the end-user could be >properly warned about possible incompatibilities before the FILER creates >a 320 block disk. (There are much more dangerous things a person can do >during formatting) This looks simple enough, but in my opinion the formatting of diskettes should be done by the OS, not by an application. Again, I'll check to see how far off-base I am in my assumptions. (I still can't believe I can't do an INIT from the Applesoft prompt. But then I've always used the supplied programs.) In any case, another tweek to the application must be done if Apple decides to support 77-track 5.25" floppies in such a way that they plug into a Disk ][ controller; such a tweek shouldn't be necessary. The device driver should do right thing and make its functionality available to the application. -- Paul Sander (408) 734-9822 | If you must describe both quantity and paul@Atherton.COM | quality of someone else's code, try {decwrl,pyramid,sun}!athertn!paul | "awful lot."
samt@pro-europa.cts.com (Sam Theis) (10/03/89)
Comment to message from: claris!sts!octopus!pyramid!athertn!paul@apple.com (Paul Sander) Who cares about 40 track floppies! Get a real disk if you need more storage. An 800K 3.5 disk hold a lot more than a 40 track floppy and is a lot more reliable. Sam UUCP: crash!pro-europa!samt ARPA: crash!pro-europa!samt@nosc.mil INET: samt@pro-europa.cts.com
jearls@polyslo.CalPoly.EDU ( Chumley The Troll ) (10/03/89)
In article <13251@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes: >This looks simple enough, but in my opinion the formatting of diskettes >should be done by the OS, not by an application. Again, I'll check to see >how far off-base I am in my assumptions. (I still can't believe I can't >do an INIT from the Applesoft prompt. But then I've always used the supplied >programs.) In any case, another tweek to the application must be done if >Apple decides to support 77-track 5.25" floppies in such a way that they plug >into a Disk ][ controller; such a tweek shouldn't be necessary. The device >driver should do right thing and make its functionality available to the >application. If you look in DOS 3.3, the formatting code took up almost half of the RWTS subroutines (the semi-equivalent of the Disk ][ driver). ProDOS is pushing its boundaries already; if they had included the formatting code it would have spilled over into main memory (or required 128k to run) long since... >-- >Paul Sander (408) 734-9822 | If you must describe both quantity and >paul@Atherton.COM | quality of someone else's code, try >{decwrl,pyramid,sun}!athertn!paul | "awful lot." - John -- _______________________________________________________________________________ Chumley@Bazaar.Deva.COM | -aka- EARLSJ@AFAL-Edwards.AF.MIL | If two wrongs don't make a right, -aka- jearls@polyslo.CalPoly.EDU | try three...
jerryk@pro-tcc.UUCP ("Jerry E. Kindall") (10/04/89)
Network Comment: to #727 by gem.mps.ohio-state.edu!uakari.primate.wisc.edu!polyslo!jearls@tut.cis.ohio-state.edu Actually, adding 5.25" floppy formatting to ProDOS probably wouldn't cause the code to spill over into main memory. There's about 3K in the second bank of the language card that is not used. _____ ||___|| Jerry Kindall | Internet: jerryk@pro-tcc.cts.com | o | 2612 Queensway Drive | UUCP: nosc!crash!pnet01!pro-tcc |__O__| Grove City, OH 43123 | GEnie: A2.JERRY ALine: A2 Jerry
brianw@microsoft.UUCP (Brian Willoughby) (10/06/89)
In article <8910040410.AA04627@trout.nosc.mil> samt@pro-europa.cts.com (Sam Theis) writes: >Comment to message from: claris!sts!octopus!pyramid!athertn!paul@apple.com (Paul Sander) > >Who cares about 40 track floppies! Get a real disk if you need more storage. >An 800K 3.5 disk hold a lot more than a 40 track floppy and is a lot more >reliable. > >Sam Thanks for the hint, Sam. I've tried the Universal Disk Controller AND the Ohio Kache Systems MultiKache Card, and NEITHER one of them works on my Apple II Plus with AE TransWarp and a 16 bit W65C802 processor. Although I own an Apple 3.5 Drive, due to the controller card I am forced to use, 'reliable' is definately not the word I would use to describe it's operation. Currently, until someone designs a better controller, the 5.25 is the MOST reliable drive in my system. Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP
brianw@microsoft.UUCP (Brian Willoughby) (10/06/89)
In article <13251@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes: >In article <7922@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes: > >>I suggest that the Disk ][ driver inside the ProDOS code (the ONLY driver >>within ProDOS other than the clock card support, all other drivers are in >>ROM) allow access to floppies of ANY block size, but that the track >>access be limited in how long it will try to seek. > >This may be a viable compromise, but it breaks down if the drive is a 40-track >drive but the head actuator is sticky enough (dust, soda, age, whatever) that >the amount of time (or number of retries) is exceeded before the seek routine >gives up. The purpose of using a number of retries is NOT so that the OS will work with damaged drives or floppies. The feature is there because 5.25 floppies are soft-sectored and there is also no Track 0 sensor to read the location of the head. If the head seek is inhibited in any way it would probably be good to quit early, thus forcing the user to fix their drive. >>>The boot ROMs on the controller contain only an IWM and a bootstrap loader. >>>They give no indication to the capacity of the drive. >> >>BTW, the IWM is made up of logic gates, and therefore cannot be contained >>within a ROM. > >For the record, ROMs _are_ logic gates. Replace the diodes that define the >1-bits with nicrome fuses, you get a PROM. Reduce the number of inputs >to the gates, you get an FPLA. Add feedback from the logic gate outputs to >their inputs, and maybe some registers, you get a PAL. By the way, the >DISK ][ controller contains two identically numbered PROMs, with different >stickers on them; one contains executable code, the other contains (with the >help of a register) a finite state machine. More than one computer >manufacturer has used PROMs as a way of increasing the flexibility of a circuit >when timing requirements are not so tight that dedicated logic was needed. OK, the IWM is made up of several different kinds of logic gates, and therefore cannot be contained within a ROM. Namely there is a bit-addressable register, a shift register, open collector drivers and a 555 Timer to keep the disk motor on for a short period after an access. These functions cannot be implemented within a ROM. [more deletions] >I must be missing something. You can produce 40-track diskettes for your >own use, AND produce 35-track diskettes that I can read, with NO special >steps (e.g. rebooting) in either process? Or do you need to hack a special >formatter for one of the formats? Or is there something else I've missed? Yes, you got it babe. I can write or copy all the files I want to a 35 track disk and then hand it to you to use on Apple's standard ProDOS with nary a single hitch involved. Formatting is a special case, but as you'll no doubt find, it is a special case for every ProDOS user. I don't use the provided FILER.SYSTEM for formatting. Instead, I use DOS 3.3 to format a disk (I always format all 40 tracks with the soft-sector address markers) and then copy a blank ProDOS directory to the disk of the appropriate size (35 [280 blocks] or 40 track [320 blocks]). This process is roughly equivalent to 'zero'ing a volume with the Pascal Filer, after the low-level formatting has been done by another routine. I looked up the directory format in Beneath Apple ProDOS and found the byte to change which indicates volume size. Using a sector editor, I wrote this change to a blank 40 track disk which is now my master for all blank disks (named /PRO40). BTW, it doesn't hurt anything if I format all disks to 40 track, because the OS doesn't use the extra blocks unless the directory size includes them. Plus, I always have the option of changing a 35er to a 40 track disk with a sector editor. > In any case, another tweek to the application must be done if >Apple decides to support 77-track 5.25" floppies in such a way that they plug >into a Disk ][ controller; such a tweek shouldn't be necessary. The device >driver should do right thing and make its functionality available to the >application. If the seek routine did not assume that it could ALWAYS find the requested track AND ProDOS read the volume size from the 5.25 disk instead of hard-coding it, then 5.25 drives larger than 40 tracks would also work if they were truely Disk ][ interface compatible. I would have to know more about these 77-track drives before I could comment on whether or not I think they could be supported in the 5.25 driver which is part of ProDOS (i.e. not a loaded driver). >Paul Sander (408) 734-9822 | If you must describe both quantity and Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP
greyelf@wpi.wpi.edu (Michael J Pender) (10/07/89)
For right now what is the most elegant approach to converting to 40 track prodos format? I have also managed to do the same thing for Pascal and DOS 3.3 and Prodos, but as I remember I didn't make a habit of it since it was a pain and involved sector editing. (The days before I knew about Prodos MLI calls)
demarco@cpsc.ucalgary.ca (Vince Demarco) (10/09/89)
all of you here are talking about complex ways for formating a 5.25 for 40 tracks. Well i i have a program that will do the formating for you and it also adjusts the bitmap so it is correct. If anyone wants me to i'll upload it to comp.binaries.apple2. Vince demarco@CPSC.UCalgary.CA