Skip to content

Commit

Permalink
mexico86: hook up kicknrun mcu [Sean Riddle, dink]
Browse files Browse the repository at this point in the history
  • Loading branch information
@dinkc64
dinkc64 committed May 1, 2020
1 parent 5a5dbc0 commit 2b04063
Showing 1 changed file with 275 additions and 71 deletions.

9 comments on commit 2b04063

@dinkc64
Copy link
Collaborator Author

@dinkc64 dinkc64 commented on 2b04063 May 1, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code for the MAME version of this:
dink_kiki3.zip
kikikai.cpp goes in drivers/, kikikai_machine.cpp goes in machine/kikikai.cpp, kikikai.h in includes/
m6801.cpp in devices/cpu/m6800. Info about m6801.cpp fix here: 5a5dbc0

Lord Nightmare suggests the MCU causes the Z80 (main) irq via SC2 through the port3 status register (0xf ->0xaf). In order to prove this, we'd need to trace out the PCB.

Thanks to Sean Riddle for the MCU decap & asm listing, :)
asm listing with lots of silly notes while I was tracing out the mcu to figure out port2, I might be willing to share if the right person asks..

best regards,

  • dink

@tmaul
Copy link
Member

@tmaul tmaul commented on 2b04063 May 1, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dinkc64 Looks like CPU_IDLE_NULL might be missing, i am getting the error:

\src\burn\drv\taito\d_mexico86.cpp(1219,4): error C3861: 'CPU_IDLE_NULL': identifier not found

@dinkc64
Copy link
Collaborator Author

@dinkc64 dinkc64 commented on 2b04063 May 1, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my bad! oops
try now :)

@dinkc64
Copy link
Collaborator Author

@dinkc64 dinkc64 commented on 2b04063 May 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidhaywood, I never tried it, I'll take a peek and see what I missed.

@dinkc64
Copy link
Collaborator Author

@dinkc64 dinkc64 commented on 2b04063 May 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidhaywood,
The mcu reset was missing, causing it to fall back to the mcu sim stuff (in kikikai_interrupt()). please try this update:
dink_kiki4.zip

@dinkc64
Copy link
Collaborator Author

@dinkc64 dinkc64 commented on 2b04063 May 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidhaywood Hmm, did you apply the m6801.cpp update? If that's not it - Can you check the changes that I made to the fbn driver and see what I missed? I am not good with MAME drivers. Also possibly try upping the interleave(quantum)? The game does a lot of shared memory communication per frame. (compared to bubble bobble & mexico86's mcu, which does a few things/frame, kicknrun's mcu does many many times that per frame)

@dinkc64
Copy link
Collaborator Author

@dinkc64 dinkc64 commented on 2b04063 May 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice :)

@dinkc64
Copy link
Collaborator Author

@dinkc64 dinkc64 commented on 2b04063 May 13, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidhaywood Hey buddy,
I hooked up csilver's mcu. Spent a week+1/2 going through the mcu code and found 3 bad bits which were preventing it from running properly. I can share my ida project and / or explain each modification if you need.
Anyhow,
This time I would like to just pass on the information for you to hookup (instead of creating another MAME driver calamity like kicknrun..)
MCU hookup is very similar to shackled / last mission, but with no INT0 irq on coin insert (INT0 isn't hooked up in the mcu rom)
// csilver mcu (0xca663965) has 3 bad bits: -dink May 2020
DrvMCURom[0x185] = 0x90; // was 0x98 - id/init comms
DrvMCURom[0x186] = 0x11; // was 0x19 - id/init comms
DrvMCURom[0x1a6] = 0x06; // was 0x0e - p2 coin bit..
notice: it's always 0x08?
I also went through each line of the mcu's listing and cross referenced every memory location/param which had bit3 set, and I'm pretty confident there are no other bad bits in the rest of the mcu's dump. (I also cross referenced csilver's code with the other dec8 mcu's, since they all share similar functions to rule out any other bad bits)

for the Japan sets, I simply modify the ID byte:
DrvMCURom[0x180] = 0x4a; // Japan id
MCU port writes:

switch (port) {
	case MCS51_PORT_P0:
		i8751_port0 = data;
		break;

	case MCS51_PORT_P1:
		i8751_port1 = data;
		break;

	case MCS51_PORT_P2:
		if (~data & 0x10) {
			i8751_port0 = i8751_value >> 8;
		}
		if (~data & 0x20) {
			i8751_port1 = i8751_value & 0xff;
		}
		if (~data & 0x40) {
			i8751_return = (i8751_return & 0xff) | (i8751_port0 << 8);
			M6809SetIRQLine(0, 1, CPU_IRQSTATUS_HOLD); // FIRQ to main cpu
		}
		if (~data & 0x80) {
			i8751_return = (i8751_return & 0xff00) | i8751_port1;
		}
		i8751_port2 = data;
		break;
}

bye for now & best regards,

  • dink

@dinkc64
Copy link
Collaborator Author

@dinkc64 dinkc64 commented on 2b04063 May 15, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Posted on your PR some info for fixing the issue :) thanks for helping with this! Also, sorry about not being too clear about the I8751 p3 inputs, it's rectified on the PR w/ some help from ajrhacker.

I think if it were hooked up like Oscar, the main cpu would get the interrupt before the mcu even has a chance to respond w/the coinage info and coin-up sound-code.

best regards,

  • dink

Please sign in to comment.