Tektronix 4924 Tape Drive Emulator

[mmcgraw74]

I get that message if the Tape Emulator is not powered and I do an emulator command.

[WaveyDipole]

That would make sense since, in effect, there would be no devices on the bus. In this case, the emulator is powered. I have debugs enabled to allow me to see any byte that the Tek may send but I am seeing nothing at all being sent. I did think that maybe connecting my DMM and using READ or RBYTE might result in some data being read, but unfortunately I got the same error. I am just in the process of reviewing the GPIB circuitry.

[mmcgraw74]

I checked my photos of the Tape Emulator board I sent you - and I mounted the GPIB connector on the bottom side of the board in the same orientation as my board.

Here is one of those photos.  Did you install the 644 board the same direction as my board?  The 644 TX pin should be in the upper right corner of the Tape Emulator board.

[mmcgraw74]

I just rechecked the error message I get on my 4054A when I try a GPIB command to address 5 with the Tape Emulator plugged in but not powered - and it was the error 69.
But then if I plug in the power to the emulator, the commands work.

[WaveyDipole]

Thanks for checking. I did some more tests with the logic analyser and the results are curious. I posted the details on VCFED but I think there may be another hardware fault. I will be removing the main board again to have a closer look.

[WaveyDipole]

Can I just confirm something with the emulator board. I notice at least 3 pins on the SD card header are taken from the 6-pin header but the pins on the Panaduino board are facing the wrong way up. From your photos I can see that you removed the header and I presume reversed it? Unfortunately the pins do not quite line up. Its only my a millimetre or less but so they might bend but I may end up using short wires instead. I'm not sure I am going to be able mount the SD card reader the same way as you did yours as the pinout is somewhat different to the Pololu version but the pins are in the same order so aside from a slight spacing issue it shouldn't be too much of a problem to solder it in. Its just that pins will have to be bent slightly left or right. I presume however, that those 3 pins with tracks to the SPI header do need connecting up?

[mmcgraw74]

I didn't have details on the exact location of the 6-pin header on the Pandauino board, so the hole locations in my board may not line up exactly.

I didn't remove the header from the board, I just loosened each of the pins and pushed each pin down from the top of the board to penetrate the Tape Emulator PCB holes.
I did one pin at a time - starting with the ones toward the center of the board and soldered that pin to the Tape Emulator board.

If you don't have a Pololu micro SD adapter - you don't need to move the six pins and should be able to jumper those pins to your micro SD adapter and then add one more jumper wire from the CS pin on the 1284 board to your micro SD adapter.

The six holes in the Tape Emulator are in the same order as the six pins on the 644/1284 board.

[mmcgraw74]

Can I just confirm something with the emulator board. I notice at least 3 pins on the SD card header are taken from the 6-pin header but the pins on the Panaduino board are facing the wrong way up. From your photos I can see that you removed the header and I presume reversed it? Unfortunately the pins do not quite line up. Its only my a millimetre or less but so they might bend but I may end up using short wires instead. I'm not sure I am going to be able mount the SD card reader the same way as you did yours as the pinout is somewhat different to the Pololu version but the pins are in the same order so aside from a slight spacing issue it shouldn't be too much of a problem to solder it in. Its just that pins will have to be bent slightly left or right. I presume however, that those 3 pins with tracks to the SPI header do need connecting up?

I missed responding to your last question.

Yes the three pins with traces to the 6-pin header need to be connected.

Here is my wiring for that board:

[WaveyDipole]

Thanks. I have now built the Panaduino based Tape Emulator board. It seems to be working. I had to change a couple of things. One was the compiled clock speed which is 16Mhz on the Panaduino, but was 20MHz on the development board. The other was to change the SD card CS pin number back to 4. After that was done, the SD card could be read and I tried the Artillery game again. It loaded fine and all of the commands, FIND, PRINT and OLD worked OK each time. I suspect you are correct in that the problems I was having with the other setup might have been down to wiring. I specifically suspect the cheap breadboard.

I have had to use two long Type B USB cables, one for the Emulator and one for the Cypress LA board, which I fortunately already had to hand. The advantage with the Panaduino board is that there is no need for any heavy GPIB cables.

