philyso

The one with 315-5433 is either MD1 VA6, VA6.5 or VA6.8 The one with 315-5487-01 is a MD1 VA7 It would be interesting to compare the ones which don't boot the game with the first one as they are likely all MD1 VA6.

My wishlist Soleil/Crusader of Centy Shining Force II Aladdin Quackshot Flashback Alisia Dragoon Rocket Knight Adventures James Pond II: Codename Robocod Sonic III Sonic & Knuckles (with lock-on feature)

According to that (old) libretro twitter, they are not really using retroarch but only licensed the libretro API portion that is used by Genesis Plus GX (the emulator core) to interact with retroarch (the frontend). They apparently developed their own libretro frontend and surely already had their own GUI (is there any screen of the new user interface or is it identical to 2017 model?) https://twitter.com/libretro/status/1040341977009717248 My guess is that AT Games 2018 model was planned long before Sega MD Mini announcement but then, when Sega discovered overall awful public reaction after AT games incidentally implied they were involved in upcoming Sega MD Mini release, they decided to manage development themselves and pick local developers for the software instead of reusing ATGames software. I think it was always planned to be two different products, one for Japan market, the other for western market, with maybe some licensing clauses to avoid competition between the two products. This situation change would also explain why Sega also announced a western release for MD Mini was now planned since they aren't bound to AT Games software anymore. Most likely, they did not change the CPU specs and it struggles running the more accurate sound emulation full-speed, which is quite a shame if true :-/

Sega CD BIOS is actually much more than just a bootloader. Among other things, it provides run-time services to software for disc access (TOC reading, play, seek, etc), CDDA volume control (fade-in/out) and backup RAM management (format, add, remove, etc) so it's actually extensively used by games while running. There is no BIOS replacement existing so far (contrary to PS1 I think) so it's probably not that simple to replace all these functions properly (i.e without breaking games), although high-level emulation (either with a software emulator or with a FPGA connected to an off-the-shell CD driveor SD card adapter) might be possible I would not be so much optimistic and the fact no Sega CD hardware implementation in FPGA exist so far should again be an indication that it's not that as 'easy' as you think it is. Sega CD hardware is actually quite complicated, you can have a look at available service manuals. Even discounting the various CD board chips (DSP, RF Amplifier, Mechanism controller, etc) used to control the CD drive (which could likely be simulated by an off-the-shell CD drive but would still need to be properly interfaced with the rest of 'emulated' Sega-CD hardware), there is an additional MC68000 CPU, many RAM chips, a PCM chip for extra stereo channels, configurable audio DACs, a CD-ROM data decoder (also connected to CD DSP) which is able to generate interrupts and handle DMA transfers, a custom 4-bit processor which handles CD commands from the BIOS and drives the CD board and last but not least a big custom ASIC that handles interfaces with Genesis side, access to Sega CD hardware from software, subcode processing, etc... but also has additional graphics processing capabilities (scaling & rotation). Looking at existing Sega CD emulators could probably help a bit but they are not very accurate in regard to hardware timings (compared to Genesis emulation) and hardware reverse-engineering seems to be still quite in early days (for example, service manuals only surfaced last year I think), which would make developing an FPGA implementation quite a serious task in my opinion (much more than well-known and deeply studied 8-bit/16-bit systems) No, there is no CD-ROM emulator (or ISO loader) released so far or even in the work for Sega-CD hardware yet, unfortunately.

Damn, off course I forgot that Mega SG won't have any analog video out so 32x hardware won't be able to mix and display Megadrive graphics. EDIT: also forgot video connection between Megadrive and 32x use a proprietary cable made specifically for MD1 or MD2 A/V port

Well, I misread it would support 32x add-on then, my bad. But that statement is a bit contradictory then, since all the 32x add-on needs is that signals it use on cartridge connector work as expected. If they indeed all were implemented in Mega NT as in a real Megadrive, then 32x games would automatically be supported through the 32x adapter out of the box, so I guess my question remain valid.

