Tektronix 4924 Tape Drive Emulator

[mmcgraw74]

I found a weird section of code in GPIBdevice.cpp for GPIBbus_SEND

// Otherwise ignore non-escaped CR, LF and ESC
      if ((databuffer != CR) || (databuffer != LF) || (databuffer != ESC)) err = writeByte(databuffer, false);

I don't know why we would be checking on LF or ESC characters on SEND of ASCII data, and we don't want to check for them on binary transfers. 

CR is the terminator for ALL ASCII transfers - PRINT or INPUT.

LF characters ARE in ASCII programs AND ASCII data files and are legitimate control characters.

I don't know that is a problem - but I do see some debug statements with partial strings - I don't know that the above statement is a problem, but I don't understand the logic.

Monty

[WaveyDipole]

It about handling terminators and the escape character when sending text vs binary. Line terminators can vary with the settings of various terminal applications and the OS being used, but the interface wants to send the terminator set by the ++eos command. By default that's CRLF, but can also be set to CR, LF or none. So line terminators are stripped and the configured terminator is sent instead. With the emulator, I have set EOS by default to 1 so that it always sends CR only as the line terminator.

When sending text, we also don't want to inadvertently send ESC characters. In addition, '+' has a special meaning so ESC, CR, LF and '+' can all be 'escaped' so that when sending binary (i.e. when using EOI as the terminator), their byte equivalents can be included in the data.

I believe I have completed the MARK command so new files can now be added. It should now be straightforward enough to add KILL and SAVE so that new files can be created and programs saved.

I will come back to INPUT, but I needed a bit of a diversion.

[WaveyDipole]

I have just pushed up update 05.38. No progress on INPUT, but MARK and SAVE have been implemented and should be working. I will have a look at KILL next and then have another look at INPUT.

[mmcgraw74]

I downloaded version 38 and tried MARK and SAVE which worked.

But looking at your MARK code, I don't think the Tape Emulator should automatically find the LAST file.

The way Tek BASIC works - you need to first find the file you want to use to MARK, then execute the MARK command which will start at that file that you did a FIND and MARK one or more new ones based on the number of files requested, then a new LAST file is created after the last MARKed file.

You are warned in the documentation - that MARKing at an existing file will replace that file and you will also lose access to all subsequent files.

Obviously an issue with our current Tape Emulator is the lack of TLIST command - so I had to know which file was the LAST file before testing your MARK command.  Your code automatically started with the LAST file - but I still have no way of knowing what file(s) were created as Tek BASIC does not report that.

My 'current hack' on TLIST was to manually create a list of the file headers in that folder - but if new files are MARKed or old files are KILLed - my 'hack' won't be current.  It also involved changing file 1 in every folder to add the 'hack' to show the list of files in that folder.

This code won't quite work on Tek BASIC - and will require a little bit of code in the menu program.

I believe we should go back to secondary address 19 for the 'new' TLIST and use secondary address 9 for the change directory command which aligns with the published uses for secondary commands.

I propose the 'new' TLIST would use the INPUT@5,19:A$ format and require PRI@5,9:"directory" command be the preceding command.

To make this work with an INPUT command - the Tape Emulator would return one filename string in filenumber numeric order with each INPUT@5,19:A$ command.
The 'TLIST' code in the menu program would print A$, then check character 8 for an "L", if not found, continue with another INPUT command.

Example 'TLIST' program for Utilities: (tape emulator responses to each INPUT@5,19:A$ in 'code' section)

610 PRINT@5,9:"UTILITIES"
620 INPUT@5,19:A$
630 PRINT A$
640 IF SEG(A$,8,1)<>"L" THEN 620
650 END

Code: [Select]

0      ASCII   DATA [TLIST    ]   3
1      ASCII   PROG [Util Menu]   30
2      ASCII   DATA [Advitm   ]   10
3      BINARY  DATA               29
4      ASCII   PROGRAM   SECRET   26
5      ASCII   DATA [492Scope ]   18
6      BINARY  DATA [4924 dupe]   33
7      ASCII   PROG [Bubl Sort]   30
8      ASCII   PROG [TapeHeadr]   11
9      ASCII   PROG [AlphaSort]   14
10     ASCII   PROG [QuickSort]   12
11     ASCII   PROG [TLIST EXT]   15
12     LAST                      3

