What were the lifetime sales for the PCE/PCEDuo

[elmer]

I've asked the experts several times and the closest answer I've received is that the Arcade Card ram is too slow for anything but simple segment storage.

The Arcade Card memory isn't randomly accessible ... you set a starting address then grab a byte at a time.

Think of it like a modern SSD, it is fast storage, but you need to load things into real work RAM if you want to execute code. (There are limited exceptions, but the basic point is accurate.)

OTOH, you can pretty much copy sprites/tiles from the Arcade Card to VRAM very fast without copying them to work RAM first.

That's what it was designed for ... to give CD games access to a lot of sprite and background data, just like the SFII cartridge.

I believe that the SuperGrafx was given so much RAM as overkill to compensate for lazy developers who couldn't push the hardware well enough through skill and work and to just make it future proof in general.

I'd suspect that it was more to allow for developers to store compressed data on the HuCard, just like people do on the SNES and Genesis.

You need to decompress the data into RAM before you use it, and the original 8KB in the PCE is just too small to store much sprite/map data.

"Yes", you can decompress directly into VRAM, and that's great for some things, but it's not really useful for "real-time" graphics, and decompressing into RAM gives a programmer a lot more options.

I'd love for one of the programming experts who have examined CD games to say whether any CD games definitely have or have not used RAM for more than content.

Well, I've only looked at one PCE CD so far, but it's doing some pretty sophisticated dynamic asset juggling in-and-out of RAM.

And by "assets", I'm including "processor-code" and "scripting-language" as well as graphics data.

Because too many console war fanboys like to say that the CD-ROM is a major hardware upgrade and that the System cards don't allow larger content segments, it only upgraded the Work RAM so that the PCE could handle running 16-bit quality games.

Well, that's because way too many "fanboys" are talking out of their behinds because they've never written a game!

It's so easy to poke fun at SNES owners ... just ask them why their 8-bit processor runs at 1/2 or 1/3 the clock speed of the PCE's processor.

They'll always come back about how much better the SNES video chip is, and there's a good argument there ... but Hudson and Nintendo both had access to similar technology back-in-the-day.

Nintendo decided to use the complete VRAM bandwidth to produce more screen layers. That meant that you had very little time available per-frame for the CPU to actually update any graphics.

Hudson only used 50% of the VRAM bandwidth to produce the PCE's background and sprites, and let the CPU have free access to video memory at any time.

As a programmer ... I much prefer Hudson's design choice.

[CrackTiger]

You need to decompress the data into RAM before you use it, and the original 8KB in the PCE is just too small to store much sprite/map data.

"Yes", you can decompress directly into VRAM, and that's great for some things, but it's not really useful for "real-time" graphics, and decompressing into RAM gives a programmer a lot more options.

So if I understand this correctly, some CD games use some of the IFU/3.0 Card ram to decompress assets that are loaded into vram? If so, wouldn't this mean that a HuCard could run the same content, only it would take up more space in the rom because it wouldn't use the same level of compression or maybe none at all?

[elmer]

So if I understand this correctly, some CD games use some of the IFU/3.0 Card ram to decompress assets that are loaded into vram? If so, wouldn't this mean that a HuCard could run the same content, only it would take up more space in the rom because it wouldn't use the same level of compression or maybe none at all?

Well, I was actually talking about the using the SuperGrafx's extra RAM for decompressing from HuCard ... but "yes", CD games could typically do the same thing.

For one concrete example ... Xanadu II keeps everything compressed on CD, loads it into SCD RAM, and then actually leaves some of it compressed-and-resident until it wants to decompress it and copy it to VRAM. Then it will overwrite the VRAM later with something else ... but still be able to quickly decompress a new copy when it needs it.

At the end of the day ... "yes", none of the decompression would be needed if you had enough RAM or HuCard space. But you don't.

Compressing data in ROM was a standard way of fitting more data into a smaller (and therefore cheaper-to-manufacture) cartridge.

