Tektronix 4924 Tape Drive Emulator

[WaveyDipole]

I just took a few minutes to have a brief look at the INPUT problem you mention and I agree that each INPUT statement seems to be reading from the beginning of a new line. However reading the description of INPUT from the 070-2270-00_4051_GPIB_HW_Supp_Jul81.pdf manual, it seems to suggest that this behaviour is in line with what might be expected: "Data bytes are received in this fashion until a CR delimiter is received, an alternate delimiter is received, or until 72 characters are received, whichever occurs first. After one of the above occurs, the 4051 stops the data transfer....". Reading the first sentence under the heading THE UNADDRESSING SEQUENCE it says: "After the 4051 has assigned data to each variable specified in the input parameter list, the 4051 terminates the operation by activating ATN...".

Admittedly I also thought the Tek would process the buffer contents into the variable pairs supplied to each subsequent INPUT statement until it had processed all the data in the buffer. Only then would it have to read the tape and get more data.

However, looking at it, the INPUT statement has two variables. Tek reads data as described up to CR (which comes before 72 characters are read) and assigns the first two values to A$ and B$ (i.e. each variable specified in the parameter list). On the subsequent INPUT it reads the next buffer full of data up to CR and again and assigns the first two values to A$ and B$. This repeats for each INPUT statement.

Could it be that the data needs to be read into an array rather than a bit at a time?

[mmcgraw74]

As I noted in my last post - I agree that Tektronix will read an entire ASCII [CR] terminated string for each INPUT command, so the program needs to INPUT all the variables in string in that command, or unaccessed variables in that string will be lost.

I modified my Adventure data files and program - and got the program to load the four initialization data files and begin accessing the other data files with INPUT statements.  However, I had to add FOR/NEXT delay loops after each CD, FIND and INPUT statement in the program.  It still has errors on random FIND or INPUT statements.  I hope we can figure out how to properly terminate the Emulator commands so delay loops are not needed.

I also updated the ROOT, GAMES and UTILITY programs.  My 4052 is able to load /ROOT/1 which is a menu and can run the menu to load the GAMES or UTILITY menus and the GAMES menu can load a couple of my games programs.  All of those files in my latest upload of the sd card image as Tek4924sd3.zip had to have delays after each command to the emulator.

I hope to repair my 4924 this week, and grab logic analyzer traces that should help.

I also tried these files with time delays on my 4054A which has different GPIB code since it uses a TI 9914 GPIB IC - but it is supposed to be faster on GPIB, so all the manually added timing loops are likely too short

[WaveyDipole]

I agree. It shouldn’t need any timing delays. GPIB handshaking is supposed to ensure that it runs at the rate of the slowest device on the bus.

I managed to get that 4051 off eBay. Auction finished a few minutes ago and I now need to arrange to collect it. I just hope it can be repaired. It seems dead money though as there seemed to be no interest so I would probaby have zero chance to sell it in the future. If it can get repaired then it should make testing things easier.

If you can get your 4924 going, then the logic analyser traces would undoubtedly be very helpful.

BTW what tapes does it use? Standard QIC-120s or QIC-150s? Or did they do what Compaq liked to, that is, add additional lugs or notches to customize so that standard media would not fit and they could charge extortionate costs for their own branded media?

[mmcgraw74]

I agree. It shouldn’t need any timing delays. GPIB handshaking is supposed to ensure that it runs at the rate of the slowest device on the bus.

I managed to get that 4051 off eBay. Auction finished a few minutes ago and I now need to arrange to collect it. I just hope it can be repaired. It seems dead money though as there seemed to be no interest so I would probaby have zero chance to sell it in the future. If it can get repaired then it should make testing things easier.

Excellent!  The seller had posted that 4051 asking for help back on June 16 on the Tek 4051 facebook group: https://www.facebook.com/groups/1157781747606102/permalink/4323203177730594/.  I posted a suggestion to help troubleshoot and we never heard from him again.  I can certainly help you get that one working - yes I suspected one or more bad DRAMs.  That has been one of my 4054 problems, and I also had to replace a couple of DRAMs on a 4907 floppy controller.  Philip Greenstock never posted again - and I figured he didn't want to fix it.  I'm glad you got it - and a good price too.

If you can get your 4924 going, then the logic analyser traces would undoubtedly be very helpful.

