OS_Mv, Move bytes between stream and memory
Register parameters
IN:
BC = number of bytes to move (0 = indicates no data)
IX = handle of file (or device)
DE = 0, move data from memory, starting at (HL), to the file
HL = 0, move data from the file to memory, starting at (DE)
OUT, if call (perhaps partially) successful:
Fc = 0
BC = number of bytes not 'moved'
DE(in) = 0, HL points to next byte to read
HL(in) = 0, DE points to next byte to write
OUT, if call failed:
Fc = 1
A = error code:
RC_EOF ($09), end of file reached at some stage
RC_HAND ($08), bad handle supplied in IX
RC_RP ($13), device is read-protected, eg. :OUT.0
RC_ESC ($01), escape, if device :COM.0, :PRT.0, or :INP.0
RC_SUSP ($69), suspension if device is :COM.0, :PRT.0 or :INP.0
RC_DRAW ($66), redraw screen, if device is :INP.0
RC_QUIT ($67), kill request, if device is :INP.0
Registers changed after return:
......../IXIY same
AFBCDEHL/.... different
Notes
If both HL and DE are zero or they are both non-zero then the operation of this call is undefined.
Bugs
OS_Mv on files previously opened with GN_Opf, OP_UP: When residing in the last 62 byte sector (or the first sector) of the current file, when OS_Mv call completes, the adjusted file pointer of OS_Mv also becomes the new EOF - and content up until the 62nd bytes of the current sector will be truncated. This bug exists in all OZ versions, V2.2 - V4.7. This bug is fixed in OZ V4.7.1 and newer releases.
An example to illustrate the problem:
File size is 40 bytes, the current file pointer is set at position 28, OS_Mv is executed to write 2 bytes, which results in new file pointer becoming position 30. Due to the bug, the rest of file contents until position 40 is lost (truncated).
Related calls
GN_Cl, close file
GN_Del, delete a file from memory
GN_Opf, open file/resource (wildcard search)
GN_Ren, rename file
OS_Cl, internal close (OZ usage)
OS_Del, file delete (internal OZ usage)
OS_Frm, file read miscellaneous
OS_Fwm, file write miscellaneous
OS_Gb, get byte from file (or device)
OS_Gbt, get byte from file (or device) with timeout
OS_Op, internal open (OZ usage)
OS_Pb, write byte to file, device
OS_Pbt, write byte to file, device with timeout
OS_Ren, file rename (internal OZ usage)
Register parameters
IN:
BC = number of bytes to move (0 = indicates no data)
IX = handle of file (or device)
DE = 0, move data from memory, starting at (HL), to the file
HL = 0, move data from the file to memory, starting at (DE)
OUT, if call (perhaps partially) successful:
Fc = 0
BC = number of bytes not 'moved'
DE(in) = 0, HL points to next byte to read
HL(in) = 0, DE points to next byte to write
OUT, if call failed:
Fc = 1
A = error code:
RC_EOF ($09), end of file reached at some stage
RC_HAND ($08), bad handle supplied in IX
RC_RP ($13), device is read-protected, eg. :OUT.0
RC_ESC ($01), escape, if device :COM.0, :PRT.0, or :INP.0
RC_SUSP ($69), suspension if device is :COM.0, :PRT.0 or :INP.0
RC_DRAW ($66), redraw screen, if device is :INP.0
RC_QUIT ($67), kill request, if device is :INP.0
Registers changed after return:
......../IXIY same
AFBCDEHL/.... different
Notes
If both HL and DE are zero or they are both non-zero then the operation of this call is undefined.
Bugs
OS_Mv on files previously opened with GN_Opf, OP_UP that are less or equal to 63 bytes length: Issuing a GN_Cl (close file) just after a OS_Mv, the file contents will be truncated into rubbish from the current file pointer and onwards (to the end of the file).
Related calls
GN_Cl, close file
GN_Del, delete a file from memory
GN_Opf, open file/resource (wildcard search)
GN_Ren, rename file
OS_Cl, internal close (OZ usage)
OS_Del, file delete (internal OZ usage)
OS_Frm, file read miscellaneous
OS_Fwm, file write miscellaneous
OS_Gb, get byte from file (or device)
OS_Gbt, get byte from file (or device) with timeout
OS_Op, internal open (OZ usage)
OS_Pb, write byte to file, device
OS_Pbt, write byte to file, device with timeout
OS_Ren, file rename (internal OZ usage)