Sega Mega Drive vs TG-16 Graphics chips

[kool kitty89]

I think the real reason is that shooters don't really require a tile layer for anything other than eye candy. You can pull off cool looking parallax effects cheaply with only one tile layer, but not if you also want to have a foreground layer for the character to run and jump on, like you'd need in a platformer. Especially if this is a platformer with 360º scrolling, like Sonic.

Do you mean linescroll? (ie rows of graphics at different speeds)

That's not what's being discussed abover, that's just line/row scroll and not intensive at all. (you can do it on a more limited basis for columns as well on some systems)

What IS being discussed is simulation of FULL separate BG layers (ie a plane sliding over/under another, not 2 rows/columns sliding past eachother).

Gate of Thunder is showing the true simulation of a 2nd BG plane with tricks using dynamic tiling (animation and tilemap manipulation) to effectively allow software scrolling, but not in the bitmap/CPU/blitter sense. (you might have the CPU rendering some tile animation beforehand to reduce ROM size, but probably not truly "on the fly" -ie it may be done in game as periodic updates, but probably not realtime CPU rendering)


There's even examples of this on 3rd gen systems (and possibly some 2nd gen -I wouldn't be surprised if some home computers did it, some would have needed to do it for just managing 1 layer smooth scrolled -like the MSX- let alone 2)

Metal Storm is a good example on the NES using a simulated scoll plane (not linescroll based "parallax" but plane/layer type parallax).


http://www.youtube.com/watch?v=wCyDzwh37OQ



Hydrocity uses it in some parts of the BG too:
http://www.youtube.com/watch?v=Aez3k...fmt=18#t=2m44s

(pay attention from 2:44 onward, or use the link to skip there)


I think Android Assault might use it in some stages too. (remember seeing it in a review a while back)


All cases tend to only push the effect horizontally, vertical scroll scrolls everything as one layer. (or one layer for the BG plane the effect is used on in the MD's case)









Hmm, actually, maybe I overlooked something: does either the MD or PCE allow per-tile offsets for horizontal scrolling? (ie could you have 2 different areas on the same scanline scrolling at different rates?) That would make it even easier to manage. (I think the SNES's mode 2 supports that, but I'm not sure about the other 2 consoles -the SNES rarely seems to take advantage of it too for that matter even though many games opt for mode 2 over mode 1 with the added 4 color tile layer)
That's the sort of thing that PCE games with a boarder (like various PC98/88 ports) have to deal with as well as they retain a static boarder around a scrolling BG all on one plane. (so if there's no hardware per-tile offset or some form of horizontal segmentation of scrolling, that would need to use software assisted tricks to pull off with dynamic tiling alone)


I just played around with the layers in Panorama Cotton, and it seems to be using a ton of dynamic tiling and similar effects, the title screen is ALL one BG layer! (everything but cotton's sprite and the japnese text; the english COTTON letters, boarder, and scrolling window are all on plane A, plane B is totally unused)
That game has even more cool tricks used that aren't noticeable on the surface. (I's have assumed 2 tilemaps were used)

[Kamahl]

Yeeesh... lots of talk while I was gone... no way I'm reading all of that.

@Chili Willy
There's nothing in a shooter that requires a lot of processing power besides collision detection, it's the collision detection that's the problem.

@People talking about SH/HL
It being an analog trick is possible... I didn't think of that. That is a possibility other than the VDP working at 12bits internally thanks.

@People talking about dynamic tiles
Games like GoT and LoT are most likely using the processor to generate a lot of the animation, although it is most likely cached (not realtime).
There are a lot of areas in these games with no obvious dynamic tiling, the processor can generate the animation for the next area while the player is in these areas.

I just don't see the necessary animation for the entire level fitting in that small amount of ram.

Hucards had very little space so they couldn't really store the tile animation, and you can't do it with the processor as you have no ram where to store the result.

[awack]

They could have dong things to stream data off CD in realtime, but that's rather limited (like Bram Stoker's Dracula -and pure tilemap oriented graphics are already inherently "compressed" by way of character/tilemapping -the main thing exploited in better SCD FMV ).
Actually, I wonder if any games DID do that...

