Bubble Bobble `bublbobr` (MAME 2003 Full Non-merged Reference Set) no longer works

[ghost]

Description

"Bubble Bobble w/ Mode Select" (rom name: bublbobr) from the MAME 2003 Full Non-merged Reference Set no longer works on the MAME 2003 Plus core. It still works in the regular MAME 2003 core however.

When using the verbose option on RetroArch with the MAME 2003 Plus core, the following problem is revealed:

[libretro INFO] Found game: bublbobr [bublbobr].
[INFO] Environ SYSTEM_DIRECTORY: "/home/drew/.config/retroarch/system".
[INFO] Environ SET_ROTATION: 0
a78-01.17    NOT FOUND
ERROR: required files are missing, the game cannot be run.
[ERROR] Failed to load content.

It should be noted that file a78-01.17 is not part of bublbobr for the MAME 2003 Reference Set; it is present however in the MAME 2010 Reference Set version.

---

Expected behavior

Game should run normally and be compatible with the 2003 version of bublbobr, and later versions if desireable.

---

Actual behavior

Fails to load due to rom missing file a78-01.17 which is not required by MAME 2003.

---

Steps to reproduce the bug

• Load the MAME 2003 Full Non-merged Reference Set version of bublbobr
• Select the Arcade (MAME 2003 Plus) core
• Game won't play

---

Logs:

Relevant --Verbose Terminal Output:

[libretro INFO] Found game: bublbobr [bublbobr].
[INFO] Environ SYSTEM_DIRECTORY: "/home/drew/.config/retroarch/system".
[INFO] Environ SET_ROTATION: 0
a78-01.17    NOT FOUND
ERROR: required files are missing, the game cannot be run.
[ERROR] Failed to load content.

---

Bisect Results:

After extensive, although not exhaustive (takes too long to compile every commit along the way), testing, the last known working commit seems to be 9d82c48 . Failure is observed as early as commit 36954d6 , however that may not be the earliest instance it fails.

It is very important to note that when commit 9d82c48 is compiled, the core's filename ends up being mame2003_libretro.so instead of mame2003_plus_libretro.so

This has me severely worried about bug regressions involving various games we fixed as of that very important commit.

---

Version/Commit Info:

• RetroArch Version: 1.7.2 f0e057c8d0
• MAME 2003 Plus core commit version: 1a22bc7

Environment information

• OS: Debian 9 (Stretch) Stable x86_64
• Compiler: gcc 3.6.0 64-bit

[Wilstorm]

I just played this a few days ago on regular lr-mame2003 and it did run fine. I was just adding a comment as I see you mentioned it above.

[ghost]

Your rom is incorrect it's missing the MCU dump "a78-01.17" which is now required for this core or you'll get a load error for the following versions...........

"Bubble Bobble" bublbobl.zip "Bubble Bobble (US with mode select)" bublbobr.zip "Bubble Bobble (US)" bubbobr1.zip

[ghost]

That's impossible, that would mean the 2003 reference set is incorrect.

The file you're referring to is present in the 2010 reference set, but not the 2003.

It's okay to be compatible with the 2010 version, but it should still accept the 2003 romset. Otherwise anyone using the 2003 reference set will get this issue.

[ghost]

I updated this driver adding support for the proper MCU dump for Bubble Bobble, this means the original rom from mame2003 is not compatable in this core, unless you happen to have "a78-01.17" otherwise you'll get a romload error.........

This is the commit where i made the changes

https://github.com/libretro/mame2003-plus-libretro/commit/8a025f37d83aff53cfba308cb2e6dcab0c61e614#diff-3124aa496f398b50111d1d5d5674490e

EDIT:: infact the two main CPU roms are different now with the parent bublbobl rom notice the CRC's have changes, although the clones just have one difference being the MCU.

[ghost]

Alright on spec i grabbed both Bubble Bobble and Bubble Bobble With Mode Select and both games work for me, the code is the exact same in this and my test core so i can only assume if you have the correct rom versions these games should work in mame2003-plus

Regards

[ghost]

Should we really be breaking compatibility with mame2003 romsets? I thought the goal is to be literally 2003 Plus.

