Porting Geny/MD games to sega cd/mega cd

Now i just had a great idea, i dont know if its possible or that has already been made, we all know how easy is to make custom soundtracks for games like sonic cd, but how cool it would be on porting games like sonic and knuckles or musha, into the sega cd/mega cd, what im saying is that we keep the game intact, exept on the soundtracks, and replace them with awesome, digital sound remixes, now i dont even know if this is possible, and if it is it would be necessary a genious in programing, but you got to admit it would be awesome.

It's possible. I think it is technically possible to port every Mega Drive game to the Mega CD as long as each loaded level fits within 512KB RAM, sure. You could load an entire Sonic 1 game at once to it seen as that is also 512KB in size. You could even add enhancements due to the increase in processing power (12.5Mhz M68k vs MD's 7.6Mhz M68k) and scaling and rotational effects ala mode 7 on SNES games.

It's possible, It doesn't really take much to port an existing Mega Drive game towards the Mega CD as they both share the same hardware together, but never that much tried unfortunately. It only got a handful of Mega CD enhancements like the MCD version of Earthworm Jim with an extra level and Redbook Audio, alot of the MCDs library is basically shovelware FMVs.

what about access times etc? Im pretty sure the Mega CD does things the Gens doesnt and visa versa. I think it would work with some exstensive modifications to the binary and even then I think some things would go askew.

we need a decent 16-bit programmer/homebrew dev to come answer.

would be sweet though, but I think it would be damn hard to even get Sonic 1 running.

Quote:

---

Originally Posted by 64k

what about access times etc? Im pretty sure the Mega CD does things the Gens does and visa versa. I think it would work with some exstensive modifications to the binary and even then I think some things would go askew.

we need a decent 16-bit programmer/homebrew dev to come answer.

would be sweet though, but I think it would be damn hard to even get Sonic 1 running.

---

Yes access time is extremely slow, you can't load anything on-the-fly. Thats why you load all of one level each in the MCD's 512K of RAM instead of streaming everything on-the-fly like your usual MD game. Thats one part of the programming that needs changing to port a MD title over. Think of the MCD's RAM as the cartridge.

yeah I see what you saying by storing it all on local RAM, tis a clever idea, im thinking of games also which require bank switching etc or those fangled 24meg carts etc, then freeing up the necessary system ram whilst keeping the system from choking, audio processor differences would be another?

how similar is the chip to the Gens sound chip or could that be done through the genesis alone but sonic with redbook audio would be nice.

then also implementing the new graphic routines/processes running through the MegaCD.

damn, id really like to know how easy it would be too do.

im pondering how it could/couldn't work and how it would etc.

Quote:

---

Originally Posted by 64k

yeah I see what you saying by storing it all on local RAM, tis a clever idea, im thinking of games also which require bank switching etc or those fangled 24meg carts etc, then freeing up the necessary system ram whilst keeping the system from choking, audio processor differences would be another?

---

Carts with bank switching doesn't free up any kind of memory. It just extends the amount of memory an MD game cart can hold over the hardwired 32Meg (4Megabyte) limit the Mega Drive sets. You still have the 64KB limit with the MD alone, or loading one full level segments with the MCD's RAM. Games that use bank-switching simply extends the game itself. For it to work on the MCD would simply require modifying the memory management code within the game. Chilly Willy would probably explain this better.

Quote:

---

Originally Posted by 64k

how similar is the chip to the Gens sound chip or could that be done through the genesis alone but sonic with redbook audio would be nice.

---

The Mega CD's own sound uses a Ricoh sample-based Wavetable sound chip. Very similar to the SNES's Sony SPC700 chip. The Ricoh chip has 8 audio channels is basically more advanced than the MD's own 6 channel FM synth and 4 channel PSG chip. Very different from all each other, but I think you could sync them all up for more richer polyphony. Listen to all the Sonic CD PAST-Music and you can hear the chip itself in action.

Quote:

---

Originally Posted by 64k

then also implementing the new graphic routines/processes running through the MegaCD.

damn, id really like to know how easy it would be too do.

im pondering how it could/couldn't work and how it would etc.

---

