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

From: Bas Wassink <b.wassink_at_ziggo.nl>
Date: Mon, 12 Jun 2023 07:56:29 +0200
Message-ID: <16413470-ef3a-abfc-17a3-94a87c278eef_at_ziggo.nl>
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 ;))

--compyx
Received on 2023-06-12 09:00:02

Archive generated by hypermail 2.3.0.