Jump to content

MPU4 Character help in MFME


andrew96
 Share

Recommended Posts

Hi, I am trying to work out the CHR chip in MPU4 and wondered of someone that had knowledge of running MPU4 in MFME might be able to help (as I know nothing on the pc emulation side, just real hardware)

 

I know the character check is preformed by a question answer response by sending address #800. I understand how that works....

 

What is eluding me is the lamp table mapping also stored in the CHR chip, does anyone know if there is a different code sent to access this table? or does it continue to send and read from address #800 for this too once the chr response is done? I believe the lamp table is  8 bytes of info.

 

so really my question is, does anyone know anything about this by looking at the debug side of MFME...  I sort of know this can show what is going on in the code, but I have no experience of MFME so have no real idea about using it etc.

 

Hopefully there is someone brainy that know the in's and out's of it !

 

many thanks in advance

Andrew

 

 

 

Link to comment
Share on other sites

18 hours ago, andrew96 said:

I know the character check is preformed by a question answer response by sending address #800. I understand how that works....

On the character chip I am working on, orange is the data sent to the character chip, yellow is its answer, this concludes the character check table for the game. (this is the calculated value, the actual values returned as it drops bits 0 and 1)

I don't know the lamp table codes after that yet! but trying to work on it....

 

perhaps I am asking in the wrong section of the forum? I thought there would be some s*it hot people that know MFME workings and could help

 

IMG_4171.jpg.c03fb35dc1d8e204a9e33b7acc4e2d5c.jpg

  • Like 1
Link to comment
Share on other sites

Hi Andrew on your original Q about the lamps having a differnt line of code I would say yes to a certain extent. Different revision numbers only follow the same character with revision numbers following in suit. So 0.1 0.2 etc. Once it changes to 1.0 the lamps which work with v 0. Will.now be jumbled up and completely wrong in that game.

  • Like 2
Link to comment
Share on other sites

@andrew96 I rewrote a bit of MPU4 stuff to do with chr in MAME, haven't got round to committing yet... there's some good info in the source you might be interested in :)   It's a challenge/response doohickey, I think they were trying to stop people copying the boards with off the shelf parts and chip burners.