We should be able to use part of my original ContinuedDev program TLIST which iterated through each filenumber in sequence - since the SdFAT order is not filename sequential.

One advantage of this 19 command returning a single file header at a time - is it could also be used after a FIND command to return the header for THAT file.

Maybe there is no need to restrict the prior command to an INPUT@5,19:A$ command?  The filename (header) of the current file is a global variable in Tape Emulator.

If the program intent is to do a TLIST - then perform the DIRECTORY COMMAND, then TLIST to get file 1 to the LAST file headers.  If after the directory command there is no filename (NULL filename), then a subsequent TLIST would do a FIND 1 to get the header and subsequent additional TLIST would FIND incremental headers.

[WaveyDipole]

I downloaded version 38 and tried MARK and SAVE which worked.

Thank you for the confirmation.

But looking at your MARK code, I don't think the Tape Emulator should automatically find the LAST file.

The way Tek BASIC works - you need to first find the file you want to use to MARK, then execute the MARK command which will start at that file that you did a FIND and MARK one or more new ones based on the number of files requested, then a new LAST file is created after the last MARKed file.

You are warned in the documentation - that MARKing at an existing file will replace that file and you will also lose access to all subsequent files.

Ok, that is my mis-understanding. I though that the files were added to the end of the current list, but I can change it to start from the current file as determined by the preceding FIND command. That will be slightly more interesting as it may or may not need to rename LAST depending on the start point and the number of files requested.

Obviously an issue with our current Tape Emulator is the lack of TLIST command - so I had to know which file was the LAST file before testing your MARK command.  Your code automatically started with the LAST file - but I still have no way of knowing what file(s) were created as Tek BASIC does not report that.

Yes, had the same problem while working on it but fortunately your original TLIST is available at the terminal from ++tlist. You can also ++cd directory and ++old to have a look at the file.

I believe we should go back to secondary address 19 for the 'new' TLIST and use secondary address 9 for the change directory command which aligns with the published uses for secondary commands.

Agreed.

I propose the 'new' TLIST would use the INPUT@5,19:A$ format and require PRI@5,9:"directory" command be the preceding command.

To make this work with an INPUT command - the Tape Emulator would return one filename string in filenumber numeric order with each INPUT@5,19:A$ command.
The 'TLIST' code in the menu program would print A$, then check character 8 for an "L", if not found, continue with another INPUT command.

Example 'TLIST' program for Utilities: (tape emulator responses to each INPUT@5,19:A$ in 'code' section)

610 PRINT@5,9:"UTILITIES"
620 INPUT@5,19:A$
630 PRINT A$
640 IF SEG(A$,8,1)<>"L" THEN 620
650 END

Code: [Select]

0      ASCII   DATA [TLIST    ]   3
1      ASCII   PROG [Util Menu]   30
2      ASCII   DATA [Advitm   ]   10
3      BINARY  DATA               29
4      ASCII   PROGRAM   SECRET   26
5      ASCII   DATA [492Scope ]   18
6      BINARY  DATA [4924 dupe]   33
7      ASCII   PROG [Bubl Sort]   30
8      ASCII   PROG [TapeHeadr]   11
9      ASCII   PROG [AlphaSort]   14
10     ASCII   PROG [QuickSort]   12
11     ASCII   PROG [TLIST EXT]   15
12     LAST                      3

We should be able to use part of my original ContinuedDev program TLIST which iterated through each filenumber in sequence - since the SdFAT order is not filename sequential.

One advantage of this 19 command returning a single file header at a time - is it could also be used after a FIND command to return the header for THAT file.

Maybe there is no need to restrict the prior command to an INPUT@5,19:A$ command?  The filename (header) of the current file is a global variable in Tape Emulator.

If the program intent is to do a TLIST - then perform the DIRECTORY COMMAND, then TLIST to get file 1 to the LAST file headers.  If after the directory command there is no filename (NULL filename), then a subsequent TLIST would do a FIND 1 to get the header and subsequent additional TLIST would FIND incremental headers.