When it comes to the colour palette, it wouldn't be any better than stock Mega Drive games. However, you COULD have more action going on on-screen and add some scaling and rotational effects thanks to the more powerful M68k and custom ASIC chip within the MCD.

I admit I would love to program the Mega CD, the Mega Drive AND the 32x to all work in tandem together, but can't lol.

I got the bank switching I mean't what would happen when say the data was needed from a different ROM and the Sega CD would have to allocate a different location from which to grab the data, so I was more talking about software modifications and how would the CD know to get the data from a location on the disk as opposed to a seperate RAM bank? So my concern was;

Say Sonic fits completely into the 512K memory limit eliminating the need to seek and remove access times what would the Mega CD do say if it Sonic 3 came into play and it needed to place say 1024K of data into the Sega CDs RAM? so I interested in what routines would be required or would it completely crap out. How would it know what memory to move and keep?

That alone would confuse the hell out of me, id love to know the answer to this.

I would love to see Megadrive cames make use of the extra routines in the GPU, but surely sprite rotation etc would require a re-write of the game code to take advantage of this? I knows its always going to be 62/64 colours so I image the colour pallattes stay on the same Hex values?

So if you have to completely re-write the game code to take advantage of these schinnadigans you might aswell not bother and just port it as standard?

So the only advantage I can see is the Audio hardware being used, Im pleased to hear you could sync it up and use a richer sound palette to enhance the game this is the only thing in my mind which would make it worth doing.

I would love to see some converstions and how you would implement these features etc or problem solve etc.

Quote:

---

Originally Posted by 64k

I got the bank switching I mean't what would happen when say the data was needed from a different ROM and the Sega CD would have to allocate a different location from which to grab the data, so I was more talking about software modifications and how would the CD know to get the data from a location on the disk as opposed to a seperate RAM bank? So my concern was;

---

I can't exactly understand what you're trying to explain? I guess if you could reword it a bit, I would be able to understand what you mean a little better.

Quote:

---

Originally Posted by 64k

Say Sonic fits completely into the 512K memory limit eliminating the need to seek and remove access times what would the Mega CD do say if it Sonic 3 came into play and it needed to place say 1024K of data into the Sega CDs RAM? so I interested in what routines would be required or would it completely crap out. How would it know what memory to move and keep?

---

Ah, Well, if that 512k of memory is already taken up with a Sonic 1 ROM, theres no more space left to fit. Loading anything more than that will cause the MCD to hang completely. I'm not exactly sure, I think you also need a little MORE RAM to cache the ONSCREEN action. Like the MD games, 64k of RAM and a streaming cartridge. The 512k RAM of the MCD behaves as the cartridge itself without that 64k, so maybe even Sonic 1 is slightly too big in it's existing form. You'd need to chop up the Memory requirements of that game for it to load all into RAM leave at least 64k cache for the onscreen action.

Sonic 3 is 2Megabytes in size and is already far too big to fit exactly everything of that game into RAM at once. Like Sonic CD, you'd have to load ONE whole level segment into the MCDs RAM. Loading times will occur every time you finish an Act. So instead of seamlessly loading into Act 2 like in the MD, the MCD would have to freeze for several seconds to unload Act 1 and load in Act 2.

There is however, another pool of 256k of RAM in the MCD, but that is pretty much used for interfacing with the MD or a storage for the ASIC chip inside. I doubt the M68k itself in the MCD could access that.

Well, I think this should also answer your first quoted question hopefully, the more low-level techies would probably word it a little better than I can.

Quote:

---

Originally Posted by 64k

I would love to see Megadrive cames make use of the extra routines in the GPU, but surely sprite rotation etc would require a re-write of the game code to take advantage of this? I knows its always going to be 62/64 colours so I image the colour pallattes stay on the same Hex values?

---

Yes, the colour palette will stay the same exactly. The MCD itself doesn't have it's own VDP chip, just an extra custom chip that allows for scaling and rotation FX, ala Mode 7. Literally all the graphics you see on a MCD game uses the same existing VDP within the MD itself.

Quote:

---

Originally Posted by 64k

So if you have to completely re-write the game code to take advantage of these schinnadigans you might aswell not bother and just port it as standard?