BTW what tapes does it use? Standard QIC-120s or QIC-150s? Or did they do what Compaq liked to, that is, add additional lugs or notches to customize so that standard media would not fit and they could charge extortionate costs for their own branded media?

The 4050 computers used 3M DC300 tapes.  I found some DC600 tapes worked when I bought my 4052 and 4054A in 2000.  My latest tape purchase was 3M DC6250 tapes.  The biggest issue with that entire series of tapes is the drive belts from the DC100 tapes disintegrate in the 40 years since they were produced.  Similar fate now for the DC600 and newer tapes.  I purchased a box of DC6250 tapes about three years ago when I got my 4052 and 4054 working again and all the belts and tapes are in great shape. 
There was no keying on the DC300/600/6250 tapes.  When we get the Emulator working - you won't need any tapes 

Lets get your 4051 working - and then I can send you a formatted tape.  There is an EBAY auction for 8KB of 4051 DRAM, that may help if there are bad DRAMs: https://www.ebay.co.uk/itm/333954433557?epid=3045752685&hash=item4dc13c4215:g:OGMAAOSwfBNgciAV


One option missing from your 4051 is the Option 1 RS-232 Serial Interface - which included an Option ROM for BASIC commands to set baud rate, etc.  This option was a PCB inside the ROM backpack.  I do have a 4051 RS-232 Printer Interface ROM Pack that I can't use with my computers as 4052/4054 ROMs were different than 4051 ROM Packs and were keyed to prevent them from plugging into the other system.  The printer interface only wired the TX pin and handshake pins, but I think it would be easy to add an RS-232 buffer to the UART RX pin so you could send and receive programs to the 4051 from a PC at 2400 baud

[mmcgraw74]

I see several DC6250 tapes for sale on EBAY like this one:
https://www.ebay.co.uk/itm/383109575317

[mmcgraw74]

Great news - I fixed my 4924 Tape Drive!

I replaced the power supply 5V output pass transistor - no change.

I have an older 4923 Tape Drive that I have been using for spare parts - I swapped the entire power supply board (same assembly part number - same components) - that worked.

4924 Tape GPIB address DIP switches set to 4 for primary address and 4051 command mode.

First test:

FIND @4:2
INPUT @4:A$

I heard the FIND @4:2 cause the tape drive to seek to file 2, which is an ASCII program called TECO (text editor for 4052 Assembler program in file 1).

I heard it INPUT the first line of the file into A$.  Yes, the Tektronix supports INPUT from ASCII program OR DATA files.

I captured the entire FIND followed by INPUT of one CR terminated character string in one trace - complete trace listing zip file is  attached.

 4924FINP.zip (5.67 kB - downloaded 55 times.)

I also captured four waveforms from this trace:

First one shows the FIND @4:2 command
Second one shows the INPUT @4:A$ command
Third one shows the A$ being sent to the Tektronix
Fourth one focuses on the end of the INPUT command









Here is a photo of the 4052 screen with the text returned from the INPUT command.

The first two lines highlighted in yellow showed me the command worked, but I forgot to trigger the logic analyzer.

The last two lines were typed with the logic analyzer triggering on the first DAV, and both commands were captured and I then stopped the logic analyzer, save the setup and data, captured the waveforms and the trace listing.



Last photo is the working 4924 tape drive on top of my 4052 computer.  The 4052 Assembler tape (3M DC6250 tape with working drive belt) is in the 4924.

I can take more logic analyzer traces tomorrow.

This should help us figure out how to support all the Tektronix tape commands

[WaveyDipole]

Monty, glad you got your 4924 up and running. I am glad that the drive is running with the power supply board from the other unit so at least you know everything else in the unit is OK. I expect that the faulty power supply board can now be repaired and serviced out of circuit and put back once repairs are done.

You mentioned in your earlier post that the 3A fuse blown. In the event of overvoltage due to Q1004 failing, CR33 should crowbar, effectively shorting the supply to ground which would casue the fuse F72 should blow. Since you have replaced the pass transistor and the voltage is still high, then it sounds like either the 741 op amp IC or possibly the 5.6V zenner (VR13) might be faulty. Might also be worth checking R17.

