Jump to content
brain

VARIABLE files on TI 99/4A

Recommended Posts

8 hours ago, brain said:

And, if you want to send an actual ':' in a field, how do you do that?

Enclose it in quotes. If part of another string, it is not a special character.

 

...lee

Share this post


Link to post
Share on other sites

Sadly, while cc40 BASIC will tokenize:

 

150 print#2,i : i^2

 

for example, it will not run.  And, when doing an input, cc40 basic expects the incoming data stream to the computer to be field separated by commas.  Thus, while we can potentially store files in the same way, the same approach in BASIC will not work.

 

How does one read multiple records in 1 line on the 99/4A?  On the cc40, it's input #2, a$,b$,c$ and so on

 

Jim

 

Share this post


Link to post
Share on other sites

On the 4A, I do not believe you can span records in a single INPUT statement. You just get an error if your input statement expects more data items than was read in the record. We are encouraged to put more than one value in a record. Using INTERNAL instead of DISPLAY, fields are strongly encoded and decoded without the ambiguities of being text..

 

in DISPLAY mode, PRINT #1:A,B,C  produces a record with a single value in it, the string that contains A B and C well formatted with the padding and spacing denoted by the ',' but the comma does not appear in that string. 

 

The 4A has a buffer of memory to hold the complete record for input or output, letting the application layer ( TI BASIC ) manipulate the data within the record. I can imagine that on a inherently serial platform the unit of input and output might be the 'register' or 'field' ... reading the TI-95 manual, it doesn't program like basic, but IO units seem to be a register ( single variable )  --- ( that is a big leap on my part from very high level documentation ) 

 

What is the unit of input and output for the CC-40's IO commands? I suppose it is in your code somewhere. 

Share this post


Link to post
Share on other sites
12 minutes ago, jedimatt42 said:

On the 4A, I do not believe you can span records in a single INPUT statement. You just get an error if your input statement expects more data items than was read in the record.

 

Actually, one INPUT statement will read values into all of the variables you want from a file until there is a type-mismatch error or EOF, no matter how many records it spans.

 

...lee

Share this post


Link to post
Share on other sites
59 minutes ago, brain said:

How does one read multiple records in 1 line on the 99/4A?  On the cc40, it's input #2, a$,b$,c$ and so on

 

You can read an entire record into a string with LINPUT, but you then need to parse the string into variables yourself. I do not believe you can read more than one record at a time with LINPUT, though I have not tried it.

 

Though INPUT can span records, if you do not INPUT all of a record with an INPUT statement not ending in a comma, I think (have not tried) the next INPUT statement will start at the beginning of the next record, missing the remainder of the previous record.

 

On a side note: The XB manual says on the page describing INPUT that a DISPLAY file cannot have more than 160 characters. I am thinking this may be wrong, but I have not checked.

 

...lee

Share this post


Link to post
Share on other sites
1 hour ago, jedimatt42 said:

On the 4A, I do not believe you can span records in a single INPUT statement. You just get an error if your input statement expects more data items than was read in the record. We are encouraged to put more than one value in a record. Using INTERNAL instead of DISPLAY, fields are strongly encoded and decoded without the ambiguities of being text..

 

in DISPLAY mode, PRINT #1:A,B,C  produces a record with a single value in it, the string that contains A B and C well formatted with the padding and spacing denoted by the ',' but the comma does not appear in that string. 

 

The 4A has a buffer of memory to hold the complete record for input or output, letting the application layer ( TI BASIC ) manipulate the data within the record. I can imagine that on a inherently serial platform the unit of input and output might be the 'register' or 'field' ... reading the TI-95 manual, it doesn't program like basic, but IO units seem to be a register ( single variable )  --- ( that is a big leap on my part from very high level documentation ) 

 

What is the unit of input and output for the CC-40's IO commands? I suppose it is in your code somewhere. 

On the cc40/ti74, the same thing occurs.  If you do print #2,a,b,c,d,e$ you will get the variables separated by spaces (aligned in columns if one uses the commas instead of semicolons) but no commas in the resulting data.

 

On the cc40, data is sent at the byte level, with minimal buffering.  Here is an output of the logs for the print#2, i;"'";i^2... statement

 

Write File
                                                                              
0000| 20 31 20 2c 20 31 20 2c 20 31 20 2c 20 2e 38 34 | 1 , 1 , 1 , .84|
0010| 31 34 37 30 39 38 34 38 20 2c 22 20 20 20 20 20 |14709848 ,"     |
0020| 20 20 42 52 41 49 4e 2c 4a 49 4d 22             |  BRAIN,JIM"    |
      

 

