[Coco] NitrOS-9 V03.02.00 Released

[Gene Heskett]

On Wednesday 10 December 2003 18:05, David wrote:
>Gene,
>
>I'll add some suggestions
>
>On Tue, Dec 09, 2003 at 09:52:37PM -0500, Gene Heskett wrote:
>> On Tuesday 09 December 2003 21:15, Boisy Pitre wrote:
>> >On Dec 9, 2003, at 8:06 PM, Gene Heskett wrote:
>> >> That doesn't float either.  Error 214 in trying to write to a
>> >> disk that was just os9format'ed.
>> >>
>> >> --------------------
>> >> [root at coyote nos96309]# /root/bin/os9copy -help
>> >> Syntax: os9copy {[<opts>]} <srcfile> {[<...>]} <target>
>> >> {[<opts>]} Usage:  copy files
>> >> Options:
>> >>      -b=size    size of copy buffer in bytes or K-bytes
>> >> [root at coyote nos96309]# /root/bin/os9copy
>> >> ./nos96309l2v030200_ds40_1.dsk /dev/fd0
>> >> /root/bin/os9copy: error 214 creating
>> >> '/dev/fd0/nos96309l2v030200_ds40_1.dsk'
>> >
>> >Gene, you are using the wrong syntax.  It should be:
>> >os9 copy ./nos96309l2v030200_ds40_1.dsk /dev/fd0,
>> >
>> >The comma at the end is important.
>
>I'm not sure that this is the correct usage for "os9 copy", is it? 
> This would simply copy the .dsk image to a file on the floppy.  If
> you have a .dsk image you wish to put onto a "real" floppy, use dd.
>
>However, as Boisy pointed out, the comma is _extremely_ important. 
> The documentation is not really explicit to some of us more
> foggy-headed individuals - Boisy had to explain it to me.  The
> comma specifies that the name preceding it is an image "file", and
> that it is to be treated as an OS9 "image".  However, the device
> (/dev/fd0) can be treated as an image just as a file.
>
>> Humm, reformatted it, then:
>
>With fdformat first.  I believe Boisy already mentioned this, but
>fdformat will lie to you about the geometry, claiming it's 9(?) SPT
>regardless of the true geometry.
>
>One caveat for setfdprm.  I guess you are aware of this, but any
>parameters set by setfdprm are lost if you remove the floppy.  If
> you remove the floppy and replace it, you need to setfdprm again.
>
>> [root at coyote nos96309]# /root/bin/os9copy
>> ./nos96309l2v030200_ds40_1.dsk /dev/fd0,
>>
>> (thats all one command line above, word wrap you know) returns
>> instantly with no disk access being done and no error message.
>> Again, splitting the os9 and the copy up with a space like you
>> did:
>>
>> [root at coyote nos96309]# /root/bin/os9format /dev/fd0
>
>I believe you would need a comma after /dev/fd0 here, too (maybe
> not)

Putting a comma of the /dev/fd0 results in a copy of the .dsk file 
being put in /dev as 'fd0,'

