Tektronix 4924 Tape Drive Emulator

[mmcgraw74]

I just saw your question on FIND yesterday:

When I tested ERROR it returned a blank instead of '0'. I am uncertain whether the data is meant to be returned as a byte or an ASCII character, hence my earlier question and possible need for adjustment. I will have a further dig around the documentation. I have not yet made any attempt to test FIND.

The data passed from the system to the emulator for the FIND command is an ASCII number with a leading space (Tek 4050 BASIC) and followed by a CR delimiter.

The directory string for the CD command is ASCII text and does not have any leading space and will also be CR delimited.
I want to use the secondary address 9 (decimal 105) for this command.  It is not a standard BASIC command, so I can generate this command with PRINT @5,9:"utilities" for example to have the emulator change the current directory to \utilities\.

The BASIC FIND @5:12 command will work for example to find file 12 in the current directory.

[WaveyDipole]

On the good news front, I was able to get the TLIST data from the emulator if I used the INPUT @5,19:A$,B$,C$,D$,E$ command as shown in the first photo.  This is not a good substitute for the TLIST command as I had to know how many files prior to issuing the command and then assign each file to a different string.

(Attachment Link)

That's interesting. Each string variable appears to accept one line up to the line terminator (CR). I found some information in a PDf file '070-2270-00_4051_GPIB_HW_Supp_Jul81.pdf' sections 4-10 to  4-16 which describes exactly this behaviour of the INPUT command. It reads data into the variable up until a CR character is received. It would seem then, that what is required is to read into a single variable and output a line at a time in a loop until the variable contains a null string "". In other words it seems we would need to iterate over INPUT @5,19:A$ until no further data is forthcomming. The interesting thing is that we have some communication in principle though.

So, how do I get my FIND, CD, READfile and OLD code enabled on AR488_STORE?

The filenumber parameter passed to FIND will be from GPIB from the system as an integer (CR delimited)
The directory parameter passed to CD will be from GPIB from the system as a character string (also CR delimited)

What is the OLD command? I see an OLD/APPEND 4/100 (hex 64). Is this the one?
READfile I presume is READ 14/110 (hex 72) so that is straightforward.
I will get to work on those and they are easily moved to the correct secondary address later if I get it wrong initially.

The data passed from the system to the emulator for the FIND command is an ASCII number with a leading space (Tek 4050 BASIC) and followed by a CR delimiter.

The directory string for the CD command is ASCII text and does not have any leading space and will also be CR delimited.
I want to use the secondary address 9 (decimal 105) for this command.  It is not a standard BASIC command, so I can generate this command with PRINT @5,9:"utilities" for example to have the emulator change the current directory to \utilities\.

The BASIC FIND @5:12 command will work for example to find file 12 in the current directory.

Thank you for the information.

