• Please review our updated Terms and Rules here

Saving ROM data from Tek 4052

I didn't get it either to start with. Just think of the ROM as a list of numbers printed out on a piece of paper, and the FPLA as a sheet of acetate with a few numbers printed here and there. Then put the acetate on top of the paper. When you look at the whole, you see mostly the original ROM contents, but when you look at specific places, the values are "overwritten" by the FPLA. Clever stuff, really. You're not likely to be implementing a lot of extra features in 48 bytes, but it should be enough to add a few tweaks or bug fixes in the field. The hardware "challenge", if you like, is catching a few random addresses and slipping a different value onto the data bus, whilst disabling the original ROM for those particular addresses.

Ahh, I see. Now I DO get it. Yes, very nifty.

Tez
 
Wow guys, I didn't expect this thread to take off so fast because I had intended to get started on preserving the ROM contents sometime this summer.

The explanations on the 82S107 actually make perfect sense. Indeed it's fascinating to know how patches were done in the old days before EEPROMs. The schematic even labels these FPLAs as "PATCH FPLA" but I didn't know what that meant. I uploaded the schematic page of interest from the Tektronix 4052 Service Manual:
http://www.electronixandmore.com/temp/4052_MAS_ROMs.pdf

Just as described earlier, there is a FLAG output on the 82S107 that I presume goes high when the FPLA takes over and that shuts off the outputs of the 74LS138 to disable the MK36000 ROMs as the FPLA outputs patched data to the bus. So now it all makes sense to just use Poke/Peek to read off the operating ROM contents then the patch FPLA's wouldn't be needed. However, one little snag, unless I'm mistaken, I did not see anything in Tektronix documentation about POKE and PEEK being valid commands in TekBASIC. I don't recall trying these commands either but if I did, it probably didn't work.

Also, I have no way of storing data off the computer. The built in tape drive might still work but I have no tapes that work. All the old tapes that were given to me with programs on them did not read. I've got a dual 8" floppy drive that connects to the computer via GPIB unfortunately I don't have the actual single-disk drive that also contains the disk controller, so the dual drive is useless. GPIB is a viable option for sending out data, but I'm not sure if I'm able to poke the memory contents of the machine. I've been told by people who used the 4052 systems in the past that assembly language programming of the computer was not documented for reasons such as possibly damaging the hardware or wiping ROM contents. The Tek 4050 reference manual did not mention anything about assembly language programming.

If worse comes to worse, perhaps instead of trying to read off the contents of the 82S107 I can try to build the circuit that is shown in the MAS schematic so an EEPROM reader would extract the corrected data from the ROM and the patch?

Anyway, I hope to gather ideas from this thread and keep it going for a while until the summer arrives.
 
No peek command! What a bummer. Well, worse come to worse you can manually pull out the 8 ROMs and read them into a Data I/O or some type of PROM burner, perhaps directly or with an adapter if it has a stange pinout. The 82S107s will need a simple test fixture like Kyle stated earlier to drive the 16 address lines to check all 65,536 combinations. When the /FLAG goes low on the 82S107, the 8 output lines must be saved with its corresponding address. It could be done manually with 16 switches and nine LEDs to monitor the outputs and flag, but guess how long that test would take. You would probably want to use a ready made microcontroller with a USB connection to a PC to save the data. Something like the teensy. http://www.pjrc.com/teensy/index.html

Since the patch data can go across all the ROM boundries, there may be a few changes in each of the ROMs that can be manual edited into the PROM burner after the ROM content was read in and then new EPROMs burned.

Does your unit have the optional serial RS-232 port? Also the tape cartridge needed is a standard 3M DC300A. While quite obsolete, you should be able to find new ones. You may need to clean the heads on the tape drive before everythings starts working properly.
Good luck with this project.
-Dave
 
Last edited:
Wow this is great Al, I saved all the files for the Tek 405x from Bitsavers. These binary files appear to be V10 or so, and those in my functional 4052 is somewhere around V6 if I recall correctly. I had always wondered if a site like bitsavers.org existed. Thanks again Al for pointing me in this direction! I wonder who recovered the 4052 firmware and put it on bitsavers?

All the binary files are named as Tektronix part numbers. They all appear to differ from those in my service manual, but the LABELS.TXT documentation on the locations seems to suggest that all the binary files are there. Huge relief for me not having to carry the burden of trying to extract the ROM contents and now I have insurance if my only good set of ROMs go bad.

Now, that leaves me one last question, these are binary files. Does EEPROM programming software read them in as is or do they require an extension like .bin for instance?
 
Finally thought I'd join in here. There's a comatose, stripped down 4052 sitting next to me here in the office that's left me stumped for over a year... my kingdom for a service manual! I have no clue if the ROMs are messed up, but considering it just gives a solid green screen and is totally unresponsive, I'd consider that a possible indication.