Or is there a newer revision of the 2003 reference set than v3 / February 2018?

[ghost]

Bubble Bobble was not 100% emulated in older MAME it had simulation of the protection eg guess work rather than the proper MCU dump which i updated the driver to support.

5th August 2006: Nicola Salmoria - As you'd probably noticed, the pics in the previous post are of the Bubble Bobble custom MCU. Despite being one of the most popular games of all times, and having been in MAME for many years, the emulation of this game has never been perfect due to the lack of the original ROM for the MCU. For some time, we had been using a 68705 program found in a bootleg board, believing it had been extracted from the original. However, monster behaviour was wrong and there were other problems, like the wrong behaviour of the clock item. After some study of the program and of the game schematics, it became clear that the original MCU is not a 68705 at all (the pinout doesn't match) but looked more like a 68701. The 68705 program had been written from scratch by the bootleggers using black box reverse engineering techniques, by running the original MCU and logging all its reads and writes from memory. Indeed, the 68705 program does a lot of reads from memory without doing anything with them--simply because the original MCU would read that memory and do some unknown action with it. Eventually, the useless 68705 program was replaced by simulation code inside the emulator, which greatly improved the emulation accuracy. Monster behaviour was improved, the clock item behaviour fixed. However, there were still some unknown things, like how the randomisation of the EXTEND bubbles really worked. At last, thanks to excellent work by Trinity, the original MCU ROM has been extracted. This required removing the cover from the chip, taking photographs of it under a microscope, and manually decoding the contents of the ROM bit by bit. The photo shown in the previous post confirms that it's in the 6801 class, not a 68701 however as it was conjectured, but a 6801U4. With this ROM, we finally have the final piece of the puzzle for a 100% guaranteed perfect emulation. Checking the original MCU program was very interesting. It was designed to provide many protection features that were eventually not used by the game, like: • Process coin inputs and update the credit counter • Handle the number of remaining lives for both players • Handle the current round number • Handle variable speed incrementing for four variables and • Return values from a 1280 bytes table of seemingly random data. The reasons why those features were not used are probably various. Some of them were probably awkward to use because they require to one one frame for the MCU to process the data, others weren't flexible enough like the coin input processing that wouldn't allow for coinage settings different from the ones hardcoded in the MCU (though versions of Bubble Bobble with different coinage settings don't seem to have been made anyway).

So, how close was the simulation to the real thing? Very close; "too good", actually. Let's see why. The clock item behaviour was spot on, but off by one frame (the simulation made the counter expire one frame too late). The EXTEND randomisation simply doesn't exist in the original MCU. While the simulation code used a RNG to provide truly random letters, the original MCU simply increases the counter every frame. This seriously affects the game, making the EXTEND letters predictable. Since a new bubble enters the screen exactly 128 frames after the previous one, and the remainder of 128 / 6 is 2, this means that if you get consecutive letters each one will be 2 places after the previous one. So if you get 3 letters you can get either E, T, N or X, E, D. After that they will repeat. There are exceptions, though: If you create a new bubble in exactly the same frame when a new bubble should enter the screen, the bubble is delayed by one frame. So by timing the fire button exactly right you can change the bubble order. In theory you could get all 6 letters in a single level--let me know if you manage to do that! Also, new bubbles will not appear if there are already 16 bubbles on the screen, so that will change the order as well. The last, and most important, thing that the MCU does is compare the player coordinates with the monsters. The results are returned as flags indicating whether each coordinate is >, =, or <, and the absolute difference. This was done correctly in the simulation code, however there appears to be a bug in the original MCU. The code there attempts to check if the player collided with a moster and set a flag and indicate which monster in that case, but it just doesn't work. It would set the flag even if the player's Y coordinate matches one monster and the X coordinate matches a different monster! This isn't much of a problem since the main program just ignores the flag--the collision detection is done correctly by the second Z80. However, the MCU also completely stops processing the monster coordinates as soon as it finds a monster whose X coordinate is within 8 pixels of the player. So e.g. if you have a monster right above you three platforms up, and that monster is the first in the list, the other monsters could stop following you. This is a very subtle effect that's completely unnoticeable from what I can tell, though in theory it exists.

