tatsumi code location shuffle (not a cleanup) #13503
Conversation
|
it would be fairly trivial to kill off the tatsumi.cpp base at this point too, the CRTC stub could go in a device, and the little rest that's in there is so boilerplate it could be duplicated in the individual drivers where needs be, however that's out of scope for this initial move. |
|
HD6445 would be shared with |
|
I mean it doesn't even seem to do anything right now other than log, so it could just be killed off entirely if it would be better implemented as something else. Anyway, I'm sure you can see where I'm going with these changes. It's not much fun looking at some of the specifics of say Apache 3 when the files are full of things only used by Cycle Warriors or Round Up 5. Despite the 3 similar board numbers, and shared sprite chip, they're mostly very different beasts. |
… but now confirmed on a PCB.
|
Round Up 5 is confirmed with a PCB to be TZB315, despite having the smaller CLUT found on Apache 3 (TZB215) and not the larger one on Big Fight / Cycle Warrors (TZB315) That's not what I was expecting. I'll add looking for a configuration register to my list of things to do, unless there's a pin determining it. That means there are still no known differences between TZB215 and TZB315. Comment was updated to reflect that this is now confirmed, because the behaviour was suggesting otherwise. |
|
HD6445, by the way, is identical to HD6345 except for bus signals. |
|
so basically we can kill that logging off, and (at the very least) add a TODO because HD6345 already exists as a device. Possibly hook it up if it doesn't cause issues. I'll note that for the next stage |
Unlikely: first off it means converting that to the dull current 6845 interface, something I've already expressed my disdain in multiple places. Also worthless because the HD6345/HD6445 has several 7220-like features, namely can be chained for genlocking .. |
|
Well we'll cross that bridge when we come to it, which is exactly why I'm dividing this work into smaller steps such as this one where nothing is actually being changed, it allows those decisions to be made separate to this. I'm not sure the current in-driver CRTC code which does nothing but log has any actual value over what's in the existing device, and the ever changing MAME politics of "you must reuse existing device, you're not allowed to write a new one" vs. "no you must do a completely new implementation" aren't really of interest to me. |
|
|
|
again, I don't currently care. This is a code move. Nothing more. Why does every single simple task have to be a mountain with MAME? It's insane levels of inefficiency with the workflow, and people wonder why they see so little progress on the arcade drivers. What should have been a couple of days work to get merged is now running into a month, and all I'm doing is getting severely burnt out with all this BS. |
The original 6845 doesn't even support smooth scrolling natively. Some 6845-based systems implement smooth scrolling by either ignoring most of the CRTC outputs and implementing custom line counters in external hardware (falco/falcots.cpp is a partially working demonstration of that concept) or by abusing the RESET pin in a way MAME's emulation doesn't even begin to accommodate. |
|
mame/src/devices/video/mc6845.cpp Lines 958 to 977 in 7f51ac8 I won't be surprised if this doesn't work right, and regardless there's no uint32_t roundup5_state::screen_update(screen_device &screen, bitmap_rgb32 &bitmap, const rectangle &cliprect)
{
int tx_start_addr;
tx_start_addr = (m_hd6445_reg[0xc] << 8) | (m_hd6445_reg[0xd]);
tx_start_addr &= 0x3fff;
m_sprites->update_cluts();
m_tx_layer->set_scrollx(0,24);
m_tx_layer->set_scrolly(0,(tx_start_addr >> 4) | m_hd6445_reg[0x1d]); // <- here |
This is the 2nd part of the old Tatsumi PR, essentially moving code around into individual files, as each of these has a significant amount of unique behaviour that really doesn't lump together well. It should be clearer now that it's just a code move as it's not tangled with the sprite device refactoring.
This is not a clean-up pass, the ONLY clean-ups done are simple OVERRIDE ones, replacing them with video_start, machine_reset. Nothing has been reformatted or refactored. If anything there are less attempts at clean-ups here than the previous submission as not to entangle the steps. Feedback requesting changes to code already present in MAME that has simply been moved will not be considered for this PR.
The point of this PR is to prepare the files for further clean-up by having everything in a more suitable location, essentially breaking down one large unmanageable task into multiple smaller ones that can be completed at will.