[Coco] os-9

[gene heskett]

On Sunday, June 26, 2011 02:59:18 PM Mark Ormond did opine:

> Ok, I convinced him to take a double sided drive installed in the
> Fd500 enclosure, (So he can remove it and go back to original.)
> 
> Now my question is how do I copy os9/nitro os to real floppies after
> booting the os from drivewire?
> 
> Later,
> dabone
 
I have done this, not on drivewire, but from a nitros9 image downloaded to 
my coco's hard drive, but with drivewire, I see no reason why the src of 
the disk image can't just as well be one of the /Xn descriptors in a 
drivewire enabled boot.  Accessing /x0@ is the key and it works with dw4 at 
least.

Here is dd.b09:
=========
PROCEDURE dd
DIM buffer(256):BYTE
DIM ipath,opath:BYTE
DIM count:REAL
DIM iname,oname:STRING[32]
INPUT #1,"sourcefile:",iname
OPEN #ipath,iname:READ
INPUT #1,"destination device:",oname
OPEN #opath,oname:WRITE
REM now reset lsn0 of target device
GET #ipath,buffer
PUT #opath,buffer
CLOSE #ipath,#opath
REM that should stop the disk change errors
REM by resetting os9's disk id data
OPEN #ipath,iname:READ
OPEN #opath,oname:WRITE
ON ERROR GOTO 10
count=0
WHILE NOT(EOF(#ipath)) DO
GET #ipath,buffer
PUT #opath,buffer
count=count+1
PRINT count
ENDWHILE
10 CLOSE #opath
CLOSE #ipath
PRINT
PRINT "bytes written:"
count=count*256
PRINT count
END
PROCEDURE dd
DIM buffer(256):BYTE
DIM ipath,opath:BYTE
DIM count:REAL
DIM iname,oname:STRING[32]
INPUT #1,"sourcefile:",iname
OPEN #ipath,iname:READ
INPUT #1,"destination device:",oname
OPEN #opath,oname:WRITE
REM now reset lsn0 of target device
GET #ipath,buffer
PUT #opath,buffer
CLOSE #ipath,#opath
REM that should stop the disk change errors
REM by resetting os9's disk id data
OPEN #ipath,iname:READ
OPEN #opath,oname:WRITE
ON ERROR GOTO 10
count=0
WHILE NOT(EOF(#ipath)) DO
GET #ipath,buffer
PUT #opath,buffer
count=count+1
PRINT count
ENDWHILE
10 CLOSE #opath
CLOSE #ipath
PRINT
PRINT "bytes written:"
count=count*256
PRINT count
END
===========

The initial LSN0 copy, close & re-open is an attempt to work around 
nitros9's penchant for discovering that because LSN0 is changed, a disk 
change event has occurred.  Sometimes it works, sometimes it doesn't.

The descriptor should already be dmoded to match the nitros9 image, and 
formatted too, but the nitros9 image itself is miss-constructed, and that 
may require using dEd, either on the image, or on the finished disk copy, 
to correct LSN0 bytes $10 and $41 (IIRC) to reflect that it really is a 
double sided 40 track disk.

I was going to use the currently configured dw4 install I just did this 
morning as an example, but because the only /Xn image it has mounted in the 
default install is BlackCaldron, and a free on it looks like this:
{t2|07}/DD/NITROS9:free /x0

"The Black Cauldron" created on: 2011/06/19
Capacity: 18,432 sectors (1-sector clusters)
16,626 free sectors, largest block 16,626 sectors

That plainly is not a 40 track DS image. In fact, dtype claims its a 400 
track SS image. And I do not have a disk with nos9 on it in 40TDS format 
that hasn't been fixed so I can verify the required changes.  However, 
careful reading of the RBF section of the os9 l2 manuals should clarify 
that.

This also isn't really fast even if it looks like it should be.  I believe 
the b09 interpretation is taking more time that an interleave of 3 allows, 
so the disk has to make at least a turn per sector copied.  I should have 
done it in assembly I guess, but was lazy.  I'll plea to that ;-)

But this should work in cases where backup doesn't.  I have used it many 
times to write an image I had sent to the coco's hard drive with minicom & 
sz, to make a floppy that I could then install from.

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)
A man's house is his castle.
		-- Sir Edward Coke