[ghost]

@SapphireTactician it isint breaking comparability adding one file wont break it on mame2003 its just a mcu dump however if you want to use updated games you will have to add the file.

[ghost]

Some people just dont like rom changes or is the work they then have to put in to update their romsets i never can tell, i try to keep this to a minmium but for certain games to work or have full sound this sometimes means the roms have to change simple as.

The whole pooint of this core is support new games or fix up broken ones or add sound support where it was lacking, for this to happen the romsets have to be altered @SapphireTactician you asked me earlier to update the esd16.c driver the roms will likely change in the process or should i just scrap the driver update for those that are rom change averse :)

[ghost]

@arcadez personally i dont really care if romsets change maybe we should rename this core and take the name association away unless the merge is the goal. To me as long as the cores help each and stay compatible the drivers are separate,

[ghost]

It'll never be merged too many folks dont want to see that happen, so yeah maybe for the best to totally remove any connection namewise to mame2003, we could always revert back to using MAME78 or you guys might come with something more imaginative :)

[ghost]

mame_arcadez(mame078 with updated drivers and added roms) :D will look good in in the retroarch desc

[ghost]

Ha Ha yeah if we start sticking all our names in it'll be sentence or two long

[ghost]

haha it looks sweet to me

[ghost]

@arcadez is your port for the original xbox or xbo360 I have two two moded xbox360s I cant remember what glitch chips i put in them though was a while ago

[ghost]

Oh i didn't port em buddy thats above my paygrade what i did was similar to here take the original port and update it, i have four on the go just now FBL which is an FBA port to the original xbox.

And MAME wise i have 72 and 84 for the xbox and i just updated MAME72 on the xbox360

[ghost]

how do i grab it and install it arcadez i think that might be a nice alternative for me!

[ghost]

which ones you after..??

[ghost]

72 and 84 never ever used alpha at all to be honest

[ghost]

You'll only need MAME 84 really as it supports everything that MAME72 does however MAME72 does have a slight edge with performance and inputs for some games. FBL will support certain games the above emulators dont and play em better.

Anyway grab MAMEoXtras from here follow the install guide and you should be up and running pretty quickly i can help ya out here and there should ya get stuck ;)

http://www.emuxtras.net/forum/viewtopic.php?f=189&t=6072

[ghost]

sweet thanks mate you probably wont see me for a while time to get the xbox and maming on the big screen is appreciated. What gui you using for the the xbox360 is it still aurora we are using its been a while

[Wilstorm]

This required removing the cover from the chip, taking photographs of it under a microscope, and manually decoding the contents of the ROM bit by bit.

That's incredible how this guy did it.

@SapphireTactician - All you need to do is add a single extra ROM to your existing set and it will work in either emulator. Just don't process it through lr-mame2003 DAT or it will remove it but it will process fine with the mame2003_plus reference DAT.

Actually mame2003_plus has the better flexibility as it's ROM will work in either but the lr-mame2003 ROM will only work in lr-mame2003. MAME doesn't care about extraneous ROMs in a set. As far as it knows it might be another clone or parent ROM from a merge set.

I kind of track changed ROMs from lr-mame2003 to mame2003_plus_libretro and there's already roughly 30 ROMs that have changed from the original lr-mame2003 reference set and about 90 new ROMs added. I can get an exact list of ROM names that have changed if you want.

Reading Arcadez added information posted above it sounds like there is an incredible amount of fixes that were missing from the handwritten bootleg ROM vs. the correct accurate dump that make it worth the new accuracy of game play implemented alone.

[ghost]

@Wilstorm on a slow day with nothing much on the cards you might wanna check out this site which details how the recent MCU dumps for MAME were done.........

http://caps0ff.blogspot.co.uk/

[Wilstorm]

@arcadez - I just took a quick peek thanks that's perfect. I actually find that type of information interesting!

[ghost]

@arcadez Oh, I get it now. I was operating under the assumption that the name had meant that it was designed to play everything from the MAME2003 set as-is PLUS additional games backported from later romsets so that we have the speed of 2003 but with a much larger library. I feel like a lot of users may be operating under the same assumption as I and will be confused when the rom doesn't work as-is without the additional file.

