johnparker007

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. So I could be missing the point, as I've not ever done any programmable logic array coding ... but if I had to make that smaller, since I know it's always working through the table in order, I'd only advance, when the challenge value received is different to the previous one... So if it writes: 00, 1a, 1a, 1a, 04, 04, 04, 04, 10, 10, 18, 18, 18, 18... I'd just return: Response[0],Response[1],Response[1],Response[1],Response[2],Response[2],Response[2],Response[2],Response[3],Response[3]... etc That said, you'd still need 64 bytes storage for your responses... but then single index to the current point in the 'Response' table. Adn that index only increments when the challenge does not equal the previously received challenge. Apologies if this is wildly off how you are implementing this! I just mean that you don't have to store the 64x challenges, only the 64x responses (since it always works through the table in order, even with repeats of challenges)... might save some space.

Ah right, I'm with ya - so on the Barcrest we saw it just reads protection challenge/response in order through the table, so should hopefully be straightforward? Definitely phase 2 of your investigations on the horizon! Once you've done that, then it should mean that no Rom patching is required, since it'll just work exactly like the original Chr - that is super cool! That patching program - I can't imagine getting all the mpu4 games working very soon, as I need to get back to Arcade Sim, so I won't be able to spend much time on it (it's going to need different patching strategies, I'll have to download some more mpu4 layouts to try)... it's always bloomin' free time that's the problem lol I think you will have your replacement Chr chips perfected way beforehand - I suspect you'll have a few requests!

Wow - that is great news! Especially that the same replacement Chr chip now works across both gamecards So can you now can write a Chr replacement chip for Super Hyper Viper that means it can run on the original ROM? No patching required? If yes, then I guess next it's time to try to do some more machines! I guess you can just burn different (unpatched) ROMs to try in your test jig? (along with matching replacement Chr)...

The patching solution will only work on ROMs that can be patched, it'll need more work to patch ROMs liek the ones you mentioned that don't follow the pattern we've seen so far on Andy Capp and Hyper Viper - your solution should in theory work on all ROMs without having to work out the patching I think between us we have made some pretty decent progress on these very old protection chips, and fixing the issues they cause Provisional name for the patch tool is C.R.A.P. (Chr-free Rom Auto Patcher) - I'm so immature lol

Great stuff, always good to confirm new info! Good to know! I have the day off today, so I'm putting together a very basic patching program, that'll just work on those fixed 'signatures' MPU4 roms for now. I'll stick the code on github once it's working for those basic ROMs, then other coders with more free time can develop it further if they wish. Not as clean as your replacement Chr chip solution, but it's certainly been an interesting rabbit hole to go down!

It sounds very likely Still a bit of a mystery how the real Chr works in that board though Cool thanks I'm pretty sure it should work just fine, as it's just pure 6809 code running where I've written the new routine. Had a dig and found some old MPU4 data, over 200 machines along with their Chr data... popped it on a sheet as a starting point, if a auto-Rom patching tool would be something needed: https://docs.google.com/spreadsheets/d/1tjRy9ZXgA4bNkLa1IdO_qfQsJzJK7V8xJB_x2EjtovI/edit?usp=sharing Are there a lot of people with boards/machines missing chr chips though? I guess as time goes on, perhaps the chr chips wear out... if it can save boards/machines from the tip, that's always a good thing

Phew - so it is working properly? I saw your post with the 'Illegal Option' error, and thought I'd have to look into it more! Cool Well I guess it still doesn't help yet with making those fake chr chips... but does show another way to run machines with protected lamps without chr chips via patching the Rom That Yamaha card, it must be doing something funky with the address space like you said... so more to work out for that route! (As an alternative, I guess a Windows program could be written, to auto-patch roms, given their 8x MFME lamp column numbers. I may have all that data extracted somewhere from back in the MFME2MAME days actually... so then anyone could burn themselves off a new ROM that doesn't require chr chip).

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

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).

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).

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!

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!

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

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.

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!

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 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!

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 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...

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 )

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)

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

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?

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; }

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!