TG16 faster than SNES? How so?

[5233]

Someone on this forum said that the TG16 would've been able to handle a port of Rocket Knight Adventures because it was faster than SNES. In what way was it faster? I recall hearing that it had an 8bit processor despite having 16bit visuals. And does anyone have any examples, such as this game vs. that game in regards to technical power? Thanks.

[jesus.arnold]

Someone on this forum said that the TG16 would've been able to handle a port of Rocket Knight Adventures because it was faster than SNES. In what way was it faster? I recall hearing that it had an 8bit processor despite having 16bit visuals. And does anyone have any examples, such as this game vs. that game in regards to technical power? Thanks.I'm not sure, though one thing I do know is that Spriggan's graphics pretty much kick the sh#t out of every vertical shmup on the SNES.

Also just to note "bit" is a completely meaningless term in relation to power and has pretty much no bearing on the console's overall performance, from what I've heard the Intellivision was actually 16-bit

[Zebbe]

The PCE CPU is running at 7.1 MHz or so while the SNES one runs at 3.5 MHz. There are other things to consider than this though when comparing how powerful or fast CPUs are.

[Chilly Willy]

The PCE CPU is running at 7.1 MHz or so while the SNES one runs at 3.5 MHz. There are other things to consider than this though when comparing how powerful or fast CPUs are.

Like the fact that while the SNES CPU can run at 3.5 MHz, it usually runs slower due to wait states on the ROM and other hardware.

[j_factor]

Like the fact that while the SNES CPU can run at 3.5 MHz, it usually runs slower due to wait states on the ROM and other hardware.

Is that the reason? I thought the CPU had three "modes", one of which was 3.58 MHz, but the default being 2.68 MHz, because the faster one has other limitations.

Anyway, yes, the TG16's CPU is faster than the SNES, and almost as fast as the Genesis.

[tomaitheous]

Someone on this forum said that the TG16 would've been able to handle a port of Rocket Knight Adventures because it was faster than SNES. In what way was it faster? I recall hearing that it had an 8bit processor despite having 16bit visuals. And does anyone have any examples, such as this game vs. that game in regards to technical power? Thanks.

Have you never seen Lords of Thunder on for the TG16? I could go and on about specs and cycles and full access to vram during active display, etc. Blah-blah-blah...blah..

But just watch these four videos:
http://www.youtube.com/watch?v=PVqkODdAI4o&fmt=18
http://www.youtube.com/watch?v=x9Ia3Ko9Slc&fmt=18 <-starting at 2:24
http://www.youtube.com/watch?v=wXAY4rss5tY&fmt=18
http://www.youtube.com/watch?v=aN-Ku5VHv2w&fmt=18

