[Coco] a not very important drivewire question

[William Astle]

There seems to be a great deal of confusion among people on the list 
about the "drive number" question being discussed.

The parameter test being discussed is the one for "DRIVE#n", *NOT* 
"DRIVEn". Furthermore, it is being discussed in the context of *drivewire*.

Drivewire allows 256 distinct "physical" disks on the bus, numbered 0 
through 255. (The disk number is an 8 bit value in the protocol.) Thus, 
*in the context of drivewire* there is no possible invalid 8 bit 
parameter to "DRIVE#n". Since the parameter is evaluated into B, there 
is no need to test it for validity in this context so the test can 
simply be removed. Again, this is in the context of drivewire.

Obviously, in a non-drivewire context, there is a clear need for the 
test. After all, there can only be 2 drives on an IDE bus and usually a 
max of 7 or 15 on a SCSI bus. Thus the code for doing the test cannot be 
removed from HDBDOS. It can, however, be eliminated when HDBDOS is built 
for drivewire.

None of this says anything about the number of virtual drives present on 
a particular physical disk. That test is a completely different one and 
is certainly applicable in the general case.

On 14-07-17 09:32 AM, Robert Gault wrote:
> Aaron Wolfe wrote:
>> Fwiw, there are printer operations built into the protocol and an os9 /p
>> module that uses them so programs can print without needing modification.
>> I don't know if hdbdos makes print #-2 work in basic, but it could
>> probably
>> be done fairly easily if not.
>
> At the moment, it does not seem to work but that is probably an artifact
> of DW4 not opening a file on the PC to receive the print data. When I
> open a file in Becker VCC, then I can get PRINT#-2,"text" to work.
> How should we tell DW4 what file to open and if necessary to flush the
> buffer? At the moment, PRINT#-2 and LLIST just freeze my Coco3 when
> using DW-HDBDOS.
>
>>
>> Is there a need for any check on the drive number?  It appears to be
>> stored
>> in the B register so there is no possible value that isn't a valid
>> drive.  ?
>
> Yes there is a need for a test. The question is not whether a drive is
> valid (aka possible) but whether it exists.
> On true hardware systems, ex. scii, you have a buss with numbers 0-7.
> Just because the buss and these values exist, there is no reason to
> believe there is a device attached to all of these buss entries.
> Likewise, just because a hard drive can have 256 Disk Basic partitions
> (aka drives) does not mean you have a hard drive with that much room
> assigned to Disk Basic. RGBDOS, now HDBDOS, was developed when hard
> drives were much smaller than they currently are. I have an old Tandon
> drive on my Coco system that was partitioned such that there are only
> eleven Disk Basic drives present.
>
> RGBDOS did a test on power up for that size of the drive and set an
> upper limit for Disk Basic. It did not test for devices attached to the
> buss but did limit what values you could use depending on the type of
> drive.
> HDBDOS also has limits on the buss because you don't want to accept a
> number larger than that with which the software or hardware can cope.
>
> Robert
>
>