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

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by bennay...@gmail.com on 16 Apr 2011 at 2:24

Attachments:

• [S1MM new!!!^^.bin](https://storage.googleapis.com/google-code-attachments/genplus-gx/issue-168/comment-0/S1MM new!!!^^.bin)

[GoogleCodeExporter]

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

Original comment by bennay...@gmail.com on 16 Apr 2011 at 2:26

[GoogleCodeExporter]

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 #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 ?

Original comment by ekeeke31@gmail.com on 16 Apr 2011 at 2:34

• Changed state: Invalid

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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. 

Original comment by ekeeke31@gmail.com on 16 Apr 2011 at 2:58

[GoogleCodeExporter]

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^)

Original comment by bennay...@gmail.com on 17 Apr 2011 at 2:33

[GoogleCodeExporter]

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.

Original comment by bennay...@gmail.com on 18 Apr 2011 at 5:57

[GoogleCodeExporter]

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.

Original comment by bennay...@gmail.com on 19 Apr 2011 at 3:08

[GoogleCodeExporter]

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.

Original comment by bennay...@gmail.com on 19 Apr 2011 at 4:05

[GoogleCodeExporter]

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.

Original comment by kingofch...@gmail.com on 19 Apr 2011 at 4:26

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 19 Apr 2011 at 8:15

[GoogleCodeExporter]

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.

Original comment by kingofch...@gmail.com on 19 Apr 2011 at 4:37

[GoogleCodeExporter]

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.

Original comment by bennay...@gmail.com on 19 Apr 2011 at 8:44

[GoogleCodeExporter]

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.

Original comment by Ice...@gmail.com on 19 Apr 2011 at 9:17

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 19 Apr 2011 at 9:19

[GoogleCodeExporter]

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^

Original comment by bennay...@gmail.com on 19 Apr 2011 at 9:53

[GoogleCodeExporter]

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. 

Original comment by ekeeke31@gmail.com on 19 Apr 2011 at 10:18

[GoogleCodeExporter]

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? 

Original comment by Chrono...@gmail.com on 21 Apr 2011 at 1:07

[GoogleCodeExporter]

Isn't it just a port of Gens?

Original comment by kingofch...@gmail.com on 21 Apr 2011 at 4:06

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 21 Apr 2011 at 6:30

[GoogleCodeExporter]

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.

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

(Notice the green planet)

Thanks.

Original comment by thiagoalvesdealmeida@gmail.com on 26 Apr 2011 at 10:07

[GoogleCodeExporter]

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.

Original comment by bennay...@gmail.com on 27 Apr 2011 at 2:25

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 27 Apr 2011 at 6:09

[GoogleCodeExporter]

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).

Original comment by thiagoalvesdealmeida@gmail.com on 27 Apr 2011 at 3:38

[GoogleCodeExporter]

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, 

Original comment by ekeeke31@gmail.com on 27 Apr 2011 at 6:46

[GoogleCodeExporter]

> 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. ;)

Original comment by kingofch...@gmail.com on 28 Apr 2011 at 12:26

[GoogleCodeExporter]

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?

Original comment by thiagoalvesdealmeida@gmail.com on 28 Apr 2011 at 4:15

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 28 Apr 2011 at 8:59

[GoogleCodeExporter]

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

Original comment by thiagoalvesdealmeida@gmail.com on 28 Apr 2011 at 6:53

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 28 Apr 2011 at 7:02

[GoogleCodeExporter]

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

Original comment by thiagoalvesdealmeida@gmail.com on 28 Apr 2011 at 11:47

[GoogleCodeExporter]

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

Original comment by kingofch...@gmail.com on 28 Apr 2011 at 11:48

[GoogleCodeExporter]

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 ? 

Original comment by ekeeke31@gmail.com on 29 Apr 2011 at 10:15

[GoogleCodeExporter]

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.

Original comment by kingofch...@gmail.com on 29 Apr 2011 at 4:44

[GoogleCodeExporter]

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

Original comment by bennay...@gmail.com on 20 Aug 2011 at 1:47

[GoogleCodeExporter]

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

Original comment by ekeeke31@gmail.com on 20 Aug 2011 at 1:58

[GoogleCodeExporter]

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.

Original comment by bennay...@gmail.com on 20 Aug 2011 at 3:55

[GoogleCodeExporter]

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...

Original comment by ekeeke31@gmail.com on 20 Aug 2011 at 4:20

[GoogleCodeExporter]

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*.

Original comment by bennay...@gmail.com on 3 Sep 2011 at 3:14

[GoogleCodeExporter]

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.

Original comment by kingofch...@gmail.com on 3 Sep 2011 at 4:12