This is why the MAME emulation of Kangaroo is inaccurate...

General discussion on MAME, MARP, or whatever else that doesn't belong in any of the other forums

Moderators: mahlemiut, seymour, QRS

Post Reply
jerky
Button Slapper
Button Slapper
Posts: 14
Joined: Sat Apr 12, 2014 4:22 pm

This is why the MAME emulation of Kangaroo is inaccurate...

Post by jerky » Sat Dec 27, 2014 5:39 pm

I wanted to share this post I made on Twin Galaxies regarding the obvious differences between how Kangaroo plays on a legit arcade machine versus the current MAME romsets (TG takes days to put your posts up so I don't have a link for ya yet but you can find it at the end of the "Undisputed Champions Thread" over there ).
http://www.twingalaxies.com/showthread. ... ons/page11

I've recently been playing a bit of Kangaroo over at High Scores Arcade in Alameda. I noticed the same thing that others have brought up here. The Gorilla never comes out as often as it does with the current MAME romsets. I also used to play Kangaroo at my local pizza joint when I was a wee lad as well. The Gorilla never came out over and over.

I wrote a speculative post about this the other day and then decided rather than guess (deleted the post), I would dust of my ol' debugging skills and dive into the Kangaroo code via the MAME developer debug build (run Kangaroo ROM with the -debug switch). That MAME debugger is pretty sweet. It was fun to go back digging through code again. It just took me a few days to figure out what "exactly" was going wrong (as much as I could without a DUMP of the missing ROM anyway).

As others have posted here, the current Kangaroo romset's are missing the mb8841.ic29 rom, which is a custom micro-controller "security chip" that has yet to be emulated properly from what I have just uncovered. The MAME developers made a quick and "dirty" fix that does not work properly (the Gorilla coming out over and over is specifically linked to the missing ROM chip and how the MAME driver tries to mimic it).

I will share the specifics (code, code and more code) in a more detailed post this weekend (in the "Emulation Gaming" Forum), but basically the MAME driver poorly "spoofs" the "security chip" which is really a "random" timer using values from 0-F (1-10) to help decide specifically when the Gorilla appears and when it comes back out. Unfortunately, this "band-aid" leads to the Gorilla appearing over and over after the initial appearance (it also does not add the correct "random" delay to the Gorilla first coming out like the Arcade does)(I haven't looked at the code yet, but the Bonus Timer is slightly "off" as well).

I know this for a fact because I have reverse engineered the specific chunk of Kangaroo code in question (Gorilla related). There are two "timers" in the code that determine when the Gorilla comes out on the screen, and when it comes out again for a second time+ (@ $E162 and $EF00). All this vital information is located/accessed in one routine within the main Kangaroo code (CALL $351C).

The first timer ($E162) counts up to about 16 seconds (0-10 HEX) from the start of each Board. This routine also does a check to see if it is Board 4 or not, when the Gorilla does not come out (only on 1-3). Once the first timer reaches 10 (HEX), a second timer takes over (using values that come from $EF00, which happens to be the "security chip" input/output in memory). A combination of one static timer and one random timer control the Gorilla release and re-appearance on each Board (1-3).

The second timer uses the values within/generated by the missing ROM chip to set an additional "random" wait time on top of the initial 16 seconds the first timer counted to. The Gorilla will not come out until the second timer sets the right value to allow the code to bypass a conditional jump or not (directly based on values being read from the missing ROM I/O at $EF00). Once that data triggers this, the routine drops down to specific code that first finds the current Kangaroo position on the screen, and then sets the initial Gorilla appearance position in memory relative to that (vertical and horizontal coordinates on the screen at $E118). Also, after the Gorilla goes off screen, this same timer based on values from $EF00 is responsible for deciding when to send the Gorilla out again (or not).

Other routines draw the Gorilla on the screen, play related music/FX and do collision detection etc using those Gorilla location values set at ($E118). But the code in question simply does not work properly because the "random" values that the MAME driver for Kangaroo generates are not correct at all. I was at High Scores today with a notebook writing down when the Gorilla appeared through levels 1-4 (using the Bonus Timer as reference). The arcade machine definitely has a "random" factor in play after the initial 16 seconds timer. The current MAME version is mainly using that first "static" timer to decide because the "random" values at $EF00 cause the code that makes the Gorilla appear to improperly execute over and over, unlike the Arcade version with the custom chip in place.

Sorry kids, but all those super high MAME scores for Kangaroo are "no good", as far as being set on an actual Kangaroo game as originally coded (at least in MAME where the scores are heavily based on leeching the re-appearing Gorilla). They are maybe worthy of a separate "track" because it does take some skill to exploit, but the MAME version acts like a "pirated" Arcade machine would which isn't exactly to "spec".

It seems that the designers specifically coded the game this way so that they could "identify" counterfeit machines back in the 80s. As the MAME developers found, you can "spoof" the custom security chip with some other timer to get the game to "run". But, if you don't have an exact copy of that custom micro-controller, then the Gorilla will behave in a very obviously "wrong way" (which most casual players would not notice, nor complain about given the scoring bonanza that occurs because of this).

If anyone tried to bypass that custom security micro-controller (or did not emulate it properly) by using some other random timer, they would end up with the same or similar results as the current MAME romsets. The Gorilla would almost always appear at around 1800-1700 Bonus Time (16 seconds give or take). Then after it was punched out, stole your gloves and ran away, or walked off the screen it would then almost immediately appear again and keep coming out until you died or the current Board ended.

I would definitely question the "Undisputed" status of any and all Kangaroo scores that heavily rely on leeching the always re-appearing Gorilla (MAME or Arcade) given this information (the super high TG Arcade scores are all from the early 80s and were "referee" verified?). No disrespect to those who worked hard to get those really high scores, but the game was not originally coded to allow for unchecked Gorilla leeching (MAME at least).

*** NON TG POST NOTE ***

I also just noticed this morning that when the security chip is not emulated properly (like in the MAME romsets), it gives the player an unfair advantage on the first Board on later levels (scoring aside). I have been playing Kangaroo (arcade machine) and have had trouble getting by Board 1 on Level 4-5+ because you have to fight past a bunch of monkeys throwing tons of apples at you to make it to the top almost every time. My usual "pattern" on these higher levels is to run right up to the third platform (avoiding monkeys on the first and second ones). But when you come up the ladder to the third platform on the left side (right around 1800-1700 bonus time btw), you have to cross the whole screen to the right while fighting off a pile of monkeys waiting for you on the right side of the screen guarding the ladder you need to go up to finish the level (with the other one above dropping apples on you too).

I watched the top MAME scores on Kangaroo here and noticed that because the Gorilla always comes out around 1800-1700 bonus time, it causes less monkeys to gang up on you at this specific point from Level 4+ (which players benefit from unfairly it seems). In those games the other players do the same thing I do in the arcade: race up to the left side of platform three on Board 1 right around 1800 bonus points. Then the Gorilla very predictably comes out on the right side opposite the Kangaroo on the left. When the Gorilla is out usually only about 1-2 monkeys throw apples at you, while the other ones don't come out on the same platform the Gorilla is on (they go up or down away from you...maybe some game limitation on objects?). After those monkeys throw just one "wave" of apples, they take off, while other monkeys climbing the tree skip platform three as the Gorilla walks across towards the Kangaroo (leaving you a very wide open window of opportunity to get to and up that last ladder that you don't seem to ever get in the arcade version). Because the "random Gorilla appearance timer" is "broken" in MAME, you can count on the Gorilla appearing on that platform, at this critical timing, and that in turn makes it much easier to get across and up that last ladder.

In the arcade, specifically the machine at High Scores in Alameda, CA, the random Gorilla appearance factor leaves you up on platform three alone many times trying to battle an almost endless wave of apples being thrown by monkeys on the right (and more monkeys keep coming as soon as others have thrown all their apples at you). I played a bunch of games the other day and took notes on when the Gorilla was appearing across Board 1-3 on levels 1-4. Some games it would come out three times, sometimes twice (and always with a random amount of time after the initial 16 static second counter). Sometimes it would not even come out until 800 bonus time or less for the first and only time on Board 1. It even occasionally comes out almost back to back (but you would only see that maybe once in a whole game or bunch of games unlike with MAME right now).

It can be nearly impossible to get by this Board 1 monkey/apple onslaught from Level 4+ without being able to rely on a Gorilla popping up on cue at 1800 bonus time at the same place. This may explain why all the "recent" Kangaroo scores set on arcade machines are only around 90-116k (that's the right score for being on Board 1 around Level 4-5 ish). It makes me wonder if the old arcade scores from the 80s in the many hundreds of thousands were on some "pirated" version of Kangaroo that did not have the security chip, or used some other random timer the way the MAME developers tried to do (allowing Gorilla leeching on an arcade machine).

So it's not the roms, it's not a case of different versions, it is actually based on the poor MAME driver emulation/bypass of the missing security rom in question (which may be reflected on the arcade machines with pirated versions of the game that have the same or similar issues). This oddball Gorilla behavior specifically happens because of the very very clever security the designers put in place. Like I said above, the current scores are a great achievement, but done on a non-legit version of Kangaroo (MAME anyway). Maybe someday soon we can get a good dump of the missing chip and then we will see what kind of high scores players can really get on Kangaroo (with the proper randomizer in place for Gorilla appearances).

cheers
jerky (JRK)
http://www.highscoresarcade.com/pro-scores.html

(when I get some time this weekend I will try to post the actual Kangaroo code I recent debugged with some notes)

*** UPDATE ***

I also forgot to mention that being able to rely on the Gorilla coming out at 1700-1800 points all the time due to the failed "security chip" emulation has a similar "advantage effect" on Board 3 (The Tower of Monkeys). From Level 4-5+ the monkeys throw fairly relentless streams of apples at you as you try to punch out enough monkey statues to get to your baby Kangaroo (and dodge apples from above at the same time).

Again, like Board 1, when the Gorilla comes out it causes incoming monkeys to climb away from the platform you and he are on. In this case you just have to dodge 1-3 initial monkeys and all the apples they throw (4-5 per monkey at this level?). Then when the Gorilla makes his prompt appearance, you get another break from apples I have yet to see in any arcade game I have played since the early 80s.

I tested this with my "No Gorilla" rom-hack on levels 4-5. You have to survive a near endless stream of apples throw by monkey after monkey. There is little to no break when the Gorilla does not come out at all (or randomly waits to 1000 bonus time or less like it does in the arcade sometimes).
Last edited by jerky on Sun Dec 28, 2014 10:35 pm, edited 1 time in total.

User avatar
mahlemiut
Editor
Posts: 4133
Joined: Mon Feb 04, 2002 10:05 pm
Location: New Zealand
Contact:

Re: This is why the MAME emulation of Kangaroo is inaccurate

Post by mahlemiut » Sat Dec 27, 2014 6:52 pm

Perhaps a bug report ought to be filed at MAMETesters...
The MB8841 MCU is emulated by MAME, but without the code dumped (which is likely not to be easily possible), you just have to simulate what it does.
- Barry Rodewald
MARP Assistant Web Maintainer
Image

jerky
Button Slapper
Button Slapper
Posts: 14
Joined: Sat Apr 12, 2014 4:22 pm

The code...

Post by jerky » Sat Dec 27, 2014 7:16 pm

I started with information from the MAME driver code I found here:
https://github.com/OpenEmu/UME-Core/blo ... kangaroo.c

Sun Electronics hardware:

TVG-1-CPU-B
2 x Z80
AY-3-9810
8-way DipSwitch
Service Switch
Program ROMS (both Main & Sound)
MB8841 (at least for Kangaroo)
TVG-1-VIDEO-B
10MHz OSC
Graphic ROMS
driver by Ville Laitinen
****************************************************************************

0000-0fff tvg75
1000-1fff tvg76
2000-2fff tvg77
3000-3fff tvg78
4000-4fff tvg79
5000-5fff tvg80
8000-bfff VIDEO RAM (four banks)
c000-cfff tvg83/84 (banked)
d000-dfff tvg85/86 (banked)
e000-e3ff RAM

memory mapped ports:
read:
e400 DSW 0
ec00 IN 0
ed00 IN 1
ee00 IN 2
efxx (4 bits wide) security chip in. It seems to work like a clock.


Kangaroo Memory Map
HEX R/W D7 D6 D5 D4 D3 D2 D2 D0 function
------------ Game Microprocessor Memory Space (Z80 - IC15) --------------

EFxx-EFxx W D D D D Output to Custom MB8841 Microcomputer
EFxx-EFxx R D D D D Input from Custom MB8841 Microcomputer


TODO:
- There is a custom MB8841 microcontroller on the original Kangaroo board which
is not emulated. This MIGHT cause some problems, but we don't know of any.

***************************************************************************

#include "emu.h"
#include "cpu/mb88xx/mb88xx.h"
#include "cpu/z80/z80.h"
#include "sound/ay8910.h"
#include "includes/kangaroo.h"

#define MASTER_CLOCK XTAL_10MHz

/*************************************
*
* Machine init
*
*************************************/

void kangaroo_state::machine_start()
{
membank("bank1")->configure_entries(0, 2, memregion("gfx1")->base(), 0x2000);
}

MACHINE_START_MEMBER(kangaroo_state,kangaroo_mcu)
{
kangaroo_state::machine_start();
m_maincpu->space(AS_PROGRAM).install_readwrite_handler(0xef00, 0xefff, read8_delegate(FUNC(kangaroo_state::mcu_sim_r),this), write8_delegate(FUNC(kangaroo_state::mcu_sim_w),this));
save_item(NAME(m_mcu_clock));

}

void kangaroo_state::machine_reset()
{
/* I think there is a bug in the startup checks of the game. At the very */
/* beginning, during the RAM check, it goes one byte too far, and ends up */
/* trying to write, and re-read, location dfff. To the best of my knowledge, */
/* that is a ROM address, so the test fails and the code keeps jumping back */
/* at 0000. */
/* However, a NMI causes a successful reset. Maybe the hardware generates a */
/* NMI short after power on, therefore masking the bug? The NMI is generated */
/* by the MB8841 custom microcontroller, so this could be a way to disguise */
/* the copy protection. */
/* Anyway, what I do here is just immediately generate the NMI, so the game */
/* properly starts. */

m_maincpu->set_input_line(INPUT_LINE_NMI, PULSE_LINE);

m_mcu_clock = 0;
}

/*************************************
*
* Custom CPU RAM snooping
*
*************************************/

/* The security chip is a MB8841 with 2K internal rom. Currently it's unknown what it really does,
this just seems to do the trick -V-
*/

READ8_MEMBER(kangaroo_state::mcu_sim_r)
{
return ++m_mcu_clock & 0x0f;
}

WRITE8_MEMBER(kangaroo_state::mcu_sim_w)
{
}

______________________________________________

The "simulation" of the MB8841 above from the driver is what causes the MAME Gorilla timing issues. I used the MAME developer version with the -debug switch to examine the Kangaroo code with this valuable driver information in mind. I ran the game with a "watch-point" set on memory at $EF00 to see how the game was accessing this data that is supposed to be generated by the MB8441 chip that has yet to be dumped. During the actual game the only part of the code that does anything with values from $EF00 happens to be the code that decides initial Gorilla appearance time and location. This driver code above runs with the actual game code below, and is what is responsible for generating the values found in memory @ $EF00 that the game reads (that don't appear to match what the arcade machine is spitting out given the drastically different results with the MAME romsets/driver).

Here's the game code...

04d6: call $351c

351c: ld a, ($e017)
351f: and a
3520: ret nz
3521: ld a, $03
3523: 1d ($e017),a
3526: ld a, ($e0cd) *** $E0CD is the level counter :0=level 1, 1=level 2, 2=level 3, and of course 3=level 4 when no gorilla comes out
3529: and $03
352b: cp $03 *** check to see if board 4 (of 1-4 loop)...no gorilla comes out on this one so ignore code below
352d: ret z

352e: ld b,a
352f: ld a,($E118) *** Gorilla Location is @ E118=horizontal, E119=vertical
3532: and a
3533: ret nz *** Is the Gorilla already on screen by checking if horizontal location is not =00 @ $E118? If so then leave this Call 351C

3534: ld a,($e162) *** $E162 is the static "Gorilla Appear Timer"
3537: cp $10 *** $E162 Starts at 0 and @ HEX 10 (16) this fist static timer has finished its job, allowing the code below that access $EF00 to set the "random time" on top of this initial value
3539: ret c

353a: ld a,($ef00) *** EF00-EFFF is listed by Mame driver as "security chip i/o"

*** This is used as a second "Timer" to "randomize" when the Gorilla comes out AFTER $E162 counts up to =10
*** $EF00 values must not be correctly emulated, causing the Gorilla to always come out over and over right after initial $E162=10
*** With the correct values in place the game would count up to $E162=10 THEN based on the values coming from $EF00...
*** ...it would jump to CS:358C set $(E039)=00 + leave CALL 351C preventing CS:3451+ to run and cause the Gorilla to appear
*** $E162 is just the "initial timer". $EF00 "randomizes" the amount of time before it appears, and regulates later appearances
*** The wrong values in $EF00 cause it to go down to CS:3541 more than it should/would because it is only using $E162=>10
*** The Arcade version must have a more random set of values coming from the "security chip" that prevent repeat trips to $3541
*** The 1st Gorilla can be at 16 seconds (10 HEX) +the random value of $EF00 (0-F extra seconds(0-10 sec))
*** The 2nd Gorilla+ appearance is totally regulated by the values at $EF00 because the $E162 counter does not reset until the end of the Board

353d: bit 1,a *** This performs a check on the values in Register a obtained above at $EF00 affecting the very important conditional jump below
353f: jr nz,$358c *** Whether it jumps here or not is affected by the shifting values in $EF00 that come from the Mame Driver simulation/ mcu_clock

*** Those values that "work" do not appear to EXACTLY mimic the Gorilla "frequency"
*** This is where the MAME versions goes wrong...it ends up skipping that conditional jump too soon
*** Normally the game would loop past here as many times as need to set the "random factor"


3541: ld a,($e039) *** This value from this memory is a "flag" this routine sets to see if it is looping around to add "random" time or not to the Gorilla appearance
3544: and a
3545: ret nz *** The Game will keep looping until the "random" values from $EF00 allow enough game cycle time to pass before releasing the Gorilla

3546: ld a,$ff *** One the correct values in $EF00 trigger the game to drop down here, the rest of this code calculates the Gorilla appearance Location ($E118)
3548: ld ($e039),a
354b: bit 1,b
354d: jr nz,$3556

354f: ld a,($e0c1) *** Get E0C1 = Kangaroo vertical location...range values on level 1 platforms 1-4 are 14,48,7C,B0 > bottom to top of level
3552: cp $30 *** Is Kangaroo located vertically between 1st(14) and 2nd(48) platform?
3554: jr nc,$357d

3556: ld b,$14 *** Set B with vertical Location=14 for platform 1
3558: ld d,$00
355a: ld c,$10 *** C=10=far left horizontal location to start Gorilla at depending on Kangaroo Location
355c: ld a,($e0c2)
355f: bit 0,a
3561: jr nz,$3567

3563: ld c,$f0 *** C=F0=far right horizontal location to start Gorilla depending on Kangaroo Location
3565: ld d,$01
3567: ld a,($e0c0) *** Get $E0C0 = Kangaroo horizontal location...range on level 1 is from 20-CB left to right on all platforms
356a: and $e0 *** note Gorilla comes up outside that at horizontal=10 on the left or horizontal=F0 on the right
356c: cp $20 *** Is the Kangaroo near the left side of the screen?
356e: jr z,$3592

3570: cp $c0 *** Is the Kangaroo near the right side of the screen?
3572: jr z,$3598

3574: ld hl, $e118 *** Get Gorilla initial start horizontal location point @$E118 (it does this once the routines above find player location)
3577: ld (hl), c *** Value in C sets new Gorilla Horizontal Location @$E118
3578: inc hl *** Move date pointer HL to Gorilla Vertical Location @$E119
3579: ld (hl), b *** Value in B sets new Gorilla Vertical Location @$E119
357a: inc hl *** Move data pointer in HL to @$E11A "Gorilla State"
357b: ld (hl), d
357c: ret *** Other routines use the values (c,b,d) set here in $E118 to display the Gorilla on screen, play music/fx, collision detection ***

357d: cp $60 *** Checking $E0C1 Kangaroo horizontal. Compare Kangaroo at vertical position 60 between platform 2(28) and 3(7C)? ***
357f: jr nc,$3585
3581: ld b,$48 *** Set B with vertical Location=48 for platform 2 Gorilla appearance
3583: jr $3558

354f: cp $9c
3587: ret nc

3588: ld b,$7c *** Set B with vertical Location=7C for platform 3 Gorilla appearance
358a: jr $3558

358c: ld a,$00 *** if =00 then the game is going to loop through the rest of the code cycle until the right "random" values from $EF00 occur
358e: ld ($e039),a *** Save this as a "flag" in memory for the code above to check
3591: ret

___________________________________________________________________________

After messing around with the code and memory above, I am pretty sure of my findings even without seeing the code dumped from an actual arcade machine/nor ever seeing what is inside the missing MB8841. I even made several patched hacked roms with different tweaks to the code above to make sure. I was able to make the Gorilla come out right away. I was able to set a more accurate "static" timer that prevented the Gorilla from repeat appearing like it does in MAME (although there is no real random time added to the initial appearance time this way). I was also able to make the Gorilla never come out out all. By messing with the values coming out of $EF00 I manipulated the game into making the Gorilla appear at any bonus time I wanted.

If someone can get the MAME developers a dump of the missing rom in question, then they may be able to fix the current MAME driver/romsets (that requires a very custom random timer to make the Gorilla appearance work right).
Last edited by jerky on Sat Dec 27, 2014 8:16 pm, edited 3 times in total.

jerky
Button Slapper
Button Slapper
Posts: 14
Joined: Sat Apr 12, 2014 4:22 pm

Re: This is why the MAME emulation of Kangaroo is inaccurate

Post by jerky » Sat Dec 27, 2014 7:19 pm

mahlemiut wrote:Perhaps a bug report ought to be filed at MAMETesters...
The MB8841 MCU is emulated by MAME, but without the code dumped (which is likely not to be easily possible), you just have to simulate what it does.
I am going to contact them and share my findings. Its hard to simulate a custom randomizer code without the actual rom chip though. We need a good dump (so to speak...insert laugh track here).

User avatar
mahlemiut
Editor
Posts: 4133
Joined: Mon Feb 04, 2002 10:05 pm
Location: New Zealand
Contact:

Re: This is why the MAME emulation of Kangaroo is inaccurate

Post by mahlemiut » Sat Dec 27, 2014 7:44 pm

https://github.com/mamedev/mame/blob/ma ... kangaroo.c -- this is the current driver source

But yeah, it looks like it only does enough to "work". Actual use is unknown, any info gained would be useful.
- Barry Rodewald
MARP Assistant Web Maintainer
Image

Haze
MARP Knight
MARP Knight
Posts: 349
Joined: Sat Mar 23, 2002 5:04 pm

Re: This is why the MAME emulation of Kangaroo is inaccurate

Post by Haze » Mon Jan 05, 2015 8:08 am

Yeah, it's certainly a real issue, and truth be told not that uncommon.

The further back you go, the more likely you are to find things (inaccurately) simulated compared to recent versions; as we've said a thousand times something like 0.106 is inferior in every way to current versions for 98% of the emulated library, it amazes me some official record sites insist on it - even if we were to fix this bug with a decap and proper emulation of the device some would still insist that 0.106 is used! I'm actually a little surprised MARP doesn't have a '1st place' rule stating that old versions can't take 1st place / trump new ones - people recording with old versions is entirely counterproductive to us.

Anyway.. In more recent times an MCU of the same type was decapped for Pettan Pyuu, improving emulation of that game (although I do still wonder about the weird jumpy tile behavior you get when trapping an enemy (2nd how to play demo in attract) and it was found that the same MCU dump also worked with 'Arabian' to provide better emulation of the bird - a little surprising because MCUs are usually programmed differently between games.

I don't know if anybody has attempted to see if Kangeroo also used the same MCU code, although it does indicate that this type of chip is a valid decapping target, or at least was for the guy who did it, I'm less sure about the current people doing it for us. One of the current guys doing decaps for us is seanriddle, who posts on the bannister.org forums ( see http://forums.bannister.org/ubbthreads. ... 742&page=1 for a thread about TMS chips and some of the work done in MESS using his decaps) If somebody here is willing to sacrifice a board or two (there's always the possibility of failure with this kind of thing) it might be worth contacting him to find out if he knows anything about that type of chip, and find out if he can do them (please be aware if they're not MASK parts inside the answer is almost certainly no)

It is not uncommon for groups who are passionate about improving the emulation of certain things, or even repairing PCBs to get together and fund ventures like this, the recent work on finding out how to reprogram the Capcom Kabuki chips is one such example ( http://arcadehacker.blogspot.co.uk/ ) so if you guys really care a lot about this then it's an avenue you should probably explore further IMHO. (you might want to make sure the existing MCU dump from Pettan Pyuu isn't suitable first mind you, it might really be that Sun Electronics just reused the exact same protection MCU code across their games)

Despatche
Button Masher
Button Masher
Posts: 33
Joined: Mon Jan 31, 2011 9:25 pm

Re: This is why the MAME emulation of Kangaroo is inaccurate

Post by Despatche » Fri Jan 16, 2015 10:29 am

The problem is that newer versions of MAME run like ass for a bunch of reasons that have nothing to do with game-specific accuracy. You could backport so many game fixes to v0.106 (as an example) and it would be a hundred times better than seriously trying to use v0.157 or whatever.

Unless you're really serious about leaving the purpose of MAME in the past (which means you need to give up MAME as a project and force everyone to use UME), there needs to be an officially backed "lite" version of MAME without the awful new video code, without all the otherwise pointless slot machines (I do not have anything against them) and pinball sets (unless MAME is about to add support for VPin or FPin, this is supposed to be PinMAME's job anyway), and last but not least with the supposedly terrible older GUI that's still coded better than 99% of MAME right now.

I know making demands like this is stupid, but I and a lot of people who use your product (free as it is) can't and shouldn't have to learn how to code, then learn how to deal with the arcane MAME code, then learn how to mesh some arcane MAME code with other arcane MAME code, just to get an emulator that actually works. Learning is great, but the ridiculous amount of effort described is not something that should be forced on anyone when there are tons of people who know very well how to do it and who enjoyed the long years of learning and doing it.

User avatar
mahlemiut
Editor
Posts: 4133
Joined: Mon Feb 04, 2002 10:05 pm
Location: New Zealand
Contact:

Re: This is why the MAME emulation of Kangaroo is inaccurate

Post by mahlemiut » Fri Jan 16, 2015 5:21 pm

Sorry, but for me (and my crappy 5+ year old system), 0.157 runs infinitely better than 0.106. Sure, 0.106 is faster, but X-MAME (only Linux option for 0.106, and the last) is quite awful in places (I'm not a Windows user), a few games don't work or just do weird shit, which the standard win32 version didn't. All the code for all systems is now in one place, and run as similarly as possible across all platforms. MAMEUI is old, outdated, buggy and uses Windows-specific code.

I'm sure it's been mentioned plenty of times before - the number of drivers in MAME does not slow down MAME.
That being said, Micko is working on a new build system for MAME, and hopefully it will be easier to leave out mechanical games when compiling. When that happens, I'm happy to leave them out of WolfMAME.
Micko is also working on BGFX, and plans to eventually incorporate that into MAME for video rendering. This may still be quite some time from happening, however. But it should make way for an improved in-built GUI, also.

And who says you need to code to use it? Download the binary from mamedev.org.
- Barry Rodewald
MARP Assistant Web Maintainer
Image

Haze
MARP Knight
MARP Knight
Posts: 349
Joined: Sat Mar 23, 2002 5:04 pm

Re: This is why the MAME emulation of Kangaroo is inaccurate

Post by Haze » Sat Jan 17, 2015 12:43 pm

Despatche wrote:The problem is that newer versions of MAME run like ass for a bunch of reasons that have nothing to do with game-specific accuracy. You could backport so many game fixes to v0.106 (as an example) and it would be a hundred times better than seriously trying to use v0.157 or whatever.

Unless you're really serious about leaving the purpose of MAME in the past (which means you need to give up MAME as a project and force everyone to use UME), there needs to be an officially backed "lite" version of MAME without the awful new video code, without all the otherwise pointless slot machines (I do not have anything against them) and pinball sets (unless MAME is about to add support for VPin or FPin, this is supposed to be PinMAME's job anyway), and last but not least with the supposedly terrible older GUI that's still coded better than 99% of MAME right now.

I know making demands like this is stupid, but I and a lot of people who use your product (free as it is) can't and shouldn't have to learn how to code, then learn how to deal with the arcane MAME code, then learn how to mesh some arcane MAME code with other arcane MAME code, just to get an emulator that actually works. Learning is great, but the ridiculous amount of effort described is not something that should be forced on anyone when there are tons of people who know very well how to do it and who enjoyed the long years of learning and doing it.
People (outside of MAME) have tried to backport things, inevitably they've given up because they realise that a LOT of the changes being made in MAME are really, really helpful and make development much easier; the amount of MAME related code you had to write in addition to just the emulation of the components was absurd, the lack of a proper object oriented development pattern meant that the same code was copy + pasted all over the place, or as soon as people needed two instances of something in a driver.

'Old MAME' was really nothing more than some cheap hacks thrown together to run some arcade games based on what we understood at the time, and it's fair to say our understanding of things at the tie was limited, the variety of cases we'd encountered was smaller, and therefore what we understood the needs of our code to be was even more limited. The project has evolved based on what we've discovered over the years and a desire to have better cleaner code.

Things like the new video system came out of necessity, the ability to emulate multi-screen games without just pretending that everything was one big screen for instance. (alloweing for much cleaner, and more readable code)

As Barry has said, the slot machines / pinballs don't make MAME any slower, well except for the MAMEUI interface, but that's because, as we've said a thousand times, the MAMEUI interface actually *is* terrible Windows 9x era code, even if you seem to want to defend it, it's one part of the project that has not evolved with everything else, and it shows.

Cleaning up the code, making it easier to work with, making it more stable (safety checking on various operations), making it easier to understand etc. has had performance impacts - Old MAME for instance bypassed the memory system entirely when CPUs accessed memory to execute opcodes meaning that if a CPU crashed it could easily try fetching a byte passed the allocated ROM, it also meant that CPUs couldn't execute code on ROM/Bank boundaries without hacks (some of which were still being found and removed as recently as last year) It meant that things could fail in unexpected ways due to idiosyncrasies MAME's behavior / design, these days it's slower, but it's bullet proof, and we don't have to worry about cases like that. Really old versions even required you to have completely separate implementations of video code for rotated games, required you to provide lists of colours used by each frame for palette compression, required you to manually specify if any single frame in a running game might possibly use more than 256 colours; like i've said, it required a whole bunch of code per driver, per game, that wasn't related to the hardware emulation at all, that was bad.

The future of MAME may well be UME style, one of the things Micko has stated is that he'd like to ship our project (MAME and MESS) as simply 'MAME' in the future, and there are discussions about how the device model will work in the future, with machines simply becoming devices you can add to the running state so you could theoretically be running a pacman mahine, a donkey kong machine and sega master system all at the same time. Why? because MAME and our codebase is now close to the point of being perfectly object oriented with no nasty globals but instead fully reusable devices that can be instanced any number of times as needed within our current tree hierarchy - if somebody took a look at the 0.106 codebase and you told them that one day this would be possible they'd laugh at you due to the volume of work it would required.

You seem to talk a lot about the purpose of MAME, but I don't really think you know much. We're not leaving any purpose in the past, we're just constantly improving things based on new needs and new findings. We want a flexible development environment, where it's as easy as possible to emulate things regardless of how obscure their needs are, and we're getting closer to that every day. We want to create a useful collection of code, a good reference for anybody who needs a reference, there was even talk about the possibility of using MAME as the basis of some in-circuit emulators, which is an interesting long-term goal, we're definitely not quite there yet. The pinball stuff, it's quite possible one day will become a drop-in replacement for PinMAME, but more modern and far less of a dead-end codewise. MAME was created to be useful, for MAME to continue to be useful it has to evolve, develop, move forward. If it hadn't evolved something else would have simply replaced it and we wouldn't be talking about MAME here, or anywhere else, it would be like Sparcade, Retrocade or something along those lines, emulators that are almost at the point where you need another emulator to run them!

Anyway, the topic was about Kangeroo, somebody should really see if it's possible the Arabian MCU fits at all, or see if they can get one decapped.

Despatche
Button Masher
Button Masher
Posts: 33
Joined: Mon Jan 31, 2011 9:25 pm

Re: This is why the MAME emulation of Kangaroo is inaccurate

Post by Despatche » Tue Jan 20, 2015 4:42 pm

mahlemiut wrote:I'm sure it's been mentioned plenty of times before - the number of drivers in MAME does not slow down MAME.
That being said, Micko is working on a new build system for MAME, and hopefully it will be easier to leave out mechanical games when compiling. When that happens, I'm happy to leave them out of WolfMAME.
Micko is also working on BGFX, and plans to eventually incorporate that into MAME for video rendering. This may still be quite some time from happening, however. But it should make way for an improved in-built GUI, also.

And who says you need to code to use it? Download the binary from mamedev.org.
Like I said, MAME itself is mostly fine. The game list doesn't affect MAME, it affects all currently supported UI systems. The current UIs are absolutely terrible and a new one really needs to be coded, and I suggest something at least functionally based on the older UI that we all know and love (hate).
Haze wrote:Things like the new video system came out of necessity, the ability to emulate multi-screen games without just pretending that everything was one big screen for instance. (alloweing for much cleaner, and more readable code)
And that's fine. The problem is that video system itself doesn't run nearly as well as it should, especially for pretty much any older game. You can go on and on about "well newer computers can deal with it", and that's exactly the problem; why deal with it at all? Why go through all the effort of making something and not take the extra bit of time to make it work?
Haze wrote:As Barry has said, the slot machines / pinballs don't make MAME any slower, well except for the MAMEUI interface, but that's because, as we've said a thousand times, the MAMEUI interface actually *is* terrible Windows 9x era code, even if you seem to want to defend it, it's one part of the project that has not evolved with everything else, and it shows.
I'm not defending the code, I'm defending the fact that the damned thing actually works. "Windows 9x era" isn't even the problem, as pretty much all new coding tools are godawful and barely work for the platforms they support.
Haze wrote:You seem to talk a lot about the purpose of MAME, but I don't really think you know much. We're not leaving any purpose in the past, we're just constantly improving things based on new needs and new findings. We want a flexible development environment, where it's as easy as possible to emulate things regardless of how obscure their needs are, and we're getting closer to that every day. We want to create a useful collection of code, a good reference for anybody who needs a reference, there was even talk about the possibility of using MAME as the basis of some in-circuit emulators, which is an interesting long-term goal, we're definitely not quite there yet.
Not one bit of what you said has anything to do with what MAME is about, and not one bit of what you said has anything to do with "evolving", never mind that "evolving" is never inherently good. You're speaking in the buzzwords and the arcane language that a salesman would.

If there is a fundamental problem with MAME, it's the same fundamental problem that all programmers today suffer: they completely despise what they're doing yet insist that it's the only thing they will ever do with their lives, which causes whatever they make to suffer. They look at programming like it's some kind of slave labor "normal" job, especially if it's for anything relating to FOSS.

(On that note, if I have ever said that I have disliked FOSS for any reason, that is why. People make fun of Windows and Mac all day, and they do absolutely nothing to stop what they so claim to despise even though they know they can and have even done so.)

Haze
MARP Knight
MARP Knight
Posts: 349
Joined: Sat Mar 23, 2002 5:04 pm

Re: This is why the MAME emulation of Kangaroo is inaccurate

Post by Haze » Wed Jan 21, 2015 6:21 am

Despatche wrote: Not one bit of what you said has anything to do with what MAME is about, and not one bit of what you said has anything to do with "evolving", never mind that "evolving" is never inherently good. You're speaking in the buzzwords and the arcane language that a salesman would.

If there is a fundamental problem with MAME, it's the same fundamental problem that all programmers today suffer: they completely despise what they're doing yet insist that it's the only thing they will ever do with their lives, which causes whatever they make to suffer. They look at programming like it's some kind of slave labor "normal" job, especially if it's for anything relating to FOSS.

(On that note, if I have ever said that I have disliked FOSS for any reason, that is why. People make fun of Windows and Mac all day, and they do absolutely nothing to stop what they so claim to despise even though they know they can and have even done so.)
I really don't see where you're coming from.

Most of what I've said has *everything* to do with MAME, because if we hadn't developed, and improved things the way we have the project would have stalled and died years ago, there would be no 'MAME' at all.

Creating an environment where people can quickly go from having a ROM dump and a few sketchy hardware details to having something very well emulated is fundamental, and having worked closely with the project over a number of years I can honestly say that is easier than ever these days - for some cases it's possible to go from 0 to 'working' in under an hour, previously that might have taken days.

Aaron was quoted years ago as saying he thought some things would never be emulated, we've seen the same time and time again, but because the project has evolved, and made things easier to work with we have seen things emulated that people thought would simply be too difficult to emulate, I'm currently ponding whether or not to look at Atari's Metal Maniax which is one he said would never be fully emulated - at the time the very idea of having to emulate multiple PCB stacks with the insane number of CPUs present was just inconceivable, these days it's actually very realistic because the codebase is so much better, the rest of the hardware IS still a bitch tho.

If being *able* to emulate things isn't one of the purposes of MAME then I do have to wonder where you're coming from. MAME being as easy to develop for and the vast library of resources it is has saved a great, great number of games, allowed us to identify dumping problems quickly before PCBs were sold on or put back together after desoldering etc.

It saddens me that this isn't really visible form the outside.

jerky
Button Slapper
Button Slapper
Posts: 14
Joined: Sat Apr 12, 2014 4:22 pm

Re: This is why the MAME emulation of Kangaroo is inaccurate

Post by jerky » Wed Jan 21, 2015 7:30 pm

I don't know if anybody has attempted to see if Kangeroo also used the same MCU code, although it does indicate that this type of chip is a valid decapping target, or at least was for the guy who did it, I'm less sure about the current people doing it for us. One of the current guys doing decaps for us is seanriddle, who posts on the bannister.org forums ( see http://forums.bannister.org/ubbthreads. ... 742&page=1 for a thread about TMS chips and some of the work done in MESS using his decaps) If somebody here is willing to sacrifice a board or two (there's always the possibility of failure with this kind of thing) it might be worth contacting him to find out if he knows anything about that type of chip, and find out if he can do them (please be aware if they're not MASK parts inside the answer is almost certainly no)

It is not uncommon for groups who are passionate about improving the emulation of certain things, or even repairing PCBs to get together and fund ventures like this, the recent work on finding out how to reprogram the Capcom Kabuki chips is one such example ( http://arcadehacker.blogspot.co.uk/ ) so if you guys really care a lot about this then it's an avenue you should probably explore further IMHO. (you might want to make sure the existing MCU dump from Pettan Pyuu isn't suitable first mind you, it might really be that Sun Electronics just reused the exact same protection MCU code across their games)
Thanks for the information. It would make sense that Sun Electronics might use the same or very similar MCUs for their games and maybe just code the games differently to accept values in various ways like Kangaroo appears to do. I had been trying to put together a list of other Sun Electronics games to debug one by one to see if they were using anything similar to the Kangaroo MCU but work and other things have taken over my limited gaming/code exploring pastime for the moment. I''ll try to track down any related driver code to compare with how Kangaroo is being emulated at the moment (dealing with the MCU). When I get a chance I will at least try to see if from the debug end whether or not any of these other games from the same manufacturer access the MCU the same way Kangaroo appears to.

In the meantime I hope someone can eventually dump the MCU in question to be sure. It would be great if it could be "simulated" properly to make Kangaroo work like it does in a 100% legit arcade cab with the proper MCU in place. I would be happy if there was an updated change in any version of MAME that fixes this. The older version in question (106) came up because that is what I believe some of the scores in question were set on.

I will try to see if some of my arcade gaming world contacts can find someone with the right board to "sacrifice" for the cause. I think we all can agree that improving the emulation for Kangaroo would be a good thing.

Post Reply