Implement namco specific commands (was 'MKGP DX not working')

[Rolel]

Hello,

MarioKart GP DX (ES3 system) is not working correctly with firmware up to 2.22 (at least).

Observed behavior:

• When defined as the wrong vendor (let's say SEGA), the JVS detection will not pass ("checking" message endlessly). But with this setup you can press "TEST" and navigate the service menu without any issue. Board is detected, buttons, analog, coins, everything works.
• When you declare the correct vendor (NA-JVS) then it pass the detection and the game runs. BUT, the JVS is not working - test/service/button, nothing works.

This game is known to send "custom" JVS commands and I suspect it causes this issue.

Regards

[toyoshim]

Oh, well. Yeah, it will be probably because of the custom commands, and it may be difficult to solve the problem unless I get a working board. I saw a similar problem when I tried the starwars. It started sending custom messages when they recognized the connected I/O is namco JVS. So, the same thing happens when you set NA-JVS.

[Rolel]

I understand.
May I be of any help by dumping some command ? Would it be possible to configure one of the USB port to be a serial terminal so I can log what happens ?

Also I confirm Starwars have the same behavior, but not too surprising as it's the same IO and same system.

[toyoshim]

Well, I need trials and errors to seek acceptable responses to the unknown commands even if we can know the command sequence. If we can have a complete trace of a successful sequence by an official IO, that would help, but I may still need some inspirations...

[toyoshim]

Good news here.
I just found this document; http://daifukkat.su/files/jvs_wip.pdf
This doesn't seem a straight-forward translation from the original spec written in Japanese, but also contains some vendor-specific commands.
So, I may try implementing these namco commands in the future.

[Rolel]

It's handling an extended subcommand (0x18) within command (0x70). This is likely the only proprietary extension to the standard JVS protocol that is used in these NAmco games.

Based on some code I got, a parsed JVS Namco extended command packet (0x70, subcommand 0x18) appears to follow this structure:
[CMD (1 byte)][SUBCMD (1 byte)][HARDCODE (2 bytes)][PARAM (2 bytes)][DATA...]

Fields Explanation:

CMD (0x70):

• The main command identifier.
• Indicates a proprietary or extended JVS command specific to Namco.

SUBCMD (0x18):

• A subcommand, further specifying the operation or action to take.
• Suggests a category or subtype of the extended command.

HARDCODE (0x504C):

• Appears as a fixed magic number or identifier used for validation.
• Possibly acting as a marker to identify the start or confirm the validity of this specific extended command.

PARAM (2 bytes):
A parameter indicating the exact nature or purpose of the command.
Some observed values:

• 0x14D0: Indicates a request to read a string or information.
• 0x14B4 and 0x143C: Trigger a special "run it back" behavior, which repeats the read of command bytes again.

DATA (variable length):

• Additional data payload (present in the case 0x14D0).
• Length is computed as (total request length - 9 bytes).

Specific Observations about param Values:
param = 0x14D0

• Performs a string/data read operation.
• The code reads an arbitrary-length string (info) from the incoming buffer and prints it.
• Returns a status byte (0x01) to acknowledge success.

param = 0x14B4 or 0x143C

• Repeats a similar parsing routine (reads command bytes again: cmd, subcmd, hardcode, param).
• Potentially used for command confirmation or retransmission behavior, possibly as a handshake or verification.

Default Case:

• Handles unrecognized or unsupported values by printing an error message and dumping the buffer's content.
• Still returns a positive acknowledgment (0x01) even when unknown parameters appear.

I hope this helps.