As for the newly required file, should I import it from the 2010 version? Or should I simply use the 2010 reference set version of the game instead on this core? Please advise.

My only adversion is that it throws a curveball that users from the "it just works" camp like myself don't exactly know how to handle correctly. Is there no way for the driver to handle both versions?

On a sidenote, reading that history of the ROM gave me an even deeper appreciation for a game that I already deeply appreciate.

[ghost]

@SapphireTactician as @Wilstorm said you can just drop the extra rom for the MCU into both bubbbobr.zip and bublbobr1.zip and they'll both work across both cores.

The parent rom bubblbobl.zip will cause problems as there was a redump of the two main CPU roms and they have different CRC.s but are named exactly the same so im not sure if you can create a dual purpose rom for that one as they might overwrite each other should you try and add both in the same zip..??

Give it go and see at anyrate.

[Wilstorm]

If you use a ROM manager like ClrMamePro the mame2003_plus DAT will process it fine or even simpler just unzip the 2010 ROM set, move the file a78-01.17 to the desktop or wherever. Then add it to these 3 sets:

"Bubble Bobble" bublbobl.zip
"Bubble Bobble (US with mode select)" bublbobr.zip
"Bubble Bobble (US)" bubbobr1.zip

Then your sets will work in either emulator.

To get the new accurate version Arcadez implemented you would have to ask the lr-mame2003 folks to add the code updates to their version.

There's a small caveat that I have no idea what lr-mame2003 does for changes or additions. I'll try to explain. When the "trio" here setup mame2003_plus these guys added support to generate a DAT on the fly, so new reference set changes are immediately available to the user to process and update their ROM sets. That's a big deal.

When they make a change to lr-mame2003 I have no idea if anyone updates a DAT or if it's word of mouth a new more accurate version works in the emulator or how updated ROMs are made available to the end users.

I think your assumption is mostly correct. There's roughly 5,000 ROM sets and roughly 4,810 or so are 100% bit-for-bit accurate. Roughly 30 have been modified from the original lr-mame2003 set and 90 or so new additions that aren't available in lr-mame2003.

I can give you a list of changed ROM set names but not what actual ROMs in the set have changed but that would only require you to open them with Winzip or something to take a look. I keep a shell version program that gives me the CRC/SHA1/MD5 of a file by right clicking and viewing the properties of a file. Also WinMerge is a great way to compare files. If you compare zips it needs to be Torrentzipped or some other utility that will create a consistent hash value.

[markwkidd]

I hate to ever have to send people to learn ClrMamePro but now that you have started explaining that maybe we should have a writeup on how to process your ROM collection to work with mame2003-plus. Wilstorm has basically written the first draft here already..

[Wilstorm]

The parent rom bubblbobl.zip will cause problems as there was a redump of the two main CPU roms and they have different CRC.s but are named exactly the same so you cant just create a dual purpose rom for that one i dont think..??

Yeah that might be a challenge. Ok so the parent ROM would be different.

What I've been doing is keeping a perfect lr-mame2003 reference set. Then I create a DAT of just the differences (at a ROM set level) compared to mame2003_plus. Then when I need to create a mame2003_plus set I copy them right over the top and you instantly have a mame2003_plus set. It's a space saver of several gigs vs building the entire set.

@markwkidd - Someone already did an awesome tutorial right in the RetroPie docs. It explains things well too.

https://retropie.org.uk/docs/Validating,-Rebuilding,-and-Filtering-ROM-Collections/

[ghost]

@Wilstorm there is the possibility to just roll the main cpu roms back to what they were for mame2003, i'd need to check the MAME Wip to see why they were redumped in the first place, although i assume it was for good reason maybe connected to the MCU dump..??

[Wilstorm]

although i assume it was for good reason maybe connected to the MCU dump..??

Yeah that makes sense that they are connected to the new/correct ROM dump.

[ghost]

Nah sorry my mistake there was a new version dumped around MAME95 so the previous parent became a clone, the roms are actually named different i think i need to get my ole peepers tested.......

