Sonic Megamix 3.5 (leaked version) {Sonic 1 hack} improper colors.

[Former user]

Original [issue 168](https://code.google.com/p/genplus-gx/issues/detail?id=168) created by bennayboy on 2011-04-16T02:24:33.000Z:

When I got it running,the picture is very dim and has the wrong colors,but it actually runs fine otherwise.

I had to disable the checksum (red screen) just to get it to run.

(I used 00033A:4E71,and 00033C:4E71 in the cheats menu then used hard reset to disable the checksum)

I have the file attached to help fix this problem.

It runs perfectly fine with JenesisDS 0.7.4 on my DS-Lite.

[Former user]

Comment # 1 originally posted by bennayboy on 2011-04-16T02:26:05.000Z:

It also works somewhat perfectly via VC WAD injection over Sonic 3.

[Former user]

Comment # 2 originally posted by ekeeke31 on 2011-04-16T14:34:12.000Z:

I fixed the checksum routine issue, it was because that game uses SRAM and ROM in the same memory range and since in this case, the emulator affects SRAM on reset, the checksum routine was actually reading SRAM instead of ROM, resulting in a bad checksum.

This hacks in fact goes around the problem by having the ROM area filled with $00 in this shared range. This probably works in other emulators by luck because they initialize SRAM with $00 while Genesis Plus GX use $FF.

Using $00 indeed fix the checksum routine for taht game, but breaks other (real) games so I don't like this solution. I could also affect this area to ROM instead SRAM on reset but then SRAM would remain disabled for ever since the game never activates it like other similar game cartridges (Legend of Thor, Phantasy Star 4) would do.

A real cartridge would use bank switching because a memory area cannot be affected to both ROM & SRAM at the same time but off course this hack was not meant to be played on a real cartridge and expect read/Writes in $200000-$203FFF area to simply go into SRAM automatically, and the rest go to ROM.

Clearly, this game need special mapper emulation (a mapper that does not even exist in reality, hence the paradox) or better coding.

Anyway, I just tried it and this hacked ROM still does not work on real hardware either. The reason it works on other emulators is that they are less accurate than Genesis Plus GX ;-) So don't blame this emulator but blame the authors of this hack for bad programming and testing on inaccurate emulators...

Here is patches to get it work (choose "no save", this game crash if you pick "save" for an unknown reason ):

0012C2:8004 005120:8004 005242:8004 005EA6:8004

There are probably more similar patches needed later in game, I don't have time to test but you got the idea: basically, what those codes do is changing the byte written into VDP register comment 0\. from $00 to $04. The reason is that bit 2 MUST be set on real hardware otherwise the color palette will be cut down.

You'd better directly patch the ROM using an hexadecimal editor (left value is ROM address, right value is 2-byte data to patch) or even better, tell the ROM hacker that he is doing things bad by pointing him here.

And please don't post copyrighted ROM here anymore, I'm not sure about google code policy but you would not want this project to be shutdown for legal issues, right ?

[Former user]

Comment # 4 originally posted by ekeeke31 on 2011-04-16T14:58:55.000Z:

To be correct, this hack apparently added generic bankswitching to enable SRAM (as used in other real cartridges, although the original Sonic did not had this) but it did it wrong because it forget to disable it once SRAM access is done.

Result is that the game crashes if you use the "SAVE" mode because it try to read ROM when SRAM is enabled.

[Former user]

Comment # 5 originally posted by bennayboy on 2011-04-17T02:33:29.000Z:

Thanks for your help,I will try it when I can get access to my Wii.

Also,this particular version of megamix is no longer accessible for download anywhere.

I think it should be re-released in the list of versions on Sonic Retro's article for it since the latest one (Sega CD version) is newer than this one.

[quote]And please don't post copyrighted ROM here anymore, I'm not sure about google code policy but you would not want this project to be shutdown for legal issues, right ?[/quote]

Yes,right. 8^)

[Former user]

Comment # 6 originally posted by bennayboy on 2011-04-18T17:57:28.000Z:

Bad news,every Special Stage and all of Labirynth Zone are still miscolored and dark.

