Tektronix 4050 GPIB Flash Drive - now available

[nikola-wan]

With lots of help on the software, my GPIB Flash Drive for Tektronix 4050 graphics computers is now available!!



4050 GPIB Flash Drive Features

1. Completely replaces 4050 internal tape drive for ALL program and data storage
2. Ready to run with 35 games and 33 R12/Fast Graphics pictures pre-installed on MicroSD card
3. MicroSD card provides Gigabytes of program data and storage
a. Plug MicroSD into USB-MicroSD adapter (not supplied) to transfer program & data files to/from your PC
4. Faster access and loading of all files than internal tape
5. Stores each ‘tape’ in separate folder – 100’s of tapes can be stored on same Flash Drive
6. Compatible with all Tektronix 4051, 4052, 4052A, 4054 and 4054A computers
7. Supports all 4050 BASIC GPIB tape commands:
a. FIND, MARK, KILL, OLD, BOLD, APPEND, PRINT, INPUT, READ, WRITE
8. Plugs into 4050 GPIB connector – no ROM backpack slots required
9. Flash Drive Micro-USB power cord included

I've just uploaded the User Guide, MicroSD files, and Arduino code to my github repository:

https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/tree/master/Flash_Drive

You can build it yourself or I can assemble it for you.

 

[nikola-wan]

I just finished recovering a tape labeled 4054 Option 30 Demo #2 and posting all the files on my github repo:

https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/tree/master/4054_Opt_30_Demo2

This tape is from the Jack Everson estate - a Tektronix sales engineer.

Option 30 is the Dynamic Graphics option board for the 4054.
Option 31 is the 'orange' screen option that enhances the Dynamic Graphics by coloring it orange.
Stored text and graphics will be green.

I need someone with this option to test these programs (Tom Stepleton, hint,hint).
Extract the zip file into the Flash Drive to create the 4054opt30demo folder and files.

PRINT@5,9:"4054opt30demo" // to CD to that folder
FIND @5:1
OLD @5: // loads the menu program file 1

here is the TLIST of programs in that folder:

 

[stepleton]

I see the bat signal persistently stored in the skies over Gotham. Will give this a shot Sunday evening!

 

[nikola-wan]

I didn't try loading these programs in my 4054. I think I would get an error on the ROPEN and VISIBILITY commands which are likely in Option 30 ROMs.

You will need to change line 88 in file 1:

from CALL "BAPPEND",5000
to CALL "BAPPEND",5;5000

the 5; will access the Flash Drive at GPIB primary address 5 instead of the internal tape drive to append the program to the main menu.

I updated the file 1 ASCII program and zip file with the change above.

 

[nikola-wan]

I found a new bug in the Flash Drive code.

CALL "BOLD",5 on a BINARY program on the flash drive does not complete when the program finishes loading.

I found this trying to manually load each of the Option 30 Demo binary programs into my 4054.

I started my iphone stopwatch when I ran each CALL "BOLD",5 and then hit BREAK twice on the 4054 after the number of seconds equal to the number of KB of program size.

Then I typed: LIST 30000,65000 which returned the last two lines of each of the Option 30 binary programs.

Then I would FIND the NEW file I had marked and typed SAVE@5: to save the program in ASCII.

I have uploaded a new "ASCII Programs" folder to the Opt30Demo folder on github.

I also found my previous filename for this folder was too long and changed it to "Opt30Demo" and uploaded a new zip which also contains the ASCII Programs folder.

My interest in the ASCII version of the programs is to see if I can create demo programs for all the rest of us that don't have the 4054 Option 30.

We should be able to find the Flash Drive issue with BOLD (and possibly BAPPEND) and fix it quickly.

 

[stepleton]

Dealing with some junk characters in File 1; still trying to run...

 

[stepleton]

It looks like line 81 also has to be changed to 81 FIND@5:P7 as well.

Well, it gets off to a magnificent start:



(Error shown at top is from before I modified Line 81 as described.)
Unfortunately the program hangs for me on line 88 after I select a menu item. I wonder if this is a Flash Drive problem?

 

[nikola-wan]

Great progress.
You mentioned having junk characters.

I just uploaded a new file 1 and new zip.

the "junk" in the original pgm lines 1620 and 1630 were CR characters at the beginning of the print string.
I replaced those with CTRL-underscore (US character for new line).

