DETECTING RedKid2500-based consoles

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
FireRat
Interested
Posts: 10
Joined: Wed Jan 03, 2018 11:47 pm

DETECTING RedKid2500-based consoles

Post by FireRat » Wed Jun 12, 2019 7:49 pm

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?

Sik
Very interested
Posts: 901
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: DETECTING RedKid2500-based consoles

Post by Sik » Wed Jun 12, 2019 11:02 pm

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

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
EDIT: all the @ are because I stripped this code out of a larger subroutine and they're local labels.
Sik is pronounced as "seek", not as "sick".

Eke
Very interested
Posts: 856
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Re: DETECTING RedKid2500-based consoles

Post by Eke » Thu Jun 13, 2019 5:32 am

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

Sik
Very interested
Posts: 901
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: DETECTING RedKid2500-based consoles

Post by Sik » Thu Jun 13, 2019 7:26 am

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).
Sik is pronounced as "seek", not as "sick".

FireRat
Interested
Posts: 10
Joined: Wed Jan 03, 2018 11:47 pm

Re: DETECTING RedKid2500-based consoles

Post by FireRat » Thu Jun 13, 2019 3:42 pm

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:

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
Do you know if RedKid supports address error?

notaz
Very interested
Posts: 191
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Re: DETECTING RedKid2500-based consoles

Post by notaz » Thu Jun 13, 2019 3:48 pm

What's your reason for detecting emulators?
Just curious.

FireRat
Interested
Posts: 10
Joined: Wed Jan 03, 2018 11:47 pm

Re: DETECTING RedKid2500-based consoles

Post by FireRat » Thu Jun 13, 2019 4:25 pm

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.

Sik
Very interested
Posts: 901
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: DETECTING RedKid2500-based consoles

Post by Sik » Fri Jun 14, 2019 8:27 am

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).
Sik is pronounced as "seek", not as "sick".

Miquel
Very interested
Posts: 478
Joined: Sat Jul 30, 2016 12:33 am

Re: DETECTING RedKid2500-based consoles

Post by Miquel » Sun Jun 16, 2019 2:22 am

@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).
Sik wrote:
Fri Jun 14, 2019 8:27 am
You still may be better off not trying to detect emulators but rather the particular quirks
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.

Sik
Very interested
Posts: 901
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: DETECTING RedKid2500-based consoles

Post by Sik » Sun Jun 16, 2019 3:11 am

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.
Sik is pronounced as "seek", not as "sick".

Post Reply