I will probably try hexing every 80-00 to 80-04 intermittently until I find the ones that fix it.

[Former user]

Comment # 7 originally posted by bennayboy on 2011-04-19T03:08:33.000Z:

Damn,it seems when playing as sonic on Labirynth zone,it does not even load at all. And also on special stages,Sonic is a garbled mess.

[Former user]

Comment # 8 originally posted by bennayboy on 2011-04-19T04:05:44.000Z:

This is the reason I hope for a Sega CD emu for Wii to be created eventually,so I can play 4.0b instead of dreading over so many problems with this corrupt leak version.

[Former user]

Comment # 9 originally posted by kingofchaos6669 on 2011-04-19T04:26:25.000Z:

I personally wouldn't bother with this older build. But, it'd be nice to play it via Sega CD emulation but I HIGHLY doubt that'll ever happen.

[Former user]

Comment # 10 originally posted by ekeeke31 on 2011-04-19T08:15:54.000Z:

Well, after adding back support for other VDP (Game Gear, SG-1000 & Master System II) and since Genesis emulation is now pretty much perfect (at least without any reported compatibility issues), I am planning to work on Sega CD emulation after that.

I've been studiying the available documentation & code for some time now and I think I pretty much got what need to be emulated and how to implement it. My only cincern is how fast it would run without optimization, Genesis Plus is indeed more accurate and therefore much slower than Gens / Picodrive.

[Former user]

Comment # 11 originally posted by kingofchaos6669 on 2011-04-19T16:37:53.000Z:

Indeed, the Wii hardware may not even be able to handle it (Wii 2 anyone?). I actually have my doubts it'd be able to handle 32X emulation either.

[Former user]

Comment # 12 originally posted by bennayboy on 2011-04-19T20:44:11.000Z:

Wii can run N64,and PS1 full speed with DS running at 70%,I am pretty sure the Wii can handle emulating Sega CD and/or Sega 32X.

[Former user]

Comment # 13 originally posted by Icedus on 2011-04-19T21:17:46.000Z:

Sega CD emulation on the Wii is likely do-able from what I understand and I definitely believe that eke would be able to work it out given enough time, but I recall reading that the 32x has some really complicated stuff going on and is generally a pain to emulate. The N64 and PS1 emulators for the Wii, as excellent as they are, are definitely not without their problems at this stage, and many games still have issues with speed, sound, textures, etc.

[Former user]

Comment # 14 originally posted by ekeeke31 on 2011-04-19T21:19:50.000Z:

Yeah sure, sadly things are not so binary simple... Let's get straight facts, not assumptions: Wii64 and WiiSX use dynamic recompiling techniques and heavily Wii-optimized rendering, this is far beyond my knowledge. Also, lot of games are still not running full speed afaik and with this kind of optimization, you generally have to deal with less accuracy, more bugs, etc NDS emulation running at 70% ? This is actually very optimistic, maybe for 2d games that does not use all the hardware, not for 3d. Anyway, don't expect faster emulation without similar optimizations as the above ones.

Anyway, I know people like to think "it runs A so it should be easy to run B" but the truth is that those are all complete different systems and different emulators so it's like comparing pines and apples, i.e not very meaningful.

I am optimistic for sega CD emulation though but 32x is a whole different beast with two additional CPU running both faster than the SVP chip alone so I can already tell you there is no way it can run at decent speed without A LOT OF rewrite and optimization in genesis plus. Basically you have now four CPU that must be emulated in sync, this requires quite a lot of horsepower.

[Former user]

Comment # 15 originally posted by bennayboy on 2011-04-19T21:53:53.000Z:

What I mean about N64,PS1,and DS is about the Wii's specs being adequate to emulate those systems,and there also is NullDCe Wii being made by someone (was Arikado) as well already running the Dreamcast menu (though buggy) runs at-least 50% full speed in the early stages according to a youtube video.

It was amazingly created in just 30 minutes! ^v^

[Former user]

Comment # 16 originally posted by ekeeke31 on 2011-04-19T22:18:15.000Z:

Actually, I probably will surprise you but there is nothing really hard or amazing in porting an existing emulator to another platform, many people can do it with some coding knowledge, though the effort being made is still respectable. The challenge is more to get it working at decent speed and optimize it for the new platform, understanding the inner of both emulation and host system to get the best of it.

Sadly, that's why POC rarely turns into playable emulators, that's something people who don't really get how emulation works seems to forget, they think "if it works now, it can only improve, just need time" but the truth is it needs also a lot of work and most devs generally abandon when they realize the task is way harder than a simple port (or once they got people attention and hopes )

If i tell you 32x emulation cannot run full speed in genesis plus without HUGE rewrite, it's because I know what i am talking about, i know Wii raw speed i can achieve with traditional emulation technique and i know the requirements for 32x + genesis hardware emulation.

[Former user]

Comment # 17 originally posted by ChronoMew on 2011-04-21T01:07:18.000Z:

There's just something I always fail to understand.

The Wii is supposedly more powerful than the Xbox (the first one), so if said system can emulate the 32X with barely any problems (NeoGenesis), how come the Wii can't?

[Former user]

Comment # 18 originally posted by kingofchaos6669 on 2011-04-21T04:06:34.000Z:

Isn't it just a port of Gens?

[Former user]

Comment # 19 originally posted by ekeeke31 on 2011-04-21T06:30:27.000Z:

Exactly.

What you don't understand is that I am NOT saying the Wii is not able to emulate 32x, I said (if you read carefully) that it was not possible to have playable 32x speed in Genesis Plus without a lot of optimization (not even counting adding 32x emulation which does not exist in the first place).

People often use Xbox ports as a reference but again there is no real point in comparing because that's two different architectures (PowerPC with customs GPU and devkit VS Intel CPU with NVIDIA GPU and DirectX support). "More Powerful" does not mean much things when it comes to porting existing code that were designed for one particular architecture.

So basically, it was nothing hard to port ALL existing emulators from the PC platform to Xbox, providing the source was available. All that devs had to do was to take the unmodified code, add XBOX API and compile it using the leaked official devkit. No surprise that all these ports were initially released by the same guy. See, there is nothing to be impressed about, it was quite running out of the box. But people are easy impressionable when they don't know how stuff really work ;-)

Similarly, NeoGenesis is only a renamed version of Gens, all efforts went into the fancy user interface which people use to compare emulators, not in emulation code and I bet this is still the same old Gens core that Stef coded years ago, which is inaccurate in many ways compared to current Genesis emulators. Now Gens, even if inaccurate, is mostly written in Intel assembly, which makes it quite optimized for this processor type and run fast enough on Celeron PC or the Xbox.

NONE of this exist in Genesis Plus GX, meaning that:

1) I have to implement 32x emulation from scratch. This is not really complex (probably less than Sega CD emulation) but still lot of work. SH2 core is implemented in MAME but it's quite slow so it would be unusable on Wii, the rest (PWM audio, 32x VDP, interfaces) would also have to be coded from scratch to fit with current Genesis emulation (remember 32x was an add-on, it can't work without Genesis running at the same time).

2) I'd have to rewrite a lot of things in PowerPC assembly or use dynamic recompiling for the two SH2 cores to at least hope getting decent speed, without any idea how fast it would really run at the end. As I said previously, this is far out of my league for now, I might give it a try because it's an interesting challenge and it's always nice to learn new things, but you need to understand that things are never as simple as you think they are.

[Former user]

Comment # 20 originally posted by thiagoalvesdealmeida on 2011-04-26T22:07:40.000Z:

I don't think 32x is necessary. There isn't even a good game for it. Sega CD, on the other hand, was much better supported, with enough good games to justify the emulation.

Hey ekeeke, let you ask you a question. I was wondering about the aspect ratio of Genesis games and I would like to know, between the following pictures, which one looks more like the way it looks on a real genesis running on a NTSC CRT.

comment 1\.: http://i.imgur.com/VWOBG.png comment 2\.: http://i.imgur.com/9C3V6.png

(Notice the green planet)

Thanks.

[Former user]

Comment # 21 originally posted by bennayboy on 2011-04-27T02:25:27.000Z:

What about Knuckles Chaotix and it prototype versions?