I have been 'porting the ASCII versions to remove OPT 30 statements.
File 5 is lots of fun!

You can load and run any of the files individually if the main menu is still not working.

FIND@5: 5
CALL "BOLD",5

The bug I posted this morning may be impacting your tests.

After typing CALL "BOLD" on any of these files - my 4054A continued to be busy.
I waited for 1 second for every 1KB of program file size - then pressed BREAK twice.

If you LIST 30000,65000 and find:

64554 CALL "BSAVE"
64560 OLD "DISCTOTAPE.CONT"

The program loaded completely and you can then run it.

This is likely the hang on line 88 with the BAPPEND command.

Just press BREAK twice and check that the file loaded completely.

 

[stepleton]

I will probably have to try this tomorrow --- thanks!

 

[WaveyDipole]

The binary BAPPEN (without the 'D' according to the Binary Program Loader cartridge manual) command has not been not tested on the flash drive. Looking at the description in the manual it seems that the command reads the whole file anyway, so I am guessing that it might be calling the same routine as BOLD and perhaps BASIC differentiates between clearing memory and loading the new file as a new program or injecting the contents of the file into a specific place within the currently loaded program. If that's the case, then the problem may be with BOLD. If, on the other hand, it uses a separate routine, then that will need to be implemented.

Thinking about it, I don't remember ever testing the ASCII version, namely the APPEND command. The OLD and APPEND commands also seem to call the same secondary GPIB address.

Whatever the case, I will do some tests to try and determine what is happening.

 

[WaveyDipole]

I did some tests on the 4051 and found that both APPEND and BAPPEN do appear to work. I ran into a couple of gotchas but once I understood what was happening, I was able to successfully use these commands. The first was that the line number at which to append the program, which needs to be specified as part of the command, must already exist in the currently loaded program. The second was that if a BOLD or BSAVE had been executed prior to BAPPEN, a FIND command needed to be called on the file to reset its pointer back to the beginning of the file. Provided both of these conditions were observed, both the ASCII and BINARY versions of the append command seemed to work.

With regards to the secondary GPIB address, in both cases it was as suspected. The APPEND command sends the GPIB secondary command for OLD and BAPPEN sends the secondary GPIB command for BOLD. In both cases, the routine simply returns the complete file.

The process I followed was this:

- create a NEW file
- load an ASCII program
- save it as a binary program in the new file
- clear memory with DELETE ALL and type in a new program with just two lines:

100 REM Test program
110 REM append here ...

I then used the call:
CALL "BAPPEN",5;110
or
CALL "BAPPEN",5;110,10

In both cases the program was appended at line 110. The original line 110 was overwritten. The BUSY light was extinguished and I could run the program.

I repeated the tests with CALL "BAPPEND" (with the 'D') and that was recognised and worked as well. I am wondering whether the point you made on FB about some terminator character might be the problem here? I am doing this on a 4051 so have no way of knowing whether the 4052 or 4054 are expecting something different. CALL "BAPPEN",5? was not recognized on the 4051.

I haven't tested any of this in the 4051 JavaScript emulator yet.

I also notice that in the case of the OLD command, the file is closed after the program is read. A FIND would be needed in order to re-open it. In the case of BOLD (and indeed SAVE and BSAVE), that isn't the case at present. I am wondering whether it should be?

Incidentally, while testing I turned on debug and I did notice an issue with the debug output which I have corrected so I will be positing an update.

 

[nikola-wan]

A short (couple of line BASIC program) test case will probably be the best test to get a logic analyzer trace if needed.

The BOLD and BAPPEN do appear to deliver the file to Tek BASIC. However, on my 4054A and 4052, these commands do not complete - and double-BREAK is required to return to BASIC and clear the BUSY condition.

I used that technique to load the original binary programs into memory, so I could SAVE them to a separate file in ASCII format to post on my repo.

I edited lines 81, 88, 96, 97, 1610 and 1620 in the attached zip file - to work with a 4052 or 4054 without Opt 30 AND 4054 with Opt 30.

****see 4054 Opt30 Demo1.zip below****

I created a new flash drive folder "No30Pgms", copied all the files in the ASCII Programs folder inside Option 30 folder to "No30Pgms", then extracted my edited file 1 from the zip to replace the original file 1.

