Tektronix 2465 MAME emulation  - Page 1
Forum section: electronics / testgear

author: siggi
author_rank: Regular Contributor
timestamp: January 08, 2023, 09:58:18 pm
content: 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 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

author: siggi
author_rank: Regular Contributor
timestamp: February 23, 2023, 07:28:44 pm
content: So I keep pushingthis along slow and steady. Here'sa 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 the155-0244-00 display sequencerdoesn'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 246Bs.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.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.

author: siggi
author_rank: Regular Contributor
timestamp: February 26, 2023, 04:40:10 pm
content: 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 MODEThe 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 COMPAREThe 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 MODEThe 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 MODEThe 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.

author: MarkL
author_rank: Unknown
timestamp: February 28, 2023, 02:46:25 am
content: (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.

author: MarkL
author_rank: Unknown
timestamp: February 28, 2023, 02:50:29 pm
content: 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...

author: siggi
author_rank: Regular Contributor
timestamp: February 28, 2023, 05:14:46 pm
content: Quote from: MarkL on February 28, 2023, 02:46:25 amThe clock is generated through the A5 boards address decoding logic, so to generate a clock "strobe" the firmware simply reads or writes to the "TRIG STAT STRB" address (0x09CF). The data bit is then read as bit 0 of the PORT3 register.It looks like this is done in a loop that reads two bits at a time, while also updating the DAC sample and hold values. I think the full TSO register value is then stored in locations $72/$73.... time passes ...Looking at the firmware, it starts each loop by reading a bit from the port3 register,thenstrobes the clock address. Also, the bits are collected by right shift, so presumably LSB first.Here's the loop:Code:81BA stx $087F // Write to DAC MSB/LSB81BD lda $09E2 // MUX0 enable81C0 lda $09C3 // read port3 (bit 0 is TSO)81C3 sta $09CF // Clock TSS81C6 rora // shift bit 0 to C81C7 ror $00D6 // shift bit to $D6 MSB81CA lda $09C3 // Read another bit81CD sta $09CF // clock TSS81D0 rora // bit to C81D1 ror $00D6 // bit to D6 MSB81D4 lda $D981D6 adda #$0281D8 sta $D9 // increment LDX by two81DA ldx $D8 // read next LDX value81DC ldx (x+$00) // And dereference it to the DAC value81DE lda $09E1 // MUX0 disable81E1 decb81E2 bne $81BA // loop around for another bit.81E4 lda $D681E6 ldb $D781E8 beq $81F181EA clr $00D781ED sta $72 // store first 8 bits read from TS81EF bra $81BA // loop around for the second byte81F1 sta $73 // store last 8 bits read from TSSo from this, the output bits should be valid on the falling edge of TSS?My implementation of the register is clearly not right. The bit order is off, and I'm one clock out of sync with the firmware.I wonder if you ever see TSO change in between interrupts? If not, I guess the first (LSB) bit is simply constant?

author: siggi
author_rank: Regular Contributor
timestamp: February 28, 2023, 06:48:23 pm
content: Quote from: siggi on February 28, 2023, 05:14:46 pmFrom playing with this in emulation, the LSB has to be the "single sweep in progress" bit. If I set that bit and go to SQL SEQ trigger mode (or re-arm it), the "READY" LED lights up and stays on until I clear the bit.So I'd guess to see the LSB of the TSO high, you'd have to arm a single shot trigger. It'd be interesting to know whether it goes high as the DS input register is written, or whether it only changes synchronously to the TSS clock. Same when the trigger fires in single sweep - does the bit change asynchronously, or does it only change when the single sequence sweep ends?Note that a single sweep will sweep all the enabled traces - which may require sweeping each channel as many as three times (e.g. in A/B dual delay mode) as well as the OSD, after which the processor will light the scale illumination for the photo.

author: MarkL
author_rank: Unknown
timestamp: March 01, 2023, 01:54:28 am
content: Quote from: siggi on February 28, 2023, 05:14:46 pmI played with a lot of different settings, and TSO is always high between frames. That makes the first bit read in a frame always a 1.When you say you set the LSB and the READY light goes on, are you poking a value into memory? What value and what location?With your description let me see if I can find the "single sweep in progress" in the serial stream, regardless of the MSB/LSB ordering or skipping a bit.Another question is what defines a frame, since there is no chip select. I can think of few things they might have done: a) Assume the bit counter inside the chip never gets out of sync (that's dangerous), b) There's some other strobe or operation that makes sure the counter resets (such as loading the input register), or c) the counter is reset based on timing (such as after an idle period on TSS between frame polls). The answer is probably not critical. I've been using an idle timeout to define the frame for the SPI analyzer.

