[Coco] a not very important drivewire question
robert.gault at att.net
Thu Jul 17 11:32:55 EDT 2014
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.
More information about the Coco