Knuckles Chaotix has level select and a positioner debug mode (when pausing the game) by making peanut-butter and jelly in the color test LOL.

If I am thinking correctly,I could use PAR codes (from bsfree) with Sonic CD if the emulator gets decent Sega CD support.

[Former user]

Comment # 22 originally posted by ekeeke31 on 2011-04-27T06:09:55.000Z:

Hopefully, emulation is never "justified" by the popularity of the system. Thiagoalvesdealmeida, remember this is all about nostalgia, not about "good" games ratio the system had and you will always find people to argue with you about what a good game is :-)

About your question, I'd say the one without borders looks the most correct (and this is how it looks in Genesis Plus GX on my CRT television). That's said, the same screen (320x224 stretched to 640x480 without borders) will look incorrect if displayed on the same TV.

The reason why is that pixels on your computer screen are SQUARE while the ones output by the Genesis (or SNES, or Master System or whatever system of that time) were not, so what people abusively describe as "4:3" have different meanings depending on the target.

What people generally forget is that 4:3 is only a "screen" (or display) aspect ratio and is determined by:

1) the resolution of the system i.e the number of "pixels" seen on screen: in Genesis case, it can be very various, 256x192 (Mode 4), 256x224, 256x240 (PAL only), 320x224, 320x240 (PAL only)

2) the pixel "width": this is determined by the pixel clock of the console (which is itself derived from the main clock) and this is what determines the pixel shape on screen. Analog TV only defines a maximal width but it's actually the console which determines the image shape, that's why a 256x224 image will have similar "width" as 320x224 on a TV screen, because the pixel clock is slower in this mode and therefore pixels are wider.

Now, people often says 320x240 is 4:3 but this is only true with square (1:1) pixels. On a Genesis, 4:3 is more like 320x224 for NTSC (but again, not exactly) if we consider the "fullscreen" area of the TV represents a perfect 4:3 area (for PAL, full screen is more like 320x268, which is why you have those big vertical borders since the max the Genesis can render is 224 or 240 lines in PAL mode).

That's why, to reproduce NTSC aspect ratio on COMPUTER SCREEN, it's usually accepted to upscale the 320x224 (or 256x224) generate image to 320x240 (or 640x480, 1280x960, etc) and omit the border that generally are output by the Genesis (vertical borders are output because vertical height of NTSC or PAL analog video signal is FIXED so the "active" display area must be completed with borders, which are generally hidden by TV overscan anyway).

That's said, this is maybe "more correct" this way but the only accurate way to get 100% correct aspect ratio is to output a true analog video signals (with vertical AND horizontal borders) like Genesis Plus GX is doing here. Unfortunately, lot of modern digital TVs cannot handle this signal properly anymore.

[Former user]

Comment # 23 originally posted by thiagoalvesdealmeida on 2011-04-27T15:38:34.000Z:

Thanks ekeke,

I thought Genesis used square pixels. Well, even if that's not the case, I think a lot of games were created with square pixels in mind

http://i.imgur.com/POuYz.png http://i.imgur.com/B4oix.png

In the first picture, the moon looks vertically stretched in GenesisPlus, and the same thing happens in the second picture, with the background square-pattern and the sphere-world.

If the pixel clock of a real genesis is different from Wii's pixel clock (or maybe the refresh rate is also different and that makes the image to stretch) - how Genesis Plus is able to achieve the same aspect ratio?

Does it use 4:3 aspect correction to resize the picture? Or the correct aspect ratio is achieved through a 100% analog behavior? (when using a CRT TV).

[Former user]

Comment # 24 originally posted by ekeeke31 on 2011-04-27T18:46:30.000Z:

No videogame console from that time used square pixel. Maybe some later games were developed using computer, I really don't know what kind of development machines they used (especially in Japan) but even the Amiga did not output square pixel.

To be honest, I personally don't see anything wrong with the way those games are displayed on a TV screen, maybe circles are not "perfect" circles but this is not something you really noticed while playing, I know some games where it's REALLY a pain to figure what the "artist" had in mind :)