(or the full avi here (http://www.arcade-extreme.com/download.aspx?file=windsofthunder_dgn_19.avi))

Could do the snes do the same game without slowing down?

Ok, I lied. I'll give a few technical reasons :D The SNES fastest cpu speed is 3.58mhz (and that's only for it's upper half of the cart address range). That's only for rom, not for ram. RAM was wait states, or you could say that it runs at 2.68mhz(that's confusing because only some cycles of an instruction will run that slow, not all the cycles of the instruction). The TG16 and SNES CPU come from the same architecture. They only have a few amount of on dye CPU registers. Really small amount. Instead, the processsors have extremely fast bus access cycle times ( it can access the bus in 1 cpu cycle VS 4 cycles for z80 or 68k). This means it does a lot of work with direct addressing(and with indexing) and immediates. This means a lot of ram access(see where I'm going with this? More ram access means slow times on the SNES for 3.58mhz mode). So while the SNES cpu can run at 3.58mhz, it's more like ~3.05mhz. The SNES CPU has long 24bit addressing mode(cost +1 cycle), but the memory map is convoluted for 16bit logical range(only 32k of rom and the same 8k ram for almost all "banks". the rest of the 16bit address range is for ports and cart expansion via special chips). On the 7.16mhz TG16, it's much more flexible for the 16bit address range as it can map any 8k chunk of its 21bit address range into the 16bit logical range - Ram or Rom it doesn't matter.

And lastly, not everything in a game requires 16bit math. A lot of stuff can still be done within an 8bit value range (9bit if you test for overflow) and that SNES games (programmers) actually drop the processor down into 8bit mode as an optimization method. And even when it comes to 16bit math, it's usually 8bit+16bit->16bit operations. Which means the 8bit processor can take short cuts and not increment the top half of the 16bit value if the lower value doesn't overflow - thus executing a little faster. This is in the context of the 65x (which the two cpu's come from) fast instruction speeds, and doesn't necessarily apply to all/other 8bit processors to the same degree. And because of shear clock speed, 16bit+16bit->16bit is still faster on the TG16. The TG16 CPU also has some nice extra instructions that the SNES CPU doesn't have ( bit test and branch on condition for zeropage registers without using the Acc reg, swapping of any combination of a,x,y with effecting flag reg, bit test immediate with zp or address and set flags without using the Acc reg, etc).

[kool kitty89]

The 1.79 MHz mode on the SNES is just for handeling I/O, right? (ie, the controllers -using the same I/O logic as the NES -which makes sense for having the 1.79 MHz mode)

Is the 1.79 MHz mode on the TG-16's CPU used for a similar purpose?



Would the SNES have actually been better off with a custom 65C02 derivative (with integrated bank switching/extended addressing plus additional I/O) clocked similarly to the TG-16's (with coresponding faster RAM) than it has in actuality? (the faster RAM could have a significant impact on cost though, and I doubt there would be too much difference between the current and hypothetical CPU costs -and without faster RAM, there's really no advantage for a faster CPU)
Then again, many have suggested that Nintendo should have just gone with a 68000, but (possible plans for backwards compatibility aside), they woudn't have been able to licence that chip for their own custom version, and wouldn't be able to use the NES controller I/O logic.

[tomaitheous]

The 1.79 MHz mode on the SNES is just for handeling I/O, right? (ie, the controllers -using the same I/O logic as the NES -which makes sense for having the 1.79 MHz mode)

Correct. But that's only for $4000-$41ff range. And the only thing mapped there is the joypad registers. All other port access of the built in system hardware is 3.58mhz mode (that would be $2000-$5fff, excluding the above mentioned $200 byte range).



Is the 1.79 MHz mode on the TG-16's CPU used for a similar purpose?

It would be used for accessing any slow device connected to the bus. The only thing NEC/Hudson uses it for is BRAM read/writes (game save ram).



Would the SNES have actually been better off with a custom 65C02 derivative (with integrated bank switching/extended addressing plus additional I/O) clocked similarly to the TG-16's (with coresponding faster RAM) than it has in actuality?

Then what it has now? Yes. But the 65816 in the snes isn't "stock". It's still a custom package. It's that no instructions were added or changed.


(the faster RAM could have a significant impact on cost though, and I doubt there would be too much difference between the current and hypothetical CPU costs -and without faster RAM, there's really no advantage for a faster CPU)

They're using DRAM not SRAM in the snes. The cost is already much lower because of that. Why they didn't go with a faster DRAM setup, I have no idea. But it is clear that they left open a window of the fixed address range for "cart" devices. Forward thinking co-processors addons (the NES was notorious for chip addons, so that says something about Nintendo's thinking). Pilot Wings, the very first SFC game used a DSP.


Then again, many have suggested that Nintendo should have just gone with a 68000, but (possible plans for backwards compatibility aside), they woudn't have been able to licence that chip for their own custom version, and wouldn't be able to use the NES controller I/O logic.

A 68k with the same speed limitations as the snes has now, would be just as slow(and somewhat slower). I think the easiest solution would have been to use a faster '816 package along with faster ram. But the co-processor interface design suffices. The SA-1 addon probably was pretty cheap (cheap as memory or cheaper). I'm surprised more games didn't use it. A 10mhz 65816 with a built in bitmap to planar converter and faster ram. Definitely nice.

[kool kitty89]

Then what it has now? Yes. But the 65816 in the snes isn't "stock". It's still a custom package. It's that no instructions were added or changed.

Doesn't the 65816 itsself have added instructions compared to the 65C02?




They're using DRAM not SRAM in the snes. The cost is already much lower because of that.
the TG-16 used SRAM for main? (iirc the Genesis, SNES, and TG-16 all had VRAM for the video memory, but that's an unrelated issue)



A 68k with the same speed limitations as the snes has now, would be just as slow(and somewhat slower).
At the same clock speed, you'd have double the bandwidth using a 16-bit data bus, inless you used a 68008. (didn't you mention previously the Genesis's bus for the 68k was clocked significantly slower than the SNES's)


I think the easiest solution would have been to use a faster '816 package along with faster ram. But the co-processor interface design suffices. The SA-1 addon probably was pretty cheap (cheap as memory or cheaper). I'm surprised more games didn't use it. A 10mhz 65816 with a built in bitmap to planar converter and faster ram. Definitely nice.

Well it did come relatively late in the SNES's lifecycle (I think the first game to use it came out in '95), but it was used more than any other enhancement chip. (seems like close to 1/3 enhanced games used it, the DSP being the second most common, then the more expensive Super FX GSU's)
It seems like a fair portion of games released from '95 onward were SA-1 games. (having the decompression hardware was a nice feature too, probably helped a lot with cramming stuff into those 32 meg carts)

It's annyoing that DK Country gets mistakingly refrenced to having an SA-1 fairly often... (I think there's even a comment from a Sega representative that gets this wrong)

[sketch]

The Genesis, SNES and TG all have different strengths and weaknesses, so designating one of them as "faster" doesn't have too much meaning. To my personal tastes, the Genesis has the best feature set (does parallax scrolling well, handles a lot of sprites with no slowdown, clean output, competent sound, tons of software), but being the best console depends a lot on personal taste.

Unfortunately, marketing people have taught us to think in terms of "fastest" or "most powerful" machine. That seems to have stopped with the current generation, however, since I think everyone realizes that the PS3 and Xbox 360 are more or less equivalent, regardless of what specs you come up with, and the Wii is less powerful but has more varied inputs. You don't see any tech speak in mainstram marketing any more, which is good.

[tomaitheous]

Doesn't the 65816 itsself have added instructions compared to the 65C02?

Over the C02? Only a handleful new instructions, but more importantly is has new/more addressing modes. It has stack related indexing which is great for high level languages, direct long mode and indirect long mode addressing. But it also lacks instructions from the later 'C02 versions because the '816 is a direct descendant to the 6502, not the 65C02 (or their later versions standardized by Rockwell). Even now, the WDC company's 65816 micro controller's lack some the extra functions that the 65C02S micro controller's have. Both the 'C02S and the '816 are pretty nice setups from the original '02.





the TG-16 used SRAM for main? (iirc the Genesis, SNES, and TG-16 all had VRAM for the video memory, but that's an unrelated issue)

Actually, I think technically the Genesis is the only system with real VRAM. I.e. dual port ram. The SNES and TG16 (I know for sure) use SRAM. But that's irrelevant because "VRAM" isn't mapped into any of these system's cpu logical address range like on a computer. They're port access via a controller interface. They just label it as (V)ideoRam because it's ram specifically for the display controller/processor. SRAM was used because it was extremely fast compared to DRAM at the time, but the chips hold less per physical size and are more expensive. IIRC, the 64k of work ram on the Genesis is SRAM (two chips). On the TG16, the main 8k onboard of work ram is SRAM (not to be confused BRAM). The CD base unit of 64k and the SCD addon system card of 192k are also SRAM. The Arcade Card Duo/Pro of 2048k <- not sure what it is.




At the same clock speed, you'd have double the bandwidth using a 16-bit data bus, inless you used a 68008. (didn't you mention previously the Genesis's bus for the 68k was clocked significantly slower than the SNES's)

Yes, you get double the bandwidth in a single access - but the 65x has a faster bus cycle access time than the 68k - that's 1 cycle on 65x and 4 cycles on 68k. That means the 65x processor can pull 32bits of data from the bus in the same amount of time the 68k can pull 16bits, even though the 65x only has an 8bit data bus. The 68008 is a horrible processor. Trust me, you don't want that in anything. It weakens all the strengths of the 68k design IMO >_>




Well it did come relatively late in the SNES's lifecycle (I think the first game to use it came out in '95), but it was used more than any other enhancement chip. (seems like close to 1/3 enhanced games used it, the DSP being the second most common, then the more expensive Super FX GSU's)
It seems like a fair portion of games released from '95 onward were SA-1 games. (having the decompression hardware was a nice feature too, probably helped a lot with cramming stuff into those 32 meg carts)

It's annyoing that DK Country gets mistakingly refrenced to having an SA-1 fairly often... (I think there's even a comment from a Sega representative that gets this wrong)

Heh. That's surprising. Considering how cheap the '816 IP was to license and produce.

[kool kitty89]

Yeah, the CPU is only one small part of the system in most cases (except for systems with simple bitmapped displays requiring the CPu to handel practically everything, like older PC's -before hardware acceleration became popular- 32x and the like).

Generally the graphics/video hardware make the biggerst difference (atari 8-bit/5200, NES, and Atari 7800 all having basicly identical CPU's, same for ColecoVision, SG-1000, MSX, ZX-Spectrum, Amstrad CPC, and Master System), even the Atari 2600's CPU is relatively close to the 6502's in NES, 5200, and 7800 (moderately slower with more limited addressing, and no interupts).

In this respect I think the main limitation of the TG-16 was the single scroll plane, compared to the Genesis's 3 scroll layers. Both had the 9-bit (512 color) palettes and worked with individual 16-color subpalettes, so that's not an issue. The big plus for the TG-16 is the much greater number of subpalettes available. While the genesis has 4 subpalettes (1 for each layer), the TG-16 has 32 subpalettes, 16 palettes each for sprite and scroll layers. (which greatly increases flexibility, particularly with sprites not having to all share a single 16-color palette, and of course for the backgrounds)

[Chilly Willy]

but the 65x has a faster bus cycle access time than the 68k - that's 1 cycle on 65x and 4 cycles on 68k. That means the 65x processor can pull 32bits of data from the bus in the same amount of time the 68k can pull 16bits, even though the 65x only has an 8bit data bus.

Except that as you mentioned before, the 65xx has almost nothing in the way of registers, so the bus usage is well more than doubled. At best, it only breaks even with the 68000. It take an optimized 8-bit code sequence making heavy use of the zero page to edge out the 68000 on speed. If you need more than 8 bits, even good code won't help.

[kool kitty89]

Actually, I think technically the Genesis is the only system with real VRAM. I.e. dual port ram. The SNES and TG16 (I know for sure) use SRAM. But that's irrelevant because "VRAM" isn't mapped into any of these system's cpu logical address range like on a computer. They're port access via a controller interface. They just label it as (V)ideoRam because it's ram specifically for the display controller/processor. SRAM was used because it was extremely fast compared to DRAM at the time, but the chips hold less per physical size and are more expensive. IIRC, the 64k of work ram on the Genesis is SRAM (two chips). On the TG16, the main 8k onboard of work ram is SRAM (not to be confused BRAM). The CD base unit of 64k and the SCD addon system card of 192k are also SRAM. The Arcade Card Duo/Pro of 2048k <- not sure what it is.

I know the differences and general advantages/disadvantages between DRAM and SRAM (and that VRAM is dual-ported), but that's interesting, so the Master System NES and contemporaries were using SRAM for main and video, or older ones liek the ColecoVision or SG-1000? (I knew the 7800 did and the 2600's RIOT of course, but not the others, particularly the SNES video RAM) I think the Atari 5200 used DRAM, along with the 8-bit computers it was derived from. (for its 16 kB shared)

All the RAM in the Sega CD was DRAM though, right? (except for the battery backup)

The PlayStation and Saturn used actual (dual ported) VRAM though, didn't they? (I know 3DO did)



The 68008 is a horrible processor. Trust me, you don't want that in anything. It weakens all the strengths of the 68k design IMO >_>
Worse than an 8088?




Heh. That's surprising. Considering how cheap the '816 IP was to license and produce.

Particularly considering that the more expensive Super FX chip was rleased 2 years earlier. (and after colaberating with Argonaut to design it, opposed to the SA-1 which was just a custom implementation of the 816 with some added features) Then again, the Super FX was capable of a lot of stuff the SA-1 wasn't. Still, I'd immagine it would have been useful as a cheaper alternative. (particularly for games that didn't use any chip, but probably should have, maybe games like Wolf3D and Wing Commander, probably Race Driven as well, among other possibilities)

Though I also tend to wonder why they didn't use a DSP for polygon rendering like Sega did with the SVP. (I have no idea what nintendo's DSP chip was like, but assuming it would have been rather slow for this purpose -which seem likely given how early it was implimented- perhaps they could have used a more powerful one -if not a faster derivative of their own chip)

[tomaitheous]

Yeah, the CPU is only one small part of the system in most cases (except for systems with simple bitmapped displays requiring the CPu to handel practically everything, like older PC's -before hardware acceleration became popular- 32x and the like).

Generally the graphics/video hardware make the biggerst difference (atari 8-bit/5200, NES, and Atari 7800 all having basicly identical CPU's, same for ColecoVision, SG-1000, MSX, ZX-Spectrum, Amstrad CPC, and Master System), even the Atari 2600's CPU is relatively close to the 6502's in NES, 5200, and 7800 (moderately slower with more limited addressing, and no interupts).

That's true. But that's also what makes the ST games (the good ones ;) ) pretty impressive. Plus, it's a planar bitmap system (not so fun for overlaying). Though I do know of some of the tricks they use to offset planar problem (preshifted sprites/tiles/etc).


In this respect I think the main limitation of the TG-16 was the single scroll plane, compared to the Genesis's 3 scroll layers. Both had the 9-bit (512 color) palettes and worked with individual 16-color subpalettes, so that's not an issue. The big plus for the TG-16 is the much greater number of subpalettes available. While the genesis has 4 subpalettes (1 for each layer), the TG-16 has 32 subpalettes, 16 palettes each for sprite and scroll layers. (which greatly increases flexibility, particularly with sprites not having to all share a single 16-color palette, and of course for the backgrounds)

I'd add to the TG-16's strengths in that it can fully read/write to vram during active display (unlike the other systems). And that the read/write pointers are separate (don't destroy one another). You can race or chase the raster beem too (man, need to get demo effects off the brain :P ). It's nice not having to worry about needing to fit everything into vblank time, including SAT updates (Sprite Attribute Table) as those are buffered on the TG16 VDP.

Genesis has 3 scroll layers: 2BG+1SPR (the window layer is shared and doesn't overlap as a 3rd BG layer). TG16 has 2 layers: 1BG+1SPR. That is its biggest downfall IMO. The Super Grafx fixed this problem, but was never incorporated into the new Duo system - so I guess that's a moot point. Every system has its down side. It seems the SNES' downside was easiest to fix.


Except that as you mentioned before, the 65xx has almost nothing in the way of registers, so the bus usage is well more than doubled. At best, it only breaks even with the 68000. It take an optimized 8-bit code sequence making heavy use of the zero page to edge out the 68000 on speed. If you need more than 8 bits, even good code won't help.

Sorry. I should have written '816 there instead of 65x (I use 65x like x86 to mean anything of that arch). But yeah, I was just mentioning the bus bandwidth because usually use that "yeah, but it's an 8bit bus" line for the '816. 65x (not specifically the 8bit 65xx) is a bus hog.



I know the differences and general advantages/disadvantages between DRAM and SRAM (and that VRAM is dual-ported), but that's interesting, so the Master System NES and contemporaries were using SRAM for main and video, or older ones liek the ColecoVision or SG-1000? (I knew the 7800 did and the 2600's RIOT of course, but not the others, particularly the SNES video RAM) I think the Atari 5200 used DRAM, along with the 8-bit computers it was derived from. (for its 16 kB shared)

I don't know of all the systems that used it, but pre-90's you couldn't get the speeds of SRAM in DRAM. Displays usually needed really fast ram (sometimes faster than pixel width too). NES uses SRAM for the nametables of the PPU, but as for the rest of the video memory - that's onboard the cart! That's what made it extremely upgradeable/flexible (this even allowed the MMC5 mapper to upgrade the colors per 4x4 tiles to 1x1 tile). NES games had either VRAM or VROM. For VROM, you could swap out an entire bank of tiles or sprites in just a handleful of cpu cycles. The PS1 couldn't even move that much data in the same amount of time frame. But yeah, NES system ram is SRAM. Not sure about SMS work ram (z80 has a built in DRAM refresh IC, so it wouldn't surprise me if it did use DRAM. Plus the z80 bus cycle was fairly slow as 4 Tcycles).


All the RAM in the Sega CD was DRAM though, right? (except for the battery backup)

The PlayStation and Saturn used actual (dual ported) VRAM though, didn't they? (I know 3DO did)


Dunno.


Worse than an 8088?

Hmm (hehe). Probably not. I'd have to go back and look. 8088 has incredibly slow instruction times (8086 wasn't much better). I can't believe the 8086/8088 became the dominant processors in the market. But that's another topic.



Though I also tend to wonder why they didn't use a DSP for polygon rendering like Sega did with the SVP. (I have no idea what nintendo's DSP chip was like, but assuming it would have been rather slow for this purpose -which seem likely given how early it was implimented- perhaps they could have used a more powerful one -if not a faster derivative of their own chip)

The DSP's they did use were already setup with an internal rom (IIRC), so it became a standalone device and used as a math co-processor (I have no idea if it uses the COP instructions of the 65816 for co-processor instruction integration or not). But for the RISC chip(SuperFX), I'm sure there was some reason why they went with it. I don't know much about either the SVP or the SuperFX RISC on a low level.

[gamevet]

Have you never seen Lords of Thunder on for the TG16? I could go and on about specs and cycles and full access to vram during active display, etc. Blah-blah-blah...blah..

But just watch these four videos:
http://www.youtube.com/watch?v=PVqkODdAI4o&fmt=18
http://www.youtube.com/watch?v=x9Ia3Ko9Slc&fmt=18 <-starting at 2:24
http://www.youtube.com/watch?v=wXAY4rss5tY&fmt=18
http://www.youtube.com/watch?v=aN-Ku5VHv2w&fmt=18

(or the full avi here (http://www.arcade-extreme.com/download.aspx?file=windsofthunder_dgn_19.avi))

Could do the snes do the same game without slowing down?


I don't believe a bare bones TG-16/PC-Engine could run that game. The Turbo-CD added a 16-bit processor not found within the TG-16. I suppose you could say it's fair, since SNES carts did the same trick within the cartridge, but we aren't really comparing apples to apples here.

[Chilly Willy]

I don't think the Genesis has actual vram... it's just called vram because it's the ram that holds the video. Think about it - the vram in the Genesis can ONLY be accessed by the CPU during the horizontal and vertical blanks, unless the display is disabled. That's the earmark of regular ram, not dual-ported vram.

[Joe Redifer]

A bare bones TurboGrafx/PC-Engine could indeed run Lords of Thunder without the CD music... if the HuCard space were big enough. The CD-ROMROM (that's how some idiots actually pronounce it) only added a mono ADPCM sound chip. That's it. Not extra processors of any kind.

It is the Sega CD which added an extra 16-bit processor.

[Black_Tiger]

I don't believe a bare bones TG-16/PC-Engine could run that game. The Turbo-CD added a 16-bit processor not found within the TG-16. I suppose you could say it's fair, since SNES carts did the same trick within the cartridge, but we aren't really comparing apples to apples here.

They put the same 16-bit chip into Magical Chase, so it's fair to compare it to SNES games.

[Gentlegamer]

Have you never seen Lords of Thunder on for the TG16?
I heard it's more intense than FEKA games and has the arcade feel! Other shooters DON'T EVEN COMPARE!

[j_factor]

I heard it's more intense than FEKA games and has the arcade feel! Other shooters DON'T EVEN COMPARE!

That's Gate of Thunder. But it is true that Lords of Thunder will give you faith in the Lord.

[kool kitty89]

I don't think the Genesis has actual vram... it's just called vram because it's the ram that holds the video. Think about it - the vram in the Genesis can ONLY be accessed by the CPU during the horizontal and vertical blanks, unless the display is disabled. That's the earmark of regular ram, not dual-ported vram.

Hmm, based on this discussion it apears to be dual-ported 8-bit VRAM:
http://www.atariage.com/forums/index.php?showtopic=130170&st=125

post#142

My fault, I looked at the wrong schematics. Here are the right ones:

http://www.emu-docs.org/Genesis/mega2.png

The Genesis does indeed only have an 8bit graphics bus. Thank you for pointing me to that information!

post# 143

There is something fishy with those DRAM's... The "AD" pins on the VDP are connected to the address pins of the DRAM, but also to a mysterious 4 bit port (marked I/O), right next to the data port. I have a feeling that this address bus is multiplexed several times... I'll continue my research.

Ah, now I understand, it's a dual port VRAM not a standard single port DRAM. That's why they only used an 8 bit data port, because this ram can be read-out very fast (30ns)



Now that I look at that thread again, it's the same one they were also arguing about the merits of the TG-16, SNES, and Genesis's CPU. And also whether the 65816 actually has a 16-bit ALU. (or if it does, whether it's necessary)

[tomaitheous]

I don't think the Genesis has actual vram... it's just called vram because it's the ram that holds the video. Think about it - the vram in the Genesis can ONLY be accessed by the CPU during the horizontal and vertical blanks, unless the display is disabled. That's the earmark of regular ram, not dual-ported vram.

It has two 32Kx4bit dual port sram. One port is parallel and one port is serial. It reads from both ports while building out the display. The only reason why you get sixteen 8bit writes total per active scanline is because the VDP itself is to busy to pass the write request along (CRAM is internal an allows for sixteen 16bit writes IIRC). This is Model 1. I've been told the Genesis 3 doesn't use dual port ram for video ram, but I'm not sure if late model 2's were changed (wouldn't surprise me if they were).


I don't believe a bare bones TG-16/PC-Engine could run that game. The Turbo-CD added a 16-bit processor not found within the TG-16. I suppose you could say it's fair, since SNES carts did the same trick within the cartridge, but we aren't really comparing apples to apples here.

Nope. No additional processors. Just an ADPCM controller (for single channel mono sample playback) and some ram to take the place of cart rom/space.



Now that I look at that thread again, it's the same one they were also arguing about the merits of the TG-16, SNES, and Genesis's CPU. And also whether the 65816 actually has a 16-bit ALU. (or if it does, whether it's necessary)

I don't think he was arguing that it didn't have a 16bit ALU, but that you could get close to the same performance with an 8bit ALU and hardware macro level instructions. But that speaks more to the power/strength of the 65x arch than to dismiss the '816. It would need some additional work for overlapping processes (the ALU already has its own ADDER, so it can increment itself in parallel). The 65x can already do a memory fetch while processing on the ALU at the same time, but it's not in every situation (1 byte implied instructions still take 2 cycles when they should only take 1).

[gamevet]

Nope. No additional processors. Just an ADPCM controller (for single channel mono sample playback) and some ram to take the place of cart rom/space.


I must be reading something wrong, because I've seen one document that shows expansion using a MOS 65802 16-bit at 16MHZ that interfaces with the CD add-on.



A bare bones TurboGrafx/PC-Engine could indeed run Lords of Thunder without the CD music... if the HuCard space were big enough. The CD-ROMROM (that's how some idiots actually pronounce it) only added a mono ADPCM sound chip. That's it. Not extra processors of any kind.

The TG16 (PCM) hardware is only used for sound effects, thus freeing up memory and CPU space. The Turbo's PCM is generated through the CPU, so there is no dedicated sound hardware to handle the load.



They put the same 16-bit chip into Magical Chase, so it's fair to compare it to SNES games.

Magical Chase is not one of the known carts that has an enhancement chip. Obviously, the SNES was designed with the idea of using such chips, as was the NES.

http://www.raregame.ru/file/c1/SNES_Games_with_Chips.doc

http://www.gamersgraveyard.com/repository/snes/history/chips.html


The most obscure chip I have come across is SA 1. Only one game uses this, the Japanese game, Jikkyou Oshaberi Parodius: Forever With Me, from Konami. It is a speech synthesizer chip, which was developed by them, most likely.



Magical Chase isn't all that impressive. Compare these 2 equal games on the SNES and Turbo. The Turbo does a pretty impressive job, but you can see that larger enemies don't hold together (dropping tiles) as well as the SNES version.

The Saturn version is miles better than both of these.


T3Gs6_CBoPA

6x0brXUS4jw&feature=related

[Black_Tiger]

Magical Chase is not one of the known carts that has an enhancement chip. Obviously, the SNES was designed with the idea of using such chips, as was the NES.

Magical Chase isn't all that impressive. Compare these 2 equal games on the SNES and Turbo. The Turbo does a pretty impressive job, but you can see that larger enemies don't hold together (dropping tiles) as well as the SNES version.

I was just joking around since I've never heard anyone talk about the TG-16 having enhancement chips, 16-bit or otherwise, for the CD-ROM or HuCard games. I'm not sure where you've been getting your TG-16 info, but there aren't any "known carts" with enhancement chips, because none do and according to the experts, the TG-16/PCE can't even make use of them through the cart port.

I used Magical Chase as an example, since it's another game like Lords of Thunder that does background layering that is supposed to be "technically impossible" on TG-16 (really the console just uses different methods), since that was the only thing I could think of that might lead you to believe that it couldn't be done on HuCard.

Parodius isn't a good example. That "tile drop out" is just sprite break-up/flicker due to poor sprite management (many TG-16 games do much more without break-up). There's a reason that the PCE is the king of 16-bit shooters. Regardless of whether Parodius originated as a PCE game and was later enhanced for arcade/SNES or is just a lackluster port, if you compare all cross platform games you'd find that the TG-16/PCE versions are better overall visually than SNES and even Mega Drive games.

It isn't proof that the TG-16/PCE is a better system, it just happened to get the better ports overall, which is due much in part to the strong CD-ROM support.

Try comparing the PCE and SNES versions of World Heroes 2, Fatal Fury 2, Fatal Fury Special, Art of Fighting, Dracula X, Godzilla, Dungeon Explorer II/Crystal Beans, Gradius II/Gradius III, Dragon Slayer 1 & 2, Tokimeki Memorial, Might & Magic III and Panic Bomber.

Here's a mock-up I did for a similar thread in another forum. The two giant Bonks on the left are exactly as they appear together in the 2 player simultaneous Bonk 3 for TG-16. The Bonk on the right is the single "giant" Bonk from Super Bonk for SNES which is a one-player-only game-

http://superpcenginegrafx.com/misc/superbonk3.png

[tomaitheous]

I must be reading something wrong, because I've seen one document that shows expansion using a MOS 65802 16-bit at 16MHZ that interfaces with the CD add-on.

Lots of misinformation out there. I've seen docs/sites list the PCE as having two 8bit processors running at 3.58mhz, or just one 8bit 3.58mhz processor. All sorts of crazy stuff. :o

The only "processor" in the CD base unit is the microcontroller unit with an embedded rom. It's just a interface device though, you can't do anything with it other than issueing SCSI commands for the CD drive. It's all port access. It's also used to control/select the clock speed of the ADPCM decoder, translate play commands, and to interface with the separate ADPCM memory. It's a peripheral device and it's not even part of the 65802 arch (not that it matters because of its completely isolated internal rom) - it's based on NEC's very liberal custom take on a z80 arch for their microcontroller line.





The TG16 (PCM) hardware is only used for sound effects, thus freeing up memory and CPU space. The Turbo's PCM is generated through the CPU, so there is no dedicated sound hardware to handle the load.

Music via TG16 with direct audio channels takes up less than 1% cpu resource because it has PCM buffers. The audio unit is on the same dye as the CPU, but it's not "generated" or driven by the cpu in that respect. It's not different than it if was on a separate IC. And when you program it, you have to access it on the bus like any other external device. Sound FX are almost always chip generated (and are in that 1% measure). For "samples" streaming using one channel is only about 4.6% cpu resource (5% for two software mixed sample channels+clip control or 8.6% for two individual hardware channels). ~5% out of a 100% per frame is super low. Well, if you wrote a nice tight streaming driver. I've seen some sloppy drivers that eat about 10-15% while tracing through some PCE games. Air Zonk takes a whopping 20-21% cpu resource because it has lame decompression routine for the sample streams. Totally worthless cause it only saves about 5-10% space.




Magical Chase is not one of the known carts that has an enhancement chip. Obviously, the SNES was designed with the idea of using such chips, as was the NES.

Black Tiger was kidding. There are no "enhancement" chips/processors for the PCE hucard games. There could have been, there's audio input lines on the cart port and such - but nothing was ever made.



Magical Chase isn't all that impressive. Compare these 2 equal games on the SNES and Turbo. The Turbo does a pretty impressive job, but you can see that larger enemies don't hold together (dropping tiles) as well as the SNES version.

Three factors. 1) SNES has the best sprites per scanline limit of all three system Genesis, PCE, SNES. 2) Those large enemies in the SNES version use BG layers, not sprites - thus you don't get the sprite "breakup". 3) Sprite "break up" or "flicker" or "blank out" has nothing to do with the CPU. This is all on the video processor side and how efficient or inefficient a programmer uses sprites cells. The PCE version is actually pushing around a lot more sprites than the SNES version because of the lack of a second BG layer.

Another factor on Parodius for PCE, that cat ship is done inefficiently. The layers sprites ontop of other sprites when they should have just been doing cell updates (those overlaying paws are causing sprite pixel overflow flicker/blank out when there isn't any reason to do it like that. The PCE has a ton of subpalettes that it doesn't need to worry about overlapping sprites to save colors). The head of the cat is also an overlapping sprite when it shouldn't be and other pieces too, etc. I've been writing a programming tutorial for PCE and that game was going to be a prime example of what not to do/improper use of sprite bandwidth. :D

[kool kitty89]

I don't think he was arguing that it didn't have a 16bit ALU, but that you could get close to the same performance with an 8bit ALU and hardware macro level instructions. But that speaks more to the power/strength of the 65x arch than to dismiss the '816.

Well, there's these statements: (edited down, with links to full posts above)
http://www.atariage.com/forums/index.php?showtopic=130170&st=125&p=1579069&#entry1579069
The 65816 is not really a full 16bit CPU. I've been told it has in fact a 16bit ALU, but I simply don't understand for what, since it has an 8 bit data bus (an opcode like adc #$1234 takes 3 bus fetches, so the first result of the addition can be computed while the high byte of the argument is fetched), and the CPU can not perform an ALU operation on 2 registers (a case where a 16bit ALU could be of use on an 8 bit bus). Plus, all those rep #$30, sep #$30 (to set/reset 16bit registers) are really annoying, which makes it almost impossible to write a decent disassembler.

The only way to achieve smooth games is to use the DMA controller whenever possible, to transfer graphics.

http://www.atariage.com/forums/index.php?showtopic=130170&st=125&p=1579120&#entry1579120

If the 65816 has a 16bit ALU, it is by definition a 16bit CPU, although I kind of doubt it is actually the case. The CPU bus of the SNES is 8 bits, but the graphics bus of the SNES is actually 16bits (the 64K VRAM is connected to both PPU's via a 16bit bus).


http://www.atariage.com/forums/index.php?showtopic=130170&st=125&p=1579335&#entry1579335

Yes, you read everywhere that the 65816 has a 16bit ALU, but from an engineer's point of view, it doesn't make any sense, and I'll explain why:

Let's take any ALU opcode (EOR, AND, ORA...), i'll pick ADC #imm.

ADC #$1234

Decodes in 16bit mode as:

69 34 12

So due to its 8 bit bus, the 65816 needs 3 bus cycles to execute the opcode. With an 16bit ALU, you fetch the opcode, the 2 bytes of the argument and then perform the addition. Note that the 16bit ALU can only perform the operation after the high byte of the argument has been fetched.

With an 8 bit ALU however, you can first add the low byte of the argument in cycle 2 and then the high byte of the argument in cycle 3. Exactly as fast as a 16bit ALU.

There is NO case in the 65816 where a 16bit ALU is needed! Another example:

lda $1000,y :y is 16bit

1st cycle: fetch opcode
2nd cycle: fetch low byte of address, add low byte of y register using 8 bit ALU, save carry
3rd cycle: fetch high byte of address, add high byte of y register with carry using 8 bit ALU

Can all be accomplished using an 8bit ALU. So, why should I assume that the designers of the 65816 effectively wasted precious logic gates on the chip by implementing an 16bit ALU, which is always idle in 1 cycle?

http://www.atariage.com/forums/index.php?showtopic=130170&st=125&p=1579548&#entry1579548


I wouldn't doubt that the 65816 might have chained 8bit ALUs, but that's essentially the same as a single 16bit ALU.

What I proposed is not 2 chained 8 bit ALUs, but just one single 8 bit ALU with 2 multiplexers connecting all 8bit portions to the ALU. You only need to save the carry for a full 16bit add/sub operation on 2 cycles.


(They work together in a single cycle). That would make dropping down into 8bit mode much less work on the architecture side.

If it has a 16bit ALU, it would certainly be divided into 2x8 bit parts. But I really doubt it because it doesn\\\'t make sense to me to waste that amount of logic.

I believe the original z80 (or was it 8080) had chained 4bit ALUs.

As far as I know, it also has 1 single 4bit ALU, which makes sense considering the Z80 takes 2 cycles between memory fetches.

[awack]

Magical Chase isn't all that impressive. Compare these 2 equal games on the SNES and Turbo. The Turbo does a pretty impressive job, but you can see that larger enemies don't hold together (dropping tiles) as well as the SNES version.
Yes, the pce port of parodius does have more flicker, but the snes port has more slowdown. I think that magical chase is an impressive game with lots of detail, sprites, colors and parallax scrolling, Ive put up a couple of shots of the first level from snes parodius(cat enemy) and magical chase.



pce magical chase snes parodius
http://i567.photobucket.com/albums/ss114/bethcongo/MagicalChaseU-090719_0322-1.png http://i567.photobucket.com/albums/ss114/bethcongo/ParodiusdaShinwakaraOwaraiheJ016-1.png

[tomaitheous]

Kool Kitty: Oh, I know about the thread. I took part in the discussion (among others on that forum ) ;)

This is what I was talking about:


Yes, you read everywhere that the 65816 has a 16bit ALU, but from an engineer's point of view, it doesn't make any sense, and I'll explain why:

His point was that having a 16bit ALU but with an 8bit data bus, that you have dead time on the ALU operation until the MSB is loaded (second have of a 16bit WORD) because the ALU can't do anything until it receives the whole value. They could have in fact used a hardware macro system to perform an 8bit operation twice in the same amount of time the 16bit ALU does the operation + the stall time. I'm not sure that it would be any cheaper though, problem more expensive at the time nothing WDC's legacy of putting out low cost but fast processors. They weren't looking to take over the CPU market for computers. WDC was a much smaller company than Motorola or Intel. They chose an 8bit bus because 8bit memory was cheaper (again, they're going to low end/cost projects). But people neglect to see the fact that 65x arch has a large bus bandwidth. But as far as 8bit operations on the 16bit ALU, it's probably as simple as loading the 8bit value into the upper half of the ALU internal register (zeroing out the bottom end). This would emulate what you need for the 6502 mode. And for setting 16bit mode for the registers (which is independent of setting the ALU to 16bit operations), probably enables a simple mask for the upper 8bits. Thus, it's still 16bit indexing with but clipping. 6502.org forum has much more info about the internal state of the '816. Much more than I or Vigo know - those guys are old timers and engineers.

Also, there are other instruction situations where his idea doesn't hold up. But I don't think we went into detail about it. It was more of light/not to serious speculation IMO. IIRC, the thread arrived at that point because the discussion as some point went into about labeling systems as 8bit and 16bit, etc.

Hey awack :D Didn't know you were on these forums

[gamevet]

Black Tiger was kidding. There are no "enhancement" chips/processors for the PCE hucard games. There could have been, there's audio input lines on the cart port and such - but nothing was ever made.


I certainly didn't think BT was talking about enhancement chips for the PCE Hucard. The wording made it appear that BT was talking about the SNES cart, not the other way around.

I have a TG-16, and you can clearly see the ROM chip under the card skin. There's no room for any enhancement chips anyways.



Try comparing the PCE and SNES versions of World Heroes 2, Fatal Fury 2, Fatal Fury Special, Art of Fighting, Dracula X, Godzilla, Dungeon Explorer II/Crystal Beans, Gradius II/Gradius III, Dragon Slayer 1 & 2, Tokimeki Memorial, Might & Magic III and Panic Bomber.

You really can't compare Super CD games to that of a cart. The amount of sprite data carried on a disc would defineatly put it at an advantage over a 32Mb cart. Gradius II/III might be a better comparison, but on the same note, you could also compare something like Street Fighter II (Hucard) between the 2 systems.

[awack]

Hey awack Didn't know you were on these forums
Yep, since 2006 and only 20 post :(, This and the pcenginefx are the only game forums i visit regularly.

[Black_Tiger]

You really can't compare Super CD games to that of a cart. The amount of sprite data carried on a disc would defineatly put it at an advantage over a 32Mb cart. Gradius II/III might be a better comparison, but on the same note, you could also compare something like Street Fighter II (Hucard) between the 2 systems.

I hear this a lot when non-Turbo fans pick and choose how to compare the PC Engine so that it's at a disadvantage. It tends to come up as soon as you mention games that are noticeably better on PCE CD. No one ever says that it's not fair to compare SNES games to PCE because the SNES has hardware support for multiple bg layers, sound compression, transparencies, Mode 7, etc, while the PCE doesn't.

Nintendo made consumers buy add-on hardware on a cart by cart basis and some even use compression for games that are actually larger in true size than many PCE-CD and Sega-CD games if you don't count their CD audio. The PCE CD-ROM is simply a format, one that Hudson/NEC and consumers both chose.

But Nintendo foolishly choosing not to use CDs for two generations (at the expense of game players) means that their consoles' games are incomparable?

I even consider Sega-CD games comparable to SNES and PCE games, since they are all the same generation and are all within the same general class of game content. I only draw the line at 32X, even though that branch of the Genesis library would still come in last as part of a 16-bit console comparison of overall game quality (not simply tech power).

Anyways, even if not comparing real actual released games on their own, if we're strictly talking 'what kind of visuals can the hardware pump out?', PCE CD games are still proof of what the system can do regardless of format. Only Sega-CD, 32X and chipped SNES games have any real 'advantage' over stock hardware.

[kool kitty89]

Kool Kitty: Oh, I know about the thread. I took part in the discussion (among others on that forum ) ;)


Oh. :)

What's your AA screen name?

[GriskaGyoran]

The only thing that the CD drive did to the actual hardware of the PC Engine was add a redbook audio channel and a bunch of RAM depending on the card you used. As a legitimate comparison though, Street Fighter II: CE for PC Engine is a good comparison for what a PC Engine can do. However I wouldn't even come close to say that the music is better that the other versions of the game, voice clarity is very good though.

[tomaitheous]

You really can't compare Super CD games to that of a cart. The amount of sprite data carried on a disc would defineatly put it at an advantage over a 32Mb cart. Gradius II/III might be a better comparison, but on the same note, you could also compare something like Street Fighter II (Hucard) between the 2 systems.

Super CD 3.0 only has 256k of 'cart' ram. That's 2megabits. It's not like you can stream animation from the CD or anything. So it does have its limitations and in my opinion comparable. The Arcade card though, that's comparable to the larger mappers used in carts for snes/genesis. PCE does have an extra/separate 64k for ADPCM samples (divide it into how ever want), but Genesis has 64k of work ram and snes 128k work ram. And ADPCM memory is much slower to read from than either of those systems (would take a whole frame just to pull 2k out of it), if you were to try an use it for graphic storage (the original Spriggan game by Compile for CD2.0 uses 64k cart ram and 64kadpcm ram for slow storage graphics, but they really didn't have a choice with only 64k cart ram for CD 2.0 format).

[gamevet]

Super CD 3.0 only has 256k of 'cart' ram. That's 2megabits. It's not like you can stream animation from the CD or anything. So it does have its limitations and in my opinion comparable. The Arcade card though, that's comparable to the larger mappers used in carts for snes/genesis. PCE does have an extra/separate 64k for ADPCM samples (divide it into how ever want), but Genesis has 64k of work ram and snes 128k work ram. And ADPCM memory is much slower to read from than either of those systems (would take a whole frame just to pull 2k out of it), if you were to try an use it for graphic storage (the original Spriggan game by Compile for CD2.0 uses 64k cart ram and 64kadpcm ram for slow storage graphics, but they really didn't have a choice with only 64k cart ram for CD 2.0 format).

Yeah, but you have the storage space of a CD, compared to a conversion that is limited to what a developer wants to use with the cart memory size. It's not like you're loading the whole game into system memory, especially a fighter, so I don't believe that point changes why the CD isn't a benefit.

Take a look at these numbers for the Neo-Geo vs. SNES ports.

Fatal Fury: SNK = 55 MEG vs. Takara (SNES) = 12 MEG
World Heroes: SNK = 82 MEG vs. Sunsoft (SNES) = 16 MEG
Art of Fighting: SNK = 102 MEG vs. Takara (SNES) = 16 MEG
Fatal Fury 2: SNK = 106 MEG vs. Takara (SNES) = 24 MEG

The 20 MEG Fighter's History is missing 2 characters, and the complex moves were removed because of the cart size limitations. This probably wouldn't be true, if the SNES had a CD add-on and this game on a disc.


I hear this a lot when non-Turbo fans pick and choose how to compare the PC Engine so that it's at a disadvantage. It tends to come up as soon as you mention games that are noticeably better on PCE CD. No one ever says that it's not fair to compare SNES games to PCE because the SNES has hardware support for multiple bg layers, sound compression, transparencies, Mode 7, etc, while the PCE doesn't.

Oh, I'm not a Turbo fan since I don't agree? That's a bunch of BS. I've owned my TG-16 far longer than the SNES and Military Madness just happens to be one of my favorites of the 16-bit era. The thread was about processing power of the PCE vs. SNES, not which system had a better (add-on) media device.



Nintendo made consumers buy add-on hardware on a cart by cart basis and some even use compression for games that are actually larger in true size than many PCE-CD and Sega-CD games if you don't count their CD audio. The PCE CD-ROM is simply a format, one that Hudson/NEC and consumers both chose.

Very few games were more expensive because of the added chips. Nintendo's carts were pretty much the same price, chip or no chip, and compared to the Genesis carts that had a chip, or a larger amount of memory, they were a bargain.

Chrono Trigger was expensive, had 32Mb of memory and a battery backup. The cart didn't have any enhancing chips and yet Phantasy Star IV was more expensive.



But Nintendo foolishly choosing not to use CDs for two generations (at the expense of game players) means that their consoles' games are incomparable?

That has no bearing on the subject of this thread. If you're going to compare the processing power of the PCE to the SNES, than it needs to be on even ground. Don't throw some game in that has a CD generating the music and very little sound coming from the hardware. You could throw out the SNES carts that are chipped, if you think it's a better comparison. The comparisons need to be 2 equal games running with 100% of the hardware, the way it was when it shipped out the door. Throwing in chipped SNES and CD add-ons isn't a fair comparison.



I even consider Sega-CD games comparable to SNES and PCE games, since they are all the same generation and are all within the same general class of game content. I only draw the line at 32X, even though that branch of the Genesis library would still come in last as part of a 16-bit console comparison of overall game quality (not simply tech power).

This isn't a comparison of which console had the best games, or the best enhanced games. The subject also wasn't a comparison of the Turbo-Duo to the SNES was it?


Anyways, even if not comparing real actual released games on their own, if we're strictly talking 'what kind of visuals can the hardware pump out?', PCE CD games are still proof of what the system can do regardless of format. Only Sega-CD, 32X and chipped SNES games have any real 'advantage' over stock hardware.

You're still not comparing an apple to an apple, since the (CD) music isn't using up hardware RAM or processing power.

[awack]

Yeah, but you have the storage space of a CD, compared to a conversion that is limited to what a developer wants to use with the cart memory size. It's not like you're loading the whole game into system memory, especially a fighter, so that point is moot.

Take a look at these numbers for the Neo-Geo vs. SNES ports.

Fatal Fury: SNK = 55 MEG vs. Takara (SNES) = 12 MEG
World Heroes: SNK = 82 MEG vs. Sunsoft (SNES) = 16 MEG
Art of Fighting: SNK = 102 MEG vs. Takara (SNES) = 16 MEG
Fatal Fury 2: SNK = 106 MEG vs. Takara (SNES) = 24 MEG

The 20 MEG Fighter's History is missing 2 characters, and the complex moves were removed because of the cart limitations. This probably wouldn't be true, if the SNES had a CD add-on and this game on a disc.



If the snes cd add-on only had 64k or 256k of memory, you would still loose a lot from the neogeo original(fatalfury2, fatalfuryspecial, artfighting) you would probably have smaller sprites with less frames of animation and less detailed Backgrounds, because you can only load 64k or 256k at a time, in some pce action games that are not streaming the music from the CD, the action will freeze while more info is being loaded,you cant do this with a fighting game thats streaming music from the CD.

As for comparing cart vs cart, one pretty big name game that came out on both systems was Raiden and its much better on the pce while Parodius is over all better on the snes in my opinion.

[TmEE]

Small verifications on RAMs in Sega systems :

MD:
68K RAM - 2x 8bit 32Kbyte or 1x 16bit 64Kbyte 100, 120 or 150ns Pseudo Static RAM (needs some refresh cycles, slight performance hit on accessing it, 5% perhaps)
Z80 RAM - 1x 8bit 8Kbyte 100 or 150ns Pseudo Static RAM (don't know about refresh cycles, but effect it seems negligeable).
VRAM - 2x dual ported 4bit 32Kbyte 100 or 120ns DRAMs or 1x 80ns dual ported 2x 4bit 64Kbyte DRAM. VDP is doing pretty much constant access to it throughout the frame, except on overscan and vertical blanking area(there is slight accesses perhaps 6 times a line, for mandatory refreshes), there's 18 (or 19)access "slots" during active line, and the VDP is preparing 8sprite pixels within single screen pixel about 16 pixels before reaching the end of visible line.

MCD:
Main RAM - 2x 80ns 128KByte 16bit wide DRAMs. No idea about refresh and its effects on performance.
CD ROM cache - 2x 100ns 32Kbyte 8bit SRAMs. Don't recall they being Pseudo Static, must check again.
PCM chip RAM - 2x 100ns 32Kbyte 8bit SRAMs. Again don't recall them being Pseudo Static.
Backup RAM - single 100ns 8bit SRAM, fully static one for sure.

32X:
SDRAM - single 10ns 256Kbyte 16bit SDRAM chip. I may be wrong with the speed, don't remember.
Framebuffers - 2x 80ns 128Kbyte 16bit DRAM chips, same as in MCD.

Not gonna include Saturn, that ones's a mix of SRAM, DRAM and SDRAM, and chips are same as what Sega has used before :P DC is full SDRAM design.


And TG16/PCE is quite much faster than SNES, no doubt about it.


EDIT:

And SNES uses 2x 100 or 120ns 8bit 32KByte SRAM chips for sound and 2x 100 or 120ns 8bit 32KByte PSRAM chips for video. I'll have to see about Pseudoness, I may have messed up.

[gamevet]

If the snes cd add-on only had 64k or 256k of memory, you would still loose a lot from the neogeo original(fatalfury2, fatalfuryspecial, artfighting) you would probably have smaller sprites with less frames of animation and less detailed Backgrounds, because you can only load 64k or 256k at a time, in some pce action games that are not streaming the music from the CD, the action will freeze while more info is being loaded,you cant do this with a fighting game thats streaming music from the CD.

That's why the Super CD has Arcade cards.

As far as system RAM goes, the SNES has 128K vs 8K of working RAM for the PCE. They both have the same amount of video ram, so I don't see where this would be a disadvantage for the SNES, if it too was using CD media.

http://www.upto11.net/generic_wiki.php?q=pc_engine



While the Super CD-ROM² games only had additional RAM for storage, the Arcade CD-ROM² cards added a number of additional ways the RAM could be accessed (sequential, non-sequential) by the CPU.
For earlier systems, the conventional 64K or 256K RAM was split into 8K banks and mostly used for program storage, transferring it to the 64K of video RAM available was unwieldly.

The Arcade Card upgrade solved this problem by having it's extra 2048K RAM made indirectly accessible, to easily map to the PC-Engine CPU's instructions to rapidly copy data from the Arcade Card to the video RAM. The entire RAM could be then accessed as a linear stream of data instead of broken up into segments.

This was primarily used to store and stream large sprites to video RAM; as evidenced by many conversions of the well-animated Neo Geo fighting games to the Arcade CD-ROM² format. Of course for other games, it provided many more frames of animation, reduced load times, and the general convenience of additional storage. Note that this RAM cannot be used for program execution due to the way it is made accessible to the CPU.

One technique that was used by games pre-dating the Arcade Card upgrade was to store graphics data in the 64K audio RAM (used for ADPCM samples) that was present. This RAM could be directly populated by the CD-ROM hardware (it had a direct DMA channel from the CD controller) without CPU intervention, and the memory could be accessed in an indirect format similar to the Arcade Card, allowing data stored in it to appear as a 64K stream of linear data that could be easily transferred to video RAM.

[Joe Redifer]

Awak, you need to post more here. Your posts are always great! I like how you can show that the Turbo often does more with less.


Anyway, as Gamevet said, this thread is about processing power (etc) PCE vs SNES. So in that regards CD games ARE comparable. Like Tom stated, the chip music doesn't take much CPU in most games. It is not an unfair advantage at all. It's just showing what each platform can do onscreen. Also, since the SNES uses a separate processor for sound and music, it makes it even MORE fair since the Turbo has to use CPU resources for sound effects in CD games.

[tomaitheous]

Yeah, but you have the storage space of a CD, compared to a conversion that is limited to what a developer wants to use with the cart memory size. It's not like you're loading the whole game into system memory, especially a fighter, so I don't believe that point changes why the CD isn't a benefit.

Take a look at these numbers for the Neo-Geo vs. SNES ports.

Fatal Fury: SNK = 55 MEG vs. Takara (SNES) = 12 MEG
World Heroes: SNK = 82 MEG vs. Sunsoft (SNES) = 16 MEG
Art of Fighting: SNK = 102 MEG vs. Takara (SNES) = 16 MEG
Fatal Fury 2: SNK = 106 MEG vs. Takara (SNES) = 24 MEG

The 20 MEG Fighter's History is missing 2 characters, and the complex moves were removed because of the cart size limitations. This probably wouldn't be true, if the SNES had a CD add-on and this game on a disc.

If the SNES CD addon had 256k for cart space, it sure as hell would still effect those ports. Maybe not missing fighters, but missing/smaller animation - smaller/less detailed backgrounds (probably whatever just fits in vram and stays there).

A side note: Neo-Geo uses ROM space for sprites and such. There's no compression and lots of redundant graphic data because of the large cell size. Their games are going to be bigger. Arcade games also tend to have huge sprites animation sheets (like counters and frame/cell reference pointers, usually layered too) because they have the luxury of not worrying about cost as much as a home consumer production would.




That has no bearing on the subject of this thread. If you're going to compare the processing power of the PCE to the SNES, than it needs to be on even ground. Don't throw some game in that has a CD generating the music and very little sound coming from the hardware. You could throw out the SNES carts that are chipped, if you think it's a better comparison. The comparisons need to be 2 equal games running with 100% of the hardware, the way it was when it shipped out the door. Throwing in chipped SNES and CD add-ons isn't a fair comparison.

See below. See other threads. We're not talking about the SNES and the SegaCD here.


This isn't a comparison of which console had the best games, or the best enhanced games. The subject also wasn't a comparison of the Turbo-Duo to the SNES was it?

But as we pointed out, there's no real speed differences between the Turbo Duo and the TG16. Sure, the cart space being ram means you can use much better decompression schemes (Lords of Thunder and Gate of Thunder decompress LZSS streams in the background while the game is playing) compared to the original 8k of ram, but that doesn't "speed" anything up. Decompressing actually slows things down.



You're still not comparing an apple to an apple, since the (CD) music isn't using up hardware RAM or processing power.
That's kinda irrelevant. I already stated the processing resource specs. Space wise, a whole song doesn't take more than a few K. Chip sound FX are in the less-than 30 byte storage range.



Yeah, but you have the storage space of a CD, compared to a conversion that is limited to what a developer wants to use with the cart memory size. It's not like you're loading the whole game into system memory, especially a fighter, so I don't believe that point changes why the CD isn't a benefit.

I'll give you a prime example why it isn't *always* a benefit. SCD 3.0 being the most popular format; hold 256k cart space at a time. You couldn't even fit a single level of SF2 into that without severely cutting out frames of animation (doesn't matter, take any port you want from Gen/Snes/PCE and fit it into that memory). And SF2 is just two characters for a level.

So while, yes you do have massive storage, the immediate storage is still a big limiting factor. Where as SNES carts have direct access to all of the 48+ meg range (byuu posted you could do up to a 100+meg cart without mappers on the SNES). They (carts) remove redundant storage (which the CD system and cart ram has a ton of). This is a pretty big advantage over the TurboDuo. So yes, I think it's still fair game.

As for the small amount of true/full Arcade Card games, there's nothing stopping the SNES from using a larger cart. But that's a little harder to argue ;) The Arcade Card takes away all the weaknesses of the CD system. But there's still no addon processors to the CD system. It's still just all brute force of the single processor of the original TG16.



And my final notes on the subject:

No one's mentioned the fact that the TG16 and TurboDuo both have more overhead than the SNES. The TG/PCE doesn't have a second BG layer. Larger enemies and bosses are made of up sprites. Fake overlapping areas of made up of sprites. That's added cpu overhead. It might not be large, but it's something. Many games also employ 'dynamic tiles'. Lords of Thunder does for the parallax floor in the water and desert levels. That takes up more cpu times to move that tile data into vram per frame. And finally transfering video data to the vram. The TG/PCE has block transfer instructions (built-in DMA to 16bit port instructions), but these are nowhere near as fast as the DMA controller on the SNES. The TG/PCE CPU spends a lot more time moving data to the video ram. The SNES in comparison has it super easy and directly translates into more free cpu usage. So please, if you're going to figure in the tiny amount of cpu resource saved for playing a CDDA track - then it's only fair you include what I've pointed out. It only goes to prove the prowess of the TG16 CPU. This includes the port of Lords of Thunder on the SegaCD. The PCE CD ports keeps up while having more cpu overhead to deal with. Or any ports to the TG16 for that matter.

[kool kitty89]

MCD:
Main RAM - 2x 80ns 128KByte 16bit wide DRAMs. No idea about refresh and its effects on performance.
CD ROM cache - 2x 100ns 32Kbyte 8bit SRAMs. Don't recall they being Pseudo Static, must check again.
PCM chip RAM - 2x 100ns 32Kbyte 8bit SRAMs. Again don't recall them being Pseudo Static.
Backup RAM - single 100ns 8bit SRAM, fully static one for sure.

This is interesting, but you only list 2x 128 kB DRAMs for main (which would include word and program RAM), but there's another 512 kB in there. Are those another 4x 128 kB 16-bit DRAMs?

Also, I've seen 16 kB (or 128 kbits) listed for the CD-ROM cache and 8 kB (or 64 kbits) for the backup RAM. These figures are incorrect?

[TmEE]

and I forgot one other DRAM chip, there's 3 of them. And I may have messed up with CD ROM cache too.... I need to look more closely into my MCD2, that happens when I get back home. There are 8 RAM chips for sure. And DRAMs are 256KByte not 128Kbyte, I think........... I'm having so much memory issues lately

[gamevet]

I'll give you a prime example why it isn't *always* a benefit. SCD 3.0 being the most popular format; hold 256k cart space at a time. You couldn't even fit a single level of SF2 into that without severely cutting out frames of animation (doesn't matter, take any port you want from Gen/Snes/PCE and fit it into that memory). And SF2 is just two characters for a level.

So while, yes you do have massive storage, the immediate storage is still a big limiting factor. Where as SNES carts have direct access to all of the 48+ meg range (byuu posted you could do up to a 100+meg cart without mappers on the SNES). They (carts) remove redundant storage (which the CD system and cart ram has a ton of). This is a pretty big advantage over the TurboDuo. So yes, I think it's still fair game.

I believe you're missing the most important part here:


The Arcade Card upgrade solved this problem by having it's extra 2048K RAM made indirectly accessible, to easily map to the PC-Engine CPU's instructions to rapidly copy data from the Arcade Card to the video RAM. The entire RAM could be then accessed as a linear stream of data instead of broken up into segments.

Memory Buffer? I don't think so.

The CPU is barely involved with this memory transfer to the video RAM. The CPU isn't burdened with memory addressing, since it's handled indirectly.



As for the small amount of true/full Arcade Card games, there's nothing stopping the SNES from using a larger cart. But that's a little harder to argue ;) The Arcade Card takes away all the weaknesses of the CD system. But there's still no addon processors to the CD system. It's still just all brute force of the single processor of the original TG16.

There's one SNES fighting game cart that uses a specialized decompression chip to hold all of the animation data necessary to provide a solid fighting game port to the console. That game is Street Fighter Alpha 2, and the game literally loads between matches, and I believe the character animation actually loses frames over earlier Street Fighter games on the console. The music sounds pretty cut down as well.

Really, if a cartridge was that efficient, we would have seen a port of Street Fighter 2 on the PCE that blew out what was on the SNES. The SNES could defineatly push much larger sprites/tiled characters than what we've seen in any of the fighters; I just don't see how you can ignore that fact, as if the actual animations of a fighting game would really be too much for the hardware. Just look at Super Punchout!!!, the game isn't memory intensive since they use the same ring (different logo) for every match and most of the data is used for character animation. The system has 512 bytes of CGRAM!

[j_factor]

Really, if a cartridge was that efficient, we would have seen a port of Street Fighter 2 on the PCE that blew out what was on the SNES.

Didn't we?

[gamevet]

No, we didn't.

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

[tomaitheous]

I believe you're missing the most important part here:

No, I was directly responding to your claim that they (the Duo and the SNES) weren't directly comparable because the CD has such mass storage. The Turbo Duo has a counter vice, and that's the 256k(2megabit) cart size limit at any given time. And that you can't just "stream" animation from the CD unit unless it's a cinema.

Duo:
Pro - mass storage.
Con - only 256k available for animations, game code, sprite sheets, level layouts, lookup tables ,etc.
Other - How big a game is, is directly related to how much times a developer wants to put into it.

Snes:
Pro - Can directly access the whole cart address range
Con - Larger carts are more expensive.
Other - How big a game is, is directly related to how much a developer wants to spend on rom chips.

To put things into perspective: A typical game might use 64k of code for the whole game. The rest is used for graphics (tiles/sprites/tilemaps), look up tables, and animation sheets.

On a 16 megabit cart, 64k (or 0.5megabits) is 3% of the total size. On the Duo 3.0 system, that's 25% of the cart space. That also doesn't include the space needed for the LUTs and maps, etc. I really don't know how else to put this into perspective.

You're looking at the over medium size and saying, "nope. you can't compare the two systems because the CD system obviously has hundreds of more space for graphics/animation". But that's the fallacy in your logic. Sure, there is the mass storage aspect, but a game "level" and all the animation in it, is directly regulated by the temporary cart size (ram). Unless you feel comfortable loading a section of a level every 3 screens... and at that it still would regulated.



Memory Buffer? I don't think so.

Huh???


The CPU is barely involved with this memory transfer to the video RAM. The CPU isn't burdened with memory addressing, since it's handled indirectly.


Really? How do you think it gets to the video ram? It sure as hell doesn't get there by itself. Every frame of animation is updated/copied to video ram by the CPU. Video ram isn't large enough to hold all the frames of animation on any of these home systems. Some small sprites and such usually stay in video ram, but that all depends on the game and design. You've used fighters as examples. Fighters especially, definitely have to update whole sections of sprite frames at a time with the CPU (doing the work or being stalled by the DMA copier).

You quote wiki sources, but I've directly worked with the Arcade card and RE'ing it as well as other PCE hardware for myself and emulator authors. I know it inside and out, have experience writing code for it for testing, hacking, and dev projects, disassembling/tracing through games that do use it, etc. I have direct experience with the TG16 and CD addon (and all systems cards). I speak with authority/understanding. The Arcade Card has much larger graphic storage space, but it *still* has to be updated/transfered manually by the CPU to video ram in code. No different from cart rom. Do you know how wonderful it would be if it could update itself to video ram without the cpu batting an eyelash? Super wonderful, that's how much.




There's one SNES fighting game cart that uses a specialized decompression chip to hold all of the animation data necessary to provide a solid fighting game port to the console. That game is Street Fighter Alpha 2, and the game literally loads between matches, and I believe the character animation actually loses frames over earlier Street Fighter games on the console. The music sounds pretty cut down as well.

They only used a compression scheme because they didn't want to spend the money for a large cart VS hardware aided decompression chip. They're not restricted to it. The SNES normally has a huge cart address range without the need for any mappers (not that mappers expensive. They can be made with a few off the shelf parts for super cheap). But that's their choice. They're not forced to use large compressed material and have long decompression times before levels. But that still doesn't negate the SCD 3.0 problem/restriction of 256k cart space.




Really, if a cartridge was that efficient, we would have seen a port of Street Fighter 2 on the PCE that blew out what was on the SNES.

Uhmm. Because the medium it's on automatically guarantees a port is going to blow away port? And the cartridge was that efficient in that the PCE SF2:CE was on.... cart! It couldn't be ported to SCD 3.0 without losing almost half the animation of the characters.


The SNES could defineatly push much larger sprites/tiled characters than what we've seen in any of the fighters; I just don't see how you can ignore that fact, as if the actual animations of a fighting game would really be too much for the hardware. Just look at Super Punchout!!!, the game isn't memory intensive since they use the same ring (different logo) for every match and most of the data is used for character animation. The system has 512 bytes of CGRAM!

What is this in relation to? I'm not sure what your point is. Are you trying to say that transfering larger data to video ram isn't taxing on the cpu? What does the 512 bytes of color ram have to do with anything!?


But honestly, I don't see how any of this relates to comparing the TG16/Duo CPU to the SNES CPU. Nothing's changed. Joe's point still holds:

Anyway, as Gamevet said, this thread is about processing power (etc) PCE vs SNES. So in that regards CD games ARE comparable. Like Tom stated, the chip music doesn't take much CPU in most games. It is not an unfair advantage at all. It's just showing what each platform can do onscreen. Also, since the SNES uses a separate processor for sound and music, it makes it even MORE fair since the Turbo has to use CPU resources for sound effects in CD games.

[kool kitty89]

No, we didn't.

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

Well, to me, that video mainy shows that the MD port it more accurate to the Arcade version (at least in terms of backgrounds, as that's what that comparison is all about). And that the PCE version was probably based on the SNES version (which was the first home console port released), as they're both missing similar things in the backgrounds. (of course the MD version also has the Arcade intro that the others lack, but that's a separate issue)

It does show that the SNES version does have some stuff going on in the BG that the PCE version doesn't, but thery're still fairly close (the big difference being an extra scroll layer on the SNES)

Of course this doesn't compare actual gameplay or other aspects like sound. (I prefer both the samples/sfx and music in the PCE version to most in the SNES version, in World Warrior or Turbo that is, SSF2 has some great music that's harder to decide between)


In any case, none of this has anything to do with CPU power, and in particular, it doesn't even support you asertation that the Duo's CD media gave it an advantage. (which it really didn't, and needed the Arcade card to handel such a game) By you logic, there should have been a CD version of SFII on the Duo that easily trumped the cart based equivelent in terms of animation (which could have been true with the 2MB arcade system card), but there wasn't any port of the SFII serise on PCE CD. (which seems odd given the greater popularity of the system, perhaps the Arcade system card wasn't popular enough to merit it, obviouly the standard duo wouldn't have enough RAM)
In fact, that example puts the PCE at a significant disadvantage in terms of storage comparing the size of the SNES and PCE ROMs. (on top of the PCE's much smaller amount of main RAM)


But using this example in the context of the CPU comparison, I'd say it supports the PCE's superiority as the PCE game seems to have signififcantly less slowdown. (maybe even less than the Genesis version)

[Joe Redifer]

the MD version also has the Arcade intro that the others lack, but that's a separate issue
No, the Genesis version switched it so a white guy gets punched instead of the black guy that was in the arcade. It is OK to punch a white guy but not a black guy. Punching a black guy is racist and oppressive. I'm surprised they didn't make M.Bison/Balrog white. But then again, Birdie changed from a white guy in Street Fghter 1 to a black guy in Street Fighter Alpha.

I am surprised that the SNES Street Fighter 2's never utilized a 3rd BG layer. In fact hardly any SNES games did that I know of. I've never seen a game utilize all 4.

Anyway, carry on...

[kool kitty89]

Wow, that one didn't make it into the censored games thread. I just looked and they also removed the red "pow/smack" animation from the arcade's punch.

[Black_Tiger]

No, the Genesis version switched it so a white guy gets punched instead of the black guy that was in the arcade. It is OK to punch a white guy but not a black guy. Punching a black guy is racist and oppressive. I'm surprised they didn't make M.Bison/Balrog white. But then again, Birdie changed from a white guy in Street Fghter 1 to a black guy in Street Fighter Alpha.

I am surprised that the SNES Street Fighter 2's never utilized a 3rd BG layer. In fact hardly any SNES games did that I know of. I've never seen a game utilize all 4.

Anyway, carry on...

Some stages of the SNES SFII Turbo have 3+ layers, I don't remember which exactly at the moment, but anyone curious enough can sift through the backgrounds page of my comparison (http://superpcenginegrafx.com/sfiice_comp_bgs_page1.html). That video doesn't show all the layering, since the characters don't jump. I wanted to keep it consistent so I only walked them back and forth, but I mention the extra layering in the descriptions of the differences.

Now 3 layers or so doesn't mean that it was achieved with a 3+ layer Mode. According to wikipedia the only Mode which uses 3 layers with 16-bit quality graphics is really only 2 full-color layers plus a 4-color layer, which seems to only ever get used as an overlay or for text. Since the SNES SFIIT has nice colorful graphics and a 4> color overlay, I'm assuming that the game is running under Mode 1.


Only the Genesis (and maybe euro) version had the white-washed intro. The japanese version retains the arcade's ethnicity-

http://superpcenginegrafx.com/img/sfiice_intro_md4.gifhttp://superpcenginegrafx.com/img/sfiice_genesis_intro2.gif

[Joe Redifer]

Wow, I didn't know the 3rd and 4th layers of the SNES were so gimpy. Makes a lot of sense now, I suppose. The 3rd layer in Super Duper Castlevania IV only had a few shades of green and nothing more.

[gamevet]

No, I was directly responding to your claim that they (the Duo and the SNES) weren't directly comparable because the CD has such mass storage. The Turbo Duo has a counter vice, and that's the 256k(2megabit) cart size limit at any given time. And that you can't just "stream" animation from the CD unit unless it's a cinema.

Duo:
Pro - mass storage.
Con - only 256k available for animations, game code, sprite sheets, level layouts, lookup tables ,etc.
Other - How big a game is, is directly related to how much times a developer wants to put into it.

Snes:
Pro - Can directly access the whole cart address range
Con - Larger carts are more expensive.
Other - How big a game is, is directly related to how much a developer wants to spend on rom chips.

To put things into perspective: A typical game might use 64k of code for the whole game. The rest is used for graphics (tiles/sprites/tilemaps), look up tables, and animation sheets.

On a 16 megabit cart, 64k (or 0.5megabits) is 3% of the total size. On the Duo 3.0 system, that's 25% of the cart space. That also doesn't include the space needed for the LUTs and maps, etc. I really don't know how else to put this into perspective.

You're looking at the over medium size and saying, "nope. you can't compare the two systems because the CD system obviously has hundreds of more space for graphics/animation". But that's the fallacy in your logic. Sure, there is the mass storage aspect, but a game "level" and all the animation in it, is directly regulated by the temporary cart size (ram). Unless you feel comfortable loading a section of a level every 3 screens... and at that it still would regulated.

Okay, then how do you explain the existance of World Heroes on the Super CD. Obviously, the combination of the Arcade card and system memory isn't enough to handle all of that animation.

Really, how do you explain how they are getting all of that animation data inside of that limited amount of data storage, without some kind of information streaming? I'd really love to hear an explanation of why you think it would take a cartridge to do so, when you have several Neo-Geo arcade fighters ported to the Super CD and it's working!

Show me one Hucard game that pulls off that kind of level of character animation and a full soundtrack.





Huh???

2 meg of data isn't going directly to system RAM.




Really? How do you think it gets to the video ram? It sure as hell doesn't get there by itself. Every frame of animation is updated/copied to video ram by the CPU. Video ram isn't large enough to hold all the frames of animation on any of these home systems. Some small sprites and such usually stay in video ram, but that all depends on the game and design. You've used fighters as examples. Fighters especially, definitely have to update whole sections of sprite frames at a time with the CPU (doing the work or being stalled by the DMA copier).

It's not getting there through system RAM, so the CPU isn't sending out memory address data in the traditional sense. It doesn't appear that the information from the Arcade memory card is being accessed in a traditional manner either.


You quote wiki sources, but I've directly worked with the Arcade card and RE'ing it as well as other PCE hardware for myself and emulator authors. I know it inside and out, have experience writing code for it for testing, hacking, and dev projects, disassembling/tracing through games that do use it, etc. I have direct experience with the TG16 and CD addon (and all systems cards). I speak with authority/understanding. The Arcade Card has much larger graphic storage space, but it *still* has to be updated/transfered manually by the CPU to video ram in code. No different from cart rom. Do you know how wonderful it would be if it could update itself to video ram without the cpu batting an eyelash? Super wonderful, that's how much.

I'm not quoting wiki. Wiki is a horrible source for any kind of detailed information.






They only used a compression scheme because they didn't want to spend the money for a large cart VS hardware aided decompression chip. They're not restricted to it. The SNES normally has a huge cart address range without the need for any mappers (not that mappers expensive. They can be made with a few off the shelf parts for super cheap). But that's their choice. They're not forced to use large compressed material and have long decompression times before levels. But that still doesn't negate the SCD 3.0 problem/restriction of 256k cart space.

Then explain to me how a Super CD game like World Heroes, or Art of Fighting manages to pull this off, since it's only 256k of cart space. The Genesis and SNES couldn't pull if off from a cart, so the PCE's hardware must be a demigod in comparison.






Uhmm. Because the medium it's on automatically guarantees a port is going to blow away port? And the cartridge was that efficient in that the PCE SF2:CE was on.... cart! It couldn't be ported to SCD 3.0 without losing almost half the animation of the characters.

Then how do explain the miracle that was those SNK fighting ports to Super CD?

[tomaitheous]

Okay, then how do you explain the existance of World Heroes on the Super CD. Obviously, the combination of the Arcade card and system memory isn't enough to handle all of that animation.

Because World Heroes (I assume you mean part 2) isn't a Super CD game, it's an Arcade Card game and requires the 4th system card... the "Arcade Card" to play.


Really, how do you explain how they are getting all of that animation data inside of that limited amount of data storage, without some kind of information streaming? I'd really love to hear an explanation of why you think it would take a cartridge to do so, when you have several Neo-Geo arcade fighters ported to the Super CD and it's working!

This is really hard to explain to you if you have no experience with programming, especially low level/direct hardware. You CAN'T just stream in either player 1 or player 2 animation form the CD! CD access is incredibly-incredibly-incredibly slow. Many times slower than normal ram *or* rom. *That's* why there is "cart ram". To simulate a small cart. Each level/load/whatever is its own cart. This is frustrating for me to try to explain to you. And that doesn't even begin to include SEEK times for random frame access.



Show me one Hucard game that pulls off that kind of level of character animation and a full soundtrack.

SF2:CE? Seriously, SF2 has a *lot* of animation. If you were a turbo fan, then you'd know NEC ditched the cart/hucard format in favor of the CD format. The *only* reason why they went back to hucard format was because the Arcade Card wasn't ready at the time (it was in development. I developer source code notes for the first Arcade Card game with dates). The Arcade Card was delayed for whatever reason (probably due to ram costs). Super CD 3.0 could not do an equivalent version. The Arcade Card could.





2 meg of data isn't going directly to system RAM.


2meg(abits) of ram is ALL the Super CD 3.0 card has! That's it. That's all that can fit at a single time(for all the graphic/sound/code/LUTs/text/etc). I'm not sure what else you mean?





Really? How do you think it gets to the video ram? It sure as hell doesn't get there by itself. Every frame of animation is updated/copied to video ram by the CPU. Video ram isn't large enough to hold all the frames of animation on any of these home systems. Some small sprites and such usually stay in video ram, but that all depends on the game and design. You've used fighters as examples. Fighters especially, definitely have to update whole sections of sprite frames at a time with the CPU (doing the work or being stalled by the DMA copier).

It's not getting there through system RAM, so the CPU isn't sending out memory address data in the traditional sense. It doesn't appear that the information from the Arcade memory card is being accessed in a traditional manner either.

Look, I don't want to be a jerk - but you clearly don't understand the mechanics of this console (or these consoles in general). The CPU *is* manually updating the frames of animation to video ram. VIDEO RAM is only 64k. It can't hold much frames of animation at a single time, especially large sprites like SF2 and other fighters. And it's isolated (on all these consoles). The cpu doesn't even have direct access to it. It has to manually stream bytes to a special PORT. The CD unit cannot stream graphic data directly to video ram. Not on the Duo. Not on the SegaCD. Not on the SNES hardware decompression chips. The frames of animation and other graphic data that does not fit entirely in video, is stored in cart ram. When the game needs a new frame, the *cpu* takes the graphic data from cart ram and manually copies it to the video processor port, which in turn the video processor writes it to the vram address pointed by the write pointer. DMA/block transfer functions expedites this, but the process is still the same; system memory -> to video memory on a frame change. You don't stream anything from the CD. It's too freaking slow. Seek time is slow. Read time is slow. Like I said, many times slower.

Yes, the "Arcade Card" has 4 independent address registers mapped to the hardware bank. It's convenient, but it's not performance issue. And you can't block transfer from one static port to another static port(i.e. one of those registers ports to the video register port). The PCE lacks that block transfer mode. This means you can't block transfer to video port(ram) from this convenient setup. You have to map in bank registers and set the pointer up. The block transfer instructions of the cpu see this as no different than mapping in any other bank of memory.

I also don't know what you mean by "traditional sense". What does that mean (to you)?




I'm not quoting wiki. Wiki is a horrible source for any kind of detailed information.

Yeah, it can be a horrible source at times. I can't help it if people take down the info I correct/update for PCE stuff. Wiki nazis for the lose. But regardless, the specific site doesn't matter. I was referring to you quoting information you don't really understand.







Then explain to me how a Super CD game like World Heroes, or Art of Fighting manages to pull this off, since it's only 256k of cart space. The Genesis and SNES couldn't pull if off from a cart, so the PCE's hardware must be a demigod in comparison.

Super CD != Arcade Card. Super CD != Arcade Card. World Heroes != Super CD. Art of Fighting != Super CD. Fatal Fury 2 (both ports) != Super CD. Sapphire != Super CD. Far East of Eden != Super CD. Those are all Arcade Card games.

Again...
Super CD = 2megabits of cart ram/space.
Arcade Card = 2megabits of Super CD memory + 16megabits of port accessed ram.

That's a HUGE difference.



Then how do explain the miracle that was those SNK fighting ports to Super CD?

Because they weren't Super CD ports. They were Arcade Card ports.


It reminds of that sega fan with the site that has Saturn and Genesis comparisons to PS1 and SNES. He has no technical understand of how the consoles work and bases the capability of the system soley on the games (and sites like wiki and such). That's fine and.. all you can really do if you lack the proper knowledge. But he couldn't understand the fact that the PCE wasn't limited by memory to show more colors. And that it was a direct decision of the developers no to use every damn color on screen. He thought using more than 64 colors on the PCE required more processing power and more memory, etc. The up to 481 thing. It doesn't. He thought I was either lying or hiding some information from him.. or something. He had a hard time believing (not sure he even entirely does).


This is all nice and all. But this still has nothing to do with processor speed comparisons.


Wow, I didn't know the 3rd and 4th layers of the SNES were so gimpy. Makes a lot of sense now, I suppose. The 3rd layer in Super Duper Castlevania IV only had a few shades of green and nothing more.

They are :o 4bg layer mode is practically useless mode on the SNES. The 3 BG layer mode is still useful though. The weak 3rd layer is only 3colors per tile(+1 reused for the whole map), but that's mappable to 8 palettes (and having access to a 32k palette also helps this layer out). Can be used as a transparency layer or just far back layer with less detail.

[Knuckle Duster]

1.21 JIGAWATTS!

88 MILES PER HOUR!

I'M RIGHT, YOU'RE WRONG, AND THIS IS WHY: BLAH!

STFU NOOB!

TL;DNR MOTHERFUCKER

ROFLSAUCE

My synopsis for this thread.

[kool kitty89]

Some stages of the SNES SFII Turbo have 3+ layers, I don't remember which exactly at the moment, but anyone curious enough can sift through the backgrounds page of my comparison (http://superpcenginegrafx.com/sfiice_comp_bgs_page1.html). That video doesn't show all the layering, since the characters don't jump. I wanted to keep it consistent so I only walked them back and forth, but I mention the extra layering in the descriptions of the differences.

Now 3 layers or so doesn't mean that it was achieved with a 3+ layer Mode. According to wikipedia the only Mode which uses 3 layers with 16-bit quality graphics is really only 2 full-color layers plus a 4-color layer, which seems to only ever get used as an overlay or for text. Since the SNES SFIIT has nice colorful graphics and a 4> color overlay, I'm assuming that the game is running under Mode 1.

Not 16-bit quality, but 16-color palettes (4-bit color), the SNES's master palette is only 15-bits (32,768 colors). Also note that the article says 4-color palettes and 16-coloer palettes per layer (note palettes plural), which implies that there are multiple (sub)palettes of that size available for each layer (only one subpalette applied to individual tiles though), like the PC Engine's multiple 16-color subpalettes per layer. (I don't know how many subpalettes the SNES uses)
Also note that in modes using 256 colors it says palette (singular), so the 256 color layer uses the single 256 color (8-bit) palette. I also don't know about the color palette(s) used for the sprite layer.

[sketch]

I feel like I'm watching a Star Trek the Next Generation episode, where they land on the planet Game-ar and everyone speaks in console specs...

[gamevet]

Because World Heroes (I assume you mean part 2) isn't a Super CD game, it's an Arcade Card game and requires the 4th system card... the "Arcade Card" to play.

Either way, you can see where I was going with that right?




This is really hard to explain to you if you have no experience with programming, especially low level/direct hardware. You CAN'T just stream in either player 1 or player 2 animation form the CD! CD access is incredibly-incredibly-incredibly slow. Many times slower than normal ram *or* rom. *That's* why there is "cart ram". To simulate a small cart. Each level/load/whatever is its own cart. This is frustrating for me to try to explain to you. And that doesn't even begin to include SEEK times for random frame access.

I do understand that and yes I was referring to the system card as the means to store that data like a cart. Someone brought up World Heroes comparisons between SNES and PCE CD, and yet you tried to say the CD storage wasn't an advantage, when indeed it is and was a major reason why the SNES (and Genesis) game was gimped in the first place.




SF2:CE? Seriously, SF2 has a *lot* of animation. If you were a turbo fan, then you'd know NEC ditched the cart/hucard format in favor of the CD format. The *only* reason why they went back to hucard format was because the Arcade Card wasn't ready at the time (it was in development. I developer source code notes for the first Arcade Card game with dates). The Arcade Card was delayed for whatever reason (probably due to ram costs). Super CD 3.0 could not do an equivalent version. The Arcade Card could.

Yet, it doesn't look much different than the SNES version, except for a missing fence in Zangief's level.

Yeah, I couldn't afford the CD system and moved on to the Genesis, SNES and Sega CD. Most of the stuff released stateside on the Hucard wasn't all that impressive (Legendary Axe had horribly tiled backgrounds) and the hardcore fans imported or could afford the CD unit.


Look, I don't want to be a jerk - but you clearly don't understand the mechanics of this console (or these consoles in general). The CPU *is* manually updating the frames of animation to video ram. VIDEO RAM is only 64k. It can't hold much frames of animation at a single time, especially large sprites like SF2 and other fighters. And it's isolated (on all these consoles). The cpu doesn't even have direct access to it. It has to manually stream bytes to a special PORT. The CD unit cannot stream graphic data directly to video ram. Not on the Duo. Not on the SegaCD. Not on the SNES hardware decompression chips. The frames of animation and other graphic data that does not fit entirely in video, is stored in cart ram. When the game needs a new frame, the *cpu* takes the graphic data from cart ram and manually copies it to the video processor port, which in turn the video processor writes it to the vram address pointed by the write pointer. DMA/block transfer functions expedites this, but the process is still the same; system memory -> to video memory on a frame change. You don't stream anything from the CD. It's too freaking slow. Seek time is slow. Read time is slow. Like I said, many times slower.

I never said it was streamed directly from the CD. Streaming data from the CD RAM card is what I'd meant.



This is all nice and all. But this still has nothing to do with processor speed comparisons.

All I said was: "Comparing a CD based game, to that of a cart game isn't a fair comparison." It's especially not a fair comparison, when you have a game that relies on excessive amounts of data storage, and would require a very expensive cartridge to do the same.


Anyways, each of these consoles have an advantage or disadvantage when it comes to the processor. The general concensus is that none is really that much more powerful than the other, but I guess it really depends on what you're trying to do with it.

[Karakasa-Obake]

I feel like I'm watching a Star Trek the Next Generation episode, where they land on the planet Game-ar and everyone speaks in console specs...

This. I have no idea what the balls is going on.

[Joe Redifer]

Mass amounts of storage is irrelevant. What matters is the CPU speed and what it can do for the onscreen action. PCE/Turbo beats the SNES in this area.

[Black_Tiger]

Not 16-bit quality, but 16-color palettes (4-bit color), the SNES's master palette is only 15-bits (32,768 colors). Also note that the article says 4-color palettes and 16-coloer palettes per layer (note palettes plural), which implies that there are multiple (sub)palettes of that size available for each layer (only one subpalette applied to individual tiles though), like the PC Engine's multiple 16-color subpalettes per layer. (I don't know how many subpalettes the SNES uses)
Also note that in modes using 256 colors it says palette (singular), so the 256 color layer uses the single 256 color (8-bit) palette. I also don't know about the color palette(s) used for the sprite layer.

By "16-bit quality", I meant 16-bit console quality graphics, since that 3rd layer is NES quality and not the same as simply "an extra layer".

http://superpcenginegrafx.com/img/sfiice_ko_bar_pce.gif PC Engine
http://superpcenginegrafx.com/img/sfiice_ko_bar_sfc.gif SNES

http://superpcenginegrafx.com/img/sfiice_numbers_pce.gif PC Engine
http://superpcenginegrafx.com/img/sfiice_numbers_sfc.gif SNES

[Joe Redifer]

The PCE life bar looks clipped on both ends, but the SNES has the white frame around it. WTF?