I was going to pick up the 4051 today, but unfortunately while driving to put some fuel for the trip in the car last night I heard a loud whining noise a couple of times, both times on bends. I checked with a couple of local mechanics this morning and the consensus is that the cause might be a worn wheel bearing. I am hoping to have it properly assessed later this afternoon, but in the meantime I don't think it wise to do a 6 hour round trip at high speed on the motorway so have postponed the trip for now.

In the meantime, thank you for the detailed capture showing the 4051 operating the 4924 during FIND and INPUT commands. I have decoded what is being sent and there are some features of interest.

Image 1:

3F 24 7B 20 32 CR [EOI] 5F 3F

The initial 3F (UNL) comes before DAV and doesn't look like its being picked up. Next we have MLA[4] and 7B which is the FIND command. We then get a SPACE followed by 32 (the number 2) which is followed by CR, UNT and UNL. The 2 is obviously a reference to file 2, but why the space?


Image 2:

3F 44 6D (0 FF CR)

The UNL again precedes the first handshake. This is followed by MTA[4] and 6D which is the INPUT command. There is no handshake during the 0 and FF so I think this might be the bus changing state and settling. There is also a CR at the end but since the trace then ends, it is not possible to determine whether there is a handshake.

Image 3

Too compressed to decode

Image 4

20 20 20 28 66 69 6C 65 20 33 29 CR 5F 3F

Three spaces followed by "(file 3)" and a CR. The trace ends with UNT and UNL.

Other items of interest:

• the SRQ line stays asserted the entire time. Is there an error condition requiring attention again? In any case, it doesn't seem to have impeded the functioning of the drive so probably does not have a bearing.
• there is no EOI during INPUT. The single EOI that does appear comes at the end of the FIND command. Is this because INPUT has not reached the end of the file at this point? If so, then that might explain why there is no EOI.
• REN seems to get un-asserted at the end of the transmission. Other signals except SRQ get un-asserted at the same time so this looks like the bus going idle. The emulator doesn't have features that would require remote control so this should have any effect.

I am not sure what all of this means yet but we do need to compare that against what the the current code is doing. I think I would like to start seeing what the trace from just the FIND command looks like using the current emulator code please.

[mmcgraw74]

In the meantime, thank you for the detailed capture showing the 4051 operating the 4924 during FIND and INPUT commands. I have decoded what is being sent and there are some features of interest.

Image 1:

3F 24 7B 20 32 CR 5F 3F

The initial 3F (UNL) comes before DAV and doesn't look like its being picked up. Next we have MLA[4] and 7B which is the FIND command. We then get a SPACE followed by 32 (the number 2) which is followed by CR, UNT and UNL. The 2 is obviously a reference to file 2, but why the space?

Tektronix always inserts a space in front of a numeric variable stored in ASCII form.  This is even true for the tape file header.

Image 2:

3F 44 6D (0 FF CR)

The UNL again precedes the first handshake. This is followed by MTA[4] and 6D which is the INPUT command. There is no handshake during the 0 and FF so I think this might be the bus changing state and settling. There is also a CR at the end but since the trace then ends, it is not possible to determine whether there is a handshake.

The trace listing is complete for the entire FIND @4:2 then INPUT@4:A$ sequence captured with 8 nsec accuracy on any transition.  Each transition has a timestamp indicating how much time has elapsed since the last transition.

Image 3

Too compressed to decode

Check out the trace listing.

Image 4

20 20 20 28 66 69 6C 65 20 33 29 CR 5F 3F

Three spaces followed by "(file 3)" and a CR. The trace ends with UNT and UNL.

Yes, that matches the printout on the 4052 for the contents of A$

Other items of interest:

• the SRQ line stays asserted the entire time. Is there an error condition requiring attention again? In any case, it doesn't seem to have impeded the functioning of the drive so probably does not have a bearing.

I believe this must be a wiring error on the SRQ signal - this signal is zero on every capture.

• there is no EOI during INPUT. The single EOI that does appear comes at the end of the FIND command. Is this because INPUT has not reached the end of the file at this point? If so, then that might explain why there is no EOI.

I think this is important.  Service manual page B-6 indicates on INPUT the 4924 will send the [CR] character last and the Tektronix will then end the command with UNT & UNL.  ASCII INPUTs are always [CR] terminated, so I think this makes sense.

