• Please review our updated Terms and Rules here

Tektronix 4050 GPIB Flash Drive - now available

WaveyDipole said:
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.
Click to expand...
I updated my Flash Drive and tried it successfully on both my 4052 and 4054A!

I did not use your BSAVE-output.zip file.

On both my computers I BOLDed the 3-line test file I've been using, then BSAVEd it to a different file number.
Then BOLDed the new file number and listed all three lines as expected.
Then BAPPENded the new file number on line 1000 and got the five lines expected.

I also ran PICTURE menu on both computers and the Binary READs worked fine.

Then I changed to OPT30DEMO directory and BOLDed BINARY pgm 5 (Pacific Coastline) which is from my tape capture.

No hangs, no error messages.

I just posted this version on my repo.
 
Thanks for the tests. Glad they worked Ok.

Since a CLOSE causes the FF to be added to the end of the data in the file, I was wondering whether to move the code that adds the FF and padding of the last block to 256-bytes from BSAVE to the close function? That way, both binary and text files will be taken care of when the Tek calls CLOSE. The function may also need to determine whether we are working with a binary or text program file (from the file type letter?) and add that last CR to ASCII program files. I don’t know whether any of this is relevant to data files?
 
I think the definitive answer is in the 070-2056-01 4050 BASIC Reference pages 7-30 and 7-31 on the CLOSE statement.

Data destined for tape (internal or external) will sit in a 256 byte buffer in the 4050 until that buffer is full - then it will be written to tape.

The CLOSE statement will flush the buffer to tape regardless of how many bytes are waiting in the buffer.

I do see on some of my recovered tape "dumps" ASCII data files with an FF byte at the end of the data, followed by the data written to that block and subsequent blocks with the MARK operation.

I think putting the CLOSE in programs that are done sending data to tape is good practice, and if not followed results in corrupt data files :(

I see in the last paragraph of the CLOSE statement that FIND or END statement issued without a CLOSE to an open tape file causes the 4050 to flush the tape buffer to tape first, followed by doing the FIND.

I believe you said that with the Flash Drive, each byte written is sent to the MicroSD card - not put in a buffer, so the Flash Drive is 'safer' in that regard if the program does not include CLOSE commands.

I think your idea of moving the FF and padding code to the CLOSE command would require a lot of testing, although it appears up to now - that the programs I've written like Adventure with dozens of ASCII data files are ok with the Flash Drive - I see that my Adventure data creation programs that I wrote for the 4907 floppy drive system had CLOSE commands too.

1656503253919.png
 
Last edited:
I understand the necessity of buffering when writing to tape because the tape drive writes in 256-byte blocks. As described in the pages above, this leaves the problem of the data in the last buffer load to deal with. The flash drive does a byte-by-byte read from the GPIB bus and writes each byte immediately to the file. There is no buffering. This is probably less efficient, but still much faster writing to tape and does not require dynamic memory to be allocated to a buffer. Since data is written to the file byte-by-byte, the problem of the last bytes left in the buffer does not arise.

Of course, it is still good practice to close a file after the program has finished processing it.

As per the 4924, a FIND command on the flash drive will also close the current file.

As we have seen, the 4054 and 4052 seem to automatically send a CLOSE after certain operations so I share your concern about adding anything to the close function and the amount of testing that might require. If the 4054 and 4052 send a CLOSE after a SAVE just the same as the do after a BSAVE then I can modify the code in the ASCII SAVE function in a similar way to what was done with BSAVE to make sure the file is properly terminated with CR and FF and that modification would affect the SAVE function only. On the other hand, if things are working with the code as it stands, then maybe it could also be left as it is. I am happy to go with either option.
 
Last edited:
I just uploaded my July 2022 update of the file image FlashDrive.zip and User Guide.

I moved the previous June 2022 FlashDrive.zip file and June User Guide to a new Archive directory

New Features in this release:
  • RTC AUTO LOAD of your Favorite Directory
  • New Main Menu that includes First Time Setup to discover your 4050 including six different Options
  1. 4050 Model
  2. Memory size
  3. R05 BINARY PROGRAM LOADER ROM PACK
  4. R12 Graphics Enhancement ROM PACK
  5. Option 30 Dynamic Graphics
  6. 4052 Diagnostic ROM Pack
  • Main Menu now uses your 4050 configuration to disable menu items that are incompatible.
  • This allows the same Flash Drive zip image to be used by all 4050 computers instead of requiring separate images for each combination
I have attached a couple of screenshots running the new Flash Drive Main Menu and First Time Setup.

This allows all the Flash Drives to use the same FlashDrive.zip image and the Main Menu will put / characters on top of selections that are not compatible with your 4050 computer due to option requirements indicated for that item in parentheses.4050 GPIB Flash Drive - Main Menu 4052 dark.jpegFirst Time Setup Discovery Complete 4052 dark.jpeg

I also shipped my first assembled Flash Drive order!

Post in this thread your interest in an assembled Flash Drive and I will PM you.
 
Thanks for this update! I'm looking forward to seeing the new features that are available.

Would it be possible for the program to ask first before it changes any information in the RTC ROM pack? I may have had a power-on program of my own --- in real life I didn't, but if I did have one, it would be gone now.

I actually do prefer my machine to start up at the BASIC prompt, so I had to CALL "!SETPU" to delete a startup program that I would have chosen not to install if given the option.

I'll detail my experiences more extensively later. For now, thanks for all of the new stuff!
 
Tom,

That's an interesting feature request.

You can REM lines 4110 and 4120 in the ROOT file 1 Main Menu program and the RTC Auto Load will not be installed in the RTC.
You would need to make these changes before you plug the Flash Drive into the 4050 and power on - this will eliminate any changes to the RTC RAM.

If you have already run the Flash Drive and First Time Setup, you can clear the RTC power-up program with a single command:

CALL "!SETPU"

I'll be interested in hearing more of your feedback on this release.

I added my R12 version of ICE RACES and my mods to Invader I to use refresh graphics to display the Invader ship - I would love to see a video of both to compare to your video of Option 30 ICE RACES :)
 
