• Please review our updated Terms and Rules here

Tektronix 4050 GPIB Flash Drive - now available

Thank you for that helpful analysis!

It think this might explain a couple of things. For example, I found that using 'FF' as padding characters works, but using '00' or '20' generates a MAG TAPE ERROR. Without receiving an 'FF', the Tek would not have detected an end of the file condition which is probably why it displays the MAG TAPE ERROR. It probably also explains all of those '20' characters present at the end of the Option30 Demo files.

What is still unexplained is why there is no 'FF' at the end of either the data or the end of the last 256-byte segment in either the recovered Option30 Demo files or any files saved with BSAVE on the flash drive? Yet, as you explained, the spreadsheet data for BOLD shows that the 4924 sends an FF at the end of the data, but before the remaining part of the last 256-byte block.

I experimented with this in the JavaScript emulator. I first programmed it to send an FF at the end of a binary program file written on the flash drive and then padding with character 20 until the end of the 256-byte block. In effect this is faking what the 4924 does based on your findings. This worked and the file loaded without error. I then padded the file on disk with character 20. When running BOLD on this, the Tek loaded the file but produced a MAG TAPE ERROR. I then changed the byte immediately after the end of the data to an FF leaving the padding in place, again faking the 4924. That worked and the error was gone. Clearly that FF as shown in the screenshot is needed. So why, then, is it not present in the recovered files?

It seems that even without the FF, the Tek "knows" exactly where the program file ends and stops loading, although it would still not have received an FF which might be the reason for the error. I have added an FF byte to the end of the program data in the attached files. Could you check whether they load on the 4054 please? It might work with the updated version I posted yesterday but it might be better to try it with the earlier 0.05.77 version.

I will have a few things to sort today so I will come back to this a bit later, but your post has some interesting observations.
 

Attachments

  • 5 BINARY PROG Pacific Coastline 19200.zip
    7.1 KB · Views: 3
  • 5 BINARY PROG Pacific Coastline 19200.zip
    7.1 KB · Views: 4
