• Please review our updated Terms and Rules here

Saving ROM data from Tek 4052

Philcogrump

Experienced Member
Joined
Jan 15, 2005
Messages
62
Location
Texas
Been away from this forum for quite a while.

I have a couple Tektronix 4052 systems and have one that works. I've received emails from other proud 4052 owners who are trying to fix their systems but theirs probably have bad ROMs. I don't think it's uncommon because both 4052s I have came to me in non-working condition. I got one up and running after I installed a whole set of NOS ROMs that a former Tek engineer gave me along with the 4052s.

Now I'm worried about these ROMs going bad because if they give up the ghost then that's it for me. So I'm putting in some effort to preserve the ROM contents. There are two main types of ROM chips on the memory board that the computer uses for the BASIC interpreter, I think, and the chips are: 82S107 and MK36000. The 82S107 is not exactly a ROM, it's an oddball FPLA (Field Programmable Logic Array) that has tristate outputs! Going to be interesting to figure out how to preserve the contents of the FPLA and coming up with a modern replacement.

The MK36000 seems like a fairly simple ROM chip. Does anyone have suggestions on EEPROM programmers or perhaps a design for a homebrew one that can read the contents off the MK36000? Or if someone has a spare EEPROM programmer...
 
Not exactly trivial, but the 82S107 could probably be replaced by a modern (i.e. fast) (E)EPROM or PLD. Some clever folks did this to replace the 82S100 PLA in the Commodore C64 (and others IIRC); you might want to google and read about what they did. e.g.:
http://www.nightfallcrew.com/?p=887
http://mikenaberezny.com/hardware/projects/pla-replacement/

As you say, the MK36000 looks like it could be replaced with a 68764/66 or, with an adapter, a 2764 or equivalent.

Most people recommend the Willem programmer.
 
Last edited:
You could probably pump the ROM's data out with a BASIC program. I don't suppose you have the async comms board?

Otherwise, didn't these things have GPIB/IEEE-488 ports? Of course, you'd also need something else that speaks IEEE-488 for that option...
 
I've considered using the Arduino (can you tell I love the Arduino?) to read/test ROM and RAM. I did use it to test single-bit RAM chips in my SWTPC. However, you really need 8+log (base two) of the contents number of pins on the Arduino to test all of the addresses of an 8-bit chip without any external switches. With external switches though, you can use the Arduino to control a few of the address pins and the switches to control the rest. Then you can pipe that data from the ROM via USB/serial to your computer, which can put that into blocks of data. If I had an Arduino Mega, I would've already done this and possibly have made an EPROM programmer too!

Kyle
 
cosam,
If there is a floppy on this computer, could it be possible to open a file for output and then set up a loop to do "print#1, peek(address +I)" and just peek the data to a sequential data file? Things to worry about would be to remember to set a "def seg = &HXXXX" to the correct portion of memory that will be read out.
-Dave
 
Not exactly trivial, but the 82S107 could probably be replaced by a modern (i.e. fast) (E)EPROM or PLD.
I see what you mean. Wow what a chip. I looked up the 82S107 as I have never heard of it. It is a Field Programmable ROM Patch. It can take 16 bit addresses and compare them to up to 48 stored addresses and if matched, output an 8 bit byte with a Flag to let the system know to disable the regular ROM for that read cycle.

To emulate this one would not only need something like a 27C512 EPROM (64K X8 ) to store the 48 address traps but also a PAL to detect the 48 trap addresses and output a chip enable for the EPROM and the Flag for the system. And this assumes the PAL or PLD can handle 48 product terms.
 
Well, I don't think you could dump the 82S107 that way, but I wonder if you'd even have to; it's an unusual kind of chip, a ROM 'patch' that effectively lets you change up to 48 bytes in a ROM. If that is indeed how it's used in the 4052 then the 'effective' contents of the MK36000 would be all you'd need and you could just pull the 82S107. I suppose the 82S107 might even be empty if no patches were ever needed.

In any case it shouldn't be too difficult to dump them both if you had to. The MK63000 looks standard and you could probably read it in something like a PC, but something to read the 'S107 might be hard to find and you'd probably have to breadboard something; then again, it's only 48 bytes ;-)

Oops, looks like dave & I crossed in cyberspace ;-)
 
I just realized that there is no reason to emulate the ROM patch chip 82S107. Just read out the complete ROM address space and save on floppy. The contents of the patch ROM will automatically be in the file. If anything goes wrong later with either chip, just replace both the ROM and patch ROM with an adapter for an EPROM with data from the saved file. Mike, am I understanding this correctly?
 
Ah, I had no idea the 82S107 worked like that. I guess if you did the "PEEK loop" twice, once with the 82S107 present and once with it removed, you'd know all you needed to know. Writing to a file on a floppy sounds like a good way of doing it, assuming the floppy can be read on another machine without too much hassle.

