Compiling an emulator for enhanced Megadrive

[tryphon]

For some time I have had discussions, noticeably with Stef, about an enhanced Megadrive. Just simple enhancements, such as :

* dissociated palettes for sprites and backgrounds

* 12 bits colors like Game Gear (or even 15 bits)

* anything else... (128 KB VRAM...)

Those modes would be selectable by a mechanism, so that normal games would be perfectly playable, and hacks using those modes could behave differently according the model they are running on.

I'd be willing to try by myself to modify an emulator to try this. But I'm facing one of my weak points when it comes to programming (I'm no professional programmer) : setting an IDE for an existing project (with all the dependancies).

So I'm asking for an emulator :

* easy to compile
* fast enough
* with no asm inside (I don't know 80*86 asm, so it'd make my understanding of the code too slow)
* if possible, not too old

So far I've tried :

* MAME (wanted to modify the megadrive core, which is quite simple to understand) but : it took litterally hours to compile, I ended with an error, and each attempt to recompile it took minutes

* Exodus : I was igominiously betrayed by Nemesis instructions, which were based on an old release He fixed this and I could give it another try, but the problem is that Exodus doesn't run real-time on my machine (even if it'd be better than nothing)

* Gens : it has asm inside, and from what I've seen, likely the raster renderer (which should be modified for my purpose, so...)

Have you other ideas ?

[cero]

Dgen is a very nice emulator to modify.

However, we've had this same discussion on Nesdev about NES and SNES enhancements several times. The conclusion each time is that it doesn't make any sense. If you want to make unlimited games, target a modern platform. "Console X, but enhanced such that only emulator Y can run the program" is a niche of a niche of a niche, barely any folks will ever run such games.

Now, if you were manufacturing such hw, it would be slightly different, but anyway...

[Stef]

Genesis Plus all the way ! Forget about DGen (too old and not accurate) and Gens (has assembly and not accurate enough too).
Genesis Plus GX is even a better base, if you want i have a simplified / fixed SDL based sources base sitting somewhere on my hard drive but i guess you can use the plain Genesis Plus GX base too (if the SDL support is better now).

[tryphon]

Dgen is a very nice emulator to modify.

However, we've had this same discussion on Nesdev about NES and SNES enhancements several times. The conclusion each time is that it doesn't make any sense. If you want to make unlimited games, target a modern platform.

It is precisely not the case : I just want to see what could have been achieved with a Megadrive such as I think it should have been released (because I don't think separated palettes and 12 bits colors would have cost much more, especially if we get rid of some less useful things like SMS retrocompatibility or Shadow/Hilight).

"Console X, but enhanced such that only emulator Y can run the program" is a niche of a niche of a niche, barely any folks will ever run such games.

I'm totally aware of that, and then again, it's mainly personal curiosity

Now, if you were manufacturing such hw, it would be slightly different, but anyway...

Would be great if M2 will include something like that in their MD mini

Thanks Stef, I'll try to compile Genesis Plus / GX...

[tryphon]

Trying to compile Genesis Plus. Opened file in code::blocks.

* installed SDL-1.2 lib and added path in linker and include options
* same with Zlib
* same with Allegro-5.1.X.X
* renamed uint8, 16, etc. as uint8_t, uint16_t, etc (which seems to be the standard names now)

It doesn't compile. I suspect the Allegro version used to be version 4 (and 5 is not backwards compatible). Problem : can't find a compiled Allegro-4 for windows, only source files. Am I condemned to compile it, though it's already difficult for me to compile the project using it ?

[Sik]

Dgen is a very nice emulator to modify.

However, we've had this same discussion on Nesdev about NES and SNES enhancements several times. The conclusion each time is that it doesn't make any sense. If you want to make unlimited games, target a modern platform. "Console X, but enhanced such that only emulator Y can run the program" is a niche of a niche of a niche, barely any folks will ever run such games.

Now, if you were manufacturing such hw, it would be slightly different, but anyway...

I think it's related to the EMD project on Discord (which is a Mega Drive on FPGA with enhancements). But right now that project hasn't really gone anywhere aside from one prototype board (not even a FPGA program). The mentioned specs definitely seem to match at least.

Honestly my first thought on making an EMD emulator would be to take BlastEm and modify that. At Titan we already did that to emulate the VDP debug register while making Overdrive 2.

[Stef]

We're speaking about that Megadrive+ since a long time now and yeah, the EMD project on Discord came up from that recurrent discussion. But today i think the EMD project goes far beyond from the specs we describe here (you are adding features to EMD every day )
While i would rather choose to stay much closer to the original MD:
- RGB444
- 4+4 palettes
- eventually 128K VRAM mode

nothing else.

BlastEm would be a better base as it's definitely the most accurate (with Exodus) but i think the core is also more complex (it uses dynarec) and so more difficult to modify to fit the features into, but maybe Mike would accept to bundle these enhancements directly into it (that would be awesome )

[tryphon]

What is this EMD thing ?

[hotrodx]

What is this EMD thing ?

Enhanced Mega Drive?

[tryphon]

Yes I had figured But I can't find anything about it on the web...

[hotrodx]

Yes I had figured But I can't find anything about it on the web...

Stef mentioned Discord, so maybe try there.

As for EMDs, I think I'd prefer it to be "doable" on actual Gennys, and are implemented on emulators now:
1. Overclocking
2. Extra RAM - like using SRAM(?) with the Mode 7-like demo.

Then there are features done on Emus that are not availabe on actual Genesis, but would be nice to have:
1. Rmoved scanline sprite limit
2. Filters

Then the stuff that will really break compatibility:
1. More palettes. Really hard to fit everything in 4 palettes.
2. More sound channels. (Just ask WM)

But more than anything, I would really like SGDK to compile into x86 target. A real x86 binary, not a Genesis binary wrapped by an emu launcher.
1. Porting games would be straightforward.
2. Debugging will be easier. Debug on x86, release on 68000 and x86.
3. Being also x86, can be a "platform" for Game Jams, giving more exposure to Genesis development.

From an x86, you can then add any enhancements. Compiling might use something like Visual Studio target profiles, some functions or features are not available on Genesis so it issues an error unless conditionally compiled.

Usually, what one can do is "wrap" SGDK with an intermediate library, then have two implementations of that library (SGDK and, say, DirectX). But a lot of things are lost in higher abstractions.

[Miquel]

The focus should be on making game development easy, and this means that when somebody makes a game doesn’t want to do two games instead because there are two sets of rules.

So, having RGB444 is much more desirable than anything else because is 100% compatible with the default RGB333.

And why you need to make happy programmers? Because to sell hardware (*), abundance of software is needed, and vice versa. The old console conundrum.


*Or to sell an idea to people if you aren’t on business

[Sik]

For what's worth it, a lot of the stuff mentioned there is possible on top of the existing hardware:

• System C2 has more colors (using external CRAM) and better color depth (15-bit)
• Tera Drive has 128KB VRAM (which also doubles transfer bandwidth)
• Sega CD and 32X add more audio channels (both slots have audio-in lines for this)
• Magistr16 has 256KB of work RAM (the only enhancement not involving the expansion slot)
• Overclocking is probably one of the most common mods after region mods

The ideal thing would be a dedicated clone though, we don't want to go around sacrificing existing hardware :​P

But more than anything, I would really like SGDK to compile into x86 target. A real x86 binary, not a Genesis binary wrapped by an emu launcher.
1. Porting games would be straightforward.
2. Debugging will be easier. Debug on x86, release on 68000 and x86.
3. Being also x86, can be a "platform" for Game Jams, giving more exposure to Genesis development.

From an x86, you can then add any enhancements. Compiling might use something like Visual Studio target profiles, some functions or features are not available on Genesis so it issues an error unless conditionally compiled.

And then you'll want ARM at some point. But if you go with SGDK in particular, I suppose a compatible library could work (same API but running on a completely different platform), as long as the game doesn't try to by-pass SGDK to write to the hardware directly.

So, having RGB444 is much more desirable than anything else because is 100% compatible with the default RGB333.

Guess what System C2 does :​O)

