MPU4 Character help in MFME

[andrew96]

Possibly just the lamp table is what I will only achieve. Most know how to over come the chr check and checksum, but very few can write code to put in the rom for the lamp table. so a chip with just a lamp table could be quite useful!

[andrew96]

1 hour ago, johnparker007 said:

Hiya   I had a thought... the 'challenge' values, in RED below (from your posted image earlier), so like:

00, 1a, 04, 10, 18, 0f, 13, 1b, etc......
 

For every ROM, I think they are always the exact same sequence of 64 challenge values?  And they do not have repeats within the table sequence.

 

yes red is sent to the chr chip, yellow (in hyper viper case) is the reply.

challenge values are doubled up on so a simple table like for the lamps is a no go

this is some of the challenge values doubled up on! (there may be more!) all reply different values to the first access of them!

so distinguishing between them I cannot see will be easy with just logic and 2 flip flops!

that's why I think barcrest started off with a 'seed' number which somehow all codes are derived from all dependant of the previous values answer!

 

[andrew96]

If I use a sequence it has to distinguish between getting reset at #00 then getting #1a and going through the chr table one after the other....till the end #00, and also #00 for reset then #00 for lamp column 1 then #01 for lamp column 2 etc, now the lamp is NOT read in sequence in hyper viper, it reads 00, 01,01,01,04,04,04,09,09,09,10,10,10  in sequence lots of times before going out of sequence to read some again and then 31,24,19 which is why i used a table for that as the output numbers out don't change 

 

they certainly packed in variation!

Edited September 1, 2021 by andrew96

[johnparker007]

Wow it does sound super complicated to try reverse engineer that chip!  

Again, I'm not an electronics guy really, but would it be possible to actually use some other more modern component that would go in the same socket (or perhaps with an 'adapter') and could run more complex code/logic... some kind of FPGA... if you had something you could deploy compiled C code on (I think you could do that with those 'Pic' chips - then you could just write the code to emulate the operations in there, and not be constrained by the Pal/gal chip architecture.

This is probably totally not possible for a bunch of electronic reasons haha, just trying to think outside of the box 

[andrew96]

these chips are currently available new ( well different numbering but are the same) for around £1

yes I could go to a more complicated fpga, cpld etc but then that means the chip cost goes up, and also some pcb adapter needs to be made etc, I had my fingers burned on getting adapters made up for the fruit machine world in the past so not doing that again!! I learnt my lesson, just do things for myself! I was just eager to find out what they had done and if I could mimic something which I have succeeded on with lamps!! yay!! (well almost)

I think I am nearly at my limits with what I can do ! even barcrest won't know anything about these now as there resources will be long gone! I am really on my own in new territory with this!!

And I don't have lots of old original chr chips to play with!

 

[Tommy c]

Great work guys, excellent.

[hitthesix]

Wow!!! fantastic stuff guys, well done

[stonyat421]

thought you had given up on the mpu4 chr andrew 

why are you not on the mecca any more 

[andrew96]

44 minutes ago, stonyat421 said:

thought you had given up on the mpu4 chr andrew 

why are you not on the mecca any more 

No I have not given up on the technical stuff! I find it too interesting!!

As for the Mecca...... with the negative comments it was no longer fun! and you know the slogan... when the fun stops stop! 

[andrew96]

Anyway more has been discovered about the chips! they are NOT PAL16 chips, they appear to be a custom version of them for which there is no information on the internet!! they quite possibly have more internal loops back to the logic array as they seem to do far more than a standard PAL chip can accomplish!

I am very happy I managed to get the lamp table into a GAL16v8 which works! but the resources for a character table as far as I can see are just not there!! they could be possible if the 2 unused flip flops could be fed back into the array, but this seems impossible due to the chips not having the 'node' or 'pinnode' commands (all outputs from the flip flops have to be connected to physical pins to be able to feed them back into the logic array). this is what leads me to believe the chips used were custom with the extra pinnodes and most likely custom software to use on designing them! I cannot see any other way of being able to manipulate the data in such ways necessary to produce all the output combinations,  192 for the character table possible values (yes its 64 x 3 in reality) and  24 for the lamp table (3 x 8 of which 8 are accessed) so 216 different combinations of output numbers PLUS 00 to reset it of course, that's a lot of data for one small PAL chip which I think a normal PAL or GAL chip could never handle!

But I am happy with by modest 8 column lamp table! 

I think with the work John Parker has managed there is really no need for me to progress further as he has broken all this totally with 'adjustments' to the rom code!

I have done what I set out to achieve as when I started no one had cracked the lamp tables for real machines! It has progressed so quickly that producing a real chip for real machines I set out to do at the beginning of the thread is now 'outdated'!

[andrew96]

 

So So So many errors when you cannot bring the pins allocated as  FF0 and FF1 out to real pins!!! 

Been trying to find a way to do that for about 3 days, but PAL chips can't do it, cpld  and fpga CAN but I am not going down that route!