In terms of the lamps (for non-BwB), there was this - it maps the lamp matrix column based on input value, based on square series (0,1,4,9,16,25 etc - so 1x1==1, 2x2==4, 3x3==9, 4x4==16 etc)

        // Rather than the search strategy, we can map the calls directly here. Note that they are hex versions of the square number series
        switch (call)
        {
        case 0x00:
            m_lamp_col = 0;
            break;

        case 0x01:
            m_lamp_col = 1;
            break;

        case 0x04:
            m_lamp_col = 2;
            break;

        case 0x09:
            m_lamp_col = 3;
            break;

        case 0x10:
            m_lamp_col = 4;
            break;

        case 0x19:
            m_lamp_col = 5;
            break;

        case 0x24:
            m_lamp_col = 6;
            break;

        case 0x31:
            m_lamp_col = 7;
            break;


One of the key source files:
https://github.com/mamedev/mame/blob/master/src/mame/machine/mpu4.cpp


Some interesting comments from the source:

As built, the CHR is a PAL which can perform basic bit manipulation according to
an as yet unknown unique key. However, the programmers decided to best use this protection device in read/write/compare
cycles, storing almost the entire 'hidden' data table in the ROMs in plain sight. Only later rebuilds by BwB
avoided this 'feature' of the development kit, and will need a different setup.

This information has been used to generate the CHR tables loaded by the programs, until a key can be determined.
For most Barcrest games, the following method was used:

The initial 'PALTEST' routine as found in the Barcrest programs simply writes the first 'call' to the CHR space,
to read back the 'response'. There is no attempt to alter the order or anything else, just
a simple runthrough of the entire data table. The only 'catch' in this is to note that the CHR chip always scans
through the table starting at the last accessed data value, unless 00 is used to reset to the beginning. This is obviously
a simplification, in fact the PAL does bit manipulation with some latching.

However, a final 8 byte row, that controls the lamp matrix is not tested - to date, no-one outside of Barcrest knows
how this is generated, and currently trial and error is the only sensible method. It is noted that the default,
of all 00, is sometimes the correct answer, particularly in non-Barcrest use of the CHR chip, though when used normally,
there are again fixed call values.

Apparently, just before the characteriser is checked bit 1 at 0x61DF is checked and if zero the characteriser
check is bypassed. This may be something to look at for prototype ROMs and hacks.


...

BwB Characteriser (CHR)
The BwB method of protection is considerably different to the Barcrest one, with any
incorrect behaviour manifesting in ridiculously large payouts. The hardware is the
same, however the main weakness of the software has been eliminated.
In fact, the software seems deliberately designed to mislead, but is (fortunately for
us) prone to similar weaknesses that allow a per game solution.
Project Amber performed a source analysis (available on request) which appears to make things work.
Said weaknesses (A Cheats Guide according to Project Amber)
The common initialisation sequence is "00 04 04 0C 0C 1C 14 2C 5C 2C"
                                        0  1  2  3  4  5  6  7  8
Using debug search for the first read from said string (best to find it first).
At this point, the X index on the CPU is at the magic number address.
The subsequent calls for each can be found based on the magic address
           (0) = ( (BWBMagicAddress))
           (1) = ( (BWBMagicAddress + 1))
           (2) = ( (BWBMagicAddress + 2))
           (3) = ( (BWBMagicAddress + 4))
           (4) = ( (BWBMagicAddress - 5))
           (5) = ( (BWBMagicAddress - 4))
           (6) = ( (BWBMagicAddress - 3))
           (7) = ( (BWBMagicAddress - 2))
           (8) = ( (BWBMagicAddress - 1))
These return the standard init sequence as above.
For ease of understanding, we use three tables, one holding the common responses
and two holding the appropriate call and response pairs for the two stages of operation

 

Edited by johnparker007
  • Like 7

[ Arcade Simulator ] Pre-alpha installer: http://arcadesimulator.net  |  Known Issues: https://tinyurl.com/yz4uom2e  |  Donation info: https://tinyurl.com/yzvgl4xo
[ Community Drive ] The drive: http://tinyurl.com/yckze665
[ Fruit Machine Database ] Initial google sheets (WIP): https://tinyurl.com/2c5znxzz
[ MFME Launch ] Source code: https://github.com/johnparker007/MFMELaunch
[ Oasis ] Source code: https://github.com/johnparker007/Oasis
[ Sound ROM Editor ] Source code: https://github.com/johnparker007/SoundRomEditor

Link to comment
Share on other sites

Oh Thankyou john! that does look very interesting and I will have to spend some time reading it thoroughly!

 

The character side is a challenge response just as you say, The CHR challenge / response table is in the rom!

IMG_4171.jpg.f504fd94d26fb5c699e48165119a79e2.jpg

Orange is sent to the chr chip and yellow is the response from the CHR chip, as you say in sequence running through the table

So I connected up my fluke trouble-shooter, thus takes the place of the CPU so you can basically BE the processor and send/receive and show data just like the CPU would, only you have complete control!

 

you can see in the video below I send data #00 to address #800 (the address the CHR chip is accessed) its response is seen to be #00, actually the response back is #03 and the last 2 bits are discarded so it it becomes #00

 

you can then see I send the next in the table #1A and get the response when read back of #C3 (again last 2 bits will be discarded so #C0)

 

you can see the video of the write and reads to and from the CHR chip on a REAL CHR chip and motherboard!

https://youtu.be/FWioGzFdt7E

 

 

 

Entering ANY codes out of sequence completely messes up the CHR response after that, that's why 'bit bashing' the CHR chip (applying codes to the input and seeing what is on the output) is totally useless and probably the reason why these CHR chips have never been able to be reproduced!

 

I still yet have to find the lamp table!! and I don't mean one of these!

lunnarp-side-table-white__0766326_pe7537

 

 

 

 

 

 

 

  • Like 5
  • Haha 1
Link to comment
Share on other sites

11 hours ago, johnparker007 said:




Some interesting comments from the source:

As built, the CHR is a PAL which can perform basic bit manipulation according to
an as yet unknown unique key. However, the programmers decided to best use this protection device in read/write/compare
cycles, storing almost the entire 'hidden' data table in the ROMs in plain sight. Only later rebuilds by BwB
avoided this 'feature' of the development kit, and will need a different setup.

Thats what I found!!!

This information has been used to generate the CHR tables loaded by the programs, until a key can be determined.
For most Barcrest games, the following method was used:

The initial 'PALTEST' routine as found in the Barcrest programs simply writes the first 'call' to the CHR space,
to read back the 'response'. There is no attempt to alter the order or anything else, just
a simple runthrough of the entire data table. The only 'catch' in this is to note that the CHR chip always scans
through the table starting at the last accessed data value, unless 00 is used to reset to the beginning. This is obviously
a simplification, in fact the PAL does bit manipulation with some latching.

Perfect, that too is what I found! Its in my video! as far as I can see, he value is sent to the PAL chip, it then latches the d type flip flops with the data out which is then enabled to get the output when it is asked to read it back, any 'write' out of sequence causes any old data to come out which is not sequenced in the table and thus the check fails! that's why trying to brute force a chip by giving it data and seeing he output to obtain the code does not work! Barcrest have been very clever here!!!!

However, a final 8 byte row, that controls the lamp matrix is not tested - to date, no-one outside of Barcrest knows
how this is generated, and currently trial and error is the only sensible method. It is noted that the default,
of all 00, is sometimes the correct answer, particularly in non-Barcrest use of the CHR chip, though when used normally,
there are again fixed call values.

I think that's my answer, no one knows!!! so I am intrigued on how MFME generated the table..... it has to surely  or all the games that use lamp table bytes would not light up correctly....

Apparently, just before the characteriser is checked bit 1 at 0x61DF is checked and if zero the characteriser
check is bypassed. This may be something to look at for prototype ROMs and hacks.

yes that works fine as long as there is no lamp table! also the checksum has to be over ridden too!

 

Many thanks, my findings are in red!! 

  • Like 1
Link to comment
Share on other sites

Many thanks Johnparker!

the penny has dropped!!!

 

 

/* CHR Tables */
   
  static mpu4_chr_table andycp10c_data[72] = {
  {0x00, 0x00},{0x1a, 0x14},{0x04, 0x04},{0x10, 0x54},{0x18, 0x4c},{0x0f, 0x20},{0x13, 0x50},{0x1b, 0x44},
  {0x03, 0x5c},{0x07, 0x78},{0x17, 0x70},{0x1d, 0x48},{0x36, 0x6c},{0x35, 0x60},{0x2b, 0x14},{0x28, 0x48},
  {0x39, 0x2c},{0x21, 0x6c},{0x22, 0x6c},{0x25, 0x28},{0x2c, 0x64},{0x29, 0x10},{0x31, 0x08},{0x34, 0x6c},
  {0x0a, 0x24},{0x1f, 0x5c},{0x06, 0x78},{0x0e, 0x34},{0x1c, 0x00},{0x12, 0x50},{0x1e, 0x00},{0x0d, 0x50},
  {0x14, 0x0c},{0x0a, 0x6c},{0x19, 0x2c},{0x15, 0x60},{0x06, 0x54},{0x0f, 0x00},{0x08, 0x58},{0x1b, 0x74},
  {0x1e, 0x00},{0x04, 0x14},{0x01, 0x4c},{0x0c, 0x60},{0x18, 0x1c},{0x1a, 0x74},{0x11, 0x4c},{0x0b, 0x64},
  {0x03, 0x5c},{0x17, 0x78},{0x10, 0x78},{0x1d, 0x78},{0x0e, 0x34},{0x07, 0x44},{0x12, 0x54},{0x09, 0x40},
  {0x0d, 0x50},{0x1f, 0x48},{0x16, 0x6c},{0x05, 0x28},{0x13, 0x60},{0x1c, 0x14},{0x02, 0x4c},{0x00, 0x00},
  {0x00, 0x04},{0x01, 0x58},{0x04, 0x14},{0x09, 0x58},{0x10, 0x50},{0x19, 0x1c},{0x24, 0x10},{0x31, 0x10}
  };

 

In the link it shows a CHR table, interestingly sending #00 and receive #00 the first of the character check is then sent #1a and your in the chr table... but there is the bit on the end in red which looks like the lamp table routine!!

send #00 receive #00 then send #00 and your in the lamp table! that's what it looks like to me, it is the right length too!! 

 

I need to set up the fluke 9020 troubleshooter up again to test this!

 

but i think this could be it!!

IMG_4184.jpg.8d14251d2b885d623d9ec0e855d55436.jpg

  • Like 2
Link to comment
Share on other sites

Cool - glad it helped, sounds like you're making good progress with your experiments :)  

Those last 8 are I believe for setting which column on the lamp matrix to address (so otherwise the lamps end up 'scrambled', but it has no effect on the running of the machine).  Knackered now so my brain's not working, but I think that was it!  

[ Arcade Simulator ] Pre-alpha installer: http://arcadesimulator.net  |  Known Issues: https://tinyurl.com/yz4uom2e  |  Donation info: https://tinyurl.com/yzvgl4xo
[ Community Drive ] The drive: http://tinyurl.com/yckze665
[ Fruit Machine Database ] Initial google sheets (WIP): https://tinyurl.com/2c5znxzz
[ MFME Launch ] Source code: https://github.com/johnparker007/MFMELaunch
[ Oasis ] Source code: https://github.com/johnparker007/Oasis
[ Sound ROM Editor ] Source code: https://github.com/johnparker007/SoundRomEditor

Link to comment
Share on other sites

13 hours ago, andrew96 said:

cheers! it appears the last pic I attached in the post above has not appeared! here it is...

IMG_4184.jpg.5220b2d7d631fcc4633083ea9bec4f39.jpg

Just quickly posting whlie waiting for something at work - I can't remember fully the chr stuff - but this code may be of use to you:
 

void mpu4_state::characteriser_w(offs_t offset, uint8_t data)

{

int x;

int call=data;

LOG_CHR_FULL(("%s Characteriser write offset %02X data %02X\n", machine().describe_context(), offset, data));

if (!m_current_chr_table)

{

logerror("%s No Characteriser Table\n", machine().describe_context());

return;

}







if (offset == 0)

{

{

if (call == 0)

{

m_prot_col = 0;

}

else

{

for (x = m_prot_col; x < 64; x++)

{

if (m_current_chr_table[(x)].call == call)

{

m_prot_col = x;

LOG_CHR(("Characteriser find column %02X\n",m_prot_col));

break;

}

}

}

}

}

else if (offset == 2)

{

LOG_CHR(("Characteriser write 2 data %02X\n",data));

// Rather than the search strategy, we can map the calls directly here. Note that they are hex versions of the square number series

switch (call)

{

case 0x00:

m_lamp_col = 0;

break;



case 0x01:

m_lamp_col = 1;

break;



case 0x04:

m_lamp_col = 2;

break;



case 0x09:

m_lamp_col = 3;

break;



case 0x10:

m_lamp_col = 4;

break;



case 0x19:

m_lamp_col = 5;

break;



case 0x24:

m_lamp_col = 6;

break;



case 0x31:

m_lamp_col = 7;

break;

}

LOG_CHR(("Characteriser find 2 column %02X\n",m_lamp_col));

}

}

 

 

That shows it going through the 64 byte table, then setting m_lamp_col (member variable LampColumn) based of that 'square series'.  MAME source here:

https://github.com/johnparker007/mame/blob/master/src/mame/machine/mpu4.cpp

... and then after in the same file using prot / lamp col to index in:

uint8_t mpu4_state::characteriser_r(address_space &space, offs_t offset)

{

if (!m_current_chr_table)

{

logerror("%s No Characteriser Table\n", machine().describe_context());



/* a cheat ... many early games use a standard check */

int addr = m_maincpu->state_int(M6809_X);

if ((addr>=0x800) && (addr<=0xfff)) return 0x00; // prevent recursion, only care about ram/rom areas for this cheat.



uint8_t ret = space.read_byte(addr);

logerror(" (returning %02x)",ret);



logerror("\n");



return ret;

}



LOG_CHR(("Characteriser read offset %02X \n",offset));

if (offset == 0)

{

LOG_CHR(("Characteriser read data %02X \n",m_current_chr_table[m_prot_col].response));

return m_current_chr_table[m_prot_col].response;

}



if (offset == 3)

{

LOG_CHR(("Characteriser read data off 3 %02X \n",m_current_chr_table[m_lamp_col+64].response));

return m_current_chr_table[m_lamp_col+64].response;

}

return 0;

}
 

 

Edited by johnparker007
  • Like 3

[ Arcade Simulator ] Pre-alpha installer: http://arcadesimulator.net  |  Known Issues: https://tinyurl.com/yz4uom2e  |  Donation info: https://tinyurl.com/yzvgl4xo
[ Community Drive ] The drive: http://tinyurl.com/yckze665
[ Fruit Machine Database ] Initial google sheets (WIP): https://tinyurl.com/2c5znxzz
[ MFME Launch ] Source code: https://github.com/johnparker007/MFMELaunch
[ Oasis ] Source code: https://github.com/johnparker007/Oasis
[ Sound ROM Editor ] Source code: https://github.com/johnparker007/SoundRomEditor

Link to comment
Share on other sites

Thanks

My next move is to check my theory of lamp table using the fluke 9020, if it is correct then make a lamp table gal chip, disable chr checking and checksum and see it it works just reading the lamp table, this is for barcrest machines, I am not going to look into BWB ones at this time

cheers

  • Like 1
Link to comment
Share on other sites

So are you ultimately looking to build your own replacement pal chips for real hardware then, where they are lost/damaged?  Or is it just for the fun of the hacking? ;) 

 

