konami/k005885.cpp: Device-fied K005885, Add notes #14172
Conversation
cam900
commented
Sep 14, 2025
cam900
commented
- Sprite emulation is still in each driver, because per-driver sprite quirks are remains (sprite RAM bank, draw list length, sprite size, etc)
- konami/ironhors.cpp: Fix notes, Use generic gfxdecode layout
- konami/ddribble.cpp, konami/finalizr.cpp, konami/ironhors.cpp, konami/jackal.cpp: Fix naming, Use BIT macro for single bit value
- Sprite emulation is still in each drivers, because per-driver sprite quirks are remains (sprite RAM bank, draw list length, sprite size, etc) - konami/ironhors.cpp: Fix notes, Use generic gfxdecode layout - konami/ddribble.cpp, konami/finalizr.cpp, konami/ironhors,cpp, konami/jackal.cpp: Fix naming, Use BIT macro for single bit value
There was a problem hiding this comment.
I find it a bit concerning that despite merging functionality duplicated in four systems to a common location, this ends up adding about 20% more lines than it removes (including other general cleanup), and also the sprite drawing is still implemented in all the system drivers.
How much is actually being shared here? If the sprite functionality is actually provided by the K005885 chip, what’s preventing it from being shared as well?
src/mame/konami/k005885.h
Outdated
| u8 ctrl_r(offs_t offset) { return (offset >= 5) ? 0 : m_ctrlram[offset & 7]; } // not from addressmap | ||
| void ctrl_w(offs_t offset, u8 data); | ||
|
|
||
| // scroll RAM | ||
| u8 scroll_r(offs_t offset) { return m_scrollram[offset & 0x3f]; } | ||
| void scroll_w(offs_t offset, u8 data) { m_scrollram[offset & 0x3f] = data; } | ||
|
|
||
| // tilemap RAM | ||
| u8 vram_r(offs_t offset) { return m_vram[offset]; } | ||
| void vram_w(offs_t offset, u8 data); | ||
|
|
||
| // sprite RAM | ||
| u8 spriteram_r(offs_t offset) { return m_spriteram[offset]; } | ||
| void spriteram_w(offs_t offset, u8 data) { m_spriteram[offset] = data; } |
There was a problem hiding this comment.
Can you use device maps and possibly avoid a layer of function calls for these?
There was a problem hiding this comment.
It will be, but some hardware allowed to reads these registers.
|
|
Is there a schematic available with a 005885 on it? |
https://arcarc.xmission.com/PDF_Arcade_Manuals_and_Schematics/Iron%20Horse.pdf has schematics for ironhors, last page mentioned 005885. https://arcarc.xmission.com/PDF_Arcade_Manuals_and_Schematics/Double%20Dribble%20Schematics.pdf is for ddribble. |
… register map konami/finalizr.cpp, konami/ironhors.cpp: Reduce duplicates in gfx layouts - screen_device in sprite_delegate is for priority map in screen.
|
Thanks, interesting chip. It has a bus for graphics roms that's 16bits*65536, where the games (at least ddribble) do banking to fit more. It has 8bits*65536 dram connected called "F", and a 8bits*8192 of sram called "X" and "V". Those must include tilemaps and sprite lists, but the dram makes me wonder what it's used for. There is also two ports from proms, one that gives 4 bits of VCB and VCF and expects 4 bits of VCD, and one with OCB and OCF and expects OCD. Iron Horse has proms, ddribble directly connects B to D. I wonder if the different attributes interpretations are due to that. What is sure is that we don't seem to be using those proms in Iron Horse (but we have them). The color output is 5 bits. If we want to implement a common version we need to take the proms and the address banking into account I guess. And it means understanding the prom ports, what they do. |
