Tektronix 4050 GPIB Flash Drive - now available

[WaveyDipole]

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.

Thank you for the confirmation as well as the additional traces.

The waveforms for BOLD and BAPPEN appear to be identical, and these in turn, appear to be the same as the ones from the 4924, although I have yet to complete my study the waveforms in full detail.

The curious thing now is that I am running the same code on my 4051 as you are on your 4054 (and presumably your 4052), but my trace does not show a UNT+UNL followed by CLOSE then EOI after the program has been transmitted. Does this mean that the 4051 simply does not send any of these? The transmission just ends and there is nothing further (see attached graphic). Why would sending UNT+UNL then CLOSE make a difference and cause the 4054 to hang? I am uncertain of the answer at present but perhaps a more detailed study will reveal something.

 

[nikola-wan]

The 4052/4054 were introduced 4 years after the 4051 and due to the bit-slice 16-bit CPU architecture had to rewrite the 4050 BASIC ROMs, so I'm not surprised that even with the 4052 using the same GPIB discrete hardware - the GPIB code has different behavior.

As we have discovered the A-Series 4052 and 4054 changed the GPIB hardware to use the TI 9914 GPIB integrated circuit - and also changed the GPIB firmware again.

There is a difference between the 4924 traces and the Flash Drive traces - the EOI in the 4924 traces includes DAV with the SPACE character.

The 4054 traces have the EOI - but no DAV, so I think the GPIB handshake not finishing is what is hanging the 4054A and 4052 BASIC ROM, and also causing the BAPPEN to act like BOLD.

 

[WaveyDipole]

There is a difference between the 4924 traces and the Flash Drive traces - the EOI in the 4924 traces includes DAV with the SPACE character.

The 4054 traces have the EOI - but no DAV, so I think the GPIB handshake not finishing is what is hanging the 4054A and 4052 BASIC ROM, and also causing the BAPPEN to act like BOLD.

Good point. Yes, that difference is still present. Also, in both cases, the EOI is issued, not during the ATN asserted period, but just after it. The CLOSE command function would have finished at this point. The flash drive would then drop to a mode where it will be listening out for the next ATN, but not actively listening for data.

This confused me at first, but it just occurred to me looking the 4924 trace, that maybe SPACE+EOI are being treated as a piece of data being provided to the CLOSE command. This is followed by UNT+UNL to clear the bus.

Looking at the Tek 4050 Series Basic Reference, the CLOSE command can take an optional 'logical file number' parameter. I am unsure as to whether that is relevant to the form PRINT@5,2 which just closes the current file, but I am now thinking that perhaps the CLOSE function ought to be able to receive a parameter. Perhaps the fact that the flash drive is not ready to receive that byte is the reason why the Tek 4054 is hanging? Since the 4051 does not send a CLOSE, the issue does not arise on that machine and so it just works. To test this theory, I tried running through the process of calling BOLD or BAPPEN and then manually sending CLOSE via PRINT@5,2:. Sure enough, the 4051 hung after the CLOSE each time.

Interestingly, the 4051 seems to send an 0x0D rather than the 0x20 sent by the 4054, but either way, at least one byte with an EOI is sent after CLOSE. In both cases, the absence of any numerical data would just be interpreted as end of transmission.

I tried an experiment where I added a line to the CLOSE function to read a parameter from the GPIB bus whenever the command is executed. At present, nothing is being done with the value of that parameter. It is simply being ignored and the current file is then closed. The updated code was uploaded to the flash drive and the whole process of calling BOLD or BAPPEN followed by a manual CLOSE repeated. This time the 4051 did not hang after CLOSE. It just returned to the command prompt and the program could be listed and executed.

I have pushed an update up for you to test on the 4054 and 4052.

 

[commodorejohn]

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.

Thanks - that's the impression that I'd gotten, but this stuff is far enough outside my wheelhouse that it's good to get confirmation from folks with more direct knowledge. Looking around, it seems like someone's already designed an equivalent device for that purpose

 

[nikola-wan]

Thanks - that's the impression that I'd gotten, but this stuff is far enough outside my wheelhouse that it's good to get confirmation from folks with more direct knowledge. Looking around, it seems like someone's already designed an equivalent device for that purpose