The Appendix B table of 4051 mode GPIB sequences shows the Tektronix using EOI on CLOSE, FIND, KILL, MARK, PRINT, SAVE, SET STATUS, and WRITE commands, but the 4924 only sends EOI on the TALK command when it reaches the EOF of a file.  I think this means it is the Tektronix that ensures the EOI marker is always at the end of each command that writes to a file to cause the 4924 to add the EOF character after the last write.  And the 4924 will replace the previous EOF with the new data on receipt of another write, and add the EOF when it receives the EOI so there is only one EOF in an ASCII program or data file.

• REN seems to get un-asserted at the end of the transmission. Other signals except SRQ get un-asserted at the same time so this looks like the bus going idle. The emulator doesn't have features that would require remote control so this should have any effect.

I am not sure what all of this means yet but we do need to compare that against what the the current code is doing. I think I would like to start seeing what the trace from just the FIND command looks like using the current emulator code please.

Ok, I'll capture an emulator FIND command and put it in the next post.

[mmcgraw74]

Hmm - first I ran into an issue.  I have the Emulator plugged into the 488 cable from the 4052 to the 4924, and I have left the 4924 powered in case we need more traces and I don't want to turn it off.

The issue is - with the 4924 attached plus the Emulator, the Tektronix hangs on the first access to the Emulator.
This could be a bus drive issue, although I captured a trace which showed the SRQ signal had lots of transitions.

I then left the 4924 powered and disconnected the 488 cable to the 4924 for the following experiment and logic analyzer trace capture:

• With the 4924 powered and USB disconnected from the Emulator, I turned on the 4052, then plugged in the Emulator cable
• Then I started the Realterm serial console to the Emulator
• I had no issue entering the PRI@5,19:"ROOT" command
• I then started the Logic Analyzer and typed FIND@5:1 with no issue
• I then typed OLD@5: and the Tektronix was locked up and wouldn't return to prompt
• I then stopped the logic analyzer and captured the attached waveform images and complete FIND and OLD of the short /ROOT/1 menu program

First image should be the FIND command


Second image should be the OLD command


And last is the complete trace listing

 EM_FOLD.zip (7.09 kB - downloaded 33 times.)

And here is the serial debug output:

Code: [Select]

Executing secondary address command: 7B
stgc_0x7B_h: started FIND handler...
stgc_0x7B_h: received parameter:  1
searchForFile: searching /ROOT/...
searchForFile: found file 1
searchForFile: done.
stgc_0x7B_h: found: 1      ASCII   PROG [Root Menu]   4
stgc_0x7B_h: type:  P
attnRequired: Answering attention!
attnRequired: Reading byte...
3F
attnRequired: GPIB command received: 0
Unlisten received.
Unlisten done.
End ATN loop.
attnRequired: END attnReceived.
attnRequired: Answering attention!
attnRequired: Reading byte...
20
End ATN loop.
attnRequired: END attnReceived.
attnRequired: Answering attention!
attnRequired: Reading byte...
45
attnRequired: addressed to talk >>>
attnRequired: Reading byte...
64
attnRequired: secondary addressing command received: 64
End ATN loop.
Executing secondary address command: 64
stgc_0x64_h: started OLD/APPEND handler...
stgc_0x64_h: reading /ROOT/1      ASCII   PROG [Root Menu]   4...
stgc_0x62_h: started CLOSE handler...
stgc_0x62_h: closing: 1      ASCII   PROG [Root Menu]   4...
stgc_0x62_h: done.
stgc_0x64_h: done.
attnRequired: Answering attention!
attnRequired: Reading byte...
attnRequired: Reading byte...
End ATN loop.
Talking...


[WaveyDipole]

Thank you for all of the additional information.

Tektronix always inserts a space in front of a numeric variable stored in ASCII form.  This is even true for the tape file header.

Great. Thanks. That explains the hex 20.

The trace listing is complete for the entire FIND @4:2 then INPUT@4:A$ sequence captured with 8 nsec accuracy on any transition.  Each transition has a timestamp indicating how much time has elapsed since the last transition.

Sorry, I don't see it attached to this post or the previous one?

• there is no EOI during INPUT. The single EOI that does appear comes at the end of the FIND command. Is this because INPUT has not reached the end of the file at this point? If so, then that might explain why there is no EOI.

I think this is important.  Service manual page B-6 indicates on INPUT the 4924 will send the [CR] character last and the Tektronix will then end the command with UNT & UNL.  ASCII INPUTs are always [CR] terminated, so I think this makes sense.

