model2.cpp: Hooked some outputs (lamps, wheel)

[Endprodukt]

hooked some outputs for model 2 based on SailorSats work. Added definitions to output names for Lamps and wheel.

[angelosa]

Absolutely no at this. Just generate a function depending on what's the machine_config caller. So for example:

void model2a_state::srallyc(machine_config &config)
{
[...]
	io.out_pf_callback().set(FUNC(model2a_state::srallyc_outputs_w));
}

void model2_state::srallyc_outputs_w(u8 data)
{
     	m_output[1] = data;
		output().set_value("Lamp_Start", BIT(data, 2));
		output().set_value("Lampe_View", BIT(data, 5)); // Lampe?
		output().set_value("Lamp_Race_Leader", BIT(data, 7));
}

Beyond being ugly and prone to breakage, there are two extra reasons about why calling the base system name is a bad juju:

1. you are iterating for every single string compare;
2. the clones won't hookup anything (iirc);

[Endprodukt]

Clones do hook. Thanks for the feedback.

[Endprodukt]

@angelosa I hope these changes will make the integration of the code possible. Thank you again.

[Osso13]

Afaik set_value is deprecated and should be removed in favour of output_finder when encountered. Adding even more shouldn't be the way to go

[happppp]

output().set_value is deprecated.

Better use 6 generic lamps, like m_lamps(*this, "lamp%u", 0U)
Then just 1 function and set each one in a for loop.

How is the wheel motor shared with m_driveio_comm_data?

[Endprodukt]

Uff. Okay I'm tired for today. I did this exactly to avoid generic lamps and define them.

I didn't do the wheel hooks but they work.

[Endprodukt]

But defined outputs are not wanted? Will tell people straight what which output does.

[happppp]

Personal preference: generic output tags in most cases.
But if there's no reference internal .lay (or SVG screen) for the leds and such, then it's nice having comments in the source file explaining what each output is.

[Endprodukt]

@happppp changed to generic lamp output. if this works for you I will also fix the outputs for model2o.

[happppp]

Lamps are on bit 2-7, right? So it's i+2, not i. And you only need one function.
What is m_output for?

And I'm not a fan of "contact MAMEdev" popmessage. To be honest if it was me, I'd use logerror instead of obscuring the game screen. (note, my opinion here may differ from model2 driver authors)

[Endprodukt]

Contact mame Dev is not from me. Will fix the rest. I appreciate the time and patience.

[angelosa]

At bare minimum a popmessage is for something unlikely that needs some testing that triggers and reporting it to MT/as GH issue/to whoever is the driver maintainer. It doesn't need the contact MAMEdev suffix because it's implicit from the use itself (and should actually be removed from anything that still uses it).

Also, this goes beyond the scope of this PR.

[Endprodukt]

okay I think I got this.

[Endprodukt]

great now my changes conflict suddenly?

[happppp]

It means you rebased on an earlier revision and not HEAD of master git branch.

[happppp]

Again about m_wheel_motor, I don't believe it's at the right place.
It writes a command to the drivecpu, and it must be the drivecpu that outputs to the steering wheel ffb motor(s). If you currently don't know where/how it does that, best just remove m_wheel_motor for now instead.

[Endprodukt]

Comparing to model1 the same method is used to grab the force feedback values but I understand the problem now. Do you see a way however to output from the drive_board without calling it wheel and getting it accepted? Maybe making driveio_comm_data an output as it already exists?

[happppp]

I don't think it should send intermediate data to output.

[Endprodukt]

Please correct me if I'm wrong but isn't that exactly what model 1 is doing?

[happppp]

I'll take your word for it (didn't look). But just because another driver has a workaround/hack doesn't mean it's ok.

[Endprodukt]

as requested, removed wheel. hope that at least the lamps can now be merged.

[happppp]

indy500, sgt24h, overrev: Do those games have the drive I/O board? If so, it's undumped/unemulated in MAME, drive_board_w does nothing for these games.

[Endprodukt]

Over Rev and sgt24h are multi compatible. See service menu. All games give output here so I'm not sure what you mean.

[angelosa]

Jaleco games should be conversion kits, forgot of which off the bat (can't find an operator manual at current time).

[happppp]

indy500 has the one with EPR-18261 according to the manual (which is already in MAME's stcc romset).
I didn't find a manual for the Jaleco games. - is it the I/O TYPE A/B/C setting? That's going to be a bit annoying for MAME, if it needs a slot device for the force feedback hw. Or if the hw isn't that different, maybe a BIOS setting. Anyway, that's just a curiosity for now, not for this PR.

[Endprodukt]

Abc indeed. Lamps work on all 3 iirc. FFB is either 2 in one or based on the io boards.