the sega genesis talks to both peripherals in two different ways. The sega genesis firstly can address 4Mbits of ROM through the cart ports. In actuality, the genesis has TWO cartridge ports, one on the top, and one on the side, which is gender swapped:
The Sega CD is thus seen by the Genesis as a large cartridge attached to the system, except while the Genesis sees the Sega CD as a large chunk of ROM - read only memory -- the addressed data port space on the Sega CD is actually RAM - memory the Sega CD can write to. The Sega CD has two modes of addressing available, one that lets the Genesis see the Sega CD as one giant 256 Kb chunk of memory at once, which only the Genesis or Sega CD can access one at a time, or as two 128 Kb chunks of memory, which can be swapped around. In this dual 128Kb mode, the genesis can access one 128 Kb chunk of memory at the same time the Sega CD can access the other 128 Kb chunk of memory, allowing them to be used like a frame buffer.
The Sega CD itself lacks any sort of hardware to draw to the screen, all drawing is done via the Sega Genesis. Despite this, the Sega CD is almost entirely it's own console otherwise. It has it's own, independently running 68000 CPU -- clocked faster than the Sega Genesis CPU -- it's own RAM, and loads of custom sample based audio hardware more in line with the SNES than the Genesis. It also includes an ASIC chip for fast 3D math, which lets the Sega CD perform hardware scaling and rotation on sets of sprites and tiles. Despite this, because the Sega CD has to use the Genesis to actually draw it's skewed and stretched art, a bottleneck emerges when the Sega CD has to quickly put tiles into the Genesis VRAM; the process is that the Sega CD must internally update some tiles in it's own RAM first using the ASIC, then move them to one of the 128Kb buffers, then swap buffers so the Genesis can see them, then wait for Vblank to DMA a large chunk of tiles from ROM to VRAM. This is why, for example, the special stages in Sonic CD are at a much lower framerate than, say, Super Mario Kart.
The 32X, by contrast, is basically a frame buffer and a
Gen Lock running on top of the Genesis. the 32X has it's own completely independent graphics system from the Genesis. Rather than using 8x8 tiles and sprites to draw images on the 32X, the 32X presents the programmer with 2
Direct Color frame buffers which can be configured in memory. There are a few color modes available to the the 32X, including an indexed 256 color palette mode, and a 16 bit per pixel color mode. The benefit of a direct color Frame buffer is that individuals pixels can be plotted on the screen arbitrarily, allowing for things like 3D polygons to be rendered. The 32X also has a hardware fill function, which lets it fill arbitrary areas of memory with solid color (or patterns) which is useful for rasterizing polygons beyond the wireframe.
The 32X interacts with the genesis in a pretty hands off way. the Genesis underneath the 32X runs basically independently of the 32X. where they communicate is in the cartridge, which is addressed by both the 32X and the Sega Genesis. The space in the cart addressed by the Genesis runs 68000 code, and the space in the cart addressed by the 32X runs SH2 code. The limits of the interaction between the 32X and Genesis is basicaly the 32X using the Genesis' controller ports to poll, and the genesis feeding its own video stream externally back into the 32X using a cable. Comparing this again to a Gen Lock, the 32X thusly essentially has two ports -- a video out port that goes to the television, and a video
IN port that takes video from the Genesis. This video-in port will take a full frame from the genesis, which gets treated like an independent background layer on the 32X. thus, 32X elements can either appear entirely behind or entirely in front of Genesis graphics, but can't intermingle. You can't, for example, have 32X elements appearing in between layers of a Genesis background. One problem with the 32X -- plotting pixels directly through the CPUs is a bit too much for the 32X to handle every single frame. Games that try to use the 32X to draw every frame entirely in the CPU wind up running at 30 FPS because doing so at 60 FPS is too slow. The Genesis, by comparison, has dedicated tile-based hardware designed to draw backgrounds at 60 FPS, and thus a common use for 32X games is to have high quality "sprite" elements with lots of colors, while letting the Genesis draw the backgrounds at 60 FPS to make the games run fast.
Now, with regards to the 32X and Sega CD, the 32X sees the Sega CD through the shared memory addressed in the cart space. In practice, all* 32X Sega CD games merely used the 32X to output more colors on screen for better full motion video, something the Sega CD could have technically done using Blast Processing on the Sega Genesis. Despite that, it's possible to write a 32X program that can still access and take advantage of the Sega CD and it's AISC like any other genesis game; it's just that doing so is redundant. It's faster to do 3D math entirely on the 32X rather than relying on the AISC due to the memory bottlenecks.
this brings us to a feature of the Sega CD that was never used in any retail game: Mode 1. Mode 1 is a boot mode from the Sega CD where the Genesis boots from a cartridge, but still can address the Sega CD's 128Kb shared memory and thus can access the hardware. This is basically a way for a cart game to access the AISC and sample based sound hardware, without accessing the actual CD ROM drive. Again, no games ever used this mode, because why would you make a game that ran on cart but required the CD hardware to run? CDs were cheaper to produce than carts and contained more space.
*Pier Solar is also technically a 32X CD game, although it uses the hardware in very different ways. Pier Solar doesn't use redbook audio, but rather streaming PCM to send super high quality audio to be played in real time. It can also detect that a 32X is present and will plant small easter eggs in the game if a 32X is present, but otherwise does not use the 32X hardware at all.
