Tektronix 4924 Tape Drive Emulator

[WaveyDipole]

I made good progress - my other Tektronix computer is a model 4054A, I tried my minor edit to your 0.05.23 code (changed CS from 3 to 4 for my board to work) and got CD, FIND and OLD all to work!

I mentioned that I was using pin 3 a while ago but it a lot of ground has been covered since then and a lot of information exchanged! I ended up using pin 3 because pin 4 is used by default by the USBASP programmer I am using to upload the code to the 1284p and there is no means to change that. The code assigns pin 4 by default if it has not been defined. I will try to remember when publishing to keep the configuration at pin 4.

I can see how not being able to communicate with the SD card reader would have caused problems but what is a bit strange is why some of the functions still worked? I can understand CD working as it doesn't actually access the SD card, but the other functions do. OLD is a bit different to FIND in that it uses ifstream rather than file, but even so, both functions need to access the card for information. READ also uses ifstream and you did get something out of that even though it was only to the serial monitor screen. Weird. I still can't explain the LA output either.

Three tests:

• CD "ROOT" (PRINT @5,19:"ROOT"), FIND @5:1, OLD @5: then I listed a couple of lines of the program that was loaded
• CD "GAMES" (PRINT @5,19:"GAMES"), FIND @5:1, OLD @5: then I listed a couple of lines of the program that was loaded
• CD "ROOT" (PRINT @5,19:"UTILITIES"), FIND @5:1, OLD @5: then I listed a couple of lines of the program that was loaded

All three successful.

That is very encouraging.

FIND and CD also worked on my 4052 computer, but OLD resulted in a hang that required cycling power on the 4052 to clear.

As a possible explanation to the difference - the 4052 has a different ROM version AND discrete GPIB hardware compared to my 4054A which has a TI 9914 GPIB controller and therefore different GPIB code in its ROM.

One more difference - on my 4052 I had to disconnect power to the Emulator or the 4052 locked up and had to be power cycled with power to the Emulator disconnected, then I could power on the Emulator for testing.  I didn't have that problem on my 4054A - I powered the Emulator from a 5V iPhone charge cube, then turned on the 4054A without issue.

The original 4051 computer has completely different ROM code than either the 4052 or 4054 - so I think it is a good idea to check out the Emulator with all three Tektronix computers.  I don't have a 4051, but there are a couple of people in the facebook group that do.

Interesting that is should behave somewhat differently on each computer. I will see if I can find the manuals for the 4052 and 4054 and if the information is available, compare the GPIB sequences.

The READ command ONLY supports BINARY data, not ASCII data -

I got the same understanding from my perusal of the manuals. The ASCII code is probably superfluous in FIND.

I tried to edit your READ_one code to use it with the INPUT command 13 (6D hex) instead of READ 14 (6E hex), but you said the READ command was not sending data on GPIB yet.

Correct. From my reading of the manuals, a number of things have to come together here first before read can work:

1. as I understand it, FIND opens a file, CLOSE closes it. It is my understanding that requesting HEADER via the INPUT command will also open a file. Once a file is opened by FIND it can be accessed using other commands such as READ, WRITE, INPUT etc until closed by CLOSE or a new file is opened by FIND. FIND closes the previously opened file. Not sure whether the same applies to OLD as there seems no point holding the file open after the emulator has read the program, although a program can't a program be appended to or modified?

2. in READ, the binary data header needs to be implemented. The BASIC program does not send any information with the READ command to determine how many bytes to read. The number of bytes to read is determined by first reading the binary header. The header will have been created when writing the data into the file. The binary format "knows" nothing about BASIC variable types just how many bytes to read. I am trying to figure out whether a header is required for each item, i.e:

[header]value[header]string[header]string[header]value

Or whether one header would be required fro the group:

[header]value|string|string|value

The problem with the latter though is how to determine how long each string is? I therefore imagine it must be the former. Of course, it would be up to the BASIC program to correctly read back each item into the correct variable type. So if it writes the sequence A,B$,C$,D then it must also read back the same sequence into the same variable types INT,STR,STR,INT regardless of the actual letter designations used.

Also, regarding files in gerenral, what command is used to assign and save the file header information to a new file? I don't see a CREATE command or any other command for setting the file description?

Can you have the INPUT command 6D hex use the READ_one code (it can be renamed from READ_one to INPUT)?

After I test the INPUT command for getting ASCII data to the Emulator from ASCII PROGRAM or ASCII non-program (DATA, TXT or LOG) files, we can divide that section of code into INPUT (ASCII files only) and READ (BINARY DATA files only).

Yes, certainly I can do that and it does sound like a plan. I agree we should first concentrate on getting the ASCII part working. Am I correct in assuming that in ASCII DATA files, each item is delimited by a CR? I know that works for A$ which reads a string(and therefore up to CR), but what about reading a numeric value into B (i.e. an int)?

I'm excited by the progress: CD, FIND and OLD make LOTS of programs work on the Emulator.