@Kevtris: Awesome work as usual. Native support for 32x and CD addons is great also. Can you confirm if Mega SG correctly handles ALL the signals available on cartridge port, not just the ones traditionally used by most commercial games and 32x add-on? Upcoming Paprium cartridge, for example, has an audio DSP on-board and sends additional audio stream to the console through cartridge port dedicated pins. Original system just mix external audio with FM/PSG stream. Will it be supported? Also, will your VDP core emulates those undocumented features that were discovered by Titan demo team and properly supports their Overdrive 2 demo? It apparently uses some debug features that no commercial games use.

Oh, didn't noticed there was already a thread discussing this. Thanks for the notice!

Piko Interactive?

I found this through a link on resetera (https://www.resetera.com/threads/mini-genesis-no-longer-being-made-by-atgames-using-proven-domestic-dev.69462/page-3): https://fccid.io/2AMTQ3680SEGA18/Users-Manual/User-manual-3952641 It looks like the User Manual of the upcoming Flashback MD 2018. The parent directory has also some interesting pictures showing the internal/external of the console as well as the menu interface (under test setup photos): https://fccid.io/2AMTQ3680SEGA18 This can be compared to the existing model which is also listed here: https://fccid.io/2AMTQ3680SEGA Apart from the addition of SD slot, the interesting thing is that the 2018 manual has copyright notices indicating it is using Genesis Plus GX emulation code (under an agreement with the original authors) and libretro (confirmed on libretro twitter), which the 2017 manual hadn't so it appears they switched to a more accurate emulation model (more accurate also means slower though so I hope they also kinda bumped the spec of the embedded SoC) The 2018 game list looks identical to the existing model which is a little bit disappointing but not really surprising (I guess AtGames only has access to a limited subset of Sega catalog and has to pay each time they want to license another game). This really makes me wonder what Sega is up to with the Mega Drive Mini: from a different perspective, their latest twitt could simply mean that they have Japanese software devs working on a slightly different menu interface for AtGames Flashback MD (more adapted to Japanese market) or optimizing licensed emulation software. Off course, the most logical would be that they simply decided to make their own product and sell it worldwide, making it a direct concurrent of AtGames Flashback MD. Pure speculation, obviously... but some stuff Bill recently wrote here could be interpreted this way

This kinda explains why 'hybrid emulation' has been abandonned. Again, not so surprising, that idea was flawed from the start. Again, this sounds like typical manager pressuring his employees to meet some unrealistic promised goal and deliberately not wanting to care about technical details and difficulties. It seems Mednafen dev was also involved (they mentionned it in one of their twit when saturn support was initially announced and it's a multi-console emulator, so....), can you confirm? Now the real question that comes to my mind would be what is the current state of the product and how many of the emulated systems that are advertised for launch (in 6 months!) are currently operational? Seems to me the preorder campaign was launched in urge because they needed funds for development, but the system is likely far from being ready yet. Thanks anyway, this was quite necessary in my opinion to clear some things up.

So, reading their broken site FAQ that was posted here and comments on their Facebook page, it seems they finally realized that accessing the cartridge in real-time through software emulation was unpractical, for all the reasons we already explained in this thread. Well, it's about time I guess (I find suspicious they waited until preorder launch to announce it as they likely knew it for quite some time). For the record, here is Byuu's recent comment about this, which pretty much sum up what I already tried to explain (although not mentionned, it is clearly about the Polymega): https://mobile.twitter.com/byuu_san/status/1037367119028125696 And now, people who wanted to buy it are pissed that it is just another emulation box and not the super-accurate & lag-free modern console clone they though it would be because of how magic 'hybrid emulation' sounded. Great job :-/ Another thing that baffles me is the prize of that thing with modules, it is quite expensive, especially considering the base unit already fully emulates PC Engine and Genesis (since it IS required for PCE-CD and Sega-CD emulation to work in the first place), so you are basically paying expensive modules that only serve as ROM dumpers and eventually passthrough to original controllers (if that is still planned of course and not canned with the rest of 'hybrid emulation').

MD.emu is based on an (old) version of Genesis Plus GX when it was still licensed under GPL so it's 100% free, you have every rights to modify it, recompile it and distribute it (under GPL terms). The fact MD.emu developer choosed to sell his Android port on Google Play should NOT prevent you to share your own modified version (actually, there is a free version available on Google Play and you can even find a free .apk on MD.emu developer website)

Most emulators use memory handlers for CPU emulation (when the decoded instruction performs a bus access, the emulator calls a function which decodes the memory address and simulates the read/write effect depending on the accessed device) so it's not necessarely hard to patch an existing emulator so that any read/write access to the cartridge area calls a specific function that instead communicates with a FPGA through some registers to issue a read or write command on the cartridge interface. From what I understand about 'hybrid emulation', that's pretty much the ONLY thing the FPGA is emulating, that is the control of cartridge interface signals like the original hardware would do to handle read and writes. No, the biggest problem is that existing emulators are not designed to stall while waiting for any cartridge bus access to complete (which would kill the emulator performance and would certainly make it unplayable, even on fastest processors) or alternatively to synchronize emulated components every cartridge bus access (indeed, for hybrid emulation to work, the emulator would have to issue the read or write command then advance the emulation of all other components for a few cycles until the cartridge - and the FPGA driving it - is ready to return data or has acknowledged the write access). I would definitively love to be proven wrong and see the proof it is indeed working as claimed, but I have serious doubts that 1) this could run at acceptable speed on their base hardware and 2) they had the time to make in-house (or even modify existing) emulators that do access to cartridges in real time.

