[Coco] NitrOS-9 V03.02.00 Released

[Gene Heskett]

This reply is NOT in timeclock order!

On Wednesday 10 December 2003 22:09, David wrote:
[...]
>> >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.

I knew that,  Apparently it watches the ready line as a disk change.
[...]
>> >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,'
>
>Yes, I guess it would.  I do believe that I did do some os9 copy'ing
>directly to the floppy.  However, it might be safer to simply use
> the os9 copy,dsave, commands on a .dsk image, and then dd the image
> to the floppy.  You'd have to do a fdformat on the floppy, but you
> wouldn't need to os9 format /dev/fd0, since the format info would
> be overwritten by the dd anyway.  "fdformat" just does a low-level
> format, which would be all you'd need.

And fdformat reports that its doing a 9 sector, eg 512 byte sector, 
format.  fdformat apparentlly reads the existing format from the 
disk, and sets itself to whatever format it was previously, 
over-riding you setfdprm attempts.  Or something similar, disallowing 
the attempt to reformat to a different style.

>Hmm...  I just played around with my setup.  I just copied a file to
> the floppy and then copied it back and did a cmp on the files and
> they were identical, so it _does_ work.

I'd assume you have an older chipset on your mobo then.

>One note.  On the os9 copy, you probably have to specify a filename
> for the destination.  I.E.  "os9 copy testfile.txt
> /dev/fd0,testfile.txt"
>
>Again, you don't want to _COPY_ a .dsk image to a floppy.  All you'd
> get would be a copy of the .dsk file.  You have to "dd" it to make
> an actual floppy of that image.

And, if the .dsk file is truely an image, you'd need an extra track to 
handle the directory entries and fd sectors when its made into a 
file, so the disk would be full before the 'copy' was done. OTH, 
these .dsk images aren't the whole disk, just from the start to the 
end of valid data!

>> 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.
>
>Unless you are running an extremely new chipset, I doubt if that's
> the problem.

Its the Nat-Semi SuperIO chipset, on a biostar M7VIB, about 2.5 years 
old now.

>  I think it's either in your configuration or your
> command syntax.  Note the above.  FWIW, here's the coco-specific
> entries in my current /etc/mediaprm.  The names were originally
> different, but when I upgraded my system, this was the file that
> came with the update, and these were the entries that were already
> there, so I left them.  Note that the setfdprm mnemonic names
> (COCO1, for example) are
>case-insensitive -- I.E, you can enter it as "coco1" just as well.
>
>"COCO1":
> SS DD sect=18 cyl=35 ssize=256
>
>"COCO2":
> SS DD sect=18 cyl=35 ssize=256
>
># TRS-8- Color Computer os9 formats (to be confirmed).
>
>"COCO360":
> DS DD sect=18 cyl=40 ssize=256 tpi=48
>
>"COCO720":
> DS DD sect=18 cyl=80 ssize=256 tpi=96
>
Thanks, that wasn't quite what I had.  I'd edited mine to add the tpi 
stuff now.  And added 2 more lines for 40 and 80 track 3.5 inchers at 
135 tpi.  They seem to work in that there are no errors reported.

I fdformatted a disk to coco3.5dd (thats the 40 track 135tpi version), 
then:
[root at coyote nos96309]# dd if=nos96309l2v030200_ds40_1.dsk of=/dev/fd0 
bs=256
1326+0 records in
1326+0 records out

Humm, not enough records to fill the disk???  Disk is 1440

[root at coyote nos96309]# dd if=/dev/fd0 of=test bs=256
1440+0 records in
1440+0 records out

Which is correct.

[root at coyote nos96309]# md5sum nos96309l2v030200_ds40_1.dsk
b0c657d6e06bf90e0b530c4d5ed893b8  nos96309l2v030200_ds40_1.dsk

[root at coyote nos96309]# md5sum test
db0a0be18821109dae8c8e474551cd5c  test

Now, look at this:
[root at coyote nos96309]# cmp nos96309l2v030200_ds40_1.dsk test
cmp: EOF on nos96309l2v030200_ds40_1.dsk

which indicates no changes were detected before the EOF on the .dsk 
file.  I'll go see if the coco can read it, brb.

---------SUCCESS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  I can read every 
sector of that 1440 sector disk with ded.

