Atgames sega flashback 2018 edition is out in the wild.

[the_randomizer]

So.....can the Family Dollar crapsac Genesis get hacked? Was going to buy the everdrive, but if I don't have to, I won't.

Personally, I would try to save up for a Mega SG. Sure, they are a bit pricey, but at least the hardware emulation is top notch, top that off with a Mega Everdrive, you'll never have to change carts again.

You probably wanna find audio from actual hardware, not emulators, and compare yourself. I don’t have the flashback console so I wouldn’t be able to compare myself.

This one is from a Model 2 ym3438



There’s audio files you can find online for the model 2 ym2612 version. I don’t think I can link the downloads here though.

I think that the emulator Genesis Plus GX sounds might close to the model two, with the low-pass filter and all that. I should do a comparison.

 

[H1B1Esquire]

Personally, I would try to save up for a Mega SG

Thinking about it, but if I'm spending over $50.00, it's just a reason to get Switch, part 2. Sad times

 

[the_randomizer]

Thinking about it, but if I'm spending over $50.00, it's just a reason to get Switch, part 2. Sad times

I know, but you're also getting top quality FPGA based hardware emulation *shrug*

 

[FateForWindows]

I know, but you're also getting top quality FPGA based hardware emulation *shrug*

Meh, the emulation's good but they didn't emulate the lowpass filter and I don't have any examples with unflitered audio to compare the YM2612 emulation with.

 

[kuwanger]

It's great to hear that people care enough to concern themselves about the little things, but Genesis emulators have a ways to go. I'd rather see the emulators improve than take the FPGA route. At least, I'd rather until the FPGA route is well established and the price seems more reasonable. Processing power is now to the point you can buy $10 emulator systems able to do consistent 60 fps in snes/genesis games. If their accuracy can be improved enough, it's just hard for me to justify an FPGA solution.

Maybe if the ao486 core improves and we have some neat sound card support (not sure what the core supports) to play most/all old DOS demos. There's a lot of those and an area where the emulators fail horribly. As does modern hardware.

 

[the_randomizer]

Meh, the emulation's good but they didn't emulate the lowpass filter and I don't have any examples with unflitered audio to compare the YM2612 emulation with.

That is an odd choice, not sure why it's not emulated.

It's great to hear that people care enough to concern themselves about the little things, but Genesis emulators have a ways to go. I'd rather see the emulators improve than take the FPGA route. At least, I'd rather until the FPGA route is well established and the price seems more reasonable. Processing power is now to the point you can buy $10 emulator systems able to do consistent 60 fps in snes/genesis games. If their accuracy can be improved enough, it's just hard for me to justify an FPGA solution.

Maybe if the ao486 core improves and we have some neat sound card support (not sure what the core supports) to play most/all old DOS demos. There's a lot of those and an area where the emulators fail horribly. As does modern hardware.

Blast 'Em is nice but the requirements are high.

 

[kuwanger]

Blast 'Em is nice but the requirements are high.

What are the exact system requirements? I presume it's the same as bsnes not running well on a Raspberry Pi? I bring that up because, an snes comparison video does a really good job of showing how emulator accuracy improvements need not require a massive rise in system requirements. Even if you limit yourself to retroarch snes9x2010 and suffer known accuracy issues to run on a cheap SBC, you're very close to real hardware from a casual gamer perspective*.

I'm not dissing Blast 'Em. I just mean I imagine Genesis Plus GX could be modified to get Titan Overdrive 2 working properly enough and still run on an SBC. It's good that Blast 'Em and real hardware (and FPGAs) are around to constantly double check the work of others to improve the situation. Long-term, it'd be great if Snes9x and Genesis Plus GX become good enough that even speedrunners can't differentiate them from real hardware.

* Meaning that it's 60fps, without graphical glitches (at least not outside whatever is endemic to the hardware/software), and only a speedrunner/taser is likely to notice.

 

[the_randomizer]

What are the exact system requirements? I presume it's the same as bsnes not running well on a Raspberry Pi? I bring that up because, an snes comparison video does a really good job of showing how emulator accuracy improvements need not require a massive rise in system requirements. Even if you limit yourself to retroarch snes9x2010 and suffer known accuracy issues to run on a cheap SBC, you're very close to real hardware from a casual gamer perspective*.