Now you can PRI@5,9:"No30Pgms", FIND@5:1 and OLD@5:1 to run the edited Opt 30 menu program on a 4054 with or without Opt 30 or a 4052.
Select program 5 from the menu and the Pacific Coastline demo also runs.

The 4051 emulator will NOT run the programs in this folder - as it rejects all the 4054 and Option 30 BASIC commands.

So I edited ALL the files in the ASCII folder to remove all 4054 and Opt 30 commands and put them in the second zip file:

****4051Demo.zip***

John, you can extract these files into your 4051 flash drive, creating 4051Demo folder and run program 1 and select 5 to get to the Pacific Coastline demo. Of course you would need a joystick to do any zooming. I dragged all these files into the 4051 emulator after DelAll and it runs - of course we have no joystick support in the emulator.

 

[nikola-wan]

John, thanks for your testing.

Yes the 4051 emulator and your 4051 don't have the termination problem with CALL "BAPPEN" or CALL "BOLD" but both my 4052 and 4054A do not terminate until double-BREAK.

Tom reported his 4054A with Opt 30 hung running the menu program (when he selected a menu item I suspect).

So we still have an issue with the flash drive and different GPIB code in the 4052 and TI9914 with different GPIB code in the 4054A.

Tom should be able to select menu item 5 and double-BREAK after about 30 seconds - running the original files including BINARY programs. Then type RUN and he will be running the Pacific Coastline demo. This will duplicate what I have found on the binary programs on my 4052 and 4054A.

Tom could also run a folder of ASCII programs with the Option 30 demo - by replacing file 1 with the 4054 Opt30 Demo1 zip file which contains an edited file 1. Then he would have no issue running any of the demo files.

 

[WaveyDipole]

Thank you for the clarification. That is interesting. It sounds like the read loop is getting to the end of the file but the transmission is not terminating. There are two termination signals, namely an FF byte to signal the end of the file and an EOI to signal the end of the transmission. I will have to check the manuals to see whether there should be any other terminating character being sent to a 4052 or 4054. It may be worth doing a trace to check whether these are actually being sent and what is actually ocurring at the moment of the hang. I will also run a trace on my 4051 so that I have something to compare with.

 

[nikola-wan]

Unlike the ASCII format that has char 127 as the EOF, I don't think the BINARY program format has such a marker.

When I recover the binary program files, my program reads each 256-byte block and then encodes that data into pairs of ASCII HEX characters.
When I look at the dump file with Notepad++, it is clear that the initial file header block of 256 bytes is not HEX encoded and many times contains fragments of prior recordings.

After the last block of HEX encoded binary I typically see 1 more block which only contains a file header (same file number as the data file just read). The header includes file number and NEW with the number of blocks originally MARKed and is blank spaces for the remainder of the 256 byte block. Then I see the next file header, etc.

Maybe the 4924 external tape detected the EOF and sent it to Tek BASIC? I'll have another look at the 4924 service manual appendix.

 

[nikola-wan]

Looking at the 4924 Service Manual and 4051 GPIB HW Supplement I can see that OLD/APPEND and therefore BOLD/BAPPEN share the same secondary address 4.

I'll bet the 4052 and 4054 code expects the 4924 tape drive to assert EOI on the last data byte of the file to end the transfer of a BINARY PROGRAM file!

ASCII Program files have the character 127 written by the BASIC ROM to mark EOF, so no EOI needs to be asserted by the 'GPIB drive'.

page 1-7 in the 4924 service manual paragraph 2 indicates if the 4924 is sending data and the end of file has been reached it will send an EOI with the last "character" in the file:



Could you modify the current code to assert EOI on the last byte if the end-of-file has been reached on the OLD/APPEND command?
Likely this condition will only occur if the file type was BINARY, but it will likely also occur if the program file is incomplete - in which case BASIC will not receive the character 127 before the end-of-file is reached.



My 4924 tape drive is not working at the moment or I would try to capture what happens

 

[stepleton]

Could you modify the current code to assert EOI on the last byte if the end-of-file has been reached on the OLD/APPEND command?

I looked into trying this out myself, but it seems like this already happens in the code? Both in the handlers for BOLD and OLD; it seems like this behaviour has been implemented since last November.