Yes, I had seen that project before. It emulates an HP floppy disk, HP hard disk or Commodore disk. My 4050 Flash Disk emulates a Tektronix 4924 Tape Drive. Tektronix designed a 4907 8-inch floppy disk system and 4909 hard disk system for their 4050 computers - but both of these require an option ROM Pack with the interface software. I have two working 4907 Floppy Disk systems, but I found its command set was overly complex and required changes to all the programs on tapes I have recovered. The Flash Disk works with the embedded 4050 BASIC because it uses the 4924 tape commands. We only added one GPIB command to the Flash Drive - a change directory command - which allows the Flash Drive to support multiple tapes stored in separate directories.

 

[nikola-wan]

Good point. Yes, that difference is still present. Also, in both cases, the EOI is issued, not during the ATN asserted period, but just after it. The CLOSE command function would have finished at this point. The flash drive would then drop to a mode where it will be listening out for the next ATN, but not actively listening for data.

This confused me at first, but it just occurred to me looking the 4924 trace, that maybe SPACE+EOI are being treated as a piece of data being provided to the CLOSE command. This is followed by UNT+UNL to clear the bus.

Looking at the Tek 4050 Series Basic Reference, the CLOSE command can take an optional 'logical file number' parameter. I am unsure as to whether that is relevant to the form PRINT@5,2 which just closes the current file, but I am now thinking that perhaps the CLOSE function ought to be able to receive a parameter. Perhaps the fact that the flash drive is not ready to receive that byte is the reason why the Tek 4054 is hanging? Since the 4051 does not send a CLOSE, the issue does not arise on that machine and so it just works. To test this theory, I tried running through the process of calling BOLD or BAPPEN and then manually sending CLOSE via PRINT@5,2:. Sure enough, the 4051 hung after the CLOSE each time.

Interestingly, the 4051 seems to send an 0x0D rather than the 0x20 sent by the 4054, but either way, at least one byte with an EOI is sent after CLOSE. In both cases, the absence of any numerical data would just be interpreted as end of transmission.

I tried an experiment where I added a line to the CLOSE function to read a parameter from the GPIB bus whenever the command is executed. At present, nothing is being done with the value of that parameter. It is simply being ignored and the current file is then closed. The updated code was uploaded to the flash drive and the whole process of calling BOLD or BAPPEN followed by a manual CLOSE repeated. This time the 4051 did not hang after CLOSE. It just returned to the command prompt and the program could be listed and executed.

I have pushed an update up for you to test on the 4054 and 4052.

I put your latest code in the Flash Drive with only the Flash Drive and logic analyzer attached to GPIB.

FIND@5:41 (to open your BINARY test program file)
CALL"BOLD",5

returned Mag Tape error 55: An attempt has been made to incorrectly access a mag tape file. Example executing an OLD in the middle of a tape file.

Memory was cleared - no program was loaded.

What was also weird - when I powered on the 4050, I have RTC Auto Load configured to run the PICTURES menu and it looked very weird - over half the picture names didn't show up.

I ran the /root/ main menu and it errored trying to get to GAMES. When I did INPUT@5,19:A$, A$ contained /4051/ but I don't have a 4051 directory on the microSD card. I tried to TLIST the PICTURES folder with the Main Menu selection 12 and it only reported odd file headers.

I then regressed the Flash Drive code to your previous drop - and still see the weird issues above - although that drop would BOLD the file 41 after I pressed double-BREAK.

I've attached the weird photos of my 4054 display and logic analyzer trace of the latest code attempting to BOLD. In this trace the Flash Drive immediately issued the EOI with FF data after the BOLD command!

 

[WaveyDipole]

I am not sure what is going on there, but if you reverted back to the previous code, things should have reverted back to to the previous state of operation. I am just downloading the files you sent to have a look at.

 

[nikola-wan]

I had to revert two versions back to your Flash Drive code ver. 0.05.79, 22/06/2022 to get the TLIST and Picture Menu - which retrieves the file headers to display the menu selections.

This version supported the BOLD and BAPPEN but requires double-break to see the result, and BAPPEN behaves like BOLD instead of appending to the target line.

 

