*Warning* the content of this page may be in violation of tektronix copyrights. Tektronix has however written somewhere that manuals for products that are no longer supported can be freely distributed by anyone to anyone. Since the service manuals for the tek1240 is available on the web I consider this page as only complementing this with useful information and not in violation with tektronix copyrights.
This page was last updated 2007-02-24
The tek1240 is what I would call a second generation logic analyzer. It has a build in dedicated screen. It's built solely for the purpose of sampling digital information from a digital system but compared with the systems of today with very limited memory and limited sampling frequency.
The unit I own got into my hands in 2003 after instrument auction where I work. It was in good working condition with probes and at that time I thought of it as a bargain. Perhaps it was. For almost two years it served me well but then suddenly in the middle of a measurement it just stopped. Everything froze and after a re-boot (power off/on) the screen read "Inter processor communication failure". Not nice at all. I left the unit standing on the floor until early december 2006 when I found a small slot of time to start looking at it.
At that time I had no service manuals, schematic diagrams or anything. Earlier attempts to take it apart had also failed but this time I was more determined.
I should place some pictures of the disassembly procedure here
I would say the logic analyzer is split into three major parts.
The timing and sampler section will be left without consideration for the moment. It was working last time the instrument was used and it contains loads of strange custom specific circuits. In total this part is four boards in my unit. One for timing and three sampler cards.
The Control processor is the part that I believe has failed on my instrument. This is one circuit board crammed with digital logic circuits. After removing that board the unit still powers up and give me the same message as before.
The I/O processor consists of several circuit boards. Mainly there is a board marked "I/O-processor" in the card cage. This board contains a CPU (zilog Z80), ROM and RAM. There are also a video driver board in the card cage and several smaller circuit boards on the front panel to manage the keypad, scroll-wheel and softkeys. The I/O is memory-mapped.
The control processor is based on the intel 8088 CPU. This is one of the first Intel 16-bit processors. In fact it was used in the first IBM PC-type computers. Since one of intels design goals was backward compatibility with their 8-bitters it has some features we today would call strange.
The software for the Control processor is stored in eight 27128 EPROMS (128k bytes ROM). Reading this was easy as the EPROMS where socketed, and the sockets were nicely marked with the memory map. In addition to the EPROM there are one 6116 (2K static RAM) and eight 4864 (64k dynamic RAM) chips.
Partly due to not finding a suitable disassembler for the 8088 I have not yet started to disassemle the code. Another showstopper here will be the size of it. Of the 128k I expect only to find very minor text blocks. All the I/O is handled by the I/O-processor so I guess only identifiers are sent over the interprocessor communication link. This is bad news indeed for someone as curious as me. I am also amazed by how hard it is to find a disassembler for it. Actually there are loads of them around but they all seem to assume you are debugging PC-software running on DOS or WINDOWS.
The schematic diagrams for the I/O processor are rather simple to follow. It's a classic Z80 computer kind of system with the only difference that I/O is not using the IO adress space but is memory mapped. Something I have not seen before in a Z80 based system.
While analyzing the code I needed to look somewhat at the hardware aswell. When doing that I found one thing or two that seems odd. I would actually call them bugs in the hardware, but likely someone wanted it to work this way. I have not figured out why yet.
The Z-80 has three interrupt modes. The tek-1240 I/O-processor uses mode 2, that is a vectored mode. This works as follows: When a unit needs service they pull the INT line. When the processor is finished executing the current instruction it issues a interrupt acknowledge by lowering the IORQ and M1 lines simultaneously, and then does a read to get the lower part of a address for where it should look for the interrupt vector table. It sounds more complex than it is really. The problem is that according to the diagrams in the service manual the IORQ line is not connected. I/O-ports are memory mapped so it's not needed. Well, how could a vector then be fed back? Well, it can't. When the processor reads the vector not a single circuit on the data-bus will answer. Fortunately there are pull-up resistors that will give a "FF" back. The processor then uses the upper 7 bits of this + the value loaded into the I register. As far as I understand this is loaded with 1, so the interrupt vector will be read from 0x01FE. This adress contains 0x1EFF so upon every single interrupt from whatever unit you will end up on 0x1EFF. Well done tektronix, why not just use one of the other, simpler, faster, safer interrupt modes?
One thing that still holds true is that EPROMS are slow. Much slower than the processors that need to read instructions from them. The solution for this has been wait-states. That is, as the processor issues a read to EPROM it is put into a wait for a number of clock cycles so that the EPROM is able to look up the data and return it to the bus before the processor samples the bus. The Tek1240 was no exception to this. So how do you do this with the Z80? Well, there is a wait pin and you know when you access the memory since there is some kind of adress decoder that fixes a CE or OE signal for the EPROM. Is this the way it's done in the Tek1240? O-no. That would be the correct way to do it. Instead someone read the data-sheet and saw the M1 pin. This one is used to signal that the processor is in the first internal cycle of processing an instruction. During this cycle the instruction byte is read from memory. So lets use it for signalling wait. Nice solution, until you think again. What if the instruction to read is a multi-byte instruction? Well, then M1 will be held only while reading the first byte! So in fact in the tek-1240 I believe the wait-states does not work. They are added to make the processor slower, but most of the EPROM reads are not delayed. Nice work Tektronix.
The I/O-procesor is based on the ZILOG Z-80 CPU. That's a nice processor that I have used before so writing and reading software for it is not that hard for me. The 1240 I have actually does not have a ZILOG processor but a MOSTEC one, but it's still a Z-80 when it comes to instructions and behaviour.
The software for the I/O processor is stored in five 2764 EPROMS (40k bytes ROM). These are socketed and can easily be read, even if the sockets are of a type I would never ever use for production type equipment. If you want a copy of them, ask I will send it but due to space limitations on the server where I have my homepage I will not provide them for direct download.
In addition to the EEPROMS you can find two 6116 Static RAMS (4k bytes RAM) and a Z80 CPU. Nice indeed. The board was even marked with the memory map for the ROM and RAM space. Since I have been working with the Z80 before I was not so terrified starting to disassemble the software. First attempts were highly unsuccessful however. Looking at the dump-files revealed little details as there were extremely few readable texts there. Problem, could there be that it used a non-ascii character set? Net search. Net search. Net search. Net search yes the service manuals were on bitsavers! Nothing in there but in the GPIB cartridge manual there were a table indicating something strange.
So I made a program that could read the EPROM images and display them using this alternative character set, and BINGO, loads of texts.
Here you can clearly see the text "DIAGNOSTICS IN PROGRESS" in the part showing the decode with alternate character encoding. To the right the norma ASCII dump shows just crap. If you want this program ask, I will send it to you for free. With sourcecode, written in Delphi.
With renewed knowledge about where the text blocks are it's not that hard doing a disassembly of the binary code into "source"-code. I believe at least parts of this was written in C, so I really won't be getting the source code back, just an assembly listing of the compiled code.
Why do I believe parts were written in C? Well, parameter passing seems to be C-ish, that is pushing on the stack making frame-pointers and such. But there is one more powerful indicator, I found the text "ingrpnam.c<ht>1.2" written in plain ASCII in the file. I guess the linker failed to remove it.
So what have I found out by doing the disassembly? Honestly not much. I have not been able to penetrate most of it as I have perhaps spent 20 hours or so analysing the code. That is not enough to find anything. Someday I may find more time and then I will perhaps get to know how the code better.
One thought here is that if I manage to get the rest of the unit back into working condition I might be able to add an ethernet interface. It should really not be that hard, the expansion slot on the backside allows you to do lots of things, and today there are cheap ethernet to serial controllers that would easily fit in it. For instance the Tibbo units.
Another more exotic thought is that modern DDR memories are pretty fast. Would it really be that hard to create a sampler board that is 16 bits wide and 512M Words deep instead of the 1024 words the current cards provide. At full 100MHz sampling that is. Now that would be cool.
I also believe that it would be rather easy to replace the scroll wheel with a ps2 style mouse.