That's said, I don't even think those games were \*really\* designed with square pixels "in mind", I think it was just easier to draw on a piece of paper with squares representing pixels and design stuff that way, that's all. I highly doubt SEGA's Q&A department was actually measuring circles dimension on screen to see if they were real circle or not, this is just something people do nowadays because they like arguing with emu authors :-P

As for Genesis Plus GX, the Wii actually can't output the exact same analog video signal as the Genesis so I have to make approximations. The 348 pixels-wide Genesis active line (including left/right borders) is simply converted to the related amount of Wii pixels, using Video Encoder scaling ability to get the same width.

Since I don't know the Wii exact pixel clock and since the upscaler most likely introduce some rounding approximations, it's hard to use exact calculated values and I actually found easier (and as much accurate in the end) to adjust scaling & find the correct amount of pixels using my PAL Mega Drive as a reference, connected on the same TV set.

Btw,

[Former user]

Comment # 25 originally posted by kingofchaos6669 on 2011-04-28T00:26:05.000Z:

What about Knuckles Chaotix and it prototype versions?

The prototypes would need special handling (aka fast timing). I still have my doubts it'll handle 32X much less Sega CD. =P

If I am thinking correctly,I could use PAR codes (from bsfree) with Sonic CD if the emulator gets decent Sega CD support.

Well, yes. Considering I'm the one who hunted down those codes in a custom build of Kega given to me by Steve Snake himself with Sega CD cheating enabled. However, you can't cheat at every Sega CD game - only ones that use Genesis RAM like Sonic CD does. If Sega CD emulation is done at some point, I personally would like to see cheats open for it, even though it won't work for many games. For them to work with Sonic CD alone would be worth it. ;)

[Former user]

Comment # 26 originally posted by thiagoalvesdealmeida on 2011-04-28T04:15:21.000Z:

Well ekeeke,

I compared Genesis Plus GX against PGEN (PS2 emulator, running at native 320x240, exactly like a real Genesis), using a video switcher (same TV and cable) and both look identical, pixel by pixel (at least with static images and with the vertical border turned off).

Really impressive. 256x224 also looks identical. I know that when you use 256x240 in a CRT the picture is analog stretched. The PC emulators to reproduce the same aspect ratio needs to digitally resize the picture (which will blur it).

What about the Wii? 256x224 games are also analog stretched?

[Former user]

Comment # 27 originally posted by ekeeke31 on 2011-04-28T08:59:10.000Z:

Hum, I think I already had this discussion before. All is done digitally by the Video hardware, the analog video signal output by the Wii or the Gamecube has a fixed length and a fixed pixel clock.

Bluring is a side-effect of basic filtering applied during upscaling. Filtering is necessary to avoid artefacts when the scaling ratio is not an integer. If upscaling is done by the graphic chip (GX) during rendering, basic bilinear filtering is used which makes things quite blurry, but the Video Encoder is also able to upscale the framebuffer width, and probably uses better filtering hardware, which results in much less blur.

And what you call "analog stretching" is not caused by the CRT, a TV actually does not "stretch" anything, it's just that the active part of analog video signal has a fixed length but can hold a variable amount of distinct color samples (pixels). The less distinct pixels you have, the "wider" they are and the more "stretched" the image appears on screen when TV is scanning the signal.

[Former user]

Comment # 28 originally posted by thiagoalvesdealmeida on 2011-04-28T18:53:21.000Z:

Yes. Now I remember that other discussion. Sorry, I don't want you to repeat the same stuff again. :)

Right now, with 256x224 games, you are doubling the horizontal resolution to 512 pixels and letting the video encoder upscale 512 to 640. I thought this would produce visible blur or artifacts. I was wrong.

Maybe the reason you can't notice blur is because the Wii is using the same vertical resolution of the original console, which is much more important.

There are some TurboGrafx-16 games for the Virtual Console that use 256x224, but the video emulation is horrible. It use 240p, but with a lot of artifacts. I suppose the reason is because they are upscaling the picture to 640, without bilinear filter, using only the GX, right?

One more thing, there are a lot of audio crackling in FCEU-GX. Do you think it's possible to solve this problem by simply pushing slightly more than 48000 samples?

Thanks

[Former user]