---

Not necessarily, if you have the Sourcecode, or some crazyarse assembly hacking skills, you could add some additional scaling sprites to say, Sonic 3 & Knuckles using the ASIC chip within the MCD. Fpr example, Knuckles Chaotix primarily uses said MD VDP for the majority of it's graphics. The sprites and 3D special stages are done on the 32bit CPUs onboard the 32x in software.

Quote:

---

Originally Posted by 64k

So the only advantage I can see is the Audio hardware being used, Im pleased to hear you could sync it up and use a richer sound palette to enhance the game this is the only thing in my mind which would make it worth doing.

---

That alone is a very nice upgrade for Mega Drive games. It could even serve as an alternative for music generation than the Redbook CD Audio. 18 Sound channels in total when you sync up the CD, and the two MD sound chips together.

I admit, I would rather hear music compositions via those 3 chips synced together than Redbook Audio. Blows the SNES' Sound chip out the water when all those 3 are used together. :nod:

Quote:

---

Originally Posted by 64k

I would love to see some converstions and how you would implement these features etc or problem solve etc.

---

I also wish more MD games received MCD enhancements, but the ones that did didn't really take much advantage of the MCD. Half-Arsed should I say. Such wasted potential. I believe the MCD is a powerful system itself. CPU itself being 500Khz faster than even the Neo Geo's!

Hopefully we receive a CD port of Wolfenstein 3D when Chilly Willy gets around to doing it! He's currently working on a 32x version. Just goes to show how powerful the MCD was.

Quote:

---

Originally Posted by Jasper061992

I can't exactly understand what you're trying to explain? I guess if you could reword it a bit, I would be able to understand what you mean a little better.

---

Its coolio, you explained it after the second quote.

But I dig what your saying about it being a powerful piece o' kit! seems vastly underused at the time and just went to waste, shame they couldn't of adjusted the colour palette so we had more sparkly colours! but I think towards the end of the 16-bits lifes they did start pulling off some impressive games (Rista etc)

But it seemed the MegaCD just lacked that killer app, yeah Sonic CD was alright but they didn't keep the mementom going, and think of how goooood some of the later arcade ports could of been! instead we were bombarded with FMV games of which some were alreet, but others blew chunks.

Would be nice also to see Some games running on the MEGA CD with no slow down too and better audio, would make interesting homebrew games.

cheers for the info man, learn't some stuffs.

Quote:

---

Originally Posted by Jasper061992

It's possible. I think it is technically possible to port every Mega Drive game to the Mega CD as long as each loaded level fits within 512KB RAM, sure. You could load an entire Sonic 1 game at once to it seen as that is also 512KB in size. You could even add enhancements due to the increase in processing power (12.5Mhz M68k vs MD's 7.6Mhz M68k) and scaling and rotational effects ala mode 7 on SNES games.

---

You have the CD 68k as well as the Genesis 68k to work with. Fonzie once mentioned you could probably manage 3D about 3x as fast with that set-up than the MD alone.
The MCD ASIC is MUCH more flexible than Mode 7, though it can replicate similar effects, it isn't limited to a single tile (I think Mode 7 can use up to 2), and it doesn't disable the MD's BG modes. It can render on any tile layer of the Genesis (Sprites, BG1, BG2) and can do straight scaling as well as scaling/rotation/warping (which is basically affine texture rendering -I believe Mode 7 is as well). I think it's also capable of drawing spans (vector lines) to plotted points, not rasterizing polygons, just drawing lines. (I think Starblade used that)

However, it's hindered by the Genesis VDP's DMA limitations and VRAM size, hence why most such effects rarely exceed 20 fps, and more often around 15 FPS. (I think BC racers managed 24 FPS NTSC) PAL is much less limited by comparison due to the much greater number of VBLANK lines pr frame.

Quote:

---

It's possible, It doesn't really take much to port an existing Mega Drive game towards the Mega CD as they both share the same hardware together, but never that much tried unfortunately. It only got a handful of Mega CD enhancements like the MCD version of Earthworm Jim with an extra level and Redbook Audio, alot of the MCDs library is basically shovelware FMVs.

---