I am no hardware expert like Kevtris but I have enough knowledge about how software emulators are internally designed and what makes them less accurate (or not) than real hardware to tell you this section of the patent (which usually is used to introduce the invention and the added value it has compared to previously existing "work") makes zero sense. Reading from a ROM file stored in volatile memory makes no difference in regard to emulation accuracy compared to direct read from the ROM chip through cartridge interface (unless of course the ROM is a bad dump but this is very unlikely with the system covered here). This is later emphasized in the patent in the 'active cartridge reading' section which I believe is the main idea behind that 'hybrid emulation' concept Again, they pretend that direct access to cartridge ROM makes emulation of the console hardware more accurate than with traditional software emulation (which is blatantly wrong) and give an example as to when the emulator would read the cartridge but they don't really address the fact the emulator will have to wait for the cartridge access to complete and thus each emulated CPU instructions processing will take the exact same time as if it was running on the original CPU, which means emulators must be interrupted and resynced (to advance other emulated components like APU, PPU,etc) after each single instruction. Such synchronization granularity would require A LOT of processing power and would require to basically write new emulators from scratch designed for this as software emulators are designed to emulate CPU instructions as fast as possible (to save remaining processing time for the emulation of other hardware components) on a single processing core and only resync to real-time when needed. I don't think even BSNES goes so far in regard to real-time synchronization between emulated components and even if it was the case, modifying it to makes every single memory access to cartridge (which actually can be made not only by the main CPU but also other chips inside the SNES using DMA or HDMA) blocks emulation for 200 ns (which is at least 10x slower than a modern RAM access) would be insanely slow.

This announce about custom controllers makes me think their 'hybrid emulation' is now pretty much limited to real-time interfacing with original controllers (as they apparently use the same connector as original ones) and they finally realized that real-time interfacing with the game cartridge was impossible from a software emulator that needs to run MUCH faster than the original CPUs did. They probably will use the exact same solution as retron-5 like products (i.e dumping the ROM ) and, when necessary, emulate the cartridge hardware with software like any other emulator so they need to find new ways to differentiate themselves from competition.