I think I follow all that but will re-read it again tomorrow when I am not so tired. Having read this I found that HEADER@5: as shown in the 4924 operators manual does nothing except show a syntax error so using PRINT@5,9 could be used to change directory as per the current CD function.

On the other hand I discovered that LIST@5: tries execute the current CD command (19) and according to the BASIC reference is meant to list the program either a single line, complete or between the requested line numbers. I hadn't realised it was possible to list the program before using OLD. It doesn't seem to be supported on the 4924, but could be on the emulator if required. I suppose that might be useful for identifying the program. If we don't want to keep that functionality, then command 19 can be re-assigned to the new TLIST as you describe, otherwise we could use 8 [UNIT] (does nothing on the 4051 except generate a syntax error) so that the two commands are adjacent numerically or we did talk about using 31 which is undefined for TLIST before. Maybe we should try it - at least temporarily?

[mmcgraw74]

The 4924 didn't support sec address 19 - so I think it is perfect for the TLIST.  Particularly if someone with the Tape Emulator is trying to find how to TLIST - 19 should be what they try.

[WaveyDipole]

Ok, fair enough, but I also just had the thought that any process that alters the file names could also update the file 0? This would include MARK, SAVE where the file is changed from NEW to ASCII PROG and KILL.

BTW, by what process are files changed to ASCII DATA or BINARY DATA? Is it when a NEW file is written to by INPUT or WRITE? What about BINARY PROG?

[mmcgraw74]

Ok, fair enough, but I also just had the thought that any process that alters the file names could also update the file 0? This would include MARK, SAVE where the file is changed from NEW to ASCII PROG and KILL.

BTW, by what process are files changed to ASCII DATA or BINARY DATA? Is it when a NEW file is written to by INPUT or WRITE? What about BINARY PROG?

Page 2-16 in the 4050 Graphics System Reference (070-2056-01) shows two PRINT statements that are directed at the internal tape drive to allow the header to be accessed.  In a later section they show an example program to modify the header to add comments.

So, I think the answer is - Tek BASIC rewrites the internal AND external tape headers.

There is a 4924 Tape Duplicator program on my repo:

https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/blob/master/NICE_UTILITIES/6_4924%20Tape%20Duplicator.UNI

You can see the PRINT@x,0: and INPUT@x,0: commands that are setting and reading the 4924 Status respectively.  They are changing the third byte of 4924 status to gain access to the 256 byte block with the Tape Header so they can rewrite it to make a copy of an entire tape including any comments in the headers.

[WaveyDipole]

I think I have misunderstood the purpose of the IO parameter after the LIST command. It seems that specifying a GPIB address sends the program listing to a specified device which I imagine could be a printer.

I have got the KILL command working this morning and have moved the current CD command to secondary address 9. I have also got secondary address 19 sending consecutive filename entries when using INPUT@5,19:A$ as requested. The list rolls around to file 0 after it reaches LAST. After changing directory using PRINT@5,19:A$ the list will reset and start at the beginning of the new directory. I have also updated FIND to set the index to the current file so that when an INPUT@5,19:A$ is done immediately after a FIND, it will print the current file header.

I have uploaded the updated code.

[mmcgraw74]

Yes - I use LIST@40: to send the current program listing in memory to my Option 1 RS-232 serial interface connected to my PC.

I will download and give your updated version of the Tape Emulator a try now

[mmcgraw74]

v39 CD(9) and new HEADER(19) commands worked fine!

I put my A-Series Hilbert.uni (as ASCII PROG file 7) and my latest HilbertOrder6-sm.uni (as ASCII PROG file 5) programs in the Games folder.

I was able to load and run file 5 on my 4052.

However, I hung the Tape Emulator trying to load file 7 - as the 4052 cannot parse the new A-Series syntax.

Here is the serial debug output for that:

Code: [Select]


gc_0x7B_h: received parameter:  7
                                           
searchForFile: searching /GAMES/...
                                           
searchForFile: found file 7
                                                   
