MPU4 Character help in MFME

[Amot]

Awesome Andrew I currently have 2 machines without the correct gamecard and it'd be a shame to break them so fingers crossed you crack it mate. I have another question regarding mpu4 roms but ill start a new thread so not to interfere here cheers 

[hitthesix]

This may help too.

makechr.pdf

[andrew96]

41 minutes ago, hitthesix said:

This may help too.

makechr.pdf 137.68 kB · 2 downloads

ooohhhhhh perfect!!!! thankyou so much for that! That will be excellent resource for finding out the needed values for the PAL chip!

I am working on doing barcrest 'Hyper Viper club' as that's the MPU4 machine I have and the way the lamps sweep across in attract mode will be a very good indicator if I have a real chip done correctly when I test it!

I need now to get to grips with PAL chip latches as I have not used registered logic before and see it needs to read the info in, use a look up table to store it in a latch to be accessed when the cpu askes for it . all because it just has data in and data out pins! I am more used to having address pins in and data pins out!! so hence the latch!

[andrew96]

ok well so far so good............

CHR check and checksum removed from rom (no chr chip fitted lamps all over the place!!!!

 

 

now same but WITH a chr chip fitted!! much more organised lamps!!

 

so it looks like my plan might actually work!!! chr chip just needs to contain the lamp table!!!!! 

[stevedude2]

Some really useful info posted on this thread and some great work by @andrew96

If it ends up with CHR chips being able to be reproduced then that is great news for the scene!

[andrew96]

ok last post for tonight.....

 

these are the values for the lamp table in MFME

so now I really do need to rig up the fluke 9020 and see if this matches the REAL chr chip!!

[andrew96]

OK so eyes down for a full house!!!

The machine I found first was the better fluke 9010 troubleshooter this time! and of course the highly sort after 6809 pod!

I don't talk on my videos...."today I am going to show you ...." etc etc , you know 5 mins before anything happens videos!

so here is whats hapening, I write to address #800 (the chr chip) data #00 then read back address #800, its #02 

then the same again......  I write to address #800 data #00 then read back address #800, its #02

then the next in the lamp table is 01, so I write to address #800 data #01 then read back address #800, its #F2

then the next in the lamp table is 04, so I write to address #800 data #04 then read back address #800, its #4A

then the next in the lamp table is 09, so I write to address #800 data #09 then read back address #800, its #16

then the next in the lamp table is 10, so I write to address #800 data #10 then read back address #800, its #72

then the next in the lamp table is 19, so I write to address #800 data #19 then read back address #800, its #72

then the next in the lamp table is 24, so I write to address #800 data #24 then read back address #800, its #42

then the next in the lamp table is 31, so I write to address #800 data #31 then read back address #800, its #82

 

so this is what I got compared to MFME

the last 2 bits of data are dropped so 02 becomes 00 , F2 becomes F0 etc etc

so why is my data different to MFME for the same game?? At this point I don't know!!!

[andrew96]

Now I find this very confusing....

here is the corrected table and the table in MFME...

this is always a repeatable read....  same as when I do the character table only the character table matches MFME perfectly!

If I change the second figure in MFME from 70 to F0...

the reel lamps are all out of sequence in MFME.....

But I do believe the figures I have read from the character chip are real, and as I have said are repeatable the same every time as long as there read in a sequential order.

If the real read is correct this would mean for every chr chip I generate I would have to read a real chip first to get the correct right table...... unless anyone has any idea why real table and MFME tables don't match!! ??

 

I am just confused now why nothing on the lamp table matches, but the character table matches completely!!

[Tommy c]

1 hour ago, andrew96 said:

 

If the real read is correct this would mean for every chr chip I generate I would have to read a real chip first to get the correct right table...... unless anyone has any idea why real table and MFME tables don't match!! ??

 

I am just confused now why nothing on the lamp table matches, but the character table matches completely!!

This bit is probably 100 % correct but you would only have to read a version that doesn't match the second string in the software version like i was talking about at the beginning of the thread. I mean you have learned lots more since then, so maybe that doesn't make a difference but i would say it does.

[andrew96]

I see what you mean but I am using the same version of rom in the emulator as I am using on the real card in the real machine, hyper viper club v0.5

so they should match up, but it doesn't

[johnparker007]

I'm not sure why they don't match either  How does it 'know' you are wanting to reset and read the 64-71 lamp data, rather than the  protection data?  In MAME source, there's an offset parameter coming in, that needs to be 0 to access protection, or 2w/3r to access lamps.

I guess another angle of attack if you get truly stuck is to compile MAME from source, then fix the driver for Hyper Viper Club v0.5 (currently sticks on reel setup alarm), add the 72 byte chr data into the MAME source to ref (I was going to be putting these in the MAME rom zips rather than the MAME source but anyway, be quickest to get in code)... then you could print out the list of chr read/writes to console/text file... might give you more info. 

I suppose another option (that involves less MAME programming) would be to try burn one of your replacement chips so it returns the response values you measured with your Fluke meter - then with the chr protection checks disabled in the ROM, give it a go and just see if it works.  If it does/doesn't - it's more info either way   (and if it doesn't maybe try the 8x MFME lamp bytes)

Edited August 26, 2021 by johnparker007

[andrew96]

2 hours ago, johnparker007 said:

I'm not sure why they don't match either  How does it 'know' you are wanting to reset and read the 64-71 lamp data, rather than the  protection data?  In MAME source, there's an offset parameter coming in, that needs to be 0 to access protection, or 2w/3r to access lamps.
 

that's now easy for the real chip send #00 is reset so then you read back #00 to confirm

then the next write of data determines if it is chr or lamp table

write #1a is chr table

or write #01 is lamp table

then whichever is chosen the table then has to be correctly read to its end where #00 to reset is again sent!

maybe thets where the difference is is this 'offest' MFME has then for the different tables!

 

......... chr table example in mame

static mpu4_chr_table ccelbr_data[72] = {   {0x00, 0x00},{0x1a, 0x84},{0x04, 0x8c},{0x10, 0xb8},{0x18, 0x74},{0x0f, 0x80},{0x13, 0x1c},{0x1b, 0xb4},   {0x03, 0xd8},{0x07, 0x74},{0x17, 0x00},{0x1d, 0xd4},{0x36, 0xc8},{0x35, 0x78},{0x2b, 0xa4},{0x28, 0x4c},   {0x39, 0xe0},{0x21, 0xdc},{0x22, 0xf4},{0x25, 0x88},{0x2c, 0x78},{0x29, 0x24},{0x31, 0x84},{0x34, 0xcc},   {0x0a, 0xb8},{0x1f, 0x74},{0x06, 0x90},{0x0e, 0x48},{0x1c, 0xa0},{0x12, 0x1c},{0x1e, 0x24},{0x0d, 0x94},   {0x14, 0xc8},{0x0a, 0xb8},{0x19, 0x74},{0x15, 0x00},{0x06, 0x94},{0x0f, 0x48},{0x08, 0x30},{0x1b, 0x90},   {0x1e, 0x08},{0x04, 0x60},{0x01, 0xd4},{0x0c, 0x58},{0x18, 0xf4},{0x1a, 0x18},{0x11, 0x74},{0x0b, 0x80},   {0x03, 0xdc},{0x17, 0x74},{0x10, 0xd0},{0x1d, 0x58},{0x0e, 0x24},{0x07, 0x94},{0x12, 0xd8},{0x09, 0x34},   {0x0d, 0x90},{0x1f, 0x58},{0x16, 0xf4},{0x05, 0x88},{0x13, 0x38},{0x1c, 0x24},{0x02, 0xd4},{0x00, 0x00},   {0x00, 0x00},{0x01, 0x50},{0x04, 0x00},{0x09, 0x50},{0x10, 0x10},{0x19, 0x40},{0x24, 0x04},{0x31, 0x00}   };

 

red chr, blue lamp tables

 

Edited August 26, 2021 by andrew96

[andrew96]

 

2 hours ago, johnparker007 said:

I guess another angle of attack if you get truly stuck is to compile MAME from source, then fix the driver for Hyper Viper Club v0.5 (currently sticks on reel setup alarm), add the 72 byte chr data into the MAME source to ref (I was going to be putting these in the MAME rom zips rather than the MAME source but anyway, be quickest to get in code)... then you could print out the list of chr read/writes to console/text file... might give you more info. 

I suppose another option (that involves less MAME programming) would be to try burn one of your replacement chips so it returns the response values you measured with your Fluke meter - then with the chr protection checks disabled in the ROM, give it a go and just see if it works.  If it does/doesn't - it's more info either way   (and if it doesn't maybe try the 8x MFME lamp bytes)

I am tending to believe the data I have regarding the lamp table actual figures is correct, but your right I need to really make my own chip op spouting out the sequence I think is correct and see! I don't think I can do the re-compiling of mame etc!

[johnparker007]

Looking at the mame source (can be viewed in browser):

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

That offset looks like it's talking about the offset into the chr memory space (800).  Have you trying some experiments using your Fluke meter such as doing these in order (may not need to be in order, unsure):

Write:  802 (800 base chr memory space + offset of 2 bytes) with value 00 (value from from 0,1,4,9,10,19,24,31 square series)
Read:  803 (800 base chr memory space + offset of 3 bytes) ... is the result 00? (1st value from MFME lamp column values from your notes above)

Write:  802 (800 base chr memory space + offset of 2 bytes) with value 01 (value from from 0,1,4,9,10,19,24,31 square series)
Read:  803 (800 base chr memory space + offset of 3 bytes) ... is the result 70? (2nd value from MFME lamp column values from your notes above)

Write:  802 (800 base chr memory space + offset of 2 bytes) with value 04 (value from from 0,1,4,9,10,19,24,31 square series)
Read:  803 (800 base chr memory space + offset of 3 bytes) ... is the result 40? (3rd value from MFME lamp column values from your notes above)

Write:  802 (800 base chr memory space + offset of 2 bytes) with value 09 (value from from 0,1,4,9,10,19,24,31 square series)
Read:  803 (800 base chr memory space + offset of 3 bytes) ... is the result 30? (4th value from MFME lamp column values from your notes above)

...etc 

I could be misunderstanding how the chip works to be honest, but it might be worth trying the above, and some variants of it.  Once you get a 00, then a 70, you've probably found it (if it indeed can be found this way), so a little trial and error if the above doesn't work could also be worth it... i.e. try with/without sending the initial reset command (if without try with/without power cycling chr), try with 801w,802r... 804w,806r etc... as you only need to do a few whilst looking to get that 70 back from a written 01, and then you've probably got it.

Apologies if that doesn't work or makes no sense  Worth a shot thought maybe (I am slightly optimistic this is how it works, but don't wan to tempt fate haha  ) 

Edited August 26, 2021 by johnparker007

[andrew96]

Thanks I will give it another go

Edited August 26, 2021 by andrew96

[andrew96]

34 minutes ago, johnparker007 said:

Looking at the mame source (can be viewed in browser):

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

That offset looks like it's talking about the offset into the chr memory space (800).  Have you trying some experiments using your Fluke meter such as doing these in order (may not need to be in order, unsure):

Write:  802 (800 base chr memory space + offset of 2 bytes) with value 00 (value from from 0,1,4,9,10,19,24,31 square series)
Read:  803 (800 base chr memory space + offset of 3 bytes) ... is the result 00? (1st value from MFME lamp column values from your notes above) RESULT #00

Write:  802 (800 base chr memory space + offset of 2 bytes) with value 01 (value from from 0,1,4,9,10,19,24,31 square series)
Read:  803 (800 base chr memory space + offset of 3 bytes) ... is the result 70? (2nd value from MFME lamp column values from your notes above)RESULT #F0

Write:  802 (800 base chr memory space + offset of 2 bytes) with value 04 (value from from 0,1,4,9,10,19,24,31 square series)
Read:  803 (800 base chr memory space + offset of 3 bytes) ... is the result 40? (3rd value from MFME lamp column values from your notes above)RESULT #48

Write:  802 (800 base chr memory space + offset of 2 bytes) with value 09 (value from from 0,1,4,9,10,19,24,31 square series)
Read:  803 (800 base chr memory space + offset of 3 bytes) ... is the result 30? (4th value from MFME lamp column values from your notes above)RESULT #14

...etc 

I could be misunderstanding how the chip works to be honest, but it might be worth trying the above, and some variants of it.  Once you get a 00, then a 70, you've probably found it (if it indeed can be found this way), so a little trial and error if the above doesn't work could also be worth it... i.e. try with/without sending the initial reset command (if without try with/without power cycling chr), try with 801w,802r... 804w,806r etc... as you only need to do a few whilst looking to get that 70 back from a written 01, and then you've probably got it.

Apologies if that doesn't work or makes no sense  Worth a shot thought maybe (I am slightly optimistic this is how it works, but don't wan to tempt fate haha  ) 

Thankyou thankyou, worth a try! exactly the same results as using #800 write / read

expand your quoted post above to see the results

 

Edited August 26, 2021 by andrew96

[andrew96]

I do apreciate your comments and help johnparker, thankyou

[andrew96]

The CHR chip does no address decoding, all it does is have data lines connected on input and output, therefore the data is read in, computed equations etc and the chips output is stored in latches so when accessed to read out it puts its data back onto the data lines in the right sequence needed! it is that simple really........

 

Edited August 26, 2021 by andrew96

[johnparker007]

Ah well, was worth a shot - a little puzzling as that seems precisely how the mame mpu4 chr read/write source selects lamps. 

characteriser_w:
If offset from 800 == 0, do protection stuff, otherwise if offset from 800 == 2, set lamp column (0-7), from input value (0,1,4,9 etc)

characteriser_r:
If offset from 800 == 0, do protection stuff, otherwise if offset from 800 == 3, lookup from those 8 bytes on the end (64 pairs + lamp column) and return

 

29 minutes ago, andrew96 said:

The CHR chip does no address decoding, all it does is have data lines connected on input and output, therefore the data is read in, computed equations etc and the chips output is stored in latches so when accessed to read out it puts its data back onto the data lines in the right sequence needed! it is that simple really........

 

Well if there's no address decoding, is it a case that you simply need to type all 64 protection values in, in sequence followed by the reads... then send the 0,1,4,9 etc sequence (followed by the reads)?

Maybe you just have to cycle through the table to get the chip in the state where it then will return the correct 8 values for the lamps?

It's going to take some careful typing lol   But that's probably something I'd be tempted to try (of course checking each answer for the 64 protection write>reads to check your on track).

Weird how in MAME it does the special 2/3 offset from 800 though... 

Edited August 26, 2021 by johnparker007

[johnparker007]

I have checked in some very old leaked MFME source to see Chris's approach, it's exactly the same.  MPU read/write emulation code has the same logic (for Barcrest chr type) of using 802/803... hmmm.  That just confirms that from the program ROMs perspective the code really is reading/writing to 800 for protection, but 802/803 for the lamps (i.e: it's not a MAME-specific hack or anything like that).

Well apart from my suggestion of the above carefully advancing through all 64 challenge/response pairs, to see if that somehow internally aligns the chr chip to that state, I'm really not sure what to suggest... it's almost like they didn't want these things hacking!   

Edited August 26, 2021 by johnparker007

[andrew96]

yeah....

 

see nothing cleaver in the address decoding...

just normal address decoding from a 138 for PAL chip select and read/write!

Edited August 26, 2021 by andrew96

[andrew96]

12 minutes ago, johnparker007 said:

 it's almost like they didn't want these things hacking!   

well when you think when these were designed and they still seem to be secure in 2021 they did a good job!!

[andrew96]

I have been thinking about what you said there about going through all the chr typing in first........

I remember now I have already proved this is not the case as I disabled the chr check in the rom so it would not even attempt to read it, but the lamp table worked fine!

so I still think for whatever reason the figures I get are right....... I guess time will tell once I can figure out a jedec file to do what's needed!

[johnparker007]

6 minutes ago, andrew96 said:

I have been thinking about what you said there about going through all the chr typing in first........

I remember now I have already proved this is not the case as I disabled the chr check in the rom so it would not even attempt to read it, but the lamp table worked fine!

so I still think for whatever reason the figures I get are right....... I guess time will tell once I can figure out a jedec file to do what's needed!

I hope they are right, look forward to seeing your results when you build a test custom chr   

It may be that when it fetches the 8x lamp values from the chr, it does some kind of reset, then dummy run though first... this is utter guesswork on my part here lol... I don't have Mame set up to compile/run... but I guess using an emulator with your patched ROM and then printing out all the mpu4 reads in the chr space would tell you if it did a dummy set of 64 reads to get to the lamps.

[andrew96]

13 minutes ago, johnparker007 said:

I hope they are right, look forward to seeing your results when you build a test custom chr   

It may be that when it fetches the 8x lamp values from the chr, it does some kind of reset, then dummy run though first... this is utter guesswork on my part here lol... I don't have Mame set up to compile/run... but I guess using an emulator with your patched ROM and then printing out all the mpu4 reads in the chr space would tell you if it did a dummy set of 64 reads to get to the lamps.

I have thought about that, but I have no idea how to get MFME to run through code and stop when it accesses address #800 then stem through the code and see! I know more about the real side than the emulation side.