I have a Data I/O 288 EPROM programmer which (according to the docs) can't read the MK36000s, so I have no way of comparing them with the dumps on the BitSavers website. Any more or less convenient way to read these out, possibly with a newer EPROMmer?

The patch ROM got me thinking tho. Assuming the 82S107s are bad and the ROMs ok, I could try chucking the patch out and see if it runs on the unpatched ROMs alone. Does that sound reasonable?

As for the ROM dump format on BitSavers, your mileage may vary with binary data. EPROMmers normally expect data in a number of different (manufacturer-specific) text based formats, often with checksums. In any case, it's not Tektronix' own format, which is also text based.

Regards,


--Roland
 
As for the ROM dump format on BitSavers, your mileage may vary with binary data. EPROMmers normally expect data in a number of different (manufacturer-specific) text based formats, often with checksums. In any case, it's not Tektronix' own format, which is also text based.

A nice little program to convert a binary file into a standard Intel hexidecimal format that all PROM programmers accept is called format83.com. It is a DOS program. I don't know if it runs in a XP Command Line window. The link below will get you to a format83.zip file that includes the code and instructions.

http://www.programmersheaven.com/download/3178/download.aspx
 
Last edited:
Apparently Motorola 68764 or 68766 eproms are pin compatible (and my stag can read/write them) and also the 2364 rom (as used in the commodore 64) although I can't just find them on this system. (manufacturer?)

I've heard that fusible link proms suffer from growback of the fuses.
I wonder if it's possible to re-program them?, although it would probably be unreliable, as there would be fuses on the point of re-connecting which probably wouldn't be re-disconnected.
 
Apparently Motorola 68764 or 68766 eproms are pin compatible (and my stag can read/write them) and also the 2364 rom (as used in the commodore 64) although I can't just find them on this system. (manufacturer?)
I think I said that in post #2 ;-)
Don't see how a 2364 ROM is relevant, but you can buy adapters to use 2764s if you can't find the 24-pin versions.
 
Sorry MikeS, Didn't look back through the thread far enough!
The pin compatibility was just a suggestion of a couple of more common parts that Ganjatron might have been able to set his eprom programmer to, in order to read his MK36000s, in order to compare them with the bitsavers version.
 
The pin compatibility was just a suggestion of a couple of more common parts that Ganjatron might have been able to set his eprom programmer to, in order to read his MK36000s, in order to compare them with the bitsavers version.
Hi Nige,

well I'll be... thanks for pointing that out! The Data I/O 288 can infact read the 6876x EPROMs! I'll give that a try with the MK36000s. Assuming the ROMs are good after all, I could even upload the contents in a standard format.

Have a great WE,

--Roland
 
Sorry MikeS, Didn't look back through the thread far enough!
The pin compatibility was just a suggestion of a couple of more common parts that Ganjatron might have been able to set his eprom programmer to, in order to read his MK36000s, in order to compare them with the bitsavers version.
No problem. Good thing you did repeat it since it looks like you weren't the only one who didn't read my post; maybe it wasn't clear enough.

Oh well, I waste too much time on here anyway...
 
Hi PhilcoBaby & Co,

well, I managed to somehow read out the MK36000s as 68764 EPROMs on my Data I/O last night. Not really sure if I got anything useful out of them tho.

For one thing, I got inconsistent checksums for subsequent reads of the entire 8-chip set. Generally I have to reseat the devices several times before they're recognised (probably due to worn sockets), but I have successfully read and programmed EPROMs in the past, so I'm not entirely sure if the Data I/O is at fault. The ROMs could infact be flaky.

I then compared the binary dump with the images from Bitsavers, and they match partially at best. This was of course expected, as the images are different revisions (I think the Bitsavers are substantially newer), but they do differ radically in places. Also, the Bitsavers images consist of 10x 8k -- where'd the extra two images come from? What this basically boils down to is that I can't really tell if the ROMs are good.

For what it's worth, I've uploaded my dumps (www.ganjatron.net/misc/tek/mk36000.zip) in various formats (Motorola Exorciser, ASCII Hex, and Binary 10). Note that I dumped the entire set into a single file. Anyone feel like checking if they look like total garbage? :)

Regards,

--Roland
 
Last edited:
I then compared the binary dump with the images from Bitsavers, and they match partially at best. This was of course expected, as the images are different revisions (I think the Bitsavers are substantially newer), but they do differ radically in places. Also, the Bitsavers images consist of 10x 8k -- where'd the extra two images come from? What this basically boils down to is that I can't really tell if the ROMs are good.
How are you comparing the binary files?

