Tektronix 4924 Tape Drive Emulator

[WaveyDipole]

Thank you. I didn't have those.

[mmcgraw74]

Something is odd about my edited trace - the REN and IFC values don't look like the waveform

I am making progress on getting the HP GPIB Preprocessor connected to the logic analyzer - I found a document describing how to get the GPIB inverse assembler loaded without errors.  I plan to connect it to the 4054A today and see if the GPIB Preprocessor and GPIB inverse assembler output works. 

Hopefully it will fully decode the states so we don't have to manually examine/edit the listings.

It should also provide the GPIB waveforms.

[WaveyDipole]

No worries. I will wait for your revised data. The amendment to the flag value needed to be done anyway.

Hope the pre-processor works out OK. That will no doubt be useful once working. We can have another look at the IFC signal once a new listing has been generated.

[WaveyDipole]

I managed to get a bit further with Adventure program file 51. There is a slight bug in the code which was causing blank lines to be added to the data file:

Code: [Select]

151 C$=CHR(13)
...
578 PRINT@5:Z$;C$
I am uncertain as to the reason for adding a CR to the BASIC PRINT statement, but since PRINT already terminates any string with a CR, adding another one was causing data elements to be placed on every other line in the file instead of consecutive lines. Consequently the first line passed verification but when the loop read line 2, it was comparing the second DATA element with a blank line in the file and so the verify failed. Simply changing this to:

Code: [Select]

578 PRINT@5:Z$
creates the with data on consecutive lines and verify then works. However, I did run into a problem. After the second file was verified I got:

Code: [Select]

GP INTERFACE BUS I/O ERROR IN LINE 622 - MESSAGE NUMBER 69

Curiously the fail seems quite consistent in that it always fails on file 12 but it does seem like the sort of thing your are getting on your 4052 and 4054? I have done a capture on the LA and will have a closer look tomorrow.

[mmcgraw74]

Hmm, when I wrote the three Adventure MAKE programs, it looked like the emulator was not putting CR after each string - so I added the CR to each string before the print statement.  Then I manually verified each data file with Notepad++ and then jumped around the file create to the file verify.

Right now I'm having trouble getting the Inverse Assembler traces or waveforms to make any sense.
Possibly the HP 10342B GPIB Preprocessor has some bad ICs.  I can't find the schematic or service manual for it on the web. 

I'm thinking it would only be helpful if the data bytes weren't correct - I don't think that is our issue with the tape emulator.

[mmcgraw74]

However, I did run into a problem. After the second file was verified I got:

Code: [Select]

GP INTERFACE BUS I/O ERROR IN LINE 622 - MESSAGE NUMBER 69

Curiously the fail seems quite consistent in that it always fails on file 12 but it does seem like the sort of thing your are getting on your 4052 and 4054? I have done a capture on the LA and will have a closer look tomorrow.

Yes - that is the type error I've been seeing on my 4052.  It seems like DATA files with numbers don't have this error, but the files with strings do.  Maybe the files with strings are much longer - or maybe the characters are sent faster than the numbers.  Tek BASIC encodes all numbers in DATA statements in binary and has to convert them to decimal ASCII in PRINT statements, where character strings in DATA statements are not in binary and are sent without modification in PRINT statements.

We should check the GPIB byte timing for string characters versus byte digits.

[mmcgraw74]

John,  when I get that error, I simply RUN x where x is the line number reported with the error.

That works to get my 4052 to get past those errors and start running Adventure.

[mmcgraw74]

Ok - I spent time this morning to convert the 4054 ADVHANG trace listing into a spreadsheet.

First I used Notepad++ column editor to insert commas between the columns to create a ADVHANG2a.CSV file.

Then used Notepad++ to convert the ns / us / msec column into numbers 0.000000001, 0.000001, and 0.001 for time calculations.

I imported that file into EXCEL and added some columns for time and ASCII data calculations.

