First of all: thank you for the clear explanation and for the time spent for me (grazie mille!).
Sorry for the delay, but i had to study your previous answer before posting just to avoid stupid questions
This is the latest code tested:
Code:
static READ32_HANDLER( port1_r ) { static UINT8 cur_view = 0; UINT16 viewval = readinputport(1); //total actual values stored in memory UINT8 button_pressed = viewval & 0x0010;
if (!button_pressed) // check if button is pressed { cur_view++; if (cur_view == 4) cur_view = 0; } viewval = (viewval | 0x0010) & ((button_pressed | 0x00ef) << cur_view); // remove the fake view button bit and add the correct view bit to the input return (viewval << 16) | viewval; }
Now, with this code somehow works even if it doesn’t cycle in a predictable way, and there’s some interaction with the “radio” button: it’s also pressed when the view button is pressed (I know, it is almost impossible for you to write a working code without compiling and testing, but this “trial and error” is helping me understanding something more on this so please keep this up even if frustrating).
Before proceeding with welcome new checks, help me understand a thing that for sure will help solving the “radio button press” problem: how can I say that bits 4-7 are those where the view selection are changed? Is it related to the declarations in the INPUT_PORTS_START region of the driver? Consider that the (partial but of interest) code is:
Code:
PORT_START PORT_BIT( 0x0001, IP_ACTIVE_LOW, IPT_UNKNOWN ) PORT_BIT( 0x0002, IP_ACTIVE_LOW, IPT_BUTTON6 ) PORT_NAME("Radio")/* radio */ PORT_BIT( 0x0004, IP_ACTIVE_LOW, IPT_UNKNOWN ) PORT_BIT( 0x0008, IP_ACTIVE_LOW, IPT_UNKNOWN ) PORT_BIT( 0x0010, IP_ACTIVE_LOW, IPT_BUTTON2 ) PORT_PLAYER(2) PORT_NAME("View Change") /* view 1 */ PORT_BIT( 0x0020, IP_ACTIVE_LOW, IPT_UNUSED ) /* view 2 */ PORT_BIT( 0x0040, IP_ACTIVE_LOW, IPT_UNUSED ) /* view 3 */ PORT_BIT( 0x0080, IP_ACTIVE_LOW, IPT_UNUSED ) /* view 4 */ PORT_BIT( 0xff00, IP_ACTIVE_LOW, IPT_UNUSED )
Then, going to a basic level and taking visual advantage from the following table:
Yellowed is the memory region we are dealing with (that’s where view button presses are detected) and question marked areas are those we want to keep unchanged (because controlled by other buttons and rely with other things). Considering that the other “view button press” (view 2, 3 and 4) positions are located in memory 0x20, 0x40 and 0x80, shouldn’t I conclude that the first 4 bits are those related to view presses and not bits 4-7? Isn’t the 0x0002 bit the same of 0x0020 and couldn't this be the culript of the radio button interference?
|