handle the REL file case where a P command positions behind the official end of a record.

[fachat]

a coment from VICE:

/* It appears that all Commodore drives have the same problems handling
    REL files when it comes to using the position option of the record
    command.  Normally when a record is selected, the drive firmware
    scan from the end of the record to the beginning for when a non-NULL
    byte is found.  When it finds it, this is considered the end of a
    record (for a read).  The problem is: what happens when you position
    the read pointer past this end point?  An overflow occurs in the
    read of course!  Since the calculated record length is much larger
    than it should be (but less than 256) the drive can read up to a
    whole block of data    from the subsequent records.  Although this is
    a bug (from my point of view), we have to try to emulate it.  Apon
    analyzing the 1541 code (the 1571 and 1581 have the same behavior),
    at $e170 (the subroutine for searching for the non-NULL is at $e1b5)
    the    overflow may not occur under one specific instance.  This is
    when the start of the record is in one block and the selected
    position places it in another block.  In this case, only a length of
    1 byte is set as the record length.  In all other cases, the length
    is set to 255 - position. */

IMHO: we should NOT emulate the overflow error. After all we're not a CBM DOS

[nils-eilers]

I disagree. Though we're not a CBM DOS, most applications running from a XD-2031 powered "drive" will expect to run on a CBM DOS. What is more, if there is any particular bug/feature in CBM DOS, there seems to be at least one application that relies on it.

[fachat]

Ok, let's revisit this if we have the first application that relies on it.