1-calculated absolute time (msec) from the relative time added to the previous absolute time
2-uninverted the GPIB Hex DATA and printed ASCII on valid data using /DAV & /NDAC & /NRFD calculation as the qualifier
3-edited the ASCII data column for PRI talk or listen address, FIND or INPUT on secondary address, UNTALK, UNLISTEN and CR.

I've attached a zip with the CSX,XLSX and PDF print files.

 ADVHANG2a.zip (174.47 kB - downloaded 48 times.)

And here is page 1 of the resulting PDF file:



I found one omission in my ASCII data edits - on line "Label 35" after the FIND secondary address command, there is a SPACE character prior to the filenumber 2 on line "Label 52", since Tek BASIC prefaces printed numbers with space.

There are no spaces on the numbers in the INPUT commands - as these files were created by printing STRING data statements and there were no spaces in front of the numbers in the DATA statements.

[mmcgraw74]

I'm going back to my direct capture of any more traces.

The GPIB PreProcessor output will only provide STATE info, and somehow my configuration is not providing the correct bits in the correct order.

I do have the GPIB inverse assembler source file - but I would have to learn the IA language to understand what it is doing, and I don't think we need it right now.

I do wonder - since lots of INPUT commands work but sometimes they fail - whether this may be a hardware issue as my board does not have the GPIB drivers, but is directly driving with the Arduino Mega 644 IC. 

I will try running the Tape Emulator directly plugged into my 4052 and 4054A without any other GPIB cables.

[mmcgraw74]

My experiments on my 4052 and 4054A plugged directly in with power from a phone charger did not have any difference in behavior.

Still got GPIB errors in random locations loading the files into Adventure.

We still could have a hardware issue with the direct drive from the Mega 644, or it could be software.

[WaveyDipole]

I spent considerable time on this error 69 issue today and I think that I have may have discovered what might be main cause of the dropouts. There were a couple of minor bugs to fix along the way, but the primary cause appears to have something to do with the use of the Arduino millis() function in the timing loop. I don't know exactly what the problem is with millis(), but having tried another approach to using it per an Arduino example, resulted in the same error 69 problems occurring. Eventually when I amended the timing function in question (waitOnPinState) to remove millis() and implement the delay using a different (and perhaps less precise) method, this seemed to solve the problem. The 4051 could now successfully run the complete program 51 all the way to the end of the verification process. I also tried and was able to successfully run program 52. Reverting back to using millis() breaks it again.

It should be noted that both programs required minor modification in order to run:

Both programs (as previously mentioned):
578 PRINT@5:Z$

Program 52:
583 IF I=15 THEN 585
584 GO TO 570

Line 583 was essentially missing from program 52 so it tried to continue with the loop and stopped with a DIM subscript error. I haven't done anything further with program 53 yet.

I have uploaded an updated version (0.05.42). I am eager to see whether it passes the 4052 and 4054 test!

(BTW, the zereos at the end of the first output are down to me accidentally leaning on the key!)

[mmcgraw74]

Great progress on the 4051 running the Tape Emulator with your v42.

I first tried v42 on my 4052.  No joy.  The 4052 will not run Adventure any more.  Most times it hangs with the I/O light on - I can stop the program with double-BREAK, but can't resume with RUN and the line number of the error.  I get a new error "INVALID COMMAND ARGUMENT IN LINE 190 - MESSAGE NUMBER 19" for example.  This line has a NEXT J statement.  J was 28 when I pressed BREAK twice.  It is always hanging on this section of code at random J loop counts. 

I have been watching the LEDs on the Tape Emulator plugged into a GPIB cable like an extender so the Tape Emulator is hanging to the right of the screen.  The GREEN LED flashes when the Tape Emulator is accessing the micro SD card.  If the GREEN LED stops flashing and the 4052 I/O Lamp is ON - the program is hung.

Next I tried v42 on my 4054A and it made a considerable improvement!  I can now load and run Adventure with no errors reported 4 out of 5 times - I couldn't run Adventure on my 4054A before.  I still get an occasional error 69 during the program initialization (Welcome to Adventure! is being printed), but I and can continue with RUN of that line number.

