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: [Select]

// 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.

[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...

[siggi]

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)?

The 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, then strobes the clock address. Also, the bits are collected by right shift, so presumably LSB first.

Here's the loop:

Code: [Select]

81BA  stx  $087F  // Write to DAC MSB/LSB
81BD  lda  $09E2 // MUX0 enable
81C0  lda  $09C3 // read port3 (bit 0 is TSO)
81C3  sta  $09CF // Clock TSS
81C6  rora // shift bit 0 to C
81C7  ror  $00D6 // shift bit to $D6 MSB
81CA  lda  $09C3 // Read another bit
81CD  sta  $09CF // clock TSS
81D0  rora  // bit to C
81D1  ror  $00D6 // bit to D6 MSB
81D4  lda  $D9
81D6  adda #$02
81D8  sta  $D9  // increment LDX by two
81DA  ldx  $D8  // read next LDX value
81DC  ldx  (x+$00)  // And dereference it to the DAC value
81DE  lda  $09E1  // MUX0 disable
81E1  decb
81E2  bne  $81BA  // loop around for another bit.
81E4  lda  $D6
81E6  ldb  $D7
81E8  beq  $81F1
81EA  clr  $00D7 
81ED  sta  $72  // store first 8 bits read from TS
81EF  bra  $81BA  // loop around for the second byte
81F1  sta  $73  // store last 8 bits read from TS

So 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?

[siggi]

I wonder if you ever see TSO change in between interrupts? If not, I guess the first (LSB) bit is simply constant?

From 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.

[MarkL]

I wonder if you ever see TSO change in between interrupts? If not, I guess the first (LSB) bit is simply constant?

I 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.

[james_s]

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?

[LazyJack]

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.

[siggi]

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?

I 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" bit I fudge the output bit a little ATM.

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.

According 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.

[siggi]

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?

Largely 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 a relative measurement feature to the original firmware, which I find pretty cool.

Actually, it would be nice to emulate the 24xx series DSOs and add some features.

I 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 .

[MarkL]

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?

For 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.

[MarkL]

Well [explitive], 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   16
 read-> +   +   +   +   +   +   +   +   +    +    +    +    +    +    +    +
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  9


Do 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.

[siggi]

Well [explitive], your test scneario of SGL SWP after a trigger DOES leave TOS low after the last TSS pulse for the frame.

Oh - that's awesome - thanks for veriying this!

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   16
 read-> +   +   +   +   +   +   +   +   +    +    +    +    +    +    +    +
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  9


Do 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.

Yes, 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: [Select]

0072  34 12


It's worth noting that bit 1 is from the clock on the previous frame, so it's stale.

Yeah - 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 Status
Trigger 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.

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.

This is good by me - the LSB is shifted out first. Though as a (recovering) software engineer, I number the bits 0-15 .

[MarkL]

Yes, 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: [Select]

0072  34 12


So 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.

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.

This is good by me - the LSB is shifted out first. Though as a (recovering) software engineer, I number the bits 0-15 .

As 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.

[siggi]

So 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.

Right - 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.

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.

Yeah, it'd be interesting to see what happens on a successful TEST 05.

[MarkL]

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.

[siggi]

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?

Thanks - 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.

[MarkL]

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    Nibble
  Value   (hex)    (binary)
  -----   ------   --------
    0       0       0000
    1       1       0001
    2       2       0010
    3       3       0011
    4       6       0110
    5       7       0111
    6       C       1100
    7       D       1101
    8       8       1000
    9       9       1001

I'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?

[siggi]

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.

That'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.

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    Nibble
  Value   (hex)    (binary)
  -----   ------   --------
    0       0       0000
    1       1       0001
    2       2       0010
    3       3       0011
    4       6       0110
    5       7       0111
    6       C       1100
    7       D       1101
    8       8       1000
    9       9       1001

I'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.

How bizarre! Apparently there are a multitude of BCD encodings, but I couldn't find a match with any of the encodings on Wikipedia.

What does the firmware do with the sweep count?

I haven't taken a look, though in emulation it's easy enough to set a read watchpoint on a memory location.

[siggi]

What does the firmware do with the sweep count?

I haven't taken a look, though in emulation it's easy enough to set a read watchpoint on a memory location.

I 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[AB], 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?

[siggi]

Here are the frames during TEST 05.
...
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.

So 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 sweep started". 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: [Select]

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?

[MarkL]

...
On the 2467/2465[AB], 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?

It 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.

...
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?

Hmmm.  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.

[MarkL]

...
Hmmm.  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.

Ok, 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?