searchForFile: done.
                                                         
stgc_0x7B_h: found: 7      ASCII   PROG [HILBERT   ]   3
                     
stgc_0x7B_h: type:  P
                                                         
Executing secondary address command: 64
                                       
stgc_0x64_h: started OLD/APPEND handler...
                                   
stgc_0x64_h: reading /GAMES/7      ASCII   PROG [HILBERT   ]   3...

Tek BASIC stopped the program load and printed a syntax error message on the underscore on the _order variable in line 100.

I pressed the CLEAR key and attempted to FIND@5:5, but the Tape Emulator was hung and had to be power cycled.

I think the OLD command didn't handle the Tek attempt to end the command?

[WaveyDipole]

I tend to agree. It would have been still stuck in the send loop.

I did an LA scan when pressing CLEAR on the 4051 and it did absolutely nothing on the GPIB bus. The thing is, if it gets stuck on syntax, then the Tek must send something to discontinue transmission. I will create a short program with a syntax error and capture what the Tek does. It is most likely holding NRFD and asserting ATN like for INPUT but I don't think I have implemented the necessary checks in OLD yet. We also talked about clearing on REN being asserted. I still need to have a look at that one as well.

[mmcgraw74]

I got the replacement transistor for my 4052 display board - installed it and now my 4052 is working again!



I'm running the Hilbert curve program - to prove this is a new photo

The blue LED in the upper left corner is from my Tape Emulator board - plugged into a short GPIB cable, so it is easier to access.

I have edited the menu programs on SD card and uploaded a new zip file to your Store. 

Delete the old files - I removed the "0" files from all folders and edited the menu programs to support the new CD(9) and TLIST/HEADER(19) commands.

[WaveyDipole]

Good to hear that you 4052 is up and running again!

I have downloaded your new ZIP (v6) containing the SD card programs.

I also ran your modifier Hibert program. It loaded much quicker and shows 19kb of memory available when the program is loaded. I couldn't list the program as the after line xxx I got an error telling me the line was too long, however the program ran and drew the matrix.

[mmcgraw74]

Good to hear that you 4052 is up and running again!

I have downloaded your new ZIP (v6) containing the SD card programs.

I also ran your modifier Hibert program. It loaded much quicker and shows 19kb of memory available when the program is loaded. I couldn't list the program as the after line xxx I got an error telling me the line was too long, however the program ran and drew the matrix.

Yes - I picked 64 bytes for the DATA statements which makes them 73 characters long including the CR
I also had to remove the space between the line number and DAT and the space between the DAT and first quote.

Since OLD parses the statement and tokenizes the command - it didn't complain.
I'm not surprised that LIST complains as the ASCII statement is 73 characters including the CR.

I was hoping this technique of converting to characters would get enough room to store an Order 7 Hilbert - but that is 4x the number of vectors - so no way it would fit in a 4051.  Someone would have to write a routine that did not require recursive calls so the 4051 would have a 'real' program to do any size Hilbert curve.

I also got a reply on my Hilbert post in vcfed saying Sierpenski triangles are also space filling curves.  However all the programs I saw were for bitmap drawing - not vectors.  I was looking at drawing vector triangles - but you need to fill the interiors to look right and that is a bit of code I haven't done.

[mmcgraw74]

With my 4052 working again - we need to figure out why the INPUT command doesn't work reliably on the 4052.

The 4054A shows an additional issue - the BASIC INIT command in almost every program hangs the computer AND the Tape Emulator
When this happens - I have to power cycle both the Tek and the Tape Emulator.
I suspect the 4054A 9914 IC and BASIC ROM are changing the REN state during the INIT and the Tape Emulator doesn't respond correctly - but that will take getting a trace to see exactly what is happening on the GPIB bus.

The 4054A also has same problem with the Adventure INPUT statements as the 4052. 

It also has a problem with the CD(old 19 or new 9) command in the folder menu programs - it gives error 69 most of the time.
If I RUN at that line number (like I do for the INPUT command hangs) it typically completes that command and continues.

Both 4052 and 4054A will complete the menu program TLIST (after the CD is repeated on the 4054A).