INPUT will be needed to support ASCII data files and READ will be needed to support BINARY data files.
My port of Adventure to the 4052/4054 requires INPUT of ASCII data files - there are 55 DATA files!.
It also requires PRINT to save the Adventure game to a file.

Here is my 4054A running Adventure from a 4907 floppy disk (8-inch disk):

(Attachment Link)

Nice to hear that we are making progress. You have a working 8in floppy disk? The last time I saw one of those was in my workplace some 30 years ago and it was obsolete back then! The old defunct drives were massive even by 5.25 in standards.

[mmcgraw74]

The READ command ONLY supports BINARY data, not ASCII data -

I got the same understanding from my perusal of the manuals. The ASCII code is probably superfluous in FIND.

I think you meant the ASCII code is probably superfluous in READ.  I agree, we should take the ASCII code in READ and move it to a new routine INPUT.

I tried to edit your READ_one code to use it with the INPUT command 13 (6D hex) instead of READ 14 (6E hex), but you said the READ command was not sending data on GPIB yet.

Correct. From my reading of the manuals, a number of things have to come together here first before read can work:

1. as I understand it, FIND opens a file, CLOSE closes it. It is my understanding that requesting HEADER via the INPUT command will also open a file. Once a file is opened by FIND it can be accessed using other commands such as READ, WRITE, INPUT etc until closed by CLOSE or a new file is opened by FIND. FIND closes the previously opened file. Not sure whether the same applies to OLD as there seems no point holding the file open after the emulator has read the program, although a program can't a program be appended to or modified?

In order to access the tape file HEADER, you first send the FIND @5:X command for file X then INPUT @5,9:A$ to fetch the HEADER.  At this point the file itself cannot be accessed without doing another FIND @5:X command.

Yes, doing another FIND command does an implicit close on the previous open file.

OLD causes an implicit CLOSE of the file after the Tektronix interrupts the command or EOF is reached.

OLD always deletes the current program in memory before loading the new one.  APPEND does NOT delete the program in memory, but that file is appended (and replaces) a specific line number (typically a REM statement) in the current program and renumbers the lines in the appended file from that point.  There is no difference to the Emulator for OLD or APPEND - that's why it is the same secondary address for that command.

2. in READ, the binary data header needs to be implemented. The BASIC program does not send any information with the READ command to determine how many bytes to read. The number of bytes to read is determined by first reading the binary header. The header will have been created when writing the data into the file. The binary format "knows" nothing about BASIC variable types just how many bytes to read. I am trying to figure out whether a header is required for each item, i.e:

[header]value[header]string[header]string[header]value

Or whether one header would be required for the group:

[header]value|string|string|value

The problem with the latter though is how to determine how long each string is? I therefore imagine it must be the former. Of course, it would be up to the BASIC program to correctly read back each item into the correct variable type. So if it writes the sequence A,B$,C$,D then it must also read back the same sequence into the same variable types INT,STR,STR,INT regardless of the actual letter designations used.

The BINARY DATA file format is your first example - a two-byte header in front of EACH numeric or string variable including the data type and length.  No need for CR between BINARY data items, no need for quotes around string data items.

Also, regarding files in general, what command is used to assign and save the file header information to a new file? I don't see a CREATE command or any other command for setting the file description?

Typically, the tape file HEADER is created by the Tektronix during creation of a new file with the MARK command to the tape drive.  This is described in the 4050 BASIC Reference Guide 070-2056-02.  First FIND the file to replace with the file that will be MARKed NEW in the HEADER and created with the number of 256 byte blocks to satisfy the number of bytes requested in the MARK command.  Typically this would be done by a FIND to the LAST file.  MARK can create multiple files of the requested size at that point if desired.  BASIC will then automatically create a new LAST file after the NEW file(s) are created.  Typically it is the Tektronix that creates and modifies the HEADER.  There were utility programs written by Tektronix that could add comments and ensure that the rules described in the BASIC Reference Guide for HEADERs were satisfied (no numbers in the comment, no S in the comment at the location indicating a SECRET file, etc).

Yes, certainly I can do that and it does sound like a plan. I agree we should first concentrate on getting the ASCII part working. Am I correct in assuming that in ASCII DATA files, each item is delimited by a CR? I know that works for A$ which reads a string(and therefore up to CR), but what about reading a numeric value into B (i.e. an int)?

Not quite.  Tek BASIC supports several delimiters between numeric and/or strings in an ASCII DATA file.  The system reference page 12-2 shows the allowed delimiters in BASIC program statements - which also applies to ASCII data files: [Space, comma, colon, semicolon and quote].

I don't expect the Emulator to worry about delimiters for data boundaries in ASCII data files - the PROGRAM will dictate when the next data item is needed and the Tektronix will just hold off handshaking in the middle of a BASIC INPUT statement until the previous numeric or string variable has been processed, and the Tektronix will end the transaction when the INPUT statement is completed.  When the next INPUT statement is started, the Tektronix will initiate a new transaction, and so on.  The Emulator will continue to leave the file open until EOF, or a FIND or CLOSE command.