One difference on the 4054A running Adventure - I now get occasional error 69 when accessing a new location.  I never saw this on the 4052 after the program was initialized and was playing the game. 

[mmcgraw74]

Great NEWS!  Tape Emulator is now working on my 4052 AND 4054A!!   

I got to thinking about the Tape Emulator Green LED on the board - it isn't anything to do with the micro SD card - it is connected to the serial TX pin!

I disabled the setup section that initializes the Comm port and Debug port.

Then I uploaded my modified v42 to the Tape Emulator and the weird problems are GONE on both 4052 and 4054!!

I think we can now work on the remaining tape functions!

I ran Adventure on both 4052 and 4054A with no issues.

I then tried to run the SysTape programs - and the Y Plot worked but the other selections reported no program found.
I checked that folder and the filenames for files 10 and higher were not formatted correctly so the emulator could not detect the file type.

I also had to mod my v42 to increase the number of files to 110 - as there are 106 files in the System Tape.

I corrected the filenames on those files and tried the 4054 Special Functions on my 4054A and the program indicated it only worked on a 4054.
I checked that file (103) and the test for the 4054 did not support the 4054A - so I added that test and here is a screenshot of one of the features only in the 4054 and 4054A computers - dashed lines:



I have uploaded a new micro SD image zip to your repo

It's Miller Time!

[mmcgraw74]

I was trying to fix some of the SysTape files and then started with the first file and compared to the original tape dump and fixed all the files.

I recommend you try to run SysTape (ROOT menu selection) - I still have some things that aren't working.

I also 'ported' COLOSSAL16 to the tape emulator, added it to the games menu and added a file 9 in that folder to use for save games.
My 4052 is not writing CRs after each PRINT to the save game file - not sure why, but it hangs on trying to LOAD file 9 because there are only two CRs in the whole file.

I ported COLOSSAL16 from a Commodore game - it is similar to Adventure and works on the 4051 emulator, should work on your 4051 (including SAVE and LOAD - use file 9).

I just uploaded the new SD image to your repo with all the changes above.

[mmcgraw74]

I believe I found the remaining bugs in the SysTape files - I posted a zip of the fixed SysTape on your repo.

I would like to know how it runs on your 4051.

My next step is to begin building the 'real' SD image folders - porting the programs to use the Tape Emulator for file access, and adding folder menu programs if not already in that tape.

[WaveyDipole]

I have just pulled v9 of the Tek4924sd archive and copied it to my SD card. Program 1 from the SysTape directory ran fine and from the menu I was able to choose all the types of graphs, enter data and produce a plot. I then ran the tutorial although only for a short while so it was not an in depth test, but it did show me at least a couple of plot examples. I also tried the Firmware Verification Program (4051 only) - option 7. This sat for a few minutes with BUSY and IO on but it didn't return to either the cursor or the error. Perhaps it just takes rather more that 'bout a minute' when you have a full compliment of 32k of RAM? I aborted after about 5 mins but will have another go tomorrow and leave it running for longer to see what happens.

After Tuesday's effort I had to have a break on Wednesday, but I did manage to do a little bit of work on the 4051 Emulator. There is still quite a bit to do before I have a working importer for the 4924 emulator directory structure.

This morning I made a start on modifying the MARK function as discussed but I didn't have a lot of time as I had to go out in the morning and had a medical appointment later in the day, so I didn't get to complete it. Hopefully I can get that done in the next couple of days. I am also putting together a synopsis of the currently working commands.

[mmcgraw74]

