(This post is missing and can not be restored)

(This post is missing and can not be restored)

(This post is missing and can not be restored)

(This post is missing and can not be restored)

(This post is missing and can not be restored)

(This post is missing and can not be restored)

(This post is missing and can not be restored)

(This post is missing and can not be restored)

This was going to be a response on the Sonic Gems Collection thread, but as it got longer I figured it would be better of as its own thread, and could even apply to other discussions.

Short story, it's possible for a faithful version of almost ANY game to run flawlessly on another system. In the case of Sonic CD, Chaotix, Sonic R, and SSA to run well on any of the Big 3. It just isn't easy, and this thread exlains why.

+First is a crash course in how computers (game consoles) work.
+Second is an explanaiton of how Emulation works.
+Third is an explanation of what a Port is.
+Last is some info on the differences and conflicts between different hardware, and how it applies to puting older games (Sonic CD} on newer platforms (Gamecube).

First, let me see if I can't ease the "portability" debate, somewhat.

While I'm not the biggest expert on porting games and the hardware of each system I have a good understanding of the basics. I'll try to explain things and help calm some of the arguments.

*Hardware 101*

1) The heart (brain, actually) of ANY game machine (computer) is the Processor. In theory, it's the only thing garunteed to be in every console. It's also usally the biggest problem spot for porting software. Because each processor is designed slightly different, the code ultimately has to be written so that the processor can understand it.

2) Next is Memory. Generally any data not in the processor, is in the memory. Memory comes in two forms:
-static memory (Read Only Mechanism, or ROM): usually a permanant set of instructions or data that can only be read/copied. In most cases it cannot be changed or deleted within the normal functions of the computer (Re-Writable discs being an exception). Also, in most cases ROM must be read in the same order it was written.

-dynamic memory (Random Access Memory, or RAM): generally, data that can be easily read written and erased instantaneously and in any order. Because different kinds of RAM have different ways of managing the stored data, many problems occur here also.

The differences between each kind of RAM and ROM create the second biggest porting issue.

**Emulation**

*I'm going to get less technical from this point on, and try to use examples for those confused by everything above.*

The biggest problem with transfering software from one system to another revolves around the way the processor and the memory interact with each-other. We'll compare a processor to a person, and memory to language/books.

Most on the board probably speak only one language fluently (some form of English). You can read any book, and talk to any person as long as they are written in/speak English. You'd have a hard time reading or speaking Japanese (or any language) without any knowlege beforehand.

Processors work the same way: they can only read and interpret data that was designed for them. Anything else will either be ignored or miscalculated.

It is possible for us to learn Japanese, but in most cases it is more efficient to translate it into English and work with it in our native language. --"native" is a term for data desigend for that piece of hardware--

Again, processors could be physically modified to undestand different data, but it's usually easier to make the foreign data readable some other way. This is where emulation and porting come in.

Emulation is like reading a book (game) written in Japanese with a Japanese/English dictionary (emulation program) next to you. You would have to take each J-word (byte of data), find the E-word that matches, read it, and understand it. With this method you have to convert each and every word one at a time. You could make it a bit easier to understand if you write each converted word down in a notebook (RAM) and erase errors as you go along, and read parts of it at a time. This way you read the book (game) somewhat sooner, but the process is longer and requires you to use more effort. If the dictionary (emulator) is a cheap one, or doesn't explain the language correctly you might still have trouble reading what you converted.

Emulators work the same way (virtual machines are similar, but not exactly the same). An emulation program tells processor A how to read data designed for processor B. This way, processor A acts just like (emulates) processor B. Because processor A has to calculate each piece of data at least twice (once to translate, and again to understand) it takes more work for processor A than it did for processor B. Often processor A would have to be almost TWICE as fast as processor B to run the same program at the same rate. In additiion the emulator might not know how to convert everything, resulting in a glitch here and there.

*Porting*

Porting software is redesigning (or completly re-writing!) software so that it will work on a different platform.

Going back to the Person/Book analogy, porting a game works much like translating a book--Manga, to make things more interesting--from Japanese to English. The entire book (game) is analized, translated, and re-written so that an English speaker can understand it. Some things might be changed or lost in the process depending on how it was translated and how much effort was used. Many parts, like the art, can be re-used as-is in the translation--but all of the text is changed. Sometimes things are added to the English version that wouldn't work in the original Japanese. Sometimes things have to be left out for some reason or another.

Again, porting works much the same way. Any part than can be easily converted between platforms usually translatess easily, but most of the code and data written for platform A doesn't convert easily to platform B. In this case alot of bulk data can be converted by a program, but the more hardware speciffic code has to (often painstakingly) be re-written or altered so that it works with platform B. This involves lots of bug squashing, attention to detail, and hard work to get the port to the same quality level as the original--especially between systems with different architecture. In downward porting (Arcade to NES) the essential parts are converted and simplified, while the less necessary bits are discarded.

************************************************
What the hell does this have to do with Sonic CD?
*********************************************

Everything above pretty much delt with one data source and one processor, but in reality most game hardware is designed differently.

