That is understood. EOI is sent only when the end of the file is reached. I did some work on PRINT and INPUT as they are reciprocal and for working with text data files. I have PRINT writing raw data to file on the SD card and I think I may have nailed the problem with INPUT causing the Tek to get stuck and requiring a BREAK. In addition to asserting EOI at the end of the file, it also has to send the EOF character (FF). That signals the Tek to end the transmission with UNT and UNL, otherwise it just sits there expecting more data. What I still don't have is variables being read back correctly. For example:
PRINT@5:A$,B
INPUT@5:A$,B
I expected this would write a string and a number to an ASCII data file and read it back, but A$ ends up containing the string with the number tacked on to the end. I notice from the tek 4050 Series Basic Reference, that the PRINT command makes use of formatting options using the USI and IMAGE commands. The text states that the format string optionally "can be" specified in an IMAGE statement, but doesn't state whether formatting using the USI command is mandatory. I had experimented with the USING command to format the output of four variables which does work, but since there seems to be no corresponding command to format the variables for the INPUT statement, it all ends up in the first string variable anyway.
I'll break down your latest questions into individual replies.
You cannot PRINT a string AND another string or numeric variables in a single BASIC statement.
Tek BASIC strips the quotes from a string variable in all PRINT commands (to the screen or to tape or GPIB device), and then sends a CR to terminate that string.
PRINT is able to send multiple numeric variables in a single statement, and that operation will ALSO be terminated with a CR.
Consequently - the INPUT command from a file on tape or GPIB device ALWAYS has a CR and the tape or device returning the CR causes Tek BASIC to end the INPUT of the data. THEN Tek BASIC parses that buffered data for the variable(s) - either a single ASCII character string, or as many numeric variables as that INPUT command contains.
This PRINT/INPUT behavior will result in Tek BASIC hangs during the INPUT - if the variables cannot be parsed.
Example - I entered the following program into my 4054A:
100 A$="This is a test string"
110 B=532
120 FIND 13
130 PRINT @33:A$,B
140 CLOSE
150 FIND 13
160 INPUT @33:A$
165 INPUT @33:B
170 PRINT A$,B
180 END
I have attached my photo of the 4054A with the program list and results
Note that running this program resulting in Tek reporting EOF in line 165.
This is because the string and the number were printed to the tape, then CR terminated.
The line 160 input returned the string PLUS the 532, so if we did PRINT A$ we would see both the string concatenated with 532.
When Tek then tried to run line 165 - there was no more data in the file - and EOF was detected.
I then recalled line 160 and added the B to the INPUT, and I typed 165 with CR - which deleted line 165 and reran the program. That didn't fix the problem - since both A$ and B were PRINTed to the same line, and Tek BASIC requested more data from tape and got EOF.
Then I edited the line 130 PRINT statement to remove B, and added a line 135 PRINT statement to write the B separately.
Now running the program resulted in no hang or EOF and both the A$ and B printed.
As further proof - I loaded my TapeDump8 program into the 4054A (using serial), and did a dump starting with file 13, and my dump program continues until it reaches a LAST file.
The second photo attachment shows ALL the bytes in File 13:
I'm not sure why this dump shows two File 13 Header strings, I may not have downloaded my latest TapeDump8 program - since I didn't have my USB flash drive plugged in which DOES have the latest program.
I am using Notepad++ to display the dump file contents and have enabled viewing ALL characters including control characters.
Line 4 - the file header, CR terminated
Line 5 - a blank line filled with spaces - this is the remainder of the first tape file block of 256 bytes
Line 6 - A$ properly terminated with CR and no quotes
Line 7 - B ASCII printed numeric variables always have a leading space, and as the only numeric variable in that PRINT statement in the new line 135, it is CR terminated
Line 8 - the ASCII character 127 which is used as the EOF marker