[WaveyDipole]

I did a handful of LA captures with and without INIT in the first line of a short program. The REN line is asserted as soon as the BASIC program starts running in both cases. Without INIT, NRFD and NDAC both get asserted for 4ms just before REN ends after the program terminates. With INIT, the IFC signal is asserted for approximately 250uS in addition to REN and simultaneously NRFD and NDAC are asserted for as long as the program runs.

I think the relevant signal is IFC (Interface Clear) and the emulator needs to clear GPIB and reset to idle whenever an IFC signal is detected. This means that the IFC signal will need to be detected during any read or write loop.

It also has a problem with the CD(old 19 or new 9) command in the folder menu programs - it gives error 69 most of the time.
If I RUN at that line number (like I do for the INPUT command hangs) it typically completes that command and continues.

I have been looking at your traces in post 262, but I believe that would like to see a trace of CD using v39 that when you have time please.

[mmcgraw74]

Some of my problems with input are still around timing - but I now have Adventure working on my 4052!

I found some Commodore 64 characters with ASCII values above 127 in my data files - I posted the new SD card image 7 on Store.

I also moved the Adventure main program to file 1 - and changed all the menu programs to load that file.
I created new files 51,52 and 53 which should be able to create and verify all the data files - but I guess we don't have PRINT to file working yet?  I can't save my Adventure game, although there was no GPIB error.  When I tried to LOAD that file - BASIC was hung on the first INPUT.  I put NEW files with those filenames in the Adventure directory for the save games.

After my data file changes - the number of times INPUT fails is reduced considerably on my 4052.  But my Adventure program currently has long delay loops of 100 between each INPUT command from a file.

please try my data file creation programs on your 4051 after you get PRINT to file to work.

Otherwise just try file 53 - which I have changed to bypass file creation and just do the verify of the current files.
On my 4052 - it verifies the file 2 against data statements in the program but always fails on file 3.

In the meantime - here is a photo of running my port of Adventure in BASIC on my 4052 from the Tape Emulator.  This time Adventure loaded without INPUT errors.  I'd say one out of three times - huge improvement.  Second photo shows a collection of treasures.

I still have some minor display problem - some of the characters are misaligned - I suspect maybe a bad voltage on the display board (leaky capacitor?).  It doesn't keep me from using the 4052 to test.

[mmcgraw74]

[WaveyDipole]

Some of my problems with input are still around timing - but I now have Adventure working on my 4052!

I found some Commodore 64 characters with ASCII values above 127 in my data files - I posted the new SD card image 7 on Store.

That's good news!. I just tried to run your program file no. 53 in "Adventure" as suggested. Unfortunately it didn't run but that seems to be down to memory (or rather shortage of it). I got the following:

Code: [Select]

MEMORY IS FULL IN LINE 16 - MESSAGE NUMBER 39

I ran MEM and it returned 308. That seemed odd considering the file is 21kb long so I deleted the program from memory and MEM returned 30699. I then loaded up file 53 again and MEM returned 8963. After another RUN attempt I got the same as above. There is evidently insufficient space to DIM the variables in that statement.

I then tried file 51 which did run and created files 0-9 but stopped on file 10. The output is shown in the photo. Yes, the PRINT command is present on the emulator. It was added in version 05.34. At present it writes to files marked 'DATA' but this will require amending to further distinguish between files of type ASCII DATA and type BINARY DATA.

Support has also been added for CALL "BSAVE" and CALL "BOLD" which require the Binary Program Loader cartridge on the 4051. The command CALL "BSAVE" writes to files of type type NEW or BINARY PROGRAM. In the same way that SAVEing to NEW renames the file to ASCII PROG, BSAVE renames a NEW file to BINARY PROG. The counterpart, CALL "BOLD" reads from type BINARY PROGRAM.

Detection of IFC to clear the interface to idle state has also been added.

I am holding fire on uploading it until I have had the chance to fully analyse the information in your latest post and LA traces. Thank you for the providing the details.