Simply because it is not possible. From what I recall (I've seen that question popping up so many times on old Sega emulation forums, with always the same answers from technical gurus): 1) loading a Genesis ROM implies to load it in internal RAM within the Sega CD then execute it from RAM with one of the two MC68000 CPU available 2) Sega CD MC68000 CPU does not have access to Genesis hardware (video/sound/etc) so you would need to load it in RAM accessible by the Genesis CPU then runs it from there 3) the maximal RAM window size available to Genesis CPU is 256KB so you are limited to quite old or basic games 4) the memory mapping of Genesis CPU when Sega CD is connected is different from when a game cartridge is connected (the space normally mapped to the game cartridge ROM starts with Sega CD Boot ROM, etc) so games have to be reprogrammed/patched to handle the needed address conversion Not possible either because SMS games require the Genesis to be switched in SMS mode, which is done on hardware reset if some pin is asserted on the cartridge interface

Like I said, both Stephane Dallongeville (who is the author of Gens emulator and SGDK devkit) and Mike Pavone (who is the author of Blastem emulator) are both respected and reasonable people, who never engaged so far in internet drama or liying. If they are saying that they got access to Flashback HD emulator sourecode and that it was given to them by someone from AtGames, I have no reason to doubt their words. This does not mean the sourcecode was PUBLICLY released but that it was released to some people who asked for it (which is actually one of the rights granted by GPL code). I understand that AtGames PRs are trying to keep everything 'under control' (or more likely 'private') and are kinda freaked out by this bad publicity, which unfortunately comes just after Sega's Megadrive Mini announcement and the overall very negative public response when knowing AtGames would be behind the product, but I would really advise them (and you) not to blame this just on 'haters' (hmm this sound familiar) and making public statements to minimize or deny their responsibility because facts are that : 1) AtGames gained its bad reputation in retrogaming community by itself, by releasing cheap and low-quality Genesis products along all these years. It's good they want to release better products (and obviously gain a better reputation) but you can not blame people for not trusting the brand anymore and being doubtful when they make announcements of upcoming 'better and greater' things. 2) It was proven (see reverse engineering analysis posted above) that the released Flashback HD product is using existing GPL emulation software (and not an original creation as initially claimed) without either mentioning the rights granted by GPL to their consumers (as normally requested by GPL terms) OR alternatively getting a proprietary relicensing agreement from the copyright owners of said GPL code (which both Gens and Genesis Plus developers denied having with AtGames or anyone affiliated with them). Instead of making a public statement that more or less denounces 'false accusations from haters' (without addressing the opposed proofs), claims that they got permissions from 'every concerned developers' (which can easily be denied by asking directly copyright owners of found code) then ask people to give them another 'chance', they should have rather acknowledged the problem and saying that they are investigating in intern and will be trying to fix any existing licensing issues. Please do not take this personal Bill, I am sure you have good intentions and as AtGames messenger, I understand that you don't like people attacking or doubting the company, but I see no reason why we should not expose problems publicly when we are aware of them and proofs are out there, just like with any other products aimed to be sold to us.

