DETECTING RedKid2500-based consoles
Moderator: BigEvilCorporation
DETECTING RedKid2500-based consoles
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 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?
Re: DETECTING RedKid2500-based consoles
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
EDIT: all the @ are because I stripped this code out of a larger subroutine and they're local labels.
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
Code: Select all
RedkidPsgFreq: equ $B00018 ; Redkid PSG frequency register
RedkidFmFreq: equ $B01054 ; Redkid FM frequency register
RedkidFmClk: equ $B01055 ; Redkid FM clock register
Code: Select all
if REDKID_FIX
lea @AbcdTable(pc), a0 ; Redkid systems have broken sound by
moveq #@NUM_ABCD-1, d7 ; default *BUT* there's a workaround!
@CheckAbcd: ; However we need to first detect
move.b (a0)+, d0 ; them because trying to poke the
move.b (a0)+, d1 ; registers directly will hang up on
move.w sr, d2 ; real hardware.
move.b (a0)+, d2 ;
move.w d2, sr ; ABCD has some undefined behavior
abcd.b d0, d1 ; when using invalid values which of
move.w sr, d2 ; course have specific behavior in
cmp.b (a0)+, d1 ; practice. The 68000 core in Redkid
bne.s @NoRedkidFix ; has an unique pattern to them, so
cmp.b (a0)+, d2 ; we try to use it as a fingerprint.
bne.s @NoRedkidFix
dbf d7, @CheckAbcd
move.w #$FFFF, ($0000).w ; Fix Redkid settings to match more
move.b #$00, (RedkidPsgFreq) ; closely real hardware (values found
move.b #$30, (RedkidFmFreq) ; by empirical testing during the
move.b #$20, (RedkidFmClk) ; development of Tanglewood)
move.w #$FFF7, ($0000).w
@NoRedkidFix:
endc
Code: Select all
;----------------------------------------------------------------------------
; Look-up table holding the values using to fingerprint Redkid systems by
; poking ABCD using undefined results. This table holds the values that would
; show up on those systems.
;----------------------------------------------------------------------------
; For each entry:
;
; uint8 .... source operand for ABCD
; uint8 .... destination operand for ABCD
; uint8 .... CCR before ABCD
; uint8 .... result after ABCD on Redkid
; uint8 .... CCR after ABCD on Redkid
;----------------------------------------------------------------------------
if REDKID_FIX
@AbcdTable:
dc.b $4A,$4A,$00, $94,$08
dc.b $4A,$4A,$1F, $95,$0A
dc.b $4E,$4E,$00, $9C,$08
dc.b $4E,$4E,$1F, $9D,$0A
dc.b $FF,$FF,$00, $FE,$08
dc.b $FF,$FF,$1F, $FF,$0A
@NUM_ABCD: equ (*-@AbcdTable)/5
even
endc
Sik is pronounced as "seek", not as "sick".
Re: DETECTING RedKid2500-based consoles
Couldn't you simply try to detect the presence of extended RAM ?
See this thread: viewtopic.php?f=2&t=2460&p=32814&hilit=firecore#p32814
See this thread: viewtopic.php?f=2&t=2460&p=32814&hilit=firecore#p32814
Re: DETECTING RedKid2500-based consoles
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).
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).
Sik is pronounced as "seek", not as "sick".
Re: DETECTING RedKid2500-based consoles
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:
Do you know if RedKid supports address error?
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:
Code: Select all
CheckEnv:
move.w sr,d7
move.w #$2300,sr
movea.l sp,a6
move.w .val+1,d1
moveq #0,d0
cmpi.w #$3456,d1
beq.s .quit
moveq #1,d0
.quit:
move.w d7,sr
rts
.hardware:
movea.l a6,sp
move.w d7,sr
moveq #2,d0
rts
.val: dc.l $12345678
Re: DETECTING RedKid2500-based consoles
What's your reason for detecting emulators?
Just curious.
Just curious.
Re: DETECTING RedKid2500-based consoles
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:
EDIT: Writing to an unsupported even/odd SRAM address does not hang the system, it just stays at 0.
- 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.
EDIT: Writing to an unsupported even/odd SRAM address does not hang the system, it just stays at 0.
Re: DETECTING RedKid2500-based consoles
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).
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).
Sik is pronounced as "seek", not as "sick".
Re: DETECTING RedKid2500-based consoles
@FireRat, so you are obtaining a word/long from an odd address the seeing if the Address Error Exception fires?
That's easy to detect on a emulator ("address & 1") and at least some emus check it (Reggen comes to mind).
That's easy to detect on a emulator ("address & 1") and at least some emus check it (Reggen comes to mind).
You can turn crazy detecting every emu there is, the faster and clean approach is to detect if real hardware is present.
HELP. Spanish TVs are brain washing people to be hostile to me.
Re: DETECTING RedKid2500-based consoles
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.
It's better to check for what differences could break your game than to try to check for particular models.
Sik is pronounced as "seek", not as "sick".