BTW, would you like to allow directory names of 8 or 10 characters? The variable 'directory' is defined as being 13 characters long (including /'s and NULL), but in the CD function the comment indicates 8 characters? There may, of course, be a reason why the latter is shorter.

[mmcgraw74]

The OLD command erases the RAM memory and loads a program from a file that was first selected using the tape FIND command.

Since the original 4051 only had 8KB of RAM, many of the original programs would use the APPEND command to overlay additional segments to the program that was loaded with the OLD command.  Same call to the tape drive as OLD, you need to FIND the file to APPEND and and use the BASIC APPEND command (not OLD) to fetch the overlay.  The system BASIC ROM would perform the different action with the data based on the use of OLD or APPEND in the program.

I already have the OLD, FIND, CD, and READ_file code working (using serial out) in my continuedDev code that you migrated into AR488_Store.  We just need to enable them in AR488_Store and I will test them against the 4052.

The table of GPIB Secondary Addresses on page 7-10 of the 4050 BASIC Reference Manual first column is the value that would be used to redirect the BASIC ROM to override the BASIC command and add the secondary address value in the GPIB addressing.

The PRINT statement can be use to send any of the GPIB commands in the table that either have no parameters like OLD or parameters like FIND 12.  Example: PRINT @5,4: will be identical to OLD @5: and PRINT @5,27:12 is the same as FIND @5:12

The INPUT statement can be used to send GPIB commands that return data.  Example INPUT @5,0: A.B.C.D will read the STATUS of the 4924 tape drive.

Yes, the GPIB Decimal secondary addresses we need for OLD, FIND, CD and READ_file are:

OLD  100
FIND 123

CD    105  (this command is only supported on the floppy & harddisk options to report the directory.  In my emulator CD will be used to change the directory with a PRINT command.  Example: PRINT @5,9:"utilities" will change the tape emulator directory to \utilities\)

Lets use 127 for the Tape Emulator READ_file command (not defined in Tek BASIC)

[WaveyDipole]

CD    105  (this command is only supported on the floppy & harddisk options to report the directory.  In my emulator CD will be used to change the directory with a PRINT command.  Example: PRINT @5,9:"utilities" will change the tape emulator directory to \utilities\)

If preceding and/or trailing slashes are not added then the program needs to add them?
Also are both backslashes '\' and forward slashes '/' to be acceptable?

In the function comments it shows forward slashes. I have copied in the CD function but for now have assumed that the slashes will be provided by the user and have not done anything to add them automatically.

[mmcgraw74]

My continuedDev CD code already added the slashes.  Maybe not the most elegant way.

void tek_CD(char *direct) {
    // limit the emulator dir name to single level 8 characters PLUS leading and trailing "/" plus NULL

    char *param;
    if (direct != NULL) {

        param = strtok(direct, " \t");
        // cout << " \n";
        // set directory = /param/;
        strcpy(directory, "/");
        strcat(directory, param);
        strcat(directory, "/");
        cout << F("directory= ") << directory << " \r " << endl;
    } else {
        cout << F("Null directory");
    }
    f_name[0] = 0; // delete any previous filename that was open
}

[mmcgraw74]

CD    105  (this command is only supported on the floppy & harddisk options to report the directory.  In my emulator CD will be used to change the directory with a PRINT command.  Example: PRINT @5,9:"utilities" will change the tape emulator directory to \utilities\)

If preceding and/or trailing slashes are not added then the program needs to add them?
Also are both backslashes '\' and forward slashes '/' to be acceptable?

In the function comments it shows forward slashes. I have copied in the CD function but for now have assumed that the slashes will be provided by the user and have not done anything to add them automatically.

I think I needed forward slashes to work with sdFAT.

It will be ok for me to add the slashes to the directory name in the BASIC programs I will be converting to work with the Tape Emulator.

[WaveyDipole]

Its not difficult to add a substitution so that when a '\' is found in the input it automatically gets converted to '/' for compliance with SdFat. This would allow BASIC notation to be used and the conversion happens in the background in the emulator. Also slashes can easily be added when not present as your updated example indicates.

I think your idea to have the emulator add the slashes is a good one. The function can just ignore and strip any slashes found in the input, whether forward or back.

Can I ask whether the TLIST command is meant to list all files (up to 99) in the currently selected directory, or all files in ALL directories? I am a little confused about the purpose of the first 'for' loop? It seems to be the second (inner) one that does all the work to list files in directory name held in the variable 'directory'.

Lets use 127 for the Tape Emulator READ_file command (not defined in Tek BASIC)

Unfortunately, 127 is not a valid secondary address. Valid addresses run from 96 - 126 (decimal) or 60 - 7E (hex).

UPDATE: just need to add another question. While working on adding the tek_FIND function from your AR488-644-TLIST-continuedDev, I came to the realisation that while the Tek documentation seems to indicate that the function opens a file but does not return anything. Your implementation seems to return a single character for the file type. Should the letter be used to set 'f_type'? or should it be returned via GPIB? It also seems to print other output to serial via 'cout'. Do we need this as output over GPIB or was this just for debug purposes?

If output over GPIB is required, then the way the function is called would have to change from:

FIND   27 (MLA 37)(MSA 123)(FileNumber+CR)(UNL)

to:

FIND   27 (MTA 37)(MSA 123)(FileNumber+CR)(UNT)

since we now need the emulator to talk and return something.

In the event that the file is not found, I see that the function simply sets f_name to NULL in any case.
I am rather suspecting that output of any kind is not required and the function simply needs to set f_name and f_type for use by subsequent commands?

Other than that, the function does appear to be working. Still working on it. though.

[mmcgraw74]

Its not difficult to add a substitution so that when a '\' is found in the input it automatically gets converted to '/' for compliance with SdFat. This would allow BASIC notation to be used and the conversion happens in the background in the emulator. Also slashes can easily be added when not present as your updated example indicates.

I think your idea to have the emulator add the slashes is a good one. The function can just ignore and strip any slashes found in the input, whether forward or back.

Can I ask whether the TLIST command is meant to list all files (up to 99) in the currently selected directory, or all files in ALL directories? I am a little confused about the purpose of the first 'for' loop? It seems to be the second (inner) one that does all the work to list files in directory name held in the variable 'directory'.

The returned variable in FIND is just for use in the code, so the other commands know what the file TYPE is.

Lets use 127 for the Tape Emulator READ_file command (not defined in Tek BASIC)

Unfortunately, 127 is not a valid secondary address. Valid addresses run from 96 - 126 (decimal) or 60 - 7E (hex).

UPDATE: just need to add another question. While working on adding the tek_FIND function from your AR488-644-TLIST-continuedDev, I came to the realisation that while the Tek documentation seems to indicate that the function opens a file but does not return anything. Your implementation seems to return a single character for the file type. Should the letter be used to set 'f_type'? or should it be returned via GPIB? It also seems to print other output to serial via 'cout'. Do we need this as output over GPIB or was this just for debug purposes?

If output over GPIB is required, then the way the function is called would have to change from:

FIND   27 (MLA 37)(MSA 123)(FileNumber+CR)(UNL)

to:

FIND   27 (MTA 37)(MSA 123)(FileNumber+CR)(UNT)

since we now need the emulator to talk and return something.

In the event that the file is not found, I see that the function simply sets f_name to NULL in any case.
I am rather suspecting that output of any kind is not required and the function simply needs to set f_name and f_type for use by subsequent commands?

Other than that, the function does appear to be working. Still working on it. though.

TLIST code will not be needed as it was not supported on the 4924 tape drive AND Tek BASIC TLIST only works with the internal tape drive. 

Tape Emulator must support the HEADER (BASIC 9, Secondary Address 105) command in order for DATA files to be accessed based on ASCII or BINARY type. 

So we can't use 105 (as it is used for HEADER on the 4924 and we need a HEADER command) or as you pointed out 127 for CD.  How about 115?  Since TLIST is not supported by the 4924 we should be able to use 115 for the Tape Emulator CD command.

As I think about trying to use READ_file - there is no BASIC command to just read multiple ASCII strings and print them to the screen except for TLIST.  So we can forget about READ_file code.  The READ_one code is needed for the READ command at secondary address 110.

[WaveyDipole]

Ok, so far I have implemented as follows:

4 [64] OLD/APPEND (imported in but untested)
Tektronix:
Emulator: (tek_OLD) appears to read a file and output its contents to the 4050

9 [69] HEADER (seems to be working)
Tektronix: allows files to be accessed based on ASCII or BINARY type
Emulator: (tek_CD) allows selection of a directory (“tape”)

19 [73] LIST/TLIST (seems to be working)
Tektronix:
Emulator: (tek_TLIST) returns a list of file headers

27 [7B] FIND (seems to be working)
Tektronix:
Emulator: (tek_FIND) finds and sets the current file by using its file number

30 [7E] ERROR (not working at present - returns no data)
Tektronix: Returns the error status of the tape drive
Emulator: Return the error status of the SD Card emulator

I still need to add:

14 [6E] READ
(READ_one_ code)

Just taking a step back fistly, do I have the correct code in command 9 [hex 69] ?

Regarding 127, having had a closer look at the original HPIB standard, as I mentioned, it seems they allocated 96-126 (or 60-7E hex) for secondary addresses, but 127 (7F) does not appear to be being used for anything. Maybe the engineers at Tek felt it best not to use it in case the standard changed in the future hence it was left undefined. I suppose it could be used though.

I think I understand from the code that how a file is read would depend on the file type. For example, a BINARY program would need to be read in its entirety, loaded into memory and run. BINARY data might, I suppose, be loaded in its entirety or in part, but would obviously not be run. I expect that the controlling program would determine how many bytes of data to load. For example, a record or array size might determine how many bytes of data to read and load into the entity in which case the READ function would need to know the number of bytes to send. A program in text form would likely to be read in its entirety and would be loaded into an editable area in the 4050's memory. Text data, on the other hand, might be read a line at a time. It looks like both tek_READ_one and tek_READ_file seem to implement some aspects of these different ways of handling a file. The READ and WRITE commands are going to be interesting ones to implement.

I will obviously use the tek_READ_one as the starting point. Would for example:

Code: [Select]

            cout << F("ASCII Program\r");
            cout << F("Type SPACE for next item, or type q to quit\r \r ");

Need to be transmitted back over GPIB to the 4050 to prompt the user to take an action to read the next chunk, or was this for testing only?

 

[mmcgraw74]

Ok, so far I have implemented as follows:

4 [64] OLD/APPEND (imported in but untested)
Tektronix:
Emulator: (tek_OLD) appears to read a file and output its contents to the 4050

9 [69] HEADER (seems to be working)
Tektronix: allows files to be accessed based on ASCII or BINARY type
Emulator: (tek_CD) allows selection of a directory (“tape”)

19 [73] LIST/TLIST (seems to be working)
Tektronix:
Emulator: (tek_TLIST) returns a list of file headers

Great progress!  But you didn't upload this version to AR488_STORE yet?

I haven't seen your code, but expect it will simply return the filename string to the system for the HEADER command.  I am putting the complete HEADER info into the long filename for each file.  This makes this call very easy.

HEADER (9 [69H]).   
Tektronix: requests the HEADER to extract filetype (ASCII, BINARY, NEW, LAST) and datatype (PROGRAM, DATA, SECRET PROGRAM) and filesize (computed from number of 256 byte blocks reported in the HEADER).
Emulator: Returns the SDcard filename of the file selected with a FIND command.  The Emulator also extracts filetype and datatype to use for subsequent Tektronix commands. 
Example: filetype BINARY, datatype DATA.  A subsequent Tektronix READ command will be expecting BINARY data to be returned and I have encoded all BINARY files as HEX, so the Emulator will be converting HEX to bytes first, then returning BINARY bytes on GPIB based on the TYPE bytes preceding the next data item.  In addition, the Tektronix may request the TYPE (6) before requesting the data as Tektronix prints BASIC error messages on a TYPE mismatch before fetching the READ data (numeric or string).

Although my original reason for encoding the BINARY files in HEX was the 7-bit ASCII limitation for transferring those files from the Tektronix to my PC.  For the Tape Emulator, I may as well encode the HEX back into BINARY data to save a step in the Emulator code.

LIST/TLIST I proposed this is now CD in previous post (19 [73H])
Tektronix: sends command with one ASCII string as directory parameter. Example: PRINT @5,19: A$
Emulator: changes SDfat directory to the string parameter with proper slashes

27 [7B] FIND (seems to be working)
Tektronix:
Emulator: (tek_FIND) finds and sets the current file by using its file number

30 [7E] ERROR (not working at present - returns no data)
Tektronix: Returns the error status of the tape drive
Emulator: Return the error status of the SD Card emulator

I still need to add:

14 [6E] READ
(READ_one_ code)

Just taking a step back fistly, do I have the correct code in command 9 [hex 69] ?

Regarding 127, having had a closer look at the original HPIB standard, as I mentioned, it seems they allocated 96-126 (or 60-7E hex) for secondary addresses, but 127 (7F) does not appear to be being used for anything. Maybe the engineers at Tek felt it best not to use it in case the standard changed in the future hence it was left undefined. I suppose it could be used though.

I think I understand from the code that how a file is read would depend on the file type. For example, a BINARY program would need to be read in its entirety, loaded into memory and run. BINARY data might, I suppose, be loaded in its entirety or in part, but would obviously not be run. I expect that the controlling program would determine how many bytes of data to load. For example, a record or array size might determine how many bytes of data to read and load into the entity in which case the READ function would need to know the number of bytes to send. A program in text form would likely to be read in its entirety and would be loaded into an editable area in the 4050's memory. Text data, on the other hand, might be read a line at a time. It looks like both tek_READ_one and tek_READ_file seem to implement some aspects of these different ways of handling a file. The READ and WRITE commands are going to be interesting ones to implement.

I will obviously use the tek_READ_one as the starting point. Would for example:

Code: [Select]

            cout << F("ASCII Program\r");
            cout << F("Type SPACE for next item, or type q to quit\r \r ");

Need to be transmitted back over GPIB to the 4050 to prompt the user to take an action to read the next chunk, or was this for testing only?

Your description of READ is incorrect, see my READ description in my example of the HEADER command in this post.

The BASIC program running in Tektronix is in control, and the Tektronix has a small buffer for each of the BASIC commands to the GPIB device.  The Emulator has a very tiny (one 256 byte 'tape' data block) buffer to handle one request at a time from Tektronix.

The Tektronix READ command will only expect one parameter to be returned, either one number or one string.  For ASCII data files, there are several delimiters for numeric variables.  Here is a snippet of comments showing the ASCII delimiters and BINARY data types at the beginning of tek_READ_one.  For BINARY data files, character strings don't have quotes as the data length is specified in the datatype bytes.  Also no CRs are needed for numeric or string variables, but I expect the Emulator needs to assert EOI on the last byte of data sent to Tektronix.

Code: [Select]

    /*
        Tektronix 4050 DATA Types: ASCII and BINARY

        ASCII DATA
        - ASCII Program lines are delimited with CR (unless changed) and files delimited by FF for EOF
        - ASCII DATA numeric items are delimited with Space, Comma, Semicolon, Colon, or CR
        - ASCII DATA string items are delimited by leading and trailing Quotation Marks
        - To use a Quotation mark inside a character string requires double quotes: ""Help""

        BINARY DATA
        - Each data item contains its own header identifying the length of the item and the type
        - This two byte Header is generated by the talker sending the binary data
        - The two byte data header has the following form:

        MSB                            LSB   MSB                        LSB
        |T3  T2  T1  L13  L12  L11  L10  L9 | L8  L7  L6  L5  L4  L3  L2  L1|
        |           BYTE 1                  |             BYTE 2            |

        L13 to L1 comprise the length of the item including the two header bytes.
        Since all numbers in Tek 4050 BASIC are 8-byte floating point, the binary number data length = 10

        BINARY data types for READ and WRITE commands
        ----------
        T3, T2, T1 are the types of BINARY data
        0   0   0 Unassigned
        0   0   1 Binary number
        0   1   0 Binary string
        0   1   1 Unassigned
        1   0   0 Unassigned
        1   0   1 Unassigned
        1   1   0 Unassigned
        1   1   1 EOF

        Tek 4050 BASIC "TYP" command returns a value based on next item in an open file:
        TYP    Description
        ---    -----------
        0      Empty File or File Not Open
        1      End of File Character
        2      ASCII Numeric Data or Character String
        3      BINARY Numeric Data
        4      BINARY Character String

    */


[WaveyDipole]

Ok, I have moved CD to 19 (73H).

Regarding READ, All I am primarily concerned with from my point of view in terms of coding is with what is transmitted over the GPIB BUS and in what direction. If all that is necessary for FIND is to receive the GPIB secondary address and send back some output based on the file type, then this makes it easier from my point of view. I am happy to leave all of the file encoding/decoding to you....

However, I do need a little clarification. For example, lets take this section of code in the FIND READ function:

Code: [Select]

        case 'P':
            cout << F("ASCII Program\r");
            cout << F("Type SPACE for next item, or type q to quit\r \r ");

            sdin.getline(buffr, line_buffer_size, '\r');          // fetch one CR terminated line of the program
            cout << buffr << '\r';                                // send that line to the serial port

            while (1) {
                while (Serial.available()) {  //any character for next data item or 'q' to quit read1
                    incoming = Serial.read();
                    if (incoming != 'q') {
                        incoming = '\0';     // clear the flag
                        sdin.getline(buffr, line_buffer_size, '\r');          // fetch one CR terminated line of the program
                        if (sdin.eof()) {
                            cout << "__EOF__" << endl;
                            return;
                        }
                        cout << buffr << '\r';                                // send that line to the serial port

                    } else {  // incoming was 'q'
                        incoming = '\0';  // clear the flag
                        cout << "__Quit__" << endl;
                        return;
                    }
                }
            }
So thee are being sent from emulator to PC:

Code: [Select]

            cout << F("ASCII Program\r");
            cout << F("Type SPACE for next item, or type q to quit\r \r ");

            sdin.getline(buffr, line_buffer_size, '\r');          // fetch one CR terminated line of the program
            cout << buffr << '\r';                                // send that line to the serial port
while here we seem to be waiting for input from the serial port which I take to be simulating something being sent from the 4050 to the emulator?):