The closest thing ive come across is Tenchi O Karua, i beleive it loads chunks of data through out each level. With out the ability to access the CD, it will start dropping BG tiles as you progress through the level.

[Chilly Willy]

Yeeesh... lots of talk while I was gone... no way I'm reading all of that.

I know how you feel, especially when kool kitty gets into the conversation.

@Chili Willy
There's nothing in a shooter that requires a lot of processing power besides collision detection, it's the collision detection that's the problem.

Not if it's done right. Here's a great tutorial from SpritesMind:
http://gendev.spritesmind.net/page-collide.html

@People talking about SH/HL
It being an analog trick is possible... I didn't think of that. That is a possibility other than the VDP working at 12bits internally thanks.

It probably is analog in the Genesis, but it's close enough to 12 bits to make no nevermind. It's also not like 12 bits would have been hard for them to do in the Genesis - even the Amiga had 12 bits and it was a full 4 years older. A simple resistor ladder is fine for 4 bits/channel - it's not like they would need an expensive DAC.

[Kamahl]

I know how you feel, especially when kool kitty gets into the conversation.

Hehehehe... gotta love kool kitty and those magnificent walls of text.

Not if it's done right. Here's a great tutorial from SpritesMind:
http://gendev.spritesmind.net/page-collide.html

Fav'd it, thanks. Although only method 3 is anything new, pretty cool idea.
There are still a lot of calculations to be done though even after optimizing (in method 2), I can't think of any genre that could make use of dynamic tiles and need more processing (dynamic tiles are useless for Sports Games).
Method 3 is Fonzies idea and that guy made mode 7 on the genny, can't really expect that from most developers.

It probably is analog in the Genesis, but it's close enough to 12 bits to make no nevermind. It's also not like 12 bits would have been hard for them to do in the Genesis - even the Amiga had 12 bits and it was a full 4 years older. A simple resistor ladder is fine for 4 bits/channel - it's not like they would need an expensive DAC.

That's what I'm saying, I just can't understand why they didn't when both the amiga and the pc engine came before. Someone must have noticed that having only 4 palettes wasn't a good idea and that they could easily alter the vdp to support 4096 colors.

[retrospiel]

I think that's just a rumor. The SNES has about as much similarity to the NES as the PC Engine does...

Hm, I don't know... I seem to remember reading that NES compatibility was very important to Nintendo's higher ups (I think it was in David Sheff's Game Over?).
It definitely was dropped some two years prior release. That we do know - BUT they sure were desperate to offer some sort of compatibility at the early hardware presentations as you can see here:

http://www.disgruntleddesigner.com/c...FC_1988Q4.html

http://www.disgruntleddesigner.com/c...FC_1989Q3.html

[Curryman123]

Can anyone explain how they achieved the water effect on the character in Dracula X.

[BLAST PROCESSOR]

No. Ever play Sapphire? There's 30fps morphing animation and all kinds of other animation going on at the same time (frame pixel updates, not just SATB entry updates). Kamahl directly hit the nail on the head. While the transfer to vram is slower on the TG than the Genesis or SNES, it doesn't have restrictions writing to vram during active display - like both the SNES and Genesis (and some other consoles). The TG16 is definitely capable of the animation that you stated as example. Being 16bit has nothing to do with it. You could have a fast 8bit DMA controller that could run circles around the Genesis 3 times over. 'Bitness' means nothing, it's all about bandwidth. The Genesis cpu isn't updating those frames to vram, a dma controller is. If the Genesis cpu was manually updating the pixel data to vram, it would be considerably slower. The DMA was there to over come the cpu's slowness (relative to this matter, doesn't mean the CPU is 'slow' per se).

My point was that the Genesis as a whole system is able to put more advanced effects together more easily and therefore, they happen more often. Sapphire is ONE game - that required the CD AND Arcade Card to pull off it's effects.

[kool kitty89]

