Part 3 Using the MAME Debugger

Shell-Script: mame_debug_gunfront.bat mame64.exe - window - debug gunfront

Shell-Script: mame_debug_koshien.bat mame64.exe - window - debug koshien

Source Code map(0x300000, 0x30000f).rw(m_tc0510nio, FUNC(tc0510nio_device::halfword_wordswap_r), FUNC(tc0510nio_device::halfword_wordswap_w));

Source Code wpset 0x300000,0x10,rw

Source Code 010B0E move.w D7, $300002.l

during bootup

after bootup during gameplay loop

Shell-Script: merge_for_edit.bat py ts_rom_tool.py - interleave c81 - 11.bin c81 - 10.bin 1st.bin type 1st.bin c81 - 04.bin > prog.bin del 1st.bin

Shell-Script: split_for_roms.bat md mod type prog.bin > mod / prog.bin py ts_rom_tool.py - half prog.bin 1st.bin c81 - 04.bin py ts_rom_tool.py - deinterleave 1st.bin c81 - 11.bin c81 - 10.bin del 1st.bin type c81 - 04.bin > mod / c81 - 04.bin type c81 - 11.bin > mod / c81 - 11.bin type c81 - 10.bin > mod / c81 - 10.bin

So what I'm going to do now is load up gunfront and koshien in the MAME debugger and see if I can determine what's happening with the input data.The debugger is an awesome tool that lets you look at all the data passing through the "CPUs" and "RAM" on an arcade PCB in real time, you can pause it look at things, or setup "break points" and "watch points" to have it automatically stop when it gets to something you're interested in.I usually create a batch file to launch mame windowed with the debugger for the specific game I want. so in this case I created two batch files, one for each game, and this lets me quickly and easily launch mame directly into game without having to waste time with menus or command lines every time I want to launch another session.If you've never used the MAME debugger in addition to the game window you'll be presented with a screen that looks like this:on the top right we see the game's code, MAME has taken the hex (right side of this box) and de-compiled it to the instructions that the CPU runs, to the immediate left of the instructions are the address within the program ROMs where those instructions reside. So if you were to properly merge all of your program ROMs together, open it in a hex editor and go to that address you'd see the same hex data as you do in this window. only MAME has done us the favor of telling us what this hex meansIt might seem like gibberish but assembly is really very simple, it's mostly just pushing binary data around. so "move" is just move data from point a to point b, "clr" means clear the data from a location, "jmp" means jump to a different position in the program, etc. the numbers to the right of the instructions are just telling it where to put the data or where to get the data from. This hardware uses the Motorola 68000 CPU so these instructions are specific to that CPU. It's a really popular one so there are lots of resources available. I've been using this document to look up any instructions I don't know: wpage.unina.it/rcanonic/didattica/ce1/docs/68000.pdf The box on the left hand side of the window basically shows you the internals of the CPU, there are places inside the CPU where information can be stored for processing. you can see some of the locations here such as "D4" and "A0" are referenced in the program code.The game will not be running to start. you'll need to click the "Debug" drop down menu and you'll find options for starting and stopping emulation or stepping through. But what I'm interested in is the Memory Window, which is also found inside the Debug Menu. So I start the game running from this menu then I select the "New Memory Window" option.If you recall back to the Address Map in part 1 the IO chip had this line:So Inside the memory window I'm going to scroll down to address 0x300000 to see what that data is doing...So with this window open and the game running I can push buttons and move the joysticks in game and see how the data changes here, all the IO goes through here so even dip switches changed will show up here.The way addresses work is that each pair of digits on the screen here makes a "byte" so the "00" at the left edge of the line is 0x300000, but the "BF" after that is address 0x300001, and so on until 0x30000F for the last pair on the right side of the line.by pushing buttons and flipping dip-switches I'm able to determine which addresses correspond to which input.for gunfront0x300001 = Dip Bank 20x300002 = ?unknown, the game is writing data here0x300003 = Dip Bank 10x300005 = Player 2 Controls0x300007 = player 1 Controls0x30000B = coin nibble (I know this because it incremented when inserting coins, also referenced in mame)0x30000D = system buttons (tilt, service, coin1 and coin2)the other addresses are either unused or not immediately relevant to us. Remember I'm mostly worried about the tilt button since that's what keeping our game from booting!doing the same thing in koshen I found this:0x300000 = ? unknown, the game is writing data here0x300001 = Dip Bank 10x300003 = Dip Bank 20x300005 = Buttons for Player 1 and Player 20x300007 = system buttons (tilt, service, coin1 and coin2)0x300009 = coin nibble0x30000F = Joysticks for Player 1 and Player 2So we've learned that the inputs are all mapped differently, no wonder it's throwing a tilt gunfront code is looking at 0x30000D which is either being triggered by something else, or wired in a way to show that's it's always pressed.looking at the PCB there would be no good way to re-wire all of these inputs so a hardware mod is out of the question. So the next step is modifying the game code to fix it. The biggest problem here is that gunfront uses a byte for P1 and a different byte for P2, while koshien uses a byte for all buttons and a different byte for all joysticks. the rest of it is just moving addresses from one location to another (for instances swapping 0x300001 with 0x300003 to make the dip banks correct). So lets get the game booting first and see where we're at before going further.So what I'm going to do next is create a watch point, I'm going to tell MAME to watch a memory address and then stop if it sees some part of the code reading or writing to that location. Since we're dealing with our IO chip I'm having it watch address 0x300000I do this by putting this command into the debugger:this is saying set a watch point starting at 0x300000 and continuing 17 bytes (it stops at the beginning of the 17th byte so we need to specify 1 number higher than the area we want to watch) and the "rw" means stop if it's reading or writing to that area.Every time it catches one the game will stop and you'll need to tell the debugger to run again but it keeps track of what it caught. also keep in mind that the yellow highlighted line is the next line of the program to be executed so it's the line of code AFTER the one caught by your watch point so sometimes it's no where near the code you care about if it happened to be something that causes to code to jump to a new location.Here we can see the first few watch points caught the "PC=" is telling us which address in the program triggered it. What we want to do is get through the code and identify every instruction that touches this address range so we know what to fix.I also scrolled through the code to see if I could find instructions that referenced the 0x300000 range but might not have run during boot or attract mode. you can see in the code above line:This is telling us that in the program hex at location 0x010B0E there's an instruction to move "word" sized data from D7 into address 0x300002There are a lot of other tips and tricks to identifying this stuff that I wont get into here. But through this process I identified the following program instructions in gunfront:01071C -> writing 00 to 0030000B010724 -> writing D0 (0000) to 003000020107B0 -> reading from 00300003010932 -> reading from 00300003 to A5 -$7FFA01093A -> reading from 00300001 to A5 -$7FF901094E -> writing 03 to 0030000B010ACA -> writing D7 (0000) to 00300002010AF8 -> writing D7 (0000) to 00300002010B0E -> writing D7 (0000) to 00300002010BD2 -> writing D7 (0000) to 00300002010D16 -> writing 00 to 0030000B010F02 -> writing D0 to 00300002010F1A -> reading from 00300007 to A5 -$8000010F22 -> reading from 00300005 to A5 -$7FFF010F2A -> reading from 0030000D to A5 -$7FF8010F32 -> writing A5 -$7ff5 to 0030000BSo now we have an IO address map so we know which ports in koshien should be mapped where in gun front, and we know where all of the instructions are in the game code... so now we modify the ROMs to fix this using a simple Hex Editor.BUT FIRST, we can't just open up the ROMs in a hex editor, remember part of the program is split across interleaved ROMs so if we open it in a hex editor we'll only see every other byte. It's be like trying to read AND MODIFY a book with every other letter missing. So I created a batch script to quickly and easily merge the program ROMs together into a single file for editing, and then another script to split that single file back out into separate files for burning to ROMs.on my split script I'm also making a backup copy of the file to a separate directly so I always have a copy of the last revision I made.So now what we'll do is we'll go down the list of instructions I made, find them in the de-compiled source window of the MAME debugger, and then find them in the hex editor so they can be changed.Here are some of the lines that need to be changed, noticed the address in the brown box on the left, and the hex in the orange box on the right, the other colored boxes identify the address locations that need to be changed.Now here's the file open in our hex editor:So baisically I take the list I made earlier of the instructions that read or write to the 0x300000 areas. We go to the address in MAME Debugger window, then go to that same address in the Hex Editor and verify that the hex is a match. Then we modify the values int he hex editor based on the cross-reference we made earlier.Once we've fixed all the locations in the list. I'll run my script to chop up the big prog.bin file into unique smaller files ready to be programmed to the ROMs. For now I'm not worried about the buttons and joystick mapping so Player 2 will get all the buttons and player 1 will get all the joysticks.IT BOOTS! The TILT error has been fixedWe still have to worry about the joystick and button mapping but unfortunately it looks like there are some sprite issue ah damn, lets get that working first before we worry about the controls.