[ Arcade Simulator ] Pre-alpha installer: http://arcadesimulator.net  |  Known Issues: https://tinyurl.com/yz4uom2e  |  Donation info: https://tinyurl.com/yzvgl4xo
[ Community Drive ] The drive: http://tinyurl.com/yckze665
[ Fruit Machine Database ] Initial google sheets (WIP): https://tinyurl.com/2c5znxzz
[ MFME Launch ] Source code: https://github.com/johnparker007/MFMELaunch
[ Oasis ] Source code: https://github.com/johnparker007/Oasis
[ Sound ROM Editor ] Source code: https://github.com/johnparker007/SoundRomEditor

Link to comment
Share on other sites

1 hour ago, johnparker007 said:

So are you ultimately looking to build your own replacement pal chips for real hardware then, where they are lost/damaged?  Or is it just for the fun of the hacking? ;) 

 

I just find it interesting, electronics and real hardware. It's just understanding how its done!

I've done a table before in a GAL chip when I had a bad custom prom go bad and there is no replacement for it, so made one from aa GAL chip to replace it,  it worked well!

IMG_0304.jpg.2fe4413555e3925d58878f44de01cf38.jpg

  • Like 2
Link to comment
Share on other sites

5 minutes ago, andrew96 said:

I just find it interesting, electronics and real hardware. It's just understanding how its done!