I've had a try of the new 4054 Opt30 Demo1.zip and it revealed a different error upon selection of a program; unfortunately I didn't take notes and will have to investigate again later. I was able to run several of the programs by manually invoking (and then BREAKing) BOLD, and I took some short videos of a few of them:

There is a third video with the YouTube video ID p0U4IMsw578 . I am leaving it unlisted and unlinked because it includes a flickering visual element; if you might be adversely affected by viewing flashing images, then you may not want to watch it. Otherwise, substitute the video ID into an ordinary YouTube video URL.

It's very nice how Option 30 offers (among other things) a capabilty to have vector "sprites". The third video features a very complicated sprite, and because the sprite's redraw rate depends on the amount of drawing there is to do, certain sprites can synchronise very poorly with a video camera's frame rate. This is the source of the flicker in the third video.


ETA: You can also see that I still have yet to "calibrate" the display on this machine.

 

[nikola-wan]

I looked into trying this out myself, but it seems like this already happens in the code? Both in the handlers for BOLD and OLD; it seems like this behaviour has been implemented since last November.



I've had a try of the new 4054 Opt30 Demo1.zip and it revealed a different error upon selection of a program; unfortunately I didn't take notes and will have to investigate again later. I was able to run several of the programs by manually invoking (and then BREAKing) BOLD, and I took some short videos of a few of them:

There is a third video with the YouTube video ID p0U4IMsw578 . I am leaving it unlisted and unlinked because it includes a flickering visual element; if you might be adversely affected by viewing flashing images, then you may not want to watch it. Otherwise, substitute the video ID into an ordinary YouTube video URL.

It's very nice how Option 30 offers (among other things) a capabilty to have vector "sprites". The third video features a very complicated sprite, and because the sprite's redraw rate depends on the amount of drawing there is to do, certain sprites can synchronise very poorly with a video camera's frame rate. This is the source of the flicker in the third video.


ETA: You can also see that I still have yet to "calibrate" the display on this machine.

Tom,

I love the videos!

Tek Logo goes so fast I can barely make out the "orange logo" being drawn before it is stored in green.
Looking at the code - I think it is stopping at line 13380 with the error "MISSING LINE NUMBER IN LINE 11380" or 11390?

Those lines in each of the programs from 2 to higher appear to somehow delete all the lines of the appended program, then find the next program on the 4907, mark that file number on the internal tape, append the program from the 4907 and CALL "BSAVE" that program to the internal tape.

As though they are creating a demo 1 tape from 4907 files.

I believe I should delete those lines in those programs, as the flash drive users can unzip one file to create the 4054 Option 30 folder whenever they want. Then they would need instructions to add that folder to the main menu in ROOT.

The Helicopter Simulation video clearly shows the "orange" refresh vectors of the rotating main blades and tail rotor with the "green" stored vectors of the helicopter body!

I used GIMP to brighten the helicopter body and PAINT to crop the uncleared left side of the screen.





I think you should publish the Green Eye video - with the flashing disclaimer.

It clearly shows the "orange" refresh graphics on top of background stored graphics, and the 'older' refreshed graphics show as green - too many refreshed vectors of that size to show entire "eye" as orange.




I think I will start a separate thread on the 4054 with Option 30 - these graphics are amazing!

Back to the Flash Drive issue - I guess if the Flash Drive code is already asserting the EOI on the last byte of the file - it is being ignored by TEK BASIC

I don't see the 4924 manual mentioning BOLD or BAPPEN commands, so I guess I need to get my 4924 working again to see if they ever worked correctly and terminated after the file loaded completely.

Since I believe my capture program got ALL the data on the tape - I don't think we are missing anything that would have been written to the internal tape by TEK BASIC.

We do have 4051 ROM source code microfiche posted on bitsavers.org - that could be searched to see if we can find how the ROM would exit properly at the end of a CALL "BOLD" or CALL "BAPPEN" command - which it does on John's 4051 and his flash drive mods to the 4051 emulator.

http://www.bitsavers.org/pdf/tektronix/405x/fiche/4051_Firmware/

 

[nikola-wan]

Actually, I scanned the 4051 ROM microfiches and realized CALL "BOLD" and CALL "BAPPEN" are in the 4051 BINARY Program ROM Pack.
I have one of these and uploaded the ROM bin files to my repo.