SRQ - this seems very odd. I am now using the same adapter board and SRQ goes HIGH on mine and stays HIGH on all the traces. When you read the LA trace was anything else connected? BTW, the layout I created uses direct writing to Arduino ports to change pin states but doesn't use interrupts.

Thank you for providing the traces and details of your captures. I have uploaded 0.05.40 so you can test whether the IFC handling works and helps at all. Once I have more fully analysed the details in your post (e.g. the CD issue), there may be other amendments.

Incidentally, adding CALL "BSAVE" and CALL "BOLD" was an interesting exercise as both commands use the same secondary address number 17 (0x71). It turns out that it is possible to support more than one command on a singe secondary address. In this case CALL "BSAVE" is a listen command and CALL "BOLD" is a talk command so it was just a matter of determining whether the command was asking the emulator to talk or listen and calling the appropriate function. I imagine that CALL "BAPPEN", which also uses the same secondary address, can further be added because it adds line number parameters so on detecting those, the emulator would modify the behaviour of the function that responds to BOLD. We then end up with 3 commands on the same secondary address.

Well, it occurred to me that a similar approach could be applied to the CD command. Currently PRINT@5,9:"directory" sets the working directory. I could be set up so that INPUT@5,9:A$ also reads back the current directory name.

Another idea that ocurred to me was to have the PRINT command produce output on the terminal screen. In the same way that you can send a listing to a printer, you could sent it to the PC screen or over serial to somewhere...

[mmcgraw74]

I just tried to run your program file no. 53 in "Adventure". Unfortunately it didn't run. I got the following:

Code: [Select]

MEMORY IS FULL IN LINE 16 - MESSAGE NUMBER 39

I ran MEM and it returned 308. There was evidently insufficient space to DIM the variables in that statement. That seemed odd considering the file is 21kb long. I deleted the program from memory and MEM returned 30699. I then loaded up the file and it returned 8963. After another run I got the same as above.

I then tried file 51 which created files 0-9 but stopped on file 10. The output is shown in the photo. Yes, the PRINT command is present and was added in version 05.34. It writes to files marked 'DATA'. It will require amending to further distinguish between files of type ASCII DATA and type BINARY DATA.

Support has been added for CALL "BSAVE" and CALL "BOLD" The command CALL "BSAVE" requires the Binary Program Loader cartridge on the 4052 and writes to files of type type NEW or BINARY PROGRAM. In the same way that SAVEing to NEW renames the file to ASCII PROG, BSAVE renames a NEW file to BINARY PROG. The counterpart, CALL "BOLD" reads from type BINARY PROGRAM.

Detection of IFC to clear the interface to idle state has also been added.

I am holding fire on uploading it until I have had the chance to fully analyse the information in your latest post and LA traces. Thank you for the providing the details.

SRQ - this seems very odd. I am now using the same adapter board and SRQ goes HIGH on mine and stays HIGH on all the traces. When you read the LA trace was anything else connected? BTW, the layout I created uses direct writing to Arduino ports to change pin states but doesn't use interrupts.

Thank you for providing the traces and details of your captures. I have uploaded 0.05.40 so you can test whether the IFC handling works and helps at all, however once I have more fully analysed the details in your post (e.g. the CD issue), there may be other amendments.

You should be able to change all three MAKE programs to remove the DIM statement and use plain variables to reduce the memory footprint.  No need to keep the entire arrays in memory.

On the SRQ subject - maybe the 4051 automatically enables the SRQ interrupt.  The 4052 and 4054A may disable the SRQ by default and only enable it if the program uses an ON SRQ statement with interrupt handler code.

Hmm - I tried a short SRQ test program on my 4054A with
10 RETURN
100 ON SRQ THEN 10

I see a lot of noise on the SRQ line with the LA.  Maybe the 644 can't drive that line hard enough?

I don't have any other equipment connected to GPIB - just a short HP GPIB cable to the LA - and the Tape Emulator plugged directly into the 4054 on top of the GPIB cable.

I'll check out your new version now.

[mmcgraw74]

I tried your new version on my 4054A - no difference.

Typing INIT hangs the 4054A and Tape Emulator.

Running Adventure, the LA Waveform looks different than on v39 - but BASIC stops at line 171 with J=3 like before.



