eliofilho
-
Posts
50 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by eliofilho
-
-
On 1/7/2022 at 8:16 PM, sirlynxalot said:
Like many collectors, he eventually decided to lessen his collection and sold many pieces of it as I personally bought an fz1 and some games from him and at the time he mentioned he did not have many fz1s left to sell. To hazard a guess, he might have felt like he'd reached the end of the collection and then let most of it go without broadly announcing it.
I would love to reach him, could you please PM me with his email or anything like that? I want to interview it to Sidequest.pt magazine.
Thanks @Sirlynxalot!
-
Digging this post in memory of BITRATE that vanished from internet a long time ago to a galaxy far far away! Anybody knows about him?
-
On 4/2/2021 at 6:59 AM, Draxxon said:
Amazon.com: At Games Legends Flashback Boom!: Video Games
these are $38.90 (free shipping with Prime) right now on amazon.
And i should tell you all, these devices have been hacked WIDE OPEN recently and SOON a pack of content is going to be releasedthat will work on ANY Legends Flashback Unit. It soon wont matter WHICH VERSION you have. Get this while you can.
Waiting anxiously!
-
1
-
-
On 2/9/2021 at 10:56 PM, RobertDaleSmith said:
IT LIVES!! Over the weekend I was able to get @candle's SNES-to-3DO circuit design running and it works great for the most part. I have to say I much rather use a SNES controller on 3DO now that I have had a taste of it.
I have consolidated all my findings into a GitHub repo and created some issues if anyone else is interested in contributing: https://github.com/RobertDaleSmith/SNES23DO
AMAZING job Robert Dale!
Would you please try to use the same assembler but for SEGA GENESIS control to work with 3DO?
Thanks in advance
-
1
-
-
Yes, until now there is no update by FROM´s SOFTWARE to fix DS3 running in Xbox Series, like it did for PS4/PS5 users unlocking fps and improving drastically the experience.
Any news from insiders?
-
On 8/27/2020 at 1:27 PM, Atariboy said:
Not a firmware question, but it didn't seem worth making a thread just to ask this. Has anyone ever confirmed if the 8BitDo M30 2.4g controller works with the Legends Flashback (Specifically, the original 2018 version of the Legends Flashback)?
All Mega Drive/Genesis controllers I have worked with Legends. If 8bitdo works with original Mega Drive/Genesis 99% probability it will work with Legends!
-
On 6/22/2020 at 2:49 AM, Draxxon said:
Is anyone interested in a Sega SG-1000 pack with box art for the Legends FB2018 (50 Games) for use with the Custom Firmware?
Draxxon I am interested in mount a full set for FB2018, with all boxart for MAME2003, Mega Drive and more. I just dont know how to do it without compile a new FW or botthering rrifanas again! Can you help me?
Maybe some guide can be useful for others too. Thanks for all efforts (y)
-
On 2/15/2020 at 5:55 PM, Draxxon said:
This is the LFB2019 all-games.ini file.
I´m a LFB2018 owner Draxxon... where can I put this ini file above? In the SD root? Tks!
-
I solved the problem without mess up with our Legends console... now I have hdmi plus audio in TV and headphones! (y)
-
1
-
-
8 hours ago, Atariboy said:
What's it supposed to be for?
Well, it is supposed to use headphones or audio out to a HT... or to use in a screen with no speakers... Too many functions!
-
4 hours ago, Draxxon said:
for me, 32GB sd cards worked after I installed the latest firmware/CFW on the 2018 model. I use SanDisc SD cards. I don't even format them. I just open the package, load the roms on it, then plug and play.
I dunno whats wrong, done the same process with the old 16Gb model and worked like a charm.
-
Here the 32Gb SD card doesnt work with the console. 16Gb worked like a charm, 2.8.4, both fat32 formatted. Any hints?
-
Im thinking in to add a phone jack in front of the console... what do you think?
I marked red the spot.
-
1
-
-
21 hours ago, Draxxon said:
Anything labelled .bin will show up and be launched with Genplusgx (sega) core. SEGACD (with bios files)
On the 2018 with CFW you should be able to run Genesis/MegaDrive (.bin/.gen/.md), SegaCD/MegaCD (.bin/.cue+bios), Master System/Mark-III (.sms), gamegear (.gg), nes/famicom (.nes/.dat), snes/super famicom/sufamiturbo/stellaview (.fig), mame2003(.zim) and final burn alpha(.7z).
SD Card up to 32GB.
Pretty amazing resume, Draxxon! You and rmr_md do a amazing digital team for this 2018 arcade machine!
Thank you both for all efforts and patience with us
-
1
-
-
10 hours ago, ft55555 said:
Is there custom firmware for the Legends 2018 that allows MAME ROMs to work?
Yes, for 2018 (old version) there is a firmware to unlock the SD Card and run all MAME 2003 fullset roms.
-
1
-
-
On 12/7/2019 at 3:55 PM, rmr_md said:
@BD-ROSS, this update should fix your problem with the 2 games:
Legends Flashback (2019) Update 0.1.16 for users with issue with Super Star Wars 2 and 3
Let me know if it works. It's the same update from the site but I used the original file names for these 2 games in all-games.ini.
I would like to try this IMG file and to run it in Windows 10, please how can I do? Is there a specific emulator or program to open this img file? Thanks in advance.
-
On 10/3/2019 at 4:55 AM, rmr_md said:
I've been able to build a custom RetroArch for this device and it replaces the default emulator really well.
You really rocks, rmr_md! I believe a new optimized OS could give new life to this hardware, free it up from the closed cores it already have and add new emulators to it, am I wrong?
I am happy with MAME, Neo Geo, SEGA CD-Gen-GG-SMS and NES, but I can get happier with SNES, PS1/PS2, Wii, how far can we go?
Cheers
-
In Europe search for it in Amazon ES or DE, Media Markets, some FNACs...
(y)
-
On 10/14/2019 at 7:14 PM, rmr_md said:
I've played around 1 hour with my Legends Flashback after I changed the CPU speed to 1.3GHz and it did not overheat, so I don't think you will need to add a cooler.
The sound delay vanished with this overclock, rmr_md? There is a lot of games with +1s delay in sound, specially arcade...
?
-
1
-
-
On 10/1/2019 at 8:06 PM, rmr_md said:
No updates, except that I found how to access the device using UART - quite simple actually-, and I could get more information about it. The emulator uses SDL2 and runs over X11 (weird implementation), and I couldn't compile anything that worked correctly (RetroArch).
I have also found that the device is underclocked to 816MHz, while the CPU supports in theory up to 1.5GHz. I could increase the CPU speed to 1.2GHz and the GPU speed from 300MHz to 400MHz, but I didn't have any time to test stability, so no public release. While this would improve framerate and speed for some games, what you currently have is likely the limit for this device.
Did I told how amazing dev are you, rmr_md? Thank you for all your efforts.
If you achieve a stable overclock to cpu and gpu I planned to add a cooler or something to its chip!
By the way I saw this new "100+ games Legends Flashback", is it the same gadget we have but with upgrades or just a new firmware?
Regards
-
On 11/22/2017 at 12:31 AM, jkgamer said:
So I've had a few days to tinker with this new ATGames device and I must say it's been great fun. Not only can I confirm that it is running a version of Android 4.4.4, but I can also provide details on how to roll your own ROMs and add them to the device.
I should state that tinkering around inside one of these can be a bit risky. You could delete vital files and render your ATGames Genesis device a brick. I'm presenting this information for those of you who are more adventurous and/or have a bit of experience messing with the Android debugger. I am not responsible if you follow these instructions (or don't) and brick your system. You've been warned.
Getting Inside
The first thing we need to do is disassemble the unit and get access to the mini-USB connector inside. There are 7 screws that hold the case together, two are exposed, four are underneath the rubber feet, and one is under the label. Obviously, opening up the unit is going to void any warranty or chance to return it to the store. After unscrewing all 7 screws, carefully separate the top and bottom halves, not pulling too hard as there are hard wired connections that need to remain in place. After opening the unit in clam shell fashion, you should see the motherboard exposed with the mini-USB port. You will also notice a wire that appears to have become disconnected from being too rough on opening the case. Do not worry, that wire doesn't connect to anything other than the motherboard. It is the antenna for the wireless controllers. Before connecting up to your PC, be sure to unplug the power from the unit. When you plug the USB cable into your PC, it will power on without the AC adapter. It also will remain on as the on/off switch only applies to the AC adapter.
Connecting and Exploring
After you've connected the unit to your PC via the USB cable, your PC should detect that an "ADB" device has been connected, but most likely won't contain the proper driver for it. One clue as to the driver is that it comes up and starts searching for an "rk3036" driver. This suggests that the ARM processor inside the unit is from RockChip, even though the CPU chip itself is silk screened with MonkeyKing 3.6. After scouring the interwebs and numerous attempts and storing generic USB ADB drivers, I found this RockChip repository on github (https://github.com/rockchip-linux/rkbin/tree/master/tools/DriverAssitant_v4.5). These are the correct drivers, although I only got them working after starting over with a clean system and installing them fresh. It seems previous attempts and installing the generic drivers somehow messed up my system so that it would no longer accept the proper drivers. I also installed Google's Android Studio which can be downloaded at (https://developer.android.com/studio/index.html). This is necessary so that you can run the Android Debugger and explore the contents of our new toy. After getting the drivers installed and Android Studio up and running, you will need Java too, I was able to pull up a DOS command prompt and type "adb devices". Sure enough, I was now able to see that the device was present and typing "adb shell" had me sitting at an Android prompt where I could start exploring its file system.
Where the ROMs are
Browsing through the various Android/Linux type files, I couldn't seem to find any ROM files, however there was a very large file named "com.atgames.menu.hal.obb" about 91MB in size. A little more research and I was able to discern that this was in fact a sort of disk image file that could be mounted under Android. This file is actually located in two places, "/system/preinstall/com.atgames.menu.hal.obb" and "/sdcard/Android/obb/com.atgames.menu.hal/com.atgames.menu.hal.obb". The first appears to be in case you need to recover your original version, which I did have to do at one point. The second is the one that we will actually pull to our PC and modify before building it back up and pushing it on to the device with new ROMs. The OBB file is generated/dumped via a batch file that comes with the Android SDK. However, my initial attempts to dump the contents of the OBB file would fail with a java exception about 75% of the way through. -sigh-. So I pulled up the file with a hex viewer and discovered that it appeared to be a FAT32 disk image. I already own a copy of "WinImage" (http://www.winimage.com/download.htm), so I decided to see if that would open the file. Sure enough, it worked. I was able to use WinImage to extract the entire contents to a folder on my PC. Among the files in that folder were other folders containing the box art PNGs, gzipped cartridge rom images, and a configuration file that I will detail later.
Getting the ROM images onto your PC
In order to extract the contents of the OBB file, we first have to get the file onto our PC. You can do this by bringing up a DOS command prompt, changing to the directory location that you wish to copy the OBB file to and executing the following command.
adb pull /sdcard/Android/obb/com.atgames.menu.hal/com.atgames.menu.hal.obb
Once it has finished copying and the prompt returns control back to you, you can then open up WinImage and open the file there. You may have to set the "Files of type:" to "All files (*.*) in order to browse for the .obb file. After opening the file, right click on the root folder in the left pane and select "Extract". Choose your storage path and make sure you've elected to "Extract with pathname". This gives you the entire contents of the obb folder which we can use later to create a new .obb file to upload to the Sega Genesis HD (2017). Looking through the extracted files you will see a Genesis folder, a Gg folder, and a Sms folder. This is where the ROM cartridge binaries are stored along with their title box art PNGs. The ROM binaries are all compressed with gzip. I used Cygwin to compress and decompress the ROM binaries and compared them to my backup archives. There may be other tools out there to gzip compress the binaries, but I'm just informing you of what worked for me. The PNGs appear to have all been created with Adobe Photoshop or Photoshop Elements. The dimensions of the box art files is 214 x 300 pixels WITHOUT an ICC Profile in the image. (Adobe Photoshop Elements 18 has an option when saving a PNG (Color: [ ] ICC Profile: sRGB IEC61966-2.1) which I had to uncheck in order for the PNGs to work with the unit.
Adding Your Own ROM Binaries
Once you've extracted the contents of the OBB file, you can start copying over gzipped ROM binaries of your own. My suggestion would be to start with a single ROM binary. If you do not include a box art PNG image with the same main filename (i.e. mygame.bin.gz + mygame.bin.png) it should just use the unkown_game.png. If you do decide to add your own box art and it doesn't like the particular PNG format that you saved it as, you will most likely be greeted with a continuously "Loading..." screen instead of a cartridge selection menu. If that happens see the recovery section below. Once you have added your binaries and PNG artwork, we have to edit the all-games.ini file located in the atgames folder of our extracted OBB files.
The alt-games.ini File
This part rivals the preparing of the box art as to being a pain in the arse. Every game cartridge must have an entry in this file in order for it to be recognized by the system. If you are only adding one or two binaries, not a big deal, adding 57 binaries, excruciating. The files is a plain generic text file that contains many entries in the following format.
[Game Title]
File=atgames/Genesis/GameTitle.bin.gz
Platform=Genesis
Genre=Sega
Description=The best Genesis game ever.
Dpad=Directional movement
Start=Start, pause
A=Action
B=Backup
C=No function
X=No function
Y=No function
Z=No function
The above sample entry should be mostly self explanatory. It starts with the game's title inside the square brackets, followed by the path in the OBB file structure to the binary itself. In this example, the game is being added to the Genesis folder. Just an FYI, I haven't seen anything that restricts Genesis, Master System, or Game Gear files to a specific folder. In fact, the Sms folder contains both Sega Master System titles and Game Gear titles. I even thought about cleaning it up, but I left it out. The Genre determines whether it shows up in the Sega Games (Genre=Sega) section, the Mortal Kombat (Genre=mk) section or the Bonus Games (Genre=Arcade) section. The rest of the fields are just documenting the title. As you scroll through the all-games.ini you may notice that there are entries that are preceded with hash tags. The hash tag simply comments out that line in the file and the menu system ignores those lines.
Rebuilding the OBB file and pushing it back to the Sega Genesis HD (2017)
Once we've got all our binaries added, all of our box art added, and we've finished adding the all-games.ini entries for each title, we are ready to rebuild the OBB file. This is where the Android SDK jobb batch file comes in. Open up a DOS command prompt and change to your Android SDK tools bin directory. Mine is C:\Android\SDK\tools\bin, yours will probably be something else since I changed the default location when installing it. Android doesn't like spaces in file paths, so I usually won't install to the "Program Files (x86)" folder. If you have trouble executing these commands, you may need to reinstall your Android SDK into a path free of spaces. Once you are at the correct directory, you should see a jobb.bat file there. You can rebuild the .obb file by executing the following command at the prompt.
jobb -d /OBBImageFolder -pn com.atgames.menu.hal -pv 1 -o com.atgames.menu.hal.newobb
OBBImageFolder should be the path where you extracted the original OBB image files and added your customizations. Again, avoid placing the folder in a path requiring spaces, if you do have spaces, try enclosing only the path in quotation marks. The OBBImagFolder should contain the atgames folder only. Inside the atgames folder is where your Genesis, Gg, and Sms folders should be located. If you were to open the .newobb file in WinImage you should see atgames in the root folder of the image. This is important, if you get this wrong, you will probably end up with the cycling "Loading..." screen.
Now that we have rebuilt the .obb file (com.atgames.menu.hal.newobb), it's time to push it back onto the Sega Genesis HD (2017). Execute the following command at the DOS prompt from the same folder where your new obb file exists.
adb push com.atgames.menu.hal.newobb /sdcard/Android/obb/com.atgames.menu.hal/
(Be sure to include the forward slash at the end of that command, you could also use /sdcard/Android/obb/com.atgames.menu.hal/com.atgames.menu.hal.newobb as the destination parameter, but we've done enough typing, let's save a few keystrokes.)
Now you've got your new ROMs on the system, but they still can't be accessed yet. For that you need to follow the next section's steps.
Swapping OBB files via ADB Shell
Now we need to go in and remove the old obb file and rename the new obb file to take its place. However, since the com.atgames.menu.hal.apk application is always running, you can't simply push your new file up to the system with the original file name. Doing so, almost always results in a corrupted com.atgames.menu.hal.obb file result. This is because the menu application is constantly accessing that file. The best way I have found to get around this is to start a game from the menu (it doesn't matter which one) and then launch the Android debugger with the command
adb shell
Once your in the debugger and the game is running, you type the following at the root@rk3036: prompt (Android prompt) so that we can find out which process id to kill to stop the menu app.
ps
This should give you a list of all processes that are currently running on the unit. Look for the com.atgames.menu.hal entry on the right side of the list and it's corresponding process ID number which is in the second column from the left. For example: My current listing shows that com.atgames.menu.hal process ID is 588. This can and will most likely change between sessions, but for now, we just want to kill it so we can swap out the obb files. Type the command
kill 588 (or whatever your process ID was)
Now we need to change to the folder that contains our OBB files. Use the following command
cd /sdcard/Android/obb/com.atgames.menu.hal
follwed by:
ls -al
You should see both the original com.atgames.menu.hal.obb and our newly uploaded com.atgames.menu.hal.newobb files. We need to remove the original now that the menu is no longer running. You can do this with the following command:
rm com.atgames.menu.hal.obb
Just to make sure it's gone, because sometimes parts of it remain or are recopied by the OS, do another ls -al and see if it is really gone. If not repeat the rm com.atgames.menu.hal.obb. I've never had to do this more than twice. It may have something to do with timing and one of the other processes tries to put it back, I'm not sure. But it needs to be gone before we rename our new obb file with the following command:
mv com.atgames.menu.hal.newobb com.atgames.menu.hal.obb
Perform another directory (ls -al) to make sure you got the name right. You might also want to verify that the size of the file matches the size of the file on the windows side.
Voila!
It's now time to exit out of the shell and reboot the unit. Go ahead and type exit to get out of the shell then issue the following command at the DOS prompt:
adb reboot
If everything went just right, you should now be presented with the game selection screens including your added binaries.
LOST.DIR
Because the original obb file appears to get recopied/reconstructed by the OS, you may want to check the /sdcard/LOST.DIR folder after rebooting a fresh change. This is because the system will run a check disk when it starts up and any bad files/chunks that are found will be placed in here. It is safe to use the adb shell to "rm *" all of those files. I need to see if there is a way to truly suspend the system so that it doesn't keep trying to replace the original file. Once you've renamed the new file the same as the original, it won't overwrite it, but if it doesn't see the original filename in that folder, it thinks something is wrong and it needs to restore it.
RECOVERY
If you get locked into a cycling "Loading..." screen, you should still be able to connect up to the unit via the adb shell. While I haven't seen a situation where I have not been able to connect via the debugger, be aware that if you go beyond messing with the obb file, I can't make any guarantees that you won't brick your system. The Android Debugger runs software on both sides in order to work (PC and Android) and if you kill a required file or application on the Android side, there's no telling if you can reset it to come back. There is a button on the motherboard to reflash an entire firmware image, but I haven't been able to dump an original or full firmware image to restore from and I doubt ATGames will provide us with one. That being said, if you just managed to screw up the obb file, it's rather simple to get back to working condition. Remember at the beginning I mentioned that there were two locations where the original obb file was stored? Well we just need to copy that obb file over are failed one. The only problem this time is that we won't be able to kill the "com.atgames.menu.hal" process, because it will just restart itself since we aren't running one of the emulators. So to restore back to working condition the following command from inside the adb shell should work:
cp /system/preinstall/com.atgames.menu.hal.obb /sdcard/Android/obb/com.atgames.menu.hal/com.atgames.menu.hal.obb
That should get you up and running again. I would also clean out the LOST.DIR directory as mentioned above after rebooting before attempting again. If you fail to do so, you will find that it won't take long to run out of flash memory space. BTW - Someone earlier in this forum stated that there are 2GBs of flash memory available for ROM binaries. Well the fact is that while there is 2GB of flash memory in the unit, only 949.0MB is partitioned for the /sdcard folder, so we have just under 1 GB for binaries and box art.
Summary
I hope this helps anyone wanting to hack into their new ATGames Sega Genesis HD (2017) units. And I hope that no one ends up bricking their system. I've tried to cover as much detail as possible, if you find something missing, feel free to let me know. And if you are a more experienced Android developer and have some pointers on how to avoid the issue with the LOST.DIR, I would welcome that feedback as well. BTW - I wouldn't try replacing the /system/preinstall/com.atgames.menu.hal.obb file with your new one as you may never be able to restore if you do. It's not that easy to replace it anyway as the /system folder is mounted as ro shortly after booting the system. There are ways to remount that as rw, but I see no real reason to do that as I haven't even come close to filling this thing up yet. Also, if you still can't get your system running after restoring the original obb file, you could try executing the shell script located in the /system/preinstall folder (./setup.sh from within the adb shell and that directory.) BTW - Looking at the setup.sh script, it appears that the Atari Flashback 8 Gold uses the same chipset/script for it's install, but the FCC images of it's motherboard does not show a USB connector, only some solder points to presumably add one. Good luck and have fun!
Amazing job! Do you know if this tutorial works with AT LEGENDS ARCADE FLASHBACK? I am wonder if is there any way to make it faster, maybe some overclock on these chips...
Cheers
-
1
-
-
Hello retrogamers! So, is there any hack update, firmware change or new modification to make in our little and slow arcade beast?
Regards to all,
-
And so there is a "Wiinesis" or "GeneWii" version of ATGames Genesis and nobody noted?
-
2
-
-
This issue only happens with the custom firmware and it's fixed if delete retroplayer.ini from your SD Card:
- option to save settings in menus to a cfg file and avoid to reconfigure stuff after each boot (example: overdrive)No my friend, my two SD Cards have not the ini file but the system still do not save options. I change music, overdrive, themes, etc. When I power off then power on the options are reset.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
PlusROM High Score Club
in Atari 2600
Posted
Sent you PM, man!