[Coco] Issues with NitrOS9 build

[Gene Heskett]

On Sunday 26 January 2014 07:56:48 Bob Devries did opine:

> Gene,
> 
> I'm with you on that one.
> 
> I suggest an entry in rules.mak. That would mean just a single line
> change in rules.mak at build time to change the value to 5.25" or 3.5".
> 
> E.g. D80TRK=5
> or D80TRK=3

I think this is a good way to handle the makefile when building 
descriptors.

But the name change of the descriptor itself, cascaded through to the 
*.bl's supplied, should also change.

Something like:

d0ss35_5.dd for the ss 35 track (DNS=1, TYP=20) 5.25"
d0ds40_5.dd for the ds 40 track (DNS=1, TYP=20) 5.25"
d0ds80_5.dd for the ds 80 track (DNS=3, TYP=20) 5.25"
d0ds80_3.dd for the ds 80 track (DNS=1, TYP=21) 3.5"

repeat that sequence for /d1 and again for /d2

We could carry that on for those who have converted their controllers for 
the higher data rate that would allow the use of 3.5" HD disks, however I 
think that if the user is savvy enough to convert the controller, he should 
be savvy enough to handle that.

OTOH, now with drivewire, would there ever be enough users doing that, that 
they would need our help?  Personally I think not.  Its like my serial 
mouse, or my 2nd monitor which the driving code was excised from c080 by 
Boisy when he did the conversion of all that into vtio plugins.  Either of 
those, I suspect that I am the only one that ever used it on a daily basis.

The coco itself is, as I have preached incessantly about, very very 
seriously crippled in terms of I/O address space, more seriously on the 
coco3 than on the earlier 1 & 2's by stealing that $10 bytes for the gime 
ghost registers, and by the unforgivable use of $20 byte wide blocks just 
for its PIA's.

All of that should have been decoded to 4 byte wide CE signals, giving the 
ability to put 7 more blocks of I/O into each of the $20 byte wide blocks 
now being decoded in the coco.  A relatively simple scheme could be devised 
as a retrofit board by Mark, that would ship an active SCS signal out to 
the mpi, which in turn would allow a much larger and denser I/O cartridge 
to be designed.

A cart with 4 additional db9 based seriel ports comes to mind,  Using some 
other ACIA chip that actually supports the 7wire protocol OOTB, would be 
very useful.

Likewise, a 4 port parallel interface with all 4 having full latching and 
handshaking of the data transfers would also be handier than bottled beer.

But all that also needs drivers.  Drivers that take up space in the 
bootfile and which need system ram access to function.   We have the memory 
in the 512k and larger machines, but each driver would need its own entry 
point that would allocate, out of the system ram, its own 8k block of 
working memory, which in turn would need to be able to move its I/O data 
into public/system ram in order to talk to the rest of the system.  And it 
would need to restore the gime to the system gime image as it exits.

The allocate the 8k page of ram is a call that already exists in os9, I 
used it in myram.  And the call to do a block data move also exists but 
I've not timed it. But very much of that and nitros9 begins to see a speed 
hit AND runs out of available bootfile memory.  It all takes bytes of code 
to make it do that walk.  Code that takes time to execute, and code that 
takes up space in the bootfile.

As I see it, given 27 years to cogitate on it, the level 3 idea is a good 
one IF we can make it work with drivewire, but so far, I haven't been able 
to make it work even without drivewire.  Sigh.

And to top that off, I probably froze and broke one of my coco coffee cups, 
I left it in the truck last night, half full, and it got down to 4F.  
Bringing in 6 bags of vittles, I forgot to make one more trip thru nearly a 
foot of snow to collect it when I came in from the radio station.  That's 
sad as I will be down to only 1 left if its broken.  Forgetful old man, 
dammit.

> and based on that, the 80 track descriptors should be correctly built,
> and also the format command will select the correct DD.FMT value for
> LSN0 for 5.25" or 3.5" at the discretion of the user/builder.
> 
> More thoughts anyone?
> 
> Regards, Bob Devries
> Dalby, QLD, Australia
> 
> 
> 
> ----- Original Message -----
> From: "Gene Heskett" <gheskett at wdtv.com>
> To: <coco at maltedmedia.com>
> Sent: Sunday, January 26, 2014 6:42 PM
> Subject: Re: [Coco] Issues with NitrOS9 build
> 
> > On Sunday 26 January 2014 03:38:36 Bob Devries did opine:
> >> One more comment on the 3.5" vs 5.25" situation:
> >> 
> >> If I bring an image to my coco3, and copy it to a floppy, I can't
> >> then backup that floppy with my now existing NitrOS9 system without
> >> hacking the descriptors.
> >> 
> >> Why was this change made? I believe that the original OS9 used DNS=03
> >> and TYP=20 for 720K drives.
> > 
> > Correct, the 3.5" drive is DNS=1 TYP=21.
> > 
> > There may be makefiles to adjust yet.  But, while doing that, how
> > about we reename the *^$# descriptors to something that not only
> > tells the tracks, but also the inch size of the disk so folks can
> > more easily differentiate and pick the _right_ descriptor?
> > 
> >> Regards, Bob Devries
> >> Dalby, QLD, Australia
> >> 
> >> ----- Original Message -----
> >> From: "Tormod Volden" <lists.tormod at gmail.com>
> >> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> >> Sent: Sunday, January 26, 2014 5:42 PM
> >> Subject: Re: [Coco] Issues with NitrOS9 build
> >> 
> >> > On Sun, Jan 26, 2014 at 7:15 AM, Bob Devries wrote:
> >> >>> Gene explained (in detail) here on the list why no Coco >disk
> >> >>> should use DNS=3 except maybe the 5.25 80trk >720k disks(??).
> >> >> 
> >> >> Which is *exactly* what I'm using, and always have. I only very
> >> >> rarely use
> >> >> 3.5" disks, and in fact don't have such a drive connected now.
> >> > 
> >> > Bob, sorry for repeating myself, but did you try the JVC header I
> >> > suggested to you? I haven't seen your answer to this.
> >> > 
> >> > Tormod


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>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

We don't really understand it, so we'll give it to the programmers.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.