// The trigger status register.
// 0x0001: single sweep not complete.
// 0x0800; A triggered.
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.
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
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.
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?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).
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.
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.
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 :).
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.
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.
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:
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.
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: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.Code: [Select]0072 34 12
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....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 ;).
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.
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?
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:How bizarre! Apparently there are a multitude of BCD encodings, but I couldn't find a match with any of the encodings on Wikipedia (https://en.wikipedia.org/wiki/Binary-coded_decimal).
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.
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 :).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.
Here are the frames during TEST 05.So I pulled the dump, deciphered the sweep counts given the information you ferreted out, and the results seem impossible. More below.
...
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.
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*
...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.
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?
...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.
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?
...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.
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.
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.Yeah, 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.
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?I'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. "[AB] sweep in progress" and "[AB] triggered" bits.
So the "Theory of Operation" section of the service manual has this to say: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?
I'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.Mkay, 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:
diff AUTO.txt NORM.txt
35,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: 1
44,45d43
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 poll
1xxx xxxx /SGB transitioned low after last poll, or is low now
x01x xxxx /SGA pin is low now
x11x xxxx /SGA pin toggled since last poll
x10x xxxx /SGA pin is high now
xxx0 1xxx /TSB pin is low now
xxx1 1xxx /TSB pin toggled since last poll
xxx1 0xxx /TSB pin is high now
xxxx x01x /TSA pin is low now
xxxx x11x /TSA pin toggled since last poll
xxxx x10x /TSA pin is high now
xxxx xxx0 SNGL mode not READY (sweep done)
xxxx xxx1 All other trigger modes
...Cool - glad it's useful!
Wow, 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?
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.
...I'm seeing that the U500 trigger hybrid output, /TGA (pin 18), is static low when the scope is auto sweeping.
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 the sweep hybrid schematics (https://archive.org/details/tektronix_tek_made_sm/page/n300/mode/1up), 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?
/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).Yeah, 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.
THO does start to drop first, so it's conceivable the sweep hybrid is switching on an unusually high (non-TTL) voltage threshold.
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.So 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.