*crickets chirp*
Okay. I'll take that as a "no."
I'm still going to take a swing at it, and I might as well throw my thoughts here.
From an interface perspective, I'm guessing the design was not SO pathological as to require cycle-precise timing to initialize the glove. Worst-case scenario I may need to disassemble Super Glove Ball and just yank its code between those first 4 $4016 reads and wherever I can pin down the end of that sequence being,
but...
From an electrical engineering perspective, I doubt that initial latch low/high hold is being timed explicitly on the glove. Building in timing hardware specifically to prevent people who didn't know to wait precisely 7212µs / 2260µs would be pathological and expensive and easily defeated by some college kid with a good scope. I suspect this is just a function of the setup code of whatever game the trace was recorded from, and for my first pass, I plan to just 4-clock, NMIwait, latch up, NMIwait, latch down and go. If that fails, I can always add code. Having some pause in there is probably a good thing- crunchy semi-analog electronics are likely to need some time to warm up or enter steady-state after being activated, but I will be surprised and depressed if the precise wait times are really required. Also, those first 4 clocks? I'm guessing that's the game "asking" whatever's connected whether it's a Glove. This would make more sense if, say, regular pads returned up/down/left/right bits first and the game could check whether, say, up and down were simultaneously held (if so, probably not a regular pad), but even so, who holds A+B+Start+Select at startup? This may still be what was showing up on the trace, we'll never know what the game was doing with the returned bits. If so, it may not even be a required part of the init- the init may begin with the long hold of the latch, or even with the first clock/poll that (unusually) occurs with the latch still raised.
From a low-level architectural programming perspective, the poster in that newsgroup snapshot who states
Well, if anyone is interested, the 7 bytes sent to init the glove seem
to be: 0x06, 0xC1, 0x08, 0x00, 0x02, 0xFF, 0x01
probably has the right idea, and even the right interpretation of the bytes. My 2 cents as to how that message breaks down is not that it's a "program" per se, but rather a configuration, bookended with the sorts of things you'd want as a Glove-side engineer to verify the message was correct. To wit, I would propose
$06: "6 bytes of data will be included in this packet"
$C1 $08 $00 $02: "go into manual-override mode and start sending me packets conforming to these parameters:..." (no clue what each byte individually represents... $08 may be bits-precision-on-position, $C1 may be as simple as "12-position angular resolution, data returned in steps of 1", but really I'm just taking stabs in the dark. the $C may also refer to 12 bytes of data in the return packet, or the $8 may be requesting 8-ish bytes of non-"junk" data in the return. $00 $02 may be 2's complement on the position data with 0 as center. The world may never know.)
$FF: "here's an easily-identifiable stop-byte. Message ends."
$01: "The message I sent should have checksum $01, if it doesn't you missed something" (or, meh, this may be real data on the order of $FF-range precision in units of $01, or in $01 byte per axis)
If I'm on the right track, posterity may just need to sit back and accept the 2-frame 12-byte packets half full of "junk" because I have no thoughts on what the checksum algo might be (other than that it can probably be computed sequentially bit by bit and take up no more than 1 byte of Glove-side memory. Could it be as simple as an odd/even sum result of the pre-stopbyte bytes? Or an odd/even count of 1s in the bitstream?) Anyway, without cracking the checksum, the Glove would probably reject any variation to the 4 real parameters.
And the "junk" bytes in the return packet? Probably not
strictly junk. It would be appallingly wasteful to force NES developers to take a 50% hit in sampling rate when all the "good" data is in the first 8 bytes. I think the newsgroup also observed the last byte seems to correlate to whether or not the glove is pointed at the speaker array. If it's something as crazy-straightforward as the levels/timings the mics are detecting, it really would look kinda like noise and be ultimately unuseful save in some explicitly designed cases. It may also be that the data packet in "hi-res" mode is 12 bytes always regardless, and the particular hi-res configuration sent to the glove only uses 6-7 of them, with the rest reserved in case of later need. If the return packet isn't fixed-at-12-bytes because of potential data usage, the only other explanation I can think of is that the glove itself needs X amount of time to sample its hardware and may force the NES dev to poll it a few extra times before it's required to return real data just so it has time to get its bits in order. Glove-side register timing is one likely candidate for that blatant vblank wait after the first 8 bytes- if the glove has only 8 regs lined up for data output, it probably needs a breather to shift the remaining 4 bytes in. Still, if I get as far as seeing any data out of the glove, I'll probably test it with the delay and with trying to grab all 12 bytes in one frame.
OR we could turn the Glove-needs-time hypothesis inside out and posit that perhaps the 12-byte return is an
artifact rather than an
intent: it may be that the glove takes Xµs to get a new frame of data any which way, whether it's polled 8 times, 12 times, or 100 times in the interim, and at that wonderful timing everyone's reproduced from that trace diagram, there just happen to be 11 samples between the header byte marking the start of real data and the header byte marking the next start of real data. This would be consistent with observations on the newsgroup that the first bytes out of the glove came from the middle of the "packet": Glove don't care. Glove gonna put Glove's data on the line when Glove's ready, regardless of what big Mr. NES coder's timeline is. It's the game's job to listen for the header byte and jump into the datastream when Glove says so.
But until I get my just-ordered flashcart and start dumping some builds to hardware, I won't really know a thing. And when/if I do get data off the glove onto the NES, I'll try to keep the board updated.
But actually, while I'm not planning a game, I wouldn't be surprised if what I am planning ends up selling a few Power Gloves to the right sorts of people if it works...