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, -ethanReceived on 2023-06-11 22:28:29
Archive generated by hypermail 2.3.0.