Mag truck

[gm_matthew]

My hack basically forces the camera to look away from the origin (0.0, 0.0, 0.0); no real reason for this other than preventing the division by zero that breaks 3D rendering. I think the camera position is being updated correctly, but rather the issue is the camera not tracking the correct object for some reason, at least not during the "how to play" sequence.

I can report that if I keep putting the hack in for the "how to play" sequence and removing it again after it finishes, the rest of the attract sequence seems to play perfectly.

[Ian]

It's weird, the actual camera position seems correct. Ie as in the attract mode from the real h/w the camera moves in front of the truck thing. Your video does the same, only the angle is off since you just fed it zero or whatever.

I had speculated some time ago that the dump could have been bad, since the Nan values ended up everywhere. But it seems maybe just 1 wrong subtraction could be causing it. It could just be 1 flipped bit reading wrong register or something. Unfortunately the game doesn't have any sort of internal crc check if I recall, plus it's a rare game so the chance of a redump is small.

[gm_matthew]

I am proud to announce that I have once and for all figured out the cause of the bug, and it's a bad dump.

At 0x91a18, the game attempts to convert the integer from 0x1678b0 to a floating-point number using a magic double (0x4330000080000000), and then save the result to 0x22db68. It's supposed to write 0x43300000 and 0x80000000 consecutively to the stack and then use the lfd instruction to load it into f13, but the instruction at 0x91a34 writes 0x43300000 to the wrong location because it uses the wrong register as a base (r30 instead of r31), so the lfd instruction ends up loading garbage. This has the net effect of setting the float at 0x22db68 to -4503601774854144, which spoils the y-value of vector 0x24f460 and subsequently messes up the calculations used to determine where to point the camera.

Changing instruction 0x91a34 to 0x917f0068 ensures that the correct address is written to and the magic double is successfully loaded into f13, and the bug is completely fixed.

I'll add the patch to Games.xml as everyone will currently be using the bad ROM.

[Bart]

I am proud to announce that I have once and for all figured out the cause of the bug, and it's a bad dump.

At 0x91a18, the game attempts to convert the integer from 0x1678b0 to a floating-point number using a magic double (0x4330000080000000), and then save the result to 0x22db68. It's supposed to write 0x43300000 and 0x80000000 consecutively to the stack and then use the lfd instruction to load it into f13, but the instruction at 0x91a34 writes 0x43300000 to the wrong location because it uses the wrong register as a base (r30 instead of r31), so the lfd instruction ends up loading garbage. This has the net effect of setting the float at 0x22db68 to -4503601774854144, which spoils the y-value of vector 0x24f460 and subsequently messes up the calculations used to determine where to point the camera.

Changing instruction 0x91a34 to 0x917f0068 ensures that the correct address is written to and the magic double is successfully loaded into f13, and the bug is completely fixed.

I'll add the patch to Games.xml as everyone will currently be using the bad ROM.

Wow that is an incredible find! If it's a bad dump though I would expect more corruption in there somewhere. I feel like we need to contact someone on the MAME team to report Magical Truck Adventure as a bad dump.

[Ian]

There could well be more bad bits in there. But if you think about it game code is probably like 5 or 10% of the total file size. It's usually textures, models and audio that eats the space. Textures especially you might not even notice a few bits randomly being flipped.

How or who do we report a bad dump to at mame?