iirc it's a rather big PITA to convert MD games to MCD due to the rather different way the games work on the MCD, I believe this came up in some other threads, mainly for game that exceed 512 kB or maybe 768 kB. (I think someone's been working on an application to convert 512 kB games to MCD though)

Modifying the software to support CD audio is another issue.

please go into further deph, tres interesting.

like what would happen if you attempted/converted a multi ROM game for CD? how would you go about trying it?

how could you adjust the audio?

how different are the two machines from one another?

tellll meee please :)

You cannot just convert a ROM to use on MD... it would require a great deal of hacking etc. since the MD side seens MCD side though a 256Kbyte window (plus control registers), and in a different location than cart area (which is occupied by MCD BIOS).
You either make something from scratch for MCD or spend a great deal of time disassembling and documenting a game you want to convert for MCD... making a new game is certainly more pleasant and faster.

Quote:

---

Originally Posted by TmEE

You cannot just convert a ROM to use on MD.

---

Thought as much, just wanted to know why..so it is literally down to memory mapping and address spaces etc?

That, and you also need something on MCD side that will show right pieces to MD side, since MD has no real control over MCD side.

Quote:

---

Originally Posted by TmEE

You cannot just convert a ROM to use on MD... it would require a great deal of hacking etc. since the MD side seens MCD side though a 256Kbyte window (plus control registers), and in a different location than cart area (which is occupied by MCD BIOS).
You either make something from scratch for MCD or spend a great deal of time disassembling and documenting a game you want to convert for MCD... making a new game is certainly more pleasant and faster.

---

Well, I did state (for the devs with the source code) it would take several modifications to get the game to work in CD format. For us, it would certainly take some serious hacking to convert to CD.

That being said, I have a burned copy of Sonic Megamix. It's based on the Sonic 1 code right? Even the betas of Sonic Megamix was in ROM form. They certainly did a good job of converting it to a CD based title.

But one thing puzzles me. You still get those slowdowns when crashing through breakable walls. Is Megamix still using the MD's M68k?

Quote:

---

Originally Posted by kool kitty89

You have the CD 68k as well as the Genesis 68k to work with.

---

Can they both be paralleled to work together for executing the same code? I know the MD doesn't have direct access to the MCD's 512k RAM (I think), but can program code be temperally held within the 256k word RAM during back and forth data transfer? If so, could the 64k RAM join them for program code? You know, with very creative programming? I'm even about to ask, can the Z80 with it's 8KB RAM be of any use other than a sound controller for this process? I also want to know more of this!

Quote:

---

Originally Posted by kool kitty89

However, it's hindered by the Genesis VDP's DMA limitations and VRAM size, hence why most such effects rarely exceed 20 fps, and more often around 15 FPS. (I think BC racers managed 24 FPS NTSC) PAL is much less limited by comparison due to the much greater number of VBLANK lines pr frame.

---

Well if true, 24fps isn't bad considering said limitations of the VDP. I'm looking to get BC Racers next up for my MCD.

Sonic games got fully disassembled and reverse engineered disassemblies so making a CD game is not that difficult.

S1MM is probably running a good chunk on the MD 68K. The game is not having its extras handled in the most effective manner so slowdown is inevitable... you cannot overclock either since MCD hates it and it uses 68K SMPS for music and that makes sound funny when overclocked...

I was playing that the other day, you can tell its really only using the MDs hardware due to the usual slow down in places that well slowed down on the origional.

however till fun, even if its crash happy.

Quote:

---

Originally Posted by TmEE

You cannot just convert a ROM to use on MD... it would require a great deal of hacking etc. since the MD side seens MCD side though a 256Kbyte window (plus control registers), and in a different location than cart area (which is occupied by MCD BIOS).
You either make something from scratch for MCD or spend a great deal of time disassembling and documenting a game you want to convert for MCD... making a new game is certainly more pleasant and faster.

---

Hmm, I thought there were only 17 address lines on the expansion port (128 kB address space).

Quote:

---

Originally Posted by Jasper061992

But one thing puzzles me. You still get those slowdowns when crashing through breakable walls. Is Megamix still using the MD's M68k?

---

