It is currently Fri Oct 20, 2017 7:36 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 64 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject:
PostPosted: Wed May 23, 2012 5:59 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
Good work & very interesting! But... you haven't examined the existing power glove games yet? When looking at how they are accessing the glove, some details can be figured out easily - and some things are getting ways more complicated.

---- TRANSMIT (INIT/CONFIG) ----

Transmission is started by outputting a long high level.

The chart at http://i49.tinypic.com/ff1hd0.jpg does have it preceeded by a short high-level & four clk pulses - I can't see the existing games doing that, so I think that that part is total nonsense... Can you try accessing the glove with that part removed?

After that long high level, the first transferred byte indicates the number of following bytes. In your example, that would be 06h, and then followed by 6 other bytes. But in other packets, the length value can (at least) range from 05h to 32h.

In Super Glove Ball, the packet transfer function is at DC94h, with incoming packet number (00h or 01h) in lower 7bit of A register. The corresponding packets defined in ROM are:
Code:
super_glove_ball_tx_packet_00h:
 db   06,C1,08,00,02,FF,01
super_glove_ball_tx_packet_01h:
 db   2E,49,01,38,01,3C,01,A1,01,7D,20,08,10,0C,01,83
 db   01,07,01,3E,1A,19,81,82,70,23,84,14,83,70,27,58
 db   98,28,82,70,81,70,21,81,12,82,15,A7,16,88,87

Normally, the game seems to be using packet 00h only. I haven't spotted a place where it sends packet 01h, maybe it doesn't ever use it at all.

In Bad Street Brawler, the transfer function is at E696h, with packet number (00h..0Ch) in X register. The corresponding packets defined in ROM are:
Code:
brawler_tx_packet_00h:
 db   2D,49,01,38,01,3C,01,A1,01,7D,20,08,08,0C,02,83
 db   02,07,01,3E,19,19,81,82,73,23,84,14,83,77,27,58
 db   98,28,82,C1,76,21,81,12,82,15,A7,16,88,87
brawler_tx_packet_01h:
 db   13,64,48,0E,50,08,44,0C,20,0C,09,11,84,72,22,82
 db   13,81,14,83
brawler_tx_packet_02h:
 db   19,64,10,0C,20,0C,02,94,41,3A,0F,14,B0,13,87,10
 db   21,52,88,84,60,70,21,88,12,84
brawler_tx_packet_03h:
 db   25,67,60,0C,01,28,01,2C,1D,18,00,00,08,0C,10,0C
 db   15,11,2E,82,C1,72,22,44,91,2E,89,FE,33,45,92,2E
 db   BE,66,16,98,17,A7
brawler_tx_packet_04h:
 db   12,64,02,B7,02,71,10,03,41,3A,08,11,82,12,81,13
 db   A7,14,88
brawler_tx_packet_05h:
 db   23,67,01,34,01,30,01,31,01,35,20,0C,10,0C,44,0C
 db   13,15,98,16,A7,11,52,53,54,21,81,12,82,13,83,14
 db   84,67,77,80
brawler_tx_packet_06h:
 db   32,69,04,0C,01,28,01,2C,1D,18,00,00,01,41,01,45
 db   20,0C,42,84,98,B0,19,87,16,84,17,83,11,20,88,2F
 db   82,C1,BF,62,70,22,44,81,33,45,82,18,98,00,00,00
 db   00,57,57
brawler_tx_packet_07h:
 db   14,65,01,B1,01,B5,01,B4,01,B0,50,0C,08,15,84,8B
 db   11,52,54,53,88
brawler_tx_packet_08h:
 db   21,68,10,0E,02,60,02,48,01,80,01,84,01,26,01,22
 db   64,18,0F,18,70,24,81,15,82,16,84,17,83,11,23,97
 db   12,98
brawler_tx_packet_09h:
 db   23,67,01,34,01,30,01,31,01,35,20,0C,10,0C,44,0C
 db   13,15,98,16,A7,11,52,53,54,21,82,12,81,13,84,14
 db   83,67,77,80
brawler_tx_packet_0Ah:
 db   1A,66,01,26,10,0C,01,25,20,0C,02,71,02,06,0C,11
 db   87,12,84,13,83,14,88,15,81,16,82
brawler_tx_packet_0Bh:
 db   16,65,20,0C,10,0C,08,0E,04,0C,01,1E,0A,11,93,12
 db   92,13,94,14,91,15,88
brawler_tx_packet_0Ch:
 db   05,41,20,0F,01,89

When played via joypad, the game supports two actions via joypad A and B buttons per level. Something like PUNCH and KICK in one level, and whatever... SEX and ROCK'n'ROLL in another level.
So, one guess: maybe the above packets are defining different gestures for that actions.
EDIT: After reading the power glove manual:
The glove BIOS has 14 built-in "programs", numbered 1-14 (for games like Bubble Bobble and Castlevania). The Bad Street Bawler game cartridge has 9 extra "programs", named A-I (for games like Gyruss and Gunsmoke). So, nine of the above 13 packets are apparently used for that purpose.

---- RECEIVE ----

I haven't discovered a "read packet" procedure in Bad Street Brawler yet. It does have a read-byte function at D836h, and it's calling that function in several places. But it's hard to tell if those calls are intended to read glove data or joypad data.
If the game is actually using "gestures handled inside of the glove" then it might simply receive data in form of "gesture flags" (rather than receiving lower-level position and rotation info).

Super Glove Ball is having a very straight read packet function at DCDCh, works like so:

Read 1 byte from glove in EVERY frame. This bytes indicates if the glove is ready to send data. 5Fh (or A0h, if you've XORed it by FFh) indicates ready. If so, the function reads 9 further bytes.

The details about variable conversion time are interesting (and good to know about them!), but with that "ready" byte, one fortunately doesn't need to care about them too much in practice.

Counting the ready-byte plus following 9 data bytes... then... one would read 10 bytes in total. Well. Obviously.
So far, I've no idea where that "12 byte" idea came from. No, stop! I got it. Look at the http://i49.tinypic.com/ff1hd0.jpg chart:
Code:
The headline says 12 bytes, for now, trust that.
The actual diagram shows only 10 bytes, that's a bug.
To fix that: Assume two extra bytes after "byte 8".
Now you have 10 continous bytes. Plus, two final bytes (both preceeded by a long delays) - that are the "not-ready" bytes for the NEXT packet.

So, actually, the 2 ending FFh bytes in 12-byte packets aren't part of that packets, they are only 10-byte long.

And the ready and not-ready values are...
Code:
  5Fh   (or A0h, when XORed by FFh) --> ready
  00h?  (or FFh?, when XORed by FFh) --> not ready
Is that correct? Or is it vice-versa for "not ready"?
Ie. FFh (or 00h, when XORed)?

---- GENERAL STUFF/QUESTIONS ----

Now, are there 3 or 4 flex sensors? Does somebody else have a glove, and could run the ROM-image from LoneKiltedNinja's test program on a NES?
That way it should be very easy to see if the thing does react to flexing a fourth finger, or if it doesn't.

Did somebody ever disassemble the glove hardware? I haven't found any schematics, nor photos of the various PCBs anywhere.
Well, except for a few pics of modded gloves... but they aren't showing the complete PCBs, and for the visible parts... it's hard to say how the PCB originally looked like before modding.
Photos & component list would be interesting. The BIOS is probably contained in some on-chip ROM in the CPU. But you never now, maybe it's on a separate EPROM with a "dump-me" sticker on top of it.

From your readme.rtf at http://www.psychsoftware.org/portfolio/ ... html#Other :
> rotation (clock-hour position minus 1; 0-11)
Ah, but elsewhere you've said that 0 is up? With the "minus one", 0 would mean turned by 30 degrees? Is that correct? Or did you mean something like "modulo 12" instead of "minus 1"?

And, it isn't clear to me where the rotation occurs - around which axis?
Probably difficult to get that clearly described... by assigning a a X,Y,Z coordinate system to the hand... or, probably better: to the TV-set.

For the power glove's rotation part... wikipedia is linking to a page that shows yaw, pitch, and roll of an airplane as an example. But, I am almost sure that only the speakers & microphones are involved... not airplanes!

NB. where exactly are those 2 speakers located in the glove?


Last edited by nocash on Thu May 24, 2012 12:01 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Thu May 24, 2012 8:26 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
Found a good description of the rotation here: http://mellottsvrpage.com/glove.htm - it's "roll" and requires the glove speakers to be aimed at the microphones. Or, in other words, the airplane flying towards the TV-Set.
The page also states what happens if you turn your hand into other directions: The speakers are no longer aimed at the microphones, and so, the thing can't sense the position.

And, I've found a few photos here http://www.instructables.com/id/Power-G ... y-Edition/ it's a bit hard to get through that page... as far as I understood, the guy is telling that he had a "B" in maths, and he's explaining how to create custom cables (cut them at desired length!), anyways, back to the pictures:

PCB at the front of the glove (on the hand): http://www.instructables.com/files/deri ... .LARGE.jpg (component side), and http://www.instructables.com/files/deri ... .LARGE.jpg (solder side). The two speakers seem to be the round black things above index finder and little finger. And, there seems to be a third speaker glued to the middle of the casing; I guess that's where the "beep" sounds are coming from.

PCB for the button part (on the arm): http://www.instructables.com/files/deri ... .LARGE.jpg (showing a fragment of the solder side only). Not much seen there, judging from the solder pads, it doesn't look as if there's a CPU on the component side (unless it'd be a SMD chip). So far, I'd guess that the CPU is located in that mysterious "junction box" (the small box that most photographers never mind taking pictures of when they are posing with their glove).

For the button byte, Super Glove Ball checks for at least five values: 0Ah, 0Ch, 82h, 83h should be as you've described them. And, FFh - is that the value showing up when no button is pressed?

Oh, and here's a typed-up copy of the glove manual: http://home.hiwaay.net/~lkseitz/cvg/power_glove.shtml - it's mentioning the "middle finger" and "last 3 fingers" - if that's correct, then there should be at least one more flex sensor beyond the middle finger.
Maybe your's is actually broken, or one needs to enable via special bytes/bits in init command. Or, you could key-in that "PROGRAM 12", and check if and how the output differs for "middle" and "last 3".


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 24, 2012 5:07 pm 
Offline

Joined: Mon Jul 07, 2008 7:40 pm
Posts: 61
You're covering a lot of ground here, nocash, and I'm having a bit of trouble figuring out what is empirical and what is guesswork.

Quote:
The chart at http://i49.tinypic.com/ff1hd0.jpg does have it preceeded by a short high-level & four clk pulses - I can't see the existing games doing that, so I think that that part is total nonsense... Can you try accessing the glove with that part removed?

After that long high level, the first transferred byte indicates the number of following bytes. In your example, that would be 06h, and then followed by 6 other bytes. But in other packets, the length value can (at least) range from 05h to 32h.


The initial four-bit read at startup is definitively not necessary given that I can re-flash the glove from any arbitrary point at runtime. I initially supposed that the glove might return something unique-ish to disambiguate itself from other controllers in those 4 reads, but I see no evidence to support that in my testing.

Quote:
After that long high level, the first transferred byte indicates the number of following bytes. In your example, that would be 06h, and then followed by 6 other bytes. But in other packets, the length value can (at least) range from 05h to 32h.

My best conjecture based on testing was that it was the number of following bytes in the init message, but given that I was able to fudge it up and down and not completely break functionality, I couldn't pin this down for certain. The additional messages you put forward do certainly lend weight to this argument, though.

Quote:
Normally, the game seems to be using packet 00h only. I haven't spotted a place where it sends packet 01h, maybe it doesn't ever use it at all.
etc.


Quote:
EDIT: After reading the power glove manual:
The glove BIOS has 14 built-in "programs", numbered 1-14 (for games like Bubble Bobble and Castlevania). The Bad Street Bawler game cartridge has 9 extra "programs", named A-I (for games like Gyruss and Gunsmoke). So, nine of the above 13 packets are apparently used for that purpose.

If you want to explore the preprogrammed modes, go right ahead. I've been mainly focusing on the "high-res" mode that lets you get at the "raw" sensor data. But I agree- there's probably some init functionality that lets a game blink the glove into a joypad-emulation mode of choice, or perhaps even define its own mode. In this case, I'd expect the game to send some packet like the ones you listed, then poll only the first byte of data every frame, as you seem to have observed if I'm reading you right. In this case, the glove would likely be sending back generic joypad 8-bit button data where each bit was mapped to some detectable parameter.
As a starting point, the first byte of the init message being the message length as already established, the second byte seems to be, with surprising frequency, $49, or in the $64 - $69 range. I'm not going to put those into binary right away, but I'd suggest that as a starting point for further analysis. Also at a glance, the fact that the start of so many programs has $01 as every other value smacks of significance. A break byte between individual button function-descriptors?

The Brawler tx packet 0C has caught my attention. It looks like another non-program mode variant, but that leading $41 I believe would crash the glove in any of my prior tests. Any idea where it's called? With that many other tx packets, if it's not a high-res mode (and I may be able to test if it is...), there's an off-chance it's setting the glove into a listen-for-program-switch-between-the-modes-I've-just-described mode...?

Quote:
Super Glove Ball is having a very straight read packet function at DCDCh, works like so:

Read 1 byte from glove in EVERY frame. This bytes indicates if the glove is ready to send data. 5Fh (or A0h, if you've XORed it by FFh) indicates ready. If so, the function reads 9 further bytes.

That matches my current documented observation, yes. But I'd advise knowing something about the timing anyway, since I can't empirically guarantee the glove won't occasionally return 0xA0 when not ready, particularly if you're e.g. accidentally reading fewer fields than you've asked for each loop.

Quote:
Counting the ready-byte plus following 9 data bytes... then... one would read 10 bytes in total. Well. Obviously.
So far, I've no idea where that "12 byte" idea came from. No, stop! I got it. Look at the http://i49.tinypic.com/ff1hd0.jpg chart:
Code:
The headline says 12 bytes, for now, trust that.
The actual diagram shows only 10 bytes, that's a bug.
To fix that: Assume two extra bytes after "byte 8".

Now you have 10 continous bytes. Plus, two final bytes (both preceeded by a long delays) - that are the "not-ready" bytes for the NEXT packet.

The 12-byte read is spurious, as I've already documented. To avoid entering wonky undefined states, you "must" read as many bytes as you've asked for (via the field mask bytes in the init message) plus one for the header, plus one extra. Any reads beyond that are strictly optional. The diagram likely reads 12 bytes (header + 11 bytes) because it asked for 9 fields and was being generous in its trailing reads. The single long delay is approximately the length of a vblank wait, indicating they're breaking the read across 2 frames; I have no idea why it's in there since with the init packet documented in the same chart, that delay actually makes the data less stable, but I can readily demonstrate that the first byte after the break is still within the packet, so if they're listening for the next header at that point, they don't know how to operate the glove either. But incidentally, thanks for isolating the tx block in Glove Ball- we now know as conclusively as we're going to where that canonical trace diagram came from :)

Quote:
Now, are there 3 or 4 flex sensors? Does somebody else have a glove, and could run the ROM-image from LoneKiltedNinja's test program on a NES?
That way it should be very easy to see if the thing does react to flexing a fourth finger, or if it doesn't.

I'll be testing this as soon as I can get my hands on a second glove. I really don't know what to expect right now. On the one hand, the alignment of the return data suggests room for a 4th finger and all the ambiguously-sourced online reviews claim the glove does thumb+3 with nothing on the pinky. On the other hand, none of the gestures in the program sets in the manual (which I do have in original print, btw) use the ring finger, meaning it may be awkward and/or flakey and/or just not there.
But yes, if anyone else can test this before I can, please report back!

And your analysis of the rotation is correct- 1 axis ("roll" along the wrist) with 12 detectable positions, 0 being back-of-the-hand faces up (12:00), proceeding clockwise to 11 (11:00). I remember the description you quoted, but the one in the current readme in the devkit does make it a little clearer.
I also had the mics and emitters swapped for a good long time, but I think I have them the right way 'round in the current readme. The two lobes on the top of the glove are (apparently high-volume, from what I can tell) speakers/emitters of, so I've heard, 40kHz pulses (all I can pick up on iPhone spectrum analysis are faint aliases at acoustic frequencies which would not be readily detectable at the recommended 3-5'). The 3 corners of the frame on the TV are microphones/receivers. And one return field of at least one operating mode will give you a clear indicator of which receivers can/can't hear the pings of which emitters.


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 24, 2012 9:35 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
Quote:
My best conjecture based on testing was that it was the number of following bytes in the init message, but given that I was able to fudge it up and down and not completely break functionality, I couldn't pin this down for certain. The additional messages you put forward do certainly lend weight to this argument, though.

And the program is using that byte as loop counter, so it's 100% proof. If you send less bytes than specified, the glove will probably timeout after a while, or treat your next some read-attempts as writes. If you send more than specified, then it'll probably treat the extra-writes as read-attempts.
And finally, if you send & specify less than required, then it might re-use whatever values that were in the input buffers (=uninitialized data on power up). That'd explain some of the effects that you've described.

Quote:
$49, or in the $64 - $69 range

Yeah, looks like bit7=0 for the "program" packets. Except that Brawler #0Ch has that bit cleared, too. The first byte should be some sort of a command byte, but I can't make any sense of it yet. Maybe the whole packet can be broken down to several command+data pairs.

Quote:
the start of so many programs has $01 as every other value

Yup, noticed that one, too. Maybe just an often used parameter value. Or the MSB of a 16bit value.

Quote:
The Brawler tx packet 0C has caught my attention. It looks like another non-program mode variant... Any idea where it's called?

Yes, looks like a non-program packet. Can you try it on real hardware? (I don't have a glove.) And the various Brawler packets, let's see:
Code:
Packet 00h - called when STARTING the game (right after selecting 1-2 players)
Packet 01h - doesn't seem to be used anywhere.
Packet 02h..06h - these are "Program A-E" (for use with other games)
Packet 07h..0Ah - these are intended to be "Program F-I" (but the menu
        selection is bugged; it handles only the cursor's row, and ignores
        the cursor's column; so trying to select programs F-I in right column
        actually mirrors to A-D in left column).
Packet 0Bh - doesn't seem to be used anywhere.
Packet 0Ch - called when BOOTING the game


So, Packet 0Ch must be something for detection and/or main menu controls. And Packet 00h for the actual game controls; it doesn't send further packets when entering the second level, so that packet seems to be used for the whole game (or... the game has sensed that I don't have glove, and doesn't send further packets for that reason).

Quote:
I can't empirically guarantee the glove won't occasionally return 0xA0 when not ready, particularly if you're e.g. accidentally reading fewer fields than you've asked for each loop.

The game uses A0h that way, so it should be stable. Unless, yes, if you read fewer than asked, then it won't be stable.

Quote:
The 12-byte read is spurious, as I've already documented.

Yup, I know. I was just talking about how and why manfredo came up with the 12-byte idea.

Quote:
The diagram likely reads 12 bytes (header + 11 bytes) because it asked for 9 fields and was being generous in its trailing reads.

No, no. It's showing how Super Glove Ball is reading the glove (as seen with an oscilloscope). Absolutely sure. It's matching perfectly with the games program code:

Read the status byte, plus 9 data bytes. Finish.

The two extra reads in following frames are just showing when the NMI handler checks further status bytes. They have absolutely nothing to do with the packet data-reading. But when seeing them on the oscilloscope, it's easy to think that they are part of the packet data.

Quote:
you "must" read as many bytes as you've asked for (via the field mask bytes in the init message) plus one for the header, plus one extra.

I am not too sure if "one extra" is really required. The game isn't doing that (except indirectly: by the following status read in next frame).
What happens if you are doing it the same way? (read 1 status byte per frame, plus 9 bytes upon status=A0h)
Would be interesing to know which status value (or values) you are receiving in that case; ie. particulary, the values that aren't A0h.

Btw. for the flex byte, Glove Ball is checking the lower 6bits. So it seems to be using all 3 fingers; and leave the upper 2bit unused (that'd be thumb as far as I've understood).

Quote:
I remember the description you quoted, but the one in the current readme in the devkit does make it a little clearer.

How new is that? I've downloaded the readme just yesterday. Moment, just downloaded it again. No, it still says "minus 1"! That is: in the summary section. It doesn't match up with the more detailed description section later on in the doc.

Quote:
I'm having a bit of trouble figuring out what is empirical

Phew. Glad to hear that. I was getting afraid that I am the only person who doesn't understand that expressions :-) canonical is giving me a hard time, too.
For the guesswork part... I think I've worked carefully, and results should be around 99..100% proof - hopefully. Please verify everything as possible & correct me if I got something wrong! Obvious guesses, like the purpose of Brawler packet 0Ch, are of course just guesses.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2012 11:47 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
Got the transmit packets more or less fully reversed. The overall transmit packet format is:
Code:
  1. Length Byte (total number of following bytes)
  2. 16bit Opcode Area (convert analog positions to temporary flags)
  3. 8bit Opcode Area (forward temporary flags to joypad bits; can use logic)
  4. Optional 6 extra bytes (whatever purpose, used only in one program)

The "opcodes" are probably just tokens. Though I am a bit afraid that they might be actual processor opcodes... in that case, my research my appear pretty foolish, and it might have been ways easier to read the datasheet... would be REALLY nice if somebody could look inside the glove and scribble down the part number of the chips. Please!
Anyways, 16bit Opcode area:
Code:
Header Byte for 16bit Opcode Area
  7    Low level mode  (0=Digital Joypad Emulation, 1=Analog Low-Level Mode)
  6    Unknown (always 1 in known packets)
  5    Configure glove for use with other games (1=Survive POWER-OFF ?)
  4    Unknown (always 0 in known packets) "prevent re-flash later"?
  3-0  Number of following 16bit commands (used range is 01h..09h)

16bit Opcodes
The upper 8bit (first byte) are:
  15   Unknown (always 0 in known packets)
  14   Unknown                          ;-can be used together with bit13-8
  13   Examine thumb finger flex        ;\
  12   Examine index finger flex        ; only one of these
  11   Examine middle finger flex       ; bits should be set
  10   Examine ring finger flex         ; (usually)
  9    Examine wrist rotation angle     ;
  8    Examine X/Y/Z coordinate         ;/
The lower 8bit (second byte) can have following uses:
For Finger Flex:
  7-4  Unknown (usually 0)
  3-2  Wanted flex or so   (3 or 2=Flex, 0=Want NO Flex)
  1-0  Unwanted flex or so (0=Want Flex, 3=Want NO Flex)
For Wrist Rotation:
  7-4  Max Angle (00h..0Bh)  ;\eg. wanted clock range 3:00 .. 6:00
  3-0  Min Angle (00h..0Bh)  ;/should be Min=3, Max=6; or maybe Max=7, or so
For X/Y/Z Coordinate:
  7-3  Unknown, maybe flag(s) and/or boundary value
  2    Select Direction (0=Right/Up/Back, 1=Left/Down/Forward) (EDIT)
  1-0  Select Parameter (0=X, 1=Y, 2=Z, 3=Fourth Axis??)
The opcodes are computing if the glove is moved in the specified way,
and the result is then stored in the flag array: Flg(1) = 1st opcode's
result, Flg(2) for 2nd opcode, and so on.

Used 16bit Opcodes
First of, the opcodes used in the two "short packets" (with only 1 opcode
each), might have some purpose, or might just be dummies (in case one
cannot specify "0 opcodes"):
  0800           ;request data or dummy or so (glove ball analog mode)
  200F           ;init/detect/disable/dummy or so (used in brawler at power up)
Next, the "normal" position/flex opcodes. Seems as if they can be used
with differet sensitivity boundaries. Below is listing all used values, and
as often as they are used (eg. for thumb, 200C is more common than 2008):
  0128 0128 0130 0130 0138 0138 0180 01B0                ;hand right (EDIT)
  012C 012C 0134 0134 013C 013C 0184 01B4                ;hand left (EDIT)
  0131 0131 0141 01A1 01A1 01B1                          ;hand up
  0125 0135 0135 0145 017D 017D 01B5                     ;hand down
  0122 413A 413A                                         ;hand back
  0126 0126 013E 013E                                    ;hand forward
  0107 0183                                              ;hand axis #4 ???
  040C 440C                                              ;ring bent?
  080C 080C 080E 480E                                    ;middle bent
  1003                                                   ;index NOT bent
  100C 100C 100C 100C 100C 100C 100C 100E 5008 500C      ;index bent
  2008 2008 200C 200C 200C 200C 200C 200C 200C 600C      ;thumb bent
Then, the various wrist rotation opcodes. Again, I have no clue if the
specified range does include/exclode the "max" value (ie. 0283 might
mean 0..8 or 0..7). But it should be easy enough to test that on real
hardware.
  value ;=expl.  ;description from manual
  0283  ;=3..8   ;hand 3 o'clock?
  0294  ;=4..9   ;hand 6 o'clock
  02B7  ;=7..B   ;hand 10 o'clock
  0271  ;=1..7   ;hand 3 o'clock
  4284  ;=4..8   ;hand 6 o'clock
  0260  ;=0..6   ;hand 2 o'clock?
  0207  ;=7..0   ;hand 11 o'clock? ;\these seem to wrap from AM to PM
  0248  ;=8..4   ;hand 10 o'clock? ;/
  0271  ;=1..7 ? ;hand 11 o'clock  ;\according to manual, these should be
  0206  ;=6..0 ? ;hand 2 o'clock   ;/vice-versa (maybe a bug)
Then some very strange ones:
  1D18           ;   right??       ;\these are used in combination with
  0000           ;   left ??       ; "normal" left/right opcodes...
  1D18           ; ...     ?       ; might be somehow related to near & far
  0000           ; ...      ?      ;/transformed to slow/pulsed & fast/normal
And some other odd ones:
  440C           ;\maybe... true if ring finger is NEWLY bent?
  440C           ;/
  040C           ;-looks like "ring", but is undocumented in manual
  6418           ;-two fingers bent?
  011E           ;-looks like hand forward, but is undocumented in manual

And, the 8bit Opcode area:
Code:
Header Byte for 8bit Opcode Area
  7    Append EXTRA SIX BYTES after 8bit Opcode Area (0=Normal, 1=Yes)
  6-5  Unknown (always 0 in known packets)
  4-0  Number of following 8bit commands (used range is 01h..18h)

Registers used with 8bit Opcodes
  Input(0)      General purpose flag (can be used to memorize current "mode")
  Input(1..9)   Results from 1st..9th 16bit Opcode
  Input(0Ah..)  Unused?
  Input(0Eh)    Another general purpose flag (used as frame-toggle or so)
  Input(0Fh)    Another general purpose flag (used as frame-toggle or so)
  Output(0)     Should be BEEP sound (judging from description in manual)
  Output(1..8)  Joypad Shift Register (R,L,D,U,?,?,B,A)  (?,?=probably sta,sel) (EDIT)
  Output(9)     Used in Brawler init and in "Joust" program (... LED?)
  Output(0Ah)   Unused?
  Output(0Bh)   Maybe abort opcode execution... or LED control?
  Output(0Ch..0Fh) Unused?

8bit Opcodes
  0nh   Unknown/unused
  1nh   flg = Input(n)
  2nh   if flg THEN BEGIN CONDITIONAL AREA, and set flg=Input(0..9) (?)
  3nh   Used... 33h is related to Input(3) and related to CONDITION?
  4nh   flg = flg AND Input(n)
  5nh   flg = flg OR  Input(n)
  6nh   Used... somehow related to CONDITIONAL stuff? (ELSE/ELSEIF?)
  7nh   Exchange flg <--> Input(n) (?)
  8nh   Output(n) = flg
  9nh   Output(n) = flg AND PulseA
  Anh   Output(n) = flg AND PulseB
  Bnh   Input(n) = Input(n) XOR flg (?)
  Cnh   Output(n) = NOT flg (?)
  Dnh   Unknown/unused
  Enh   Unknown/unused
  Fnh   Used... FEh is used, related to Input(n)

Extra Six
Finally, "PROGRAM E" has those EXTRA SIX BYTES after the 8bit opcode area. The bytes there are 00,00,00,00,57,57, purpose is unknown.


The overall format seems to apply to the "analog" mode packet, too. Namely, the "number of 16bit opcodes" and "number of 8bit" opcodes seem to be there; except that, in analog mode, the two "8bit opcodes" are actually those 16 flags that you've described.

The "direction bit" in the 16bit opcodes doesn't match up with the readme.rtf - are you sure about "right/up/away-from-screen is positive
"? From the direction bit, I'd expect "right/down/away" being all positive (or all negative).

Aside from the "last 3 fingers" in Program 1, ring finger is also mentioned in Program E and G. Either the glove manual is wrong, or your glove is really broken - did you check it for shortcut & broken wire?

NB. as far as I can see, Bad Street Brawler is having only "faked" glove support; it's simply configuring the glove to emulate a joypad. So it's using only 2D digital input, not using the 3D analog feature at all.

PS. The button/priority in your doc is a bit confusing; a bit like saying that generally the week starts on wednesday, but tuesday comes earlier, and monday is right after the weekend :-) As far as I figured out, you mean ordering like so - from highest to lowest priority:
Left/Right, Up/Down, Enter, Select, Start, Center, 0,1,2,3,4,5,6,7,8,9, A,B
Or did I get that wrong?


Last edited by nocash on Thu May 31, 2012 1:10 pm, edited 2 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sun May 27, 2012 9:39 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
Found more info on buttons, http://www.cse.unsw.edu.au/~waleed/tml/data/glovedata.h
Does mostly match up with the readme.rtf info. But has two additional definitions:
Code:
#define PGLOVE_PROG  (0x84)
#define PGLOVE_NOKEY (0xFF) /* No key pressed is indicated by FF */

That should solve the "what-if-no-button-pressed" question. And 84h for PROG button... do you get that value, too? And if it switches to program mode, does the 84h show up only for a short moment?
And the directions...
Code:
#define PGLOVE_UP    (0x0C)
#define PGLOVE_RIGHT (0x0D)
#define PGLOVE_DOWN  (0x0E)
#define PGLOVE_LEFT  (0x0F)

Damn, that's all different than in the readme.rtf, except, DOWN is same. Can you double-check the DPAD button numbers? I've no clue which of the different values are correct.
The floating point values & extra pitch/yaw entries in glovedata.h are obviously some custom format, not based on the real hardware. But the button numbers seem to be taken as-in from hardware.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 29, 2012 7:26 pm 
Offline

Joined: Mon Jul 07, 2008 7:40 pm
Posts: 61
In the order of fastest to most esoteric...

I'm clarifying a few spots in the readme in parallel with writing this.

Quote:
And the program is using that byte as loop counter, so it's 100% proof.

99% proof. Until I see a design doc for the glove, it's impossible to tell intentional vs convenient behavior, and particularly, at what value any undefined/error states begin.

Quote:
The "direction bit" in the 16bit opcodes doesn't match up with the readme.rtf - are you sure about "right/up/away-from-screen is positive
"? From the direction bit, I'd expect "right/down/away" being all positive (or all negative).

Just re-confirmed on glovetest, and that's the orientation I also used on Nesglovphone. Yes, that does mean Y is inverted from screen coordinates, and yes, that does mean you need to correct for it in your own code, but since this was WAY before the dominance of OpenGL and DirectX, I'm utterly unsurprised at it being a traditional math-class x/y plus right-handed Z.

Quote:
Aside from the "last 3 fingers" in Program 1, ring finger is also mentioned in Program E and G. Either the glove manual is wrong, or your glove is really broken - did you check it for shortcut & broken wire?

The cabling inside the frame is twisted something fierce, but I'm not going to chop up my glove for science. It does what I need it to, it's complete-with-box/docs, and I don't have a spare. Same goes for questions on the chip inside, although I do recall seeing a variety of "how to take your glove apart" docs in my own research which may have info on the innards, since iirc they do things like change the clock rate.

Quote:
So, Packet 0Ch must be something for detection and/or main menu controls.

It results in the glove not sending any data, so it's not a high-res mode. If it's used at power-on, then I'd say the likelihood is that it sets the glove to "listen" for other program commands.

Quote:
I am not too sure if "one extra" is really required.

I've tried reading precisely the requested number plus header. It makes the LEDs unhappy, so I wouldn't trust the read data with my life. If the code only uses the first 9 data bytes, either they got lucky or they're intentionally saving a read by knowing that the glove won't be ready for a few frames anyway.

Quote:
Code:
Documentation!!!!!11

Again with the "what's empirical vs conjecture and/or what sources are you finding??"
That's a lot of data to pull out of thin air, particularly if you're going to use it to challenge direct on-hardware testing. Also, you call my function descriptions confusing? ;)

Anyway...
if I read you right (and it would help to throw one or two concrete verified examples as context if you are going to dump that much data)
our canonical packet
Code:
06 C1 08 00 02 FF 01

reads as
Code:
06

6 bytes in the message
Code:
C1

header byte for the 16-bit commands. In binary,
1 - low-level / high-res mode
1 - 1/unknown
0 - (don't) configure for other games / survive power off (have you tested this??)
0 - 0/unknown
0001 - 1 16-bit command
Code:
08 00

16-bit command 0008, the 08 of which just happens to serve functionally as a mode selector per my own testing, the 00 of which remains unknown save for the fact that in my testing it seemed to have little if any effect unless the whole "opcode" was *F*F (*=wildcard). But according to your docs,
Quote:
Enable middle finger flex

or if you got your byte order reversed (which, honestly, I'd architecturally half-suspect; little-endian makes for much simpler chip design)
Quote:
usually 0

... enlightening.
Code:
02

2 8-bit opcodes/data; so far so correct
Code:
FF 01

I think my docs win here; interpreting those bytes as header/opcode makes very little sense.

BUT... now that I've gone through that exercise, I'm guessing you're probably deriving stuff based on your own use-case code observation of the programming packets, not the raw-mode inits. Which means analyzing the canonical packet is probably meaningless. But congrats on cracking the format, at least, because I think it still holds, and it makes great practical sense and good architectural sense, and it does line up with my observation... mostly... for parsing the raw-init.

Code:
06
bytes in the header
Code:
C1
high-res mode, 1 command. Although I'd put a question mark next to that "high res mode" since 1 positive example does not a specification make, and I've royally wrecked things with values other than C in that nybble.
Code:
08 00
who knows, just don't make it 0F0F or similar. ... *tries something* oh... Oh myyyyyyy... yes, very interesting! *notes to report later*
Code:
02
8-bit fields
Code:
FF 01
raw return field masks

Now that's a nice looking packet. But... *digs out aforementioned notes* it begs the question: why do we need 1 16-bit opcode? Isn't
Code:
04 C0 02 FF 01

a valid init string, assuming we're reading things right?

As it turns out... *drumroll* it is! (at least, on a warm re-flash)
BUT
there's a catch: the glove took it's dear sweet time to go back into an operating state. Meaning, speculatively, that nybble probably loads a countdown timer that moves on when it hits 0. And if it starts at 0, it resets to max on its first step and you need to wait for it. It seems odd that it would count that far without actually reading, though, so the fact that the glove still works when flashed that way from a prior good state may mean that somehow the prior-good values were never flushed because the glove went undefined. But it may mean that you can indeed have 0 opcodes and the glove correctly handles it, it just takes awhile.
...
*does another test*
Iiiiinterresting. Okay. Scratch half of that. On a warm re-init, the glove takes its time. On a "cold" re-init (unplug the glove and plug it back in while the NES is still running; given the bootloader on my flashcart I can't actually do a true cold start), it works quite quickly. So it may be one of those "better safe than sorry" dummy values just to fill a blank in the glove memory and prevent mildly-undefined behavior.

...

...

okay, if I've missed some things, I may need to come back later. Getting too distracted transcribing this stuff into the readme :)


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 29, 2012 7:54 pm 
Offline

Joined: Mon Jul 07, 2008 7:40 pm
Posts: 61
wait... that 0x01 in the $C1 is what I had as a mode selector, not the $0800.
Pay no attention to my discussion of those bytes in the prior post. Something odd is going on here- either the glove was already hot so $C0 and no "16-bit opcode" didn't actually change the operating mode, or else the operating mode defaults to my Mode 1, or else my fiddling with that nybble in prior testing caused it to read more or fewer subsequent bytes which just so happened to have mode-like effects in conjunction with other pre-heated config that didn't get overwritten, or... gah. This makes an amount of almost-but-not-quite-but-really-kinda sense that I'm going to need to test and sleep on.

_________________
Psych Software- failing to profit from retro/indie development since before it was cool
http://www.psychsoftware.org


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 29, 2012 8:38 pm 
Offline

Joined: Mon Jul 07, 2008 7:40 pm
Posts: 61
Okay. I still need to sleep, but I've tested enough to verify that nocash is on more the right track. After a canonical init, there are enough warmed values in the system that the low nybble of that 16-bit-header byte functions as a de-facto "mode switch" likely by "reading" more and more not-actually-provided garbage from the aether while never getting around to overwriting the 8-bit values, meaning the mask bits persist.

Likewise, when there is no 16-bit opcode provided, the most recent opcode used seems to persist even through re-plugs, yielding canonical behavior if the canonical 0x0800 was the last init.

This means I'm going to need to rewrite my test tool to accept FAR more bytes if I want to properly test all the functionality of the glove.

_________________
Psych Software- failing to profit from retro/indie development since before it was cool
http://www.psychsoftware.org


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 29, 2012 9:00 pm 
Offline

Joined: Mon Jul 07, 2008 7:40 pm
Posts: 61
... and upon further FURTHER one-more-idea-before-bed testing, no, even that's half wrong. Because when I go to $C2 for the header, say
Code:
06 C2 xx xx xx xx 00

which would technically be a valid 2 16-bit opcodes, 0 8-bit opcodes (keeping the old field masks), NONE of the bytes of what ought to be the "16-bit opcodes" seems to have any effect (other than, reading 2 opcodes, I can now jam the glove with 0x_F_F in the second opcode rather than just the first).

So my best remaining guess is EITHER
(a) in raw mode, that header nybble really ~is~ some kind of mode switch and the glove is smart enough to persist any existing setup even though it still half-heartedly reads and "processes" opcodes, or
(b) the glove persists enough setup that if you give it screwy/incomplete/nonsense opcodes, it doesn't completely break, but all the same its behavior is undefined if it doesn't get a good and full and complete packet with nonzero-length opcode blocks for everything.

And, although it makes NO technological sense given the wiring, peripherals should NOT be able to do this, I half suspect that something in the cached program on the glove causes the glove to somehow talk memory with the NES >.< I could swear the mysterious inexplicable sprite glitches I occasionally see in my glove demos have changed since I started throwing odd over/underdefined over/undersized packets at the glove, and one re-plug after a particularly tenuous config even caused my system to lock/reset for the first time since I got the glove (when I first plugged it in, it was a good dozen replug/resets before anything would run, even commercial titles).

_________________
Psych Software- failing to profit from retro/indie development since before it was cool
http://www.psychsoftware.org


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 30, 2012 1:22 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
Quote:
I do recall seeing a variety of "how to take your glove apart" docs in my own research which may have info on the innards

Aren't those docs just saying that it has "four screws"? Not the type of component list that I was looking for... I've spent hours on searching, and no matter what I was doing, the "best" results for glove+cpu have been Arduino, ARM, and Intel Dual Core. Well, and of course, that damn "four screws".

But wait, when I was more than endless frustated, I started guessing: Maybe a 8031/8051? That led to http://www.electrongate.com/wpd/page7.html Okay, Miracle Piano with 80C31 sounds just right, the SGS J004 is just that: a miracle (no clue what it is, but the piano is a different story).
And, a COPS888CL in the glove? Hmmmm, let's remove the "S" and "CL" then it'd be COP888, then we have this: Datasheets (eg. at http://www.datasheetarchive.com/), and two webpages that do actually talk about the glove:

Here, http://www.embeddedrelated.com/usenet/e ... 8004-1.php somebody has tried to extract the BIOS ROM from the glove - which seems to be difficult; so far it may be possible only by decapping the chip.

And a long mailing list log http://psg.mtu.edu/pub/tf/programming/gla-91o there's plenty of messy text in there, I haven't read all of it. Only Tim Deagan's cpu pinouts:
Code:
pin #   cop888                  PowerGlove
-----------------------------------------------
1       C2,I/O, , ,             INPUT C on 4021
2       C3,I/O, , ,             INPUT D on 4021
3       G4,I/O,SO, ,            ?
4       G5,I/O,SK, ,            DATA LATCH
5       G6,I,SI, ,ME            DATA CLOCK
6       G7,I/CKO,HALT RESTART, ,XTAL
7       CKI, , , ,              XTAL
8       Vcc                     +5VDC
9       I0,I, , ,               R1 pullup,SW8(Bdn),SW0,RGHT
10      I1,I, , ,               R2 pullup,SW9(Boff),SW1(Aup),LEFT
11      I2,I, , ,               R3 pullup,SW2(Aon),ENTER,DOWN
12      I3,I, , ,               R4 pullup,SW3(Bup),PROG,UP
13      I4,I, , ,               R5 pullup,SW4(Bon),START
14      I5,I, , ,               R6 pullup,SW5(SloMo),SELECT
15      I6,I, , ,               R7 pullup,SW6(Adn),B
16      I7,I, , ,               R8 pullup,SW7(Aoff),A
17      L0,I/O,MIWU, ,          R26 gnd,THUMB
18      L1,I/O,MIWU, ,          R27 gnd,INDEX
19      L2,I/O,MIWU, ,          R28 gnd,MIDDLE
20      L3,I/O,MIWU, ,          R29 gnd,RING
21      C4,I/O, , ,             ?
22      C5,I/O, , ,             SW0-7 & CENTER
23      C6,I/O, , ,             ENTER
24      C7,I/O, , ,             GND
25      L4,I/O,MIWU,T2A,        CLK on 4021
26      L5,I/O,MIWU,T2B,        RC net to LBlu,->|- red finger wires
27      L6,I/O,MIWU, ,          ?
28      L7,I/O,MIWU, ,          GRY from top of glove (XMTR2 ?)
29      D0,O, , ,I/O BIT 0      YEL from top of glove (XMTR1)
30      D1,O, , ,I/O BIT 1      GRN from top of glove (XMTR2)
31      D2,O, , ,I/O BIT 2      BLU from top of glove (BEEPER)
32      D3,O, , ,I/O BIT 3      PUR from top of glove (XMTR1 ?)
33      D4,O, , ,I/O BIT 4      INPUT E on 4021
34      D5,O, , ,I/O BIT 5      INPUT F on 4021
35      D6,O, , ,I/O BIT 6      INPUT G on 4021
36      D7,O, , ,I/O BIT 7      INPUT H on 4021
37      GND                     GND
38      RESET#                  ?
39      G0,I/O,INT, ,ALE        ?
40      G1,WDOUT, , ,           ?
41      G2,I/O,T1B, ,WR#        BRN to junct box (pin1 LM324 near rcvrs)
42      G3,I/O,T1A, ,RD#        ORG to junct box (RCs to LM324 nr rcvrs)
43      C0,I/O, , ,             INPUT A on 4021
44      C1,I/O, , ,             INPUT B on 4021

Note: The exact part number of the cpu seems to be unclear for whatever reason (maybe a custom variant, or maybe it's only a black blob?). The pin names in the middle column are as for a COP888CLMH, but Tim mentioned that the glove might actually use a different COP888xxx variant. Anyways, the overall pinouts are probably correct, and it looks as if he knew what he was doing.

Don't know if that info will be of any use. But I am feeling much better if I know what I am rev-engineering. The known chipset has now increased from poor 0 chips to at least 3 chips: COP888, 4021, LM324.


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 31, 2012 12:03 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 530
Quote:
traditional math-class x/y

Thanks for checking! Added glove emulation in my no$nes emulator yesterday (via dual-analog gamepad for X,Y,Z,Rotation axis). That also confirmed that your directions are correct (tested with the glove ball game).
The thing that was puzzling me was that the direction bits in 16bit opcodes don't match up with the sign bits of the analog values...
Oh, oh, oh, I think I got them all wrong, and left/right are vice versa in the opcodes! I have been using the Gyruss program description (from glove manual) as reference. It's a bit confusing, but essentially it does say "hand clockwise = ship clockwise = joypad left". But now it seems to me as if they got that wrong, and did actually mean "hand clockwise = ship anti-clockwise = joypad right".
The only other reference to left/right is the Knight Rider program description (which is actually vice-versa as the Gyruss one). And as third reference, treating 8bit opcodes as 81h=right and 82h=left would also better match to the bit-ordering in NES joypad shift register. And accordingly, in 16bit opcodes, bit2 would be 0=right, 1=left.
EDIT: I've EDITed the opcode descriptions (in the post from 24 Feb) that way; I hope left/right directions are now correct.

Quote:
Quote:
> Packet 0Ch must be something for detection and/or main menu controls.
It results in the glove not sending any data

What do you by "not sending any data"?
Do you receive all 00h bytes, or all FFh bytes, or something else?
Does the data change when pressing dpad/select/start buttons?

Quote:
I've tried reading precisely the requested number plus header. It makes the LEDs unhappy

Unhappy LEDs? I've never seen a glove in action, so I don't know how happy they can be... From the manual, in joypad-emulation mode, the upper four LEDs should indicate DPAD directions. And lower two LEDs are unclear: either the plain "rapid fire" PulseA/PulseB generators... or more probably: the Button A/B signals (ANDed with the pulse generators if they are used/enabled).

And in analog mode, the manual doesn't seem to say anything there. From Tim's pin-outs, the joypad shift register (4021) seems to be located right in the glove and then passed to the NES. If the LEDs are squeezed through the same shift register... then they should reflect the most recently transferred data bits. Does that match up with what you are seeing on hardware?

If you are reading the glove the "official" way: Last received byte in frames with packet should be 3Fh (error flags all good) of which LSB (Fh) would be upper four LEDs. And in frames without new packet available it should be... well, that "not ready byte" - which is STILL UNKNOWN, mind that!

Can you test what value that "not ready byte" has? Please!
At NMI: Read one packet (ready_byte=A0h, plus next 9 bytes).
At next NMI: Read one byte (not_ready_byte = has WHAT value?)
At next NMI: Read one byte (another not_ready_byte = has SAME value?)

EDIT: Another idea: Maybe there is no "not_ready" byte at all - and the glove just returns normal joypad data when it isn't ready. In that case, the byte should change when you press DPAD/SEL/STA/A/B on control pad... can you see any such effects in the "not_ready" byte?

Ah, and back to the LEDs. You could test the shift-register theory if you read the analog data in slow-motion (one bit per minute or so) then you should see bits moving this way: RightLED --> LeftLED --> LowerLED --> UpperLED.
Of course, such slow-motion might cause timeouts in the glove, so it may shift-in trash; but the bits that were already in the shift-register (before starting slow-motion transfer) should be still visible.
Or, to make things more simple: One could use a multimeter to check if the LEDs are connected to the joypad shift-register outputs.
EDIT: Or just cover the speakers/mics with your hand, and check if the Error Flag bits change the corresponding LEDs bits. Bit0=Right LED and so on.

Btw. do you have the Super Glove Ball game? And checked how the LEDs should "officially" look like in analog mode?

Quote:
survive power off (have you tested this??)

No, I still don't have a glove. The survive 30-second-power-off feature is described in the manual; and the bit is set only in packets that do use that feature. And you also mentioned something about "glove doesn't forget data until powered-off TWICE" or so. I guess the bit is causing that effect.

Quote:
or if you got your byte order reversed (which, honestly, I'd architecturally half-suspect; little-endian makes for much simpler chip design)

The command "cc" and data "dd" bytes just look nicer in 16bit "ccdd" form than in "ddcc" form. In reality, they seem to be two 8bit values. The 16bit notation is just for easy of discussion: "Bit15" is a bit shorter than "Bit7 of 1st Byte of the opcode".

Quote:
04 C0 02 FF 01

Risky. My theory about dummy opcodes was that there must be at least one opcode. With the long delay that you are getting, it sounds as like an 8bit counter decremented till zero; ie. treated as 256 opcodes in this case. Interesting that the glove survives it (I'd have expected it to fill RAM by 256 result bytes).

Code:
06 C2 xx xx xx xx 00

Risky, too. Maybe "06 C2 xx xx xx xx 02 yy yy" would be more stable. You could change the "yy yy" bytes, and then check if the glove does mask return values accordingly.

Quote:
the mysterious inexplicable sprite glitches

After adding the glove emulation yesterday, I started getting sprite glitches in your test program, too. A flickering character, usually showing up near middle of screen, and sometimes at other locations.
Must be a bug in your program - are you trying to access SPR-RAM outside of vblank, maybe?

EDIT: Did you check with no$nes vram viewer (or similar debugger)? You have 61 unused OBJs, two used OBJs with "2P" symbols... and one garbage OBJ (without glove emulation it's an "invisble" tile, located in middle of screen; the position changes "randomly" when you press joypad buttons; can been seen when moving the mouse on the lower-right OBJ cell).

---

Oh, and my experiences with Super Glove Ball & emulated glove: It works somehow strange.

First of, the game doesn't use the full 8bit range for X,Y,Z. Only these ranges:
Code:
X = -40h..+3Fh (128 steps, out of 256 possible steps)
Y = -28h..+27h (80 steps, out of 256 possible steps)
Z = -18h..+01h (20 steps, out of 256 possible steps)

This may be just subject to how the game is programmed - the glove itself does probably support full range of -80h..+7Fh (all 256 steps) on X/Y/Z ... right?

Btw. does the glove calibrate itself on farthest-seen X,Y,Z values? In similar fashion as how you've described it for flex sensors?

And back to Super Glove Ball. When moving the glove (or actually: my gamepad's analog sticks): The sprite on the screen goes terror. After some hours, I figured out that it's a bug in the game, not in my emulation.

Since the glove is too slow to return data in every frame, the programmer did have the "great" idea to interpolate data by moving the glove like so in each frame:
Code:
  HalfDistance = (GlovePosition - SpritePosition)/2
  SpritePosition = SpritePosition + HalfDistance

Now, how is it possible to get that wrong? It is possible:
Code:
  sbc  a,[xx]   ;parameters are 8bit unsigned, result is 9bits signed
  cmp  a,80     ;outch, treats bit7 as sign-bit
  rcr  a        ;make HalfDistance with garbage in sign-bit

Correct would be, of course:
Code:
  sbc  a,[xx]   ;parameters are 8bit unsigned, result is 9bits signed
  rcr  a        ;make HalfDistance, shift-in cy=(not sign)
  xor  a,80     ;fix inversion of sign-bit

If somebody wants to patch/bugfix the game, the opcodes are found at A52Ah (X) and A4EFh (Y).

In practice, the bugs show up as so: For X: FAST glove movements on RIGHT side, cause sprite to move in LEFT half of screen. And for Y: FAST movement from BOTTOM to TOP is ignored (the sprite STAYS at bottom of screen, no matter how much and how long you are moving up).

But, I am doing that FAST movements with a thumb-flip on the gamepad sticks, which is apparently faster than expected by the programmer. Maybe, you can't move the glove that fast in real life (unless you are Bruce Lee), and thus won't ever see the problem on real hardware...

Does somebody have the Super Glove Ball game & a glove, and can test if that fast-motion-bug appears on real hardware, too?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 02, 2012 3:27 pm 
Offline

Joined: Mon Jul 07, 2008 7:40 pm
Posts: 61
I was somewhat preoccupied last weekend and this work week, but I've finally had tome to start applying some of your findings. The glove devkit has been updated to allow init packets of up to 32 bytes and the readme has been substantially revised with a bit cleaner presentation of known info, a bit more thorough discussion of supposed info, and a new couple pages worth of your findings on the Program Mode.

Quote:
Unhappy LEDs? I've never seen a glove in action, so I don't know how happy they can be... From the manual, in joypad-emulation mode, the upper four LEDs should indicate DPAD directions. And lower two LEDs are unclear: either the plain "rapid fire" PulseA/PulseB generators... or more probably: the Button A/B signals (ANDed with the pulse generators if they are used/enabled).

And in analog mode, the manual doesn't seem to say anything there. From Tim's pin-outs, the joypad shift register (4021) seems to be located right in the glove and then passed to the NES. If the LEDs are squeezed through the same shift register... then they should reflect the most recently transferred data bits. Does that match up with what you are seeing on hardware?

If you are reading the glove the "official" way: Last received byte in frames with packet should be 3Fh (error flags all good) of which LSB (Fh) would be upper four LEDs. And in frames without new packet available it should be... well, that "not ready byte" - which is STILL UNKNOWN, mind that!

Can you test what value that "not ready byte" has? Please!
At NMI: Read one packet (ready_byte=A0h, plus next 9 bytes).
At next NMI: Read one byte (not_ready_byte = has WHAT value?)
At next NMI: Read one byte (another not_ready_byte = has SAME value?)

EDIT: Another idea: Maybe there is no "not_ready" byte at all - and the glove just returns normal joypad data when it isn't ready. In that case, the byte should change when you press DPAD/SEL/STA/A/B on control pad... can you see any such effects in the "not_ready" byte?

If there's a byte that returns the LEDs, I haven't seen it (and I did go looking, particularly when I noticed one field towards the very end of the return which changed roughly in sync with the LEDs). In raw mode, both when Glove Ball does it and when I do it, all 6 LEDs on the frame blink on and off in pretty-close-to-unison whenever the glove is polled. In program modes, they do reflect whether the glove has identified and is sending directional/A/B gestures.

And after you read the last field you asked the glove for in the init, the glove returns continuous FFs (post-inversion, so the raw line data would be 00s) until the header byte of the next packet. Hence my observation that when Glove Ball requests 9 fields but only reads 8 of them, that first read on the next frame is going to return the 9th field, and the read following that would either return the next header (if the glove is ready) or FF (more likely, since giving the glove only 3 frames for 9 fields is cutting it close).

Quote:
If you are reading the glove the "official" way: Last received byte in frames with packet should be 3Fh (error flags all good) of which LSB (Fh) would be upper four LEDs. And in frames without new packet available it should be... well, that "not ready byte" - which is STILL UNKNOWN, mind that!

"Error flags all good?" Where are you getting that? I see no evidence of a consistent final byte of the packet other than whatever field you ask for. The canonical glove ball packet asks for 9 fields, the last of which is the occlusion data- 2 0s and 6 bits which are 1 if the corresponding speaker-mic pairing is unobstructed.

Quote:
The survive 30-second-power-off feature is described in the manual; and the bit is set only in packets that do use that feature. And you also mentioned something about "glove doesn't forget data until powered-off TWICE" or so. I guess the bit is causing that effect.

Good observation. I never really saw the joypad-program modes as practically playable, so I didn't catch that level of detail in the manual.

Quote:
My theory about dummy opcodes was that there must be at least one opcode. With the long delay that you are getting, it sounds as like an 8bit counter decremented till zero; ie. treated as 256 opcodes in this case. Interesting that the glove survives it (I'd have expected it to fill RAM by 256 result bytes).

Actually, I spoke too soon when reporting that. I've gotten it with no delay now as well. But yes, I would advise at least one opcode in each block to avoid undefined behavior.

Quote:
Risky, too. Maybe "06 C2 xx xx xx xx 02 yy yy" would be more stable. You could change the "yy yy" bytes, and then check if the glove does mask return values accordingly.

There's commentary on this in the new readme. I'm now fully convinced the raw-init packet follows the same basic structure as the program-inits, but it's beyond me what the 16-bit opcodes do. What I was previously identifying as "program modes" were almost certainly the glove getting malformed packets of increasing insufficiency, and thus reading increasingly further into some internal memory bank and treating that cold-start garbage as opcode. But as soon as I start sending well-formed packets, even using the data from the malformed ones as a starting point, the glove goes into more or less its canonical raw operation. But the undocumented "mode" behavior does still appear to be deterministic once I let the glove cool and restart, so I'm kinda curious whether it's identical across all gloves or just a function of silicon manufacturing that will differ from unit to unit with the particular electrical properties at startup... Regardless, the fact that certain previously-dubbed "modes" contain complex-behavior fields like "gesture" which aren't present in the canonical configuration tells me there's something programmatic going on if only we could figure out what data is being used to engage it.

Quote:
EDIT: Did you check with no$nes vram viewer (or similar debugger)? You have 61 unused OBJs, two used OBJs with "2P" symbols... and one garbage OBJ (without glove emulation it's an "invisble" tile, located in middle of screen; the position changes "randomly" when you press joypad buttons; can been seen when moving the mouse on the lower-right OBJ cell).

I develop on Mac, so I work against Nestopia which is highly accurate but has no debugger. I do indeed use only 3 of the 64 hardware sprites- 2 are pointers marked "2p" (to suggest anyone who hasn't read the manual to try the 2nd controller) and the third, in canonical operation, will move in X/Y with the glove (remember as you implement your emulator that the data is 2's complement with 0 being center and -128 to 127 being the extremes), change tile from 0 through B with rotation, and change color with the status of the first few fingers. If you're only using joypad input, yes, movement will appear random because the joypad buttons will be read into every field the tester expects to contain glove return data.
The glitches I'm seeing are things like e.g. the red 2p sprite flickering by +/- 3 or so pixels every frame when ever the position-tracker sprite gets to certain areas of the screen. In Nesglovphone for awhile I had issues of sprites disappearing entirely. My first suspicion was overrunning vblank or not zeroing $2003, but what ended up solving the problem was changing which sprite indices I used. Which is frustrating, but leads me to think it might be an issue with the PowerPak devcart, which does claim to give some games sprite issues (and gives other games other issues which it doesn't even claim).

Quote:
Btw. does the glove calibrate itself on farthest-seen X,Y,Z values? In similar fashion as how you've described it for flex sensors?

I do not believe so. I don't know what goes on under the hood, but it seems to track fairly consistently wherever, up until it loses contact with the sensors.

Quote:
Does somebody have the Super Glove Ball game & a glove, and can test if that fast-motion-bug appears on real hardware, too?

I can get some odd wrap-around errors by e.g. holding the glove to screen-left and then slamming it right, but the glove always gets back to the right position within a few frames. Also of note, the glove-on-screen only uses the middle region of the screen, so it makes some sense that it would clamp the values after reading them.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 02, 2012 4:08 pm 
Offline

Joined: Mon Jul 07, 2008 7:40 pm
Posts: 61
Also, the COP888EK looks mildly promising. The CL datasheet I found lists that half-ish of the I pins are left dangling. The EK has a full set of I pins which double as analog comparator inputs (although that doesn't appear to be how they are wired to be used if your chart is right). At very least, it's interesting to notice that the I-pins, while mapped to button inputs, sound to be on analog pull-up circuits, which would be consistent with my quick-skim of the EK.

_________________
Psych Software- failing to profit from retro/indie development since before it was cool
http://www.psychsoftware.org


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 02, 2012 4:25 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19107
Location: NE Indiana, USA (NTSC)
LoneKiltedNinja wrote:
What I was previously identifying as "program modes" were almost certainly the glove getting malformed packets of increasing insufficiency, and thus reading increasingly further into some internal memory bank and treating that cold-start garbage as opcode. But as soon as I start sending well-formed packets, even using the data from the malformed ones as a starting point, the glove goes into more or less its canonical raw operation.

Once we figure out more about the glove's operation, this might end up being the beginning of a way to dump the internal ROM.

Quote:
I develop on Mac, so I work against Nestopia which is highly accurate but has no debugger.

FCEUX for Windows works without sound in Wine for Ubuntu. Does FCEUX for Windows work in Wine for Intel Mac?

Quote:
My first suspicion was overrunning vblank or not zeroing $2003, but what ended up solving the problem was changing which sprite indices I used. Which is frustrating, but leads me to think it might be an issue with the PowerPak devcart, which does claim to give some games sprite issues (and gives other games other issues which it doesn't even claim).

If you turn off rendering early at the wrong time, you might get problems with some sprites overwriting other sprites. I had issues with LJ65 on my PowerPak, and others had the same issues on their real hardware, until blargg figured out that turning off rendering early is safest just before hblank on a scanline with no sprites.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 64 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], Google Adsense [Bot] and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group