konami/k005849 info

[jwestfall69]

I've recently been working on jail break and rush'n attack boards. Both have the konami 005849 custom IC on them for handling tiles/sprites. Below is some info from the jail break board, but the same things happen on the rush'n attack board.

• 0x2403 bit 0 tile banking
• 0x2403 bit 1 tile banking
• 0x2403 bit 2 sprite banking (already known)
• 0x2403 bit 3 flip/flop where sprite data get read from (unset = 0x1000, set = 0x1100)
• 0x2403 bit 4 seems to be another bit for palette/color selection, but only applies to tiles
• 0x2403 bit 5 ??
• 0x2403 bit 6 when unset, sprites disappear (could be another sprite bank bit?)
• 0x2403 bit 7 when set, masks off the left/right most 8 pixel columns of the screen

Note for bit 3 on rush'n attack, mame has it backwards.

Below are videos showing the behaviors on my jail break board.

bit0 + bit1 tile banking:
https://github.com/user-attachments/assets/81fccf27-0427-416a-8995-71e72f874535

bit2 sprite banking:
https://github.com/user-attachments/assets/6c20cd19-4175-4efc-89d8-f575be6a22ce

bit3 flip/flop where sprite data get read from:
For this one the sprite debug test is setup to write the sprite data seen on screen to 0x1000 and a modified version of it to 0x1100 (sprite_num + 1, y position + 16). Such that as I flip the bit you can see the left most sprite is shown when the bit is unset and right most is shown when the bit is set.
https://github.com/user-attachments/assets/f9704f7f-0140-412d-9938-3bb340111052

bit4 seems to be another bit for palette/color selection, but only applies to tiles:
For this one I pick a random tile that has the bunch of different colors in it, flip bit4 on, then go and change the color palette number associated with the tile.
https://github.com/user-attachments/assets/0c0e952b-a22b-4ded-abed-cc81ac0b3ddd

bit6 when unset, sprites disappear (could be another sprite bank bit?):
https://github.com/user-attachments/assets/6b7dcf5c-303b-4f12-8519-581a0cd19875

bit7 when set, masks off the left/right most 8 pixel columns of the screen:
For this one I change one of the tile banking bits which forces the entire screen to be filled with garbage/visible tiles, then got flip bit7 multiple times. You can see how it masks the screen edges.
https://github.com/user-attachments/assets/aad73d53-4b81-46c2-bbbf-7a854ddb8941

[happppp]

tile bank is already in color ram bit 6,7*.
sprite bank is already in sprite ram bit 6.
*: gberet color ram bit 7 = tile priority over sprites

0x2043 global bank bits 0,1,2 are ORed with these?
Bit 4, does it select sprite palette for tiles?

[happppp]

gberet: if I swap spriteram select bit (bit 3), there's tile/sprite lag that's not visible on PCB videos.
Visible with eg. the enemy lying in wait, stop walking a few times to stop tilemap scroll and you'll see the enemy 'sliding' a bit.

edit:
in jailbrek (although unemulated in the MAME driver), when the game writes to sprite ram bank 0 (0x1100), 0x2043 bit 3=1,
and when the game writes to sprite ram bank 1 (0x1000), bit 3=0

in gberet/mrgoemon it's the other way around, when the game writes to sprite ram bank 0, bit 3=0,
and when the game writes to sprite ram bank 1, bit 3=1

[jwestfall69]

tile bank is already in color ram bit 6,7*. sprite bank is already in sprite ram bit 6. *: gberet color ram bit 7 = tile priority over sprites

0x2043 global bank bits 0,1,2 are ORed with these?

I'm not 100% sure whats going on with these bank bits. If you look at the schematics for both boards

https://github.com/jwestfall69/mad/blob/main/machine/jail_break/docs/jail_break_schematics.pdf
https://github.com/jwestfall69/mad/blob/main/machine/rush_n_attack/docs/rush_n_attack_schematics.png