[WaveyDipole]

I have done some tests here as well and can confirm the odd behaviour of version 0.05.81. I ran the images program from the Pictures directory and got the same weird effect on the menu. Only every other menu item appeared. Reverting back to 0.05.80 got rid of the problem, but I didn't test BOLD and BAPPEN. At least we know that 0.05.79 is OK but with a double-break requirement.

In version 0.05.81 I removed the lines I added to the CLOSE function and that solved the menu problem. I haven't tested BOLD or BAPPEN at this point, but evidently adding those lines to the CLOSE function did cause the other problem. I ran a trace and can see that every other call to LIST LIST (command 19 [0x73]) returns a null result. The function is returning a nil result over GPIB (FF+EOI).

I saw no direct calls to CLOSE (command 2 [0x62]), but I dod notice that preceding LIST there is a call to FIND and at the beginning of the FIND function there is a requirement to close the current file and it calls the CLOSE command handler. This is the problem I think. We don't want to be reading another parameter during FIND, which is what CLOSE is now doing. I will need to restructure the code a bit and will push an update once this is ready. In fact, I will have to check for any other function that calls CLOSE.

I am not sure why you have had to go back TWO releases to version 0.05.79 to get BOLD and BAPPEN to work, but will need to have a look at that as well.

 

[WaveyDipole]

Ok, I have modified the code and checked for all instances where the CLOSE command handler is called and replaced them with a call to a new closeFile() function. This function contains the necessary instructions to close the file and clear the filename buffer, but does not read a parameter from GPIB. That is now only done in the CLOSE command handler.

I tested this on the 4051 and could run the Pictures menu OK and all the entries appeared. I could also run BAPPEN and append a binary program to an existing one. Lets hope this works on the 4054. If you still have problems executing BOLD or BAPPEN, the binaryRead() function will need to be re-visited.

 

[nikola-wan]

John - great news - your latest code fixed BOLD and BAPPEN and Picture Menu and TLIST are back working on my 4054A

Fabulous!

Now I'll check on the Option 30 Demo BINARY PROGRAM files and make sure they should load from the MENU with CALL "BAPPEN"!

I'll also check whether this code is now compatible with the 4924 both connected to 4050 GPIB.

Here is my 4054A photo to prove it

 

[nikola-wan]

Update on testing your new code.

My Opt30Demo folder with all but file 1 in BINARY PROGRAMS worked fine on my 4054A - although I don't have the Option 30 so none of the dynamic graphics worked. I found at least one of the programs that does a FIND and BOLD to load another program - that I have to edit to use the Flash Drive instead of the internal tape.

Then I ran my PICTUREs Menu and everything worked fine.

I connected the 4924 and reran some Opt30Demo programs - didn't see any issue. Same goodness on PICTURE menu binary R12 files.

I tried the 4924 BOLD and BAPPEN and they both worked but got error 69 reports. My previous traces showed NFRD/NDAC illegal states (less than 1 microsecond). Could be the lack of GPIB drivers on the Flash Drive board is causing that issue. I'll just update the Flash Drive manual to indicate no other GPIB device should be hooked up while using the Flash Drive.

Yippee! I'm ready to post your new Flash Drive firmware to my repo!

I will be building my first Flash Drive for an order when I get the Oshpark boards - hopefully by end of this week!

 

[WaveyDipole]

Excellent news!

I am glad that the Opt30Demo programs will now load. I am looking forward to hearing from Tom Stepleton as to whether he was able to run them without hiccups. Some of the graphics he posted earlier were great and probably not seen by anyone for many years.

I had pondered over the NRFD/NDAC illegal states. I did wonder whether sometimes the GPIO pins on the Arduino might be still in output mode instead of having switched to input_pullup. That would make it impossible for the 4924 to sink the signal to low on the line in question. It might be a timing issue or still some unresolved logic problem wich would require deeper investigation. I think for now, it is safer to state that now other device should be connected as you suggest.

 

[nikola-wan]

One question. Did your last code drop change the BSAVE to insert FF and SPACE character after the file is CLOSEd by the 4050?
Or do we need to do something to all the binary files like the one you supplied me for testing?

 