Code: [Select]

            while (1) {
                while (Serial.available()) {  //any character for next data item or 'q' to quit read1
                    incoming = Serial.read();
                    if (incoming != 'q') {
                        incoming = '\0';     // clear the flag
                        .....
                    } else {  // incoming was 'q'
                        .....
                    }
                }
            }
So we wait for any key other than q and then we send e.g. a line (or item) of data:

Code: [Select]

sdin.getline(buffr, line_buffer_size, '\r');          // fetch one CR terminated line of the program
So the thing is, in reality is the emulator sending a prompt for a key-press and a human sitting there pressing the key or, as seems more likely, is something being sent repetitively by the BASIC program or command? If in reality the "conversation" is between BASIC program and emulator, then what exactly is being sent from the 4050 to the emulator to request the next chunk? Is it just another read command or some character? Do we actually need to send the prompts? Or as I suspect, is the CR (or EOI for BINARY PROGRAM and BINARY DATA) sufficient to signal the end of the chunk? Secret also seems to behave like BINARY (i.e. with HEX conversion), so I presume EOI would apply here as well?

Any clarifications would be helpful and I do apologise for all the questions. I have also been busy looking at the Tektronix manuals today and clarifying some things including making a comparison between 4050 GPIB commands (4050 BASIC reference) and the ones supported on the 4924. This has proved to be enlightening and I understand now what you mean about the TLIST command.