I'm not dissing Blast 'Em. I just mean I imagine Genesis Plus GX could be modified to get Titan Overdrive 2 working properly enough and still run on an SBC. It's good that Blast 'Em and real hardware (and FPGAs) are around to constantly double check the work of others to improve the situation. Long-term, it'd be great if Snes9x and Genesis Plus GX become good enough that even speedrunners can't differentiate them from real hardware.

* Meaning that it's 60fps, without graphical glitches (at least not outside whatever is endemic to the hardware/software), and only a speedrunner/taser is likely to notice.

I'm picky, but I think Titan Overdrive 2 would be better if it was encoded in NTSC and not PAL (20% faster frame rate). That said, Genesis Plus GX's state is unknown, not sure how or if it's being improved on, but as far as Blast Em goes, it hasn't been updated in over a year. I tried Exodus, but I can't seem to get a smooth framerate on that either. Like, it runs at 60 fps, but there seems to be a lot of dropped frames.

 

[kuwanger]

I'm picky, ...

I can totally understand that. For me? On Genesis I'm not very picky at all (stable frame rate and for the audio to not sound off). SNES, so so (I'd like Star Fox to play in the ballpark of accurate speed since I've played it a lot on real hardware). For DOS, very picky (mostly I'd just like to see DOS emulation to improve* beyond support for games).

That said, Genesis Plus GX's state is unknown, not sure how or if it's being improved on,

It looks like it's being improved, but it looks more like quality of life/port changes not trying to improve the accuracy.

but as far as Blast Em goes, it hasn't been updated in over a year. I tried Exodus, but I can't seem to get a smooth framerate on that either. Like, it runs at 60 fps, but there seems to be a lot of dropped frames.

Yea, frame rate stutter really bothers me now days when 20 years ago I would have been tolerant of it. It's why I don't play games through Dolphin even though the increased resolution is really nice.

* Not complaining about PCem but it's the same issue you mention about Blast Em with high system requirements. I'm glad PCem exists, but I hope the recent evidence that DOSBox might be getting more release might mean they'll start pulling in the various forks, some of which tried to work on getting the accuracy improved in the demo scene.

 

[rrifonas]

not that i particularly mind but a couple of things:

1)the .emu series is technically not free software (i am not stopping you but fyi, it would need to either be compiled by the user or acquired by them for the ones that are not available at explusalphas website unless you do not care of legal ramifications.)

2) i appreciate the enthusiasm but aside from gathering an apk list is there any scripts or code added by you, i am curious and dont mean this in any negative way.

3)I wanted to keep this thread for RND for the 2018 model (although odds look bleak) wouldnt posting this in the 2017 version thread be more appropriate?

dont mean anything mean by it, it just feels out of place in this thread.

Thank you.

