Hello.
I want to develop a game that's compatible in one of the most common clones around, which also happens to be the worst, too bad. I'm talking about those based on the RedKid 2500 SoC, such as AtGames' Firecore, TecToy's Megadrive 2017, and so on. It's easily distinguishable by its horrible sound setup, caused by bad hardware configuration from the MDI, the firmware.
In order to have proper sound among other fixes, games can be ran through firmware replacement "Neto Boot Loader", or fixing said hardware configuration from the game's side, like Tanglewood does. Of course, I'm taking the latter approach, which wouldn't require the custom firmware if the user doesn't know/want it.

There's a nice guide documenting the ports for RedKid 2500 settings along with suggested "good values" right here: https://www.neto-games.com.br/hacking_g ... id2500.php
The problem with that is, that to date I have found zero info on how to detect this environment!! I need to detect it, because attempting to write to hardware settings while running on actual real hardware, would crash it. I've tried looking on the net for hours, I've not found much. The closest is this post from Neto, but... it tells me nothing, unless I knew what did Jump_Control, M68K_Clock and Z80_Clock do equal to. May I ask anyone owning these clones to check those values with the Neto Boot Loader, and post what do these mean or something?

I'd like to try myself but, I really can't even afford a bad clone just yet until I either complete studies (4 more years) or something else happens. Thanks for your patience.

EDIT: Yes I know those COULD be pointers to the real ports, how to know it doesn't actually mean the VALUES?

I should write an article about this at some point. You can fingerprint shitty clones by probing what happens when using invalid BCD values.

This is the code I currently have albeit I need to verify it does what it's intended to do (at least it doesn't seem to crash). It's based on what Tanglewood does (albeit Tanglewood does more checks on top of this). Hope BigEvilCorp doesn't mind, at least the code was written from scratch :​P

That could needlessly trip some modded consoles tho (and Tera Drive would trip the VRAM check as well). Magistr16 could also trip it since it has more work RAM (256KB) and you don't want to detect it since as far as we can tell its sound is fine. By general rule, you want to avoid needless collateral damage when it could have worked just fine.

Also in case anybody reads that thread and gets the wrong idea: $B00000 onwards is where the custom registers are stored. Also trying to probe them is precisely what you should avoid because it'll hang up on a real console (hence needing to fingerprint them in another way, e.g. using ABCD).

Thanks a lot, Sik!
An aside question. Just before the place I intend to run the RedKid check, I have another check for detecting Kega Fusion, Gens/PicoDrive/GenPlusGX, and hardware, all based on odd addressing's behavior, like this:

I'm building a base engine for MD, MCD, 32x and System C2. In the case of MD, I'm detecting the presence of SRAM and kind (size, even/odd support), MCD presence, HW/Emu environment, and hopefully which Emu or HW version (including clones in this case). There's a lot of things you can do in a certain setup but not in another, or things you must do differently. In the case of VFX, the result could be different depending of a setup's timing (for instance, for a certain HBlank-based effect, I had to write a version specific to Gens). Or in the case of software-rendering a mode7-like field (such as the special stage from Sonic CD), I can:

Is MCD present? If yes, use the hardware renderer through ASIC and DMA the result from WordRAM

Do we run from AtGames? If yes, increase 68k clock if necessary, use the software renderer (mode 0), tell it to buffer base+processed textures to additional RAM and DMA it when frame is complete (if booting from cart, it may require copying the game to SDRAM and running from there, not sure yet)

Do we run from real HW with enough SRAM present and full even/odd addressing support, or an emulator? If yes, use software renderer (mode 0), tell it to buffer base+processed textures to SRAM (just like gasega68k demo)

Do we run from real HW and there's enough SRAM present, but only at even or odd address? If yes, use software renderer (mode 0), tell it to buffer base+processed textures to SRAM and DMA it, but cart hw would auto-skip the even or odd address. Output would look 2:1 though, with half the horizontal resolution (EDIT: Yes in this case I'd only be using half the total of bytes), but I can fill the gap by displaying the output from both plane layers and horizontally shifting one of them.

Do we run from real HW and there's not enough SRAM present, no matter if even or odd address? If yes, use software renderer (mode 1), tell it to buffer base+processed textures to SRAM at 1/2, or 1/4, or 1/8, or whatever size it fits, and either DMA it, maybe more than once, with a different auto-increment... OR, I heard it's best to do it with manual writes in this case

Do we run from real HW and there's no SRAM in the cart at all? If yes, either pick the other bonus stage (there's 2), or... use the slower software renderer (mode 2), which although not coded yet (so I don't know if resulting FPS would be acceptable, even with quality loss), should do less emphasis on buffering, which means writing it all manually to VDP. I don't want to resort to TOO MANY unrolled loops or LUTs, with or without them the result would nevertheless be lower than the methods above, but wasting so much ROM would defeat their purpose as well.

I'm writing this engine for my last Sonic the hedgehog fangame, I'll release the source code once it's complete, and I'm going to use this base for making custom homebrew in the future, hence why it targets so many devices. I want it to be versatile enough so I interchangeably better code to it in ASM+C without GAS (that's just personal) but most importantly, don't need require to constantly test my program everywhere or ask friends to burn their CDs Overall the point is to get the program working in a shorter time with less mental effort, because I have a career to study right now. BUT, BECAUSE there's a slight unavoidable CPU cost, depending the target device I'm compiling for, and the environment the engine runs at, I do apply different speed hacks as necessary. Sound messy, but I already tried to port a WIP game to MCD+32x combo "the right, clean & optimized way" , all in ASM, with a friend in charge of Sh2, all in a short time but, the burn-out was horrible.

EDIT: Writing to an unsupported even/odd SRAM address does not hang the system, it just stays at 0.

You still may be better off not trying to detect emulators but rather the particular quirks, then you can catch multiple implementations sharing the same quirks. Redkid is kind of an exception since the registers in question are pretty much a feature unique to Redkid rather than a quirk.

I suppose you may want to include detection of 128KB VRAM (which is not present on stock consoles but can be modded in, as well as being present on a Tera Drive). You could exploit it either to add more detail (more graphics in VRAM) or to speed up transfers (important for software renderers). In the latter case make sure to probe that DMA speed indeed gets faster, mind you (do a large enough DMA and see how many lines it takes).

But even different revisions of real hardware have some different quirks, and again, there's also modded systems to account for (which more likely than not will work just as fine, yet could potentially trip some careless checks like trying to guess by measuring memory size).

It's better to check for what differences could break your game than to try to check for particular models.