I have just pulled v9 of the Tek4924sd archive and copied it to my SD card. Program 1 from the SysTape directory ran fine and from the menu I was able to choose all the types of graphs, enter data and produce a plot. I then ran the tutorial although only for a short while so it was not an in depth test, but it did show me at least a couple of plot examples. I also tried the Firmware Verification Program (4051 only) - option 7. This sat for a few minutes with BUSY and IO on but it didn't return to either the cursor or the error. Perhaps it just takes rather more that 'bout a minute' when you have a full compliment of 32k of RAM? I aborted after about 5 mins but will have another go tomorrow and leave it running for longer to see what happens.

That program doesn't return to BASIC - if no error is reported, your 4051 passed the test.  You have to power cycle your 4051.

After Tuesday's effort I had to have a break on Wednesday, but I did manage to do a little bit of work on the 4051 Emulator. There is still quite a bit to do before I have a working importer for the 4924 emulator directory structure.

This morning I made a start on modifying the MARK function as discussed but I didn't have a lot of time as I had to go out in the morning and had a medical appointment later in the day, so I didn't get to complete it. Hopefully I can get that done in the next couple of days. I am also putting together a synopsis of the currently working commands.

Sounds good.

I don't think we need to work on READ or WRITE - as I have to modify all the SD card programs to support the @5 GPIB address, I can replace READ with PRINT and WRITE with INPUT as they are equivalent - just take more file space and maybe are a little slower - which is not a problem for the SD card or performance.

The internal tape is quite a bit slower than the Tape Emulator for file read/write and super slow for FINDing a file.

[mmcgraw74]

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:

(Attachment Link)

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

This is a comment I made in an older post on Sept 16 at 08:17:28pm

Tek BASIC EOF is 255 not 127 as I stated in that post.

Reason to bring this up again - in running the 4050R12 Enhanced Graphics ROM demo tape picture files - file 9 which is the SIN(X)/X plot hangs every time on both the 4052 and 4054A.  Since I disabled the debug output - I don't know what the last Arduino debug message was.

I wonder if the emulator code is looking for character 127 as EOF?  There is one near the end of that picture file.  I wonder if this is what is stopping the loading of the picture file.  All I have to do is run that program line again and the file load completes and the picture is displayed.

[WaveyDipole]

I did pick up on the fact that EOF was hex 0xFF at some point from the manual but off the top of my head I am uncertain whether the emulator is looking for a 0x7F (127) anywhere so I will check the rest of the code and amend accordingly.

I have been dealing with family matters and a bit of a saga with a replacement for my ailing tower PC (see PM) which is why I haven't been on for a few days, but hopefully tomorrow I can finish sorting out the MARK function and check this out.

I am curious why turning off the debug messages is necessary. While it is true that processing them takes time, the GPIB handshaking protocol is designed to wait for the slowest device to catch up. There is a timeout parameter as a GPIB interface cannot wait indefinitely for a signal but I can't imagine the timeout period on the Tek 4054 or 4052 would be so short as to present a problem. I haven't seen anything about setting the GPIB timeout on the Tek, but if there is such an option somewhere it might be worth exploring and increasing the timeout period. I will have a dig into the manuals tomorrow to see whether I can find any information on this.

[mmcgraw74]

I haven't seen any Tek setting for changing the GPIB timeout.

I was thinking that if the serial output was blocking the Arduino from GPIB - that might cause the timeout.

Printing 72 characters (11-bits with 8-bits plus Stop/Start/Parity) at 9600 baud is 80msec.

The 4051 GPIB Hardware Supplement page 4-2 indicates: According to the IEEE Standard, each peripheral device on the bus must respond to ATN within 200nsec by setting NDAC low and NRFD either high or low (IEEE std page 93).  The 4051, however, allows a peripheral device up to 45 usec to respond.

The next page has this information on error message 69:

After 45 μs, the 4051 releases NRFD and checks to see if NRFD and NDAC are not both high.
If they are both high, the 4051 assumes that there is an error and the PRINT operation is
aborted. The 4051 prints a GPIB interface error message on the screen (message 69). If NDAC
is low and NRFD is low, the 4051 waits for NRFD to go high before continuing with the address
operation. If NDAC is low and NRFD is high, the 4051 assumes that all devices are ready to
receive the first peripheral address and the 4051 prepares to place the primary listen address
on the Data Bus.