That's a shame .emu is not free and the redistribution rules are quite difficult to understand - it looks like you can redistribute even a recompiled version. If it was a free emulator, it would save the awful experience with the Genesis Flashback HD 2017. I've been playing with .emu for some time and I was able to recompile them using the Genesis Flashback HD 2017 keymap, and I also was able to modify the Atgames launcher to associate different file extensions with different emulators. The final outcome is that I could replace the original emulator with MD.Emu inside the original launcher/dashboard (even when running games from cartridge), and as a bonus I can launch games from other .emu emulators directly from the Atgames launcher, or even create a link in all-games.ini to start the emulator straight from the launcher (Really good feature when you don't want to edit all-games.ini for any single game you want to add). MicroNut99 helped me a lot testing these features and figuring out the differences between the obb and the non-obb version. We've been even able to start RetroArch (I compiled a custom version for the Flashback HD 2017) from the Atgames launcher and with both controllers working. Unfortunately the Arcade cores are not very stable for this hardware, but Genesis games run quite well.

Regarding the Genesis Flashback 2018, it looks like a quite solid plug-and-play machine. I've heard some eventual cracklings in the sound but it's much better than anything Atgames has offered before. I think this model may have some way to 'hack it' when the 'SD Card unlock' is released. I've opened the other 'firmware updates' and they are regular RockChip update files, with a parameters files (partition information) and a .img file with the actual data to be changed. My guess is that If we have the knowledge to create 'rockchip updates' - and having the partition parameters are crucial here -, we may be able to create scripts as 'updates' to dump the original partitions to learn how it works and if it can be hacked with homebrew or different cores.

 

[WD_GASTER2]

I actually am going nuts because there are several things that CAN be attempted but i am wondering how far i am willing to go over this device... :S

on a separate note: the Arcade flashback generations: A full nand has been dumped by me. requires soldering for bootloader mode but its possible. if i can open and repackage it, we will have homebrew for it (and possibly reenabling adb!) however lets see where this goes. on the genesis 2018 model, i get a corrupt dump with my tools so bleh!

 

[WD_GASTER2]

a little more info:

the nand is
https://www.digikey.com/product-detail/en/macronix/MX30LF2G18AC-TI/1092-1164-ND/4968347

it looks to be a 2gb 48 tsop.

 

[MicroNut99]

Maybe I made some progress today... idk... have you made it this far WD_Gaster?

 

[WD_GASTER2]

waaayyyyy past that. adb communication doesnt work. you booted to recovery mode. there is no adb if you noticed... however ....

IM IN THE NAND!

 

[MicroNut99]

waaayyyyy past that. adb communication doesnt work. you booted to recovery mode. there is no adb if you noticed... however ....

IM IN THE NAND!

Congrats and
How?

 

[WD_GASTER2]

there is a hidden bootloader mode. i will give more info a bit later. this literally just happened less than 10 minutes ago. *pray for me* I am going to change the sd loader value to 1. if this works and i can flash back(please dont brick on me....) i dont think a firmware fairy will be needed.

also @asper

you deserver credit for this. one of your notes on the 2017 edition came in handy!!!

 

[Jacobeian]

It's great to hear that people care enough to concern themselves about the little things, but Genesis emulators have a ways to go.

That's a little bit exaggerating though. That particular demo uses undocumented debug features of the Genesis GPU that were only recently discovered by the Titan demo coders and that are not used in any other commercial or homebrew games, so it hardly can be used to judge overall accuracy between emulators. It's just that Blastem and Picodrive emulators were updated shortly after that demo and technical infos about these extra features were released and Genesis Plus GX didn't.

That's a shame .emu is not free and the redistribution rules are quite difficult to understand - it looks like you can redistribute even a recompiled version. If it was a free emulator, it would save the awful experience with the Genesis Flashback HD 2017.

All .emu are licensed under GPL and therefore they are free to modify, distribute or install on other systems, providing you respect GPL licensing terms (i.e share your code modifications). They are all based on GPL emulators (MD.emu for example is just an old version of Genesis Plus GX emulator with added Sega Cd support copypasted from Picodrive apparently). The only thing that is not free is the .apk icons that are the property of R. Broglia (this means you can recompile your own version, distribute it for free or sell it on Google Play but you can not use the exact same icon). There is even a FREE (as in gratis) version of these emu on Google Play if you look enough for it.

 

[WD_GASTER2]

@asper i may need your help on this one. it requires your understanding of math with the nand.

please pm me if you can.


ok i will open the challenge to everyone.
the following are the offsets to the nand for the device:
it seems to be recognizing it as a 256mb device (which if they managed to fit it in there... impressive)

CMDLINE:console=ttyS2,115200 androidboot.selinux=disabled earlyprintk init=/init initrd=0x62000000,0x00800000 root=/dev/rknand_rootfs rw rootwait mtdparts=rk29xxnand:0x00000800@0x00000800(misc),0x00004000@0x00001000(recovery),0x00000800@0x00005000(boot),0x00000800@0x00005800(resource),0x00002800@0x00006000(kernel),0x00007000@0x00008800(rootfs),0x0001E000@0x0000F800(rom),0x00004000@0x0002D800(emulator),-@0x00031800(data)

the sector where the partition starts and then the block count. if you look at the data partition (the last one) the partition start is known. it doesnt know what the block count would be.

@asper did a write up on making sense of this here: https://www.mdfbrew.org/tutorials:backup_original_partitions (this is for last years model but still applies here) I made an arbitrary block count dump and managed to learn that its 132mb however I am not sure what the block count equivalent would be and I am also heading to bed as I have work to do tomorrow. so if anyone wants to tackle this challenge, be my guest if we get the right block count, in theory the sd file that needs to have the value set to 1 to enable cfw should do the trick.

 

[kuwanger]

That's a little bit exaggerating though. That particular demo uses undocumented debug features of the Genesis GPU that were only recently discovered by the Titan demo coders and that are not used in any other commercial or homebrew games,

That's a nice way of saying "Genesis emulators have a ways to go". The major point of demos is to do "impossible" things, and that often involves taking advantage of undocumented features of hardware. I hope the Genesis demo scene continues and perhaps finds even more undocumented features to really push the limits of the hardware.

so it hardly can be used to judge overall accuracy between emulators. It's just that Blastem and Picodrive emulators were updated shortly after that demo and technical infos about these extra features were released and Genesis Plus GX didn't.

I'm not dissing Genesis Plus GX. And the point is not "accuracy between emulators" but "accuracy between an emulator and hardware"; it just happens that Blastem is close enough to hardware to judge (although admittedly I always prefer such comparisons to include an actual hardware capture precisely because one can't be 100% sure of such things). The point of showing multiple emulators is to show which ones best match the hardware and to give a certain amount of impetuous for other emulators to be "more competitive"--it's all about hardware being the gold standard, though. It's nice to hear that Blastem and Picodrive were improved, but Picodrive too needs some work.