BTW, I have pushed the latest version of the code up.

[mmcgraw74]

You are correct, the conversation is between the BASIC program and the Emulator with the Tektronix as the controller for GPIB traffic based on the BASIC command being executed.

FIND for the Emulator involves getting one filename at a time from the current SDfat directory by SDfat index and extracts the first number from the filename (which the filename is in the format of the Tektronix tape file HEADER) which is the 4924 tape filenumber.  Since SDfat does not necessarily store files in filename sequence, my code for the emulator iterates through files from first SDfat index until the extracted filenumber equals the requested FIND filenumber.  The serial output of filetype is just for debug.  There is no Emulator response required for the FIND command.  The Tektronix sends EOI with the CR to terminate the FIND command as shown in the 4924 service manual section starting on page B-5 with 4051 MODE GPIB sequences.  The 4924 doesn't send anything to Tektronix for this command.

The fragment of FIND code you posted is just determining the file type from a specific character in the HEADER (SDfat filename).
The returned char for the FIND is just the filetype for Emulator use if the next call is a READ.

I have merged several fields to get the filetype returned if this call is successful in FINDing the requested filenumber:
B = Binary Program (encoded in Hex)
P = ASCII Program
S = ASCII Secret Program (encoded in Hex)
D = ASCII Data file
H = Binary Data file (encoded in Hex)
N = New file (file created by MARK command, but not written to yet.  Tektronix updates the header when file is written depending upon the command: SAVE, BSAVE, WRITE, WBYTE)
L = Last file