My point was that the Genesis as a whole system is able to put more advanced effects together more easily and therefore, they happen more often. Sapphire is ONE game - that required the CD AND Arcade Card to pull off it's effects.

No... the PCE is fundamentally better at allowing animation by way of its flexible DMA set-up as well as very fast ROM allowing much easier/faster updates to VRAM from ROM. (that's also what makes the dynamic tilign effects more possible on the PCE)

Of course, CD games will tend to be much more limited as they have limited RAM in general. You can't expect a game loading in 64k chunks to be heavily animated, or even 256k for that matter.

The very fact that PCE card games didn't push for huge ROM sizes like others did is the only reason you don't see more animation as such. (not a technical limitation either, bank-switching is a rather trivial and inexpensive option, but more ROM is not cheap in general)


It seems that hucards were pushed into the lower-end bracket with CDs becoming the standard format next-gen format on the platform (almost like a true successor to the original '87 PCE), thus it was less attractive to push expensive hucard games. (sort of like pushing 8+ Mbit games on the NES and SMS -I think some Tectoy games pushed that and maybe some late FC games or NES multicarts, but it wasn't common at all since it had dropped into the budget category -also why you didn't se Genesis or SNES games pushing much beyond 4 MB/32Mbit).




OTOH, the SNES DOES have disadvantages over the Genesis due to tighter DMA bandwidth for VDP updates (in some cases not a huge difference, but it depends on the circumstances -I think there's some additional limiations compared to the Genesis, and if Vblank DMA halts the CPU like in the MD that would put even more of a hurt on CPU time available). Both are at distinct disadvantages to the PCE as far as animation and VDP updates go though.

Hm, I don't know... I seem to remember reading that NES compatibility was very important to Nintendo's higher ups (I think it was in David Sheff's Game Over?).
It definitely was dropped some two years prior release. That we do know - BUT they sure were desperate to offer some sort of compatibility at the early hardware presentations as you can see here:

The final design doesn't really demonstrate that though and the choice of the CPU doesn't either. (the CPU was a very good low cost option that was easy to license -like the 6502, the problem was that they clocked the onboard RAM too damn slow for whatever reason -the system was 2.68 MHz max for all intents and purposes until later games using fast ROM in the later part of its life pushed it up to 3.58 MHz, still too slow -they should have been able to push it to double those 2 speeds respectively, at very least if they'd implemented a mechanism like the PCE and some other 650x platforms did to allow single cycle memory accesses rather than 1/2 cycle ones requiring double speed memory)


It certainly wouldn't have been a bad idea to have compatibility though and they could have done it in a way that minimized cost/performance detriment (building on and re-using the old hardware rather than tacking it on -especially building the new PPU on the old one's logic or at least partially to maximize chip space usage unlike the MD's VDP with the tacked on SMS block and totally different Genesis block -may have shared a few things like DACs, but a lot of logic tacked on due to the vastly different designs -packed vs planar, very different sprite system and tilemap, etc, etc; I think the SMS VDP may have used the old TMS9928 logic more efficiently, but I'm not sure on the details).
I'm not sure if there's any recognizable similarities, but maybe the SNES's PPU (or one of them rather) does share similarities to the NES's. (not sure if the NES used composite planar pixel format, but that would be one small indication even if the tile/sprite systems were vastly different -the resolution is nothing special in that sense given it's a common one used at 5.37 MHz dot clock like the TMS9928/9918: 3/2x the NTSC colorburst signal; the fact the NES and SNES both used 21.48 MHz master clock oscillators -for NTSC models- would be some evidence as well but still not definitive)

There's also the lack of a dual cartridge bus, but that's not really saying anything either other than the limits of the cartridge port. (though it would have been interesting if Nintendo had continued with the dual VDP+CPU bus design on the SNES . . . not a very cheap option though and somethign that would add to the cost of every game made as it did with the NES/FC -larger PCB with more pins and at least 2 ROM chips for every game -or possibly using a single 16 bit ROM chip configured to be on 2 8-bit data buses -you'd need some added logic to allow that too though and AFIK no NES games went that route)

There were definitely worse areas to waste money on and Nintendo seems to have done that with the sound system... (backwards compatibility and a 5-10 MHz 65816 would have kicked ass, more so if they could have modified the VRAM set-up to allow PCE type accesses as well as vblank DMA, or better yet have dual 64k VRAM banks to allow one bank to be updated any time and then flipped to the VDP side, especially if they could do that as well as a single 128k block only updated in vblank -or just 68k total with a mode to break it into 2 32k banks without contention or the normal 68k configuration to save cost on RAM -especially if they kept using SRAM for video and couldn't switch to cheap DRAM).
Again, the Ricoh PCM chip should have been an obvious option and I'd be surprised if Nintendo didn't consider it given its fairly prominent use in the arcade and FM Towns while being made by their primary chip vendor (Ricoh). The SPC700 was far more advanced, but for all intents and purposes the Ricoh chip could have matched it adequately with some nominal advantages on top of much lower cost. (especially if they'd added interface logic to allow it to share CPU DRAM and cartridge ROM and avoid the restriction of dedicated audio RAM -or if they did give it its own block of RAM, maybe add DMA to CPU RAM/ROM for fast loading of additional samples without CPU overhead)

Plus they'd have the NES sound hardware on top of that to boost things a fair bit. (significantly more useful than the PSG from the SMS)
That and they could have potentially added in an FM synth chip as well (the YM2612 was a likely choice given the integrated DAC for less board space used -I think it was nominally cheaper than the YM2151 as well), and that would also offset the need for more PCM use. (NES+YM2612 audio could have meant that the ricoh chip would have been OK even if configured more like the MCD's 64k RAM block requiring the CPU to update it for more samples)
Stronger pure synth hardware would be an asset to reducing ROM inflation from heavy sample use. (and allow PCM to be used more selectively and at higher quality)




Even still though, they could have gone the PBC route, or more like a cross between PBC and 2600 adapter for the 5200 and have a mostly active adapter that used the SNES controller ports and composite video/RF out (have a comp video input on the cart slot -or use the RGB derivative of the NES PPU and have RGB inputs on the cart slot). Something like the Super 8 without a separate AV port. (Sega could -and arguably should- have done the same thing with the SMS rather than tacking on the Z80 and SMS block on the VDP and putting most of the SMS hardware inside the PBC instead -just use the MD video encoder, AV port, controller ports and I/O, and power with the VDP+CPU+RAM inside the PBC -possibly merge the CPU and VDP to save cost and use the same ASIC inside later model SMSs -though if Sega had designed the MD to actually be efficiently backwards compatible more like the Mk.III -if not better than that- they wouldn't have had the Z80 and SMS VDP logic being weak points in the system as they are -and as it is they at least could have tweaked the Z80 to be much more useful with better bank switching and a faster clock speed in MD mode -use a Z80B or Z80C clocked at 5.97 or 7.67 MHz)

[awack]

Can anyone explain how they achieved the water effect on the character in Dracula X.

Tomaitheous posted this on another forum.

The top part with Richter uses two tricks. The first is an H-int call on a specific line (that water line) and it changes every color in the sprite to solid blue. Since it's drawing out the screen, only the part of Richter from there, down, shows as solid blue. The other part is on that water line, it cycles turning all sprites on and off at 60hz. This makes the sprites translucent over the BG layer, but looks like the water is translucent.

[kool kitty89]

@People talking about dynamic tiles
Games like GoT and LoT are most likely using the processor to generate a lot of the animation, although it is most likely cached (not realtime).
There are a lot of areas in these games with no obvious dynamic tiling, the processor can generate the animation for the next area while the player is in these areas.

I just don't see the necessary animation for the entire level fitting in that small amount of ram.

Hucards had very little space so they couldn't really store the tile animation, and you can't do it with the processor as you have no ram where to store the result.

Remember, it's not pure animation either: it's a hybrid of animation, tiling (which inherently compresses data -especially with carefully stylized art design to cater to heavy re-use of tiles and flipping/mirroring), manipulating the tilemap (char-scrolling like MSX/Colecovision games, etc) AND generating additional tiles on-the fly/ahead of time and buffering those into VRAM (too little work RAM, so buffer to VRAM as soon as possible and move onto the next tiles that need to be shifted).
Depending on how smooth you want the scrolling (ie 1 pixels, 2, 4, 8 -the last would be pure tilemap based char-scrolling) you'd need fewer redundant tiles (less ROM and/or less CPU work to shift added tile animation).
And you'd also tend to avoid doing any vertical parallax stuff (only perspective for horizontal, plain scrolling for vertical).

Using as few tiles as possible and animating those (or shifting with the CPU) with tons of tilemap updates would conserve memory very well and would also have been the best option for horizontal smooth scrolling on the MSX (or other char based platforms with no hardware scrolling), except later models of the MSX could afford a lot more pre-rendered animation due to the larger RAM capacity. (MSX2 would still have to rely on software and character tricks for H-scroll though)

In the extreme case, you could have a single 8x8 tile repeated over a large area and then animated to simulate smooth scrolling (either loaded from ROM, rendered ahead of time, or rendered on the fly -in all cases updating the tilemap every frame).



Again, if you can do per-tile offert H-scroll on any of these systems, that would help tremendously and allow simulated BG layers with little/no added animation/resource. (have different sections of the same layer scrolling at different rates horizontally on the same scanline)


And hucards had plenty of space compared to Famicom/NES games. (Metal Storm is only 384 kB)

Sonic 3 isn't that big either at 2 MB, but still big compared to most Hucard games.

Memory (and CPU resource -and RAM to buffer into) only limits how detailed the animated area is and/or how smooth the animated/tilemap scrolling is. Again, you could do dynamic tiling with just 1 8x8 cell, but that would be super low detail.

In Metal Storm's case, in the first stage it seems to use a 32x32 area (16 8x8 cells) repeated over large areas and animated+charscrolled (while accounting for the rate of normal hardware scrolling as well) to simulate another BG layer, in the 2nd it seems to use a single 8x8 pattern for a very large far BG plane, and more examples later on.
Some parts do vertical scrolling parallax as well. (full simulated 2 axis 2 layer scrolling on a 384 kB NES game )

http://www.youtube.com/watch?v=bRQ0LIJ3jzU

That's what I'm saying, I just can't understand why they didn't when both the amiga and the pc engine came before. Someone must have noticed that having only 4 palettes wasn't a good idea and that they could easily alter the vdp to support 4096 colors.

Cost and the fact that they decided to tack on the SMS VDP to the Genesis one and waste that space on the die that could have been used for added DAC bits and/or more CRAM.
That and adding the logic to support SH/HL (probably would have been rather trivial if they used planar graphics like Amiga EHB, but for packed pixels it's more complicated).

Dropping the internal SMS block and SH/HL support (which were barely used anyway) might have been more than enough to allow full 12-bit RGB and 8 lines of CRAM if not leaving over more space for other things. (could do more palettes using the added flags that used to be for SH/HL -up to 8 BG and 16 sprite palettes, or 8 shared BR/sprite palettes with no added CRAM over the, or 16 palettes for sprites of such 8 could also be used by BG -if you could manage 16 lines of CRAM as such)
A 1/2 horizontal res mode with 8-bit pixels (256 colors -paletized or semi-palette/direct color hybrid stuff) would have been great, even if limited to a per-layer basis (ie applied to all tiles on a BG layer when selected or all sprites). That and/or a plain bitmap mode(s) to facilitate software rendering. (especially if that could be done while leaving sprites and the 2nd BG plane active as well -so one 16 color full or 256 color 1/2 res bitmap layer and a tile layer and sprite layer as well).

Though rather than playing around with the added color and low res stuff internally, they could have saved cost and just used the external pixel bus for external expansion more like Hudsen did for the PCE. (both the PCE and MD VDP -earlier revisions- have digital video output intended for use in the arcade with external DACs for more color and other things -like dual VDP layers as in the SGX- and Hudson put that on the PCE's expansion port but NEC never used it -SGX could have been an add-on but wasn't- but Sega didn't so that).
It might have been best to add all expansion to the cart slot and remove the side port: that way, not only does it save cost (removing the traces and pins for the side port) but also means carts could potentially take advantage of said expansion with enhancement chips (let alone full add-ons: and color enhancement for the Sega CD or such would have been cheaper/more flexible to do -all add-ons would be through the cart slot too). Just use outboard pins on the cart slot like the 7800 or SNES. (they could have even reduced the pin count of the "main" slot considerably and moved all non-essential pins to the expansion section -thus making normal carts cheaper with smaller/lower pin count PCBs, perhaps around 50 pins like the SMS).
If they added analog RGB inputs on the cart slot, you could use the main AV port for all add-ons too. (digital video from the VDP is sent to the cart slot and used by ehancement chip for added color/layer/etc and output as analog RGB which is fed to the cart slot RGB inputs and then into the MD video encoder -with a signal to override the MD VDP RGB with external cart slot RGB)
Those RGB lines would also allow the PBC with SMS VDP to piggyback on the MD encoder.





As I mentioned before to Jorge in my long post on the last page, it might also have been cheaper/simpler to re-use the SH/HL mechanism short of adding 4-bit DACs for real 12-bit RGB: so just use the more limited (but much better than 9-bit) palette and allow CRAM to index that as 11-bit colorspace (9-bit RGB plus 2 intensity bits -one wasted state since there's only 3 intensities vs 4 possible with 2 bits).
Still remove the SH/HL logic for the shading effects (only used as true palette entries now) and push for 8 to 16 palettes if possible. (or 24 even with 8 dedicated to BG and 16 sprite, but that might be pushing it)
11-bit CRAM over 9-bit wouldn't save a whole lot, but it would help a little, and the removal of the SH/HL logic and lack of full 4-bit DACs would help too. (dropping the internal SMS VDP would help as well -either make it external in the PBC, or separate on the MD motherboard to later be removed to save cost)

Again, if you used 16 total palettes, sprites could use all and BG could share half.


Then there's the possibilities of added "palettes" with no added CRAM at all and/or some added CRAM but not fully added. You could use direct RGB selection or shade/intensity selection to modify indexed palettes for shifted versions of those palettes.
Before I was thinking it might be good to have 2 palette dedicated to sprite and BG and more bits for RGB/I control of palettes, but leaving them as shared would probably be better (or have a global toggle via a VDP register for which palette mode you used, or maybe on a per layer basis).

Say you take the tilemap palette selection flags (2 bits) and keep those for toggling through the 4 CRAM indexes, but then use the shadow bit to toggle normal/dark shades on that palette (and disable any use of shadow -or remove the SH/HL logic entirely); or if you only assigned 2 palettes (1 bit) you could use the added 2 bits to toggle for bright and dark "palettes" and/or modify RGB values. (like have 1 bit red and 1 green intensity control)
Same thing for sprites except with 4 bits for palette selection options instead of 3. (again with potential to have variable modes on the VDP side)

You could still support that with added CRAM entries too: like you could have 8 CRAM lines and have all 8 shared (use all 3 bits on tiles for indexes) and use the 4th bit on sprites to toggle bright/dark palettes. (or use 4 palettes dedicated to each BG and sprites and use more bits for intensity/RGB control)


Those options would still apply with or without using 12-bit RGB. (but 12-bit would add more potential color values for the shifted palettes)



One other option to conserve CRAM would be to use an offset rather than dedicated indexes: say you take the existing 64 entries in the MD, but instead of dividing them into dedicated palettes, you keep it linear and use the 3 bits on the tilemap side and 4 bits on the sprite side (assuming you disabled/remove SH/HL) to provide an offset to define where to start within the line of CRAM entries. (8 segmented groups for BGs and 16 for sprites -defining which 15 colors segment from the line of 64 entries is used in the palette, or less or more than 64 entries to more efficiently use the mechanism -without going for more, 60 entries would be more useful since it's groups of 15 and not 16).

That wouldn't increase on-screen color count, but it would make the combinations of those colors far more numerous and flexible. (more closely approaching a plain 61 color bitmap)


However, I'm not sure what kind of logic that would involve, and it it got too complex, it would defeat the purpose of using less CRAM altogether. The Saturn's VDP2 used that for its 4k CRAM entries, but that's not saying much as it was much later with a much larger VDP. (though it must have been an attractive option to save RAM rather than going beyond 4 kB of CRAM more like the Neo Geo's 8k or beyond using normal palette segments rather than offsets of a contiguous line of indexes)

[tomaitheous]

that required the CD AND Arcade Card to pull off it's effects.

I already asked before; what do you think the CD system adds to the PCE/TG that the CORE system can't already do? And the Arcade Card is nothing more than memory. No different than a large cart. The Arcade card fixes the inherent problem with CD based games in relation to carts. CD ram is cart space. Carts scaled in size as these systems went through their life cycles, while CD games got stuck with relatively smaller and smaller space comparable to carts.

My point was that the Genesis as a whole system is able to put more advanced effects together more easily and therefore, they happen more often. Sapphire is ONE game -

That was example of real frame animation being updated. There are other forms of animation (and all systems did it). Awack did a in depth look at Rondo of Blood. There's a incredible amount of animation in that game. Even if some of the frames are made of palette changes and/or grouped sprites - it's still animation. So that's an example of animation on the other side of the spectrum.

Awack also did some sprite frame (frames as in any change to the sprite; palette,flip,twitch, etc) comparisons between ports of Genesis, SNES, and PCE/CD. With, IIRC, PCE games usually having more sprite animation than SNES games (of the same game). Cotton is the game that comes to mind.

You're simply subscribing to the fact cause you see it more on the Genesis, and less on the PCE/CD, that the Genesis is more capable and the PCE less capable. While that's a perfectly valid assumption if that's all you have to go on, but it's not really accurate - relative to what these games are doing (or more accurately, what Genesis games ARE doing - not what they it's capable of). I'm not saying the PCE completely beats the Genesis in this department or vice versa. But I *am* saying they're fairly close to each other.

OTOH, the SNES DOES have disadvantages over the Genesis due to tighter DMA bandwidth for VDP updates (in some cases not a huge difference, but it depends on the circumstances -I think there's some additional limiations compared to the Genesis, and if Vblank DMA halts the CPU like in the MD that would put even more of a hurt on CPU time available). Both are at distinct disadvantages to the PCE as far as animation and VDP updates go though.

IIRC, full vblank DMA bandwidth on the SNES is 6k. Genesis (NTSC) full vblank bandwidth is 7.3k. It's relatively/fairly close. But I would think the SNES max vblank DMA would have more impact on the CPU than the Genesis, because of the lower cpu performance of the SNES cpu relative to the Genesis. By comparison, the PCE has the disadvantage of having slower 'dma' bandwidth in comparison of the two, but the advantage of writing to vram during active display. But that's not a complete/even trade off. It still takes more cpu resource than the Genesis (the DMA on the Genesis and SNES halts the cpu - so it can accurately thought of in terms of cpu resource). It probably comes out about even with the SNES, but I haven't worked the numbers. Anyway, the PCE being able to write to vram during active display isn't always a benefit for the lack of a DMA (use custom 6280 block transfer instructions in place of DMA chip).

[kool kitty89]

Anyway, the PCE being able to write to vram during active display isn't always a benefit for the lack of a DMA (use custom 6280 block transfer instructions in place of DMA chip).

Did the SMS also have to do CPU driven block transfers to update video DRAM?

Too bad the PCE didn't have fast DMA (allowing the CPU to be halted) AND the ability to use it any time in active display or vblank.
And it's too bad the MD didn't have a slow DMA mode to allow interleaved access to the 68k bus (Amiga/ST style 50/50 split -which IS used for Z80/68k bus sharing iirc) for 100% CPU bandwidth when used. (and thus you could clip for more DMA without eating more and more into CPU time -especially useful for software rendered stuff where the screen-size is smaller anyway; you'd need 2x the vblank time for the same bandwidth, but 100% CPU time is 100% CPU time -especially since there are many cases where CPU time is the limiting factor and not DMA bandwdith -probably why Zero Tolerance didn't clip for more DMA time -it would cut into CPU resource, and probably something that cut-down the framerate of games like Hard Drivin' even more -it clips to 192 lines iirc)

Plus, PAL vblank is always big (even if you push the full 240 lines there's as much bandwidth as NTSC clipped to 200 lines), so an interleaved DMA mode would have been even more beneficial/useful there.

For games that max out DMA at 224 lines in NTSC, that knocks down the CPU to an effective 6.56 MHz.
If you clipped to 160 lines in NTSC with full (fast) Vblank DMA on the Genesis, that would eat 39% of the total CPU time for an effective 4.68 MHz 68k. (and 2.78x the bandwidth of 224 lines)
However, if you clipped to 160 lines with slow 50/50 interleaved DMA, you'd get 1.39x the bandwidth of 224 lines NTSC and have 7.67 MHz of CPU performance.
Thus, at 50% DMA, to allow as much bandwidth as saturated 224 lines, you'd need to clip to 184 lines (or 188, but I rounded to 8 pixel increments).

Or, in PAL, if you wanted as much DMA time as 224 line NTSC fast DMA, you'd need to clip to ~224 lines (opposed to the maximum 240 in 50 Hz mode), so not bad at all for having 7.6 MHz compared to NTSC in fast DMA. (a real shame the MD doesn't support interleaving -or does it???)
For that matter, if you wanted as much DMA time as 160 lines 50% NTSC DMA, you'd only need to clip to ~192 lines in PAL.




Or if they REALLY wanted to have a nice DMA set-up, they could have used dual DRAM banks for video (like the toggle/flip mechamisn in MCD word RAM or 32x framebuffers) as Chilly Willy suggested and thus allowed 50/50 split DMA with the 68k running 100% while allowing 50% of the bus bandwidth to go toward DMA loading into the "open" video DRAM bank (the one not being read from the VDP) for an entire screen's worth of DMA time (or as long as you wanted before you toggles the RAM banks for the VDP to use the other).
And, like above (and the Amiga), they could have allowed interleaving to be disabled and V-DMA to steal CPU cycles for full bus bandwidth as well. (probably very rarely used given how much more flexible interleaved DMA would be with that sort or time)

That could even have been cheaper in the long run too. (plain DRAM instead of the dual ported/custom chips with I/O ports, and once the added DRAM+bus steering logic could be integrated with other ASICs on the board)
Same thing with using DRAM for main memory though: could have used MORE RAM and still cost much less in the long run over PSRAM but cost more R&D time and a bit of board space initially. (it probably would have made sense to merge the logic into one of the I/O ASICs in early revisions, then merge the I/O chips, then I/O with VDP just as they did historically)
Hell, with more main DRAM, they could have more easily afforded to do a v-RAM dual banking scheme with just 2 32k DRAM chips (VDP only accesses 32k banks at a time) and still be much better off as you could be continuously loading added graphics from main RAM and ROM using interleaved DMA (large amounts of main RAM -like 256k- would allow more graphics to be decompressed as well).

[Sik]

Looks like some people here is missing something in regards to S/H... It doesn't have any flags allotted to it, it's tied to priority, that's why it's rarely used. Many games use priority to have scenery both above and below sprites at the same time, and that's done by using tile priority (which would also affect S/H when enabled, making it hard to use). It could have been efficiently worked around by changing of the sprites themselves instead based on their current position, but eh, nobody bothered with it...

[kool kitty89]

Actually, I noticed Metal Storm actually pushed 2 axis 2-plane scrolling effects simultaneously in different directions: the 4rd stage has the BG animation scroll vertically while the main plain scrolls horizontally and simulating a 3rd layer behind that scrolling normally with the main layer!