MAMEWorld Forums - Programming - Re: Need help with Cruis'n World driver

> I checked the new code and there still are the same problems: the button is seen as
> being repeatedly pressed and released. With the new code, anyhow, it works somehow: i
> can cycle between the views, even if the view button press is not recorded all the
> times.

whoops, I have just notice a mistake in the "removes the fake button and adds the correct button". the code was ok for IP_ACTIVE_HIGH but not IP_ACTIVE_LOW, sorry. try with this line, instead

Code:

viewval = (viewval | 0x10) & ((button_pressed | 0xef) << cur_view); // remove the fake button bit and add the correct view bit to the input

> Essentially, if i am correct, we are dealing with a 4 byte long memory region in
> whitch the current view AND the button position is stored, right?

well no (or better not exactly). maybe the easier way to see this is from the perspective of the game itself: the game knows (because it has been programmed in that way) that at the memory location where "port1_r" (the memory handler we are modifying) is located he will find a 32bit value such that
* bits 0-15 are equal to bits 16-31
* bits 4-7 (and its copy 20-23) are "1" if no view button is pressed, or contain a single "0" if one of the view buttons is pressed

hence the game keeps checking those bits and depending to the position of the "0" (if any), it chooses which view has to be displayed. so for MAME those bits are just the input bits and it depends on the game code how the bits get interpreted

therefore the original code does the following: it reads the 16bit inputs from your controllers and returns it in the 32bit format expected by the game, i.e. copying the value both in the lower half of the number *and* in the upper half (in the real cabinets, it would be the wiring between the PCB and the controller of the cabinet to communicate the proper values)

since we want to have a single button cycling through the views, we have to intercept the input bits and modifying them before they "reach the game"

>
> i.e how this line:
>
> UINT8 button_pressed = viewval & 0x0010;
>
> defines a button press? because only if the two values are the same it will return
> 0x0010?
>

viewval is the whole value of the inputs: bits 4-7 for the view buttons, bits 0-3 might have different functions, like accessing service mode or whatever (we don't care about them here, but in the end we have to send them unmodified to the game, to be sure we don't interfere with the process... that's why at the end we return "(viewval)<<16 | viewval")

with the original code, we could check: bit 4 (masking & 0x10) to see if the first view button has been pressed; bit 5 (masking & 0x20) to see if the 2nd view button has been pressed; bit 6 (masking & 0x40) to see if the 3rd view button has been pressed; bit 7 (masking & 0x80) to see if the 4th view button has been pressed.

with our modified code we only have a single button, so bits 5-7 of viewval are always "1" (nothing can be pressed by the user since you put IPT_UNUSED in those bits

) and only bit 4 can change between "0" and "1"

so "viewval & 0x10" will be "0x10" if bit 4 of viewval is "1" (i.e. button de-pressed) and will be "0x00" if bit 4 is "0" (i.e. button pressed). so, rather than "defines a button press" the code "detects a button press"

the definition is in the input port of the driver

the game anyway still expects that different view buttons are communicated in bits 4-7 not only 4 (we never modify the game code here, just fake the data that get sent), that is why we need the "if" part which counts how many times you have pressed the (now unique) view button so that we can later put the "0" in the right bit corresponding to the view button we want to be pressed.

> How this line
>
> viewval = (viewval & ~0x10) | (button_pressed << cur_view);
> removes the fake button and adds the correct button?

premise, this code was only correct for my original interpretation of "1" button pressed and "0" button de-pressed, so I will explain all the three versions of this line to (hopefully) shred some light on the bitwise ops

what the line you quoted did is to:
- set bit 4 in viewval to zero, which I thought it was button de-pressed, by masking with ~0x10=0xef (all bits 1 except for bit 4)
- "add" the button_pressed bit (which is bit 4 only, in our modified code) shifted of the proper amount of bits, because the game expects it to be in bits 4-7 depending on the view button (the "or" operator ensures that if button_pressed was 0x10, the one is put in the right position and the other bits remain 0)

my later proposal to cope with the right interpretation of "1" button de-pressed and "0" button pressed was

> viewval = (viewval | 0x10) & (button_pressed << cur_view); // remove the fake button bit and add the correct view bit to the input

which does basically the same as the original with inverted 0-1. namely,
- set bit 4 in viewval to 1, which is button de-pressed, by using "| 0x10"
- try to add the button_pressed 0 in the correct position

the problem in this code is that if we pressed the button, button_pressed is not only zero in bit 4 as we would like, but also in bits 0-3 and 5-7 (you remember that button_pressed was only 0x00 or 0x10, right?

), so when we shift it we send not a single "0" (i.e. a single button pressed) as we would like, but multiple ones.

the final version of the code (the one at the top of this reply) attempts to fix this by adding to button_pressed all other bits as "1" so that only a single zero gets set

I hope this was of help