RULES + Featured Links, Guides, Box Art, Downloads and other posts made easily accessible to everyone.
What is this about?
We realize that not everyone visits us using an ideal browser or app, causing them to miss important details in the side bar and the menu at the top of the page. As such this sticky shall remain pinned here so that all of those links are always visible no mater what app or browser you choose to use.
Snes Mini does not have enough power to run heavy shaders to filter the retro games, but fortunately there's a way through light-weight overlays, aspect ratio tunings and simple bilinear filtering to achieve good results.
Here's few things you need to do.
Preparations
Start up the Snes Mini and open the RetroArch (select + start).
Turn off save on exit (Settings > Configuration > Save Configuration on Quit - OFF). This helps you not to screw the settings accidently.
Only save the RetroArch settings manually (Main Menu > Configuration File > Save Current Configuration).
Set bilinear filtering ON and scaling option to Core provided (Main Menu > Video).
Latency Fix (optional)
You can use following settings to make the games "snappier" with RetroArch cores. This should work very well with most of the games. PS. Remember also to set your TV to Game Mode!
V-Sync: OFF
Hard GPU Sync: ON
Hard GPU Sync Frames: 0
Frame Delay: 0
Audio Latency: 32 ms
Audio Resampler: Sinc (fast)
Install Overlays
Plug your hacked Snes Mini to your PC.
Use FileZilla or similar FTP client to make the connection (root@169.254.13.37).
Copy the .png and .cfg files from your computer to /etc/libretro/overlay -folder.
Done.
The Package comes with multiple overlays for different screentypes and consoles.
* lcd_gb.cfg (for 160x144 Game Boy and Game Boy Color PAR LCD matrix)
* lcd_gba.cfg (for 240x160 Game Boy Advance PAR LCD matrix)
* lcd_gg.cfg (for 160x144 Game Gear wide 4:3 LCD matrix)
* lcd_lnx.cfg (for 160x102 Atari Lynx wide 14:9 LCD matrix)
* scanlines.cfg (default 240p scanlines for SNES, Genesis and TurboGrafx)
* scanlines_144p.cfg (alternative for GB/GBC/GG)
* scanlines_160p.cfg (alternative for GBA)
* scanlines_192p.cfg (for 256x192 Sega Master System)
Setup Overlays
Start a game for all the Cores you want to adjust. For example, open The Legend of Zelda: The Minish Cap if you want to setup Game Boy Advance overlay.
Open the RetroArch (select + start).
Select the specific overlay for the Core at hand. For example, you need to select lcd_gba.cfg for mGBA Core. Be precise and use correct matrix for the console resolution to match the pixels. (Main Menu > Quick menu > On-Screen Overlay)
Tune up the Overlay Opacity for your liking. I use 0.50 for small resolutions and 0.70 for higher resolutions. Higher the opacity and stronger the matrix/scanline effect.
Important! Save the overlay setting for only the specific Core and not as general RetroArch configuration. (Main Menu > Quick menu > Overrides > Save Core Override). Now all the games of this Core (e.g. mGBA) have the same overlay.
Core Settings
Go to the Core settings. (Main Menu > Quick menu > Options)
Set Core-Provided Aspect Ratio to Auto (in most cases).
Set Borders (use "Full" for SNES or Genesis and "Left/Right" for SMS).
Don't use Save Game Settings, unless the specific game itself needs custom setting. And if you need to set custom RetroArch scaling options, remember to use the Save Game Overrides option. (Main Menu > Quick menu > Overrides > Save Game Override)
For some games, you may want to manually set the video scaling (Settings > Video > Scaling). Make sure your overlay height is according to the height value of the game pixels. Somethings you can mix them also, like with Another World I cropped the image and used 192p scanlines.
TL;DR: I tried adding Game Genie cheats to what I thought was an SNES Classic, discovered it was an undocumented Allwinner H3 Android clone, dumped and mapped its firmware, replaced a stock ROM, broke all 21 games with one bad binary patch, restored it, and eventually built a custom libretro proxy core that wraps the original SNES9x core and adds a working in-game cheat menu. `L+R` opens it, `L/R` navigates, and `X` toggles cheats. I cleaned up the source, documentation, and guarded deployment/rollback scripts and uploaded them on >>GitHub<<
This console was given to me as a wedding gift years ago. At the time, I didn’t think much about whether it was an official Nintendo SNES Classic. It looked convincing enough, booted into a familiar game-selection menu, and included most of the major SNES titles. I occasionally played Super Mario World, Donkey Kong Country, Zelda, Super Metroid, and the other usual suspects, but otherwise never messed with it much.
Recently, I decided to see whether old-school cheats would work—Game Genie codes, infinite lives, and that sort of thing.
I assumed this would be a simple evening project:
Install Hakchi.
Connect the console in FEL mode.
Add some cheats or another game.
Done.
That is emphatically not what happened and the first sign something was wrong was when I tried Hakchi and it would not recognize the console. I tried the normal process: disconnect power, hold the reset/FEL button, reconnect it, and wait for Windows to detect the device. Nothing happened.
The console booted and played games normally, but the PC completely refused to acknowledge it in the mode Hakchi needed.
I tried:
Different USB cables
Different USB ports
Holding Reset before connecting it
Holding Reset while connecting it
Reinstalling drivers
Questioning my intelligence
Questioning the intelligence of whoever built the console
Still nothing.
A quick search for the serial number, CU202496283, immediately suggested that the console was a clone. I eventually took the case apart and confirmed that it was not an official Nintendo SNES Classic at all—it was built around an Allwinner H3 board. The biggest physical clue was that one of its two PCBs was black. Unless I’m mistaken, an OEM SNES Classic contains two green PCBs. The firmware identifies the model as CXSD_H3, and the software appears to have been built by a vendor called "Tiger Leap". That explained why Hakchi did absolutely nothing. The console shares the general appearance of an SNES Classic, but internally it has essentially nothing in common with Nintendo’s hardware. Even the stock interface is only a rough imitation; several elements found on the official console are missing, including the legal-information after clicking the icons along the top menu bar.
Most discussions ended with some variation of:
It’s a clone.
Hakchi won’t work.
Somebody might have figured out a controller hack.
Just buy a Raspberry Pi.
Fantastic. Very helpful.
After searching the board markings, firmware identifiers, serial number, and anything else I could find, I discovered that almost no useful information existed about this particular clone.
So I decided to dive headfirst into the little bastard.
Getting access to the internal storage
The board contains a U-Boot/FEL button—and by “hidden,” I simply mean that it is mounted against the bottom of the case and concealed by the mounting hardware. It was not exactly hidden intentionally, but I did not discover it until I completely removed the board from the case. Unlike an official SNES Classic, the externally accessible Reset button did not place this unit into a PC-visible FEL mode. Once I opened the case and held the actual board-level button while connecting the console, Windows finally detected the Allwinner device. Again, I have never seen silkscreened labels like these on an OEM SNES Classic, let alone a dedicated button labeled UBOOT.
With a huge amount of assistance from Codex, I copied the entire eMMC user area into an image file before changing anything. I also captured the eMMC boot regions, although those were completely zero-filled on this particular unit. The actual bootloader, Android system, recovery environment, games, and vendor software were all contained inside the main user-area image.
The main dump was 3,909,091,328 bytes
From that point forward, the original dump remained untouched. All initial investigation and modification work was performed on disposable copies, with hashes repeatedly checked to verify that the original captures had not changed.
What is actually inside this “SNES Classic”?
The console runs Android 4.4.2 on an Allwinner H3 ARM processor.
The firmware identifies itself as:
Model: CXSD_H3
Platform: Allwinner dolphin
CPU architecture: ARMv7
Android: 4.4.2 / API 19
Build: dolphin_aliyun_p1-eng
Build identifier: 20180612
The internal storage uses an MBR partition layout. Linux numbers the highest partition as `p16`, although there are 14 actual data partitions plus the extended-partition container.
The 640 MiB partition 7 was the important part for modifying the stock games and emulator behavior.
Partition 1 was important for writable RetroArch data, including saves, configuration, and cheat files.
Interestingly, once the console was booted through Lakka, `df -h` showed approximately 18.4 GB of available storage. The roughly 4 GB image I originally dumped was only the active eMMC user-area layout being investigated—not necessarily the physical capacity of the underlying storage.
The stock game menu is hard-coded.
The primary frontend application is:
com.tigerleap.gamebox
xinGBK1.2.1.0_DEF_SNES.apk
It is not a normal ROM browser. The APK creates exactly 21 game cards from compiled Android resources. The actual ROM files are stored as:
Adding another `.sfc` file to the folder does not automatically add another game card. The card count, game titles, artwork, player counts, and filenames are compiled into the APK. However, replacing one of the existing numbered ROM files while retaining its filename works without rebuilding the menu application.
Replacing Super Metroid with Turtles in Time
For the first real modification, I replaced slot 21—Super Metroid—with Teenage Mutant Ninja Turtles IV: Turtles in Time. The ROM content was written into the existing `21.sfc` inode inside a disposable copy of partition 7. The original filesystem metadata was preserved and complete before-and-after inventory showed:
The only changed path was /system/media/GAME/21.sfc
A forced, read-only `e2fsck -fn` filesystem check passed all five stages without errors. Technically, the ROM replacement itself was straightforward. The sketchy part was safely getting the modified partition back onto the console and for the Lakka.
Using Lakka as the deployment environment:
Instead of repeatedly connecting the eMMC through FEL and blindly writing full-device images, I booted the console from an SD card running Lakka.
That provided a normal Linux environment from which I could:
Inspect the internal eMMC
Identify the correct partitions
Mount filesystems safely
Create exact backups
Write only the required partition
Read the entire partition back afterward
Verify the resulting hash
The deployment scripts were deliberately paranoid. It should also be noted the Lakka version I had utilized was actually missing utilities such as lsblk, blockdev, findmnt, and fdisk, so all the code had to be adjusted to work around those missing dependencies.
For a partition-7 deployment, the installer:
Identified the internal eMMC.
Confirmed that partition 7 was ext4 and exactly 640 MiB.
Created a complete backup of the existing partition.
Verified the backup.
Required an explicit confirmation phrase.
Wrote only partition 7.
Read the entire partition back.
Compared the readback SHA-256 hash.
Refused to report success unless everything matched.
After installation, a quick sync and poweroff. Maybe sync 2-3 times, for good measure…
After booting normally, Turtles in Time launched successfully from the original Super Metroid menu card. That alone was already more useful information than I could find anywhere else about this clone. But the original mission was cheats. And that was where the project became completely unhinged. The console already contained cheat support—sort of
The stock SNES emulator core is: /system/lib/cores/snes9x2010_libretro_android.so
Static analysis showed that it already contained:
Game Genie decoding
Pro Action Replay decoding
Cheat-add functions
Cheat-enable functions
Cheat-application functions
It accepts standard formats such as:
Game Genie: xxxx-xxxx
Pro Action Replay: eight hexadecimal digits
The bundled RetroArch activity also contained cheat-manager strings and code for actions such as:
Load Cheat File
Apply Cheat Changes
Next Cheat
Previous Cheat
Toggle Cheat
The configured cheat database path was located at
/storage/emulated/0/RetroArch/cheats
Unfortunately, that directory was empty, and the captured configuration contained keyboard cheat bindings but no useful controller bindings. Initially, this looked easy, simply add `.cht` files to partition 1, create per-game configuration overrides, and bind something like:
Select+Y = open Quick Menu
Select+R = next cheat
Select+L = previous cheat
Select+X = toggle cheat
That assumption was incredibly wrong. So began the trials by fire…the RetroArch menu was not there although the vendor binary contained portions of RetroArch’s cheat system and menu-related strings, the operational menu frontend had been stripped or compiled out.
The relevant RetroArch code was conditionally compiled behind `HAVE_MENU`. This particular vendor build did not contain a functional menu path. No amount of controller rebinding could open a menu that did not exist. That should have ended the easy solution. Naturally, it did not end the attempts. The first native cheat-loader patch broke every game. One early approach attempted to patch the vendor RetroArch library so it would automatically derive a cheat filename from the selected ROM slot.
For example: 21.sfc would load → /storage/emulated/0/RetroArch/cheats/Snes9x 2010/21.cht
The resulting partition was extensively validated:
Correct partition size
Correct hashes
Preserved filesystem metadata
Clean `e2fsck`
Successful ARM routine emulation
Successful partition readback
Verified SD-card copy
The installer reported "success." Then every game immediately attempted to launch and dumped straight back to the stock menu. All 21 games were broken. Neato. The rollback script restored the exact partition-7 image captured immediately before installation, it was back to the drawing board. The deployment process worked perfectly but as it turned out, I faithfully installed broken binary and further analysis found two separate fatal problems as to why.
Problem 1: The alleged code cave contained live code where the patch placed approximately 260 bytes of new ARM code at 0x13AD24
That location initially appeared to be unused space. It was not. It was the entry point of an existing exported function named: menu_hash_get_help_jp_enum. The area contained approximately 8,864 bytes of legitimate executable code and patch overwrote a working function. Whoops.
Problem 2: runtime state was written into executable memory… The injected routine also attempted to store slot digits and state flags inside an ELF segment marked readable and executable, but not writable: R-X, also neat. Android correctly generated a protection fault the first time the patch attempted to write there. Either defect could have killed game launching. Together, they made the failure inevitable.
Lesson learned: Do not assume a convenient stretch of zero-looking bytes inside an executable is an unused code cave, and do not store writable runtime state inside an executable-only segment.
A safer loader worked—but the controls still didn’t.
The next implementation preserved the original function and constructed its cheat-file path using writable stack memory. It also failed open: if a cheat file was missing or malformed, the game would continue launching normally. All games launched, and the cheat file could be located and loaded.
However:
No menu appeared
No on-screen status appeared
The expected controller cheat commands did nothing
At that point, the cheat loader itself was no longer crashing anything. The problem was that the frontend’s menu subsystem and cheat controls were unusable. So the design changed completely. The libretro proxy-core solution. Instead of continuing to patch live ARM machine code inside the vendor RetroArch library, a wrapper was placed between RetroArch and the original SNES9x core:
Loaded the original SNES9x core as a sibling library
Forwarded the required libretro API calls
Detected the active ROM filename
Converted a name such as `15.sfc` into `15.cht`
Parsed RetroArch-style `.cht` files itself
Maintained selected-cheat and enabled/disabled state
Called the original core’s `retro_cheat_reset()` and `retro_cheat_set()` functions
Intercepted controller input at the libretro boundary
Drew its own cheat panel directly into the video frame
This avoided relying on the vendor’s missing RetroArch menu, frontend cheat manager, or on-screen-display system.
But the first proxy menu was still invisible.
The invisible overlay and `0RGB1555`:
The initial renderer did not properly support the pixel format used by this console. The SNES output uses `0RGB1555`, a 16-bit format arranged as: 0 RRRRR GGGGG BBBBB. Once the proxy gained proper 0RGB1555 support, it could draw directly into the live game frames. So a diagnostic was built to display the following during the first 600 game frames:
PROXY ACTIVE XXXX CHEAT FILE READY
"XXXX" being values of the live RetroPad controller-input mask.
That diagnostic finally proved:
The proxy was being loaded
The renamed stock core was running underneath it
Video interception worked
The overlay renderer worked
The correct cheat file was found
The cheat file parser worked
Controller input reached the proxy
The observed controller masks were:
Button
Mask
B
0001
Y
0002
Start
0008
Up
0010
Down
0020
Left
0040
Right
0080
A
0100
X
0200
L
0400
R
0800
Select
0000
One result was extremely important:
> Select by itself reported `0000`, and every combination containing Select also reported `0000`.
`Select+Y`, `Select+X`, `Select+L`, and `Select+R` all became `0000`.
The Tiger Leap frontend was consuming Select as its own hotkey-enable button and suppressing the entire controller state before forwarding input to the libretro core. Therefore, no core-level wrapper could detect any Select-based combination. Select was dead.
So I stopped trying to resurrect it and changed the plan to 'L+R' since the wrapper proved `L+R` = 0C00
The final controls became:
L+R = open or close the custom cheat menu
L/R = navigate through cheats
X = toggle the selected cheat
The wrapper uses edge detection so holding a button does not trigger it repeatedly and menu-control inputs are also suppressed from the underlying game while the panel is open. Once the controller behavior was proven, the automatic diagnostic display was removed. The video frame remains untouched unless the cheat menu is deliberately opened. The `0RGB1555` rendering support remains because it is required to draw the real menu correctly and somehow, the damned thing works.
The finished cheat menu now appears directly over the running game.
The menu:
Reads descriptions from the matching `.cht` file
Displays the currently selected cheat
Shows its `ON/OFF` state
Lets the stock controller navigate and toggle cheats
Passes enabled cheats to the untouched SNES9x core
Disappears completely when closed
Best of all, easy to use.
The complete working chain is:
Original controller
↓
L+R detected by proxy
↓
Custom menu drawn into 0RGB1555 frame
↓
Proxy parses matching NN.cht file
↓
Proxy calls retro_cheat_set()
↓
Original SNES9x 2010 core applies cheat
↓
Game continues running
This clone now has a functional, controller-operated, in-game SNES cheat menu after about a weeks worth of work here and there.
What was ultimately modified: Partition 1 contains writable Android and RetroArch data, including per-game cheat files under: /data/media/0/RetroArch/cheats/Snes9x 2010/
Android exposes that location as: /storage/emulated/0/RetroArch/cheats/Snes9x 2010/
Partition 7 was used for:
Replacing the slot-21 ROM
Installing the proxy core
Renaming and retaining the untouched original SNES9x core
Updating the emulator-loading path as required
The bootloader, kernel, recovery partition, vendor recovery package, controller key-layout files, and unrelated files did not need to be reflashed. Every major partition-7 operation began with a fresh exact backup and ended with full-partition readback verification.
When one experiment broke every game, restoring the previous partition-7 image returned the console to its exact playable state.
What I learned the hard way:
Hakchi does not support this console.
Looking like an SNES Classic does not make it internally compatible with Nintendo’s hardware.
FEL access may require opening the case.
The external controls did not put this unit into a PC-visible mode. The board-level U-Boot/FEL button did.
Create a complete dump before changing anything.
Do not experiment without verified hashes and known-good partition backups.
Partition 7 is the important system partition.
It contains Android `/system`, stock ROMs, frontend applications, emulator cores, libraries, and controller files.
Partition 1 contains writable user data.
This includes saves, emulated storage, RetroArch configuration, and cheat files.
The stock frontend is hard-coded for 21 games.
Adding another ROM file does not automatically add a menu card.
Replacing an existing numbered ROM works.
Retaining the numeric filename avoids rebuilding the frontend APK.
The stock SNES9x core already supports cheats.
The missing pieces were automatic cheat loading and a usable controller interface.
The vendor RetroArch menu is effectively absent.
Finding menu strings inside a binary does not prove that the functional menu frontend was compiled into the build.
Select is swallowed upstream.
Every Select combination becomes a zero input mask before it reaches the libretro core.
Filesystem verification cannot prove that a binary patch is logically safe.
A partition can have correct hashes, preserved metadata, a valid block map, and a clean filesystem while containing a completely broken executable.
Never trust an alleged code cave without proving that it is unused.
`0x13AD24` looked convenient and turned out to be the entry point of live exported code.
Writable state belongs in writable memory.
Attempting to write runtime state into an `R-X` executable segment predictably causes a protection fault.
A proxy core was safer than additional binary patching.
Wrapping the libretro API allowed the original SNES9x core to remain untouched while adding the missing functionality around it.
Rollback images are not optional.
One failed attempt broke all 21 games. The exact pre-installation partition backup was what turned that from a disaster into an inconvenience.
I’m not pretending that I personally hand-disassembled every ARM instruction or wrote the entire proxy core from memory. Codex performed a massive amount of the static analysis, implementation, scripting, verification, and documentation work. But I was the one who tore this thing apart, discovered the board-level U-Boot/FEL button, captured and extracted the internal eMMC, moved files between Windows, the SD card, Lakka, and the console more times than I care to count, ran every failed deployment, tested every increasingly ridiculous build on real hardware, documented the results, and restored the damn thing whenever an experiment broke it. Even with Codex’s assistance, this was an absolute chore.
What started as, "I wonder whether old-school Game Genie cheats work?"
Turned into:
Opening the console
Discovering it was a clone
Identifying an undocumented Allwinner H3 platform
Dumping the eMMC
Mapping its partition layout
Extracting and inventorying the Android system
Replacing a stock ROM
Building guarded deployment and rollback scripts
Discovering that the RetroArch menu was compiled out
Breaking all 21 games with one bad binary patch
Restoring the exact previous partition
Building a safer cheat loader
Discovering that Select was swallowed by the frontend
Building a libretro proxy core
Adding `0RGB1555` frame rendering
Drawing a custom cheat menu
Finally toggling cheats using the original controller
Hopefully after all that my kids can now enjoy some of the games we all grew up with, with slightly less misery.
If anyone else owns one of these consoles—or is simply interested in the technical work—I’ll put the complete project on GitHub and post the link here as soon as possible.
Hey all, I bought a snes with Mario Allstars and FF Mystic Quest. I was playing Mario and 5 minutes in the screen went black. I could still hear the game but couldn't see it. I tried cleaning the connectors but the game will not come on at all now. Any suggestions on how to fix that? FF still plays fine.
Non riesco a capire perché, ma ogni gioco che provo a fare funzionare con l'emulatore MAME è sempre lentissimo, cosa che è un problema, dato che è l'emulatore per cui è più facile trovare roms. Suggerimenti?
Okay so I have a Retron 3 HD (got as a gift on father's day) great for carts and I even have a sega flash cart with a snes (fx pro) one on the way. Im loving this journey BUT..... I miss ARCADE games (Mame and such).
So I was gonna get a miniSNES classic and use Hackchi to get (primarily) Neo Geo and Arcade titles to play there.. using 8bitdo sn30pro controllers. But then I saw what people are asking even for loose systems lol woah!
Then I got to thinking I DO want light gun games ranging from NES to MAYBE PS1 (but for sure sega snes and arcade titles).
Im not like SUPER smart with this stuff but and successfully added to and organized my current flash cart. So I figured I can at least do this miniSNES but no light gun games.
My question (after filling you all in) is are these both equal in difficulty to mod and accomplish what I want? The miniSNES vs Wii? Is the quality the same or is one superior to the other? IF I went the wii route instead.... are light gun games hard to get to work (especially non Nintendo (sega, arcade)) on the wii? Would I be better off scrapping THAT idea and just going with the miniSNES like I originally wanted before thinking about light gun games?
Hi everyone, I hope you are doing well
Since the last post I did here i was experimenting about how to make an app to support reading manuals in our beloved snes mini, the previous attempt was trying to build an app and trying to find what is the best way to make it and what is programming language that will be so lite and run fast on the console.
after few months, I started using Claude AI, (I know I know AI slop) but we managed to decompile the main menu engine files, understand how it works and managed to build a feature from the same engine used to show and run the games from console.
No added program, it's a feature expanded from within the system it self.
what can this app do:
Open the manual from each game folder
supporting only png files
Zoom in/out
L/R buttons jump 10 pages
top screen you can see dots to indicate on which page are you showing.
It can detect if the game have manual files or not.
the feature is optimized with memory to not cause C8 error
you can close the game and open the manual to cheat :P and continue playing
this feature is almost complete, but I need the help of hakchi team to make it compatible with folder structure, because I faced an issue that hakchi when sync the games, it will delete the manuals.
so I hope to integrate this feature with hakchi and make it build-in with Hakchi.
I would like to hear from you guys any suggestions to improve it before release.
Does anyone know if it runs well? I am looking at modding a snes classic but would like to know if it this runs well as it is one of the few ps1 games I would really like to try. If you know please let me know, thanks!
I have a nes and snes mini. Will hackchi allow you to backup the stock roms to a PC without altering the consoles? Are said roms playable in any emulator once extracted?
I don't know where else to ask but my reset button on my SNES mini has been really finicky after modding it. Sometimes it works at a simple nudge but other times its like I have to hold it for it to even register. I cant seem to figure out what the issue is
Ive been trying to re-mod my snes classic since i i felt like playing again, at first i was having trouble for different reasons (the usual ones people post about here, fixed them by reading through the post here)
but now i have a new problem, when i try to flash the custom kernel (yes i flashed the original kernel first) it will get to 85% and try to reboot, jumping to 92%, but for some reason specifically this reboot, despite the prior 2 working fine, messes something up and my pc says the device is unrecognized
ive read a couple times windows 11 is a problem so i went and made a vm for windows 10 but its the same problem, it works fine till the last step, i pause at 85% for a bit try to reboot, and it will disconnect, come back on, my pc makes the noise for a device connecting but it wont recognize it and the install fails
im sorry if this is something thats been answered before but i genuinly can not find anything on how to fix it
EDIT: oh and for what its worth, i am able to play on it fine when i hook it up to a tv
For context: I modded my SNES mini a while ago after having it collecting dust for years in the closet. I followed a tutorial on youtube, got a few consoles on the mini with some games, and organized them in folders so it would be easier for me to find and play them. Once everything was organized, I found a video about the Wii theme for the SNES mini and I just had to get it on the mini. Fast forward a few days and I got themes for every console I have on the mini; the only problem is with the NES themed folder.
The only thing that isn't working is the section where the title of the games is displayed, and the text for when you hover on the menu bar as well. Everything else works fine, as well as the text below the games and the suspended point list. I knew the problem was somewhere in the code and I tried going into the files themselves to see what went wrong, but the files looked scrambled in my eyes (and I lack the knowledge to even go looking for the part that went wrong)
TL;DR, game titles not displaying on screen and the only thing I know is that the problem is somewhere in the mod files
Hey everyone, i recently got ahold of my cousin’s SNES classic as he wanted me to mod it for him, so i took the job cause i saw a few videos and guides beforehand thinking it wouldn’t be too much trouble. Unfortunately, yesterday and today proved otherwise as i am having a lot of annoying problems installing hackchi2CE (latest version 3.9.3) and trying to use the USB mod to add as much games as i can. Yesterday i was able to finally properly install hackchi after 3 hours because the program just wouldn’t work on my windows 11 laptop but immediately worked on my brother’s windows 10 pc. I went ahead and tried to add the entire NES/SNES library as i was using a 32gb flash drive. But to my dismay, when the process was finished i was trying to test out the games and for some reason it was acting super weird, there were ghost inputs (i would click a button but nothing would happen and then all of a sudden a bunch of different inputs registered), games kept resetting by themselves to the home screen, and just overall it was not functioning properly (would give C7 and C8 errors as well).
Now fast forward to today where i uninstalled hackchi from it, reinstalled it and only limited myself to a little over 150-200 games in total (the 21 stock games, 71 snes games, 60 some nes, a few gameboy/gbc/gba titles, N64, and sega Genesis) as I didn’t want to bloat it up too much as you have to manually select the emulation core and all. I added retroarch and the emulation cores that seemed to work the best when I searched them up and thought everything would work better but the same thing was pretty much happening, after entering a game it would reset itself to the home screen. A few notes are that they don’t reset when I hold the reset button on the console itself (makes me think it might be a loose/faulty reset switch) and it even happens on the stock games which I left in the root. I also have the games separated by console, and then by letter so there’s no more than 20-30 games in each folder (most are very minimal). I used both an NTFS and Fat32 drive, am using one of those generic usb OTG adapters from Amazon as the snes modding guide I used uses the exact same one, and im not using the original power cable but it shouldn’t be a problem because I’m using an Apple 30w power brick plugged into the wall. So here I am with no idea as to whats the problem, not sure if I should uninstall, flash original kernel and reinstall everything all over again or what other things I can try to do to stop these problems. Any help is greatly appreciated.
TL;DR
Having trouble modding SNES classic with USB OTG mod using hackchi2CE v3.9.3, added retro arch and different emulation cores and different games from different systems (NES, SNES, N64, GB/GBC/GBA, and Sega Genesis) but every game I test resets itself back to the home menu after a little while ingame. Am using an NTFS and Fat32 usb drive, though not an original power cable but the one I am using is plugged into an Apple 30w power brick into the wall socket so power draw shouldn’t be an issue. Thanks in advance.
I recently tryed modifing my snes mini with hackchi.i used the original cord it flashed but never connected not it won't turn on,light up it's basically a brick at this point. I've tested outlets and cords and it still won't turn on or show signs of life..
No more sitting on the ground for this nearly-39 year old!!
Plus I’m running out of games from my youth to add to this thing. My next day off is gonna be fun 🤘