Code: [Select]

char tek_FIND(int num) {
    // char f_name[46];  //the filename variable
    /*  FINDs and OPENs file (num)
         Returns: string result= "A" for ASCII, "H" for HEX (Binary or Secret file), "N" for Not Found
         FIND iterates through each file in a directory until filenumber matches num
         since SdFat file index is not sequential with Tek 4050 filenames
    */

    if (!dirFile.open(directory, O_RDONLY)) {
        sd.errorHalt("Open directory failed");
    }

    for (int index = 0; index < nMax; index++) { //SdFat file index number

        // while (n < nMax ) {
        file.openNext(&dirFile, O_RDONLY);
        // Skip directories, hidden files, and null files
        if (!file.isSubDir() && !file.isHidden()) {

            file.getName(f_name, 46);

            int filenumber = atoi(f_name);

            if (filenumber == num) {
                // debug print the entire file 'header' with leading space, and CR + DC3 delimiters
                cout << F(" ") << f_name << "\r ";

                // all BINARY files are in HEX format
                if ((f_name[7] == 'B') && (f_name[15] == 'P')) {
                    dirFile.close();  // end of iteration through all files, close directory
                    return 'B'; // BINARY PROGRAM file
                } else if ((f_name[7] == 'B') && (f_name[15] == 'D')) {
                    dirFile.close();  // end of iteration through all files, close directory
                    return 'H'; // BINARY DATA file ** to read - parse the data_type
                } else if (f_name[25] == 'S') {  // f_name[25] is location of file type SECRET ASCII PROGRAM
                    dirFile.close();  // end of iteration through all files, close directory
                    return 'S'; // SECRET ASCII PROGRAM file
                } else if (f_name[15] == 'P') {  // f_name[15] is location of file type (PROG, DATA,...)
                    dirFile.close();  // end of iteration through all files, close directory
                    return 'P'; // ASCII PROGRAM file
                } else if (f_name[7] == 'N') {  // f_name[7] is location of file type (ASCII,BINARY,NEW, or LAST)
                    dirFile.close();  // end of iteration through all files, close directory
                    return 'N'; // ASCII LAST file
                } else if (f_name[7] == 'L') {  // f_name[7] is location of file type (ASCII,BINARY,LAST)
                    dirFile.close();  // end of iteration through all files, close directory
                    return 'L'; // ASCII LAST file
                } else {
                    dirFile.close();  // end of iteration through all files, close directory
                    return 'D'; // ASCII DATA file, also allows other types like TEXT and LOG to be treated as DATA
                }
            }
            //f_name[0]=0; // clear f_name

            if (file.isDir()) {
                // Indicate a directory.
                cout << '/' << endl;
            }

        }
        file.close();  // end of iteration close **this** file

    }
    cout << F("File ") << num << " not found" << endl;
    f_name[0] = '\0';  // clear f_name
    dirFile.close();  // end of iteration through all files, close directory

    return 'O'; // File num NOT OPEN (or NOT FOUND)
}


[WaveyDipole]

Sorry we seem to be at cross purposes and it is my fault! The snippets of code that I pasted in the last post are from the READ function and that is the one I was interested in when writing that post. I stated 'FIND' in error. Mea culpa!

Nevertheless, I do appreciate the provided detailed explanation of the FIND function as I had similar questions about that in a previous post. This clarifies things for me and confirms what I had already concluded so was very helpful.

Sometimes the smallest problem can send one around a 'needle in a haystack' type of search and the case in point was the problem with the ERROR function that was returning the result twice. I spent all day today trying to figure that one out and it turned out to be down to a mis-timing of the EOI signal. The HPIB standard calls for it being sent "with" the last character. My code was sending it once the handshake on the last character was complete but as the LA traces showed, technically this was AFTER the last character an too late. It needed to be sent during the handshake so that its timing coincides exactly with the receiver reading the character

This led to a conundrum: how does the program know that the current character being sent is the last one? With a fixed buffer and known length of the data this is easy. The last character is the length of the data - 1 (C++ arrays start at 0). But what if we want to send multiple chunks (buffer full) of data in succession as when sending binary data, e.g. a binary program? Or what if the data is being read from a file?  How do we know that the character we currently reading is the last one before EOF? Once we reach EOF and drop out of the read loop it is too late....

That's the problem I need to solve next. I have solved the problem with the ERROR function and it now sends a single result. CD and FIND still work although a couple of other errors came to light, but at least that allowed me fix them. I now need to have a close look at the READ_one function as this is where the EOF conundrum will come into play. It has been suggested that the peek() function might be helpful, but I will now leave this for another day.

[mmcgraw74]

I saw this morning that you had uploaded a version 5.20 two days ago, so I downloaded it and tried a couple of things.

FIND @5:1 may have worked, but I see a Tektronix GPIB transaction after that command that I need to look at.  It may be a HEADER command request - I don't know if the Emulator HEADER code is in v5.20.

I tried OLD @5: after the FIND and the Tektronix HUNG.  I captured a trace for that too and will upload it after I answer your questions just posted.