I also attached a zip of the trace listing

[mmcgraw74]

I took some time with EXCEL to edit the trace.

I figured out how to compute absolute time and added that column.
Also added column that inverted the GPIB data.
And added an ASCII decoded column with blanks for data invalid.  I used /DAV & /NDAC & /NFRD to enable the ASCII output text.

Then I manually edited in the UNTalk, UNListen, PRI 5 Talk or Listen, FIND and INPUT commands.

I also found the technique to get Notepad++ to freeze the heading lines of the trace:

• Clone the trace to Other View
• Right click the divider bar and rotate left
• Adjust the divider bar to show the header lines at the top
• Scroll the bottom view and the header lines are always visible

Hope this helps.

 ADVHANG2edited.zip (5 kB - downloaded 17 times.)

[WaveyDipole]

I tried your new version on my 4054A - no difference.

Typing INIT hangs the 4054A and Tape Emulator.

Looking at the LA output it seems that the emulator is going to idle, however I did omit something. There was a flag that should have been reset. Theoretically it should not have made a difference since the next MTA or MLA received ought to indicate whether the emulator should talk or listen but ideally the flag should have been cleared. I have now amended the code to clear that flag.

Thank you for the updated LA output. I just had a look and realised that there is something a bit odd going on. Here is the first few entries:

Code: [Select]

Label    >Time usec Time msec DATA DATA ASCII ATN NDAC NFRD EOI DAV REN IFC
Base     > Relative Absolute  Hex  Hex        Bin Bina Bina Bin Bin Bin Bin
__________ _______  ________  ____ ___  ____  ___ ____ ____ ___ ___ ___ ___
     -4     505.4    0.505    82   7D          0    0    1   1   1   0   0
     -3         8    0.505    00   FF          0    0    1   1   1   0   0
     -2        40    0.505    20   DF          0    0    1   1   1   0   0
     -1         8    0.505    A0   5F          0    0    1   1   1   0   0
      0     2.008    0.507    A0   5F          0    0    1   1   0   0   0
      1     78.74    0.586    A0   5F    UNT   0    0    0   1   0   0   0
      2     11.45    0.598    A0   5F          0    1    0   1   0   0   0
      3       104    0.598    A0   5F          0    1    0   1   1   0   0
      4     23.35    0.621    A0   5F          0    0    0   1   1   0   0
      5     30.46    0.652    A0   5F          0    0    1   1   1   0   0
      6     245.1    0.897    00   FF          0    0    1   1   1   0   0
      7        40    0.897    58   A7          0    0    1   1   1   0   0
      8         8    0.897    DA   25          0    0    1   1   1   0   0
      9     2.176    0.899    DA   25          0    0    1   1   0   0   0
     10     111.9    1.011    DA   25  PRI 5 L 0    0    0   1   0   0   0
     11     11.44    1.022    DA   25          0    1    0   1   0   0   0
     12       104    1.022    DA   25          0    1    0   1   1   0   0
     13     23.36    1.046    DA   25          0    0    0   1   1   0   0
     14     29.90    1.076    DA   25          0    0    1   1   1   0   0
     15     214.5    1.290    CA   35          0    0    1   1   1   0   0
     16         8    1.290    00   FF          0    0    1   1   1   0   0
     17        48    1.290    80   7F          0    0    1   1   1   0   0
     18         8    1.290    84   7B          0    0    1   1   1   0   0
     19     2.048    1.292    84   7B          0    0    1   1   0   0   0
     20     38.56    1.331    84   7B   FIND   0    0    0   1   0   0   0
     21     11.44    1.342    84   7B          0    1    0   1   0   0   0
     22       104    1.342    84   7B          0    1    0   1   1   0   0
     23     23.36    1.366    84   7B          0    0    0   1   1   0   0
     24     30.58    1.396    84   7B          0    0    1   1   1   0   0
     25     284.6    1.681    84   7B          1    0    1   1   1   0   0
     26     80.70    1.762    84   7B          1    0    0   1   1   0   0
     27     385.1    2.147    80   7F          1    0    0   1   1   0   0
     28         8    2.147    00   FF          1    0    0   1   1   0   0
     29        40    2.147    DF   20          1    0    0   1   1   0   1
     30        40    2.147    FF   00          1    0    0   1   1   0   1
     31         8    2.147    FF   00          1    0    0   1   1   0   1
     32         8    2.147    DF   20          1    0    0   1   1   0   1
     33     18.00    20.147   DF   20          1    0    1   1   1   0   1
     34       136    20.147   DF   20          1    0    1   1   0   0   1
     35     23.64    20.171   DF   20          1    0    0   1   0   0   1
     36     11.44    20.182   DF   20          1    1    0   1   0   0   1
     37       104    20.182   DF   20          1    1    0   1   1   0   1
     38     31.11    20.213   DF   20          1    0    0   1   1   0   1
     39     188.4    20.402   DF   20          1    0    1   1   1   0   1
     40     75.22    20.477   D7   28          1    0    1   1   1   0   1
     41         8    20.477   00   FF          1    0    1   1   1   1   0
     42         8    20.477   00   FF          1    0    1   1   1   0   0
     43        40    20.477   80   7F          1    0    1   1   1   0   0
     44         8    20.477   CD   32          1    0    1   1   1   0   1
     45        24    20.477   CF   30          1    0    1   1   1   0   1
     46         8    20.477   FF   00          1    0    1   1   1   1   1
     47         8    20.477   DF   20          1    0    1   1   1   1   1
     48         8    20.477   CD   32          1    0    1   1   1   1   1
     49         8    20.477   CD   32          1    0    1   1   1   0   1
     50         8    20.477   CD   32          1    0    1   1   1   0   1
     51     1.120    20.478   CD   32          1    0    1   1   0   0   1
     52     68.59    20.547   CD   32     2    1    0    0   1   0   0   1
     53     11.44    20.558   CD   32          1    1    0   1   0   0   1
     54       104    20.558   CD   32          1    1    0   1   1   0   1
     55     8.176    20.566   CD   32          1    1    0   0   1   0   1
     56         8    20.566   80   7F          1    1    0   0   1   0   0
     57         8    20.566   00   FF          1    1    0   0   1   0   0
     58        40    20.566   70   8F          1    1    0   0   1   0   0
     59         8    20.566   F2   0D          1    1    0   0   1   0   0
     60        24    20.566   FB   04          1    1    0   0   1   0   1
     61         8    20.566   FF   00          1    1    0   0   1   1   1
     62         8    20.566   FF   00          1    1    0   1   1   1   1

