On 6/11/23 22:28, Ethan Dicks wrote: > 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. Yes, CR should be the record terminator. VICE should do (and does) the same. There's also no option to change CR to CR+LF, if people want to change CR to CR+LF they'll have to use some external tool to do so. > 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 don't see this happening in x64sc or xvic with current VICE, I tried with True Drive Emulation (TDE) on, TDE off and filesystem device with both x64sc and xvic. When I use the `block` command in c1541 to inspect the block the file I've written to the .d64 I don't see any LFs, just CR as expected: c1541 #8> block 17 0 <# 8: 17 0> > 00 00 10 46 4F 4F 0D 42 41 52 0D 48 55 50 50 45 4C ;..foo.bar.huppel > 10 0D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ;................ When using `read "foo,s" foo-vic20 and use hexdump I don't see LFs either: $ hexdump -C foo-vic20 00000000 46 4f 4f 0d 42 41 52 0d 48 55 50 50 45 4c 0d |FOO.BAR.HUPPEL.| > > I can force CR only by explicitly sending CR and using ; to prevent > the kernel from adding the EOL char: <snip> That should not be required at all. > 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. As I mentioned, it isn't an option, and would actually be a lot of extra work and would only lead to confusion. > > 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 > Since I cannot reproduce this: what VICE version are you using and what OS are you running? Also, how do you extract the .seq files for hexdump? (please don't tell me you're using Dirmaster ;)) --compyxReceived on 2023-06-12 09:00:02
Archive generated by hypermail 2.3.0.