author: james_s
author_rank: Super Contributor
timestamp: March 01, 2023, 01:59:01 am
content: MAME is cool, but I'm wondering what is the point of emulating an oscilloscope when you don't have the analog front end and capture, which is the heart of the whole instrument? Is this a "just because" project?

author: LazyJack
author_rank: Frequent Contributor
timestamp: March 01, 2023, 06:43:41 am
content: He said it. He wants to debug and change the firmware.Actually, it would be nice to emulate the 24xx series DSOs and add some features.

author: siggi
author_rank: Regular Contributor
timestamp: March 01, 2023, 03:09:09 pm
content: Quote from: MarkL on March 01, 2023, 01:54:28 amI emulate the "primary latch(es)" described in the spec sheet, and this is then loaded into the shift register every time a new read starts (every 16 bits).To futz the alleged "single sequence in progress" bitI fudge the output bit a little ATM.Quote from: MarkL on March 01, 2023, 01:54:28 amAccording to the spec sheet, the trigger status register is reset each time the input register changes and I presume this clears the output shift register counter. Other than that, my bet would be that the firmware just makes sure to always read 16 bits at a go.

author: siggi
author_rank: Regular Contributor
timestamp: March 01, 2023, 03:26:16 pm
content: Quote from: james_s on March 01, 2023, 01:59:01 amLargely it's that, plus I've always been curious about how the horizontal calibration and particularly the vertical auto calibration work in these scopes. I believe these were likely the first Tek scopes that are largely "closed case" calibrated.There's also that bug in my 2467 CTT firmware that I'd love to fix one day. MAME has partial emulation of the HP3478A that someone used to add arelative measurement feature to the original firmware, which I find pretty cool.Quote from: LazyJack on March 01, 2023, 06:43:41 amI have a 2430. The interface on those early Tek DSOs is IMHO pretty lovable. They use a vectorizer to display the captured trace on the CRT, which looks absolutely beautiful. They're however pretty awful DSOs. Because they use fast CCD capture with slow digitization, they're pretty much totally blind - there's just so much dead time. If you can't trigger on a glitch, there's basically no hope of ever seeing it.

author: MarkL
author_rank: Unknown
timestamp: March 01, 2023, 06:48:45 pm
content: Quote from: james_s on March 01, 2023, 01:59:01 amFor me, "just because". I think it's fun, and at times educational, figuring out how this old stuff works. The 24xx series scopes are particularly interesting because schematics and theory of operation are readily available to provide a solid basis, but some of the finer operations still need to be reverse-engineered.

author: MarkL
author_rank: Unknown
timestamp: March 01, 2023, 08:17:24 pm
content: Well , your test scneario of SGL SWP after a trigger DOES leave TOS low after the last TSS pulse for the frame. Obviously I did not try enough operating modes looking for this condition. Screen shot below of SGL MODE armed (READY) and then sweep done.The previous observation that TSO does not change between frames is still true (at least so far, I should say).As you say, the assembly code shows a bit is read before TSS is pulsed. Let's say a frame has bit numbering like this, in time order for the 16 TSS clock pulses:(start) (end)bit-> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16read-> + + + + + + + + + + + + + + + +clock-> | | | | | | | | | | | | | | | |From the assembly code, it appears to store the frame bits like this:$72: 8 7 6 5 4 3 2 1$73: 16 15 14 13 12 11 10 9Do you agree? I can pull out the logic analyzer to confirm if needed. I think in this case I can use the SPI analyzer and just capture on the TSS falling edge.It's worth noting that bit 1 is from the clock on the previous frame, so it's stale.If you want me to reverse the above bit numbering to better match your code, please let me know. We just need to be consistent.