>> [root at coyote nos96309]# /root/bin/os9 copy
>> ./nos96309l2v030200_ds40_1.dsk /dev/fd0,
>> bash: /root/bin/os9: No such file or directory
>>
>> ???????????????
>
>Is this where your os9 command is?
>
>> >> -----------------
>> >> So I rewrote them with dd again:
>> >> ----------------
>> >> [root at coyote nos96309]# dd if=nos96309l2v030200_ds40_1.dsk
>> >> of=/dev/fd0 663+0 records in
>> >> 663+0 records out
>> >> [root at coyote nos96309]# /root/bin/os9format /dev/fd0
>> >> [root at coyote nos96309]# dd if=nos96309l2v030200_ds40_2.dsk
>> >> of=/dev/fd0 313+1 records in
>> >> 313+1 records out
>> >> -------------
>> >> and then ran os9dcheck against the second disk. It munched
>> >> along for 10 seconds or so and segfaulted:
>> >> -------------------------
>> >> [root at coyote nos96309]# /root/bin/os9dcheck /dev/fd0
>> >> Volume - 'NitrOS-9/6309 Level 2 Disk 2' in file: (null)
>> >> $00B4 bytes in allocation map
>> >> 1 sector per cluster
>> >> $0005A0 total sectors on media
>> >> Sector $000002 is start of root directory file descriptor
>> >> Segmentation fault
>> >
>> >Strange.  I suspect dcheck read bogus data and freaked.
>>
>> Yup, all zeros in an fd sector.
>>
>> [...]
>>
>> > you're doing this on a 720K or 1.44MB 3.5" floppy drive?  I
>> > haven't had much luck with the 1.44MB on my Linux box making
>> > 720K disks that are readable on a CoCo.
>
>I don't think I've had any problems in this respect.  My /d0 on the
> coco is a 3.5 and I have made good boot disks on my Linux box.
>
>> One thing I haven't tried yet is to format it on the coco and
>> bring it back up for the copy op.  I'd be using a 5.25" drive but
>> ATM I'm out of drive power connectors in there, only 2 sets of Y
>> cables in there now.  But I did find another Y set in the basement
>> just now.  The drive is good, works just fine on the coco.  ISTR
>> the one time I had it hooked up, I could only format 512 byte
>> sectors.
>>
>> But first I'll format it as a 40 track ds dd on the coco and see
>> if this shi, ah chipset can read it.
>
>This should work, although it would be nice to not have to do this. 
> I like things to work as they should - and I believe they will when
> you get the syntax straight.  It's a little vague at first.

I got a message from someone who has experence with my chipset and 
writing bios. He says the superio chip set can indeed do this, its 
just not being properly configured by drivers/block/floppy.c.  So I'm 
working on that intermittently, attempting to setup additional 
entries in the disk format tables it contains that would match the 
os9 requirements.  So far, not much luck, even the debuggig I turned 
on seems to be going to /dev/null.

When that failed, I went downstairs and hacked into the startup script 
to make the /t3.dd thats in the os9boot file into a t2 that addresses 
my hardware, finding all sorts of bugs in the shell that I don't 
recall hitting before.  Bugs that make me break up what should be a 
one liner argument list to xmode into 5 seperate invocations of xmode 
to get it all set.

Then I found I can only iniz and use 4 of the dozen or so window 
descriptors in that bootfile too, bummer.  And only one of them is 
really usefull, the rest seem to be limited to 28 char wide active 
portions of the screen, and about 6 lines deep, on a 40x16 screen.

Anyway, I got that so I can type text back and forth between here, 
using minicom, and there, useing supercomm.

Next I found that sz uses a 1k block size in the linux version, but 
the coco/os9 version is hard coded to a mnax of 256 byte blocks.  I 
fixed that sz invocation up here to limit it to 256 byte blocks, but 
then minicom got a tummy ache (its a POS) and I'm going to have to 
reboot to get rid of it and the locks it has on /dev/ttyUSB0.

Gawd I wsh we had a term program for linux that actually worked like 
Term-4.7 on the amiga.  Maybe we do, and I just haven't found it.  
Anyway, I have now wasted another day with this and I have to get on 
my horse and ride.  We have a music session to go audit at a local 
supper club, a close friend of mine, and a funeral visitation to hit.  
A local teacher, 41, got tired while shopping down in star city, sat 
down to rest and died.  She had been waiting for a heart transplant 
and already had a pacemaker in to keep that one ticking, but I guess 
it wasn't enough.  To top that off, out of that whole family, all but 
one so far has died at about 40 for the last 2 or 3 generations.  And 
that one has worked for me for the last 19 years.

Wish me luck tonight, I feel like I need it...

-- 
Cheers, Gene
AMD K6-III at 500mhz 320M
Athlon1600XP at 1400mhz  512M
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.