Comment # 29 originally posted by ekeeke31 on 2011-04-28T19:02:33.000Z:

I have no idea.

To the initial poster, you might want to check this thread on SpritesMind: http://gendev.spritesmind.net/forum/viewtopic.php?t=920

Looks like a later version of Sonic Megamix, including sourcecode. The package includes a compiled binary (S1MM.bin) which seems to have previous bug fixed. I deciced to modify the way I handled the ROM/SRAM mapper, it's now not exactly what the real mapper was doing but it remains compatible with games that used it while preventing Sonic MegaMix from crashing when it forgets to re-enable ROM.

[Former user]

Comment # 30 originally posted by thiagoalvesdealmeida on 2011-04-28T23:47:11.000Z:

Something is wrong with this version. Even Sonic's homing attack is absent.

[Former user]

Comment # 31 originally posted by kingofchaos6669 on 2011-04-28T23:48:15.000Z:

It's the leaked source code. I wouldn't be using it if I were you as the Megamix developers won't like it. =P

[Former user]

Comment # 32 originally posted by ekeeke31 on 2011-04-29T10:15:28.000Z:

The link has been removed anyway. From quickly looking at the source, this is probably the most advanced Sonic hack in existence, very serious work at first glance. And yes, the included build is still a little buggy, are they still working on it ?

[Former user]

Comment # 33 originally posted by kingofchaos6669 on 2011-04-29T16:44:49.000Z:

I actually wouldn't call Megamix a hack at this point, it's more or less a fangame. :D

Team Megamix ported it to Sega CD and released one version. As far as I know, they're still working on it.

[Former user]

Comment # 34 originally posted by bennayboy on 2011-08-20T13:47:08.000Z:

Apology for bump,but Sonic Megamix 3.9 is still miscolored in genplus-gx 1.6.0 which is a downer for me. 8^/

[Former user]

Comment # 35 originally posted by ekeeke31 on 2011-08-20T13:58:00.000Z:

Not my problem, I'm not going to make the emulator less accurate just because badly coded hacks exist, better tell the devs what they are doing wrong and that it's their responsibility to test their hacks on accurate emulators or real hw.

Or wait for an official release because I guess this is another leaked beta, right ? I cannot find any infos on a 3.9 version so I cannot help you with patches

[Former user]

Comment # 36 originally posted by bennayboy on 2011-08-20T15:55:23.000Z:

Oops I meant to say 3.5,I named my VC inject 3.9 LOL. \*Falcon Pwnched\*

Apology for bump,but Sonic Megamix 3."5" is still miscolored in genplus-gx 1.6.0 which is a downer for me. 8^/

Remember that 3.5 is a leaked/unfinished version which is why it is buggy.

It would be great if you do manage to get Sega CD up and running so Everyone can play Sonic Megamix 4.0b as well as Sonic CD.

I remember saying a VC injected Sonic Magamix 3.5 works properly with the right colors but still won't save correctly,the question is,is the VC's emulator for Sonic 3 (my inject wad) accurately emulating when running Sonic Megamix 3.5?

The main reason I want to play Sonic Megamix 3.5 is because it has Knuckles and Tails as playable characters unlike the official v3.0 of Sonic Megamix.

[Former user]

Comment # 37 originally posted by ekeeke31 on 2011-08-20T16:20:17.000Z:

Still, my point remains.

There is nothing I can "fix" so I don't understand why you would think a new emulator version would change anything so there is no point of bumping anything because it won't change

I thought it was clear that this is a bug in this hack that need to be fixed (or patched)in the ROM, not the emulator...

[Former user]

Comment # 38 originally posted by bennayboy on 2011-09-03T15:14:15.000Z:

In light of that,how is the progress going with Sega CD and Sega 32x emulation,if you are still into implementing them \*hopes in for at least Sega CD emulation\*.

[Former user]

Comment # 39 originally posted by kingofchaos6669 on 2011-09-03T16:12:29.000Z:

The main issue I can think of is, he Wii's hardware might not even be able to emulate either Sega CD or 32X at full speed. If it happens, it might not happen anytime soon. Those systems \*may\* be a PITA to emulate.