Transfer files to/from N* CPM image?

[allison]

Chuck Guzis wrote:
> On 21 Apr 2010 at 7:49, allison wrote:
>
>   
>> By null I meant if you read RDR: or wrote to PUN:  the data would go
>> to the bit bucket and not to any device.
>>     
>
> Exactly so.  If you have, for example, an Amstrad Joyce, there's 
> nowhere to send or receive the data, as there is no (standard) extra 
> port.  There's a printer, but that's a horse of a different color and 
> not serial at all.
>   
On some it's not there and others not present and that applies
to PRN:, PUN:, RDR:.

On systems I build and play with the BDOS is often a fresh assembly
rather than an old image and the first fix is to make punch and reader
call table handle them as NUL (move data to A and return no error).
That prevents hangs needing reset or a timeout loop in the driver
that takes forever.
> But I've also seem (and been guilty of one or two) CP/M 
> implementations that completely ignore implementing IOBYTE, so that 
> any attempt at redirection using STAT fails.  If all you have is a 
> memory-mapped console display and integrated keyboard and printer, 
> IOBYTE makes little sense for most applications.  I suppose one could 
> implicitly redirect RDR to the keyboard, again, it makes little 
> sense.
>
>   
I've also done that.  That means all devices are console
or null.

However I find implement the console portion of IObyte
is handy as that can easily make the console redirectable
at both input and output level.  That works well on NS as
there are two SIO and printer(or some parallel thingie.
> PIP has a couple of device names that most CP/M implementations are 
> meaningless (INP: and OUT:) and many others (e.g. UC1:, CRT:) that 
> are known only to PIP.
>
>   
IN and OUT are devices internal to a patch area of pip
and makes it easy to create "pipmodem".  The others
the BIOS can work with if IObyte is implmented.

Why do IObyte?  Because it makes CP/M IO programatically easy
and sidesteps all of the problems of IO hangs.

  Simple file printer:

      Get command line
      Open file(s) to print
      set IObyte console to point to printer device for OUTPUT
      transfer file
      on EOF reset IObyte to previous setting.
      exit.

   simple terminal program:

       DO
        test constat and fetch conin byte if present
        flip IO byte
        output char to conout
        test constat   and fetch conin byte if present
        flip IO byte and output char to conout
       while conin not "CTRL-C"
       exit.

The drivers for logical conin, conout and constat can be pointed to the 
logical
devices enumerated in the IObyte field bits and an point to one of 4
devices or device combinations, same for Punch, Reader, and LIST
bit fields.  This can be controlled from user via STAT.  It's easy enough
to create an ASSIGN tool to modify IO byte as well as we are talking
about a single byte at 0003H and maybe in the BIOS if user want it to
remain across boots. 

Likely overkill answer but it's often annoying to see CP/M 
implementations that
leave out very useful bells and whistles.


Allison

> --Chuck
>
>
>
>