[WaveyDipole]

I haven't seen any such setting either, but yes, print operations take time. I have been careful to print messages after an action has taken placed and not during it. Occasionally I have put messages inside loops for test purposes but I generally avoid that. It wouldn't take too much time to break it down so that debug messages can be shown on a per-function basis. I have already done that to some extent, but all GPIB secondary commands are at present lumped into one group.

Incidentally, I tend to run the serial port at 115,200 baud so delays might be reduced when compared to running at 9600 baud. I could try at 9600 and see whether it affects the 4051.

I have now updated the MARK command and it will hopefully work as described. If not please let me know and I will adjust it further. I had a lot of distractions yesterday so apologies if I have missed anything. I have uploaded the code to the repository.

[mmcgraw74]

Sorry, I am also using 115200 baud on serial debug.

I have only encountered one issue running the tape emulator with debug enabled - and this issue is not at random locations in the loop running INPUT commands - and happens on both my 4052 and 4054A running the 4050R12 Enhances Graphics demo files, trying to load the selection 1 picture of (SIN X)/X which is file 9 in folder "GrpR12demo".

The picture program is file 8, and the error occurs on line 575 INPUT @5:B$.
The Y value is 16 every time.
All I have to do is RUN 575 to get past this point and load the rest of the picture.

B$ is dimensioned to 5000 in line 130.

Each INPUT is CR terminated and I append the CR that Tek BASIC strips off back into B$ in line 576.

Using HxD to examine the file 9 SIN XX and searching for all the HEX 0D, the sixteenth CR is at offset 156A, and the string being INPUT is only 363 bytes long as the previous 0D is at offset 13FF.

The R12 Enhanced Graphics picture format is 3 7-bit characters for each 10-bit X/Y endpoint with one bit indicating MOVE or DRAW.  They have a CALL "IMAGES" command which only accesses the internal tape to read the entire file up to the EOF (FF).

In order to access the files on the tape emulator I figured out how to emulate that ROM call with the INPUT command, by reading the file until the CR terminates that input string, append the CR and concatenate all the strings.

Looking at the original demo tape files - I did not see an FF for end of file on many of the files, so I added a CR to the end of the data and manually counted how many strings were in each picture and put that count in DATA statements in line 555 and READ that data into R array for the 13 picture files.  I stop the INPUT loop when I have read all the data - which may be more than the true data size as the tape files are in multiples of 256 byte blocks.  I then crop the data to the proper file length stored in DATA statements 556 and 557.

I don't see any other tape emulator issue - than on this particular picture file.

I have uploaded my latest image - now named TapeEM-full-1.

The main menu works, along with SysTape, Games, Adventure, GraphingT1 - all of which should work on your 4051.  Since you don't have the MAXIPACK yet, you can't run the R12 demo - but you should be able to create a simple program with the loop attempting to read SIN XX and see if your 4051 passes. 

I still think this is an INPUT command timing issue.

I will download your latest code and try it.  If I have the same issues as before, I will disable debug prints and see if that eliminates the random issues.

[mmcgraw74]

I downloaded your latest image and tried the R12 demo.

SINX/X picture 1 had error 69 on line 757 at Y=16.

I did RUN 575 and now the program just hung (no error, but BUSY and I/O lamps on).

Double BREAK - line 575, Y=24.

RUN 575 - another hang, double-BREAK, line 575, Y=36.

I gave up and commented out the debug print in setup, and changed the version string to 44a.

Now 44a behaves like 42a - still stops at line 575 on SINX/X for Y=16.
But after RUN 575 - the picture loads, displays and the demo progresses through all 13 pictures and back to the main menu without any other issue.

[WaveyDipole]

I made no changes to anything other than the MARK command so I wouldn't expect it to have made any difference to running the graphics demo just yet. However, I have downloaded TapeEM-full-1 and have started to look at the problem you describe. At this point I have some more questions, though not all are related to the demo:

