Bubble Trouble (bubbletr) diorama/scoreboard setup #9733
Conversation
There was a problem hiding this comment.
This isn’t acceptable for three reasons:
- These game type hacks in drivers are a liability, and we’re trying to get rid of them, rather than add more of them.
set_valueis going to be removed in the future due to problematic semantics. Outputs need to use output finders.- The shared memory hack doesn’t reflect how the game actually works, and we don’t want to add more of them.
My gut feel is that the I/O microcontroller is missing some interrupt where it would be setting the outputs. I’ve had a quick look at it a couple of times, and unfortunately it isn’t something that jumps out immediately.
|
Thank you for reviewing. I see. With my current knowledge, I can offer no changes to this pull request that will lead to it being accepted. Hopefully, the outlined issues can eventually be resolved. This game is quite interesting to see in action. Users of MAMEdev MAME should be able to use an appropriate image to get a static diorama background that lacks the dynamic pieces. |
|
While it still wouldn't be ideal from a technical point of view, this could still be done without copy+pasting the ugly code. The only technical difference is that Bubble Trouble has one less piece, the only reason for the copy+pasted code is because different hardcoded names for each piece have been used. More generic names in the artwork elements would allow for the exact same code to be used, without making MAME 'worse' by copy+pasting already unwanted code. This would also likely be preferable even if the driver is switched to finders. There are 8 main output elements in the function, you could just name them 'diorama0' 'diorama1' etc. and use an output finder array. This would of course require the Golly Ghost artwork files to be updated. It wouldn't solve the underlying issue of the code not representing the hardware, but it would mean that everything still 'just works' once that is fixed at some point, rather than adding additional game specific code that will need deleting. |
|
@StormedBubbles I agree with David. |
|
@happppp probably worth sub-classing it too so that if( m_gametype==NAMCOS2_GOLLY_GHOST ) can go away, and the output finder + functions become specific to a namcos2_diorama_state |
|
Yup, that's my plan, subclassing Golly Ghost. |
@happppp I'm happy to make any changes as necessary to the artwork layout file. Please let me know what will need to be done. 👍 |
|
The commit is here: 7c67c12 You can use the updated gollygho layout file as a basis. I uploaded it to the MAME artwork forum on MAMEWorld: |
|
gollygho_default.zip |
|
Based on my reverse engineering, doing this absolutely properly, without the DPRAM hacks, would entail adding UART support to the M37450 core, something quite far beyond what a first-time contributor might be expected to provide. (Yes, these games need a second MCU of that type besides the C68, and despite the mismatched copyright dates, C65 won't work here.) |
|
So you're saying there's probably an undumped MCU in the Diorama that the one on the NS2 board communicates with? |
|
No, the dump for this second M37450 is already provided in the set. It just isn't at all what it's currently mapped as (supplemental code for a HD63705 I/O MCU). |
|
Ah right, is it possible this doesn't even have the C65 at all, and has that MCU instead, with external program only, performing the same role? The information on a lot of these boards was awful, not helped by some people saying certain boards were identical to ones they weren't identical to (as I found when fixing Final Lap) We know for some of the other Namco boards they sometimes used unprogrammed MCUs running in 'external' mode before giving them a Cxx part number. |
|
What I'm saying is, yes, it looks like it needs C68 rather than C65, but with its customary internal program. (C65 won't work for this case, at least not with the standard Namco program; it's worth noting that it uses the optional external ROM to override interrupt handlers and such.) The "external" MCU dumps in the set are for a separate M37450 running in ROMless microprocessor mode; this code wouldn't work for the I/O MCU itself because it doesn't access the DPRAM directly. I also did a comparison of UART interfaces on various Mitsubishi MCUs, since I know that their M16C series (which is currently represented in MAME only by NO_DUMP entries for unextracted internal code) inherited some of the 7700-series peripherals. Unfortunately, it seems Mitsubishi kept rearranging the control and status registers and adding extra modes (M37450 might even be their first original MCU to have a built-in UART), so the M37450 serial interface isn't fully compatible with much else other than the 3800 group. |
|
The mystery continues: PCB photos of Bubble Trouble show that the I/O MCU is definitely C65, not C68, so this is probably likewise the case for Golly! Ghost. However, the socket next to it is populated with some version of the "SYS C65" EPROM; though this was never dumped for either game, it likely solves the mystery of the incompatible serial communications. Either way, the extra M37450 dumps cannot possibly have come from a main System 2 board, since the filenames for those have the extension ".ic7", which does not identify a position there. |
|
Did you check the original archives from when Golly Ghost was dumped? One thing I did find in the past when studying Namco drivers is that often alt sets and unused ROMs didn't get added at all, even when they were dumped. It sounds like ic7 is from some kind of extra IO board then? |
|
The PCB pics of Gholly Ghost shows a C68, I believe (it's a bit blurry). |
|
That appears to be one that's running Bubble Trouble |
|
Right, sorry. Gholly Ghost 2 Bubble Trouble. |
|
So it could be that Bubble Trouble (from 1992) has the newer base board with the C68 (C68 internal ROM shows a copyright date of 1991) while Golly Ghost (from 1990) used the older base board with C65 (and an extra ROM for it, that's missing?) At least the photos confirm that IC7 is on a separate board, which it is presumably communicating with. I'd guess this board takes the simple on/off commands and drives the motors with them to move the elements. As I said, I think it's worth having a look at the original ROM archive for Golly Ghost if it's still around, it would not be the first time an unused ROM did not get added to a Namco set, or it might confirm it matches something else. |
|
I've looked back at some archives, and found Phil Stroffolino saying this about Golly! Ghost! in 2001:
So it appears that at least some Golly! Ghost! PCBs were indeed produced with C68. I think this is like the 10 MHz/12 MHz issue on CPS 1, where the manufacturer revised the main board at some point and placed some of their older games on it as well. The photo of the drive PCB is indeed helpful; it even provides an XTAL value (9.8034 MHz). |
Hello,
Thanks to the tremendous efforts of @Widge-5, who meticulously restored the Bubble Trouble diorama artwork from YouTube footage of the game and constructed a corresponding MAME lay file, it is now possible to play Bubble Trouble (bubbletr) with a full, moving undersea-diorama setup with these code additions.
Widge's video explains the restoration process, shows the working diorama, and has a link to the artwork/layout files.
The gist is that the Bubble Trouble diorama is a drop-in replacement for the Golly Ghost diorama that has only 4 moving pieces (ship, ship trapdoor, treasure chest, and clam) instead of Golly Ghost's 5. We were able to identify the Bubble Trouble moving pieces by activating the Golly Ghost diorama for bubbletr in the MAME code and then applying its artwork to Bubble Trouble. The scoreboard appears to function exactly the same as Golly Ghost's.
Now, everyone should be able to enjoy this game closer to the originally intended way of playing it 😃.
If anyone out there has access to the physical diorama pieces and can provide higher-quality photos, please let us know!