On another note, it seems that Tek MaxiROM has now disappeared from eBay. I had it on my watch list since I purchased the 4051 and was intending to purchase it once the computer was repaired and now that the computer is working I had planned to wait for the new month which is just a few days away to make the purchase into next months budget. I have contacted the seller to find out whether there will be any more made available, but with it being a crowd-sourced project and the price being reduced from $50 to $40 I fear that was the last of the stock. I am waiting for them to get back to me and will keep an eye out anyway.

[mmcgraw74]

Great news getting your 4051 repaired and the Tape Emulator board is working.  Now it should be easier to debug the remaining code

Too bad about the MAXIROM cartridge no longer posted on EBAY.  I did post a note on Facebook as a couple of the members of the Tek 4051 BASIC group do volunteer work for the vintagetek museum - maybe they can help.

[WaveyDipole]

Thank you. I got a reply back from the seller, vintagetek (Bob Haas), as follows:

Not knowing what the demand would be, we only made a small quantity for our own internal needs and some for sale. The demand has not been great, so we have no plans at present to make more. If we get more inquiries we sill start another batch.

Unfortunately this confirms what I suspected. I am hoping that someone on Tek 4051 BASIC can help.

I asked them whether the technical details and gerbers are available so that I can make at least the PCB myself but am not holding out much hope. The online image has the IC number blurred out and even if I could find out what it was I would still need the ROM content. I imagine this is to deter clones from Far East sources which is understandable.

[mmcgraw74]

With such small volume - I don't see clones from the Far East being an issue.

Bob Haas was the hardware engineer on the Tektronix 4052/4054 and then the 4041 computers.  Great guy.

Bad timing on them selling all the modules.  It might be possible to PM one of the facebook folks that ordered the MAXIROM to dump the ROM contents.

The new board looks very simple - 20V8 GAL for decode and one ROM.  Looking at one of the photos they posted, the previous board had four 27128 EPROMs, so a 27512 bay be the part on the new board.

The 4051 ROM Packs were limited to 8KB each (up to four 2Kx8 ROMs or EPROMs). 

So each 27128 can hold two of the 4051 ROM Packs - not the Hi/Lo labels on each of the original MAXIROM EPROMs.  This provides up two eight ROM Packs in the four 27128 or in a single 27512.

Jos Dressen created the 4052 Multi-Function ROM Pack - which I have which used an AMD 27C010 1-Megabit EPROM to store the images.

If you can get the MaxiRom image - we may be able to modify one of the extra PCBs Jos sent me to make a 4051 MAXIROM.  Jos' board also included a 6850 serial interface.

I'll do some more checking around and try to find someone who purchased a MAXIROM and would download the ROM image.

[WaveyDipole]

I got a reply from VintageTek to my request for gerbers and technical information. They didn't send me any technical information, but just the following:

We have ordered another batch of boards. We will be relisting the item when we have the boards.

Bob Haas
vintageTEK ebay Sales Manager

Perhaps they have received another inquiry or needed some more for their internal use. I appreciate it must be difficult when demand is very limited and difficult to predict. I will be keeping an eye out on eBay for them to re-appear.

BTW, I thought I could make out the sequence AL20V8 on the photo of the IC, but a search for that didn't find anything of interest. Adding the 'G' makes all the difference....

I did come across a 4051E01 ROM Expander on eBay but at $225 that's quite a lot of money.

The board by Jos sounds interesting and I would have liked to know more, but I guess I should now wait for the MaxiROM to re-appear.

[mmcgraw74]

Great news!

Jos' board was designed for the 4052/4054 ROM Packs which are not compatible with the 4051, so a lot of changes would be required to support a 4051 - and since Jos doesn't have one, he didn't offer one.

The MAXIROM specifically targets the 4051 - so you wouldn't need a 4051 ROM expander or 4050 ROM expander that supported both 4051 and 4052/4054 computers.

[mmcgraw74]

Great news - I fixed my 4924 Tape Drive!

I replaced the power supply 5V output pass transistor - no change.

I have an older 4923 Tape Drive that I have been using for spare parts - I swapped the entire power supply board (same assembly part number - same components) - that worked.

4924 Tape GPIB address DIP switches set to 4 for primary address and 4051 command mode.

First test:

FIND @4:2
INPUT @4:A$