1. the MARK command

I did notice today that the MARK command is still not working as per description. I started MARK at the file immediately after file currently selected with FIND but re-reading your description it seems that it actually starts from and includes that currently selected file. I will need to make that adjustment.

Then, I also noticed this statement in your previous post:

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.

This statement seems to suggest that MARK, as already noted, starts at the currently selected file and creates the number of requested files, overwriting the current file and adding further files until the number of requested NEW files has been is created. It then appends a LAST file and everything after that numerically is deleted? I find that really odd as a) there is a potential to inadvertently loose the currently selected file and b) there is no means to create or clear one or more files on a tape without deleting everything that comes after the current file so one could inadvertently loose an awful lot of files! KILL only works with one file so it would seem that if someone wants to clear multiple files and reset them to new within a group of existing files they would have to use KILL multiple times?

I guess this is probably all related to the limitations of working with tape, but it does mean I will need to amend the MARK command again. Before I do though, I would like to just clarify that statement. Is my understanding above correct?

2. Filename format

I notice that in the new TapeEM-full-1 archive you are using actual file sizes so I did a bit of work to update the functions that rename and create new files to append the size of the file in bytes to the end of the file name rather than the record size. I have followed the specification here where the file length is exactly 39 characters:

https://github.com/mmcgraw74/Tektronix-4050-GPIB-Flash-Drive/blob/master/Tek-GPIB-Tape-Emulator%20command%20template.ino

As per specification, the file size field has six digits. By default, numbers are formatted as right justified and left padded with spaces which means the filename length will be slightly longer when compared with existing ones on TekSD/TapeEM, although the position of each field corresponds exactly with the existing file names and the specified format. I wanted to confirm whether the file size should be left or right justified? Right justified would yield filenames that are consistently 39 characters long. Otherwise the file name would vary in length depending on the number of digits in the file size, unless the file size field was padded with spaces. I had not observed and spaces at the end of the file names used so far.  I am uncertain as to what was envisaged?

3. The SINX/X picture file

I did have a bit of a look at the SINX/X picture file and program 8. I see they have been changed recently and the recent version is the one that corresponds with the discussion in your post. I can read a string with INPUT@5:A$ multiple times manually. I wrote a small program that read in a loop and did get it to run once all the way through but since then it seems to have consistently stuck at the 24th iteration which is a bit strange since in your experiment it consistently stuck on the 16th. So far I do not know the reason for this but will keep investigating.

This is the listing of the simple program that I used:

Code: [Select]

10 PRINT@5,9:"GrpR12demo"
11 FIND @5:9
13 LET B=0
15 FOR I=1 TO 124
20 INPUT @5:A$
22 PRINT I
25 IF A$ <> "" THEN 60
30 NEXT I
40 PRINT "Iterations: ", I
42 PRINT "Variables: ", B
50 END
60 B=B+1
70 GO TO 30
Please forgive the haphazard numbering!

[WaveyDipole]

I ran the program again this morning and to my surprise it ran all the way through to the end. I ran it a couple of times more to make sure and got the same result. Remembering your comments about having to turn debug messages off, it realised that since I was not connected to the emulator via serial, debug messages were effectively turned off. I then opened a terminal and connected to the emulator in via the serial port to observe the debug messages and ran the program and sure enough it stopped on iteration 24. I disconnected from the terminal and ran the program again and this time it ran all the way to the end. I also tried with debug messages turned off but with a terminal connected to the serial port. No messages were displayed and the program ran all the way to the end. The experiment seems to confirm your finding that turning on debug messages which adds the burden of the Arduino having to process numerous print actions can and does interfere with the process. Connecting to the serial port does not, of itself, appear to cause any problem.

The next question is, when you were testing the  SINX/X picture file using program 8, were debug messages turned on or off, and was a terminal connected to the serial port?

For my part, I will check whether there is any debug message in particular that is causing problems.