tetrisp2: Implement MPEG video decoding for VJ's King Qtaro PCI video decoder card

[987123879113]

PCB pics for documentation (thanks @Shizmob): https://up.shiz.me/a/vj-visual-and-music-slap/ Seemingly the only clear gameplay footage available on the internet for this game for documentation/reference: https://www.youtube.com/watch?v=bjrhNC54h0o

pl_mpeg (an MIT licensed header-only MPEG-1 video decoder library) was added because each of the Qtaro subboards on the PCI card in the PC contains an MPEG-1 video decoder implemented in the FPGA bitstream.

There's a lot of TODOs left: The VIA chipset for the PC motherboard is not implemented so Win95 will ask for you to install the drivers for the "new" hardware on every boot. They use a boot script to restore the Windows configuration back to default every boot so it'll happen unless you manually remove that code or all of the required hardware is implemented. The PC is also underclocked for performance reasons. Better documentation of the PC side hardware in general is still needed (CPU, RAM, BIOS dump).

VJ and VJ Dash are playable if you get the PC side booting but there are still glitches due to video playback timings not being accurate (usually not a huge issue) and DMA timing issues (can result in videos starting or ending at the wrong time, and occasionally the sound doesn't load properly). Stepping Stage and VJ use the same general setup including the PC so I tried to also fix parts of Stepping Stage as far as I could test (which was not far). Stepping Stage uses a JSP dongle on the PC side so that is another hurdle for that game series (VJ doesn't have any dongles).

The existing dump of VJ Dash (ver 1.2) was also tested to make sure it was worked using the new data from VJ and the VJ Dash upgrade kit data, but I can't verify that the ROMs I had to fill in actually match with a ver 1.2 board so I didn't make it the main VJ Dash entry. One graphic ROM from the old existing vjdash entry was found to be different in a way that didn't suggest it might be a bad dump, for example.

[simzy39]

Just in case there are some things you can take from this PR and don't know about it, here: https://github.com/mamedev/mame/pull/8224

[cuavas]

Let me catch up on stuff and I'll take a look at this. If nothing else, non-contentious parts can be grabbed piecemeal.

[987123879113]

I'm aware of https://github.com/mamedev/mame/pull/8224 but I don't think there's anything that can be brought in from that PR aside from maybe the layout changes which I didn't notice the issues personally.

[cuavas]

Sorry to be annoying, but I cribbed a bunch of the code in 5a546932e2e5aca0450b1a00e5e96e3981804a29, but it’s going to cause conflicts. Release is sneaking up on us, and it’s better to at least have the updated ROMs and disk images in before freeze.

Some notes:

• I marked all the ROMs that were copied from the new set as BAD_DUMP as a precautionary measure. If there are ROMs that are guaranteed not to be different, the BAD_DUMP flag can be removed, but it’s best to flag ROMs taken from other sets.
• I cleaned up a bunch of K&R in an Allman file, and moved memory allocation/save state registration from an init function to machine_start where it belongs.
• Changes to i82371sb.{h,cpp} would blow up if anything actually uses set_cpu_tag – you need to ensure the subdevices are set up properly at config complete time.
• The 68k CPU implements byte smearing, so you should be able to just ignore the mem_mask in the tilemap memory write handlers. I’d expect the background tilemap behaves the same way (i.e. mem_mask should probably be ignored in tetrisp2_vram_bg_w). It’s quite possible the tilemap RAM is only eight bits wide, and it just writes whatever’s on the least significant byte on the bus irrespective of the selected lanes. Maybe the tile info member functions should be masking code_hi with 0xff?

I’ll get back to the PC side of this later.

[cuavas]

I’ve added the sound card and UPS in 47c281d0fc86ccfb00cf5f050afa85ed30790715. Once again, there were a bunch of the usual best practices things, in particular a bunch of read handlers not checking for debugger accesses. The biggest thing is that the driver needed far too much detail about the insides of the PC device. Things need to be encapsulated.

I assume it’s correct behaviour that vjdash now wants to wait for the PC before the game will run. I got step3 to the desktop, but the game screens were blank the whole time.

It’s possible I’ve messed something up in the refactoring, but it should at least be clear what direction stuff should go in.

Where do you want to go from here?

• Do you want to try merging master into your fork?
• Do you want me to merge master into your fork?
• Do you want me to merge your fork into a separate branch off master that you can pull?

[987123879113]

I'll handle merging it back into the branch so I can also test to make sure nothing is broken.