The sprite and tiles roms all share the same address/data bus and an 74LS138 is used for determining which rom is enabled.

Using the sprite debug page I sent the sprite number to 0 then went and tested every combination of the 3 bits to see what rom(s) were getting enabled to draw the screen. This is what I got for jail break

|  INPUTS   |          ACTIVE ROMS        |
| reg bits  |    sprite roms    |  tiles  |
|-----------+-------------------+---------+-----------------------
| 2 | 1 | 0 | 3E | 4E | 5E | 3F | 4F | 5F | Notes
|-----------+-----------------------------+-----------------------
| 0 | 0 | 0 | 0  | 1  | 1  | 1  | 1  | 1  | sprites normal, tiles junk; both sprites/tiles are being read from 3E
| 0 | 0 | 1 | P  | 1  | P  | 1  | 1  | 1  | sprites normal, tiles junk and must be getting read from 5E
| 0 | 1 | 0 | P  | 1  | 1  | 1  | P  | 1  | sprites normal, tiles normal
| 0 | 1 | 1 | P  | 1  | 1  | 1  | 1  | 1  | sprites normal, all tiles solid black; sprites being read from 3E? pin 9 on the 74ls138 is pulsing, it trying to use that to read tile data?
| 1 | 0 | 0 | P  | 1  | 1  | 1  | P  | 1  | sprites junk, tiles junk; tiles being read from 3E and sprites from 4F?
| 1 | 0 | 1 | 1  | 1  | P  | 1  | P  | 1  | sprites junk, tiles junk; tiles being read from 5E and sprites from 4F?
| 1 | 1 | 0 | 1  | 1  | 1  | 1  | 0  | 1  | sprites junk, tiles normal; both sprites/tiles are being read from 4F
| 1 | 1 | 1 | 1  | 1  | 1  | 1  | P  | 1  | sprites junk, all tiles solid gray; sprites being read from 4F? pin 9 on the 74ls138 is pulsing, it trying to use that to read tile data?

For the ACTIVE ROMS. The values are what I saw when probing with a logic probe.

0 = rom was always enabled
1 = rom was always disabled
P = pulsing, which is indicating the 74ls138 is flip/flopping enabling 2 roms

Pin 9 of the 74ls138 is not wired up to anything, but you can see it was getting enabled for 2 of the combinations.

Bit 4, does it select sprite palette for tiles?

It only seems to effect tiles. The end of this video shows me flipping the bit and it having no effect on the sprite colors, while the tiles change. Also the first part of the video shows me setting the first 3 bits to 110, which causes the sprite graphic data to get pulled from the tile rom (4F).

2026-09-20.09-52-18.mp4

For the sprite ram bank I adjusted the sprite debug so for jailbrek it only writes the sprite data to 0x1000 and rushatck to 0xd000

https://github.com/user-attachments/assets/4c4d3bbe-c97c-445a-a568-0b5df93528ce
https://github.com/user-attachments/assets/a9fc0ec9-95af-4031-a7a3-114a7648369b

The both behave the same. bit 3=0 causes the 5849 to read from 0x1000/0xd000 and bit 3=1 from 0x1100/0xd100

[happppp]

Thanks, I updated the notes here: 8556ed4

And did a small update to the drivers: 99c5ec7
Screen width is now 256 (left and right columns clipped with reg 3 0x80). And I also added 2nd spriteram bank to jailbrek (copy pasted from gberet). Now sprites aren't 30fps anymore in that game.

[jwestfall69]

I saw haze's irq comment on your commit so I grabbed irq/sync timings for both games to see if it might help with the sprite lag/emulation. These were taken with the original game code running and not my diag stuff. jailbrek doesn't seem to enable firq so its not included.

rushnatck irq:

rushnatck nmi:

rushnatck sync:

jailbrek irq:

jailbrek nmi:

jailbrek sync:

[happppp]

Thanks for double checking, it matches k005849.cpp and the drivers in MAME.