SEQ file/PRINT# default line terminator CRLF in VICE?

Hello, all,

I'm dusting off an ancient project (updating previous work on FLOPTRAN
IV from Byte in 1980) and I'm running into something odd.

For convenience, I'm doing all my restoration work in VICE, not on
real hardware.  What I think I'm seeing is with disk files, to .d64 or
to the local filesystem, PRINT# is writing out CRLF, not CR, which is
bunging up reading the data back in as numbers (not strings).
Everything seems to work fine if I'm writing to virtual tape files
(.TAP), it's SEQ disk files that are odd.

From what I've been able to verify, the expectation in the Commodore
world is that just CR is the record terminator.  I can see how VICE
might write out CRLF for SEQ files stored on a local filesystem to be
more compatible with modern tools, but this happens even when writing
to files inside a .d64 container.

The program I'm working with writes out a set of byte values  that
then get read back in by the following loader program:

   10 open1:input#1,pc:print"begin at "pc
   20 input#1,a:ifa>=0thenpokepc,a:pc=pc+1:goto20
   30 print"end at"pc-1
   40 input#1,pc:ifpc<0thenclose1:end
   50 input#1,a:pokepc,a:input#1,a:pokepc+1,a:goto40

This is the original code from 1980.  It works on real machines and it
works on VICE with virtual tape.  It fails to read any records with
"?FILE DATA ERROR IN 20" if the OPEN is used to open a disk file
written by VICE with OPEN 1,8,8,"NAME,S,R", but it works if I strip
out the LF from those files.

Just to underscore the difference, here's a SEQ disk file written by a
BASIC program running under VICE:

    1 d=9
    2 input"filename";f$
   10 open8,d,8,f$+",s,w"
  100 print#8,"line 1"
  110 print#8,"line 2"
  120 print#8,"line 3"
  130 print#8,42
  140 print#8,"done"
  200 close8
  500 open8,d,8,f$+",s,r"
  510 input#8,a$,b$,c$,x$,d$
  520 printa$:printb$:printc$:printx$:printd$
  530 close8

$ hexdump -C testfile
00000000  4c 49 4e 45 20 31 0d 0a  4c 49 4e 45 20 32 0d 0a  |LINE 1..LINE 2..|
00000010  4c 49 4e 45 20 33 0d 0a  20 34 32 20 0d 0a 44 4f  |LINE 3.. 42 ..DO|
00000020  4e 45 0d 0a                                       |NE..|
00000024

I can force CR only by explicitly sending CR and using ; to prevent
the kernel from adding the EOL char:

    1 d=9
    2 input"filename";f$
    3 z$=chr$(13)
   10 open8,d,8,f$+",s,w"
  100 print#8,"line 1"z$;
  110 print#8,"line 2"z$;
  120 print#8,"line 3"z$;
  130 print#8,42z$;
  140 print#8,"done"z$;
  200 close8
  500 open8,d,8,f$+",s,r"
  510 input#8,a$,b$,c$,x ,d$
  520 printa$:printb$:printc$:printx :printd$
  530 close8

$ hexdump -C testfile-nolf
00000000  4c 49 4e 45 20 31 0d 4c  49 4e 45 20 32 0d 4c 49  |LINE 1.LINE 2.LI|
00000010  4e 45 20 33 0d 20 34 32  20 0d 44 4f 4e 45 0d     |NE 3. 42 .DONE.|

With that dive into it, is this CRLF vs CR something that's
controllable by an option?  I know why one might want CRLF by default
if working with modern platforms but I would prefer this work the same
way across all environments.

Another piece of the puzzle is I found a descendant of FLOPTRAN IV on
zimmers.net for the VIC-20 and it runs fine, but it explicitly puts a
CR and uses ; on all the PRINT# statements (and it works as expected
even in VICE).

I can change the loader code to just deal with the extra LF, but I'd
like to hear from anyone who knows specifically about VICE and SEQ
file implementation to comment.

Thanks for any observations,

-ethan