author: siggi
author_rank: Regular Contributor
timestamp: March 01, 2023, 08:40:47 pm
content: Quote from: MarkL on March 01, 2023, 08:17:24 pmOh - that's awesome - thanks for veriying this!Quote from: MarkL on March 01, 2023, 08:17:24 pmYes, this matches what I see in the emulator - e.g. I set the simulated trigger status register to 0x1234 and I see this in memory:Code:0072 34 12Quote from: MarkL on March 01, 2023, 08:17:24 pmYeah - probably the read-back is always stale. It seems to be that resetting the ... time passes ... K. So Tek service manuals and other documentation has to be read carefully, it seems. From page 5-156 of the tek_made catalog:Trigger StatusTrigger status monitors the activity on the sweep and triger inputs. This data is latched and then ouput 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....So my emulation is still wrong, but oh-boy is the description in concordance with what we observe. Presumably setting up for a single sequence will always read back the single sequence in progress status at least once. Also reading the last bit out of the shift register updates the shift register with the most current state of the primary latches.Quote from: MarkL on March 01, 2023, 08:17:24 pmThis is good by me - the LSB is shifted out first. Though as a (recovering) software engineer, I number the bits 0-15.

author: MarkL
author_rank: Unknown
timestamp: March 02, 2023, 01:47:24 am
content: Quote from: siggi on March 01, 2023, 08:40:47 pmSo this is interesting. The 6800 is a big-endian architecture, and 0x1234 is being stored with 0x34 first at $72, which is a little-endian interpretation. In the end it doesn't really matter; we just need to be clear and consistent in our discussion with the bit positions.QuoteAs an embedded developer, [15..0] is how I would number the bits too, but I was trying to illustrate how the serial order ended up in storage without dragging in any connotations of MSB, LSB, endian, etc. Perhaps I should have used something non-numeric for the bit positions like A, B, C....At any rate, let's stick with bit 1 through bit 16, which represents the time order of the bits read by the firmware from TSO. I propose symbolic names TSO1, TSO2 ... TSO16. TSO1 is the stale bit, which we're pretty sure at this point is "single sweep not complete".With all that in mind, I'll use the SPI analyzer on the scope to see what else I can figure out. If TSO during TEST 05 from the exerciser menu is still of interest (mentioned in email), I can try to get that first. It's about 250 frames/sec for a second or two, so it shouldn't be a lot of data.

author: siggi
author_rank: Regular Contributor
timestamp: March 02, 2023, 04:09:23 pm
content: Quote from: MarkL on March 02, 2023, 01:47:24 amRight - this possibly indicates that the two bytes are independent in function. Other places where 16 bits of data are loaded into X, the byte ordering is clearly big-endian, as is the order of the DAC register halves. Also, as far as I have seen the DAC is written with a single 16 bit write to 0x087F which is the last byte of the address range for DAC MSB. This spills the lower byte to 0x0880, which is the first byte of the address range for DAC LSB.Quote from: MarkL on March 02, 2023, 01:47:24 amYeah, it'd be interesting to see what happens on a successful TEST 05.

author: MarkL
author_rank: Unknown
timestamp: March 02, 2023, 09:15:01 pm
content: Here are the frames during TEST 05. TSO is connected to MISO and the hex value is LSB first (i.e., the hex value is in backwards bit order, TSO16 to TSO1). To be ultra clear, TSO16 is 0x8000 and TSO1 is 0x0001.I manually started the capture a moment before I started TEST 05 on the 2465. TSO outputs 0x0054 frames until TEST 05 kicks in at +8.800ms. It looks like it runs until +1.020s and TSO goes back to idling with 0x0054 frames.In case it matters, the settings on the 2465 are also included in the zip file. This 2465 has a GPIB port, and it's a dump of the GPIB "settings?" command. There are no signals being input.I don't know how helpful this will be by itself. If you need the TSO values in the context of other pins, or other signals somewhere, please let me know.In the meantime, I'll fiddle around with various operations to see if I can spot any more TSO bit meanings. There seems to be some sort of counting going on in the two high order nibbles, and the counts get higher as the sweep speed increases. The high order nibbles are 0x00 at slower speeds, so maybe it's some kind of missed trigger count when the sweep is resetting at the end of a sweep (just an initial guess). Both nibbles are often the same, or at least close to each other in value... maybe something to do with A and B sweep?From the datasheet:Main sweep gates are counted and read out along with the trigger status data.So there's got to be a counter in there somewhere.