Agreed. Thank you for the list of commands which terminate with an EOI. I have made a note and will remove asserting EOI from the INPUT response.

The traces from the emulator do actually look rather messed up. It is difficult to work out the pre-able, but there does appear to be a 7B for FIND, something possibly comes just before ATN is unasserted and then we have a space. There might just be another character being send before ATN is asserted again and we have 5F and 3F (UNT, UNL). Ignoring SRQ, the bus then goes idle.

The second trace is more interesting. One can make out a 3F at the beggining, which seems to come before DAV. We then have a space while ATN is still asserted and a 46 (F) with EOI. This appears to persist into the second ATN asserted period. There is a long pause after which we get an IFC.

The 4924 operators manual states that "Once addressed as a talker to execute an inout operation, the 4925 (sic) continues to send data over the GPIB until it receives either the GPIB UNTALK or IDC (Interface Clear command". Since it can't receive UNT while sending, we have previously seen that the Tek asserts ATN to cause the send loop to abort. Here we have IFC and then ATN. I had a look back at the previous traces and didn't see IFC being asserted. The GPIB controller would probably send an IFC on startup but that doesn't appear to be the case here. The final two characters are 45 (MSA(5) and  64 (OLD). The bus then appears to go idle.

Firstly, the emulator is not designed to "hear" IFC yet. Secondly, there seems to be some ambiguity as to what's happening at the end of the FIND command. I haven't examined the trace log yet which is what I intend to do next.

[mmcgraw74]

The trace listing is complete for the entire FIND @4:2 then INPUT@4:A$ sequence captured with 8 nsec accuracy on any transition.  Each transition has a timestamp indicating how much time has elapsed since the last transition.


Sorry, I don't see it attached to this post or the previous one?

The trace listings are small zip file attachments in the previous posts (actually close to 60KB of text but zipped to 1/4 that size).

Here is the trace listing from today with the FIND then OLD:

 EM_FOLD.zip (7.09 kB - downloaded 36 times.)

Second attachment is the 4924 trace of FIND then INPUT of A$

[WaveyDipole]

I spotted the second ZIP file in the post just above, but missed the one in the earlier post just before the images. I now have both. Thank you.

I picked up the 4051 yesterday. The size of it - specifically the depth - was a bit unexpected and it is going to be a struggle to find space to accommodate it. There was a bit of disintegrating filter material in the carrier over the fan. I cleared this away to prevent bits getting sucked inside and gave it a good wipe down. The top cover was then removed to have a look inside.

Apart from the usual dust and grime that might gather inside a piece of equipment of this age, the inside looks intact. I don't see any signs of damage or components in distress. I haven't looked inside the power supply case yet though. It also seems to have a full complement of memory chips. A bank of them that runs almost out of view under the CRT is soldered in. The larger group that sit further back and under the neck of the tube are socketed. This does allow for the possibility of a bank to be removed and be used as spares if needed, although there is also that listing you mentioned for the upgrade pack which might be worth getting. In addition to the GPIB port, the unit also comes with two additional D-type ports on the back: J40 which is 9 pin, and J41 which is 15-pin. I have not yet determined their purpose, although there is an instruction next to J40 stating that the unit needs to be powered off before connecting a joystick which probably explains the purpose of J40.

The unit also came with a cartridge in one of the slots to the rear marked “4051 BINARY PROGRAM LOADER”, product number 4051R05 and lists some functions:

CALL “BOLD”
CALL “BSAVE”
CALL “BAPPEND”, 100
CALL “LINK”, 200

It also refers to the Operator Manual for further details.

The first order of business will be to disconnect and check the power supply to make sure all voltages are present and correct. Once that is confirmed, I plan to leave the internal tape drive disconnected and cartridge removed and do a power up test. At present, I am unsure how to get to the logic boards located below the CRT. This will be a necessary step at some point to check that all chips are seated properly. I presume there must be at least one of more ROM chips inside somewhere but I haven't located them yet. I also need to have a read of the operators manual to familiarise myself with the principle controls.

[WaveyDipole]