Bubble Bobble parent mame2003 "a78-06.51", 0x00000, 0x08000, CRC(32c8305b) "a78-05.52", 0x10000, 0x10000, CRC(53f4bc6e)

Bubble Bobble parent mame2003-plus "a78-06-1.51", 0x00000, 0x08000, CRC(567934b6) "a78-05-1.52", 0x10000, 0x10000, CRC(9f8ee242)

This is your core guys what'ya wanna do..?? i can just roll it back and use the maincpu roms from mame2003 then all you'd need is the MCU dump or keep them as they are

[ghost]

@arcadez just leave it we have a dat generator rename the core and do what we are going the only parts that need to stay the same are the osd functions to control mame from libretro there is no reason we have to be tied to the 2003 romset if we arent merging. There is a way round this though if you do want to keep compatability just rename the driver name to not match mame2003 and add a fake bublbob with the right romsets and mark as not working. Seems a bad way of going about it though

[markwkidd]

I also say keep the bugfixed versions.

[ghost]

there is no reason we have to be tied to the 2003 romset if we aren't merging.

Ummm, I probably don't have any say in this as I'm just a tester, but I'd really really like to NOT have to throw out / overhaul an entire romset. Especially because there is no reference set for 2003 Plus, and I'd like to not have to keep / maintain more than one set, meaning I'd have to hack and piecemeal who knows how many roms if the 2003 set gets completely divorced. Furthermore ClrMamePro doesn't run on Linux unless I want to deal with WINE (which really I don't - I want to move away from Windows, not cater to it with a compatibility layer). On that note, is there a Linux alternative to ClrMamePro?

That all being said, while I'm all for bug fixes and extra compatibility, it'd be very very much appreciated to be, for lack of better words, backwards compatible with the 2003 romset.

[Wilstorm]

@arcadez - But your one of the founding fathers like good ole George Washington right on Mt. Rushmore. The first in line.

So does rolling back mean loosing the new accurate version you implemented? If so I would opt to keep the new version.

[ghost]

It's not a bugfix per say more a new version was dumped.....

0.94u3: Tormod Tjaberg added Bubble Bobble (newer set). Renamed (bublbobl) to (bublbob1).

The code wasn't originally mine so what the dev must have done is used the new parent above without then supporting the new clone BritneysPAIRS was known for his hacky shortcuty methods :)

Thats how i missed it, there's nothing to stop us just keeping the original parent from mame2003 but it will still support the new protection MCU.

[ghost]

@SapphireTactician your looking at this wrong if you have a mame078 99% will work just rebuild that 99 and use what works

[Wilstorm]

specially because there is no reference set for 2003 Plus,

@SapphireTactician - You actually do have a reference set, but even better, it's dynamic.

You're thinking of traditional MAME sets like MAME 0.78 that is static for all of time, for eternity. Each new release is static 0.79, 0.80, etc. What Plus is doing different is it started with 0.78 as it's base and is in a perpetual state of updates. It will never have a static set in the traditional sense.

This is just my opinion but a ROM manager tool is a must. If not you would need to track every commit and hand edit your ROMs which sounds crazy to me. From week to week the set becomes stale and you need to update to take advantage of the new additions and updated accuracy like Bubble Bobble.

I know what your saying but take Bubble Bobble for example. Would you prefer the older inaccurate set just so the set works both ways or the new 100% accurate game that played exactly like the arcade.

It's a tough call but really no different than say mame2010 (also a "true" static set) or mame2014, or mame2016, etc. those emulators are static sets. mame2003_plus is not traditional in it's a dynamic set that has ROMs being added and updated vs. just working on the interface or options, etc. like these other emulators do.

Thats how i missed it, there's nothing to stop us just keeping the original parent from mame2003 but it will still support the new protection MCU.

Wow, that's almost tempting. You can keep the same parent ROM but still have the accurate MCU only needing to add a single ROM. I think I would opt for that then.

[ghost]

Ok apart from the new MCU the parent rom for Bubble Bobble is the exact same now as it was in mame2003

[ghost]

@Wilstorm Your assessment of my thinking is 100% correct. My (mis)understanding was that it would use the static 2003 set but with the added benefit of backports of games that weren't available to 2003 for those who need the 2003 core due to low end hardware, plus any fixes so long as editing roms isn't mandatory (I feel such edits should be optional, if the user wishes to take advantage of the improved accuracy, they may, but those who can't / don't want to be bothered shouldn't be forced to).

Don't get me wrong, I really do appreciate things like increased accuracy, especially for games I care about, plus fixing sound and video (as "Bonk's Adventure" bonkadv won't work in 2003 but works great in 2003 Plus), but I'd like the option to be able to use this core even if I'm happy with a rom as-is (in other words, it should be able to use either the old parent or the patched parent, in case someone like myself is too lazy to keep patching a rom in order to keep up with a rolling release cycle, but yet still wants the other benefits the core has to offer).

Perhaps I'm asking for too much (in regards to the project's direction and not just this individual case), especially given that I'm not a developer here. If so, I apologize.

[Wilstorm]

@arcadez - I don't know if it's a lot of work but I do like your idea of reverting back to the older parent ROMs but leaving the new MCU decryption ROM in place then it's kind of like the best of both worlds. 100% compatible both ways but also on the Plus core a bonus of better game play accuracy.

[ghost]

It's done all you need to do is have the MCU rom in your bublbobl.zip and bingo it will work across both cores.

[ghost]

@arcadez When fixes / new versions of roms like this happen in the future, can it be possible to allow the old static version to still be usable as well within this core? I love new stuff, but only when any changes that require end-user action is optional.

I understand if that's not acceptable. After all, I get my original understanding of this core isn't correct or even compatible with the direction @grant2258 seems to want since merging with 2003 seems unlikely according to him. Maybe it's the fact that I'm a Debian user, but I'd like the option to continue using this amazing core along with any backports for it, but at the same time, not feel forced to patch a rom if I'm satisfied with it / can't be arsed as we Debian users do like to keep things as static as possible unless it becomes an inconvenience via bugs or lack of support.

[ghost]

@SapphireTactician

At the end of the day the choice is in your hands to either take advantage of this new core understanding the direction we are taking and that you may have to update the odd rom or sample here and there or just stick with the original mame2003 core.

You do come across as whining a bit here keep in mind no one is forcing you or anyone else to use this core, but be rest assured im not planning anymore significant changes to the drivers or roms that they support infact i thought i was done until you requested i update esd16 earlier which funny enough means the roms will change surely you wont be moaning about this next :P

[ghost]

@Wilstorm your totally correct the roms change with every MAME, FBA or Raine release their never truely static, i hate updating roms myself but if you were to post something to that effect over on the mameworld forums you would be told to go and do one very quickly.

At the end of the day it's a users choice to update to the latest mame with the understanding that alotta stuff will have changes and you may have to put in a bit of graft to get everything up and running or just stay on an older version but miss out on the fixes and improvements that come with each new release.

Take Bonze Adventure in every MAME release bar the last the game will crash on later levels but with the new C-Chip dump that's fixed but you'll need a new rom to take advantage of this the same dilemma rings true for users of this core or those that prefer to stick with mame2003 it's horses for courses know what i mean.

[ghost]

@arcadez Sorry about that, I tend to think in extremes / worst case scenarios. The way @grant2258 talked about not wanting to be "tied to 2003" left me under the impression that in the future, updates to roms could become increasingly frequent, or drastic.

To be perfectly honest, my main draw to this core was the backports; I mainly just want a 2003 that can use later games since later mame cores and FBA are too slow for my target devices like the RPi.

And again, the way you said is fine, but imo I feel it should also remain backwards compatible for those who are in it for just the increased library.

[ghost]

@SapphireTactician as i said the big rom changes are done and will now as far as on my end remain stable as they are, obviously if another dev comes along with a different outlook in that regard then thats a debate for another day.

Anyway should you not be off enjoying Tang Tang :)

[ghost]

You're right. :) I'll close this now and play it right away. Thanks again.

[ghost]

@SapphireTactician i said there is no need to be tied to the mame2003 romset if we arent merging as long as we keep the mame core (libretro) functionality the same between both. so fixes can apply to both platforms. Obviously we will try to keep the base romset working but its not always possible