author: siggi
author_rank: Regular Contributor
timestamp: March 02, 2023, 10:26:24 pm
content: Quote from: MarkL on March 02, 2023, 09:15:01 pmThanks - I'm going to take a look, see what the emulator thinks it's doing. I speculate that the 05 tests are validating the trigger hybrid, including the analog values from the A5 board against the line trigger input. I've always wondered how it's able to do that without respect to the line voltage, but now that I look at the schematic, one end of the coupling transformer is fed from the centerpoint between the two main DC caps - so I guess on 115V the input is doubled.I wonder if the counts might be sweeps vs triggers? I see that the display sequencer has the sweep gates as inputs, which makes sense as it presumably needs to know when a sweep has concluded to set up for the next sweep in sequence. However, it also has /TSA & /TSB from the trigger hybrid ... time passes ... I think those might be inputs to the trigger hybrid, though, corresponding to the /STE signal to each of the 203-0213-90 trigger dies.So maybe the two count sweeps started vs. sweeps completed - in which case they would never be more than one count apart?There is a mention in the DS that auto triggers don't "count" someplace.

author: MarkL
author_rank: Unknown
timestamp: March 03, 2023, 11:39:46 pm
content: I did some experimenting with creating a number of sweeps between TSO polls, and it appears the count is returned in the high order byte of TSO (TSO16..TSO9). The count maxes out at 0x99 after decimal 99 sweeps.Below is an example screen capture of 23 sweeps with the resulting read from TSO. Here's what you're looking at: When the SPI analyzer is turned on, it overrides my labels so the traces are TSO-->MISO1, TSS-->CLK1, sweep out from the 2465 back panel-->MOSI1. The trace labeled CH1 is the pulse generator input on the 2465 Ch1. The 2465 trace was set to 10ns/div so it would complete all the sweeps quickly enough before the TSO was read.What's very strange is the binary sequence used to represent the decimal value in each of the nibbles. The decimal representation for both nibbles goes like this:Nibble NibbleValue (hex) (binary)----- ------ --------0 0 00001 1 00012 2 00103 3 00114 6 01105 7 01116 C 11007 D 11018 8 10009 9 1001I've shown the binary in the hopes that maybe someone else can spot an encoding scheme, a pattern, or relate this sequence back to a design decision in the chip. The only pattern I see is the 3 high order bits are in groups of 4 vertical 1's, offset by two steps to the other two groups. And the low order bit is just alternating.To verify the full range of the count, I wrote a short script to send the 2465 1 to 120 pulses to make it sweep that number of times, and then record the TSO value for each step. The results are attached in the zip file below. I'll save you some time and say it's consistent with what's described above.I can't see anything I did wrong. If someone else feels inclined, perhaps they can verify.What does the firmware do with the sweep count?

author: siggi
author_rank: Regular Contributor
timestamp: March 04, 2023, 04:43:27 pm
content: Quote from: MarkL on March 03, 2023, 11:39:46 pmThat's awesome - also how strange to do this in BCD-ish. I guess someone decided that'd be preferable to writing binary to decimal conversion, though I'm not aware of any place this sweep count is ever displayed.Quote from: MarkL on March 03, 2023, 11:39:46 pmHow bizarre! Apparently there are a multitude of BCD encodings, but I couldn't find a match withany of the encodings on Wikipedia.Quote from: MarkL on March 03, 2023, 11:39:46 pmI haven't taken a look, though in emulation it's easy enough to set a read watchpoint on a memory location.

author: siggi
author_rank: Regular Contributor
timestamp: March 04, 2023, 05:16:13 pm
content: Quote from: siggi on March 04, 2023, 04:43:27 pmI set a watchpoint on $73 read, then fiddled a bit. Aside from the memory check on startup, I didn't get a single hit on read. I even stepped through CAL 01/02/03/04, where the vertical calibration hit LIMITs and I now have an uncalibrated scope, guesss I need to throw away the EAROM settings.It's still possible that the value is used in particular modes, or perhaps from options. I didn't play with the B sweep as a case in point.On the 2467/2465, the trace and readout intensity is under software control. On those I could see the firmware modulating the A/B-sweep brightness as a function of how often it's sweeping?