Nintendo could easily have released 640MByte cartridges for the SNES, it was never a question of technical capability. It's just that nobody would have wanted to pay the ridiculous price that it would have cost to manufacture cartridges with all the dozens of ROM chips that it would have needed.

CD-ROM was a revolutionary reduction in the price-per-megabyte cost of data storage for games ... which allowed people to make much more expansive games affordable.

IMHO, the original PCE CD was just too starved for memory to more than hint at the capabilities. SCD was when things really took off.

[Arkhan Asylum]

I am pretty sure the CD hardware preemptively killed the SuperGrafx.

That thing basically launched dead in the water.

Why bother going back to card-only shit when you have the cheap, seemingly endless CD storage?

Nobody wants to go from anime cutscenes and fancy audio, back to a "new" console that can't do any of that...
....


unless you bank on people buying the RAU-30, and hoping enough people have SuperGrafx SuperCD setups to make it worth the effort it takes to write the game.


I joked about making a SuperGrafx arcade cd game for all 4 of you.

[elmer]

I am pretty sure the CD hardware preemptively killed the SuperGrafx.

Yep, I agree.

That, and the SuperGrafx pricing, the stupid H.R. Giger Alien-inspired design rather than just making it slip directly into an existing IFU-30, the very few and expensive games, etc, etc.

Pretty much a text-book example of how not to try to fracture a console's marketplace.

I joked about making a SuperGrafx arcade cd game for all 4 of you.

That's still my dream ... it's the most interesting 4th-gen "combination-console" to me, with the most elegant technical design (not physical look).

X68000 was a multi-thousand-dollar home computer and so doesn't really count as a "home console"; Neo Geo really was an Arcade-machine-in-a-box, but it was still a cartridge machine, even after the Neo Geo CD came out; Sega CD was the usual brain-damaged Sega mess of a design, totally hampered by the Genesis's 4-palette 60-color video output; and the SNES was a nice video chip with a slow CPU and a brain-damaged memory-map (with no CD).

Is there anyone that I missed offending there? 

[Nazi NecroPhile]

Is there anyone that I missed offending there? 

You missed a chance to point and laugh at the CD-i. 

[elmer]

You missed a chance to point and laugh at the CD-i. 

Damn, how on Earth could I have forgotten that excellent target! 

[TurboXray]

The limited amount of system ram on the PCE prevented devs from using more complex compressing schemes (although technically they could have used a small ring buffer). If you look at hucard games, except for the late gen ones - they all use simple RLE-ish style compression. That means less animation or grafx overall (Parodius PCE vs SNES). The smaller amount of ram also means less decompressed asset space for quick updates to vram dynamically throughout a level (animation, etc). The SGX is definitely a better setup with the additional 24k. 64k would have been prime though. 8k is just fairly limiting. It means throwing more rom at it or putting ram on the hucard.

 Yeah, original CD games are starved for ram too. Except for a few games, most load all sprites and tiles into vram for that level, all sound FX into ADPCM, and leave the 64k of ram for code and map/level data. Most original CD games don't even bother compressing the graphics. The SuperCD breathes much easier thanks to the extra ram. Not only that, but optimized SCD games tend to use LZss compression schemes and leave the data compressed in CD ram. A small amount is coupled with the 8k to give the "work" ram area a large working range. Usually +16k. A few games use self modifying code (more of convenience than speed; no need to take up variable space at page $2000 or map ram in, for temporary work variables) like Dracula X.

 If you look at Gate of Thunder and Lords of Thunder, both games compress the graphics with LZss schemes, and while the game logic is running, it'll run a background process to decompress assets ahead of time. IIRC, GoT even does linear to planar conversion after decompressing.

 The original CD should have been 192k-256k range and the SCD as 448k-512k range. The ADPCM ram is slower in speed and port based/accessed. They could have made that area much larger for hybrid fast/slow ram configuration. I'm sure that ram was cheaper than the faster ram.