Now see if I can do the same thing with the 2nd .dsk image...
And that seems to have worked, for here anyway:
root at coyote nos96309]# setfdprm /dev/fd0 coco3.5dd
[root at coyote nos96309]# fdformat /dev/fd0
Double-sided, 40 tracks, 9 sec/track. Total capacity 360 kB.
Lies like a rug, doesn't it^^^^^^^^^
Formatting ... done
Verifying ... done
[root at coyote nos96309]# dd if=nos96309l2v030200_ds40_2.dsk bs=256 
of=/dev/fd0
627+0 records in
627+0 records out
[root at coyote nos96309]# dd if=/dev/fd0 bs=256 count=627 of=test.disk2
627+0 records in
627+0 records out
[root at coyote nos96309]# md5sum nos96309l2v030200_ds40_2.dsk
7471977f814e1b726adb8addbf60794f  nos96309l2v030200_ds40_2.dsk
[root at coyote nos96309]# md5sum test.disk2
7471977f814e1b726adb8addbf60794f  test.disk2

Even the md5sums check!  So at this point, I'd suspect its readable on 
the coco.  But I got up early to let the dog out, and need more nap 
time.  Many thanks for listening and for the hints on mediaprm, it 
appears that somehow adding the tpi= made it work.  AND that fdformat 
is a bad dog, and lies like a rug!

>> 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.
>
>What system is this?  Some of the latest release?

CoCo3/63C09 equipt, Nitros9, HDB-DOS, TC^3 scsi controller, an mpi, a 
Disto 4n1 thats had the scsi stripped from it now, and a 1gig drive, 
setup half for basic as virtual floppies, several hundred of them, 
and half for os9, or about 500 megabytes.  It boots nitros9 from 
virtual floppy 128 on the hard drive at the moment, but the tools to 
allow me to quickly change the bootfile were accidently left off when 
it was reinstalled.

All of this folderol is my failed attempts to get either a sneakernet 
path using floppies from here to the coco, or a terminal base path so 
I can send the latest release to it and install it.

>> 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.
>
>Yes, These need to be fixed.  The /w? descriptors need to be fixed.

Yes, well, if I took the time to look up the appropriate xmode 
commands, I'm sure I could incorporate that into the startup script 
too.  But having a shell buffer limited to about 100 chars is a major 
PITA too, as I have to break the xmode commands to fix the seriel 
port up into 5 pieces to keep from overflowing the buffer and getting 
a reject message with a crap character or two on the end of one of 
the vars.  I should load and link xmode until I'm done with it I 
guess as that would speed up the last 30 seconds of the boot quite a 
bit.

>> Anyway, I got that so I can type text back and forth between here,
>> using minicom, and there, useing supercomm.
>
>Why don't you just use "login" on the coco, and log in as a
> terminal. Does supercomm use its own zmodem?

Yes/no, 2.3a at least does, in that it can do the automatic part of 
the zmodem protocol trigger and launch rz with the correct options 
when it receives the *B0000000000000000 string from the "modem".  
Using rz/sz from the command line times out by the time I get to the 
other end to start the transfer its listening for.  Flight of stairs 
to climb and half the house to play broken field running through to 
get here.   The rs-232 cable itself is about 25 feet, through a hole 
in the floor...

It also appears that the launch syntax for linux is quite a it 
different as it has no provision to pass the device to use to it, and 
one must use the bash <> redirection, something I'm not sure works 
100%.

>  If you used login,
> you could use the rzsz programs.  I'm not sure what size blocks
> they support.

For the versions for the coco/os9, 256 is max.  I'm the one that 
compiled what you are running, from version 3.16 on to 3.36, the last 
one I did.  3.24 and onward contain some crc calc speedups I did that 
add about 150-200 cps to its max speed.  Its still no speed demon, 
730-40 cps on a nitros system, middle 500's on a 6809 system.  9600 
baud at the interface though, its just exersizes the cts/rts lines a 
lot.

>> Next I found that sz uses a 1k block size by default in the linux 
>> version, but the coco/os9 version is hard coded to a max 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 wish 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.

I've since found its much more stable if run from an initlevel 3 bash 
screen, as opposed to a shellterm in X.  But its most certainly NOT 
equal to Olaf Barthel's Term-4.7 on the Amiga.  Thats the standard 
against which ALL others should be compared.

Just don't try and switch in and out of X if you are using the NVidia 
drivers for your GForece2, then its crash and burn time for the whole 
machine. :(

>I've not had much trouble with minicom logging onto the OSK box.  I
>think I've used login on the coco, but it's been a long time if I
>did.

Do you recall the syntax to put in the startup to launch a login 
against /t2?  Its probably in the book someplace I suppose, but like 
you, its been at least 3 coons ages since I last tried that just to 
see if it worked, and I was running level one v2 on a 64k old grey 
ghost coco then!

Actually, for rzsz on the coco, any old shell can launch a session, 
its the "stair climbing timeouts" that will eat your lunch.

[snip]

Thanks for the flowers.

-- 
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.