Also the "DATA" field in the file HEADER does NOT have to contain "DATA" and some ASCII data files have "TEXT" or "LOG" in that field.  So the only test needed in the Emulator is for the "P" in PROGRAM to distinguish between program files and all data files).

I'm excited by the progress: CD, FIND and OLD make LOTS of programs work on the Emulator.

INPUT will be needed to support ASCII data files and READ will be needed to support BINARY data files.
My port of Adventure to the 4052/4054 requires INPUT of ASCII data files - there are 55 DATA files!.
It also requires PRINT to save the Adventure game to a file.

Here is my 4054A running Adventure from a 4907 floppy disk (8-inch disk):

(Attachment Link)

Nice to hear that we are making progress. You have a working 8in floppy disk? The last time I saw one of those was in my workplace some 30 years ago and it was obsolete back then! The old defunct drives were massive even by 5.25 in standards.

Yes, I now have two Tektronix 4907 8-inch disk drive systems that I have repaired and are fully operational!  And they are big and heavy.

You can also see my Tektronix 4924 Tape Drive on top of the 4907's.



I have also recovered several Tektronix 8-inch floppy disks and posted the files on my repository.

I had thought I needed to emulate the directory structure of the floppy disk system, but I think the approach we now have in the emulator is much simpler (single level of directories), and I can modify the floppy disk programs I have recovered to use files in different microSD card directories instead of hierarchical directories.

[WaveyDipole]

I have pushed up an update with what, I hope, is a working INPUT. Currently it reads whole lines of text only but should return the next line each time INPUT is called, provided that the file already is open.

In order to access the tape file HEADER, you first send the FIND @5:X command for file X then INPUT @5,9:A$ to fetch the HEADER.  At this point the file itself cannot be accessed without doing another FIND @5:X command.

This is why I need to resolve the matter of the header record as this will be crucial to the next stages of development. It is accessed by a number of commands including FIND, HEADER, MARK, OPEN, KILL, READ, WRITE. I have seen the Tektronix specification in the manual and imagine that when the 405x requests the header record it will need to be transmitted in the correct Tek format. The emulator stores the information in the filename in a somewhat different format, so when FIND finds the file, it will need to extract the header information which will need to be stored or converted into Tek header format while the file remains open.

Incidentally, I discovered that the last number in the header information is the number of records allocated. It seems that records can be 128 or 256 bytes long. Will the emulator be expected to support both?

The filename format includes:

xxxxxx MARKed filesize in bytes

MARK records the number of 128 or 256 byte 'records' allocated. Is the intention here to record the actual file size in bytes rather than the number of records?

[mmcgraw74]

I have pushed up an update with what, I hope, is a working INPUT. Currently it reads whole lines of text only but should return the next line each time INPUT is called, provided that the file already is open.

In order to access the tape file HEADER, you first send the FIND @5:X command for file X then INPUT @5,9:A$ to fetch the HEADER.  At this point the file itself cannot be accessed without doing another FIND @5:X command.

This is why I need to resolve the matter of the header record as this will be crucial to the next stages of development. It is accessed by a number of commands including FIND, HEADER, MARK, OPEN, KILL, READ, WRITE. I have seen the Tektronix specification in the manual and imagine that when the 405x requests the header record it will need to be transmitted in the correct Tek format. The emulator stores the information in the filename in a somewhat different format, so when FIND finds the file, it will need to extract the header information which will need to be stored or converted into Tek header format while the file remains open.

Incidentally, I discovered that the last number in the header information is the number of records allocated. It seems that records can be 128 or 256 bytes long. Will the emulator be expected to support both?

The filename format includes:

xxxxxx MARKed filesize in bytes

MARK records the number of 128 or 256 byte 'records' allocated. Is the intention here to record the actual file size in bytes rather than the number of records?

I have been recovering dozens of Tektronix 4050 series program tapes by reading every block in every file.  The 4924 tape drive was introduced with the 4051 in 1975 and replaced a 4923 tape drive which was designed to work with the 4000 series Tektronix terminals.  The 4923 tape drive only supported 128 byte blocks and the 4924 tape drive could be configured for either, but the 4924 tape drive default is 256 byte blocks.

None of the 100's of 4050 tape drive programs I have recovered use 128 byte blocks - as the 4051 internal tape drive was designed to support 256 byte blocks - so we don't need to support anything but 256 byte blocks.  In addition, I don't think the block size is of any importance as their is no Tek BASIC command that fetches a data block.  For my Tape Dump program I use a different company "TransEra" ROM cartridge with data block read and write commands.

The first block on the 4050 tapes I have recovered by reading the all the blocks with my Tape Dump program only uses the HEADER string at the beginning of the block, which can only be read by a 4051 program using the PRINT @x,19: BASIC statement where x=33 for the internal tape drive or x=4924 primary GPIB address for the external tape drive. 

The ONLY 4050 programs that have this statement are the ones that read the original tape header and rewrite the header with comments supplied to the program by the user.

