Products > Test Equipment
Tektronix 2465 MAME emulation
siggi:
--- Quote from: MarkL on March 01, 2023, 01:54:28 am ---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?
--- End quote ---
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.
--- Quote from: MarkL on March 01, 2023, 01:54:28 am ---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.
--- End quote ---
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:
--- Quote from: james_s on March 01, 2023, 01:59:01 am ---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?
--- End quote ---
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.
--- Quote from: LazyJack on March 01, 2023, 06:43:41 am ---Actually, it would be nice to emulate the 24xx series DSOs and add some features.
--- End quote ---
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:
--- Quote from: james_s on March 01, 2023, 01:59:01 am ---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?
--- End quote ---
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:
--- Quote from: MarkL on March 01, 2023, 08:17:24 pm ---Well [explitive], your test scneario of SGL SWP after a trigger DOES leave TOS low after the last TSS pulse for the frame.
--- End quote ---
Oh - that's awesome - thanks for veriying this!
--- Quote from: MarkL on March 01, 2023, 08:17:24 pm ---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.
--- End quote ---
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: ---0072 34 12
--- End code ---
--- Quote from: MarkL on March 01, 2023, 08:17:24 pm ---It's worth noting that bit 1 is from the clock on the previous frame, so it's stale.
--- End quote ---
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.
--- Quote from: MarkL on March 01, 2023, 08:17:24 pm ---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.
--- End quote ---
This is good by me - the LSB is shifted out first. Though as a (recovering) software engineer, I number the bits 0-15 ;).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version