Tektronix 4050 GPIB Flash Drive - now available

[nikola-wan]

Excellent work! I agree that secondary address 17 supports CALL "BOLD" and "BSAVE" on the 4924 - because I just got it to work on my 4924.

Note the three line program loaded by CALL "BOLD",4 - terminated without BREAK and the three lines I saved are in the file.

The CALL "BAPPEN",4,17;1000 should append those three lines at line 1000 and renumber the lines - which is what happened - hooray!

First photo below shows 4924 successful commands, including BAPPEN properly appending the file to the program in memory

Second photo on 4054A with flash drive photo showing these commands using the Flash Drive and a NEW file 40 in ROOT.

CALL "BSAVE",4 hung - I pressed BREAK twice. Then I examined the header on file 40 and it showed a binary program.
CALL "BOLD",4 hung, but after double BREAK the 3 line program was in memory.
CALL "BAPPEN",4 on that same file hung, but after double break only the 3-line program was in memory

See 4054A photo 2 and 3 shows what happened trying those commands on the Flash Drive.

This is with your last Flash Drive code drop in early May. I tried patching those two lines of code - no difference in the result on the 4054A.

I did a logic analyzer capture of 4924 BOLD and BAPPEN - although the file number was 3 for that capture.
When I went back to take photos - file 3 was not working, so I remarked and used file 4 for the photos.

Last two pictures are the end of the 4924 BOLD and BAPPEN traces. I think what happens here is the key.
In both cases the data had been transferred and there was about 20msec of dead time.

I'm working to get the trace files into excel spreadsheets.

 

[nikola-wan]

Here is the decoded logic analyzer trace for BOLD.
I think row 1279 to the end matches the BOLD picture.

I see controller issuing a CLOSE followed by the 4924 issuing an EOI and then controller issuing UNTALK and UNLISTEN and thats the end of the trace. I had to stop the capture so I know there was no more transitions on GPIB.

There is a weird 36 decimal issued by the controller before the CLOSE.

The picture of the end of the BAPPEN trace closely matches the BOLD picture.

 

[stepleton]

Unfortunately I don't have time to pitch into the logic debugging this evening, but I thought it would be good to retake the videos, since...

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!

...that's not right! In real life, the entire helicopter is drawn with refresh graphics.

As we all know, refresh graphics are not stored on the tube and so are constantly being redrawn, and that means that if your recording frame rate isn't synchronised with the redraw, things don't look quite right. It's similar to shooting a video of a CRT raster display if you haven't got the camera synchronised with the raster: some parts of the screen will seem dark, or there will be flickering, or you'll see some other kind of distortion.

The green you're seeing in the video is only on the screen temporarily --- you basically never see it with your own eyes. But the unsynchronsied camera can capture those instants by accident.

Unfortunately, unlike a raster display, I think the refresh rate for refresh graphics varies. If you have a complicated graphic (e.g. the connected polygon graph in the GREEN EYE demo), then I think it takes a comparatively long time for each refresh of the vector "sprite" on the display. The helicopter graphics would therefore have a faster "frame rate" than the GREEN EYE graph, since they are much simpler. (I haven't yet conclusively verified that this is what's really happening, though.)

My camera does allow you to select the recording frame rate precisely, but while this does allow you to capture a CRT raster quite well, it's harder to dial in the correct frame rate if it can vary based on what's on the screen!

Anyway, here is my second recording of the helicopter demo, with a different recording frame rate. It's a little closer to what you see in real life.

Oh, and: only confusing matters, if you watch it at low resolutions like 480P, it appears to make things look much greener than they should!

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

I don't like to mess around with flickering graphics. Here's a second, published recording at a different frame rate which seems like it may be safer, but even so: viewers with any photosensitivity may want to avoid this video. I may replace it with another if I can better reproduce the experience of seeing the demo in real life: the flicker in person is far less noticeable.

As with the previous video, different resolutions will yield different viewing experiences.

 

[WaveyDipole]