Using f9dasm.exe in a cygwin terminal session, I disassembled the 4KB binary for a 6800 at offset 8800 which is the Bank Switch ROM starting address in the 4051.

I've attached the output listing file in this zip.

4051 ROM Packs have a two byte ID at the beginning of the ROM: "4051"
Each ROM CALL is listed at the beginning with the ASCII name in six bytes with space padding at the end for names shorter than six bytes.
The following two bytes is the entry point in the ROM Pack:

• BSAVE starts at 883E
• BOLD starts at 8952
• BAPPEN starts at 8E00
• LINK starts at 8BA8

I also see an "EMSAV" at 9052 and "EMGET" at 910A - but neither of these CALLs is documented in the 4051 Binary Program Loader operators manual posted on bitsavers.org.

It's been decades since I have tried to follow 6800 assembly code, but I'll see if I can make sense of this listing for BOLD.
Or I can try to fix my 4924 and see if these commands work with a 4052 or 4054 which embedded these two CALLs in the BASIC ROM.

 

[WaveyDipole]

Looking at the 4924 Service Manual and 4051 GPIB HW Supplement I can see that OLD/APPEND and therefore BOLD/BAPPEN share the same secondary address 4.

I was rather surprised by this statement and let me explain why. The OLD and APPEND commands do share the same secondary address, as do BOLD and BAPPEN, but whereas OLD and APPEND do share address 4, BOLD, BSAVE and BAPPEN calls all send secondary address hex 71, or decimal 113. With the offset removed, this translates to decimal 17. This is easily verified by decoding traces or enabling the appropriate debug output on the flash drive. Although in either case one is essentially reading bytes from a storage medium, files in binary format need to be handled somewhat differently to ASCII files. For example, CR and LF have no meaning in binary mode and there is no need to stop the transmission on a CR, only when the buffer is full. It therefore seems odd that a binary command would call an ASCII handler? Whereas it is possible to tie a listener and talker pair of functions to a single GPIB secondary address, trying to tie in multiple talker or multiple listener functions to a single address would require an additional parameter of some sort to select the function. In theory its possible, but command syntax does indicate that anything like this has been implemented. I would be interested to see this information.

I captured a trace of the BAPPEN call in operation on my 4051. The function does send an EOI with the last character and the trace does confirm that.

One thought that occurs to me is to leave out the final FF. This is easy enough to do. Just located lines 527 and 528 in AR488_Store_Tek_4924.cpp which look like this:

err = gpibBus.writeByte(c, DATA_CONTINUE); err = gpibBus.writeByte(0xFF, DATA_COMPLETE);

Comment out line 528 and change line 527 to look like this:

err = gpibBus.writeByte(c, DATA_COMPLETE); // err = gpibBus.writeByte(0xFF, DATA_COMPLETE);

This does work on the 4051, but generates an error:

MAG TAPE ERROR IN IMMEDIATE LINE - MESSAGE NUMBER 55

I believe this is the same error that was reported on the 4054 with the current code? However, the file does get appended and the program can be run. Re-instating the original lines gets rid of the error.

I would be interested to know whether the above mod has any effect on the 4052 or 4054? Does it perhaps not like the FF on the end of the transmission?

Page B-2 of the Binary Program Loader's Operator's Manual gives the meaning of error message number 55. The first item about the tape head can be dismissed although if the file pointer is not at the begging of the file for some reason (e.g. a FIND is required) then this is going to produce the same result. The remainder focuses on the wrong type of file being used (ASCII vs BINARY). This suggests that the routine does somehow differentiates between ASCII and BINARY files. I did wonder whether those apparently superfluous bits at the end of the binary files (essentially repetitions of file headers and spaces) in the original Opt30Demo directory might be having an effect. I edited one of them in a hex editor to remove that section and tried loading the before and after version using BOLD on the 4051. Both versions completed loading without the 4051 complaining which tells me nothing really. Obviously I could not run or do anything with the result on my 4051, but a LIST did not produce a coherent listing. The screen displayed fragments of program code, gaps and random characters and finally rebooted showing the Maxirom startup message.

Monty I then tried you modified demo for the 4051 with option 5 as suggested and this produced a menu and the pacific coastline (see pics).

BTW, Tom, I initially thought that the helicopter simulation had a sound effect then I realised that's just the droning of the fan on the 4054!