I downloaded the two zip files - are they Identical? I put the program 5 in the second zip on the flash drive and tried CALL"BOLD",5 on that file with your latest code and had the same hang as before, although the program is loaded in memory. I reflashed the May 4 flash drive code and tried again - same hang as before :( CRUD :( Both attempts were on my 4054A.

Then I tried that file on my 4052 with the May 4 flash drive code - same hang but program was loaded and ran after double-BREAK :(
 
Monty, sorry, yes, I had attached the same file twice. I am surprised that the forum didn't warn me, but it shows just how well I am functioning at the moment... :sick:. I have now attached the second file.

I have attached the second file, but given the results of your tests on the first one (thank you for that BTW), I don't think its going to make much difference. Whenever I have gotten a mag tape error, I have also found after double break, that the program had loaded and could be run. Since the program is getting loaded into memory, we can't be that far from a solution but it is eluding me at present. :( I can't help thinking that those 8 bytes at the beginning of the file (bytes 2-9) might somehow be significant.

Could I ask which file you were testing when you obtained that screenshot? It looks quite short. Could I have a copy of it please?
Thanks.
 

Attachments

  • 19 BINARY PROG ---------------- 512.zip
    440 bytes · Views: 3
Last edited:
Yes, here is my program for the logic analyzer capture:

Code:
100 REM Line 1
110 REM Line 2
1000 REM Line 3
 
Thanks. Can't get much simpler than that!

PS, Monty, do you have the full service manual for the 4052 or 4054 please? I was hoping to find them in your repository, but couldn't see them. if you have them, is there any chance of obtaining the please? At the moment I can only look things up with reference to the 4051.
 
I made a logic analyzer capture of the 4054A performing a CALL "BOLD",5 with the modified file you posted.

I've attached the excel spreadsheet pdf and the waveform.

Differences I see between 4054A with Flash Drive and with the 4924 on CALL "BOLD":
- Flash Drive issues an EOI with the FF byte after the binary data.
- 4050 immediately asserts ATN
- 4050 issues Untalk, Unlisten, Untalk, LISTEN Dev5, CLOSE
- Flash Drive asserts EOI with FF data but no DAV
- no more GPIB transfers, double BREAK required

For the 4924 CALL "BOLD":
- 4924 did not issue an EOI until after the CLOSE from the 4050 and only one FF and the rest are SPACE characters
- 4050 only asserted ATN to the 4924 after 256 bytes are transferred
- 4050 issues to the 4924 Untalk, Unlisten, Untalk, LISTEN Dev4, CLOSE
- 4924 asserts EOI with SPACE character data and DAV, 4050 accepts data
- 4050 issues to the 4924 UNTALK and UNLISTEN with ATN
 

Attachments

  • 4054BOLE.png
    4054BOLE.png
    14.6 KB · Views: 3
  • 4054BOLT.pdf
    97.5 KB · Views: 2
Sorry, I was in a bit of a rush when trying to respond yesterday morning that I forgot that the May version still sends FF+EOI at the end of the binary data. I have now pushed an update which removes the EOI and applies the method I got working in the JavaScript emulator yesterday. Please try this version. The 5.79 version got rid of the EOI and added padding, but didn't take care of the FF character. For files saved on the flash drive, this one (5.80) sends just an FF (no EOI) at the end of the binary data and then adds the padding. For files that have a length that corresponds exactly to a 256-byte block, it simply reads the file. No FF and no padding are added.
 
BTW, that EOI after CLOSE is a bit curious since CLOSE is a LISTEN command and the 4050 is sending LISTEN Dev4. There is no indication in the 4924 documentation as far as I can see, that CLOSE will send an EOI, so why are we seeing one sent with a space character?

Unfortunately, I haven't got to a point yet, where the 4051 is sending a CLOSE after receiving the data. Also, the JavaScript emulator did not have a CLOSE command implemented, so I added one. Since there is no file being opened on disk as such, the function just clears buffers and pointers, but it was was available for completeness. I ran the following command sequence:

Code:
FIND@5,17:
CALL "BOLD",5

I saw no CLOSE being sent. So I then tried sending one manually using PRINT@5,2: as indicated in the 4924 manual:

Code:
PRINT@5,2:

The command does get executed, but I saw no EOI getting sent. I can't send one in code from the storage controller to the emulated 4051 since we are running a listening command and there are no hooks on the Tek side to listen to a response. However, I could add a line to the TEKTRONIX4051.js code to log outgoing EOI signals from the Tek. This is the beginning of the Tek section that sends outgoing data to GPIB:

JavaScript:
        if( GPIB_TALK ) {
     
            if( (GPIB_DAV_OUT == 1) && (GPIB_NDAC_IN == 1) ) {


                if ( GPIB_EOI_OUT == 1 ) {
                    console.log("EOI signalled!");
                }

If the conditions are met for a byte being out on the GPIB bus (DAV asserted, NDAC asserted as per original lines) then check whether EOI is also asserted (=1) and if so, then print a message to the console.

I then ran the whole command sequence again. This time, the console showed that EOI was being sent from the Tek both after the FIND command and after the PRINT@5,2: (CLOSE) command. It may therefore be that the EOI we are seeing in the trace after the CLOSE is actually being signalled by the Tek.

However, as I mentioned, we are not yet seeing the Tek respond with a UNT/UNL and CLOSE after the BOLD, so it would seem that there is still something missing....
 
Last edited:
With your latest code I do see the CALL "BAPPEN",5;1000 with the Flash Drive look like the CALL"BAPPEN",4;1000 with the 4924 with one exception. I see the EOI after the close, however it does not have DAV asserted - and the 4050 hangs at this point until double-BREAK.

I've attached the waveform, trace listing, excel trace list decoded and pdf print in case you don't have excel, in a zip file.

There has to be something we are missing that is different about the 4924 behavior.

Also, after double-break, the CALL "BAPPEN",5;1000 does NOT append the file to the current program - it just acts like a BOLD and replaces everything in memory with the binary program file.

Here is the zoomed view of the CLOSE showing the EOI at the end - but that is the end of the logic analyzer capture until I pressed double-BREAK a couple of seconds later.

Ok - I attached the zoomed CLOSE waveform for the 4924 CALL "BOLD",4 and I see that the 4924 sets NDAC high after the ATN goes high following the CLOSE command. Then I see the 4050(?) EOI without DAV followed by REN high which causes NFRD low, followed by a second and third 4050 ATN cycles which cause NDAC & NFRC activity. The fourth attachment is the screenshot of the excel spreadsheet 4924 BOLD total trace, with the additional cycles (no DAV on any of them) commented.

Does it make any sense to you? quite a bit different than I thought. I wasn't paying any attention to commenting the trace list if DAV wasn't asserted.
 

Attachments

  • FD_BAPC CLOSE.png
    FD_BAPC CLOSE.png
    12.6 KB · Views: 5
  • Flash Drive BAPPEN traces.zip
    257.2 KB · Views: 2
  • 4924BOLE BOLD end waveform.png
    4924BOLE BOLD end waveform.png
    12.4 KB · Views: 5
  • 4924_BOLC CLOSE2.png
    4924_BOLC CLOSE2.png
    119.8 KB · Views: 5
Last edited:
Thank you for the detailed information. I don't have Excel, but can read Excel files using LibreOffice and having the complete data to scroll through has been very useful as has the ZIP file containing all of the data and screenshots.

It looks like we have made some progress with that last modification, but as you say, we appear to be missing something about the 4924 behaviour. I have noted what you are saying about BAPPEN not completing the append but behaving like BOLD. Very strange, but possibly symptomatic of the process not being completed correctly?

I also had a look at the data you sent me. That's a good spot about there not being a DAV signal during the EOI and also the behaviour of ATN and REN. Very strange. Will have another look in the morning.
 
Monty, when you did the test with the 4924, was the Flash drive also connected to the GPIB bus or not?
Yes, both the 4924 and Flash Drive were connected to the 4054A GPIB - plus the logic analyzer, but it is only a high impedance load.

The 4924 was not turned on during the Flash Drive traces yesterday. Do I need to leave it turned on too? I could disconnect it if needed.
 
Is it possible to get a trace with ONLY the 4924 connected?

When I looked at the second screenshot (4924BOLE BOLD), I noticed that during the UNT+UNL and then the CLOSE command, that the status of NDAC is remains unchanged, in other words, no 3-way handshake. Immediately after CLOSE, when ATN gets un-asserted, both NDAC and NRFD go up and at the same time we see the EOI.

In the first screenshot (FD_BAPC CLOSE), the status of NDAC changes so we have a handshake, however, once the CLOSE command has been sent, both NDAC and NRFD stay down and we still get the EOI. As we know, the flash drive then hangs.

It is possible to determine in screenshot 2 that listen address 24 is being sent, whereas in the first one, listen address 25 is sent, so the correct device seems to be getting addressed, but because NDAC is not getting raised, there is no acknowledgement that the data byte has been accepted.

I don't understand why NDAC and NRFD go up after the CLOSE command, since there has been no UNT+UNL? During this period we see the EOI and 0x20 on the bus, then briefly a zero and ATN gets asserted. We then have a 0x20 on the bus again? When ATN goes up again, we briefly get a zero and when it gets asserted the final time, once again we see 0x20 on the bus? Nothing seems to happen during either ATN asserted period. It all seems rather strange.

I suggest that it might be a good idea to eliminate the possibility of the flash drive interfering with the 4924 transfer and causing us to miss something, hence my request to get a clean 4924 transfer without the FD on the bus. The LA shouldn't pose a problem, neither should the 4924 when turned off as that would present a high impedance load as well. So, with the 4924 turned off, there should not be a problem with the FD capture. On the other hand, the if the FD was powered on during the 4924 capture, it might be causing an unexpected interference. Notwithstanding, the 4924 successfully completes its transfer, but I would like to be sure that that 4924 trace is actually what it is supposed to be and not skewed in some way by the Arduino.
 
Great call!

I had been experiencing flaky 4924 operation during previous captures - sometimes hanging the 4924 and would power cycle the 4924. Possibly reading the status register in the 4924 might have cleared the errors, but I was in a hurry.

I unplugged the Flash Drive from the 4054 and only had the 4924 and logic analyzer connected to the 4054 GPIB.

I captured 4924 with a good tape doing BSAVE, BOLD and BAPPEN and had no errors on the 4924 and no error 69 on the 4054A.
The 4924 BOLD retrieved all three program lines and BAPPEN to line 1000 resulted in five program lines.

Same three line program as before.

Here are some of the screenshots. All the screenshots, CSV, XLSX, and PDFs are in the zip file.

This should clear things up :)

I'm updating the Flash Drive user guide - I wouldn't mind if we said the Flash Drive must be the only GPIB device connected to the 4050 computer, unless the weird behavior could be fixed in the Flash Drive code :)
 

Attachments

  • 4924BAPI BAPPEN with EOI at end of trace.png
    4924BAPI BAPPEN with EOI at end of trace.png
    11.7 KB · Views: 4
  • 4924BOLE middle to end.png
    4924BOLE middle to end.png
    12.2 KB · Views: 4
  • 4924BSVE BSAVE End with no Flash Drive installed.png
    4924BSVE BSAVE End with no Flash Drive installed.png
    13.9 KB · Views: 4
  • 4924 traces June 25 no Flash Drive installed.zip
    677.4 KB · Views: 2
Last edited:
Thank you for the detailed analysis. These screenshots make sense now. I am still looking over the data.

That clarifies why you were having difficulty with the 4924 and shows the flash drive was causing the problems while connected to the bus at the same time.

Can I confirm that the flash drive connected on its own to the bus still has the same problem with BOLD and BAPPEN? Also with the flash drive connected only, does the Tek 4052/4054 still issue a CLOSE after the BOLD or BAPPEN?

Ideally, the flash drive should not interfere with other devices on the bus so I need to further study the problem.
 
Yes, I confirm that only connecting the Flash Drive and logic analyzer to the 4054 GPIB still has the same hang on BOLD, BAPPEN and same wrong result on BAPPEN - looks like BOLD with the three line BINARY test program file you posted.

Here are new screenshots of the BOLD,5 and BAPPEN,5;1000. I couldn't get the entire trace into the capture, but in both cases got some of the BINARY DATA and the FF and all the SPACES in the PAD area. In both captures the EOI from the Flash Drive has no DAV - which appears to be the difference in the 4924 traces yesterday and the Flash Drive traces today.
 

Attachments

  • 4054 traces no 4924.zip
    220.7 KB · Views: 2
  • 4054BAPE.png
    4054BAPE.png
    13.8 KB · Views: 5
  • 4054BOLE.png
    4054BOLE.png
    14.3 KB · Views: 5
This is all-'round neat, but I'm specifically curious as to how easy it would be to use this with vintage HP equipment - looks like the connector should be the same, from what I gather, but are Tektronix and HP storage devices compatible beyond the IEEE-488 protocol level? I've got a 9000/360 with no SCSI controller, and it'd be nifty if I could just use this to boot off of instead...
 
This is all-'round neat, but I'm specifically curious as to how easy it would be to use this with vintage HP equipment - looks like the connector should be the same, from what I gather, but are Tektronix and HP storage devices compatible beyond the IEEE-488 protocol level? I've got a 9000/360 with no SCSI controller, and it'd be nifty if I could just use this to boot off of instead...
From what I've seen the answer is no to the IEEE-488 protocol and no to the command compatibility.

The Tektronix 4051 computer was introduced in 1975 close to the introduction of GPIB. Tektronix chose to use single-byte GPIB Secondary Addresses to notify a device of the type of command. I haven't found any other products using this command protocol - so the Flash Drive GPIB code wouldn't work with other manufacturers equipment such as HP. In fact, I believe most of the early GPIB equipment had unique commands, which required custom programs to interface. For example: Tektronix introduced test equipment (power supplies, digital multimeters, relays, etc that plugged into a TM5000 enclosure) in the early 1980's using GPIB, and at that time Tektronix published a GPIB command standard. There were programs written for the Tektronix 4050 computers to interface to that equipment, but I don't believe any other vendors used that Tektronix instrumentation protocol either.

As you can see in this forum thread - we are having to reverse engineer how the 4050 computers accessed the Tektronix 4924 tape drive for programs and data - even though the Tektronix 4924 Service Manual included an Appendix giving some details on those commands. The ones we are trying to get to work now are BINARY PROGRAM SAVE, OLD (LOAD), and APPEND. The 4050 manuals show the ASCII PROGRAM SAVE, OLD and APPEND, but not the BINARY versions. Same goes for the 4924 Service Manual. However, we have found that the BINARY versions do exist on both sides as undocumented commands.

The Flash Drive is working for ASCII PROGRAMS, but I recently posted in this thread my recovery of two tapes that were recorded with BINARY PROGRAMs. BINARY PROGRAMS load about 4x to 8x faster than ASCII PROGRAMS - which is the biggest reason to see if we can get the BINARY PROGRAM commands to work in the Flash Drive.

I think we are getting close.
 
Back
Top