Anyways, the goal of at least some emulators is to be so accurate and "just work" so a curve ball like a new demo won't break badly (or at all). I totally understand if getting all extant games, demos, etc working is the goal, but the former produces a future proof emulator that can be quite amazing. It's hard to say how realistic such is for undocumented hardware. And like I was saying earlier, as far as Genesis goes I'm perfectly content using an emulator that works on extant games. If it's possible to support the undocumented features without much of a performance cost and someone wants to implement it for Genesis Plus GX (or fix up Picodrive a bit more), that's great.

Edit - And not even picking on emulators as the FPGA MiSTer also clearly has issues running the demo--there's at least 5 or 6 obvious graphical glitches and the audio just sounds off, even ignoring a possible different palette on why the MiSTer version seems much darker. Clearly you can't recreate what you don't realize exists (unless you're laying down identical masks and dumb luck reproduces identical undocumented instructions or the like).

 

[rrifonas]

@asper i may need your help on this one. it requires your understanding of math with the nand.

please pm me if you can.


ok i will open the challenge to everyone.
the following are the offsets to the nand for the device:
it seems to be recognizing it as a 256mb device (which if they managed to fit it in there... impressive)

CMDLINE:console=ttyS2,115200 androidboot.selinux=disabled earlyprintk init=/init initrd=0x62000000,0x00800000 root=/dev/rknand_rootfs rw rootwait mtdparts=rk29xxnand:0x00000800@0x00000800(misc),0x00004000@0x00001000(recovery),0x00000800@0x00005000(boot),0x00000800@0x00005800(resource),0x00002800@0x00006000(kernel),0x00007000@0x00008800(rootfs),0x0001E000@0x0000F800(rom),0x00004000@0x0002D800(emulator),-@0x00031800(data)

the sector where the partition starts and then the block count. if you look at the data partition (the last one) the partition start is known. it doesnt know what the block count would be.

@asper did a write up on making sense of this here: https://www.mdfbrew.org/tutorials:backup_original_partitions (this is for last years model but still applies here) I made an arbitrary block count dump and managed to learn that its 132mb however I am not sure what the block count equivalent would be and I am also heading to bed as I have work to do tomorrow. so if anyone wants to tackle this challenge, be my guest if we get the right block count, in theory the sd file that needs to have the value set to 1 to enable cfw should do the trick.

Hi WD_GASTER2,
Assuming that the NAND size is 2GB and using the steps from mdfbrew (End address for 2GB NAND is 400000 hex), the missing value (count) should be 0x003CE800.
If you are using Windows 10 you use Calculator in Programmer Mode and subtract 31800 from 400000. The result will be the block count for the data partition.

EDIT: I think I misread your messsage. Is the NAND size really 256MB? If it's 256MB, the missing count should be ‭0x0004E800.
256MB = 268,435,456 bytes / 512 (bytes/sector) = 524, 288 dec = 0x00080000 hex. 80000 - 31800 = 4E800.‬