Thanks Mike, that must be the answer. I notice that the formatting process for an HD disk in an HD drive on the COCO fails after the first pass on the disk formatting run. That must mean - reading back to verify the format is failing.
So, hole "covered" tells the drive to write at 2x the speed! Interesting, and makes sense. and you are right, I am buying a couple of boxes of DD disks locally. On Mon, Mar 25, 2019 at 12:23 PM Mike Stein <mhs.st...@gmail.com> wrote: > The difference in coercivity between DD and HD 3.5" diskettes is actually > relatively small, ~660 vs. ~720 Oersteds, compared to the much larger 290 > vs. 660 difference of 5.25" diskettes. > > But the thickness of the coating is also different, HD being less than > half that of DD, and different materials are used with the HD having a > finer granularity. > > Nevertheless, you can usually get away with using HD diskettes at DD (with > the hole covered if using an HD drive), although it's not quite as reliable > as using the proper media, especially regarding long-term data retention > (probably because the lower DD write current makes them more susceptible to > being erased); even the other way around often works, i.e. a DD diskette > with a hole punched at HD, although this is even less reliable. > > Anecdotally it seems that 3.5" HD diskettes in general have become > somewhat unreliable, even used at HD, which may at least partially account > for folks having issues using them at DD. > > But I think we're missing the more important issue; the reason for all > these differences is to squeeze more bits per inch on a track; unlike > 5.25", 3.5" diskettes all have 80 tracks and run at the same 300 RPM, so of > course this means that data will normally be written and read at twice the > rate in HD mode (500Kbps) than at the DD rate (250Kbps). > > I assume that the CoCo controller only transfers data at 250Kbps whereas > with the HD hole uncovered the drive will expect to see data at 500Kbps > (and use HD write current) and I suspect that's why Steve's having trouble. > > 3.5" DD diskettes are still around; why not use the right media in the > first place. > > m > > ----- Original Message ----- > *From:* Kurt McCullum <ku...@fastmail.com> > *To:* m100@lists.bitchin100.com > *Sent:* Monday, March 25, 2019 11:02 AM > *Subject:* Re: [M100] question regarding floppy disks. > > Yeah that does sound strange. And I agree, the drive 'should' switch based > on the hole in the disk. Does it format to 720 or 1.44 when the hole is > covered? > > On Mon, Mar 25, 2019, at 7:37 AM, Stephen Adolph wrote: > > Kurt, agree with everything you have said. > > The odd thing is- > > * using an HD disk in an DD/HD drive, and covering the hole with tape, > would seem to be BAD > ---> because you are telling the drive to use the wrong current settings > for the actual disk media. > > However, this is apparently the way to make my system functional. > > so, strange. I would have thought it would be the opposite - let the > drive decide what current to use, matched to the "cookie". > > > On Mon, Mar 25, 2019 at 10:19 AM Kurt McCullum <ku...@fastmail.com> wrote: > > > The magnetic coercivity on HD disks is different than on regular disks. It > requires more energy to lay down the tracks. If you start with a blank HD > disk rather than a pre-formatted disk then you have a better chance. That's > because once the HD tracks are laid down, you need to erase them for your > new format. If your drive doesn't have enough energy to completely erase > the existing track, it wont work. 720k disks have a lower coercivity and > therefore work with either a 720k or 1.44mb drive. A 1.44 drive has a > sensor for the open hole and when it sees that hole, it will use a higher > level of write energy to properly work with the media. When that hole is > covered, it will use a lower level which is what the 720k media is looking > for. Though I do remember that formatting a 720k disk in a 1.44mb drive > didn't always work when going back to a 720k drive. > > Not sure about the Coco drive, but my TPDD2 does not work reliably with HD > disks. I have only been able to format one properly and it had data failure > shortly after. > > Kurt > > On Sun, Mar 24, 2019, at 6:32 PM, Stephen Adolph wrote: > > interestingly, > > Yes, if I take an HD disk, and tape over the hole to make it appear to be > a DD disk, then it works. > > But why? > > the floppy is capable of both formats... > > On Sun, Mar 24, 2019 at 7:39 PM Mike Stein <mhs.st...@gmail.com> wrote: > > > Have you tried closing the HD sense hole with a piece of tape or similar? > > ----- Original Message ----- > *From:* Stephen Adolph <twospru...@gmail.com> > *To:* m...@bitchin100.com > *Sent:* Sunday, March 24, 2019 6:08 PM > *Subject:* Re: [M100] question regarding floppy disks. > > the Coco is using it's standard controller > > When issuing the DSKINI 0 command the coco tries to format for 180kB. > > The combination of > (Coco, std controller, PC 1.44MB drive + a 720kB dd floppy) works > > whereas > (Coco, std controller, PC 1.44MB drive + a 1.44MBB hd floppy) does not work > > this is something I don't understand! > > > > On Sun, Mar 24, 2019 at 5:42 PM Gregory McGill <arcadeshop...@gmail.com> > wrote: > > likely the floppy controller doesn't support 80 tracks or high density.. > most of the controllers of the era are ds/sd 40 track or dsdd 40 track.. > are you able to format 720k? ds/dd 80 track? > > Greg > > On Sun, Mar 24, 2019 at 2:38 PM Stephen Adolph <twospru...@gmail.com> > wrote: > > I'll start by saying this isn't an M100 or TPDD discussion, but just > looking to understand something. > > I have a Tandy Coco3 with a 3.5 inch floppy drive. The drive is a > standard PC drive and it is working well. > > Seems though that I cannot use 1.44 MB floppies in that drive. They don't > seem to want to format. > > I really don't understand where the problem could be. > - the drive and the floppy are compatible > - the disk is known good and formats at 1.44MB in a PC > - if it can support 135 TPI, why can't it support 35 TPI? > > Does anyone know what's going on? > > thx > Steve > > > >