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.