[Coco] Need help with 3.5" drives and NitrOS-9

[Gene Heskett]

On Tuesday 03 December 2013 21:56:40 Robert Gault did opine:

> Willard Goosey wrote:
> > When the 6809 Nitros releases first started coming out with this $21
> > DNS setting for 3.5" drives I decided to ignore it because I have
> > approximately 100 dsdd 3.5" OS9 disks and I didn't feel like patching
> > them all. Much easier to patch the occasional descriptor.
> > 
> > I don't know what your driver is doing different but it's obviously a
> > software problem. Drive data rate is not tied to tpi. A 135 tpi DD
> > disk is written to at the same speed as a 48 tpi DD disk.
> > 
> > Willard
> > Sent from Samsung tablet
> 
> Willard,
> 
> That's what I found empirically and what Gene says; use 48tpi. The
> problem seems to be the way rb1773.asm is written which considers 96tpi
> and 135tpi to be treated the same and differently from 48tpi.
> 
> In short we need to revise something. The easiest thing would be to make
> typ=$20 for both 5.25 standard OS-9 disks and 3.5" disks. But if that
> were done, you would get misleading messages from the format command.

In what way, Robert?  Format should not care, it should either take our 
command line data as gospel, or the descriptors data if we don't give it 
any.
 
> It looks as if the optimum solution (if indeed there is one) for this
> specific problem would be to change rb1773 so that it changes behavior
> when it sees 96tpi somewhere in the descriptor but handles 48 & 135tpi
> the same way. Unfortunately there is no indicator for tpi but only 5.25
> and 3.5 inch disks. The size of the disk clearly is irrelevant while
> the track density is what is important.

That is in rbf.d, but again format should ignore that completely, as in a 
step to the next track is a single step until its hit the number of tracks 
we told it to format, or as spec'd in the descriptor for cyl, or the 
carriage hits a stop or the spindle.  That is generally non-destructive as 
it just gets pushed back to the previous track and the error isn't caught 
till the verify run and you wind up with a valid FAT for one track less 
than when it hit the stop or spindle.
 
> So now we are faced with two issues, backwards compatibility and badly
> written sections of rb1773/rb1773desc. While I hate to see bad code in
> NitrOS-9, I don't see a solution that does not involve individual
> tweaking of the descriptors or rb1773 by users.

Backwards compatibility with stuff previously formatted wrong can all be 
fixed with ded. Without losing data if its done right.  BTDT, about 100+ 
times.

> We need an executive decision on this or live with chaos. :) Who wants
> to decide in the absence of Boisy? :)
> 
 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

P-K4
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.