New NMK214 device: added implementation for NMK214 descrambling GFX device and hook it up to nmk16 driver

[sergiopolog]

Added implementation for NMK214 as a new device. It's used for descrambling GFX data on some games in the nmk16 driver.

The implementation was made based on the reverse engineering work of the chip at silicon level:
https://github.com/sergiopolog/GateArray-RE/tree/master/NMK/nmk-214

Results of the descrambling GFX process for both sprites and background tiles using this implementation match exactly with the ones from previous implementation made by @mamehaze (and Antiriad) back then.
In this case, all the internal configurations that could be selected to perform it are included, even if they are never used for any game, just for documentation purposes.

Real hardware performs the descrambling process on the fly for each word/byte fetch from GFX ROMs, but due how the drawgfx system is made on MAME, I couldn't find an option to integrate it and mimic the real hw behaviour.
I simply run the decoding of the entire GFX regions just when both devices are initialized at startup, (similar to what the previous implementation did on init handler).
If there is a way to do this on real GFX fetches from 'sprites' and 'bgtiles' regions, please, let me know.

By now, the descrambling process is only hooked up for sabotenb (and clones) set.
On a later PR, I plan to apply it to the rest of games using it on nmk16 driver and split the current "tdragon_prot_state" class into two different classes: One for NMK111 and NMK113 protection (tdragon and hachamf) and another one for NMK214-215 protection, as they are completely different processes, even if they use the same MCU model (TLCS-90)

[cuavas]

If you really want decoding to happen on-the-fly, you can’t use gfxdecode_device – its purpose is to cache decoded tiles, so it works by reading tile graphics en masse and storing the bitmaps in an easy-to-use form.

The code looks like it would have issues with soft reset (F3 by default). If the user resets the system, the already decoded graphics ROM content will be decoded again. This may be masked by the caching performed by the gfxdecode_device, as tiles decoded before the system was reset won’t be decoded again.

Also, tiles aren’t invalidated after the NMK214 is configured, so any tiles that are decoded before that (e.g. if the user manages to pause the system immediately on start and bring up the tile viewer before the game initialises the NMK214) won’t be refreshed when.

[sergiopolog]

If you really want decoding to happen on-the-fly, you can’t use gfxdecode_device – its purpose is to cache decoded tiles, so it works by reading tile graphics en masse and storing the bitmaps in an easy-to-use form.

Got it. Is there any other (feasible) alternative to 'gfxdecode_device' to use in decoding gfx?

Apart from that, all other fixes/suggestions are included now in the PR

[sergiopolog]

@cuavas Is any further action needed on this PR from my side?

[cuavas]

I tidied up the code and pushed to your branch.

It still isn’t going to play nicely with save states because the content of the memory regions won’t stay in sync with the state of the decoder (memory regions aren’t added to save states because they’re intended to be used with ROM which is static).

The case were I’d anticipate this causing trouble is with -state where a save state is loaded immediately on start. At this point, the system probably won’t have initialised the NMK214 chips, but the save state will likely have been taken after those chips have been initialised, so it will run with scrambled graphics.

Solving it properly, and allowing on-the-fly changes to the unscrambling, really requires device_gfx_interface to be slimmed down with the actual decoding moved to a derived class.

I can think of a couple of relatively easy ways to work around it:

• The brute force approach of adding the graphics ROM region contents to save states for systems using the NMK214 chip.
• Add an additional member not registered for save states to track whether graphics have been actually been decoded, and implement hackery in device_post_load to force an immediate decode if a saved state is loaded before graphics are decoded, or to suppress decoding graphics when going the other way.

[cuavas]

I patched it up using the second approach, and added the code to force tiles to be decoded after unscrambling. This will do until device_gfx_interface is refactored some more.

[sergiopolog]

@cuavas Thanks. I will prepare another PR to include this descrambling process to all the games using it in the nmk16 driver.

tdragon_prot_214_state could be decoupled from tdragon_prot_state, as latter is only used for tdragon and hachamf, but not for the rest of games, so I will do it, too.