nbla000
Posts: 4
Joined: Fri Aug 14, 2020 4:58 pm

buggyboy and buggyboyjr (tx1.cpp) artwork steering problem.

Hi, this is my first post here so I wish to tanks all the people involved in mame developing for your valuable work! thank you very much.

I've released (just for fun) some mame artwork with animated elements for Outrun, hangon and shangon at the moment, they will be in the Mr. Do MAME IN-GAME ARTWORK page but until then you may temporary download here

Now I'm working on buggyboy / buggyboyjr / speedbuggy artwork also with animated elements (steering and gear) and I think there is a problem with the audio driver (tx1.cpp) for the steering output.

The problem for me is that the steering should report a value from $0 to $ff (0-255) but it reports a value from $0 to $0f (0-15) both for buggyboy and buggyboyjr while is correct for tx1 (same driver).

By looking the code ( tx1.cpp) there is the answer, for me there is a typo.

This is the portion of code for tx1 (rows 483,484)

Code: Select all

PORT_START("AN_STEERING") PORT_BIT( 0xff, 0x00, IPT_DIAL ) PORT_SENSITIVITY(20) PORT_KEYDELTA(6)

While this is the portion of code for buggyboy (rows 957,958)

Code: Select all

PORT_START("AN_STEERING") PORT_BIT( 0x0f, 0x00, IPT_DIAL ) PORT_SENSITIVITY(25) PORT_KEYDELTA(25)

and this is the portion of code for buggyboyjr (rows 1047,1048)

Code: Select all

PORT_START("AN_STEERING") PORT_BIT( 0x0f, 0x00, IPT_DIAL ) PORT_SENSITIVITY(25) PORT_KEYDELTA(25)

To prove what I say, i've released a test artwork for both tx1 and buggyboy, by going on service mode, you may test the steering value that is for both $0-$FF in the service screen but the artwork reports $0-$f for buggyboy (and buggyboyjr too) while is correct for tx1.

I don't know if is a typo as I think, is there someone that may confirm or not what I think and if there is a problem, I don't know how to report this information to developers, is this post enough or there is another way?
Attachments
tx1.zip
steering test artwork for tx1
(1.72 KiB) Downloaded 1 time
buggyboy.zip
steering test artwork for buggyboy
(1.72 KiB) Downloaded 1 time

User avatar
cuavas
Posts: 77
Joined: Tue Nov 11, 2014 1:04 pm
Location: Sydney, Australia
Contact: Website

Re: buggyboy and buggyboyjr (tx1.cpp) artwork steering problem.

A range of 0-15 with sensitivity and key delta of 25 does seem suspicious. However, I think the problem is the sensitivity and key delta being too high, while the range is correct. Note that that TX1 and Buggy Boy are not identical hardware.

Note the code here for Buggy Boy and Buggy Boy Jr: https://github.com/mamedev/mame/blob/ma ... 1.cpp#L185

These games read the analog inputs through a quad 4-bit ADC chip that packs two values into each byte. The steering value appears in the low four bits and the accelerator appears in the high four bits. If you increase the range of the steering input, half the bits will be discarded and the game won’t work.

Note the code here for TX1: https://github.com/mamedev/mame/blob/ma ... 1.cpp#L216

The steering value is read via an 8-bit PPI port, giving it a larger range.

If anything, the sensitivity and key delta for Buggy Boy should be reduced if it makes the games more playable. You’ll need different layouts to deal with the different input ranges TX1 vs Buggy Boy.

nbla000
Posts: 4
Joined: Fri Aug 14, 2020 4:58 pm

Re: buggyboy and buggyboyjr (tx1.cpp) artwork steering problem.

Thanks for your explanation, I understand your point of view but what I don't understand is why then in the service screen (F2 from Mame) the rom program reports a steering value from 0$ to $ff

There is a documentation where to check? and if the drivers is correct then there is a way to read the service screen value ($0 -$ff) from an artwork or I have to give up to steering simulation of my artwork? just 15 values for 360 degrees is no realistic.

User avatar
cuavas
Posts: 77
Joined: Tue Nov 11, 2014 1:04 pm
Location: Sydney, Australia
Contact: Website

Re: buggyboy and buggyboyjr (tx1.cpp) artwork steering problem.

The value you see in service mode is an accumulated count produced by the software. It’s not showing the last raw count it read there.

I think you may be misunderstanding how a “360° wheel” actually works. It doesn’t report its position at all, it produces a stream of pulses when you turn it and the system counts pulses to determine how far the wheel has been turned. The I/O port values are the raw counter output. Buggy Boy only has a 4-bit counter, so if you manage to spin the wheel far enough in either direction (more than eight pulses) between the game reading it and updating its accumulated value, the counter will overflow and steering will behave erratically.

It’s like a spinner or one axis of a trackball.

nbla000
Posts: 4
Joined: Fri Aug 14, 2020 4:58 pm

Re: buggyboy and buggyboyjr (tx1.cpp) artwork steering problem.

I suspected that there was a software "manipolation" so unless we have on layout syntax a sort o system counter too that simulate the software and not only the hardware, there is nothing we can do to simulate the steering rotation for buggyboy/buggyboyjr while is possible for tx1 of course as I dimostrated on the attached test artwork.

Many thanks for your info.

Return to “MAME Discussion”