[stonyat421]

34 minutes ago, andrew96 said:

 

So So So many errors when you cannot bring the pins allocated as  FF0 and FF1 out to real pins!!! 

Been trying to find a way to do that for about 3 days, but PAL chips can't do it, cpld  and fpga CAN but I am not going down that route!

cpld  and fpga CAN but I am not going down that route!

i gave up ages ago mate think john has the answer with his patcher reminds me of the old days when keygens were the answer to patching software 

[andrew96]

22 hours ago, stonyat421 said:

cpld  and fpga CAN but I am not going down that route!

i gave up ages ago mate think john has the answer with his patcher reminds me of the old days when keygens were the answer to patching software 

It's fun patching the roms manually!!

[loo]

from reading this and what you have said about generating the output from the input data, it reminds me very much of cyclic redundancy check, thats a shift register with some logical feedback. perhaps they implemented a custom crc algorithym. just a thought.

[andrew96]

Well after extensive testing, here is what I have found since last year........ the patching of the rom to exclude the CHR check is fine...... it is the lamp table that is causing problems with machines!  the lamps may well be correct, but it seriously messes with the percentage making some real machines really really bad!! MFME uses one set of lamp figures where in a real chip it uses 3 DIFFERENT tables to get the lamp table, therefore MFME sorta 'fudges' the figures to work! but I believe the real CHR chip with its different tables may be also seeding some percentage calculation too. Barcrest do seem to have MPU4 buttoned up really well when they did the CHR chips!

 

So patching roms may or may not work for you....

[andrew96]

Basically at NO POINT does the lamp table in MFME match ANY of the 3 tables in the real CHR chip, the software code somehow comes up with the right lamp table from the 3 tables in the CHR chip!! If the software can do that it is very likely so mother manipulation is taken place for percentages too.

I guess its fine for MFME where your not playing with actual cash! but not good for real machines!

[johnparker007]

@andrew96 totally man    I've recently had a situation where my current approach for MPU4 patching doesn't work for Cloud 999 on real hardware.  Works perfectly fine on emulator!  Patching's currently a bit of a bodge, at least my ones are... currently I bypass the checksum, though I suspect the machine may 'know'... it's always a struggle for free time to work on these things though...

Better way, which is a classic old way, is to find some spare bytes, figure out/decomp the algo it's using to build the checksum, then simple use a brute force or whatever to get the required bytes to get your patched ROM (with say just a simple lamp bypass routine, and chr routine BNE/BEQ swap) so it has the original checksum, and job's a good'un.  Can try finding/patching the actual expected checksum, but that can have other issues.

Coincidentally I've been side-tracked recently as had a request for an MPU3 patch - looked into it and they're a lot easier than MPU4 to bypass, at least the few I've tried on... the first one is winging it's way to a real machine as I type (A Lucky Strike Club MPU3) - hopefully it will work fine, it does work correctly in emulator.


For your approach of building a replacement MPU4 chr chip - could something like this be used?

Raspberry Pi Pico - £6.60
RP2040 microcontroller chip designed by Raspberry Pi in the United Kingdom
Dual-core Arm Cortex M0+ processor, flexible clock running up to 133 MHz
264KB of SRAM, and 2MB of on-board Flash memory
Castellated module allows soldering direct to carrier boards
26 × multi-function GPIO pins

https://www.amazon.co.uk/Raspberry-Pi-Pico/dp/B09KVB8LVR/ref=sr_1_3?crid=3SG98I7DSFFJI&keywords=pi+pico&qid=1645125431&sprefix=pi+pico%2Caps%2C118&sr=8-3

If programmed correctly, could it read/write the correct voltage signals through those GPIO pins?

It could be updated since it's just software, so the software could support a library of machines.. though it would require some kind of socket I guess, so it starts to get expensive - since you'd realistically need socket+RPi per machine. Plus it'd need power from somewhere... so not a perfect mod, but it could perhaps work  

Edited February 17, 2022 by johnparker007

[andrew96]

oh MPU3, I was going to look into the CHR on those but was told no point as they are easy to patch out and are easily done! threads are about showing how easy it is!

As for MPU4....... I am not planning to do any more on this front, My aim was to work out how its done, which I found and even a simple Microchip PIC chip could easily emulate a real CHR. Rather like Barcrest moved to PIC chips on MPU5! I doubt anyone would want to take up the challenge as its always 'end user cost' that's the big problem, things manufactured are always to expensive for fruit machine collectors it seems! but no such constraints when it comes to pinball, people will shell out several hundred for a new remanufactured pinball MPU! seems so different!!

So if anyone fancies the challenge it is up for grabs!! I won't be going any further now, in fact in the past year I have very much moved away from fruit machine related electronics. I lost a lot of interest over the time and am at the end now of doing anything more really

[andrew96]

2 minutes ago, andrew96 said:

As for MPU4....... I am not planning to do any more on this front, My aim was to work out how its done, which I found and even a simple Microchip PIC chip could easily emulate a real CHR. Rather like Barcrest moved to PIC chips on MPU5!

To do this your need a real chip first on a program card, then something like I have (and shown in the earlier pages) a fluke 9010 and a 6809 pod, and a working mpu4, then use the fluke to interrogate the 3 different tables it contains for the lamps (as I have said before none of these match the MFME table and I could find no connection between the 3 inside the chip and the one on MFME), then use the tables to create a PIC chip which gives out the right data in the sequence when needed, and design a plug in pcb which plugs in place of the CHR chip which will contain the PIC chip on, then all will be good!!

That's one way round it!! the other way is to patch the rom and put up with the poor play the machine gives... which I think will be the current option people will do!

[johnparker007]

I believe the poor play is down to these basic checksum bypass patches/basic chr prot/lamp bypasses, like my system does at present... I know a couple that actually behave differently in MFME along with a real Cloud 999... in the future I'll do a better solution for the checksum bypass and chr stuff protection stuff, that I suspect will fix the gameplay issues (the additional reads don't really happen on the 6809 side from what I can see, even though you see them when probing).  The gotcha is that is may need additional free space, there's not much free bytes in those ROMs! 

Once I've finished up this basic bypass MPU3 patcher, I'll be back on Arcade Sim anyway, so be a while before I can get into that stuff...


But plan is to sort out 'stealth bypass'... and then can test for known issues with the 'basic bypass' method, which should then be fixed - fairly optimistic that will sort things out - it's just getting the damn time to work on it!

Good luck with your future hobby projects anyway, I'm sure you'll find something cool to hack  

[johnparker007]

I had another thought  so if this:

the other way is to patch the rom and put up with the poor play the machine gives

were the inescapable fact due to these extra values you seen when you probe the Chr out of circuit, that would mean that all the long term percentages would be wrong in MFME when people play machines that don't have emptiers/exploits, or leave them on autoplay for a long time.

If it held true that the simplified model that MFME/MAME use to provide the expected values to the ROM code were erroneous and causing poor play, then it'd be easily seen and repeatable, with massive 'drift' from the expected payout percentage.

If this is actually repeatable, so there's an MPU3/4 machine, that when run in MFME on autoplay for say 1 day, has a very large drift from the expected payout %age, I'd like to know about it, as it could be a way into improving the emulation accuracy!

As far as I'm aware though, these big drifts from expected payout %age don't occur... which would seem to mean that the 'hidden' tables you are detecting via probing don't make it into the wider running codespace.

My theory is (currently) that weird behaviour like this is down to these patching techniques (that I'm also using)... and could be remedied with stealthier patches, to be investigated when I next get chance to work on this after another chunk of Arcade Sim work.

We'll get there in the end!

Edited February 18, 2022 by johnparker007

[andrew96]

so why would barcrest go to the trouble of putting 3 different lamp tables in which are accessed all the time rather than one character check table which is just stepped through in sequence....... lamp tables in some places are not stepped through in sequence in a real machine giving different step codes. Unless someone goes through the code step by step seeing what it does and how it interreacts in software we will never know! but Barcrest went to some trouble with some tricks it seems to me.

[andrew96]

Anyway I am just passing on what has been found out in a real machine with a patched fixed 1 lamp table.  It definitely makes for poor play in some machines. Maybe in some machines its perfect.....but who knows which roms were written with this wider implication in them to prevent CHR hacks!

I agree rom patching is good for MFME as your not playing with real money, its for the fun of it! but in a real machine in a real arcade it is dangerous for sure!!!

[serene02]

I remember something Chris talked about many many years ago. That Barcrest used a lot of ‘Red Herrings’ in the chr check.  Could this be the case with what you are finding on the real hardware Andrew?

J

[johnparker007]

31 minutes ago, andrew96 said:

Anyway I am just passing on what has been found out in a real machine with a patched fixed 1 lamp table.  It definitely makes for poor play in some machines.

Which machine has the poor play please?  And how easy (and quickly via a playthrough from a cleared RAM) can this be replicated?

If this can be gotten down to a reliable STR (steps to reproduce)

This is longterm, as I have to wrap up the basic version of MPU3 patching and get back to Arcade Sim tasks, but if that behaviour does not repro in MFME, using an unpatched ROM, then that would suggest that 'perfect' patching is ultimately possible (hopefully via stealth patches that fix checksum in junk bytes etc).

I'm already aware of some test machines with good STR (using a unstealth patched ROM), but more would always be welcomed!  

So then these STR can be used to objectively verify (or not as the case may be!) whether the stealth patch ROMs work correctly, initially on emulation, and then on real machines.

It's a fun corner of the scene, that still needs work - and we can hopefully save lots of machines from the tip, be it via PIC chip type replacements, or stealth patched ROMs... these Chr chips are going to keep dying/getting lost...