• Please review our updated Terms and Rules here
  • Exhibitor application for VCF West 2022 is now open! If you are interested in exhibiting, please fill out the form here.

Tektronix 4050 GPIB Flash Drive - now available

WaveyDipole

Experienced Member
Joined
Jul 23, 2021
Messages
105
Location
United Kingdom
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: 2
  • 5 BINARY PROG Pacific Coastline 19200.zip
    7.1 KB · Views: 3

nikola-wan

Veteran Member
Joined
Mar 7, 2018
Messages
924
Location
Texas, USA
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 :(
 

WaveyDipole

Experienced Member
Joined
Jul 23, 2021
Messages
105
Location
United Kingdom
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: 0
Last edited:

WaveyDipole

Experienced Member
Joined
Jul 23, 2021
Messages
105
Location
United Kingdom
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.
 

nikola-wan

Veteran Member
Joined
Mar 7, 2018
Messages
924
Location
Texas, USA
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: 2
  • 4054BOLT.pdf
    97.5 KB · Views: 1

WaveyDipole

Experienced Member
Joined
Jul 23, 2021
Messages
105
Location
United Kingdom
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.
 

WaveyDipole

Experienced Member
Joined
Jul 23, 2021
Messages
105
Location
United Kingdom
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:

nikola-wan

Veteran Member
Joined
Mar 7, 2018
Messages
924
Location
Texas, USA
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: 4
  • Flash Drive BAPPEN traces.zip
    257.2 KB · Views: 1
  • 4924BOLE BOLD end waveform.png
    4924BOLE BOLD end waveform.png
    12.4 KB · Views: 4
  • 4924_BOLC CLOSE2.png
    4924_BOLC CLOSE2.png
    119.8 KB · Views: 4
Last edited:

WaveyDipole

Experienced Member
Joined
Jul 23, 2021
Messages
105
Location
United Kingdom
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.
 
Top