Yes, none of the games will be able to boot until all of the pieces are implemented. The vj.exe program on the PC side closes immediately unless the Qtaro card is implemented so you shouldn't even see that running on step3's HDD at this point. Same for the VJ HDD, it'll immediately close out of the main program if you do all of the hardware setup steps without the Qtaro card.

[987123879113]

@cuavas I made a new branch off latest master and pulled in the changes + did some refactoring (I followed the way you encapsulated the ISA sound device) for communication with the Qtaros/King Qtaro device. I gave vjslap and vjdash a quick go and they both working as expected for me now.

I responded to your DM with a link to a CHD diff that'll let you boot the games without messing with Win95 for testing purposes. It has the hardware already installed + modifies the autoexec.bat to disable the system restore on boot.

For step3 specifically, you need to use the maincpu ROMs from stepstag to have any chance of seeing anything other than a black screen. The game should work but you'll see an anti-piracy video rendered in the background because the JSP dongle check isn't implemented or patched out, and all of the songs should load to the same song/chart also due to anti-piracy. You should see the main VJ program stay on the screen now though. With the dongle check patched out you should be able to load some songs but nothing will match the in-game title because of the mismatched maincpu ROM. But it at least works for testing.

<mamecheat version="1">
    <cheat desc="Security Check Patch">
        <script state="run">
            <action condition=":jaleco_vj_pc:maincpu.pd@40317a==1bd8f766">:jaleco_vj_pc:maincpu.pd@40317a=000001b8</action>
            <action condition=":jaleco_vj_pc:maincpu.pw@40317e==40c0">:jaleco_vj_pc:maincpu.pw@40317e=9000</action>
        </script>
    </cheat>
</mamecheat>

[TopHat1989]

I know nothing about coding but I just want to get any of these games running. Just working sound in stepping stage or VJ would be enough for me but I see you actually made some Video Codecs, which is pretty impresive. I have the Full VJ rom and CHD set, Stepping Stage Special and Step3 roms and Step3 CHD, I don't know if any thing more is available. Can you give me some pointers about getting these games to run, even with issues. Just to get something more out off them besides black screens and Boot loops

[987123879113]

Unless you have additional dumps to share that aren't available in MAME already then you do not have the required data to run the Stepping Stage games. None of the Stepping Stage games have a full dump available currently. There are partial dumps but none of them are fully dumped and are all missing a piece of critical data. It's impossible to run them without seriously hacking around the games and someone capable of doing that should be capable of getting the games running already with everything provided.

I already mentioned in a previous post how to get the VJ games running. On the Windows side you need to install all of the requested hardware drivers during boot, and you also need to modify the autoexec.bat on the C drive to disable the code that'll restore the system registry and other such system states on boot so that the drivers don't need to be installed every time the game is booted. The required PC hardware isn't emulated in MAME and until it is then that step will be required for all of the VJ and Stepping Stage games.

You also need to use the code in this PR to even let the Windows side of the games to work properly otherwise the program running on the PC side will just shut down immediately and the arcade hardware side will get stuck waiting for the communication with the PC side.

It's best to just give up trying to run Stepping Stage anything until someone provides a full proper dump of at least one of the games. It's not a matter of "just" getting audio working. You need it all to get even just audio to work.

[TopHat1989]

Sorry for bothering you about it, but I still have one question. Would it be possible to play music from another file independent from mame? All of the stepping stage music is Available online

[987123879113]

There's no simple solution for you. Just get the PS2 version named "Stepping Selection" and play that if you really want to play a Stepping Stage game.

[simzy39]

Is this still ready to merge? It's almost been a year since it was open

[987123879113]

Code-wise it's still probably as good as it's going to get from me. I noticed there was a conflict so I just rebased against latest upstream master and tested to make sure it's still working using vjdash.

[987123879113]

Originally this was a large PR with a bunch of devices but now it's just the video code left, and the MPEG code in particular seems to be the source of delays so I split the code off into smaller commits. One is the base of the video decoder PCI card device code and the other is just the MPEG video stream decoding parts. The commits can be independently compiled and playable even with just the base commit. Also additionally added imperfect_features for timing issues since the 3 video streams can go out of sync sometimes.

[cuavas]

I cribbed the PCI card and cleaned it up a bit in 1b9cdb3f597adb22591175944f751ccb892fdfb4. I only tested that the thing validates and starts. It was mostly indented using spaces, so srcclean changed a lot of lines, causing the conflicts.

[987123879113]

Thank you. I've rebased the PR against latest master so now only the MPEG-TS decoder parts are left.