Here is the decoded logic analyzer trace for BOLD.
I think row 1279 to the end matches the BOLD picture.

I see controller issuing a CLOSE followed by the 4924 issuing an EOI and then controller issuing UNTALK and UNLISTEN and thats the end of the trace. I had to stop the capture so I know there was no more transitions on GPIB.

There is a weird 36 decimal issued by the controller before the CLOSE.

The picture of the end of the BAPPEN trace closely matches the BOLD picture.

Thank you for the detailed trace of the 4924 operation. I see the CLOSE command after the binary program read operation is completed. I notice that there is no EOI at the end of the data being sent? The EOI only comes after CLOSE.

The 36 decimal is hex 24 which is LISTEN 4 which would make sense for the CLOSE command. Prior to this we see UNLISTEN and UNTALK, so the controller has to address the 4924 to listen again.

Looking at the format of the binary program files, I see that each one starts with 40FD, then there are a couple of null bytes and then a series of bytes before a 20 (space) and then the file description starts. I wonder whether that sequence of bytes includes some kind of checksum so the Tek would know how much data to expect and therefore does not need an EOI to terminate the transmission?

I did a quick experiment and removed the EOI but this also failed, so there is more to it I suspect.

I don't have much time today, but will have another look at this later on.

 

[nikola-wan]

I checked the Tek_4924.cpp file for EOI - it looks like we only have code that sends EOI, where the BAPPEN shows the controller is sending the EOI after the CLOSE command to the 4924?

 

[WaveyDipole]

Monty, sorry I am unsure that I follow your last comment. Its probably me (it usually is) and this hot weather that we are having! Whatever the case, I had a look another at the code that could be called when a call to BAPPEN is made. This is how it should work:

- BAPPEN calls secondary address 17 [hex 71 including offset]
- the flash drive executes the function tied to address 71 checking whether the flash drive has been called to listen or talk
- if addressed to talk, binaryRead() is called to read the file and send the data to GPIB
- data is sent until the end of file, then terminated by an FF byte together with an EOI signal
- binaryRead() exits
- talk function 71 exits

On the other hand, in the case of OLD/APPEND where secondary address 4 [hex 64 including offset] is called, the function performs an ASCII read, terminates by sending EOI on the last byte, and then does call CLOSE to close the file on the SD Card.

The close function does not send anything. It just closes the file on the SD Card. There is no requirement to send EOI and none is sent.

From what I can see in the trace output, it is the controller that calls CLOSE after BAPPEN

Both functions have a check for the correct file type, but what I did notice is that whereas the OLD function has a fail-safe in the event that the file type is incorrect, BOLD does not. If the file type is incorrect you still have to send something. The flash drive has been addressed to LISTEN and the Tek is expecting some kind of reply. In the case of OLD we just send FF with an EOI, i.e. essentially a NULL response, but a response nonetheless. The Tek then returns a MAG TAPE ERROR 55. Otherwise in the absence of a response, the Tek would just hang and require a double-break to get back to the system prompt.

The same fail-safe code has not been added to the BOLD routine and an update, which includes the previously mentioned debug fix, has been pushed to the repository. I have also changed the names of the DATA_CONTINUE and DATA_COMPLETE flags to SEND_DATA_ONLY and SEND_WITH_EOI which should hopefully clarify their purpose and make it easier to follow the code. Please note that where SEND_WITH_EOI is used in connection with a function that operates on a buffer, the EOI is sent on the last byte in the buffer only.

I would be surprised if either of these corrections make a difference with regards to this particular problem though. I checked the format of the filenames in 4054_Opt_30_Demo2 and they seem spot on so there should have been no reason for the routine to branch to the error condition (lines 1636- 1640) and hang for that reason.

 

[nikola-wan]

There is another issue with the 4054A BAPPEN on the Flash Drive - that has been detected on both my system and Tom's.

CALL "BAPPEN" on the 4054A from the Flash Drive does not append, it appears to be the same as CALL "BOLD" and deletes the previous program.