nikola-wan said:
I added my R12 version of ICE RACES and my mods to Invader I to use refresh graphics to display the Invader ship - I would love to see a video of both to compare to your video of Option 30 ICE RACES :)
Click to expand...
I did give Ice Races (R12 edition) a try earlier, but haven't filmed it yet. Sadly, the 4054A here appears to be playing up again, with a tendency to hang now and then, so it'll be time to open the case again soon and figure out what the matter is. I am hoping for (and suspecting) that resocketing some of the socketed chips will help. The 4054A here does not really care for warm weather like what we're having now.

This reminds me that I really do need to get around to dumping those Option 30 ROMs. I'll have to lift the sticker off of them to determine what kind of EPROM they are so that I can set up the programmer accordingly --- do you have any guesses as to what they might be? Did Tek use only EPROMs of a certain type in 4054As?

Anyway, the new implementation is an impressive recreation given the resources available. The cars do blink a lot, and they move more slowly than they would in the Option 30 original. Even on the 4054A, I'd prefer to use the variant with the simple triangle-vs-rectangle graphics just for the sake of speed. But it's all still fun to play, and that's what counts. I might recommend that the rectangle car have a different shape, since right now it's impossible to tell which end is the front just by looking. Maybe give it a bit of a taper?

Once I get the computer working more dependably again, or perhaps once it gets cooler, I'll try to make a recording.
 
Interesting, thanks for the tip on the ROMs. I'll try to peel a label soon and have a look to see what I've got.

I don't see support for this chip by the good old TL866II+, but the Retro Chip Tester Pro lists it, albeit as "untested". What would you use to dump these PROMs?

(Also, I thought that the 4054A had switched from PROMs to EPROMs? Not sure where I read that, though.)
 
Here's what I did in 2000 to download my 4054A ROMs. I was using a Data I/O 29 with Unipak2B which supported the 28S86 PROM.

The Option 30 was introduced in 1979 with the 4054 and had bipolar PROMs for the ALU and ROMs with patch ROMs for the MAS board. The A-series introduced in 1982 changed the MAS board to EPROMs, eliminated the patch ROMs, but only supplied new PROMS for the ALU board to add new microcode.

The ALU is a bipolar bit-slice AMD2901 design and runs at much higher speed than the system ROMs. That's why I think the Option 30 with the bipolar X300 may use the same PROMs.

I checked the box this morning that had the 4054 to 4054A upgrade kit I bought off EBAY in 2006 and it still had the microcode PROMs I removed from the ALU - that's where I got the PROM part number.
 
Thanks very much for the information! I took a deep breath and decided to go for it with the Retro Chip Tester Pro. If it worked correctly, then attached are the contents of the six Option 30 ROMs, which were 28S86s exactly as you expected. The explanation for why such devices might be necessary is interesting.

I cannot easily say for now whether they contain valid 8X300 code. Some more poking around with this disassembler might illuminate things.
 

Attachments

  • Opt30ROMs.zip
    4.4 KB · Views: 7