Just putting this link I found on Mike Pavone twitter (https://twitter.com/mikepavone?lang=fr) which proves that Gens, Picodrive and Genesis Plus code is used in Flashback MD software (well, at least identical functions and data names but it would make no sense from developer point of view to use so much exact same names as existing emulators if not copying code from them) https://www.retrodev.com/files/atgames_analysis.html Also, regarding this statement: FYI, according to mask of Destiny, author of Gens (Stephane Dallongeville) and Genesis Plus (Charles MacDOnald) have explicitly denied giving any agreement to anyone regarding the use or relicensing of their code in the existing Atgames Flashback. Also, third parties can not give agreement on code for which they don't own the copyright, so, from AtGames statement above, it's possible they subcontracted the whole emulator development to a developer (that Marat guy?) which fooled them by pretending he wrote all the code himself, but instead bundled existing GPL emulators portions together without telling anyone. Anyway, according to Stephane Dallongeville in a french forum (link below), ATGames released the source code of the Flashback MD emulator yesterday (probably to comply with the GPL) but I couldn't find a link anywhere. http://www.gamopat-forum.com/t98761p150-megadrive-mini-by-sega

Well, it seems like someone as analyzed the built-in emulator and things are not so 'clean' as you are saying. http://www.sega-16.com/forum/showthread.php?33299-Petition-against-ATgames-being-the-Mega-Drive-Mini-Developer&p=813434&viewfull=1#post813434 Mask of Destiny is a respected member of the MD emulation scene so I don't see any reason for him to lie or for us to doubt what he is claiming so it would be interesting to know what will be AtGames stance about this. The most frustrating maybe would be that if they had respected the GPL and made the source available on demand, people would have been able to modify and replace the current emulator with something better. Even from ATgames's point of view, it would have been beneficial to have a better emulator developed by the community, free of charge, instead of paying someone to simply put existing pieces of open-source code together (MD Flashback would also have probably gained a better reputation and possibly increase its sales).

Those 'excuses' smell kinda fishy to me Was this 'other' company owning 'retroblox' even confirmed? The only mentions of 'retroblox" in google are related to this thing and the only trademark I could found for this name is a deprecated one owned by 'Push Run Holdings' LLC (which unsurprisingly also owns the 'Polymega' trademark). Also that particular line sounds kinda sarcastic. Off course people want to know more and see more after being teased, it's not just 'some people' and it's not about being 'insatiable' (which I translate here as over-demanding) I am too wondering about that supposed patent, does 'published' mean it's accessible to public using google patent or other internet sources?

In my opinion, they are facing technical issues with their initial idea of 'hybrid emulation' (i.e interfacing the cartridge directly through the software emulator while it's running) as already predicted by some others in this thread and are slowy turning back to more traditional method that is proved to work (i.e first dumping the whole ROM into internal memory then emulating the game as with any other emulator). That would explain why they are suddenly blaming 'competitors' that are 'stealing their ideas' although none of the existing product is using the concepts they were advertising (separated 'console' modules and real time interfacing with controller/cartridge hardware from emulation software)

More than its large ROM size, Pier Solar is protected against dumping: from what I remember (there was a website explaining the technical details but it got deleted), you need to do specific timed steps to get the full 8MB ROM dump. And even with full dump, they would need to emulate the special mapper and save feature it uses to get the game starting and running. That's why it took so much time to get it dumped and emulated, and only in a few recent emulators.

As for reducing BIOS Processing time, they are mostly due to the speed of CDROM unit being used in those old consoles and access times being quite slow so it's easily reducible if you are using a modern CD unit and rewrite the BIOS 'disc read/play/seek' functions to directly interact with the disc instead of interfacing with the several layers of original hardware (generally the BIOS running on console CPU communicates with a CD command processor, which itself controls a CD DSP, a RF AMP , a Servo Signal processor, etc). Emulators generally only emulate the communication between BIOS software (running on main CPU) and the CD command processor and the rest is HLEed. By rewriting the BIOS calls, you could theoretically remove an additional level of emulation processing (the communication with CD command process and interpretation of CD commands). That said, for Sega CD, no such 'custom BIOS' or 'HLE implementation' exists as of today (at least publicly) and looking at the complexity of Sega CD BIOS (the official documentation with the API can be found here: http://antime.kapsi.fi/sega/md.html),I find it hard to believe they had the time to rewrite a custom new one that does not include ANY of the original (copyrighted) code, just like I cannot believe they are rewriting new emulators from scratch rather than reusing open-source ones like they did with Retron5/RetroFreak. As confirmed by the above article, Hybrid Emulation is just a buzzword to tell that only console 'internals' are emulated and anything that could physically be connected to the console (controllers, game cartridge or cd) is directly interfaced instead of being emulated like with traditional emulators. But the internal of the console (which more or less represent 90% of actual emulators code) still need to be emulated in the traditional way. I don't think each module needs to have its own CPU though, it could just be some FPGA that makes the interface between the input hardware (controllers, game cartridge) and the CPU running the emulator on the main unit.

The reason Super Street Fighter II is special is that it uses a custom mapper in the cartridge to allow support for extended size (5MB) when max size is 4MB using traditional cartridges. See http://segaretro.org/Super_Street_Fighter_II:_The_New_Challengers So it's pretty much an unique case (another one would be Pier Solar which is also very large) and there is no reason the other games you mentioned won't work, they might be 'large' games for you but they are still under the 4MB limit. Super Street Fighter II does not have save support so that's not the same issue. It is also different from Street Fighter II because of the size issue mentioned above. That said, issues with EEPROM games is something that existed for a long time with Genesis emulators and also flashcarts so it's good they got this fixed. There are a few games that won't boot (Wonderboy in Monster World and Megaman are the most famous ones but also NBA JAM and a few other sport games) or won't save (I know Rings of Power is one of them) if EEPROM mapper is not properly emulated. There are a few threads in Krikzz forum about these EEPROM-based games (they even got ROM patches for some of them).