mitchell.cpp (Poker Ladies)

[jotego]

The driver seems to be missing some information:

mame/src/mame/drivers/mitchell.cpp

Line 461 in 994b8d1

/* bits 6 and 7 are unknown, used in several places. At first I thought */

Bit 6 can be used as a character layer enable bit or as an MSB for the char ROM. This is based on the Pang! schematics Skutis has worked out from the PCB. I helped a bit in the task, implementing it on FPGA.

I have verified that the screen transitions in the attract mode of Poker Ladies look clean once bit 6 is implemented. Bit 3 turns the screen off when writting to the palette because the game may try to change the palette during the active frame time. I don't know how important that is in emulation as the screen is not rendered in parallel with the CPU clocking away. Just in case you find something funny, bit 3 would be the other one to implement.

Please consider implementing bit 6.

[Paul-Arnold]

It looks like the comments in the source code for bits 6 and 7 actually match the schematic ?
Source code also says implementing those bits fix some games but break others so not sure what’s going on.

[angelosa]

Source code also says implementing those bits fix some games but break others so not sure what’s going on.

Sounds like per-game custom pin behaviour from the description.

@jotego have you traced all games in the driver?

[jotego]

We only worked on the Pang! and Super Pang! PCBs.

[jwestfall69]

I been recently writing some tests for pang/super pang PCBs. Here is a video of the behavior jotego is talking about running on my pang board (using z80 cpu).

pang-io_00.mp4

The first 4 bytes are the sprite definition, the last byte is what gets written to io $00.

There are a couple things missing in emulation I found from the schematics of the PCB/86S106 and getting my code up and running on hardware.

1. In order to write to palette memory you need to request it. This is done by setting bit 3 of io $00 to 1. You then need to poll bit 3 of io $05 to be 1 before you should write to palette memory (I believe this should happen at the next vblank). Once you are done writing you need to set bit 3 of io $00 to 0 to release palette ram. This behavior can be seen at bp 8005 in pang in the debugger.

2. There is a sprite buffer. The CPU is storing sprite data into the same ram chip as work ram is in. Writing anything to io $06 signals to the 86S106 chip to copy the sprite data into its internal buffer. There is some weird timing around this that I haven't figured out yet. The only way I could reliably get it to copy is by doing it in my irq handler. I assume the timing has something to do with vblank, but waiting for start of vblank and writing to io $06 only seems to copy it maybe 1 in 5 times.

3. Bit 0 of io $05 is vblank. You can see this in pangs irq handler bp 0046 in the debugger. If the bit is one it does the write to io $06 to trigger the sprite copy. My original irq handler wasn't checking for vblank and was just writing io $06 every time. This would result in some corruption on screen, usually a bunch of dashes on one of the tile rows.