I think most/all MCD titles have to use the 68k to some degree (it's the main way to interface with the Genesis -I think there's some DMA too). Some might use it minimally, but I think more use it substancially, probably more often neglecting the CD's 68k than the Genny's. (given the number of ports)

Quote:

---

Can they both be paralleled to work together for executing the same code? I know the MD doesn't have direct access to the MCD's 512k RAM (I think), but can program code be temperally held within the 256k word RAM during back and forth data transfer? If so, could the 64k RAM join them for program code? You know, with very creative programming? I'm even about to ask, can the Z80 with it's 8KB RAM be of any use other than a sound controller for this process? I also want to know more of this!

---

I think they need to be used for different tasks, but can work in parallel, at least to a significant degree. (ie one isn't always halted when th eother is working) They work in separate bans of RAM and communicate through the 256 kB of word RAM. (RAm can be configured in different ways too though, one being to use bank switching to give the entire 768 kB for the Genesis to access)

Quote:

---

Well if true, 24fps isn't bad considering said limitations of the VDP. I'm looking to get BC Racers next up for my MCD.

---

It definitely does in fusion (other games range from 15-20 FPS in NTSC), it;s a little weird set-up using 2 updates per 5 frames. Remember that there's a TON of clipping done (increasing DMA time) as well as a rather large status bar and boarder. (and there's no split screen multiplayer unfortunately)

I think AH-3 Thunderstrike uses the largest display window for a continuous ASIC generated display on the CD, I think that's at either 20 or 15 FPS.



I do wonder why most games used the 256 wide mode rather than 320 given that 320 provides proportionally higher DMA bandwidth, so similar framerates and screen sizes for higher resolution (assuming the ASIC rendering speed was not a limiting factor), though I'd imagine limited VRAM space would be a contributing factor there.

Quote:

---

Originally Posted by kool kitty89

I think most/all MCD titles have to use the 68k to some degree (it's the main way to interface with the Genesis -I think there's some DMA too). Some might use it minimally, but I think more use it substancially, probably more often neglecting the CD's 68k than the Genny's. (given the number of ports.

---

I guess I can understand that.

Quote:

---

Originally Posted by kool kitty89

I think they need to be used for different tasks, but can work in parallel, at least to a significant degree. (ie one isn't always halted when th eother is working) They work in separate bans of RAM and communicate through the 256 kB of word RAM. (RAm can be configured in different ways too though, one being to use bank switching to give the entire 768 kB for the Genesis to access)

---

Thats pretty smart. So you could have a Mega CD game that consumes just about the entire 768KB, right? Thats nearly a Megabyte if true! So does that mean you could load say for example, for the first 512KB RAM, a massive level, then load the other part of said in the 256KB RAM? Is that where the bank switching takes place? Or is it vice versa?

Quote:

---

Originally Posted by kool kitty89

It definitely does in fusion (other games range from 15-20 FPS in NTSC), it;s a little weird set-up using 2 updates per 5 frames. Remember that there's a TON of clipping done (increasing DMA time) as well as a rather large status bar and boarder. (and there's no split screen multiplayer unfortunately)

---

I think AH-3 Thunderstrike uses the largest display window for a continuous ASIC generated display on the CD, I think that's at either 20 or 15 FPS.

20fps is still good though. ;)

Quote:

---

Originally Posted by kool kitty89

I do wonder why most games used the 256 wide mode rather than 320 given that 320 provides proportionally higher DMA bandwidth, so similar framerates and screen sizes for higher resolution (assuming the ASIC rendering speed was not a limiting factor), though I'd imagine limited VRAM space would be a contributing factor there.

---

VRAM could well be the culprit. What COULD have been nice was if Sega waited and released the Mega CD in late 1994 instead with the 2 32x CPUs instead of the M68k, and 1.5MB RAM with 512k for interfacing with the MD. leaving out the ASIC chip to reduce costs. But adding it's own framebuffer and those wretched cables at the back to overlay the VDP graphics, just like the 32x did. Am I missing something or would that have been a better idea? ;)

Quote:

---

Originally Posted by Jasper061992