And yeah, it's only 48 bytes - I guess the trick is knowing which 48 bytes you're after ;-)
 
...
And yeah, it's only 48 bytes - I guess the trick is knowing which 48 bytes you're after ;-)
Heh, heh, that's why I put the ;-)
;-)

Yeah, sounds like we're all on the same page. I guess it hinges on whether you can in fact PEEK/dump that range either out a serial port or to a diskette that can be read elsewhere.

FWIW, if you can't find (or your programmer can't handle) a 24-pin 8Kx8 EPROM (68764/66) then I think Jim Brain has some cheap 28>24 pin adapters (if you don't want to bother making one yourself).
 
Still with us, Philcogrump? Assuming you can read it that way and our assumption is correct that the 'S107 isn't really needed, you wouldn't need a programmer unless/until you actually needed a replacement, and worst case I'm sure someone on here could program one for you.
 
...
To emulate this one would not only need something like a 27C512 EPROM (64K X8 ) to store the 48 address traps but also a PAL to detect the 48 trap addresses and output a chip enable for the EPROM and the Flag for the system. And this assumes the PAL or PLD can handle 48 product terms.
If you did actually need to emulate one of these I suppose you could just parallel another '512 which just has a single bit programmed in the appropriate locations to emulate the flag bit and switch in the 'patch'.
 
Mike and Steve,
We're pretty good. We solved this gent's problem in a few hours of brainstorming. We should set up shop! 8)
Yeah, well, on paper so to speak...

As they say, in theory practice and theory are the same thing, but in practice that's not always the case...
 
Heh, heh, that's why I put the ;-)
Heh, I figured as much. I'll admit, I was about to reply saying I'd read more than that out before using only bits of wire and a multimeter, before I twigged what one would actually need to do to read out those 48 (rather ellusive) bytes!

you wouldn't need a programmer unless/until you actually needed a replacement, and worst case I'm sure someone on here could program one for you.
And even then, if you can indeed run without the FPLA, you might as well just burn a "pre-patched" version straight to the new chip.
 
Heh, heh, that's why I put the ;-)
I guess it hinges on whether you can in fact PEEK/dump that range either out a serial port or to a diskette that can be read elsewhere.

That's certainly the approach I would explore. I can understand what that means and how to do it.

The EPROM/hardware stuff....well....err...I'm afraid you guys still leave me groping through a fog of incomplete knowledge.

It is a thinner fog than it used to be though ;)

Tez
 
Writing to a file on a floppy sounds like a good way of doing it, assuming the floppy can be read on another machine without too much hassle.
Steve,
You're right he may have a one of a kind floppy format. It would be safer to open an output to a com port and shoot the data to a PC and save on that system.
-Dave
 
...
And even then, if you can indeed run without the FPLA, you might as well just burn a "pre-patched" version straight to the new chip.
Well, yes, that's what we're talking about; pay attention!
;-) ;-)
Dump the patched contents (if there even were any patches), save that for archival purposes and burn (or ask someone to burn) a replacement EPROM from that image if/when needed. But you had an excellent idea, to dump the ROM(s) with and without the patch, maybe even read the ROM directly, even if only for historical reasons.
 
...
The EPROM/hardware stuff....well....err...I'm afraid you guys still leave me groping through a fog of incomplete knowledge.
It is a thinner fog than it used to be though ;)
Tez
Pshaw; you're just being humble.
This is a really neat chip that we're talking about here though, and I'd never heard of it before.

Nowadays most computers have their BIOS in an EEPROM, i.e. an Electrically Erasable and Programmable Read-Only-Memory, and if you need to upgrade or fix a bug you just flash a new image into it with software. But in the old (pre-EEPROM) days a BIOS or equivalent would be in a _really_ Read-Only-Memory (ROM) which had the code permanently installed when it was manufactured, or in an EPROM (Erasable & Programmable ROM) which required a special UV light and a programmer to erase and change the contents; if there was a bug or an upgrade you had to physically replace the chip at the cost of a service call or having a 'user' poke around in the delicate innards with the attendant risks.

What this neat chip (82S107) does is let the computer itself effectively change certain bytes in the ROM/EPROM just as if it were an EEPROM, even though the ROM/EPROM itself can't be reprogrammed; when the computer accesses those locations that you've changed, the 82S107 recognizes the address, disables the ROM, and spits out the corrected data instead of whatever is in the ROM.

Always neat to see how things were done in the old days without all the tools and devices we take for granted todey.
 
Well, yes, that's what we're talking about; pay attention!
;-) ;-)
Heh, I think I lost track with all the thick and fast posting going on! Dave must've mentioned it when I was mid-post.

Anyway, I hope theory and practice coincide on this one. These look like interesting machines - shame that the chances of me actually getting my grubby mits on one seem pretty slim...

The EPROM/hardware stuff....well....err...I'm afraid you guys still leave me groping through a fog of incomplete knowledge.
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.
 
Back
Top