I heard the FIND @4:2 cause the tape drive to seek to file 2, which is an ASCII program called TECO (text editor for 4052 Assembler program in file 1).

I heard it INPUT the first line of the file into A$.  Yes, the Tektronix supports INPUT from ASCII program OR DATA files.

I captured the entire FIND followed by INPUT of one CR terminated character string in one trace - complete trace listing zip file is  attached.

(Attachment Link)

I also captured four waveforms from this trace:

First one shows the FIND @4:2 command
Second one shows the INPUT @4:A$ command
Third one shows the A$ being sent to the Tektronix
Fourth one focuses on the end of the INPUT command

(Attachment Link)

(Attachment Link)

(Attachment Link)

(Attachment Link)

Here is a photo of the 4052 screen with the text returned from the INPUT command.

The first two lines highlighted in yellow showed me the command worked, but I forgot to trigger the logic analyzer.

The last two lines were typed with the logic analyzer triggering on the first DAV, and both commands were captured and I then stopped the logic analyzer, save the setup and data, captured the waveforms and the trace listing.

(Attachment Link)

Last photo is the working 4924 tape drive on top of my 4052 computer.  The 4052 Assembler tape (3M DC6250 tape with working drive belt) is in the 4924.

I can take more logic analyzer traces tomorrow.

This should help us figure out how to support all the Tektronix tape commands

(Attachment Link)

John,

