Main > Linux
Attempting to hack and document GunCon2 for Linux, FreeBSD, and MacOS X.
Numbski:
Default:
1111 1111 1111 1111 (FF or 255) - Control Pad and A,B, and C buttons
1111 1111 1111 1111 (FF or 255) - Select, Start, and Trigger (anything else?)
0000 0000 0000 0001 (01 or 1) - Unknown, suspect X-Axis
0000 0000 0000 0000 (zero) - Unknown?
0000 0000 0000 0101 (05 or 5) - Unknown, suspect Y-Axis
0000 0000 0000 0000 (zero) - Unknown?
So we have 6 octets (actually bytes...I'm used to saing octets from subnetting!). It could be that the buttons are 8-bit and the
X and Y axis are 16 bits each. 8-Bit has values of 0-255 for a total of 256 possible
values, whereas 16 -bit would be 0-65535, or a total of 65536 possible values.
I won't know for sure until I can hack up a little tracking program, but here's
the data I already have in binary notation, masked off by byte:
First, a lookup table to keep things simple for the binary-impared:
--- Code: ---0000 - 0
0001 - 1
0010 - 2
0011 - 3
0100 - 4
0101 - 5
0110 - 6
0111 - 7
1000 - 8
1001 - 9
1010 - A
1011 - B
1100 - C
1101 - D
1110 - E
1111 - F
The following has been edited. Thanks to Waremonger for correcting me on sig figs. :)
First Byte (Control Pad Nibble)
0111 1111 - Left - bit 8
1011 1111 - Down - bit 7
1101 1111 - Right - bit 6
1110 1111 - Up - bit 5
1111 1111 - Nothing Pressed
First Byte (Buttons Nibble)
1111 0111 - A - bit 4
1111 1011 - B - bit 3
1111 1101 - C - bit 2
1111 1110 - ? - bit 1
1111 1111 - Nothing Pressed
Second Byte (Select, Start, Trigger Nibble)
0111 1111 - Start - bit 8
1011 1111 - Select - bit 7
1101 1111 - Trigger - bit 6
1110 1111 - ? - bit 5
1111 1111 - Nothing Pressed
--- End code ---
So what it boils down to here is that all bits default to on, and
when a button is pressed, that button switches to a 0.
For example, up is 1110 (bit 1), and right is 1101 (bit 2), if I want up-right,
I get 1100, as the 1st and 2nd bits become 0's.
So....yay! It's starting to make sense. :) 2 bytes down, 3 bytes to go. :)
Numbski:
Okay, here's the status script I've hacked up. It displays the status in hex based on my original observation:
--- Code: ---#!/usr/bin/perl -w
use Term::Cap;
# What is the character device for the gun?
$guncon = '/dev/ugen0.1';
# clearing out our status...just in case.
$status = undef;
$value = undef;
if (!-c $guncon) {
print "$guncon is not a character device!\n";
exit;
}
if (!-r $guncon) {
print "$guncon exists, but you aren't allowed to read it!\n";
exit;
}
# See if we can figure out what your terminal speed is...
# We'll presume 9600bps if nothing else.
$OSPEED = 9600;
eval {
require POSIX;
my $termios = POSIX::Termios->new();
$termios->getattr;
$OSPEED = $termios->getospeed;
};
$terminal = Term::Cap->Tgetent({OSPEED=>$OSPEED});
#$terminal->Tputs('cl', 1, STDOUT);
$clear = $terminal->Tputs('cl');
# Try to open a filehandle to the gun character device.
print "Attempting to open gun at $guncon...\n";
open GUN, $guncon or die "Can't open $guncon : $!\n";
# Switch us to binary mode scotty! Read the status and print it.
while(1){
binmode GUN;
sysread(GUN,$status, 20);
foreach $value(split(//, $status)) {
printf("%02x ", ord($value));
}
$status = undef;
$value = undef;
print "\nPress Ctrl-C to exit\n";
print $clear;
}
--- End code ---
What it appears to be at this point is that the third byte is the horizontal axis, and the fifth byte is the vertical axis. I'm trying to figure out what the 4th and 6th bytes do now.
Numbski:
Ah ha... it looks like the 4th byte provides the third numerical place for the horizontal axis. When I wave the gun SLOOOWLY from left to right across the screen, the 3rd byte runs up very fast, and the 4th byte slowly counts 0-5. It doesn't look like the 6th byte ever changes, although in theory I guess it could be the 3rd placeholder for the vertical axis. Perhaps I can use the other two drivers as a reference for determining sane values there and adjust the script to return actual X/Y values along with only returning what buttons are really pressed?
Numbski:
Okay, latest version of my script. If anyone else could test this it would be much appreciated! Just want to make sure I'm not barking up the wrong tree. That, and the value of horizontal2 is something of an oddity. I'm just not getting consistent results.
--- Code: ---#!/usr/bin/perl -w
use Term::Cap;
# What is the character device for the gun?
$guncon = '/dev/ugen0.1';
# clearing out our status...just in case.
$status = undef;
$value = undef;
# Define our byte hash
$byte{ '0' } = 'Buttons1';
$byte{ '1' } = 'Buttons2';
$byte{ '2' } = 'Horizontal1';
$byte{ '3' } = 'Horizontal2';
$byte{ '4' } = 'Vertical1';
$byte{ '5' } = 'Vertical2';
if (!-c $guncon) {
print "$guncon is not a character device!\n";
exit;
}
if (!-r $guncon) {
print "$guncon exists, but you aren't allowed to read it!\n";
exit;
}
# See if we can figure out what your terminal speed is...
# We'll presume 9600bps if nothing else.
$OSPEED = 9600;
eval {
require POSIX;
my $termios = POSIX::Termios->new();
$termios->getattr;
$OSPEED = $termios->getospeed;
};
$terminal = Term::Cap->Tgetent({OSPEED=>$OSPEED});
#$terminal->Tputs('cl', 1, STDOUT);
$clear = $terminal->Tputs('cl');
# Try to open a filehandle to the gun character device.
print "Attempting to open gun at $guncon...\n";
open GUN, $guncon or die "Can't open $guncon : $!\n";
print "$guncon opened successfully. Proceeding to read...\n";
# Switch us to binary mode scotty! Read the status and print it.
while(1){
binmode GUN;
sysread(GUN,$status, 6);
$i=0;
$value=undef
$tempvalue=undef;
# Our bytes are split and handled individually...
foreach $value(split(//, $status)) {
$tempvalue = sprintf("%08b ", ord($value));
print "$byte{$i}:\t$tempvalue\n";
$i++;
}
$status = undef;
$value = undef;
$tempvalue=undef;
print "\nPress Ctrl-C to exit\n";
print $clear;
}
--- End code ---
Numbski:
It occurs to me that bytes 3 and 5 should probably default to 0 and not 1 and 5. :) I'm wondering if I shouldn't adjust my script to autmagically substract 1 and 5 from the reported values? Or does someone know if that's an expected behavior? Also, it looks like the upper-left corner of the screen is 0/0. It jumps straight from 5 (00000101) to 00010011, or 19 on the vertical axis. Horizontal it jumps from 1 to 22 (00010110). So who knows...that's probably why you have to use a calibration routine...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version