I have checked the power supply. The fuses on the +20V and -20V rail were good, but the regulated +15V rail was out of range and needed adjustment. This resulted in all other rails (+12V, -12V and +5V) reading slightly high. After adjustment, it reads +15.040V, so comfortably within the expected range. All other rail voltages are also now comfortably within limits.

The display has changed from a full glow and now has a patchy appearance but is still very different from the power-up screen condition I saw the "Introduction to the Tektronix 4051: Part 1" video here:



Hitting Page does nothing and there is no cursor. The BREAK, I/O and POWER lights are all lit. When the ribbon cable to the tape drive is disconnected, the BUSY light comes on as well.

I now need to decide what to look at next.

[mmcgraw74]

Outstanding purchase!

All the manuals for the 4051 have been posted here - including the two service manuals and a folder with scans of the 4051 BASIC ROM:

http://www.bitsavers.org/pdf/tektronix/405x/

This link contains captured ROM images including some of the 4051 ROM Packs that I captured:
http://www.bitsavers.org/bits/Tektronix/405x/

Tektronix also had an active user community and published a newsletter "Tekniques" with user articles and programming tips and tricks.
Tekniques articles are available here:
http://bitsavers.trailing-edge.com/pdf/tektronix/tekniques/

And my github repository of programs I plan to 'port' to the Tektronix 4924 Tape Emulator:
https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files

Several Tektronix 4051, 4052 and 4054 repair articles have been posted to vcfed.org including my repairs.

The 4052 uses the same tape drive, storage tube, display board with a different mainboard than the 4051.

The joystick connector is the small one - I hacked a Kraft PC joystick and successfully connected it to the joystick port.  Now I have a Tektronix joystick.
I don't believe any of the games used the joystick.  The POINTER command required a keyboard key press to read the position of the joystick.  This obviously targeted digitizing applications.

The 15-pin connector only worked with the Tektronix 4631 and 4632 Hard Copy units that would print the contents of the storage tube screen by scanning the screen and sending the signal to a linear CRT in the 4631 which imaged 3M light-sensitive paper for a printout like the ones I captured from the original Battlestar Galactica TV series:

First attachment shows closeup of part of the 4051 screen with the Personnel Report


Second attachment shows Aurora handing the printout from the 4631 (disguised in the foreground) to Colonel Tigh


Third attachment shows the 4631 hard copy of the 4051 screen


Fourth attachment is a press photo of the Battlestar Galactica crew with a Tektronix 4051


https://vintagetek.org/tektronix-in-movies-shows/ link has an article about the Tektronix computers and other equipment loaned to film Battlestar Galactica original TV series.

I also highly recommend you visit the https://www.facebook.com/groups/1157781747606102 Tek 4051 BASIC facebook group which has several 4051 and 4052 users.
Here is the link to the post on the 4051 you purchased and my suggestion on troubleshooting:
https://www.facebook.com/groups/1157781747606102/permalink/4323203177730594/


Last attachment is my Tektronix 4054A, 4052 and 4631 hard copy unit family photo:

[mmcgraw74]

I just saw your last 4051 photo.

This screen is expected when powering on a 4051 - the screen does this and you press the PAGE key to clear the screen.

If the PAGE key doesn't do anything - the BASIC ROM didn't finish testing memory.

You can try to type a simple program:

100 PAGE
110 PRINT "HELLO"

Then type RUN

[mmcgraw74]

If all the lights are on to the right of the screen - the system ROM did not complete system initialization and none of the keys will work.

If only the Power light is on - the system ROM did complete system initialization and BASIC is running.

If pressing the PAGE key does not clear the screen - it may be that key isn't working (after 40 years of non-use).

I had a couple of keys that needed to be carefully exercised - now all the keys work.  The contacts are Cherry keyswitches with gold plating, so they should work better with use.

If you type PAGE and press return, the screen should clear (with a background flash), then you should see a blinking cursor.

[mmcgraw74]

When you get your 4051 working - I highly recommend you purchase this Tektronix 4051 10-in-1 ROM pack from vintagetek.org on EBAY:

https://www.ebay.com/itm/114758122653?hash=item1ab81dfc9d:g:WyYAAOSwcJxgbKot

This is a new design from one of the Tektronix hardware engineers that designed the Tektronix 4052, and includes ALL the 4051 ROMs and more in one slot:

4051R01 Matrix Functions
4051R05 Binary Program Loader
4051R06 Editor
4051R07 Signal Processing I
4051R08 Signal Processing II
4051R12 Graphics Enhancement
4051R14 GPIB Enhancement
4051 DDT51.8 6800 Assembly language Debugger
4051 Extended BASIC
4051 Extended Fonts


You also get a documentation CD-ROM with all the ROM Pack User Guides!

The EBAY page for this MaxiROM Pack has two photos of a new 4051 "CLIST" command which shows the all the 4051 ROM CALL functions, including ALL the MAXIROM CALLs.

The CLIST command is included in the 4051 and 4052/4054 R14 GPIB Enhancement.

The internal BASIC ROMs of the 4051 and 4052/4054 do NOT include a CLIST command.
My 4054 upgraded to 4054A DOES include a CLIST command, which is very handy.

Here is my ROM mapping table for the MaxiROM new CALL commands (from the two CLIST photos in the EBAY post):

Code: [Select]

EXEC          This is a standard CALL in all 4051 for assembly language programs

RATE, etc     These CALLs are included in the 4051 Option 1 RS-232 Comm backpack

RPSAFE        I don't recognize these?  Maybe ROM Pack utilities?
RPKILL
RPWIPE
RPCOPY

BOUNDS, etc   4051R12 Graphics Enhancement

WAIT, etc     4051R14 GPIB Enhancement

CONVL, etc    4051R07 Signal Processing I

IDN, etc      4051R08 Signal Processing II

DEBUG         DDT 51.8 Debugger for 4051 assembly language programs

EDITOR        4051R06 EDITOR

FONT00, etc   4051 Extended Fonts

WHILE         4051 Extended BASIC

There are some very interesting new commands in the Extended BASIC ROM including QDRAW (which I imagine may be similar to the Fast Graphics ROM call?), structured BASIC calls like WHILE and CASE, VLIST and a couple of different CLIST, PEEK and POKE, MTPACK and TNAME.

[WaveyDipole]

The 15-pin connector only worked with the Tektronix 4631 and 4632 Hard Copy units that would print the contents of the storage tube screen by scanning the screen and sending the signal to a linear CRT in the 4631 which imaged 3M light-sensitive paper for a printout like the ones I captured from the original Battlestar Galactica TV series:

That would explain why the post is connected directly to the display board.

You can try to type a simple program:

100 PAGE
110 PRINT "HELLO"

Then type RUN

Tried typing this "blind" and then RUN <enter> but nothing.

If the PAGE key doesn't do anything - the BASIC ROM didn't finish testing memory.

If all the lights are on to the right of the screen - the system ROM did not complete system initialization and none of the keys will work.

All the lights are on. The BUSY light goes out sometimes but BREAK and I/O always stay on. The POWER light also stays on but this is only to be expected while the unit is powered on. Evidently then, the system ROM did not complete system initialisation so I guess it doesn't get as far as the BASIC ROM.

If you type PAGE and press return, the screen should clear (with a background flash), then you should see a blinking cursor.

I did forget about pressing the return, but even with Page + Return unfortunately I get nothing.

When you get your 4051 working - I highly recommend you purchase this Tektronix 4051 10-in-1 ROM pack from vintagetek.org on EBAY:

https://www.ebay.com/itm/114758122653?hash=item1ab81dfc9d:g:WyYAAOSwcJxgbKot

This is a new design from one of the Tektronix hardware engineers that designed the Tektronix 4052, and includes ALL the 4051 ROMs and more in one slot:

Yes, once it is working, that does sound like a good idea. Thanks for the link and the details of the commands. I have made a note.

I have both volume 1 and volume 2 of the service manual. I found some information about further disassembly and have managed to remove the front bezel and keyboard and access the system and memory boards. I have taken some photos and will have a more detailed look another time.

Thank you for the Battelstar Galactica pictures! I did come across and downloaded one picture of the Galactica bridge and will add the pictures you posted to my collection!

I have so far resisted joining Facebook, but have just joined using a throwaway account. I have also requested to join the Tek 4015 group and am awaiting acceptance.

[mmcgraw74]

Here is a photo of the Battlestar Galactica bridge with Tektronix 4051's with the screens in use.

I also found a Battlestar Galactica article in Miami Herald TV Guide newspaper insert indicating the extras on the set were playing games on the computers to make it more realistic, and they continued playing games when the cameras were off!