CALL "BAPPEN" works properly on the 4924 with my 4054A.

Here is my test program (so the whole trace is captured by the Logic Analyzer):

100 REM Line 1
110 REM Line 2
1000 REM Line 3

On the 4924 (configured as GPIB primary address 4), if I find and CALL "BSAVE",4 this program on tape, and then find that tape file again and CALL "BAPPEN",4;1000 I get this resulting program LIST:

100 REM Line 1
110 REM Line 2
1000 REM Line 1
1010 REM Line 2
1020 REM Line 3

When I repeat this same test on my 4054A with the program CALL "BSAVE",5 to the Flash Drive, a CALL"BOLD",5 leaves the program in memory after I press BREAK twice, but then FIND@5:41 followed by CALL "BAPPEN",5;1000 overwrites the entire program as though it is a CALL"BOLD" (after I press BREAK key twice to stop the BAPPEN).

I even deleted line 110 and did a CALL "BAPPEN",5;1000 and all three lines 100, 110 and 1000 are there, but no APPEND has occurred.

I know the Flash Drive has nothing different to do for BAPPEN versus BOLD - but this is really puzzling.

I will capture more logic analyzer traces of the 4924 versus 4054 CALL "BSAVE" / BOLD / BAPPEN later today to see if we see any differences.

 

[nikola-wan]

Tom, I uploaded more Option 30 programs to github for you to test!
https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/tree/master/4054_Opt30_GAMES

I have not been able to recover all the files on this tape.
I fixed the file 1 Menu using code from the Option 30 Demo file 1 Menu.

Lunar Lander file 2 and UFO file 5 were not recovered and Star Wars file 2 and data file 3 were only partially recovered
I left all the programs in ASCII while we are debugging BINARY program loading.

Here is the Option 30 Games Menu on my 4054A.

The Option 30 Dynamic Graphics board only has ROMs for the 8X300 microprocessor.

I think that is why my 4054A and 4052 don't barf on running programs with the Option 30 CALLs.

My next step on the games is to try to convert the Option 30 CALLs into R12 refresh graphics to see if I can get it to run on all the other 4050 computers

 

[stepleton]

Oh boy! I'll try those out at some point soon

PS: Has anyone ever backed up those Option 30 ROMs? They're quite easy to access in the 4054A...

 

[nikola-wan]

I don't think those ROMs have ever been backed up - that would be great.
The Option 30 user manual has been scanned and posted at dvq.com/tektronix but we don't have the Option 30 Service Manual.

 

[WaveyDipole]

I am equally baffled. Any further traces would be appreciated. Let s hope that they provide some clue. Failing that, the Binary Program Reader ROM will have to be disassembled to understand what it does exactly. I think I downloaded a 6800 reference a while back but will also need a reference to 405x machine system calls. I eagerly await your traces!

 

[nikola-wan]

I am equally baffled. Any further traces would be appreciated. Let s hope that they provide some clue. Failing that, the Binary Program Reader ROM will have to be disassembled to understand what it does exactly. I think I downloaded a 6800 reference a while back but will also need a reference to 405x machine system calls. I eagerly await your traces!

I'm still working on traces.

Check out these docs in the 4051-Assembler folder on my repo for info of 4051 System Rom entry points and System Rom calls:
https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/tree/master/4051-Assembler

- Tek 4051 Assembler Program instructions
- 4051 assembly code documentation.pdf
- sys rom.txt

 

[stepleton]

Are you ready for some heart-pounding Option 31 action??

#6 - SEA DOG

#7 - ICE RACES

#8 - NIGHT RACE ("beginner" mode is boring; be sure to skip ahead to "advanced")

#9 - STRAFE (this one is a bit hard to control)

Games #6 and #8 take advantage of the Dynamic Graphics capability to scale vector "sprites" in order to offer a simplistic first-person perspective.