From an IO perspective, the data above is prepended by a 9 byte PAB block, that signifies the record boundary, but we are also using the comma to denote a boundary, to approximate the " : " of the 99/4a

 

Jim

 

 

Share this post


Link to post
Share on other sites
2 hours ago, Lee Stewart said:

 

You can read an entire record into a string with LINPUT, but you then need to parse the string into variables yourself. I do not believe you can read more than one record at a time with LINPUT, though I have not tried it.

 

Though INPUT can span records, if you do not INPUT all of a record with an INPUT statement not ending in a comma, I think (have not tried) the next INPUT statement will start at the beginning of the next record, missing the remainder of the previous record.

 

On a side note: The XB manual says on the page describing INPUT that a DISPLAY file cannot have more than 160 characters. I am thinking this may be wrong, but I have not checked.

 

...lee

I can understand 1 record per LINPUT.  Makes sense to me.

 

It would be nice to know if you don't input all of a record but then move to a new line number, if the counter advances to the next record or not.

 

Jim

 

Share this post


Link to post
Share on other sites
1 hour ago, brain said:

I can understand 1 record per LINPUT.  Makes sense to me.

 

It would be nice to know if you don't input all of a record but then move to a new line number, if the counter advances to the next record or not.

 

Jim

 

You mean like PRINT REC(17)

Share this post


Link to post
Share on other sites

Here’s my test program for this, in TI BASIC:

100 OPEN #1:”DSK1.TEST”,OUTPUT,INTERNAL,VARIABLE 254
110 PRINT #1:1,2,3,4,5,”CASEY”
120 PRINT #1:6,7,8,9,10,”CASEY”
130 CLOSE #1
140 OPEN #2:”DSK1.TEST”,INPUT,INTERNAL,VARIABLE 254
150 INPUT #2:A,B,C
160 PRINT A,B,C
170 INPUT #2:D,E,F
180 PRINT D,E,F
190 CLOSE #2

Results from running this program:

1        2

3

6        7

8

Edited by Casey

Share this post


Link to post
Share on other sites
3 hours ago, brain said:

It would be nice to know if you don't input all of a record but then move to a new line number, if the counter advances to the next record or not.

 

It does—as long as you do not end the INPUT with a comma.

 

...lee

Share this post


Link to post
Share on other sites

I should mention something that is kind of implied by @Casey’s last post regarding reading back (INPUT) data printed  to a file in DISPLAY (default) format. @Casey used INTERNAL format. If you use DISPLAY format with the same PRINT statement, the listed INPUT will not work because the PRINT did not store any field separators. You can think of PRINTing to a file in DISPLAY format as identical to PRINTing to a printer or the screen. The file record will look exactly the same, i.e., it is text for fields with only spaces separating them. Upon INPUT, XB will choke without separators (commas). You can mitigate this by outputting a comma (",") between field separators:

30 PRINT #2:I;",";I+1;",";I+2;",";I+3;",";I+4
  -or-
30 PRINT #2:I,",",I+1,",",I+2,",",I+3,",",I+4

or—just use INTERNAL format as  @Casey did. Of course, then you cannot easily view the file in a text reader. There are trade-offs. 🙄

 

...lee

Share this post


Link to post
Share on other sites
3 hours ago, Casey said:

Here’s my test program for this, in TI BASIC:

100 OPEN #1:”DSK1.TEST”,OUTPUT,INTERNAL,VARIABLE 254
110 PRINT #1:1,2,3,4,5,”CASEY”
120 PRINT #1:6,7,8,9,10,”CASEY”
130 CLOSE #1
140 OPEN #2:”DSK1.TEST”,INPUT,INTERNAL,VARIABLE 254
150 INPUT #2:A,B,C
160 PRINT A,B,C
170 INPUT #2:D,E,F
180 PRINT D,E,F
190 CLOSE #2

Results from running this program:

1        2

3

6        7

8

OK, for internal storage, I take away from this that the next input statement will advance the record number.  If it's possible for you to send the actual raw file it created, that's appreciated as well.

 

Jim

 

Share this post


Link to post
Share on other sites
2 hours ago, Lee Stewart said:

I should mention something that is kind of implied by @Casey’s last post regarding reading back (INPUT) data printed  to a file in DISPLAY (default) format. @Casey used INTERNAL format. If you use DISPLAY format with the same PRINT statement, the listed INPUT will not work because the PRINT did not store any field separators. You can think of PRINTing to a file in DISPLAY format as identical to PRINTing to a printer or the screen. The file record will look exactly the same, i.e., it is text for fields with only spaces separating them. Upon INPUT, XB will choke without separators (commas). You can mitigate this by outputting a comma (",") between field separators:

30 PRINT #2:I;",";I+1;",";I+2;",";I+3;",";I+4
  -or-
30 PRINT #2:I,",",I+1,",",I+2,",",I+3,",",I+4

or—just use INTERNAL format as  @Casey did. Of course, then you cannot easily view the file in a text reader. There are trade-offs. 🙄

 

...lee

OK, we were doing this (add in the commas) before, to create the field delimiter, in DISPLAY mode, but I was concerned it was wrong.

 

Jim

 

 

 

Share this post


Link to post
Share on other sites
2 hours ago, brain said:

OK, we were doing this (add in the commas) before, to create the field delimiter, in DISPLAY mode, but I was concerned it was wrong.

 

Pretty sure that never happened. Of course, I may well have missed it. If you mean the following

23 hours ago, brain said:

print #2:i;" : ";i^2" : ";sqrt(i)" : ";sin(i)" : ";"       test"

You are using ‘:’ as a field delimiter, which it is not. INPUT will choke on the first one it encounters unless your one and only INPUT variable is a string variable, in which case the entire record will be read in as a string.

 

BTW, the square root function is SQR( ), not SQRT( )—at least, that is the case on the TI-99/4A.

 

...lee

Share this post


Link to post
Share on other sites
2 minutes ago, Lee Stewart said:

 

Pretty sure that never happened. Of course, I may well have missed it. If you mean the following

You are using ‘:’ as a field delimiter, which it is not. INPUT will choke on the first one it encounters unless your one and only INPUT variable is a string variable, in which case the entire record will be read in as a string.

 

BTW, the square root function is SQR( ), not SQRT( )—at least, that is the case on the TI-99/4A.

 

...lee

You must understand I am talking about actions performed on the cc40, not the TI99/4A.

 

My point was that we have been able to denote the "fields" in the print statement on the cc40.  On the cc40, we were doing:

 

print #2, i,i^2 (and so on)

 

but, in DISPLAY mode, what is sent to the drive is:

 

1        1      (and so on).

 

In other words, a column-aligned set of fields, but no way to see if the original was 1 field or 2.

 

TO ensure the data was interpreted as fields on the cc40 drive, we modified the output to:

 

print #2,i;",";i^2;",";  ... and so on.

 

Then, the data comes through to the drive with the commas in the stream, analogous to your previous note #36 about putting the commas in manually. 

 

Currently, we are storing the commas in the file itself.

 

When the input #2 is executed, and we send the data with the commas in the data stream, the INPUT cc40 function parses the data into comma separated values and places them in their respective variables, assuming the correct type and no eof and such. 

 

And, it is SQR() on cc40 as well.  I was copying the program freehand and added the 'T'

 

Jim

 

Share this post


Link to post
Share on other sites

No prob—sorry, I must have had my nose too close to the screen—forest-and-trees problem, dontcha know.

 

1 minute ago, brain said:

And, it is SQR() on cc40 as well.  I was copying the program freehand and added the 'T'

 

Yeah, I don’t care to remember the number of times I’ve done that. SQR( ) should mean “square”, after all. The developers must not have had severe enough OCD. |:)

 

...lee

 

Share this post


Link to post
Share on other sites
16 minutes ago, Lee Stewart said:

 

 

You are using ‘:’ as a field delimiter, which it is not. INPUT will choke on the first one it encounters unless your one and only INPUT variable is a string variable, in which case the entire record will be read in as a string.

 

 

In the code you quoted of mine, I was asking if that line of BASIC was the proper way to delimit fields on the TI (The presence of the colon after the channel number marks it as TI BASIC, as cc40 requires a comma there.  A subsequent note indicated I had the syntax wrong, as it is print #2:i : i^2, but when I tried that on the cc40, it failed to run.  cc40 will not accept colons in between variables, so I could not emulate it.

 

Which is OK.  I thought, perhaps, when I thought the delimiter was " : " (with quotes), that we should use the " : " in our code as opposed to the "," we were using, but it appears in both cc40 and TI BASIC, separating fields in a single print statement is done by manually adding in commas between the data elements.  That was what we had in our code when I first asked the question here, which is why I said in my last note that it was where we started.

 

Jim

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...