[WaveyDipole]

Went to post an update this morning on the Facebook group and found that my account has been locked out. No explanation given, just a dialog to request a review. I logged out and back in again but now don't get any options for anything, just a message that says "Help us confirm its you" but the Continue button is greyed out so I don't appear to even have the option to contact anyone. Only signed up yesterday and my only activity was to make a couple of posts on the group!

I tried your advice to disconnect the memory expansion board. It was easy enough to do by just unplugging the ribbon, but I got the same result. Just spent the last hour swapping memory chips two at a time using those from the last bank on the expansion board, but to no avail. It is, of course, possible that there is more than one faulty chip so for all the effort this is still inconclusive. Unfortunately I can no longer report back to the group.

UPDATE: just tried another browser and in addition to the above there was a Captcha verification which didn't appear in Chrome. I got past the Captcha and Facebook then did a verification by sending a code to my mobile phone. I then got a message saying that I am back on Facebook. Just going to post the update there.

[mmcgraw74]

I created a thread on vcfed.org about repairing your 4051 - that may give additional help!

https://www.vcfed.org/forum/forum/genres/other/1217766-new-tektronix-4051-owner-needs-help-repairing-his-4051

[WaveyDipole]

Thanks for creating the post and passing my comments submitted to the Facebook group.  The feedback received from members so far has been appreciated and given me some useful lines of investigation to pursue so in this respect it has been very helpful.

[WaveyDipole]

Monty, I attempted building the ROM reader on a breadboard and I have it partially working. Unfortunately at the moment it only reads the top half of the ROM but the bottom half is gibberish. I tried it with a couple of the ROMs and got the same result. It is possible I got something wrong with the wiring so I will re-check this tomorrow and have another go, but it seems to be working in principle. Once I get it working as it should be then I will read and make a copy of all of the ROMs and compare them with those you linked on bitsavers.org.

I have finally been able to post on vcfed although my initial post will not appear for some time as the first few will be moderated. Its been up a couple of hours now but still awaiting moderation.

UPDATE: Got the ROM reader program working this morning. Re-checked the wiring and found an error. Once I corrected it I could read the entire ROM. I read the two ROMs I tried last night and they compare exactly with the copies I downloaded from bitsavers.org. Now that it is working properly, later on I will go ahead read and compare all of the other ROMs.

[WaveyDipole]

I have now checked all of the remaining ROMs including those on the system board, those in the expansion pack and the two in the Binary Program Loader cartridge and they all look good so we can rule out any problems with ROMs. Once I get the PSU back up and running I will be able to get back to re-checking and diagnosing the main board.

In the meantime, I checked the fan and tape drive. There is not a lot I can do with the fan. It is running OK but a bit noise. I was hoping to lubricate it but it can't be disassembled for maintenance. On the tape drive the drive motor works fine and the rubberised wheel that makes contact with the tape didn't look too bad either. Unfortunately, the head looked rather crusty. I cleaned it with IPA, then tried Servisol and then rinsed with IPA again. It cleaned up a bit and the read/write elements look fine, but the remainder of the face has quite a bit of oxidisation and might be pitted. I wound't risk running a tape through it as it would probably scrape the magnetic coating off it! In any case, once we get the emulator working, the tape will be surplus to requirements anyway so I'm not too worried about it. For now I have put it back into the machine so it can remain connected.

I realised the changes I made in the last version of the emulator code were based on a false premise. Once can't start processing the secondary GPIB commands while ATN is still asserted. There was obviously still something not quite right with 31 and 32, but 33 is definitely not going to work properly. I have obviously been sidetracked over the last few days with getting the 4051 I purchased working so have not done much with the code since last Wednesday. I enjoyed playing with a couple of 4051 emulators today (as you may have seen from my comment on vcfed) and ran a handful of demo programs - at least on Brad's emulator. All good fun!

[WaveyDipole]

Now that the Tek4051 is repaired and working, I tried connecting the 4924 emulator to it. So far the results are an error message:

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

It took me a while but I did find the explanation in one of the manuals.

69     An input error or an output error has occured on the General Purpose Interface Bus. Both the NDAC and NRFD signal lines are inactive high, which is an illegal state. This usually means that there are no peripheral devices connected to GPIB.

I will need to figure out what the problem is but so far I have not been able to communicate using GPIB.