Thanks for recovering these files --- I hope you might be able to get the other ones with some more effort! In any case, I can say with real certainty that I am today's undisputed world champion for all available games on the 4054/Option 30 platform.

(As an aside: none of these games present an easy method of quitting. I suspect you were supposed to press the AUTO LOAD key when you were finished, and this would take you back to the menu?)

 

[nikola-wan]

OMG! Those games are great!!
Misspelled my name in the video comments: Monty McGraw

I can only imagine that the Lunar Lander game on that tape would have the kind of terrain in Strafe

Tragically, I've tried multiple times to recover the Lander, Star Wars and UFO games from that tape, but the tape is "shedding".
After baking it - it still gave me issues - I had to find some Tyvek and put it around all the metal posts to get the last four games.

I think I'll bake a couple of remaining tapes to recover at a time and use the Game tape base plate and move the tape reels from other tapes to get more files recovered from those tapes.

 

[stepleton]

OMG! Those games are great!!
Misspelled my name in the video comments: Monty McGraw

My apologies, this should all be corrected now.

On that note, I think @WaveyDipole may have referenced me in a readme somewhere as Tom Stephenson, although perhaps there really is such a person and I am just presuming too much

 

[WaveyDipole]

Tom, my apologies. Have now corrected you name in the readme!

I have been experimenting with these binary files in the emulator to see how they behave. In there I can enable some logging and see exactly the bytes that are being read. I have noticed something rather interesting. With the Opt30 Demo files, each time one of the binary files is read, it is only read up to a specific point. The complete file is not read. You can probably guess where it stops - at the point where the superfluous lines start.

Remembering that these files were originally on tape, to occurred to me that maybe the file is being read in exact 256-byte records, and that appears to be the case. I checked 5 not quite so random random files (coastline and helicopter were already on my radar) and each time the read stopped on a 256-byte boundary. I made a table including the file number, the first 14 bytes (up to the space and file name), the size of the file, the size of the file in hex, the point the file was read up to and the number of records that were read.



One thing to note is that since the Tek always stops reading at a specific point despite the file on disk actually being much longer, means that somehow the Tek can determine when to stop reading. There is no specific byte or byte sequence at the point where it stops reading. It just happens to be at the exact end of the file data and on a 256-byte boundary. The additional superfluous information is just ignored. My guess is that the entire file represents the number of records originally allocated (marked) for the file on the tape, versus the stopping point which represents the end of the last record that is actually used.

Secondly, an FF byte is NOT sent at the end of the transmission.

When you look at the table it becomes apparent, at least for the Option 30 demo files, that only two bytes in the header actually change, but I can't see a pattern.

Then there is the last line, which is a file created on the 4051 and saved as a binary file to the flash drive. What happens with this one in the JavaScript emulator is interesting and weird. The file is 315 bytes long on disk, however, the emulated Tek will continue to "read" this up to hex byte 1FF, i.e. exactly 512 bytes, filling the remainder with null bytes. The reason this is even possible is down to a fluke in the JavaScript emulator code, however, it does demonstrate that the Tek is trying to read in blocks of 256 bytes as would have originally the case when using tape. Since my disk file is only 315 bytes long, which is more than one 256-byte record, the Tek wants to read 2 records, or 512 bytes. The opening sequence of bytes for this file is somewhat different to the others, although up to the 10th byte, perhaps not that different.

What does all of this mean? I don't yet have a full understanding, but when BOLD or BAPPEN is called, the flash drive will try to send the entire file. When it reaches the point that the Tek wants to stop, the flash drive will remain in talk mode and want to keep on going which may explain the hang.

Quite how the real 4051 manages it, I don't know, although the FF+EOI being sent at the end, despite apparently being incorrect, seems to be enough to terminate the transmission and make it work. Perhaps the 4052 and 4054 have stricter handling and expect the correct number of 256-byte records?