This led to a conundrum: how does the program know that the current character being sent is the last one? With a fixed buffer and known length of the data this is easy. The last character is the length of the data - 1 (C++ arrays start at 0). But what if we want to send multiple chunks (buffer full) of data in succession as when sending binary data, e.g. a binary program? Or what if the data is being read from a file?  How do we know that the character we currently reading is the last one before EOF? Once we reach EOF and drop out of the read loop it is too late....

I believe the answer depends upon which command is being handled:

For example:
OLD - I believe the Tektronix will expect one ASCII character string - CR delimited at a time from the Emulator, with the Emulator asserting EOI ONLY when EOF is reached.  The Tektronix will have to parse the character string for syntax errors, then encode and store the tokenized version of the string into memory, before accepting more characters.  When we get OLD working, I think we will find the Tektronix delaying its acceptance of the next character from the Emulator until it has finished processing the last string.  What I see in captured ASCII program data blocks from tape is just a CR character on the line following the last program statement.  I believe this causes the Tektronix to terminate the OLD statement.  However I suspect that if the last program statement ends at the end of the file that EOF (ASCII 127) from the Emulator with EOI asserted will also terminate the OLD statement.

OLD for Binary Programs should be similar with the Tektronix holding off accepting another byte from the Emulator while is stores the previous tokenized statement (I don't know what the BASIC tokens are, nor what terminates a tokenized statement).  Same termination should apply - Emulator will only terminate on EOF but Tektronix may terminate OLD earlier based on NULL statement logic.

[mmcgraw74]

I'm still having trouble getting the OLD command to work after a FIND command.

I don't see the emulator posting a debug message, although I see the logic analyzer trace showing the correct primary address of 5 and secondary address of 4 for the OLD command.

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

[WaveyDipole]

I had added OLD but hadn't got around to actually testing it, so I couldn't really confirm whether it should be working at this point. Bearing in mind the problem with EOI discovered yesterday, I have been having a working on and testing the OLD function this morning, using file 1 which contains a short BASIC program (ASCII data) as an example. The function is relatively short so was an ideal candidate to test reading a file and sending EOI with the last character of the file. While working on it I found as follows:

Firstly, the function uses the getline() method which reads up to the end of line delimiter. This means it works only for ASCII files. Is that what was intended?

Secondly, the getline() method strips the CR line terminator so it was necessary to include a bit of code to add a CR back to the end of each line before sending it over GPIB. When sending ASCII data over GPIB,  ASCII line terminators are ignored and striped and a line terminator (LF, CR or CR+LF) appended as determined by the setting of the EOS parameter. However, when using EOI as a terminator, all characters are sent without any processing. As a result, the CR was getting stripped by getline() but no line terminator was being appended in accordance with the setting of EOS. Without the CR being added back in, text would be received at the other end without line terminators.

Finally, if the function is intended to deal with ASCII data only, then it should probably be restricted to working on only those file types it can support. My initial thought was to look at the f_type variable and proceed only if it indicated certain file types such as P, N, L, D and possibly S? On the other hand, if it needs to work on both ASCII and BINARY, it may as well be re-written to treat all file types as binary data. That way, it doesn't matter what file type it gets called on and will simply return the entire contents of the file asserting EOI on the last character. It would probably be a matter of using read(buffer, bufferlength) where bufferlength is set to 'line_buffer_size' instead of getline(). There would also be no need to add in the stripped CR. I will experiment with this but won't change it for now.

In the meantime I have just pushed 0.05.23 which includes all the work yesterday and the work just done this morning on the OLD function up to the repository. The functions CD, FIND, ERROR and OLD should (theoretically) be working. If any are not working, I would be interested in seeing the serial console output on the emulator.

It does not surprise me that the Tek computer tokenizes the BASIC keywords. This technique is used to save memory space on other computers of the period.

[mmcgraw74]

The Tektronix OLD command only works with ASCII files.  Tektronix made an optional ROMpack for the 4051 to add BOLD and BSAVE commands for files to the internal tape - but there are not equivalent commands for the external 4924 tape, so we can ignore the need to support BINARY programs - and none of the 100's of programs I have recovered have been in BINARY form.

We do need the Emulator to terminate ASCII program lines with CR, as I did with my continuedDev version, but the EOI would only be asserted by the Emulator on a GPIB byte if the end of SDfat file was reached.  During the sending of ASCII program statements to the Tektronix, the Emulator would try to send a character at a time - with the GPIB handshaking protocol indicating whether the Tektronix was ready for the data, until the Emulator reaches the end-of-file or the Tektronix terminates the command as the controller (which it will do upon a BASIC parsing error or empty line with a CR).

In my experiments yesterday - I don't believe the Tektronix requests the file HEADER after the FIND and prior to the OLD command unless the PROGRAM requests the HEADER (which none of mine do).  I think the Tektronix BASIC parser will terminate the OLD command if the input string of characters is not a proper BASIC statement.

I will check out your new 5.23 version today!

[mmcgraw74]

I have some good news and some bad news.

First the good news:

• FIND is working  (FIND @5:1 and FIND @5:2)
• CD is working     (PRINT @5,19:"UTILITIES")
• READ is working  (READ @5:A$)

Now the bad news:

• OLD isn't working  (PRINT @5,4:  this got the result in the console screenshot, no hang on the Tektronix - but no program.  OLD @5: showed nothing on the console, see the waveform output - makes no sense)

Here is the console screenshot:



I couldn't get the OLD @5: command to work so what you see in the console screenshot was PRINT @5,4: which puts the Emulator in LISTEN mode   The emulator serial output shows it decoded the primary address of 5 and the secondary address of 64, and although the serial output shows it started the handler - no data was sent to the Tek, likely because the Emulator was addressed to LISTEN

I know I used OLD @5: with my 4924 and the command worked, but the 4924 is not working now   I found a -12V fuse that was open and the +5V output reads 10V   Looks like the 5V filter capacitor has died   I don't know if the logic is fried, but I'll put a different capacitor in it tomorrow without connecting the logic board and see if I can get the proper 5V output.

Here is the logic analyzer listing for OLD @5:

Code: [Select]

HPIB STATE  -  State Listing                                                   

                                                                     
Label    >   Time    DATA ATN NDAC NFRD EOI REN SRQ IFC DAV
Base     > Relative  Hex  Bin Bina Bina Bin Bin Bin Bin Bin
__________ _________ ____ ___ ____ ____ ___ ___ ___ ___ ___

    -11         8 ns   80   0    1    1   1   0   0   1   1
    -10         8 ns   80   0    1    1   1   0   0   1   1
     -9         8 ns   A0   0    1    1   1   0   0   1   1
     -8     4.048 us   A0   0    1    0   1   0   0   1   1
     -7         8 ns   A0   0    0    0   1   0   0   1   1
     -6     23.50 us   A0   0    0    1   1   0   0   1   1
     -5     29.39 us   80   0    0    1   1   0   0   1   1
     -4        96 ns   82   0    0    1   1   0   0   1   1
     -3         8 ns   8F   0    0    1   1   0   0   1   1
     -2        40 ns   9F   0    0    1   1   0   0   1   1
     -1         8 ns   DF   0    0    1   1   0   0   1   1
      0     38.42 us   DF   0    0    1   1   0   0   1   0 Primary Addr (20H) 32 decimal Device 0 Listen Address
      1     70.60 us   DF   0    0    0   1   0   0   1   0
      2     11.45 us   DF   0    1    0   1   0   0   1   0
      3     41.00 us   DF   0    1    0   1   0   0   1   1
      4     23.53 us   DF   1    1    0   1   0   0   1   1
      5     27.06 us   DF   1    1    0   0   0   0   1   1
      6     27.18 us   DD   1    1    0   0   0   0   1   1
      7         8 ns   99   1    1    0   0   0   0   1   1
      8       168 ns   B9   1    1    0   0   0   0   1   1
      9     14.90 us   B9   1    0    0   0   0   0   1   1
     10     20.64 us   B9   1    0    1   0   0   0   1   1
     11        32 ns   B9   1    1    1   0   0   0   1   1
     12     30.06 us   B9   1    1    1   0   0   0   1   0
     13     39.26 us   B9   1    1    1   0   0   0   1   1
     14     21.97 us   B9   1    1    1   1   0   0   1   1
     15     70.66 us   B9   0    1    1   1   0   0   1   1   Primary Addr (46H/70 dec) Device 6 ?? Talk Address
     16     39.78 us   B9   0    1    0   1   0   0   1   1                                   ---
     17         8 ns   B9   0    0    0   1   0   0   1   1
     18     23.50 us   B9   0    0    1   1   0   0   1   1
     19     22.69 us   BF   0    0    1   1   0   0   1   1
     20     37.94 us   BF   0    0    1   1   0   0   1   0   Sec Addr (40H/64 dec) ?????
     21     77.96 us   BF   0    0    0   1   0   0   1   0
     22     11.43 us   BF   0    1    0   1   0   0   1   0
     23     34.71 us   BF   0    1    0   1   0   0   1   1
     24     37.66 us   BF   0    0    0   1   0   0   1   1
     25       152 ns   FF   0    0    0   1   0   0   1   1
     26     31.46 us   FF   1    0    0   1   0   0   1   1
     27     50.51 us   FF   1    0    1   1   0   0   1   1

Time Printed: 08 Jul 2021 13:00:53

It makes no sense at all.

I need to repair my 4924.

[WaveyDipole]

I have some good news and some bad news.

First the good news:

• FIND is working  (FIND @5:1 and FIND @5:2)
• CD is working     (PRINT @5,19:"UTILITIES")
• READ is working  (READ @5:A$)

Read works only inasmuch as it reads a line from the file and sends it to the serial port. The code hasn't been updated yet to send to GPIB.

Now the bad news:

• OLD isn't working  (PRINT @5,4:  this got the result in the console screenshot, no hang on the Tektronix - but no program.  OLD @5: showed nothing on the console, see the waveform output - makes no sense)

Can't figure the LA output at the moment either. What GPIB address is the Tek on?
I don't suppose you have another device connected with the GPIB address 6?
Is there any chance you can try this again with #define DEBUG_DEVICE_ATN un-commented and show the console output please?

Incidentally, I did have a look at the 4051 documentation, in particular Appendix B of the 4924 service manual which provides a table of GPIB command sequences, including '"ALTERNATE" MODE GPIB SEQUENCES' when a 4924 is used. Given the command sequences in your post, am I correct in assuming that we are using standard 4051 mode and not the "alternate" mode? In any case, its the odd number (CPA) that should be greater than the even (DPA) number so this still doesn't make sense.

I couldn't get the OLD @5: command to work so what you see in the console screenshot was PRINT @5,4: which puts the Emulator in LISTEN mode   The emulator serial output shows it decoded the primary address of 5 and the secondary address of 64, and although the serial output shows it started the handler - no data was sent to the Tek, likely because the Emulator was addressed to LISTEN

Yes, that seems to make sense. If the emulator is being asked to LISTEN (MLA) then it will switch to a listening state (data lines in input_pullup state) so will not be in a state to send anything.

BTW, I have read up a bit more on the OLD/APPEND command and now understand that it is specific to ASCII programs as you pointed out so I guess OLD needs to be adjusted to respond only to files of type 'P'? However, that is aside from the problem of why there was no response in the first place.

I know I used OLD @5: with my 4924 and the command worked, but the 4924 is not working now   I found a -12V fuse that was open and the +5V output reads 10V   Looks like the 5V filter capacitor has died   I don't know if the logic is fried, but I'll put a different capacitor in it tomorrow without connecting the logic board and see if I can get the proper 5V output.

I don't have the circuit diagram but lets hope that there is nothing more than just a faulty filter capacitor, although it does sound like maybe the 5V regulator has failed? Hopefully none of the logic ICs have been affected.

[WaveyDipole]

Just came across this Tek 4051 on eBay. Wondering whether it is worth a punt?
Would make it easier to test things, but just wondering why the screen is fully lit like that?

https://www.ebay.co.uk/itm/133812508227

Its over a couple of hours drive from me to pick it up (assuming I can "win" it) so I don't want to travel that far it its not repairable.
 

[mmcgraw74]

Yes, well worth it.  All Lights on the Right Mean the ROMs didn't boot, same with the screen.  I can help you fix it.

You can make an offer for less - he may take it!

Monty

[WaveyDipole]

Was wondering whether it might be a symptom of not booting from ROM(s) and nothing more serious than that. Sometimes ICs need re-seating but ROMs can go corrupt. They can usually be replaced if one can get hold of either an image file and has the equipment to burn it onto a new EEPROM chip, or already prepared EEPROM chips.

I repaired a Tek 468 oscilloscope a while back. It had a dead CPU and faulty clock but as it turned out, the ROMs were still good. I don't have an EEPROM burner but managed to obtain both image files and ready burned replacement ROMs chips. The original chips are unobtainable so the replacement chips being alternatives and having a slightly different pinout, required adapters, but they do work. For now I have left the originals in place and am keeping the newer chips as spares in case the originals should fail. The scope otherwise required very little maintenance and seems to work pretty well with measurements being pretty much spot on.

Regarding this project though, I spent a lot of time yesterday browsing through the manuals and your implementation notes on the GitHub repository to better understand the header and binary formats and other bits and this will all come into play in the next stages of development. I do think, however, that I am getting to a point where it will start to become more difficult to test things so having real Tek hardware would be useful.

I was wondering, regarding the filename/header format, for example:

9      ASCII   PROG [AlphaSort]   14

In your file names, what does the last two digit number represent?
Which part is considered the "comment" string? Is it the bit in square brackets?
Are you planning on sticking with 44 characters for the file header/name?
The filenames in the examples seem to vary between 34 and 36 characters in length but I notice you have defined f_name as 46 characters long which I assume is because Tek header = 44 characters plus CR + '\0' ?
Just seeking to understand.

BTW, apparently the 4051 is up for nearly double the starting price elsewhere so I expect the seller will be looking for somewhere around that price. It also turns out the drive may be between 3.5 - 4 hours so up to an 8 hours return trip. Not sure it is worth it but still thinking about it and will probably wait to see how the auction works out. A courier option would have been more convenient.

[mmcgraw74]

Was wondering whether it might be a symptom of not booting from ROM(s) and nothing more serious than that. Sometimes ICs need re-seating but ROMs can go corrupt. They can usually be replaced if one can get hold of either an image file and has the equipment to burn it onto a new EEPROM chip, or already prepared EEPROM chips.

I repaired a Tek 468 oscilloscope a while back. It had a dead CPU and faulty clock but as it turned out, the ROMs were still good. I don't have an EEPROM burner but managed to obtain both image files and ready burned replacement ROMs chips. The original chips are unobtainable so the replacement chips being alternatives and having a slightly different pinout, required adapters, but they do work. For now I have left the originals in place and am keeping the newer chips as spares in case the originals should fail. The scope otherwise required very little maintenance and seems to work pretty well with measurements being pretty much spot on.

The ebay seller posted his 4051 on the facebook "Tek 4051 BASIC" forum last month and asked what the problem could be.  I indicated the likely issue was one or more DRAMs were defective and the ROM memory test failed.  I suggested what he could do to debug and the made no more posts.  I suggested that he remove the expansion memory board shown in his photos to see if base memory in the 4051 was ok.  If that didn't help, then likely the problem was in base memory and he could substitute socketed memory from the expansion board into the main board until the main board worked.

Regarding this project though, I spent a lot of time yesterday browsing through the manuals and your implementation notes on the GitHub repository to better understand the header and binary formats and other bits and this will all come into play in the next stages of development. I do think, however, that I am getting to a point where it will start to become more difficult to test things so having real Tek hardware would be useful.

I was wondering, regarding the filename/header format, for example:

9      ASCII   PROG [AlphaSort]   14

In your file names, what does the last two digit number represent?
Which part is considered the "comment" string? Is it the bit in square brackets?
Are you planning on sticking with 44 characters for the file header/name?
The filenames in the examples seem to vary between 34 and 36 characters in length but I notice you have defined f_name as 46 characters long which I assume is because Tek header = 44 characters plus CR + '\0' ?
Just seeking to understand.

Yes, the comment in the file 9 header is in square brackets.
The last number in the header is the number of 256 byte blocks. 
Tek allowed multiple digits for this number for large data files.

The tape file header format is shown in the 070-2056-01_4050_BASIC_Reference_Manual Jul 79 on bitsavers.org page 7-42.
The \0 is supposed to be a NULL character.
The Tektronix programs to edit the file header added a CR and NULL character to the end of the header.

 

[mmcgraw74]

BTW, apparently the 4051 is up for nearly double the starting price elsewhere so I expect the seller will be looking for somewhere around that price. It also turns out the drive may be between 3.5 - 4 hours so up to an 8 hours return trip. Not sure it is worth it but still thinking about it and will probably wait to see how the auction works out. A courier option would have been more convenient.

You might send him an email - and ask if he could meet you halfway.
Since the auction includes "Make an offer", this means the seller might take a lower offer.

[mmcgraw74]

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! (see first photo).



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.

Next two photos show that if a complete program (/ROOT/1/) is loaded - it runs:





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.

I thought the READ code worked - because of the serial debug messages, but READ hung on both the 4052 and 4054A and it is my mistake.  The READ command ONLY supports BINARY data, not ASCII data - and I was trying to READ ASCII data and program files with the Emulator.

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.

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).

I haven't repaired my 4924 tape drive yet, but will work on that now.

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):