Here is a comparison of floppy data capacity, historically speaking. IIRC: This is by memory, so I may have errors like # sectors vs tracks in 3.5 HD, but I'm pretty sure of the total capacities. Also, Apple 3.5 had variable sectors/track, average was 10. spt - sectors/track bps - bytes per sector tpd - tracks per disk s - sides (or heads) cap - capacity (bytes) and kilobytes format coding spt bps tpd s cap cap (k) standard 4+4 8 256 35 1 71680 70 Apple DOS 3.2 5+3 13 256 35 1 116480 113.75 Apple DOS 3.3 6+2 16 256 35 1 143360 140 Apple 40 trk (non-std) 6+2 16 256 40 1 163840 160 Apple SSDD3.5 DD 10 512 80 1 409600 400 Apple DSDD3.5 DD 10 512 80 2 819200 800 Apple DSHD3.5 HD 18 512 80 2 1474560 1440 SSSD5.25 4+4 8 256 35 1 71680 70 SSSD5.25 4+4 8 256 40 1 81920 80 DSHD5.25 HD 32 256 80 2 1310720 1280 SSSD5.25 4+4 9 256 40 1 92160 90 DSSD5.25 4+4 8 256 40 2 163840 160 DSSD5.25 4+4 9 256 40 2 184320 180 SSDD3.5 DD 9 512 80 1 368640 360 DSDD3.5 DD 9 512 80 2 737280 720 DSHD3.5 HD 18 512 80 2 1474560 1440 DSXD3.5 XD 36 512 80 2 2949120 2880 At its introduction, Apple's 13-sector format added almost 60% capacity over the industry standard. The 16-sector upgrade made it almost double. Impressive, for a while. Alas, while the rest of the industry went 40 tracks, double-sided, double and high density, Apple stood still. Also, by doing so much disk control in software, with critical timing, (as well as integrated video circuitry), you couldn't easily upgrade system performance by simply putting in a faster processor. IBM drives became fast and cheap with higher capacity, Apples remained slow and expensive and low capacity. With the 3.5 drives, Apple non-standard format added a more modest 25% capacity. But once again they fell behind when the industry went to high density. Lack of intercompatibility made file transfers between the two groups a pain in the butt. I believe that it should be possible to read and write SSSD5.25 disks (80k) with Apple II disk drives. This format was mainly used by some CP/M computers of that time. But it was also supported in early versions of PC-DOS/MS-DOS. I started work on such a project 20 years ago but never finished it. Sort of like my 384 vertical-line, interlace scan project for the ][+ and //e. I'm pretty sure I still have the working prototype for that somewhere in the basement. It was a simple design, and worked well but never got around to putting it into production. ----- Original Message ----- From: "Michael J. Mahon" Newsgroups: comp.sys.apple2 Sent: Friday, October 25, 2002 3:17 PM Subject: Interlaced Apple II video (was Re: Floppy Data Capacity) > Joel Buckley wrote: > > >Sort of like my 384 vertical-line, interlace scan project for the ][+ and //e. > >I'm pretty sure I still have the working prototype for that somewhere in the > >basement. It was a simple design, and worked well but never got around > >to putting it into production. > > Interesting. > > I assume that you page-flipped between hi-res page 1 and 2 during > vertical blanking and used a hardware technique to delay the start > of the even field by 1/2 line? > > More information would be very interesting. > That's exactly right. It seems so obvious, why didn't anybody else do it? With my Apple ][+, all the ic's we're socketed, so you could lift up a pin to jumper a signal out to a breadboard circuit and back. If memory serves (I haven't dug out my old notes) I tried several techniques. One was a hardware page flipping toggled by Vertical sync or blank and activated by an Annunciator output. While that was the most straightforward, it involved intercepting on board circuitry. A second technique was to run the VSYNC into the NMI and switch the pages via software. I used NMI rather than IRQ because of the monitor IRQ zero page bug. I had used 60 Hz into NMI before to have a real-time clock (good only while power was on). It was gated with an Annunciator output, because you had to turn it off on any disk access. (I used another output to control a relay for a telephone dialer. My old JCat modem didn't have any programmed dialing support.) It was easy to toggle the delayed VSYNC inside the Apple circuitry for my prototype. But if I had wanted this to be a practical project, you couldn't be running wires all over the motherboard. It would be more practical to extract the standard vsync from composite video out, create a delayed version, and then recreate the composite interlaced video. It would be a bit more complicated and I never got around to doing it that way. I made some demo graphic images, diagonal line with half the staircasing, etc. It looked good. It didn't work well with every monitor. With interlacing, you'd like 1/30 sec persistence. The regular Apple only needed 1/60th. I considered designing a card for the //e slot 7 to do it. This should be realtively easy because they brought out the composite video sync signal on pin 19 (strangely slot7 only). So you're saved the trouble of separating the sync from the composite video. I was disappointed that they doubled the horizontal resolution, and didn't take the little extra effort to double vertical as well. The video-overlay card supports interlace scan. Most of the time it was just used to line double the standard Apple video during video overlay. Though I remember seeing a demo, that used it to depict a 400 vertical line desktop. The ][+ was really a fun machine to tinker with. One person could understand every line of code in the operating system, and every piece of circuitry on the mother board. Those were the days! Joel wrote: >----- Original Message ----- >From: "Michael J. Mahon" >Newsgroups: comp.sys.apple2 >Sent: Friday, October 25, 2002 3:17 PM >Subject: Interlaced Apple II video (was Re: Floppy Data Capacity) > > >> Joel Buckley wrote: >> > >> >Sort of like my 384 vertical-line, interlace scan project for the ][+ and >//e. >> >I'm pretty sure I still have the working prototype for that somewhere in >the >> >basement. It was a simple design, and worked well but never got around >> >to putting it into production. >> >> Interesting. >> >> I assume that you page-flipped between hi-res page 1 and 2 during >> vertical blanking and used a hardware technique to delay the start >> of the even field by 1/2 line? >> >> More information would be very interesting. >> > >That's exactly right. It seems so obvious, why didn't anybody else do it? >With my Apple ][+, all the ic's we're socketed, so you could lift up a pin >to jumper a signal out to a breadboard circuit and back. >If memory serves (I haven't dug out my old notes) I tried several >techniques. >One was a hardware page flipping toggled by Vertical sync or blank and >activated by an Annunciator output. >While that was the most straightforward, it involved intercepting on board >circuitry. >A second technique was to run the VSYNC into the NMI and switch the pages >via software. >I used NMI rather than IRQ because of the monitor IRQ zero page bug. >I had used 60 Hz into NMI before to have a real-time clock (good only while >power was on). >It was gated with an Annunciator output, because you had to turn it off on >any disk access. >(I used another output to control a relay for a telephone dialer. My old >JCat modem didn't have any programmed dialing support.) >It was easy to toggle the delayed VSYNC inside the Apple circuitry for my >prototype. >But if I had wanted this to be a practical project, you couldn't be running >wires all over the motherboard. Actually, there were several products that used milled-pin sockets or small PC boards to tap/intercept/modify main board signals. I suppose there is a small upper bound on the number of such "daughter boards" that could be tolerated in one system. ;-) >It would be more practical to extract the standard vsync from composite >video out, create a delayed version, and then recreate the composite >interlaced video. It would be much easier just to knock out most of the first half-line of the vertical sync pulse (which is not serrated on an Apple). I would add back to the composite video on alternating fields, a signal which starts where the horizontal sync pulse would end and ends halfway through the line. If the signal were added with the same amplitude as the sync, the result would be a 1/2-line delayed vertical sync pulse every other field. It might be necessary to lengthen the end of the shortened vertical sync pulse to keep its total length nearly constant, but most modern monitors would probably sync stably without problems. A related issue is that each alternate field occurs 1/2-line later and then 1/2-line earlier, rather than always 1/2-line later in a standard video signal. This would probably result in the lines of the two fields not being equally spaced from each other, but could always be compensated by shifting the start of the delayed vertical sync slightly. The actual "knockout" pulse could be generated by an annunciator, assuming that solid "vapor lock" to the horizontal sync was achieved. It sould be possible to accomplish this within the vertical blanking interrupt routine. >It would be a bit more complicated and I never got around to doing it that way. >I made some demo graphic images, diagonal line with half the staircasing, etc. >It looked good. This would be a nice complement to the pseudo-double hi-res technique in which different color sets are used to plot points with 560x192 resolution. Of course, the a monochrome display is used, and the standard waivers apply about plotting points with different "color sets" in the same byte. This technique also cuts the stairstepping by a factor of two, particularly visible on nearly vertical lines. >It didn't work well with every monitor. With interlacing, you'd like 1/30 >sec persistence. The regular Apple only needed 1/60th. This would be another plus for a monochrome display, since they typically have a longer persistence phosphor. >I considered designing a card for the //e slot 7 to do it. This should be >realtively easy because they brought out the composite video sync signal on >pin 19 (strangely slot7 only). So you're saved the trouble of separating the >sync from the composite video. I was disappointed that they doubled the >horizontal resolution, and didn't take the little extra effort to double >vertical as well. The sync signal is dostributed to slot 7 because Apple intended it to be used to adapt the Apple output to different video standards--like PAL. >The video-overlay card supports interlace scan. Most of the time it was just >used to line double the standard Apple video during video overlay. Though I >remember seeing a demo, that used it to depict a 400 vertical line desktop. Actually, the VOC supports all the IIgs video modes! Interesting that no one has written any software to use it that way--to my knowledge. The simplest--read lowest chip-count--way to get the Apple II video generator on a card was to use the IIgs video generator. >The ][+ was really a fun machine to tinker with. One person could understand >every line of code in the operating system, and every piece of circuitry on >the mother board. Those were the days! Amen to that! In my opinion, computer hardware is personally interesting in proportion to how understandable and manipulable it is. Practically every personal computer since the Apple ][+ (including even the //e, with its increased integration, and the IIgs, with its overlayed kludges) has been less transparent and, therefore, less interesting to me. This is a general problem in the electronics field, since higher levels of integration have made most equipment unknowable and unmodifiable. I learned electronics by taking apart old radios and TVs and making new circuits out of the components. The complexity barrier has virtually closed that path to today's kids. ;-( And what is true in hardware is even more true in software. The Mac used to boast that the manuals required to understand it and its software weighed less than the computer. While this is certainly true for the 8-bit Apples, both the IIgs and the Mac fail the test pretty badly. -michael Check out 8-bit Apple sound that will amaze you on my Home page: http://members.aol.com/MJMahon/