Could it be that transmission needs to be interrupted by the Tek by sending an ATN? We already seem to have that capability implemented in the code and certainly on the first 4924 trace that I was sent, there is an ATN and then UNT+UNL so transmission ought to have been stopped at this point. This case is a little different to ASCII files where we are looking to pause the transmission. Here we are looking to end it. However, even if we could interrupt, that technique is not going to work for disk files because they are very unlikely to finish on the exact 256-byte boundary. For example, for the 315-byte file mentioned above, the flash drive will send exactly 315 bytes. The Tek will sense that transmission has stopped prematurely and display a MAG TAPE ERROR (which is what does actually happen without the FF+EOI). Satisfying the Tek would require sending "padding bytes" up to the 512-byte boundary. In order to do so, the flash drive would need to be able to calculate this. (Alternatively perhaps BSAVE would have to create files on disk that are exact multiples of 256 bytes, padding up to the last 256-byte boundary?) On the other hand, as can be seen from the Opt30 Demo files, where files are longer than the total number of used records, there needs to be a means to stop after X records has been read. So the problem is actually two fold: sending in 256-byte blocks and to stop sending. The latter means either determining X or allowing interruption. Does the 4924 firmware read the header bytes and calculate exactly how many records to send? Or does the Tek interrupt it?

Plenty of food for thought.

 

[nikola-wan]

Tom, my apologies. Have now corrected you name in the readme!

I have been experimenting with these binary files in the emulator to see how they behave. In there I can enable some logging and see exactly the bytes that are being read. I have noticed something rather interesting. With the Opt30 Demo files, each time one of the binary files is read, it is only read up to a specific point. The complete file is not read. You can probably guess where it stops - at the point where the superfluous lines start.

Remembering that these files were originally on tape, to occurred to me that maybe the file is being read in exact 256-byte records, and that appears to be the case. I checked 5 not quite so random random files (coastline and helicopter were already on my radar) and each time the read stopped on a 256-byte boundary. I made a table including the file number, the first 14 bytes (up to the space and file name), the size of the file, the size of the file in hex, the point the file was read up to and the number of records that were read.

View attachment 1242712

One thing to note is that since the Tek always stops reading at a specific point despite the file on disk actually being much longer, means that somehow the Tek can determine when to stop reading. There is no specific byte or byte sequence at the point where it stops reading. It just happens to be at the exact end of the file data and on a 256-byte boundary. The additional superfluous information is just ignored. My guess is that the entire file represents the number of records originally allocated (marked) for the file on the tape, versus the stopping point which represents the end of the last record that is actually used.

Secondly, an FF byte is NOT sent at the end of the transmission.

When you look at the table it becomes apparent, at least for the Option 30 demo files, that only two bytes in the header actually change, but I can't see a pattern.

Then there is the last line, which is a file created on the 4051 and saved as a binary file to the flash drive. What happens with this one in the JavaScript emulator is interesting and weird. The file is 315 bytes long on disk, however, the emulated Tek will continue to "read" this up to hex byte 1FF, i.e. exactly 512 bytes, filling the remainder with null bytes. The reason this is even possible is down to a fluke in the JavaScript emulator code, however, it does demonstrate that the Tek is trying to read in blocks of 256 bytes as would have originally the case when using tape. Since my disk file is only 315 bytes long, which is more than one 256-byte record, the Tek wants to read 2 records, or 512 bytes. The opening sequence of bytes for this file is somewhat different to the others, although up to the 10th byte, perhaps not that different.

What does all of this mean? I don't yet have a full understanding, but when BOLD or BAPPEN is called, the flash drive will try to send the entire file. When it reaches the point that the Tek wants to stop, the flash drive will remain in talk mode and want to keep on going which may explain the hang.

Quite how the real 4051 manages it, I don't know, although the FF+EOI being sent at the end, despite apparently being incorrect, seems to be enough to terminate the transmission and make it work. Perhaps the 4052 and 4054 have stricter handling and expect the correct number of 256-byte records?