I've done a table before in a GAL chip when I had a bad custom prom go bad and there is no replacement for it, so made one from aa GAL chip to replace it,  it worked well!

IMG_0304.jpg.2fe4413555e3925d58878f44de01cf38.jpg

Cool!  Well it sounds like you'll soon be able to make replacement pal chips - good luck with the rest of your quest - hopefully with that MAME source you'll have everything you need to crack it :)  

  • Like 1

[ Arcade Simulator ] Pre-alpha installer: http://arcadesimulator.net  |  Known Issues: https://tinyurl.com/yz4uom2e  |  Donation info: https://tinyurl.com/yzvgl4xo
[ Community Drive ] The drive: http://tinyurl.com/yckze665
[ Fruit Machine Database ] Initial google sheets (WIP): https://tinyurl.com/2c5znxzz
[ MFME Launch ] Source code: https://github.com/johnparker007/MFMELaunch
[ Oasis ] Source code: https://github.com/johnparker007/Oasis
[ Sound ROM Editor ] Source code: https://github.com/johnparker007/SoundRomEditor

Link to comment
Share on other sites

Great work Andrew im watching this with great interest, correct me if I've read it right if you can work out the lamp table it would be possible to create a jedec file for the lamps and burn a pal/gal then disable the chr check in the rom file. Would it need a different lamp table set up for different games or does the code work the same on all mpu4 machines cheers Tony 

  • Like 1
Link to comment
Share on other sites

44 minutes ago, Amot said:

Great work Andrew im watching this with great interest, correct me if I've read it right if you can work out the lamp table it would be possible to create a jedec file for the lamps and burn a pal/gal then disable the chr check in the rom file.

CORRECT!!!! that's the first thing I am aiming for 👍

 

Would it need a different lamp table set up for different games or does the code work the same on all mpu4 machines cheers Tony 

I believe different games use different lamp tables, It would be silly if barcrest didn't after developing a secure PAL chip!

I know the character table is in the rom, but I have not found a lamp table in the rom (unless anyone can correct me on this) it is unique held only in the PAL chip

How I am planning to find the lamp table is to read the real chip out in the correct sequence. I have no idea how the lamp table is reconstructed in MFME or if it can be seen in MFME as I have no idea about MFME and hence the questions at the beginning of the thread!! 

 

This info should help others too trying to get games working but don't have the correct chr chip!

👍👍

  • Like 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...