IFC is LOW (asserted) but at the same time so is ATN and commands are being sent: UNT, PRI 5, FIND. After this ATN goes HIGH and the parameter 2 is sent. IFC goes HIGH but is asserted briefly before and after the 2 is sent as if the Tek is still trying to force the emulator to clear. It doesn't seem to make sense for commands or data to be transmitted while IFC is still asserted. However, the emulator is responding to ATN being asserted by the TEK by going to attention and subsequently a series of commands is being transmitted while IFC is still asserted. I have therefore added a statement into the main loop to prevents the emulator from going to attention while IFC is still asserted. The emulator will wait for a short while and try again on the next iteration of the loop. If IFC is now de-asserted, it will go to attention, otherwise it will wait another period until IFC is de-asserted.

[mmcgraw74]

Here are the original 4054 GPIB schematic and the 4054A GPIB schematic from one of the two 4054/4054A latest service manuals.





And links to both the 4054/4054A version 3 service manuals:

http://dvq.com/tektronix/Tek_070-2840-03_4052-4054A_technical_data.pdf
http://dvq.com/tektronix/Tek_070-2839-03_4054-4054A_parts_and_schematics.pdf

The Technical Data only described the 4054 GPIB and mentioned that the 4054A used a 9914A IC.

Here is a link to the TI 9914A GPIB Controller manual:
http://www.bitsavers.org/components/ti/TMS9900/TMS9914A_General_Purpose_Interface_Bus_Controller_Data_Manual_Dec82.pdf

I will download and try your new amendment to the emulator.