OK, more specifically: colors on the Mega Drive have a xxxxBBBxGGGxRRRx format. Colors in System C2 are xBGRBBBBGGGGRRRR, with bits 14-12 being the LSB of each component (if you make them always zero, you could treat colors as if they were 12-bit instead). This was relevant for the SegaSonic Bros port to Mega Drive since it meant colors could be used as-is (mostly, there was tweaking due to some shades becoming identical). Heck, the instructions screen is actually slightly bugged up in the arcade because one of the palettes is in Mega Drive format rather than C2 (so letters have a slightly darker background than they should). Whoops.

[tryphon]

Still can't compile Genesis Plus.

I find lines like :

Code: Select all

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
M68KMAKE_PROTOTYPE_HEADER

in m68k_in.c

How is it supposed to be correct ?

[hotrodx]

For what's worth it, a lot of the stuff mentioned there is possible on top of the existing hardware:

• System C2 has more colors (using external CRAM) and better color depth (15-bit)
• Tera Drive has 128KB VRAM (which also doubles transfer bandwidth)
• Sega CD and 32X add more audio channels (both slots have audio-in lines for this)
• Magistr16 has 256KB of work RAM (the only enhancement not involving the expansion slot)
• Overclocking is probably one of the most common mods after region mods

The ideal thing would be a dedicated clone though, we don't want to go around sacrificing existing hardware :​P

But more than anything, I would really like SGDK to compile into x86 target. A real x86 binary, not a Genesis binary wrapped by an emu launcher.
1. Porting games would be straightforward.
2. Debugging will be easier. Debug on x86, release on 68000 and x86.
3. Being also x86, can be a "platform" for Game Jams, giving more exposure to Genesis development.

From an x86, you can then add any enhancements. Compiling might use something like Visual Studio target profiles, some functions or features are not available on Genesis so it issues an error unless conditionally compiled.

And then you'll want ARM at some point. But if you go with SGDK in particular, I suppose a compatible library could work (same API but running on a completely different platform), as long as the game doesn't try to by-pass SGDK to write to the hardware directly.

So, having RGB444 is much more desirable than anything else because is 100% compatible with the default RGB333.

Guess what System C2 does :​O)

OK, more specifically: colors on the Mega Drive have a xxxxBBBxGGGxRRRx format. Colors in System C2 are xBGRBBBBGGGGRRRR, with bits 14-12 being the LSB of each component (if you make them always zero, you could treat colors as if they were 12-bit instead). This was relevant for the SegaSonic Bros port to Mega Drive since it meant colors could be used as-is (mostly, there was tweaking due to some shades becoming identical). Heck, the instructions screen is actually slightly bugged up in the arcade because one of the palettes is in Mega Drive format rather than C2 (so letters have a slightly darker background than they should). Whoops.

Yeah, adding an ARM target will even broaden the appeal.

The reason I would like to use SGDK as the basis, instead of a wrapper around SGDK, is that the wrapper usually becomes the platform. Think something like SDL. Since SDL wraps the implementation, apps are "ported to" SDL, minimizing the nuances of the underlying implementation.

Devs are so used to framebuffer rendering nowadays. So if we enforce something like SGDK as the API, it will orient devs to concepts like BG Planes, setting palettes, hardware sprites, among others. I think the appeal is something similar to CHIP-8 development, but even moreso since the Genesis/Megadrive is a popular console.