-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
konami/nwk-tr.cpp: implement broadcast CG select
- Loading branch information
Showing
1 changed file
with
72 additions
and
44 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
24cb885
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to convert the k001604 device reg area into an address map instead of a switch case mess with this change in effect?
Also 0x2 for exid sets it to write to cg board 1 only. It's 0x3 that sets it for a broadcast write.
24cb885
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a switch case here, beyond the one in
sysregs_w
which should really be decoupled at root.24cb885
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's https://github.com/mamedev/mame/blob/master/src/mame/konami/k001604.cpp reg_r and reg_w I would have planned to decouple in the near future. That's my concern.
Edit: Or...I could create two address maps (read and write) out of reg_r and reg_w.
Edit 2: I will likely put untangling sysreg_r and w for zr107, gticlub and nwk-tr for a future PR as those are straightforward. Hornet on the other hand isn't.
24cb885
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
regs_r
andregs_w
should be a singleio_map
address map yes,What's 1 then? Just unmapped or mirror of 0?
24cb885
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding m_exid:
0x0: None/unmapped
0x1: CG Board 0 (master)
0x2: CG Board 1 (slave)
0x3: Both
Proof of m_exid = 0x3 being a simultaneous write to both cg boards is from setting two watchpoints at m_exid and k001604:regs_r and regs_w in racingj. The last value written to the byte m_exid is located before it writes to the tilemap register area for initialization before POST is 0xF0 thus enabling both exid bits. The next time racingj will write to m_exid is after its tilemap register initialization.
This long statement of what I did has prompted me to do the same for other Konami PPC games to see how they behave with their exid bits before POST. sscope will come later today after I'm done with work.
Edit: My previous statement is incorrect, see below.
24cb885
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks more sane than what Kale did, but it does not work.
Try this quick hack and you get missing tilemap layer graphics:
if (exid==0) m_cg_view.disable();
if (exid==1) m_cg_view.select(0);
if (exid==2) m_cg_view.select(1);
if (exid==3) m_cg_view.select(2);
If you assume it's active-low, it will work. But I'm not sure it's worth the assumption that the hw is configured with the ability to write to both boards simultaneously when it fixes nothing at all and it contradicts Hydreigon's 'proof'.
if (exid==3) m_cg_view.disable();
if (exid==2) m_cg_view.select(0);
if (exid==1) m_cg_view.select(1);
if (exid==0) m_cg_view.select(2);
24cb885
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing as what you are suggesting just completely blanks the screen/throws heaps of unmapped space accesses, plus it's not what's happening (it generally writes a 2). What's your source of all this?
24cb885
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe...I'm going to have to end this discussion here after my analysis of the two exid bits with various other games. This was the behavior I recorded for the following games written to the byte m_exid would be assigned to before initializing tilemap regs:
This means, at most, only the EXID0 bit determines which CG board to read and write while EXID1's purpose is currently unknown. While I had a very long day of work, I'm glad to have double checked this behavior with other games.
24cb885
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is pretty clear being inconclusive, I'll just revert it later if @happppp doesn't beat me to it.
First off: bits 7 and 6 aren't really used in this context, those are irq ack lines. Then this is (yet again) the wrong perspective about #11343 , it's probably doing a more educated chip select for the CRTC interfacing (that part is a stub under the hood at best).