Differing file input behaviour in TI BASIC and XB

[pixelpedant]

This is probably something very rudimentary, but I can't seem to figure it out.  I've got a DIS/FIX 120 file, called PATS. 

 

PATS

 

In console BASIC, the effect of the following

 

10 OPEN #1:"DSK1.PATS",FIXED 120
20 INPUT #1:PAT$
30 PRINT PAT$
40 PRINT LEN(PAT$)
50 CLOSE #1

is to print the content of the first record and report its length as 120.

 

In XB, the observed behaviour is to read nothing into PAT$ and report its length as 0.

 

What difference am I missing, which results in this difference in behaviour?

 

 

[+FarmerPotato]

Hmm, the XB manual indicates that this opens the file with defaults SEQUENTIAL, DISPLAY, and UPDATE.

 

This should be non-destructive until you PRINT #1.

 

I made a 1-record file in TI BASIC and ran the above. I got the same result in BASIC or XB right after that. So I'm not sure what's going on with your program? Is it really there when you run it in XB?

 

If you don't intend to change the file, you should open it as INPUT. I've only used UPDATE when I also use RELATIVE and

INPUT #1,REC X:A$

PRINT #1,REC X:A$

and so on.

 

Having a file open with UPDATE and SEQUENTIAL is awkward. You can input a record, but print over the next record. You can RESTORE #1 to the start of the file to rewrite it I guess.

 

It's been 30+ years since I wrote any XB so I could be missing something.

 

[pixelpedant]

I observe the same behaviour from 10 OPEN #1:"DSK1.PATS",INPUT,FIXED 120. 

 

Moreover, since console BASIC can "see" the data (and so can TI Image Tool and TI99Dir), I'm able to copy it over to a file opened in another format, like this

10 OPEN #1:"DSK1.PATS",FIXED 120
15 OPEN #2:"DSK1.PATS2",VARIABLE 128
20 FOR X=1 TO 3
25 INPUT #1:PAT$
30 PRINT #2:PAT$
35 NEXT X
40 CLOSE #1
45 CLOSE #2

But the resulting new file exhibits the same behaviour.  Readable in BASIC.  Unreadable in XB. At least all the ways I'm trying to.  I feel like it has to be something to do with the data. 

 

Are any value sequences not permitted in a DISPLAY record, such that they would be seen as an EOF or EOL or something along those lines?

[pixelpedant]

Hypothesis: it has to do with how null bytes are handled. 

 

The following program writes, then reads, four strings to file, with the strings consisting of

 

1) Entirely Null bytes

2) Null bytes, followed by some non-null values

3) Non-null bytes, followed by null bytes

4) Entirely non-null values

5 OPEN #1:"DSK1.NULLS",OUTPUT
10 NULLS$=CHR$(0)
15 NULLS$=NULLS$&NULLS$&NULLS$&NULLS$&NULLS$ 
20 PRINT #1:NULLS$
25 PRINT #1:NULLS$&"XYZ"
30 PRINT #1:"ABC"&NULLS$
35 PRINT #1:"ABCDE"
40 CLOSE #1
45 OPEN #1:"DSK1.NULLS",INPUT
50 FOR X=1 TO 4
55 INPUT #1:VALS$
60 PRINT LEN(VALS$)
65 NEXT X

In Extended BASIC, its output (consisting of the length of each string, read from file as input) is:

 

0

0

3

5

 

While in Console BASIC, its output (consisting of the length of each string, read from file as input) is:

 

5

8

8

5

 

That is to say, Extended BASIC treated records either beginning with or consisting exclusively of nulls as a null string, and also ignored trailing nulls, while TI BASIC returned the entire content of the record in each case.

 

[Tursi]

Yeah.. BASIC wasn't really intended to deal with binary data...

 

Still, your results surprise me.

 

[pixelpedant]

Yeah, I suppose CALL SPGET (in XB) generates variable data containing null bytes, but it is impossible for these to occur at the beginning or end of a pattern.  And allophone data from the text to speech engine (via the Text-to-Speech Disk or TE2) contains no null bytes whatsoever (meaningful values ranging from 1 to 255).  So I can't think of a circumstance where this distinction in behaviour would have practical implications, where "intended functionality" goes. 

[+Torrax]

4 hours ago, pixelpedant said:

This is probably something very rudimentary, but I can't seem to figure it out.  I've got a DIS/FIX 120 file, called PATS. 

 

PATS 640 B · 4 downloads

 

In console BASIC, the effect of the following

 

10 OPEN #1:"DSK1.PATS",FIXED 120
20 INPUT #1:PAT$
30 PRINT PAT$
40 PRINT LEN(PAT$)
50 CLOSE #1

is to print the content of the first record and report its length as 120.

 

In XB, the observed behaviour is to read nothing into PAT$ and report its length as 0.

 

What difference am I missing, which results in this difference in behaviour?

 

You need to use:

20 LINPUT #1:PAT$

 

And your example will work.  The XB ref-card description reads as "assigns data from the indicated file to string-variable".

 

Hope this helps.

[pixelpedant]

I do believe you're certainly correct, that LINPUT is the sensible route around issues with XB INPUT's parsing of DISPLAY data, in practice. 

 

Though the way INPUT just completely ignores any record which begins with nulls still strikes me as pretty weird.  And I'm glad I'm now aware of how INPUT deals with nulls, in general.  Not exceedingly useful information, I suppose.  But all information is worth having!

[RXB]

True that occurred to me the second I read the difference.

I use LINPUT much more often then INPUT due to imbedded characters like " (character 34) will just screw up a input command.

 

Extended Basic Manual page 113: "No editing is performed on what is input, so commas, leading and trailing blanks, semicolons,

colons, and the quotation marks are placed in string-variable as they are given."