author: siggi
author_rank: Regular Contributor
timestamp: March 04, 2023, 07:55:56 pm
content: Quote from: MarkL on March 02, 2023, 09:15:01 pmSo I pulled the dump, deciphered the sweep counts given the information you ferreted out, and the results seem impossible. More below.One thing I see is that TSO6 (0x20) is set whenever the sweep count is non-zero in your dump. I think, however, that this bit logically has to mean either triggered or "at least one sweepstarted". Consider the case where the sweep is super slow, like 500ms/DIV, in which case the sweep count will increment ever 5s. However, the TRIG'D light lights up at the start, and stays lit until the sweep is done.So, I think the TSO register has to have some kind of latching "triggered" or "sweep started" bit, which is almost certainly TSO6 for the A sweep. There almost certainly has to be a "sweep in progress" flag as well. Likely these flags exist for both A and B sweeps? If so, that'd account for 4 out of 8 bits, with the 5th bit being "!single sequence in progress".Now, looking at the sweep counts and trigger flags, there are several cases where the counts are "impossibly" high:Code:dt=3.40ms, v=0010110001110011, ct=26 *T*dt=2.50ms, v=0010001001111111, ct=22 *T*dt=11.30ms, v=1111111111111111, ct=NANA *T*dt=2.10ms, v=0001110001110011, ct=16 *T*dt=2.30ms, v=0001100001110011, ct=18 *T*dt=2.50ms, v=0010000101110011, ct=21 *T*dt=1.60ms, v=0001011001110011, ct=14 *T*dt=2.50ms, v=0010000101110011, ct=21 *T*dt=2.30ms, v=0001100001110111, ct=18 *T*dt=2.50ms, v=0010000101110101, ct=21 *T*dt=1.60ms, v=0001011001110101, ct=14 *T*dt=3.90ms, v=0011001001110111, ct=32 *T*dt=2.50ms, v=0010000101110011, ct=21 *T*dt=1.70ms, v=0001011001110011, ct=14 *T*dt=2.50ms, v=0010000101110111, ct=21 *T*This lists the delta time between TSO value reads, and as you see there are as many as 32 sweep counts in a 3.9ms interval, which corresponds to an 8.2kHz sweep frequency, AND the triggered flag is set. The problem is that I can't think of any way for the hardware to route or generate an 8kHz signal to the triggers.So, what's up with that?

author: MarkL
author_rank: Unknown
timestamp: March 04, 2023, 10:50:53 pm
content: Quote from: siggi on March 04, 2023, 05:16:13 pmIt could be the sweep count capability was "for future use" and never used in the 2465. I have a 2445A which also has the digital intensity control, so I could look there to see what it's doing.QuoteHmmm. I will set up an SPI trigger to look for high sweep count values to see if I can catch any pins that might be supplying something n the 8kHz range. The chip does have a 5MHz clock input, so it could be generating something internally, possibly initiated by a command that puts it in a test mode.