Could it be that transmission needs to be interrupted by the Tek by sending an ATN? Certainly on the first 4924 trace you sent, there is an ATN and then UNT+UNL, although in this case we are not looking to pause the transmission as is the case with ASCII files, but to end it. However, that technique is not going to work for disk files because they are very unlikely to finish on the exact 256-byte boundary. For example, for the 315-byte file mentioned above, the flash drive will send exactly 315 bytes. The Tek will sense that transmission has stopped prematurely and display a MAG TAPE ERROR (which is what does actually happen without the FF+EOI). Satisfying the Tek would require sending "padding bytes" up to the 512-byte boundary. In order to do so, the flash drive would need to be able to calculate this. (Alternatively perhaps BSAVE would have to create files on disk that are exact multiples of 256 bytes, padding up to the last 256-byte boundary?) On the other hand, as can be seen from the Opt30 Demo files, where files are longer than the total number of used records, there needs to be a means to stop after X records has been read. So the problem is actually two fold: sending in 256-byte blocks and to stop sending. The latter means either determining X or allowing interruption. Does the 4924 firmware read the header bytes and calculate exactly how many records to send? Or does the Tek interrupt it?

Plenty of food for thought.

Great analysis.

The fact that the BOLD/BAPPEND is a different Secondary Address 17 - I think the 4924 switches to a 256-byte block mode. In particular, binary programs are not stored the same as binary strings. They are closer to memory images of a program as line numbers and BASIC commands are converted to binary, but text strings - such as those in REMark commands are stored as ASCII text in memory and are therefore 'visible' when examining the binary files.

I believe the binary program initial bytes do indicate to Tek BASIC how large the program is - so it has to be Tek BASIC's logic that dictates when to stop the file transfer process on GPIB (or to the internal tape drive).

On trying to capture 4924 Call "BOLD", "BSAVE", "BAPPEN" for my short test program - I find Tek BASIC reporting error 69 most of the time, but after the file has been completely transferred. Tek BASIC Error 69 reporting an illegal GPIB state of both NFRD and NDAC inactive high - which I see on the logic analyzer as about an 800nsec period. This is when I capture with the 4054A which has the TI9914 GPIB controller hardware. I imagine that the 4051 and 4052/4054 with discrete GPIB circuitry and software GPIB operation do NOT see this error.

 

[WaveyDipole]

I have perhaps made a little progress. I managed to get binary files to load in the JavaScript emulator without needing the FF+EOI at the end and without producing a MAG TAPE ERROR. It loads the demo files and my original 315-byte file and a version padded to 512 bytes. In the case of the shorter file, the padding is added automatically by the JavaScript emulator readBinProg() function which just sends 0xFF for all missing bytes.

The trick now is to replicate this on the flash drive..... and then hope it works on the 4052 and 4054 as well.....

 

[WaveyDipole]

Ok, I believe I have replicated the process I got to work with the JavaScript emulator on the Flash Drive. I have uploaded an update to the repository. It loads both my test file and a couple of the Option30 Demo files I tested (coastline and helicopter)) without error - at least on the 4051. I don't know at this point whether this solves it for Option30 Demo files on the 4052 or 4054, but I am hoping that it will, at least, work for files saved using BSAVE on the flash drive.

 

[nikola-wan]

Your latest code didn't help, but my logic analyzer captures of the 4924 BSAVE and BOLD have the answer (I hope)

1. Internal and 4924 tape files are in data blocks of 256 bytes (file header is in special 'hidden' block of 256 bytes)
2. When a tape file is created - based on number of blocks requested, all data blocks are filled with spaces
3. When a 4924 receives a CLOSE during a SAVE or BSAVE - the 4924 writes FF after the last character.
4. When a 4924 is sending a BOLD (and possibly OLD?) file to the 4050 it sends whole 256 byte blocks.
5. The 4050 buffers the 256 byte blocks and if it finds an FF it sends a CLOSE to terminate the BOLD transfer

zip file attached with Excel files, pdfs of excel and this side-by-side screenshot showing the FF being sent in BOLD but NOT in the BSAVE data!