If I CD to a directory manually, FIND a data file with two numbers per line, INPUT A,B - the first two numbers are correct.
However, the second INPUT A,B command done manually, results in the numbers in incorrect order.
Here are the commands:
PRI @5,19:"ADVENTURE"
FIND @5:1
INPUT @5:A,B
A
1
B
133488
INPUT @5:A,B
A
1641035
B
5
INPUT @5:A,B
A
92813
B
8
Here is the first couple of lines of the contents of the /ADVENTURE/1 ASCII data file (each line is [CR] delimited:
DATA 1,133488,1,6771679,2,36315,2,8849417,3,4673330,4
DATA 1641035,5,1987117,6,234943,6,387847,7,7400652,8
DATA 92813,8,249958,9,9462081,10,2517217,11,7523733,11
DATA 7763223,12,1512460,13,8969927,14,7412167,14,12721
You had asked before whether the "DATA" in the file above would interfere with INPUT of the variables.
Here is page 10-22 of the BASIC Reference showing how Text is ignored in extracting a VALue from a string:
The Emulator should continue reading from the same line if the contents have not been consumed.
It appears the Emulator is reading the second line to satisfy the second INPUT command and the third line to satisfy the third INPUT command.
I think the FIND command is not terminating properly, because I wrote a program to run all the test commands above and the program generates an error on the line number with the FIND command and stops the program execution.
Likely the Tektronix must timeout on the GPIB bus condition if the FIND command is typed individually.
I may have been able to capture the FIND command typed manually:
Here are the waveform and trace listings:
BAD_FIND.zip (1.98 kB - downloaded 31 times.)
Sorry the columns are in a different order in my latest trace listings, I eliminated the SRQ signal - which appears to be mysteriously wiggling in the trace. I also eliminated the STATUS bits which included the SRQ pin. Maybe the emulator is not setting the SRQ to output mode - or is initializing it as zero?