According to the LABELS.TXT file on bitsavers, two of the 10 firmware images are from the patch FPLAs. The images don't appear blank so there were still plenty of patches programmed into the FPLAs. I wonder how the images were taken off an FPLA if it goes tristate on some address locations? Maybe Al can explain this?

Would it be possible to overlap the FPLA image to all the ROM images based on address locations to make final ROM images without needing the FPLAs?
 
How are you comparing the binary files?
Actually, I just did a casual side by side comparison with the Linux hexdump util (incl. ASCII output). The diffs are so obvious that you don't need a binary diff. Having said that, I'll piece together a 64K image from the BitSavers dumps now that I understand their labeling, and compare that.

According to the LABELS.TXT file on bitsavers, two of the 10 firmware images are from the patch FPLAs.
Yeah, I finally figured out 160-1685 and 160-1702 are the FPLA dumps. I should've disregarded those. In any case, the fact those ROMs give me inconsistent checksums every time I read them suggests dere's sumptin' skwewy awound here... :D

Have a great WE,

--Roland
 
Yeah, I finally figured out 160-1685 and 160-1702 are the FPLA dumps. I should've disregarded those. In any case, the fact those ROMs give me inconsistent checksums every time I read them suggests dere's sumptin' skwewy awound here... :D

I wouldn't be surprised if there are inconsistent checksums because the FPLAs have tristate outputs and if certain address ranges aren't programmed then the output is floating, so your Data I/O is probably confused on how to interpret a tristate output to 0 or 1. That was one of the concerns I raised earlier in this thread when asking how to extract data off the FPLAs. Now that I think about it, I wonder if those binaries on bitsavers for the FPLAs are garbage if the FPLA was read off in the same manner as the MK36000 ROMs?

What kind of Data I/O programmer are you using so I know what to look for when buying a suitable programmer/reader?
 
Hi Philco,

I didn't even attempt to read the FPLA (the Data I/O definitely can't read them), only the MK36000s.

I've got an early 90's vintage model 288A programmer. It has an interchangeable 8-socket module (came with the standard 32-pin). Like I said, the sockets appear to be worn, and it takes several reseats before I can successfully read/write a device -- something you should look out for. (It actually helps if you lift the chip 1mm or so before clamping it). The 288A can be operated at the panel via hex keypad or via RS232 using their software (which I found on the web). You might also want to look into a more modern programmer.

I poked around with the MK36000s last night again -- some (but not all) yielded consistent checksums if read individually. Might try dumping them separately again. Of course I still have no idea what revision these ROMs are. I can only go by those inspection stickers with handwritten dates on the board -- sometime in 1980 in my case, tho I'd have to check again for the exact dates.

Regards,

--Roland
 
Hi again PhilcoBaby et al,

I went back to my Data I/O and redid the ROM dumps (hey, it was a snowy weekend and I had nothing better to do). In preparation for that I dismantled the #1 (master) socket on the EPROMmer and cleaned the leaf contacts with a toothbrush. The result was a slight improvement in that I only had to reseat the ROMs once or twice now. I checked the socket with a few EPROMs I had lying around, and they were read consistenly and without hassle, so it's clear the Data I/O isn't happy with the MK36000s.

I reread and reseated each chip until I got an identical checksum, and dumped that in binary format so it can be compared to the BitSavers ROMs. I also included the labels for each chip along with the datecode printed on them. These appear to be 2 years older than those from BitSavers, and thus different revisions, so they obviously still differ when doing a side-by-side comparison. There are however, a few identical chunks.

Once again, the new dumps can be found at: www.ganjatron.net/misc/tek/mk36000.zip

I'm still clueless as to how ROM failure would manifest itself: would I see runs of identical bytes (e.g. FF, as in an erased EPROM), or just random garbage?

Regards,

--Roland
 
Quick update: I reinstalled the ROMs without the patch ROMs. Absolutely no change in behaviour. Might try it without any ROMs at all, just to see if it makes a diff.

Regards,

--Roland
 
What does your Tektronix do in the next several seconds after it is first turned on?

There are 4 lights next to the tape drive. I haven't looked at the Tek in years so my memory is fuzzy on what the lights are, but I think they're BUSY, I/O, and POWER. I can't remember what the last one was. When my working Tek is first turned on, the POWER light comes on and stays on the whole time. The BUSY light and probably the I/O light comes on then should go off after a few seconds, and the screen should start glowing. Press HOME would clear the screen and at that point you should see a flashing cursor in the upper left.

I had a set of ROMs that were a bit flaky but they did boot up, but when I typed certain BASIC commands the computer just hung up or did not respond properly. The good set of ROMs fixed those issues. If your ROMs are flaky as you suspect because of the checksum issues then perhaps try burning some new compatible ROMs using the binaries from bitsavers?
 
Back
Top