The Sega Genesis (Mega Drive) had two processors: one for general data and graphics, and one for music (MP3s and CDs were still new technology, so a MIDI processor was used). It also had two main memory sources: internal RAM (much like regular PC RAM) and external ROM - the cartridge (there is also a tiny bit of internal ROM to start the system, but beyond that it doesn't do much).

Cartrige ---~~> Processor(s) <---~~> RAM

Above is the basic structure of how the data flows. Information is taken from the cartridge, processeed as images, data or music, and sent back and forth between the RAM as its needed.

This set-up is simple and very easy to set up an Emulation scheme for. Other classic consoles (Super NES and earlier) worked much the same way. Because of the way cartridges were set up, extra hardware chips, and even RAM memory could be added to the cartridge, an essentially create new data "on the fly" for the processors to read. For t hese games, the additional parts have to be simulated or emulated also to work properly. And even though CD-based media is slower and less eficcient than cartridges, Genesis games are small enough to fit entirely within the RAM of the BIG 3 many, many times over.

Sega CD (Mega CD) was a more complicated beast. CDs are capable of holding tons more data than even most cartridge-based mediums today. By replacing the cartridge with the CD, the basic formula doesn't change much:

CD-ROM ---~~> Processor(s) <-----RAM

But the above only works for pure data. Also, because CD's have no electrical components, they can't simply feed data to the processor. Instead it has to be read (laser}, interpreted (processed}, and then sent along. The processor needs its own set of instructions to convert the laser reflections into data (Called a BIOS--the same concept of the Genesis internal ROM, but more complex and with more instructions). The Genesis is also incapable of CD audio as well, so the Sega CD has a seperate component to handle that also, plus any other CD related improvements the Genesis wasn't designed for. While they were at it, and then Sega decided to add to the MIDI capabilities of the system too. In order for the audio to be processed correctly the sound produced by the Genesis sound chip was routed though the Sega CD and layered with the sound produced by the Sega CD's processor and music chip. Finally Sega CD also had an internal save system (RAM) that could also be stored on an external source (it looked like a Genesis cart). The final layout is alot more complicated than the last one (and a @#%$ to illustrate using ASCII )

CD -> Laser -> Reader -> A
A: B <~~> CD Processor <~~> CD Active RAM <~~> CD Sound Chip <-- Genesis Sound Chip
B: Genesis Processor <~~> Genesis RAM ~~> Cart Backup RAM ~~> CD Backup RAM <-- A

So to simulate a Sega CD environment you have to emulate 2 PROCESSORS, 2 sets of RAM, 2 SOUND CHIPS, the BACKUP MEMORY, the BIOS SYSTEM and the way they interact and send data to each other.

Plus, (for the big 3) instead of CD audio, MP3-style compression will probably be used so that has to be converted as well. All of this reconverting and reprocessing, even on a hefty system like the Xbox, involves alot of processor power.

*In the case of Sonic CD, since it has already been ported to PC, brining that version to the Xbox shouldn't be a headache. Direct emulation is also possble, though more difficult. In the case of PlayStation and Gamecube, an efficient emulation scheme can eventually be written, just not easily. However, it is possible to REPROGRAM Sonic CD for the PS2 and GCN, especially if Sega still has the original sources for the Sega CD version. Its a matter of changing the program to do with the (relatively) more efficient systems what it took a wacky jumble of hardware to do. And in case you didn't know it is possible to port (completly rewrite/convert} some parts of the software, while emulating (simulating) other parts and still having things come out much like the original. The fact that the Big 3 have more PC-like architecture than older systems also helps conversion/emulation.

Just remember that emulation within the industry is less difficult than outside projects that most of us know of. Much emulation done for "research" has to be done with gueses, speculation, and reverse engineering to find out how the one hardware works and convert it to another. In Sega's case, they BUILT the friggin Sega CD to begin with, and know what makes it tick. It wouldn't be incredibly tough for Sega to work with the hardware deigners of other systems to figure out how to get an Xbox to act like a Sega CD. It isn't super easy, but it's a million times less difficult than the process of developing public emulators. **I saw some posts saying how publicly developed emulators don't work for some hardware--chances are the progress public emulators made is BEHIND what the Industry has, not ahead.

Still want more fun??? I won't go into as much detail since most of what's above applies to the same situation.

Sega Genesis 32X (Super 32X, Sega Mars): I said Sega CD was a beast of a hardware. 32X was a SUPER F---NG BEAST OF A HARDWARE! Kind of...

Like Sega CD, 32X had its own processor, sound chip, and BIOS in addition to what the Genesis had.

I don't know exactly how the Genesis and the 32X became a 32 bit system, but I do know that the 32X had a pass-through mechanism that bypassed the 32X hardware and just used the Genesis as if it was by itself (for regular Genesis games). I also know that the 32X could take the video data from the Genesis and either re-process it, or overlay new image data on streaming data.

In the case of a Sega CD 32X game, the sound would be routed twice, from Genesis to CD and from Genesis/CD to 32X.

The visuals would also come frome two seperate sources--the 32X/Genesis and Sega CD--and combine them.

Finally, with the complete Sega 32X CD System, you have 3 Processors, 3 Sound Chips, 3 sets of RAM that have to work with each other.

Sega Saturn isn't as crazy as the 32x CD, but has similar problems. I forget what did what, but I know Sega Saturn had 3 different processors, and two sets of ram (a small ammount for video, and a large ammount for data). Programming the 3 processors to operate cooperativey was supposedly difficult by itsellf, and coordinating them with the RAM only made things worse. Mathematically, the Sega Saturn was more capable than the PS1, but the overall designn killed any superiority Saturn might have had.

If you reached this point of the post, get yourself a cookie for reading all this and possibly educating yourself. Now go outside, and find fresh air! Oh, and thanks for reading...