The Mega CD's own sound uses a Ricoh sample-based Wavetable sound chip. Very similar to the SNES's Sony SPC700 chip. The Ricoh chip has 8 audio channels is basically more advanced than the MD's own 6 channel FM synth and 4 channel PSG chip. Very different from all each other, but I think you could sync them all up for more richer polyphony. Listen to all the Sonic CD PAST-Music and you can hear the chip itself in action.

---

Shadowrun uses both chips simultaneously. Try playing it under emulation and then disable the FM or PCM sound.

Even FMV games like Sewer Shark use both PCM and the Genesis chips. In fact, Sewer Shark uses the "periodic noise" feature on the PSG for some of their songs.

Quote:

---

Originally Posted by Jasper061992

The Mega CD's own sound uses a Ricoh sample-based Wavetable sound chip. Very similar to the SNES's Sony SPC700 chip. The Ricoh chip has 8 audio channels is basically more advanced than the MD's own 6 channel FM synth and 4 channel PSG chip. Very different from all each other, but I think you could sync them all up for more richer polyphony. Listen to all the Sonic CD PAST-Music and you can hear the chip itself in action.

---

Doing such for hacked games would be tougher than rebook audio though, which might be tougher than using the MD sound hardware. (depending on how much RAM the samples take up for the MD and how easy gettign the sound engine to work would be; Megamix seems to have done that well though)

Quote:

---

Originally Posted by sasuke

Even FMV games like Sewer Shark use both PCM and the Genesis chips. In fact, Sewer Shark uses the "periodic noise" feature on the PSG for some of their songs.

---

Yes, in fact, a few such games seem to ignore the PCM chip for the most part, like Sewer Shark and Nova Storm. (I think some of the SFX might even be done with the YM2612 DAC rather than the PCM chip given the poor quality)

FMV games have to rely more on realtime sound due to the CD being dedicated to streaming video. (and not wanting to sacrifice data for streaming audio, or CPU resource for decompression in-game -not cutscenes)

Silpheed is probably the Best example of MD+MCD sound hardware working together: note the FM Towns and Sega System 18/32 used a similar set-up with the YM2612 (2x in the 18/32) and Ricoh PCM chip.

Quote:

---

Originally Posted by Jasper061992

Thats pretty smart. So you could have a Mega CD game that consumes just about the entire 768KB, right? Thats nearly a Megabyte if true! So does that mean you could load say for example, for the first 512KB RAM, a massive level, then load the other part of said in the 256KB RAM? Is that where the bank switching takes place? Or is it vice versa?

---

You need to have the game support management of the banks, hence simple ports of games relying on >256 kB flat mapped memory aren't possible.

Quote:

---

VRAM could well be the culprit. What COULD have been nice was if Sega waited and released the Mega CD in late 1994 instead with the 2 32x CPUs instead of the M68k, and 1.5MB RAM with 512k for interfacing with the MD. leaving out the ASIC chip to reduce costs. But adding it's own framebuffer and those wretched cables at the back to overlay the VDP graphics, just like the 32x did. Am I missing something or would that have been a better idea? ;)

---

They COULD have still done that as a follow on to the Sega CD with backwards compatibility modes as well, that's the premise of a proposition made by Chilly Willy here:
http://sega-16.com/forum/showthread.php?t=8497&page=3
and cropping up again recently here: http://sega-16.com/forum/showthread.php?t=10761&page=5

OTOH, they could have had a top mounted Sega CD and supported video expansion a la 32x. (exp port lacks necessary connection the cart has)

Quote:

---

Originally Posted by kool kitty89

Hmm, I thought there were only 17 address lines on the expansion port (128 kB address space).

---

but on a 16bit bus ^^

Quote:

---

Originally Posted by TmEE

but on a 16bit bus ^^

---

XD duh! Same thing with the cart slot only having 23 address lines (as well as the 68k its self, plus byte select lines), I should have remembered that, ;)

This thread has already been done before!

http://www.sega-16.com/forum/showthread.php?t=9008

Quote:

---

Originally Posted by Da_Shocker

This thread has already been done before!

http://www.sega-16.com/forum/showthread.php?t=9008

---

Yeah, that thread did come to mind when I saw this one.