Wikipedia article on the 8x300 indicated the instructions are 16-bit, so the data in the six PROMs are in pairs - similar to what they did on the MAS EPROMs to get 16-bit to the ALU for each instruction fetch. Can you tell if that disassembler assumes the files to pass in are 8-bit or 16.bit. I think you may need to shuffle the three pairs (U375 and U385, etc) into one file to provide the 16-bit binary image to the disassembler. I did that for the 4052 and 4054 in order to examine the BASIC ROM code with HxD.
 
Oh yes, the disassembler and I are already some ways down that road :) Notice from the README that the disassembler requires you to call it with two arguments: the first is the high-byte ROM file, the second is the low-byte ROM file.

When I wrote yesterday, I had experimented with a few different orderings of the six ROM files, but not many of them. As usual, it was well past time to go to bed on a work night. The few ROM file arrangements I tried all had some signs of potentially being an incorrect permutation, such as JMPs to locations outside of the ROM. (I'm not sure why the Option 30 board would need to have any code in RAM...)

As I don't have an address map for the Option 30 board, I don't know how dependable my "correct ordering" heuristics are, so I think what I'll do instead is just try to beep out the connections between the ROMs and the 8X300 and see if I can determine the correct file ordering that way.

But there's also a chance that my ROM dumps are bad. Either way, I'll keep you posted on developments.
 
I did some investigatory probing.

Confusingly, only four of the six PROMs are connected to the 8X300. The two others send their data lines to a latch elsewhere on the board and seem like they must be used for something else. In some way this is a relief: the contents of those two PROMs are strange, with contents like these typical:

Code: 
00000000: 0922 2200 2222 2243 0022 2222 2222 2222  .""."""C."""""""
00000010: 2222 2200 2222 223a 6214 6215 34f5 2222  """.""":b.b.4.""
00000020: e222 22e2 2222 e222 2222 2222 1415 2222  ."".""."""""..""
00000030: 2222 22e2 2222 e222 223c 6216 6217 36f7  """."".""<b.b.6.
00000040: 2222 e222 22e2 2222 e222 2222 2222 2222  ""."".""."""""""
00000050: 2209 2222 0022 2222 1cfc 2222 e222 22e2  ".""."""..""."".
00000060: 2222 e222 22e2 2222 e222 2222 2222 2222  ""."".""."""""""
00000070: 2222 3839 e21c 3c22 3839 2218 2222 3a18  ""89..<"89"."":.
00000080: d922 22e2 2222 e222 22e2 2222 e222 22e2  ."".""."".""."".

It reminds me of some kind of lookup table or of using a ROM as a replacement for combinational logic.

The four PROMs connected to the processor are U385 and U475 (connected to processor data lines I8-I15) and U375 and U495 (connected to processor data lines I0-I7). I think Signetics counts bits backwards, so the first two are the least significant byte and the last two are the most significant byte. The physical layout of the chips is puzzling, and it suggests to me that Tek was leaning on the autorouter to help out with the layout (the right-angle traces are another clue, of course).

Looking at some arrangements of the ROM data, the layout that makes the most sense to me is this:

Code: 
 MS8   LS8
-----+-----
U495   U385, followed by
U375   U475

This arrangement has the most JMP instructions followed by locations that are the targets of other JMP instructions, like this:

Code: 
        jmp     x0219
x022b:  xmit    0h,dliv

where x022b: is a generic label generated by the disassembler. The reason I think this is a good sign is because (as I understand it) the 8X300 has no stack and no instructions for call/return, so if you wanted to run something like a "subroutine" and then jump back to the caller, you'd need to be able to get to the instruction after the JMP.

There are other recognisable patterns like this jump table making use of the odd XEC instruction:

Code: 
x0050:  xec     x0051,r11
x0051:  nop     
        jmp     x070d
        jmp     x0728

My reason for putting U495,U385 in front of U375,U475 is because the second pair of ROMs has an empty bit at the end; I assume it's extra space that wasn't needed.
 
Finally, as a separate question: do you know how to interpret the four diagnostic/status LEDs on one of the "main" logic boards, or do you know of any materials that describe this?

Today I'm afraid the 4054A would not power on successfully at all. I'm used to seeing all four LEDs seem illuminated (mostly --- you feel that some might be blinking rapidly), but today a few remained off.

It remains hot in London, and I think the 4054A is not pleased about it.
 
Check out my post:
https://forum.vcfed.org/index.php?threads/tek-405x-web-browser-emulator.62548/post-1217981

it has a link to the 4052/4054 System Test Fixture (I have one - untested) Instruction Manual and pictures of the front panel LEDs and what the combinations mean if the system locks up.

That same manual I posted includes description of the LEDs on the 4052/4054 ALU, MCP and MAS system boards that should also help (pdf pages 10-15), including a flow-chart of the microcode self-test (and source code listing for the microcode).
 
Last edited:
Thanks, this is an excellent resource and exactly what I was looking for. One of these days we're going to have to find a more durable repository for wisdom than posts on long vcfed threads, I hope!

In any case, I think we're back in action now. One important troubleshooting rule is: if you've messed with something and you have a problem, concentrate your attention in the area of the thing that you just messed with. That was the Option 30 board and its PROMs, and I think that when taking them out and then putting them back, I may have introduced some board flex that displaced the nearby 8X300 just slightly enough that some pins weren't making good contact within the socket. Squishing the 8X300 back into the socket seems to have brought us back in business. I think it will be useful sometime to pull the chip altogether and treat the socket with some contact cleaner, but this is a delicate operation for such a wide, thin ceramic chip.

Another clue was the fact that none of the LED/front panel light patterns matched the description in the System Test Fixture documentation --- which suggested to me that the problem may have something to do with how my system is different (i.e. Option 30).
 
Great news! The Option 30 support for BASIC was apparently added to the v1.5 BASIC ROMs which are common between 4054 and 4052, same goes for the 4054A v 1.5 ROMs. Both my 4054A and 4052 could load and tolerate the Option 30 Demo program CALLs without printing CALL NAME INVALID error 32 messages.

So the PROMs on the Option 30 board are just for the 8x300 to process the vectors into Option 30 format and refresh them when the VISIBILITY commands are executed by the BASIC program.
 
nikola-wan said:
So the PROMs on the Option 30 board are just for the 8x300 to process the vectors into Option 30 format and refresh them when the VISIBILITY commands are executed by the BASIC program.
Click to expand...

This seems sensible to me. Do you have your own hypotheses about what the strange U395 and U485 PROMs (the ones filled with a lot of 0x22 bytes) might be for?

Now that we're back in business, I can continue to report experiences with the Flash Drive. While most of these are criticisms and bug reports, I hope it's clear that I deeply appreciate the effort that has gone into making the whole package, and that I submit these remarks for you to use at your discretion and in the hopes that the bundle will become even more excellent.

I am working the FlashDrive.zip file that's currently on GitHub, dated 10 June 2022. Notes:
  1. Feature request (mentioned earlier): ask before modifying TransEra RTC power-up commands
  2. "1. Game menu" seems to work well. R12 Invader is a fun game; I didn't try all games.
  3. On my machine, "2. Picture Menu (R12)" brings up the "4054 Option 30 Games" menu instead.
    1. But once it's loaded, attempting to load a game yields MAG TAPE ERROR - MESSAGE NUMBER 55
  4. "11. Option30 Demo (Option 30)" does not seem to load; after printing "Option30 Demo (Option 30) is loading..." we see NO PROGRAM FOUND - MESSAGE NUMBER 59.
    1. Running input@5,9:a$ reveals the current Flash Drive directory to be /No30Demo/, which doesn't seem to exist in FlashDrive.zip
  5. Manually entering the /Opt30Demo/ directory and running the menu program: if you choose a menu item, that option shows, but then all of the menu options that follow play automatically (you don't go back to the menu)
    1. Also, the "For information, call (301)..." info boxes within the demos seem to be misformatted.
  6. "13. SVG>FG (R12)" pulls up what looks like the old "4050 Tape Emulator Menu" from the version of the Flash Drive software that I found on the zip file from April.
    1. Nevertheless, input@5,9:a$ shows that the current FlashDrive directory really is /SVG2FG/. It just looks like the first file on the tape in this directory really is the old menu code.
    2. The old menu code still has the bug where TLIST doesn't work; it just repeats the first directory item :)
  7. Feature request: It would be nice to have a menu option for Opt30Games.
  8. Feature request: Have the root menu define some useful navigation functions for the User Definable Keys, so if the user quits the root menu, they can explore the flash drive on their own and also avoid some repetitive typing. Some ideas:
    1. UD Key 1: TLIST the current directory
    2. UD Key 2: Print the current directory name
    3. UD Key 3: List all possible directories
    4. UD Key 20 (so hard to bump by accident): FIND@5:1 followed by OLD@5: followed by RUN
I hope this is useful! As a bit of happier news, I've recorded the R12 versions of ICE RACES per your request, but I'll wait until tomorrow to upload them to YouTube as it's now quite late. Till then...
 
You must log in or register to reply here.
Back
Top