[WaveyDipole]

No, I haven't looked at BSAVE yet nor at CLOSE from that point of view.

For existing files saved with BSAVE on the flash drive, when BOLD/BAPPEN are called, the routine will send the data, then an FF, then pad the rest up to the 256-byte boundary, emulating what the 4924 would have sent. This seems to adequately deal with the missing FF at the end of the data in the file - assuming there is supposed to be one. Tests would seem to indicate that at least one FF is needed at the end of the data otherwise a MAG TAPE ERROR ocurrs.

On the other hand, files recovered from tape, such as the ones from the Opt30Demo, don't have any FF characters at the end of the data or at the end of the file, yet somehow the Tek automatically stops loading when the end of the data has been reached. The recovered files are, I presume, an exact replica of what was recovered from the tape and one can readily determine that file lengths are already in exact multiples of 256 bytes. Manually changing the byte at the end of the data was an experiment, but if BOLD/BAPPEN already work on other Opt30Demo program files that have not been modified, then how does that work without an FF at the end of the data? Adding an FF manually is easy enough since one can determine the end of the data visually in a hex editor, but making that modification programmatically would be tricky since we don't know where the end of the data is. Somehow, the Tek can make that determination though....? If it works without modifying the file, do we actually need to modify anything?

It is also the case with the flash drive that if a file length is exactly on a 256-byte boundary (file-length mod 256 = 0) , then BOLD/BAPPEN send no FF or padding characters. This means that the binary program files that have been recovered from tape are read exactly as they are and the data is not modified in any way before being sent over the GPIB bus.

Also, as determined from the traces, BOLD/BAPPEN do not signal EOI at any time so the flash drive routines does not send an EOI either.

I am happy to make any further modifications, but we would need to more fully understand the mechanism. Specifically, why do the Opt30Demo files load without having an FF at the end of the data, whereas other binary program files, as determined by traces and experimentation, appear to require one?

I suppose you could say the jury is out on the best was forward.

 

[nikola-wan]

My recovery program on BINARY PROGRAMs is in whole 256 byte blocks - may explain the Option 30 Demo results.
I think if we create BINARY PROGRAMS to speed up the loading time, they won't be saved in 256 byte blocks unless we want to change the BSAVE logic in the Flash Drive.

 

[WaveyDipole]

I take your point and it should be quite straightforward to add something in to BSAVE to pad the end of the file so that its length is exactly in 256-byte blocks and keep things consistent. I will experiment and post an update later.

 

[WaveyDipole]

Ok, I have updated BSAVE to round the file length to the nearest 256-byte block. A test to load a program and BSAVE it to a new file, then load it again with BOLD was successful. A call to BAPPEN to append the saved file to an existing program also worked. I have attached the resulting binary file saved on the SD card.

I tried both with and without the FF at the end of the data. The version without the FF did not work and returned a MAG TAPE ERROR.

I have posted version 0.05.83. Hopefully it will work on the 4054 and 4052 although there are still unanswered questions in my mind.

 

[nikola-wan]

One more thought - my captures of ASCII programs always show an FF character at the end of every program (using Notepad++ as my editor with View | Show Symbol | Show All Characters enabled) - and the ASCII programs have an extra CR with no data after the last line and immediately followed by the FF.

Do I need to capture a 4924 trace of an ASCII Program save from the 4054A?

Since the 4924 does not know when a program save has ended - the 4050 must be sending a CLOSE after ASCII program SAVE too - which causes the write of the FF by the 4924 into that tape block?

Same could be true for the ASCII program OLD command - when the FF was received from the tape, the 4050 might send a CLOSE to terminate the file transfer.

 

[nikola-wan]

Ok, I have updated BSAVE to round the file length to the nearest 256-byte block. A test to load a program and BSAVE it to a new file, then load it again with BOLD was successful. A call to BAPPEN to append the saved file to an existing program also worked. I have attached the resulting binary file saved on the SD card.

I tried both with and without the FF at the end of the data. The version without the FF did not work and returned a MAG TAPE ERROR.

I have posted version 0.05.83. Hopefully it will work on the 4054 and 4052 although there are still unanswered questions in my mind.

I will give it a try.