author: MarkL
author_rank: Unknown
timestamp: March 05, 2023, 12:57:19 am
content: Quote from: MarkL on March 04, 2023, 10:50:53 pmOk, there is truly 33 or 34 sweeps occurring between many of the TSO polling intervals by looking at the A gate output on the back (I've been calling it the A sweep output). It's hard to say if something is sending those sweeps to the chip or if it's generating them itself for testing. The 8.5kHz signal is present on a number of pins: 1, 6, 10, 13, 15, and 37, and is sometimes mixed in with other pulses and clocking.I think the chip is generating it itself. It has the 5MHz clock input, so it has a source. It's also responsible for the CAL output, so arbitrary clock generation in this chip already exists in at least one place.Is this important? I can capture all the pins above at once with the scope or the Saleae if you need to know what threy're doing, but maybe I should focus on the other bits in TSO?

author: siggi
author_rank: Regular Contributor
timestamp: March 05, 2023, 03:45:24 pm
content: Quote from: MarkL on March 05, 2023, 12:57:19 amYeah, the holdoff function is also highly programmable. The input register has five bits for trigger holdoff, plus it's adjustable with the DAC. Maybe this is just a really fast autosweep - though I'm surprised to see what I've termed A-triggered bit set for those sweeps. There is a "FREE RUN" bit in the trigger dies, so maybe that's used here - I'll play with the emulator a bit, see if I can figure out what the various modes are.Quote from: MarkL on March 05, 2023, 12:57:19 amI'm not sure that this is important, though I suspect it might be necessary to understand this in due course for the emulator to pass the 05 tests. I'm more interested to know about the bits in the TSO, particularly if there are e.g. " sweep in progress" and " triggered" bits.

author: siggi
author_rank: Regular Contributor
timestamp: March 08, 2023, 12:38:57 am
content: Quote from: siggi on March 05, 2023, 03:45:24 pmSo the "Theory of Operation" section of the service manual has this to say:Trigger and Sweep Activity (Status)The activity of the Trigger and Sweep circuits, as indicated by the /SGA, /SGB, /TSA, and /TSB lines, is reported to the Microprocessor via the TSO (trigger status output) line when clocked by the TSS (trigger status strobe) signal.So /TSA and /TSB are inputs to the Display Sequencer, and not outputs from it, as I had surmised. Presumably these four account for 4 bits of the TSS, with the a fifth bit being the "not single sequence underways".Quote from: siggi on March 05, 2023, 03:45:24 pmMkay, I think this is simply a really fast auto sweep. I'm still trying to figure out how auto sweep works, though by diffing the register settings for the same sweep in AUTO vs NORM I see this:Code:diff AUTO.txt NORM.txt35,37c35,37< :trig_a: 0xFA< -TM0-1, Not Trigger Mode: 1(FAST_COMPARE)< -FR, Not Free Run, Continuous Trigger Gate: 0---> :trig_a: 0xFF> -TM0-1, Not Trigger Mode: 3(SWEEP)> -FR, Not Free Run, Continuous Trigger Gate: 144,45d43So in other words, AUTO is FAST_COMPARE mode with the continuous trigger gate, whereas NORM is SWEEP mode with no continuous trigger gate.I guess in FAST_COMPARE, the sweep triggers on the first of /TGA|/TRIG or THO - or maybe the sweep triggers on the falling edge of THO on auto sweep?

author: MarkL
author_rank: Unknown
timestamp: March 09, 2023, 06:33:20 pm
content: Ok, this took a bit (pun intended?) of playing to come up with a model of what's happening in TSO. At the moment it fits my current set of observations, but you'll probably find something that's inconsistent.Sorry I'm not including data dumps and screen shots; there were just too many combinations to document it all. If there's a particular operating condition(s) you'd like to see, please let me know and I will grab a screen and data capture.Current guess at lower TSO bits 3/9/2023----------------------------------------"now" refers to the interval when TSO is being read out (polled).TSO8..TSO1----------0xxx xxxx /SGB remained high since last poll1xxx xxxx /SGB transitioned low after last poll, or is low nowx01x xxxx /SGA pin is low nowx11x xxxx /SGA pin toggled since last pollx10x xxxx /SGA pin is high nowxxx0 1xxx /TSB pin is low nowxxx1 1xxx /TSB pin toggled since last pollxxx1 0xxx /TSB pin is high nowxxxx x01x /TSA pin is low nowxxxx x11x /TSA pin toggled since last pollxxxx x10x /TSA pin is high nowxxxx xxx0 SNGL mode not READY (sweep done)xxxx xxx1 All other trigger modesOther notes:- /TSB continues to indicate B trigger status, whether B trigger is inuse or not.- /TSA is continuously high or low when free-running in AUTO mode(*not* AUTO LVL mode), depending on if A trigger voltage level iscompletely above or below the input signal.

author: siggi
author_rank: Regular Contributor
timestamp: March 09, 2023, 09:34:03 pm
content: Quote from: MarkL on March 09, 2023, 06:33:20 pmWow, this is awesome. Just to make sure I understand correctly: the x11x (toggled) state is latching - e.g. if the pin in question has toggled, it's going to stay in the x11x state?

author: MarkL
author_rank: Unknown
timestamp: March 09, 2023, 10:36:12 pm
content: Quote from: siggi on March 09, 2023, 09:34:03 pmCool - glad it's useful!The x11x pattern is latched for one poll cycle, then on the next poll it shows the "now" pin state again. The x11x state I think is to let the processor know a transition happened between polls on /SGA. /TSA, or /TSB.If not clear I can set up an example and post the capture.

author: siggi
author_rank: Regular Contributor
timestamp: March 10, 2023, 02:40:29 am
content: While you have the subject on the slab, I'm wondering what is the condition that fires an auto sweep. From looking at the signals between the display sequencer, the trigger hybrid and the sweep hybrids, I'm thinking that it has to be THO transitioning low. This would mean the display sequencer has direct control over the frequency of auto sweep, which almost certainly is related to the reciprocal of sweep speed to maintain something like a steady auto trace brightness across sweep speeds.Seeing how THO goes to both the trigger and the A-sweep hybrid, my bet is that THO transitioning low to the sweep hybrid is what triggers the auto sweep. Looking at thesweep hybrid schematics, it looks plausible that a low THO would initiate a sweep?I guess to validate this, you'd need to look at THO in auto sweep vs the trigger hybrid output?

author: siggi
author_rank: Regular Contributor
timestamp: March 10, 2023, 03:04:58 pm
content: Quote from: MarkL on March 09, 2023, 10:36:12 pmAh, I get it now. Either state of each line (except B sweep) is represented as a latched bit in the trigger status reg. So a set bit means that a particular state occurred and was latched for a particular signal. So a x11x pair means both states occurred from last read.I was wondering why the B-sweep doesn't get the same treatment, but then I realized it shouldn't need to, as the B sweep should always be bracketed by the A sweep.

author: MarkL
author_rank: Unknown
timestamp: March 10, 2023, 11:59:54 pm
content: Quote from: siggi on March 10, 2023, 02:40:29 amI'm seeing that the U500 trigger hybrid output, /TGA (pin 18), is static low when the scope is auto sweeping./SGA going low indicates the beginning of the sweep, and comparing that to THO it's difficult to say who's first due to the vastly different edge speeds of 18ns vs. 74ns (see below).THO does start to drop first, so it's conceivable the sweep hybrid is switching on an unusually high (non-TTL) voltage threshold.EDIT: Let me clarify and say that THO falling is obviously not a result of /SGA falling, but it is not a foregone conclusion that THO falling is causing /SGA to fall. Only that the timing does support the latter as a possibility.

author: siggi
author_rank: Regular Contributor
timestamp: March 11, 2023, 07:11:33 am
content: Quote from: MarkL on March 10, 2023, 11:59:54 pmYeah, I guess the falling edge of THO is not very time critical, but presumably the rising edge has to be crisp for the trigger and sweep hybrids to be sequenced correctly for a sweep.I think this confirms that the display sequencer initiates auto sweep through THO, at least the data doesn't contradict that hypothesis.Now, looking at thetek_made catalog info sheet again, I found this:Ramp Initiation Sweep Gate CircuitryRamp is Initiated by the coincidence of a “LO” at the “Not Trigger”, “Not Auxiliary Trigger" and “Trigger Holdoff” inputs.which seems to further confirm that the falling edge of THO will initiate a sweep if the trigger strobe didn't beat it to it.

author: siggi
author_rank: Regular Contributor
timestamp: March 24, 2023, 08:47:11 pm
content: Quote from: siggi on February 26, 2023, 04:40:10 pmSo it turns out that in the presence of the CTT option, the 2465 does offer the possibility of triggering on alternate slopes for dual B delay sweeps.Likewise, in the presence of the CTT option, my 2467 allows setting distinct slopesANDtrigger levels for each of the delay sweeps. This allows e.g. automated measurement of pulse width, or - possibly - say automated rise time measurement. The latter would be fairly touchy, though my 2467 does display the trigger level voltage as I'm adjusting it.As an aside, I find myself pondering how the CTT option does delta delay measurements, for triggered B sweeps in particular. Since the delay sweeps alternate, there's no way to directly measure the time from one B trigger to the other that I can think of. I guess the CTT option has to measure the A to B trigger delay for each delay/trigger/slope setting and then compute the difference?