I went back to this post (Reply #205 on previous page of this thread) where I was able to get my 4924 Tape Drive to work for a short time.

I had the 4924 FIND @4: 2, then INPUT @4: A$.

As I reported in that post - file 2 is a TECO text editor program file - yes Tek BASIC can INPUT from an ASCII program file.

I posted a zip file "4924FINP.zip" in that thread, but did not decode the cycles.

Since the TAPE Emulator is not yet working on INPUT - I spent some time manually decoding the logic analyzer trace file and am attaching that zip to this message.

 4924FINP - decoded.zip (6.49 kB - downloaded 44 times.)

This program file can be found on my repo here:

https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/blob/master/4052A-4054A-Assembler/4052A-Assembler%20uni%20format/TECO-editor.uni

The INPUT @4: A$ command only inputs the first CR delimited text string, and the decoded trace listing is a match for the first line of the program.

Following the CR sent by the 4924, I see Tek BASIC assert ATN and Tek BASIC send UNTALK then UNLISTEN and then Tek BASIC deasserts ATN and the transfer is complete.

Logic Analyzer screenshots of this 4924 transaction are in the post #250

[mmcgraw74]

Other items of interest:
the SRQ line stays asserted the entire time. Is there an error condition requiring attention again? In any case, it doesn't seem to have impeded the functioning of the drive so probably does not have a bearing.
there is no EOI during INPUT. The single EOI that does appear comes at the end of the FIND command. Is this because INPUT has not reached the end of the file at this point? If so, then that might explain why there is no EOI.
REN seems to get un-asserted at the end of the transmission. Other signals except SRQ get un-asserted at the same time so this looks like the bus going idle. The emulator doesn't have features that would require remote control so this should have any effect.

I am not sure what all of this means yet but we do need to compare that against what the the current code is doing. I think I would like to start seeing what the trace from just the FIND command looks like using the current emulator code please.

The SRQ signal must be miswired.  I shredded a ribbon cable to connect a GPIB connector to the HP 10342B Bus Preprocessor that I was hoping to use with the logic analyzer for disassembling the GPIB traces.  I haven't gotten the 10342B to work - so I plugged a header pin connector into the ribbon cable and wired the logic analyzer pin by pin.  I don't see the Tek seeing an SRQ asserted - so I think it is safe to ignore that signal in the traces for now.

The Tek BASIC INPUT command does not read a whole file, nor a whole record.  The INPUT command inputs ASCII strings or ASCII numbers and is stopped (delimited) by the CR in the data.  No EOI is needed, since the Tek BASIC does not indicate how many variables are in the INPUT command - the ASCII data is input until a CR is received and Tek BASIC will end the command with UNTALK/UNLISTEN.

REN is always asserted by Tek BASIC when it starts a program or an immediate command and is deasserted when the program ends (see the 4051 GPIB HW Supp page 1-8, item 10c).  The manual also indicates that when REN is asserted - device front panels are disabled and the devices look for commands on GPIB.

On a sad note - my 4924 only worked the first time I powered it on.  I had to move it and disconnected power and it no longer works

Also, when I returned from vacation and powered on my 4052 - I can't read the screen, but the computer is working.  I think it is a high voltage problem because I can see the blinking cursor and briefly see typed characters which quickly fade out.

My 4054A computer is working, but I would have to move the logic analyzer to the other room to connect to the 4054A if we need more traces.

[WaveyDipole]

The SRQ signal must be miswired.  I shredded a ribbon cable to connect a GPIB connector to the HP 10342B Bus Preprocessor that I was hoping to use with the logic analyzer for disassembling the GPIB traces.  I haven't gotten the 10342B to work - so I plugged a header pin connector into the ribbon cable and wired the logic analyzer pin by pin.  I don't see the Tek seeing an SRQ asserted - so I think it is safe to ignore that signal in the traces for now.

Ah, that explains the SRQ signal then. I agree. It can be ignored for now.

The Tek BASIC INPUT command does not read a whole file, nor a whole record.  The INPUT command inputs ASCII strings or ASCII numbers and is stopped (delimited) by the CR in the data.  No EOI is needed, since the Tek BASIC does not indicate how many variables are in the INPUT command - the ASCII data is input until a CR is received and Tek BASIC will end the command with UNTALK/UNLISTEN.

That is understood. EOI is sent only when the end of the file is reached. I did some work on PRINT and INPUT as they are reciprocal and for working with text data files. I have PRINT writing raw data to file on the SD card and I think I may have nailed the problem with INPUT causing the Tek to get stuck and requiring a BREAK. In addition to asserting EOI at the end of the file, it also has to send the EOF character (FF). That signals the Tek to end the transmission with UNT and UNL, otherwise it just sits there expecting more data. What I still don't have is variables being read back correctly. For example:

PRINT@5:A$,B
INPUT@5:A$,B

I expected this would write a string and a number to an ASCII data file and read it back, but A$ ends up containing the string with the number tacked on to the end. I notice from the tek 4050 Series Basic Reference, that the PRINT command makes use of formatting options using the USI and IMAGE commands. The text states that the format string optionally "can be" specified in an IMAGE statement, but doesn't state whether formatting using the USI command is mandatory. I had experimented with the USING command to format the output of four variables which does work, but since there seems to be no corresponding command to format the variables for the INPUT statement, it all ends up in the first string variable anyway.

Do you have a definitive test I could use for the readback of variables? I found the ADVKEYS data file we used for testing previously, but I don't have the program that can read back that data and which I presume was tested and working properly on one of your Teks? Would it be possible to have a copy please?

REN is always asserted by Tek BASIC when it starts a program or an immediate command and is deasserted when the program ends (see the 4051 GPIB HW Supp page 1-8, item 10c).  The manual also indicates that when REN is asserted - device front panels are disabled and the devices look for commands on GPIB.

Interesting observation and I noticed the same behaviour of REN on the handful of traces I carried out over the last couple of days. I hadn't linked it to a the program being executed, but I have only been running individual commands at the cursor which individually can be considered a one line program. REN gets asserted a few milliseconds before ATN and gets de-asserted a few milliseconds after the final ATN during which UNT + UNL are sent. After reading your comment I tried running a short two line Hello World program on the 4051 with no GPIB comms and monitored on the LA. I do see the same behaviour as you mention. I believe the panel gets disabled on the device being addressed. certainly that's what happens with my DMM.

On a sad note - my 4924 only worked the first time I powered it on.  I had to move it and disconnected power and it no longer works

Sorry to hear that. Seems a bit odd though.

Also, when I returned from vacation and powered on my 4052 - I can't read the screen, but the computer is working.  I think it is a high voltage problem because I can see the blinking cursor and briefly see typed characters which quickly fade out.

You may be correct and you mentioned a weird fog in the centre on the VCFED thread. Do the characters shrink towards the centre as they fade out? If not, then it might not be the EHT choke. Does it use a storage tube like the 4051? If so then maybe its related to one of the unregulated supplies (+320v and +185v on the 4051).

My 4054A computer is working, but I would have to move the logic analyzer to the other room to connect to the 4054A if we need more traces.

Since I now have a working 4051 to test with, I can now do my own LA traces so there should be less of a need for me to rely on them being sent over unless it is something related specifically to the 4052 or the 4054.

[mmcgraw74]

That is understood. EOI is sent only when the end of the file is reached. I did some work on PRINT and INPUT as they are reciprocal and for working with text data files. I have PRINT writing raw data to file on the SD card and I think I may have nailed the problem with INPUT causing the Tek to get stuck and requiring a BREAK. In addition to asserting EOI at the end of the file, it also has to send the EOF character (FF). That signals the Tek to end the transmission with UNT and UNL, otherwise it just sits there expecting more data. What I still don't have is variables being read back correctly. For example:

PRINT@5:A$,B
INPUT@5:A$,B

I expected this would write a string and a number to an ASCII data file and read it back, but A$ ends up containing the string with the number tacked on to the end. I notice from the tek 4050 Series Basic Reference, that the PRINT command makes use of formatting options using the USI and IMAGE commands. The text states that the format string optionally "can be" specified in an IMAGE statement, but doesn't state whether formatting using the USI command is mandatory. I had experimented with the USING command to format the output of four variables which does work, but since there seems to be no corresponding command to format the variables for the INPUT statement, it all ends up in the first string variable anyway.

I'll break down your latest questions into individual replies.

You cannot PRINT a string AND another string or numeric variables in a single BASIC statement.

Tek BASIC strips the quotes from a string variable in all PRINT commands (to the screen or to tape or GPIB device), and then sends a CR to terminate that string.

PRINT is able to send multiple numeric variables in a single statement, and that operation will ALSO be terminated with a CR.

Consequently - the INPUT command from a file on tape or GPIB device ALWAYS has a CR and the tape or device returning the CR causes Tek BASIC to end the INPUT of the data.  THEN Tek BASIC parses that buffered data for the variable(s) - either a single ASCII character string, or as many numeric variables as that INPUT command contains.

This PRINT/INPUT behavior will result in Tek BASIC hangs during the INPUT - if the variables cannot be parsed.

Example - I entered the following program into my 4054A:

Code: [Select]

100 A$="This is a test string"
110 B=532
120 FIND 13
130 PRINT @33:A$,B
140 CLOSE
150 FIND 13
160 INPUT @33:A$
165 INPUT @33:B
170 PRINT A$,B
180 END

I have attached my photo of the 4054A with the program list and results



Note that running this program resulting in Tek reporting EOF in line 165.
This is because the string and the number were printed to the tape, then CR terminated.
The line 160 input returned the string PLUS the 532, so if we did PRINT A$ we would see both the string concatenated with 532.

When Tek then tried to run line 165 - there was no more data in the file - and EOF was detected.

I then recalled line 160 and added the B to the INPUT, and I typed 165 with CR - which deleted line 165 and reran the program.  That didn't fix the problem - since both A$ and B were PRINTed to the same line, and Tek BASIC requested more data from tape and got EOF.

Then I edited the line 130 PRINT statement to remove B, and added a line 135 PRINT statement to write the B separately. 
Now running the program resulted in no hang or EOF and both the A$ and B printed.

As further proof - I loaded my TapeDump8 program into the 4054A (using serial), and did a dump starting with file 13, and my dump program continues until it reaches a LAST file.

The second photo attachment shows ALL the bytes in File 13:



I'm not sure why this dump shows two File 13 Header strings, I may not have downloaded my latest TapeDump8 program - since I didn't have my USB flash drive plugged in which DOES have the latest program.

I am using Notepad++ to display the dump file contents and have enabled viewing ALL characters including control characters.

Line 4 - the file header, CR terminated
Line 5 - a blank line filled with spaces - this is the remainder of the first tape file block of 256 bytes
Line 6 - A$  properly terminated with CR and no quotes
Line 7 - B    ASCII printed numeric variables always have a leading space, and as the only numeric variable in that PRINT statement in the new line 135, it is CR terminated
Line 8 - the ASCII character 127 which is used as the EOF marker

[WaveyDipole]

I have tested bearing in mind your comments that you can't mix both numbers and string variables in the same statement except in my test I had the numeric variables first. As you pointed out, it is possible to print several numeric variables in a single PRINT statement and read them back with INPUT:

PRINT@5:111,222,333,444,555
FIND@5:3
INPUT@5:A,B,C,D,E

This read back the 5 values into variables A to F. I then tried printing a string variable to the file and reading back the 5 numeric variables first with one INPUT command and then the string variable using a second input command (INPUT F$) but ran into a hang. Further investigation reveals that individual PRINT statements work fine and terminate with a CR as you describe, but subsequent PRINT statements seem to overwrite the previous line, in other words, the write operation starts at the beginning of the file each time. When I edited the file manually and added in a test string on a second line, I could then read back the numbers with one INPUT statement and the string with a second INPUT statement. I need to figure out why the write operation seems to restart at the beginning of the file each time.

I also copied the PRINT routine into WRITE and the INPUT routine into READ. A minor amendment needed to be made to allow them to operate on BINARY DATA files but a test shows that it is possible to mix numeric and string variables in one WRITE statement and read them back. At the moment these two routines are writing binary bytes. There is no conversion to the HEX representation of bytes, but this can be added as you have already provided the code for this. The Tek writes, reads and handles the header byte pairs so there is no need for the emulator to handle this. It just needs to write and read back the raw data.

Hopefully today I can solve the file pointer problem and we should then have working PRINT and INPUT.

Looking ahead, I realised that it will not be possible to read/write/amend the file header as described in the manual. The example shows that the header is read from the first record in the file which would work fine with the 4924. However, on SD, the header information is stored in the filename so it can't be read from the file content. That problem comes further down the line but once we get around to commands like MARK, KILL and SECRET, the handling of the header will need to be resolved.

I am also a little unclear about the CLOSE command which I note you have used in your program. If I open a file with FIND and then do CLOSE, nothing actually happens on the GPIB bus. CLOSE@5: seems to do nothing either. CLOSE@5:1 gives me an IO error. I am not sure how to actually issue a CLOSE on a file on the emulator as I see no activity there in response to the command being issued. The closest I can come is to issue a FIND@5:x where x is another file. The 4924 doesn't actually list a CLOSE command in the table of operating commands.

[WaveyDipole]

UPDATE: I think that with a little help I may have solved that PRINT problem and PRINT/INPUT it now seems to behave as you describe. I will tidy up and push it up to the repository in a while so you can give it a try.

[mmcgraw74]

I have tested bearing in mind your comments that you can't mix both numbers and string variables in the same statement except in my test I had the numeric variables first. As you pointed out, it is possible to print several numeric variables in a single PRINT statement and read them back with INPUT:

PRINT@5:111,222,333,444,555
FIND@5:3
INPUT@5:A,B,C,D,E

This read back the 5 values into variables A to F. I then tried printing a string variable to the file and reading back the 5 numeric variables first with one INPUT command and then the string variable using a second input command (INPUT F$) but ran into a hang. Further investigation reveals that individual PRINT statements work fine and terminate with a CR as you describe, but subsequent PRINT statements seem to overwrite the previous line, in other words, the write operation starts at the beginning of the file each time. When I edited the file manually and added in a test string on a second line, I could then read back the numbers with one INPUT statement and the string with a second INPUT statement. I need to figure out why the write operation seems to restart at the beginning of the file each time.

I also copied the PRINT routine into WRITE and the INPUT routine into READ. A minor amendment needed to be made to allow them to operate on BINARY DATA files but a test shows that it is possible to mix numeric and string variables in one WRITE statement and read them back. At the moment these two routines are writing binary bytes. There is no conversion to the HEX representation of bytes, but this can be added as you have already provided the code for this. The Tek writes, reads and handles the header byte pairs so there is no need for the emulator to handle this. It just needs to write and read back the raw data.

Hopefully today I can solve the file pointer problem and we should then have working PRINT and INPUT.

Looking ahead, I realised that it will not be possible to read/write/amend the file header as described in the manual. The example shows that the header is read from the first record in the file which would work fine with the 4924. However, on SD, the header information is stored in the filename so it can't be read from the file content. That problem comes further down the line but once we get around to commands like MARK, KILL and SECRET, the handling of the header will need to be resolved.

I am also a little unclear about the CLOSE command which I note you have used in your program. If I open a file with FIND and then do CLOSE, nothing actually happens on the GPIB bus. CLOSE@5: seems to do nothing either. CLOSE@5:1 gives me an IO error. I am not sure how to actually issue a CLOSE on a file on the emulator as I see no activity there in response to the command being issued. The closest I can come is to issue a FIND@5:x where x is another file. The 4924 doesn't actually list a CLOSE command in the table of operating commands.

The editing of the file header is not typical in programs - in fact, the only program I have found that does that is from Tektronix as a utility, to help add user information to the file header.

I don't know if Tek BASIC reads the file header.  I believe (but am not positive) that BASIC reports errors if you attempt to write or print to the wrong type of file.  This should be easy to verify.

According to the BASIC reference manual - pages 7-30 and 7-31, the CLOSE statement, FIND statement, END statement or pressing BREAK key twice, will flush the mag tape write buffer contents to the tape.

[mmcgraw74]

UPDATE: I think that with a little help I may have solved that PRINT problem and PRINT/INPUT it now seems to behave as you describe. I will tidy up and push it up to the repository in a while so you can give it a try.

I'll check it out!

[WaveyDipole]

UPDATE: I think that with a little help I may have solved that PRINT problem and PRINT/INPUT it now seems to behave as you describe. I will tidy up and push it up to the repository in a while so you can give it a try.

I'll check it out!

Just pushed up version 0.05.35.

Thanks for the info on the header. I guess it makes things easier if we don't have to worry about editing the header information. The MARK command just needs to create a filename header in the appropriate format and with the correct number sequence and SAVE needs only to re-write the existing file name to make it a PROG type.

I did a bit more digging and it seems CLOSE is listed as one of the commands in the alternative commands table. Since we are not using alternative sequences, we probably don't need to worry about it too much. FIND closes the previous file and OLD automatically close a file after it has read it. I found it curious that neither CLOSE, END or pressing BREAK twice appeared to send anything to the GPIB bus so I had a look on the logic analyser. When CLOSE or END is executed, only the REN line goes low briefly but nothing else happens. When BREAK is hit twice, nothing happens at all on the GPIB bus so its a bit of a mystery quite how the data is flushed to tape....

[mmcgraw74]

I have downloaded your version 0.05.35.

I had to change a couple of things to make it compile:

1 - I edited the Store_Tek_4924.h file to set SD_SCK_MHZ(50) as the parameter name wasn't found
2 - I commented GPIBdevice.h line 1.  I googled ArduinoCloudProvidersExamples and the Arduino.cc page indicates it is only compatible with boards with the SAMD CPU.

3 - Then I updated the Config.h line 10 to display the 0.05.35 version number when I use the ++ver command on the serial console.

I can use INPUT on ASCII PROGRAM files but not ASCII DATA files?

How do I enable the serial debug output to see those commands on the serial console?

[mmcgraw74]

I enabled debug serial console and cmd parser.

I found a change needed to be made in FIND command.

I decided to create a file 0 in each directory with the header string for each of the files.

My file 1 in each directory is a menu program - the last selection will emulate a TLIST command by printing each of the lines in file 0.

The 5.35 code for FIND starts looking for file 1.

I edited Store_Tek_4924 line 349 and changed (filenum > 0) to (filenum >=0).

Then when I recompiled, I did this test on my 4052 (non-persistent display but I can see the lines printed for a moment):

PRINT @5,19:"UTILITIES"
FIND@5:1
OLD@5:
RUN

I then selected 2 to get a TLIST and it worked!

I then moved the Tape Emulator to my 4054A

I was able to load the "UTILITIES" file 1, however the 4054A hung on the line 100 INIT statement and didn't print anything.
I had to power cycle the 4054A - and I power cycled the Tape Emulator.

I loaded "UTILITIES" file 1 again and deleted line 100.
Now the program printed the menu and waited for my INPUT.

I typed 2 and the 4054A and it hung again and required power cycling.

So good news with my changes on the 4052.
Please try that with your 4051.

I will need to hook a laptop with serial to my 4054A to see what is happening on the serial debug console.

New feature request - If the Tape Emulator detects REN going inactive it should exit the current command (and flush writes if necessary) and return to idle.