Products > Test Equipment
Tektronix 2465 MAME emulation
siggi:
Hey y'all,
Since some time around December 2021 I've been noodling on a MAME emulation of the venerable Tektronix 2465. Arguably the 24X[57][AB] are the best portable analog oscillcopes ever produced - certainly I think so - and IMHO they deserve at least the same amount of love^Wattention^Wpreservation as console games.
Here's a quick video showing what the emulation can do right now: https://youtu.be/sR10wNtOMVI. The row of blinking dots across the top are the front panel LEDs, I haven't taken the time to relocate them where they belong. I also have some buttons out of place to allow me to play with the V/DIV controls for CH1/2.
So far, enough of the digital logic is implemented to allow the emulation to display the on-screen-display and to pass all self-tests up to the 05 tests (given a good EAROM image). This is where the scope starts testing the analog controls, which are so far unimplemented.
Given how well documented the hardware is, it should be relatively straightforward to complete a full emulation of this scope, the 24X5/7AB scopes, and their options in general.
If you're a software or an emulation nerd, I'd love some help and/or guidance with this. I'm pretty sure I'm holding the MAMEs wrong, or at least sub-optimally. If you can point me in a more profitable direction, that'd be awesome.
The cosmetics and functionality of the emulation need a whole lot of help, obviously. As a case in point, I'm still not sure how I'd best plumb up the SEC/DIV and V/DIV controls - it doesn't look like MAME has good support for on-screen dials like that?
Help with grousing through the schematics and plumbing up the various controls would also be helpful.
I'd perhaps be remiss if I didn't mention my ulterior motive in this: there's a bug in the CTT option of the 2467 that results in a crazy bright OSD when I select the CTT menu (I upgraded from 07 to the latest - 09 firmware, which sadly didn't fix it). It'd be wonderful to be able to fix that (30+ year old bug) one day, though first I'd want to be able to reproduce it in emulation :).
Peace,
Siggi
siggi:
So I keep pushing this along slow and steady. Here's a fairly recent recording, where I've plumbed up the V/DIV and SEC/DIV controls, along with all buttons and the front panel LEDs. There's even relay clicking :).
Most of the custom Tek hardware in this scope is documented, including the display sequencer, the sweep hybrids and the trigger hybrids, so it's been relatively smooth sailing to at least model the control state of those. The preamp hybrids are the only chips/dies that are entirely missing. The tek_made catalog has a mention of the "203-0210-90 300MHz Vertical Preamp", but no data on it. Even so, it was pretty easy to infer the size of the shift register and the function of the various bits in it.
However, the otherwise excellent "data sheet" for the 155-0244-00 display sequencer doesn't detail the trigger status register. I believe this register is used to assess the state of the trigger hybrid(s) during the 05 self tests, as well as during vertical auto cal - not to mention automated measurements in the 246[57]Bs.
So far I've only been able to infer two bits out of the 16 the firmware reads out, and I think a more direct approach is needed to ferret out the details of what's in that register. The register is read out of the display sequencer serially on pins 18 (data) and 19 (clock). The "tek_made" chapter for the chip has this to say about the "Trigger Status":
Trigger status monitors the activity on the sweep and trigger inputs. This data is latched and then output in a serial fashion on command from the system controller.
Each time the input shift register is updated, or each time the data is read out, data is transferred from the primary latches to the storage latches, and the primary latches are cleared.
Main sweep gates are counted and read out along with the trigger status data.
One bit of the data indicates when the single sequence is completed.
From observation, here are the (two out of 16) bits I think I've sorted:
--- Code: ---// The trigger status register.
// 0x0001: single sweep not complete.
// 0x0800; A triggered.
--- End code ---
So, if anyone has one of those open on the bench, it'd be cool to hookup a logic analyzer and try and see what's in that register.
* Does it count triggers or sweeps - or maybe both?
I guess an easy way to test this is to run some sweeps in auto with no trigger, vs some triggered sweeps.
* Does it count A sweeps only or are there two counters?
Setting up a triggered B sweep would show this.
* Is there a bit to latch B trigger/sweep events like there is for the A sweep events?
Alternatively I suppose I could acquire one of those chips and breadboard something around it to exercise it to reverse the details.
siggi:
In the process of fleshing out the emulation of the trigger dies/hybrids, I re-re-re-read the spec sheet in the tek_made catalog and I found some interesting trivia. It turns out that the trigger dies have some features that seem to be unused.
Trigger mode selection: there are 4 distinct trigger modes, only one of which (SWEEP TRIGGER MODE) I've ever seen selected so far.
These are described on page 6-52 of the tek_made catalog:
* SWEEP TRIGGER MODE
The Trigger Gate sets at the first crossing of the Trigger Level by the Trigger Signal in the direction of the Selected Slope after the Trigger Signal is displaced in the opposite direction in the absence of Trigger Holdoff. The Trigger Gate resets at the assertion of Trigger Holdoff.
* SLOW COMPARE
The Trigger Gate sets when the Trigger Status Output has recovered to the false state, and the Trigger signal is displaced from the Trigger Level in the direcation of the selected slope. The Trigger Gate resets when the Trigger Signal is displaced from the Trigger Leven in the opposite direction of the selected slope.
* FAST COMPARE MODE
The Trigger Gate sets when the Trigger Signal is displayed[sic?] from the Trigger Level in the direction of the selected slope and resets when the Trigger signal is displaceced in the opposite direction.
* STROBED FAST COMPARE MODE
The Trigger Gate sets when the Trigger Strobe is true and the Trigger Signal is displaced from the Trigger Level in the opposite direction of the selected slope. The Trigger Gate resets when the trigger signal is displaced in the opposite direction.
The other feature is "TRIGGER SLOPE SELECTION", where it seems it would be possible to select different trigger slopes for each delay sweep. I don't think the scope offers the possibility of selecting trigger slope per delay sweep - though I may be wrong about that.
MarkL:
(Interesting discovery on Trigger mode selection! ...Will also need to do some reading.)
I've done some preliminary looking at the display sequencer status bits on a 2465, using pins 18 (DATA) and 19 (CLK) as you describe.
Here's the connections so far:
CH1 (yellow) - pin 18, TSO (Trigger Status Out)
CH3 (blue) - pin 19, nTSS (Trigger Status Strobe)
I tried using the scope's SPI analyzer to capture 16 bits of TSO data, but stopped digging further because I'm not getting results consistent with what you've determined so far.
For a very simple test case with the 2465 set to 20ms/div NORM, I'm getting TSO == 0xAA00 while it's waiting for a trigger, and TSO == 0xFE00 after it's triggered by a short pulse and in the middle of a sweep.
Using MSB out first ordering, bit 0x0001 is never set and bit 0x0800 is always set. LSB out first isn't consistent either.
I'm sampling SPI data on the falling edge of clock, but perhaps it is not so simple. Data is stable through the falling and rising edge of the clock as far as I've seen. Maybe there's something else like a delay before sampling the data?
The serial data I/O appears to be completely software driven. Can you tell from the code when it samples the data line (TSO) in relation to when it toggles the clock (nTSS)?
If it helps to visualize what's going on, below are some captures of two clock pulses that shows where the data transition occurs in relation to the clock (two_clocks.png), one whole frame (sixteen_clocks.png), and three frames (three_frames.png). All these are taken with the 2465 in NORM mode, waiting for a trigger.
MarkL:
Ok, some observations on what I posted last night (sometimes it helps to sleep on it).
As I noted, the data line line (TSO) is stable through the entire clock pulse (TSS), so clearly the data is updated after the clock has already completed a pulse. So, it's not valid to acquire the bit value on either the falling or rising edge of the clock, but instead sometime afterwards. Otherwise I'm capturing the _previous_ data value.
According to the datasheet, the max delay from clock transition to data update is 300ns. It doesn't specify falling or rising, but does say from "-TSS", so one could interpret that to be the falling edge of the clock. Still, the data transitions are much greater than 300ns anyway, about 970ns from the falling edge and 610ns from the rising edge of the clock.
I need to mock-up a way to stretch or delay the clock pulse so I can have the scope sample the data line after about 1.5us if I'm going to use the SPI analyzer to re-assemble the frame.
Or maybe I can use a different tool to look at this. Some possibilities are a Saleae Logic Pro, which will certainly record the TSS and TSO, but I don't know if it can handle the delay issue either for the serial decoding. If not, some post processing could do it.
It's a pretty slow signal, so maybe even a C program on a fast microcontroller could do it real-time.
Another approach could be that if the 2465 is storing the reassembled status frame in memory somewhere, and you know the location, I could let the 2465 firmware do the work and just capture the value being written to SRAM with a big old logic analyzer (HP 167xx).
Let me look at this some more...
Navigation
[0] Message Index
[#] Next page
Go to full version