The BASIC TLIST command to the internal tape only - reads the file HEADER from each file and lists the information to the 4050 display by default, or can be redirected to PRINT each file HEADER to a GPIB device.  Tek BASIC replaces the last number (number of 256 byte blocks in the file - not including the HEADER block) with the calculated file size.

This calculated file size will match the filesize requested with the MARK command which created the file - not the amount of the file that is used.

The TLIST command is really only useful to a user that wants to either remember which file number to open on a previously recorded tape, or is trying to add or replace files on the tape with the MARK command and wants to find the LAST file to use that file number as the starting file number for the MARK command.

I used the 4051 computer for 3 years in the late 1970's, developing programs.  When I purchased my vintage 4052 and 4054 computers twenty years later, I couldn't find a 4051.  I noticed the 4052 and 4054 computers (introduced in 1979) added several new BASIC commands including a HEADER command.  When you run the HEADER command on either the internal tape or 4924 tape, you must run this command immediately after a FIND command and Tektronix PRINTs the file header information for that file exactly like the print in the TLIST - where the filesize is printed in bytes, not number of blocks.  However, the file that you have printed the header is no longer open and another FIND command must be issued before the file can be accessed.

I have created the filename for each file on the microSD card in the Emulator in the same byte for byte format as the 4050 tape header with three exceptions:

• The leading space before the filenumber is stripped when the filename saved (and I don't use the file extension)
• The trailing CR and DC3 are stripped when the filename is saved
• The starting location of the number of blocks of the LAST file is shorter by one byte than all the other files

My Emulator code adds the leading space and trailing CR and DC3 to the header string before sending it to the system to match what Tek BASIC documentation on the header format.

Apparently TEK BASIC on the 4054A (the A-Series 4052 and 4054 added the TI 9914 GPIB ASIC and many new BASIC instructions, so the firmware is different than the 4052) does not access the file header before the OLD command, since we don't have that working yet on the Emulator.

I do believe TEK BASIC will access the file header before executing a program READ statement from tape - as Tektronix will need to process each binary data item header for each READ.

Thanks for the updated code - I will test that now and we will see if the INPUT command also requires the header be accessed.

Since the file header is an entire block of 256 bytes - I don't know if Tek BASIC ROM expects to access the header like a user with the special PRINT statement followed by an INPUT command for the ASCII header string after a FIND command, with a subsequent additional FIND command to access the data items based on the data file type, but we will find out

I replace the 4924 5V power supply fuse yesterday and the tape drive appeared to start working and I was able to use the front buttons to fast forward and rewind the tape, but when I turned it off and connected it to my 4052 and turned it on again - it is not working    I don't plan to debug the 4924 issue today.

I hope your updated code for INPUT works on the 4054A.  I have prepared a fourth directory on the microSD card with my Adventure game port where the statements that access the 55 data files have been changed to access these files on the emulator.  Fingers crossed.

[mmcgraw74]

I have pushed up an update with what, I hope, is a working INPUT. Currently it reads whole lines of text only but should return the next line each time INPUT is called, provided that the file already is open.

I tested your new drop and INPUT provides data but doesn't work right yet.

Here is a photo from my 4054A:



Here is the ADVKEYS file 1 being INPUT:

Code: [Select]

   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
   DATA 15,9459313,15,1515430,16,10541692,16,9046363,17
   DATA 10386,18,211942,18,5511277,19,197385,20,115990,21
   DATA 1191644,22,53591,23,12562,23,405292,25,60879,26
   DATA 5963048,27,38576,28,1305,29,10150041,29,7478239,30
   DATA 8824300,31,7307409,32,41708,33,945573,35,9466352,36
   DATA 2145145,37,8929575,38,2233302,39,5279045,41,6111523
   DATA 42,7523588,100,14,100,6674000,101,369,102,5,102
   DATA 89070,103,499,104,19,104,8960908,105,517,106,23
   DATA 106,408142,107,387,108,21,108,562,109,4,109,81056
   DATA 150,7536914,151,11425101,152,7533245,153,1289448,154
   DATA 3516401,155,636,156,4191,157,35917,158,504325,158
   DATA 8824505,158,8783307,200,2524729,200,291920,201
   DATA 1697949,202,221453,203,248,203,2544612,204,5572845
   DATA 204,10706,204,104358,205,4373864,205,9,206,10541692
   DATA 207,221141,207,9851065,208,10386,209,8833780,210
   DATA 221423,211,1236540,212,313242,212,347870,212,3748
   DATA 213,8745885,214,1905,215,1588264,216,190310,217
   DATA 274600,218,1592479,219,1126054,219,1929708,220
   DATA 119741,221,405215,300,12716,301,111864,302,5646856
   DATA 302,404,303,2720472,303,10302,304,4882,304,1402110
   DATA 304,352487,305,82878,305,84854,306,9292709,307
   DATA 822045,307,199744,308,108970,309,117759,309,8321691
   DATA 310,405501,311,3426,312,2150731,313,319778,313
   DATA 2707727,314,1233737
Notice that each INPUT is only reading the first number on each of the separate lines in the file.

The "DATA" text is ignored - there are no quotes.

This is the same file contents that work with the files located on the 4907 GPIB floppy drive.

The program is running line 174 in a loop to fetch two variables and save them in two different numeric arrays.

The K0 array should contain the first number (Adventure room number) and the K5 array will contain the large number (value encodes which room is accessed from which direction from the K0 room number.

The program hung on line 174 with the FOR loop index stopped at 29, there are only 28 DATA statements in file 1 and K0 contains only the first number of each line.

I just checked the contents of K5 array - it contains the second value on each of the 28 DATA statements.

Sounds like the Emulator is fetching a new line for each INPUT statement instead of only fetching a new line when the contents of the previous line have been consumed.

Tek BASIC when READing variables in DATA statements does not consume a whole DATA statement, just the variables requested.

Great progress, though!  We are getting very close to running Adventure, the most complex program for the 4052/4054 that I have written

[mmcgraw74]

I just looked at your new INPUT code in AR488_Store_Tek.cpp and see in your comment that it reads a "line at present".

We need it to 'ignore' lines and just return one GPIB byte at a time to Tektronix, which needs to include the CR.

Is there an SDfat call other than read a line that we can use for INPUT that would be byte at a time?

We will need the same functionality in the READ code later.

[WaveyDipole]

Yes, the input code is pretty basic at this stage and your test does provide an indication that the function is being recognised.

Is that the standard format of the Tektronix data file? If so then curious that the word DATA is repeated on every line. Are there any other keywords that might appear? Also, how does it treat text (string) data? In double quotes? I assume yes, because otherwise how could a comma in text be distinguished from a delimiter? Not a big deal and the main point is that each item of data is between commas.

Now that I know what the data file looks like, I can work with that. In SDfat, getline(0 can read to a specific delimiter, but only one delimiter.  Here it would seem we need to distinguish between comma, CR and space so that's not going to work. We can't read a line at a time either (well we could but then you would have to preserve the remainer of the line somewhere and work out how far you had got on the previous input request) so I think it will indeed need to read byte by byte and parsed. Shouldn’t be too difficult though.

[mmcgraw74]

Is that the standard format of the Tektronix data file? If so then curious that the word DATA is repeated on every line. Are there any other keywords that might appear? Also, how does it treat text (string) data? In double quotes? I assume yes, because otherwise how could a comma in text be distinguished from a delimiter? Not a big deal and the main point is that each item of data is between commas.

There is no standard format for a Tektronix ASCII DATA file.  The file contents were typically created by a BASIC program which would dictate whether the data items were written one at a time with separate PRINT statements which would generate a CR after each data item, or multiple data items (numeric or string or both) in a PRINT statement (this is the way my Adventure DATA files were created).  In either case, the BASIC program did not need to know where CRs were located.

Yes, the 'DATA' text is unnecessary - but totally ignored by Tektronix as it is not quote delimited as all ASCII character strings must be quote delimited. 

Now that I know what the data file looks like, I can work with that. There is no specific SDfat call that I know of to read to the next delimiter so I think it will indeed need to read byte by byte and parse. Shouldn’t be too difficult though.

Yes, I agree that the Emulator response for an INPUT GPIB command should be byte by byte ASCII characters - no need for any parsing.  I expect there must be an SDfat call that can stream binary data without any parsing.  Let Tektronix BASIC parse the GPIB bytes, driven by the BASIC INPUT statement being executed.

READ on the other hand, may be different, or may not be different, based on whether the Tektronix BASIC ROM issues an INPUT @2,6: command to fetch the TYPE of the next BINARY data element prior to each READ of a BINARY data element.  I seriously doubt the BASIC READ command will operate that way (too much GPIB overhead - huge performance impact).

I imagine the READ command will be a byte by byte transfer - just like INPUT and the BASIC ROM will be expecting the first two bytes are the TYPE - in binary, followed by the numeric or string variable with the data length encoded in the TYPE bytes.

From the 4924 Tape Service Manual page B-4 description of the INPUT @2,6 GPIB command to fetch the TYPE, I expect this is just for a user program to examine the TYPE of the next binary data item.  My BASIC programs that used BINARY data files made no such call.  They just did READ commands to fetch the numeric or string variables.

Using BINARY data files on Tektronix programs was a lot faster than using ASCII data files - due to the elimination of processing ASCII numbers into Tek BASIC 64-bit internal floating point format (Tek BASIC did not support integer data type).

[mmcgraw74]

From the 4924 Tape Service Manual page B-4 description of the INPUT @2,6 GPIB command to fetch the TYPE, I expect this is just for a user program to examine the TYPE of the next binary data item.  My BASIC programs that used BINARY data files made no such call.  They just did READ commands to fetch the numeric or string variables.

In support of my contention above, the INPUT @x,6:A command only returns one ASCII integer with the TYPE, it doesn't return the length of the data item, so it can't possibly be used by the BASIC ROM.

[WaveyDipole]

I see from the screenshot how your program is printing only the first number in each line to the screen.

I am now totally baffled. If the the emulator is not expected to look at delimiters, and as can be seen from your screenshot, Tek BASIC is parsing because it is chopping the data into numbers, and furthermore the INPUT or other commands do not indicate how many bytes to send, then how is the emulator to know how many bytes to send each time an INPUT command is called?

Each INPUT command cannot send just one byte either as each data type is different in size and each INPUT command can include multiple variables and mixed variable types so the data length BASIC expects back needs to correspond to the sizes of the variables requested.

So does the emulator just keep sending until the Tek 405x signals it to stop in some way? If so, then what is the signal? The Tek can't send a data byte at the same time as the emulator is already doing so. Nor does EOI seem likely because EOI is usually signalled by the sender.

I did come across this description in the manual for the input command:

The INPUT command. This causes the 4924 to transfer the
contents of its current file to the 4051 as a string of ASCII
characters. The 4051 stores the first "logical record" (the
characters up to the first CR character in the string) in the string
variable A$, which must be dimensioned large enough to accept
it.

So is the answer to send the next "record" or 256 bytes and let the Tek decide how to process the information? That would seem in line with your comment about parsing, but we have already seen that sending a whole line didn't result in the data being read correctly either.

I did wonder whether it is a simple matter of handshaking but again, that didn't work for sending a complete line. What I could try is a simple "send to the next comma" and see what happens.

[mmcgraw74]

The Tektronix is the GPIB controller and is either the source of the data or listener for the data and completely controls the pacing of the bytes on input, so the GPIB device always operates one byte at a time, not on data blocks.

All I'm saying is the Tektronix does the data parsing for INPUT and READ commands - the tape emulator would only have to parse a BINARY data stream if requested by the program using the INPUT @x,6: command, which I have NEVER seen in any Tektronix program.

[WaveyDipole]

The Tektronix is the GPIB controller and is either the source of the data or listener for the data and completely controls the pacing of the bytes on input, so the GPIB device always operates one byte at a time, not on data blocks.

I take your point on that. When I do a ++read to read my DMM for example, the controller addresses the meter and tells it to send a reading. The meter sends a reading of a specific length. The controller does not know how long that stream of data will be. It only knows that whatever the meter sends it will be terminated with a specific terminator byte or bytes (CRLF sequence) and maybe an EOI signal. Thats how it knows when to stop receiving and forwarded the data to the controlling program which interprets it and does something with it.

So I guess applying this in reverse, the emulator (which is a device like the meter) receives a command from the controller (Tek) in response to which it has to send some data. That stream of data has to be finite just like the meter reading. It can't just keep sending indefinitely. I agree that the Tek hardware knows or cares nothing about that chunk of data it just received but passes it on to BASIC to interpret. However, it does need to know when to drop out of the receiving loop and pass control back to the BASIC interpreter.

So yes, the GPIB handshake process itself is a byte by byte process and knows nothing about terminators or the data content being passed, but each end must know when to start and stop. With my DMM, the signal to stop is a CRLF sequence or an EOI. So what is it with the Tek? It could, I suppose, be a timeout?

I am working on the assumption that the Tek uses standard delimiters like the comma. One of the manuals did state it can use others such as space and CR but the common default for ASCII data is the comma. The version I have just pushed up simply reads up to the next comma or end of file. I would interested to see what it does.

[mmcgraw74]

The Tektronix is the GPIB controller and is either the source of the data or listener for the data and completely controls the pacing of the bytes on input, so the GPIB device always operates one byte at a time, not on data blocks.

I take your point on that. When I do a ++read to read my DMM for example, the controller addresses the meter and tells it to send a reading. The meter sends a reading of a specific length. The controller does not know how long that stream of data will be. It only knows that whatever the meter sends it will be terminated with a specific terminator byte or bytes (CRLF sequence) and maybe an EOI signal. Thats how it knows when to stop receiving and forwarded the data to the controlling program which interprets it and does something with it.

So I guess applying this in reverse, the emulator (which is a device like the meter) receives a command from the controller (Tek) in response to which it has to send some data. That stream of data has to be finite just like the meter reading. It can't just keep sending indefinitely. I agree that the Tek hardware knows or cares nothing about that chunk of data it just received but passes it on to BASIC to interpret. However, it does need to know when to drop out of the receiving loop and pass control back to the BASIC interpreter.

So yes, the GPIB handshake process itself is a byte by byte process and knows nothing about terminators or the data content being passed, but each end must know when to start and stop. With my DMM, the signal to stop is a CRLF sequence or an EOI. So what is it with the Tek? It could, I suppose, be a timeout?

I am working on the assumption that the Tek uses standard delimiters like the comma. One of the manuals did state it can use others such as space and CR but the common default for ASCII data is the comma. The version I have just pushed up simply reads up to the next comma or end of file. I would interested to see what it does.

The Emulator should not care about delimiters during the INPUT command.  The Tektronix will decide if the INPUT command is satisfied and end the command, OR if the Emulator hits the end of file, it will return the EOF character 127 with EOI asserted to end the command.

I will download and check out your version 28 right now

[mmcgraw74]

Version 28 did not get as far as your previous version - the Tektronix hung on line 174 in the program (photo in previous post) with only K0(1) holding a value and K5(1) was uninitialized with J=1.

I believe we need to open the buffer in the FIND command after the file is found.

The INPUT command would just access that buffer and when the INPUT is terminated by the Tektronix, leave the buffer open for the next INPUT command.

If the INPUT function reaches EOF, it would return the EOF character with EOI asserted to the Tektronix to end the command, and the INPUT function would close the file, otherwise the file would remain open until EOF was reached or a new FIND command is issued by the Tektronix - in which the FIND routine would close the previous file and open a new file and buffer.

[WaveyDipole]

Thank you for giving it a try. Clearly I was on the wrong track.

The Emulator should not care about delimiters during the INPUT command.  The Tektronix will decide if the INPUT command is satisfied and end the command, OR if the Emulator hits the end of file, it will return the EOF character 127 with EOI asserted to end the command.

In that case, maybe the INPUT command would have to just send the whole file with EOI on the last byte just like in the OLD command and rely on the Tek to control the transmission via the handshaking.

I believe we need to open the buffer in the FIND command after the file is found.

The INPUT command would just access that buffer and when the INPUT is terminated by the Tektronix, leave the buffer open for the next INPUT command.

If the INPUT function reaches EOF, it would return the EOF character with EOI asserted to the Tektronix to end the command, and the INPUT function would close the file, otherwise the file would remain open until EOF was reached or a new FIND command is issued by the Tektronix - in which the FIND routine would close the previous file and open a new file and buffer.

I agree and have already implemented that. FIND has to leave the file handle open otherwise the emulator can't subsequently read from or write to the file. I have also changed the stream type from ifstream to fstream as FIND does not know whether the file will subsequently be read from or written to. In the version just uploaded I have copied the contents of the OLD function into INPUT. The only change is that it checks for the D file type instead of P and closes the file once it has reached EOF. As you mention, this will rely on the Tek to control the input through handshaking.

[mmcgraw74]

I'm downloading your version 29 to test right now!

[mmcgraw74]

Hmm, it stopped with a GPIB error message on line 174 again after reading only one value for K0 and K5.
Further attempts at INPUT@5: also generate the GPIB error message 69 (see 4050 BASIC Reference booklet error messages).

I see that the file is opened on entering the INPUT command.  I think this is one problem as the BASIC program will issue one INPUT command each time through the loop.

I still think the open needs to move into the FIND command and the INPUT and even OLD will just consume the open buffer.

[WaveyDipole]

Sorry, missed that. Should have removed that line. Just comment it out and try again. The file is already being opened in FIND. Each INPUT (and therefore open()) would reset the file pointer to zero otherwise.

Also noticed that this line:

      if (sdin.peek() == EOF) {

Needs to be corrected to this:

      if (sdinout.peek() == EOF) {

The perils of copy and paste!

BTW, the Pandauino arrived about an hour ago!

[mmcgraw74]

I commented out the ifstream sdin(path) line in INPUT - hung on line 174 without getting any data.

I don't think the path statements are needed in INPUT anymore either.

I still think INPUT is closing the stream on first exit.

Glad to hear the Pandauino arrived!

I wouldn't wait for the auction to end - I would make an offer - say 100 pounds before the auction is over.

[WaveyDipole]

I commented out the ifstream sdin(path) line in INPUT - hung on line 174 without getting any data.

I don't think the path statements are needed in INPUT anymore either.

I concur.

I still think INPUT is closing the stream on first exit.

There appears to be nothing that actually closes it, but the implication might be that it is reading to EOF every time it is called, in which case the read is not being controlled. It just runs as far as it can. This has me really baffled and I am not sure what to try next.

I wouldn't wait for the auction to end - I would make an offer - say 100 pounds before the auction is over.

I tried an offer of 120GBP and 130GPB and both were automatically rejected. I don't think it will go for less than the starting price especially as he had it advertised for 250 elsewhere.

Do you have any logic analyser traces when using INPUT?

[mmcgraw74]

Are you going to bid at the last moment?

[WaveyDipole]

I also want to mention that there is a detailed 4051 GPIB Hardware Supplement manual describing how the 4051 (and 4052) handle GPIB with discrete logic and BASIC firmware: http://www.bitsavers.org/pdf/tektronix/405x/070-2270-00_4051_GPIB_HW_Supp_Jul81.pdf

I have been catching up on my reading and had a look at section 4 of this manual again and went step by step through the handshaking process. It seems there are two ways that the Tek controls the process. one is by holding off the NRFD and NDAC lines. The manual states that the processes involved take at most 12ms and the emulator timeout is set at 5000ms (5 seconds) so there should be no problem with the timeout being too short.

The second is by asserting ATN when it has read enough data to satisfy all variables in the current INPUT statement. The emulator should, at this point, immediately terminate the send loop and go to attention to await the next command. This is the element that I think was missing with the result that the loop would instead run to the end of the file on every INPUT command, starting at the beginning of the file again with each subsequent INPUT request.

I have re-jigged the code again to process the file byte-by-byte instead of by line or buffer-full, but also added the means to drop out as soon as ATN gets asserted. I am hoping that this will now interact correctly, allowing the Tek to control the emulator data flow. After each INPUT command is stopped, the current file pointer should remain at the last read position and the next INPUT command should pick up where the previous one left off until it reaches EOF. I could only test as far as ensuring that the complete file is sent across GPIB, which it is.

I have uploaded the updated code.

BTW, yes, I think I will now leave the bidding it as late as possible. Still a couple of hours left an no bids.

[mmcgraw74]

I tried your v29 build on my 4054A - similar result, line 174 was run once, both K0 and K5 got one number, J=2, BREAK key twice returned to BASIC.

I then tried simpler experiment on the 4054A:

PRI @5,19:"ROOT"
FIND @5:2
INPUT@5:A$,B$,C$

this worked BUT A$,B$,C$ ONLY contained the three directory strings NOT the entire header string from file 2.
I imagine this is because there are no quotes around the string and Tektronix used space as a string delimiter in this case.

However now trying a second INPUT@5:D$ resulted in hang in I/O until I pressed BREAK key twice.  D$ contained no data.

So it appears leaving the first INPUT command prevents further data access.

I'll have to take my laptop into the other room with the 4054A to capture the serial debug output.

Taking the logic analyzer into the other room would require I make space near the 4054A - so I'll try the laptop first.

BTW - the 4052 continues to hang on poweron if the Emulator is powered.  I have to poweron the 4052, then plug the USB cable into the Emulator.

The 4052 appeared to match the 4054A results on a similar experiment - but had an error message on the second INPUT command instead of hanging in I/O until I pressed the BREAK key twice.

PRI @5,19:"ROOT"
FIND @5:2
INPUT@5:A$,B$

this worked BUT A$ and B$ only contained the first two directory strings, not the rest of the header info in file 2 (matched the 4054A).

However INPUT@5:A$,B$ resulted in Tektronix printing a GPIB error 69 (this is different)

Here are the serial debug messages for the 4052 test:
Note I updated the Config.h version number to 29 with today's date

Code: [Select]

AR488-Store ready (device).
++ver
AR488 GPIB storage, ver. 0.05.29, 13/07/2021
Executing secondary address command: 73
stgc_073_h: started CD handler...
OTstgc_0x73_h: received directory name: ROOT
stgc_0x73_h: set directory name: /ROOT/
stgc_0x62_h: started CLOSE handler...
stgc_0x62_h: closing: ...
stgc_0x62_h: done.
stgc_0x73_h: end CD handler.
Executing secondary address command: 7B
stgc_0x7B_h: started FIND handler...
stgc_0x7B_h: received parameter:  2
stgc_0x7B_h: found: 2      ASCII   DATA [DIR LIST]   4
stgc_0x7B_h: type:  D
stgc_0x7B_h: done.
Executing secondary address command: 6D
stgc_0x6D_h: started INPUT handler...
stgc_0x6D_h: reading /ROOT/2      ASCII   DATA [DIR LIST]   4...
stgc_0x62_h: started CLOSE handler...
stgc_0x62_h: closing: 2      ASCII   DATA [DIR LIST]   4...
stgc_0x62_h: done.
stgc_0x6D_h: done.

Here is the debug serial console output - note CLOSE handler after first INPUT AND no second "started INPUT handler"

[WaveyDipole]

I then tried simpler experiment on the 4054A:

PRI @5,19:"ROOT"
FIND @5:2
INPUT@5:A$,B$,C$

this worked BUT A$,B$,C$ ONLY contained the three directory strings NOT the entire header string from file 2.
I imagine this is because there are no quotes around the string and Tektronix used space as a string delimiter in this case.

Not sure what you mean? Unless you have a different version, the file seems to contain only 3 directories on 3 lines?

/root/
/Games/
/UTILITIES/

So I'm not sure what is missing? Each CR at the end of the line would be interpreted by the Tek as a a delimiter for each of the 3 strings read into A$, B$ and C$.

However now trying a second INPUT@5:D$ resulted in hang in I/O until I pressed BREAK key twice.  D$ contained no data.

So it appears leaving the first INPUT command prevents further data access.

Is this on another file? In the file above I would expect there to be no more data after the 3 elements had been read. Having said that, the emulator ought to be just dropping the transmission if it can't read any more data and not hanging the Tek.

Here is the debug serial console output - note CLOSE handler after first INPUT AND no second "started INPUT handler"

There are 3 variables and 3 items read so after that we have reached EOF hence I think the close. However, perhaps the call to close should be removed as the file will be closed on the next FIND or manually on CLOSE.


 

[mmcgraw74]

My mistake on the contents of ROOT/2, Yes, the file only contains the three subdirectories on my original sd card image.

But my 4052 test I only input two strings, not three on the first INPUT and the second INPUT hung.

So INPUT is still not working correctly.

Same thing happens on my 4054A