MPU4 Character help in MFME

[johnparker007]

1 hour ago, andrew96 said:

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.

Not sure - looks like the debugger might do some kind of memory breakpoints... I've not really used it much at all for that kind of thing, though the memory is empty at 800 (it's not really there), so it probably wouldn't even trigger.  Hopefully when you make your test chip it'll just work

If you get stuck after you've made the test chip, I'll try set aside some time, though it'll probably mean a full day faffing around for me to get Mame building, and patched with things to test out the hacked Rom, and log the 800-803 accesses.  I am on another FME project (Arcade Simulator) so I will struggle to allocate that much time to be honest!

[andrew96]

Hi no worries, very thankful for your input so far, thanks again

[johnparker007]

Hi again  

ok I took a look into using MFME as it has a debugger after all, and I don't want to get into the timesink that is doing custom mame builds and fixing mame drivers  

In this video I show (Andy Capp) using read breakpoints, write breakpoints - and actually show it reading and writing to 800 to do the challenge/response stuff - all marrying up perfectly with the defined Chr (onscreen also).

Then I use reading/writing breakpoints to those additional addresses 802/803 - which show it writing the 0,1,4,9 square series values, and getting the correct lamp table column data back (0 is column 0, 1 is column 1, 4 is column 2, 9 is column 3 etc).  I think I saw a write of 10 flash up but I missed it (that would've read back the next column value).

I try to move the mouse to circle the relevant info as I'm doing it all - so hopefully this will give you all you needs to perform further investigations.  Though I would say from the MPU4 program/memory map side, it is doing as I thought: 800 rw for the protection data, 802/803 rw for the lamp data (using square series).

Still not sure how you 'address' that pal chip in the real world though, that's your department now - I'm not an electronics whizz!  ...but at least you have more info now, and you can step thru code etc... hope it helps in your quest  

Also it get's 'stuck around 3m30s in the vid, jumping back to address 800 when I'm trying to break on 803... I thin it may be an MFME  bug in the debugger - once I stopped and disabled everything and reset and reenabled it then seems to work properly.

 

Edited August 26, 2021 by johnparker007

[andrew96]

oh wow!!! that is superb work!! just had a really quick look and looks perfect!!

will look at it more tomorrow

I did start work on the jedec file tonight and I now have the generated signals the chip produces to output enable its self! the same as a original chip does. blue trace is derived in the pal chip from the pink and yellow inputs to the chip!

next step is to work out the latching system, then will add in the data tables.

I have to do this bit little by little in small stages as I am not confident doing anything in wincupl really!! I last used it 6 years ago!!

[andrew96]

Sorry John I still have not studied in depth your video yet, I have been working on sorting out the registers in the PAL chip.

so much to do and sort and not enough time! but I will get round to looking, I am sure its going to be very useful for the next stage of my PAL chip work!

I have 'just' got the registers sorted in the pal chip! I have done it so it stores the value sent to it's inputs so it can be read back out again.

so here is the video!!! I send #00 then read back #02, that's fine as the last 2 bits are masked out by cpu code, (it is the way it works!!) 

Send #25 read #26

send #30 read #32 

 

 

when I run it with a game rom it does indeed (even with the values it reads back from the test chip) move the lamps so I am really pleased it is doing what I want it to do at this stage!

the next stage is to get the lamp table in so it reads what I believe to be the right values out! If the values don't put the lamps in the right order I will be studying Johns video!!!

[davep180]

Still following this (sort of), @andrew96and @johnparker007. I love that there are people like you guys around doing this stuff.

[andrew96]

1 hour ago, davep180 said:

Still following this (sort of), @andrew96and @johnparker007. I love that there are people like you guys around doing this stuff.

Well it means its currently going to plan!! I am pleased with the results so far

[andrew96]

ok guys! so you want to know the next step!!

 I added the lamp table into the PAL chip,  my table !! the fluke read it back fine!!! but when I run the game rom it read it just fine but the lamps were not in the right sequence at all! (it was close though)

so next step was to use the lamp table from MFME for the game.....

here is the table in wincupl

 

the table read out fine on the fluke!!

so then i fired up the rom to run, and low and behold the lamps are all in the right place!!!!!!!!

 

 

top right hand corner is the 4 reels with 3 lamps each! all in the correct order and working as they should!

 

so yep it works!!!

so why does the fluke not read the same data from the chip when being interrogated?  this I have no idea on at the moment!!! they must have done something to hide the data from being interrogated. this is a mystery!!

 

But for now I have a working chip with the lamp table in it!!

Edited August 27, 2021 by andrew96

[Zippy]

This isn't all about electronics and how to implement things from coding, roms and other stuff I haven't a clue about but can benefit the virtual world no end, it is people like @andrew96 and @johnparker007 that are the brains behind the machine which in turn gives an understanding of how to implement work arounds in FME world, speaking to many that have real fruit machines and know how to repair on a real machine brings light to MFME and MAME, so even though I am nowhere on their level I understand the fundamental basics.

Without the real fruit machine world/owners how could anything be incorporated in FME world, I see it as a stepping stone.

Fantastic thread Andrew and love the progress you are making mate.

May happiness and good fortune smile upon those that give us what we require to exceed in what we do.

[andrew96]

[johnparker007]

Wow @andrew96 this really is great work   I recognise that group of reel lamps up in the corner!  Definitely working correctly   

If I get an old fruit machine missing its Chr chip, I know the man I'm calling to burn me a new one off!

So you can now burn a working Pal for any Barcrest machine?  Next stop, Bwb machines  

Truly a very satisfying outcome, congratulations man  

Edited August 28, 2021 by johnparker007

[andrew96]

Hi John

yes it was so pleasing to have this all come together in such a short time really! I surprised myself with the coding in wincupl for the pal chip! I thought I would be spending days and possibly longer working out the pal chip coding!

I have been studying your really useful video you posted! It was very enlightening and showed me the way to do this on MFME myself!

this is what I have found so far..... your indeed totally right #800 address read right data for chr and #802 / #803 for read right of the lamp table....... but on real hard ware this turns out to do exactly the same! the address decoding is on the main mpu4 so the security chip just sees 'access' and 'data'. In fact the address decoding allows for addressing from #800 to #8FF and it access the chip, there is no distinction between any address for the real hardware as long as it is in that range. (tested with the fluke) My guessing is they had planned a more elaborate idea of accessing the security chip using different addresses which never was implemented!, still its handy to know in there programming code #800 is chr and #802/#803 is for lamp table! I guess it made it easier for them to know what side it was accessing!!!

the other thing of notability is...... when I run looking at the lamp table (as in your video) the thing that jumped out as me was it read and wrote to the chip 3 times with the same data  and returned the same data........  so tried this on the real chr chip and got 3 different answers back for the same place in the lamp table!! I am investigating this to see if I can find how the lamp data for each place on the table is derived! so in the real security chip the actual lamp data key is NOT transmitted but a encrypted version, this must be how they hide the code in plain sight!!!! more on this hopefully to follow!!

 

thankyou again for taking the time to make the video and post it 

hope that all made sense!

[andrew96]

It is really not that easy! Here is a headscratcher!!!!!

I have been using this type of program card....

 

it works 100%

 

now I have transferred both chips to the card for the machine, it is this program card

 

Now the lamps have changed!!!!! reel lamps are now well split up and not in the nice chunk at the beginning where they should be!

 

 

I can still read my new lamp table from the chip, no problems there and all the values are good read back with the fluke.  Its not the card as I get the same on 2 good cards! they also work perfectly with a proper chr chip used with this rom!

I don't understand why it works well on one type of program card and not another when the proper chip does!! very confusing!

 

[andrew96]

It appears the table changes with the addition of the Yamaha sound, it seems to be changing the lamp table mapping

In the current lamp table only the first 2 table entry's change the first 2 columns, the rest change nothing!!

this seems where MFME and the real world differ!

[johnparker007]

Ah so adding the sound chip changes the lamp table mapping - most curious!  Well it's amazing progress so far, I guess just keep plugging away at the problem, you may be the first person to ever have a working fake Chr replacement chip, pioneering stuff man - really great work!    

[andrew96]

cheers, I have really tried!

NO chip inserted the 1st and last columns (8th) are correct! you would expect this as they are #00 and that's what is present on the data lines with no chip! 

so location #01 has #44 on the good NON Yamaha card! on that columns 1, 2, and 8 are then correct!!!

on the Yamaha sound card columns 1 and 2 are correct, nothing more!

so I go through the whole of the table (from #02 through to #7F) inserting #44, after hours and hours of plodding through the table #44 does nothing to move any lamps on any columns at all!.

so am really really well and truly stuck!

 

The fluke won't do like MFME and run through the code and be able to stop and display what's it's writing to address #802 ! so that's not a option! And MFME doesn't behave as in the real world with a Yamaha sound program card!

 

MPU5 was easier than this!!  

 

So I have no idea how to resolve this!!

 

Edited August 29, 2021 by andrew96

[johnparker007]

On the plus side, at least it does work perfectly on the non-Yamaha board - so that is definitely progress further perhaps than anyone has even gotten before!   

I think this is perhaps more an electronics problem now, which is not really my area...

Though I did do another look into the MFME debugging side of the CPU code - this may or may not be of interest:

For the initial protection stuff, it's reading/writing $800... but, for the lamp stuff, it's also using $801 (as well as $802 and $803).

Here's a quick video in the debugger:

You can also see the MUX going up - not sure if that's to do with lamp multiplexing, or some on-chip register - anyway, so what it's doing for every Chr lamp 'cycle' seems to be:

- Send 00 to $801, to reset
- Send 'challenge' value (the square series lamp column mapping 0,1,4,9...) to $802
- Read 'response' value from $803

So:
Startup: $800 only (all read/write)
Lamps: $801 (write 0 to reset), $802 (write challenge value), $803 (read response value)

I don't think that helps you, but it is a little bit of new information at least

I guess if the objective is purely to get machines working without their original Chr chip, another route might be some automated ROM patching tool... so it patches out the protection check, checksum check, then finds the
sta $801
stb $802
ldb $803
code, and patches something in with a baked copy of the required values instead (so the lamps are correct).  Would need an assembly whizz (I've only done a little z80, not really my area)... as it might then be something that could just be an automated tool, at least for say Barcrest roms.

Good luck with your project, hope you can find a way forward!  

Edited August 30, 2021 by johnparker007

[johnparker007]

And just checked another thing (again using Andy Capp) - so in MFME, as expected - if I patch the value  $0801 (seems to be the lamp table reset on real hardware) in the ROM to $FFFF, after machine has booted (so I don't trigger checksum alarm) - the lamps still work perfectly fine, as we've seen that the chr simulation code operates directly on those addresses and shouldn't need the reset.

 

Another thing you could try, I guess to confirm - is make a patched ROM that ignores the checksum, and also patch $0801 to $FFFF in that ROM image... then you could verify that it does indeed require the reset before the $802w then $803r on the real hardware (so I'm assuming that on real hardware, the lamps will be messed up, even though in MFME they are not - as the real chr chip will need those 00 reset signals sent via the $801 write).

Again sorry not really answers - but may help in gaining more understanding   

My machine code knowledge is super crappy - but someone who writes 6809, it seems like it would be something like a kind of portable routine to JMP to, the challenge 0/1/4/9 etc is already in B register, so then some kind of code to change that register LDB, based on what it contains: 

if B contains 0, change to 0
if B contains 1, change to 68
if B contains 0, change to 20

etc... as per Andy Capp MFME lamp table:


 then returning with that new value in B and the lamps should be correct (I think!).  So then the machine should run with correct lamps, with no chr chip present (as it has the lamp mapping in the modified ROM).

Edited August 30, 2021 by johnparker007

[johnparker007]

Right I'll stop playing wit this now lol   I've come back to it again - so I booted Andy Capp, and once past protection check, moved the lamp code to a spare area on the ROM (plus removed the unnecessary $801 write) - all still works.

So I guess that's another option on this chr stuff - just patching out both protection, and having it JMP to the custom routine that changes B reg to correct value, then RTS.  Then some NOPs to skip the old routine that is unused - and the lamps should work and be remapped (without having a chr installed).

 

Edited August 30, 2021 by johnparker007

[andrew96]

Thankyou thankyou! I am going through what you have done, yes in the hyper viper rom I am using I have the chr check and checksum bypassed, so it never looks for the chr check on the security chip.

 

Really coincidental I have discovered hyper viper club (mine) uses exactly the same security chip as Andy Capp II : The Great Escape used in the makechr.pdf !

 

when the real security chip is used it writes and reads the same 3 times before moving on to the next...

mame has position 1 as #74

so the  cpu writes 01 to the chip, read it gets #F2

then it writes 01 again, then the read is #7A

then it writes 01 a third time and the read is then #F6

If you 'AND' them all together you get #70 

brill! thats how it does it you think!!!

BUT then you look at the next in the table!

 

 

mame #40, result #00

 

so nope that's not it!!

Now I can put in my table  #74 the #40 and it works the same, the cpu still reads it 3 times but with mine it is the same value!, trying to work out a link between the 3 returned numbers the real chip gives and the table I uses to get it working

some seem to work using that, some don't! just trying to find a relation between real values and fixed values that work!

here are the other values

 

 

Edited August 30, 2021 by andrew96

[johnparker007]

50 minutes ago, andrew96 said:

Thankyou thankyou! I am going through what you have done, yes in the hyper viper rom I am using I have the chr check and checksum bypassed, so it never looks for the chr check on the security chip.

Ooh could I go for a copy of that ROM with the Chr protection and checksum bypassed please?

Really coincidental I have discovered hyper viper club (mine) uses exactly the same security chip as Andy Capp II : The Great Escape used in the makechr.pdf !

when the real security chip is used it writes and reads the same 3 times before moving on to the next...

Interesting!  So the MPU4 memory mapping hardware does this outside of the running program then?  In the Andy Capp ROM I was looking at above, the original routine does the 801w, then 802w, then 803r as three directly sequential instructions (sta $801, stb $802, ldb $803).

mame has position 1 as #74

so the  cpu writes 01 to the chip, read it gets #F2

then it writes 01 again, then the read is #7A

then it writes 01 a third time and the read is then #F6

If you 'AND' them all together you get #70 

brill! thats how it does it you think!!!

BUT then you look at the next in the table!

 

 

mame #40, result #00

 

so nope that's not it!!

Now I can put in my table  #74 the #40 and it works the same, the cpu still reads it 3 times but with mine it is the same value!, trying to work out a link between the 3 returned numbers the real chip gives and the table I uses to get it working

some seem to work using that, some don't! just trying to find a relation between real values and fixed values that work!

here are the other values

 

 

I see what you mean, it does seem to work for some of them!  Maybe you are onto something!  

 

[johnparker007]

From our chat   Just so people in future can have access to this info... this is the code that removes need for Chr for the lamps:

I don't have a 6809 assembler so did mnemonics/branches by hand:

C1 00 ;cmpb (immediate) #$00
27 1d ;beq relative
C1 01 ;cmpb (immediate) #$01
27 1c ;beq relative
C1 04 ;cmpb (immediate) #$04
27 1b ;beq relative
C1 09 ;cmpb (immediate) #$09
27 1a ;beq relative
C1 10 ;cmpb (immediate) #$10
27 10 ;beq relative
C1 19 ;cmpb (immediate) #$19
27 18 ;beq relative
C1 24 ;cmpb (immediate) #$24
27 17 ;beq relative 
C1 31 ;cmpb (immediate) #$31
27 16 ;beq relative 
39			; rts (no match found, shouldn't get here)
;+29 bytes from after first BEQ above
C6 00		; ldb #$00
39			; rts
C6 70		; ldb #$70
39			; rts
C6 40		; ldb #$40
39			; rts
C6 30		; ldb #$30
39			; rts
C6 10		; ldb #$10
39			; rts
C6 60		; ldb #$60
39			; rts
C6 40		; ldb #$40
39			; rts
C6 00		; ldb #$00
39			; rts

So that routine at $1000 (there was spare space there), then absolute jsr to it from the standard crh code, followed by some nops, and B register then has correct lamp info from the 'fake chr' routine in Rom.

Vid of Hyper Viper lamps working with completely zero'd characteriser, attached layout+rom below.

 

Hyper Viper Club (Barcrest) [c].zip

Edited August 30, 2021 by johnparker007

[niallquinn]

I love this sort of shit (don't fully understand it at first, takes a few passes to work it out), great stuff folks!

 

[andrew96]

oh my word!!!!! this is great!! I will try this rom back on real hardware on the 2 cards and see what happens!!

[andrew96]

I have tried it on both the rom card and the yamaha sound card, on both the correct lamps do light! (I know the lamp sequence off by heart now)

but on real hardware it doesn't like it!! ILLEGAL OPTION!