| Products > Test Equipment |
| Tektronix 2465 MAME emulation |
| << < (4/7) > >> |
| MarkL:
--- Quote from: siggi on March 01, 2023, 08:40:47 pm ---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 --- --- End quote --- 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. --- Quote --- --- 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 ;). --- End quote --- 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:
--- Quote from: MarkL on March 02, 2023, 01:47:24 am ---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. --- End quote --- 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. --- Quote from: MarkL on March 02, 2023, 01:47:24 am ---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. --- End quote --- 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:
--- Quote from: MarkL on March 02, 2023, 09:15:01 pm ---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? --- End quote --- 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? |
| Navigation |
| Message Index |
| Next page |
| Previous page |