Missed opportunities....
There are a ton, hardware wise. We know from articles and interviews that the PC-Engine itself was always destined for more than what it was released as. The PCE by itself was nick named the 'core' system. The CD addon was in development and show cased even before the system was officially released. But onto specifics.
- Lack of adequate core ram. More than just speculation, it's believed that the PCE original was developed with 32k of ram in mind, but only shipped with 8k. The upper 24k is just the 8k mirrored, not open bus. Fittingly, the SGX actually populates this mirrored ram with the additional 24k to make the original 32k ram. 8k of ram is limiting. It limits the type of compression schemes you can use. It limits caching decompressed data for later parts of levels (instead of doing it real time).
- The cut back of vram to 64k. The VDC has full access to 128k of vram. The arcade Bloody Wolf which is basically just a PCE without a VCE, has that full 128k. It has all the player and enemy frames loaded in. Having larger vram space also means you can use better compression schemes and cache the frames into vram (like you would normal ram). I would have put more emphasis on this than regular system ram. Especially when you consider the CD addon original only gave 64k of work ram (simulated cart rom).
- The lack of any second BG layer. Scrollable or fixed overlay/underlay. The PCE is setup to have a digital pixel bus to another device. That type of setup is used in quite a bit of arcades system, to mix different layers of different video chips. In the context of the PCE, the VCE is almost a waste. Bloody Wolf gets by just fine without it. It makes me wonder if something else was planned but cut. Maybe the SGX was closer to the original PCE design, but was cut down due to costs.
- Audio. It's not surprise to me that the stock audio isn't miles ahead of the NES or even home computers at the time. The CD addon was more than likely to be their key marketing advantage. The difference of chips tunes like the PCE has, to that of CDDA audio - only strengthens the CD addon's value. There are upgrades that can be done via cart (mono input being one of them), but also a higher res timer. You can use the scanline interrupt (all 262 lines) to make 16khz audio, but it's rather expensive. An external timer that you resync on vblank INT would be perfect. It could even digitally mix channels for you and output them on two 5bit channels (10bit output), etc. But of course, hucards were replaced with dominant CD format fairly earlier on. The real mist opportunity is on CD games. You have 6 channels to use at once to make some really unique and great sound FX, yet more settled back on generic/typical PSG-ish tiny type SFX.
- CD addon memory. The original CD addon memory was DRAM. DRAM is/was much less expensive than SRAM. Yet they only included a measly 64k. With only 64k of vram, 64k of simulated cart space is pathetic. They should have gone at least with 128k. At least that. It ended up costing them more in the long run because the there is no /RDY for DRAM interface on the cart port (on the expansion bus), so the 192k upgrade ram on the SCD card is SRAM. Much more expensive than DRAM. They should have started out with 192k or 256k of DRAM to begin with. I mean, considering the cost of everything else in the CD addon base ( the MCU, the cd drive logic, the ADPCM IC + ADPCM ram) - it would have been relatively low.
- VDC. The VDC in the PCE (basically THEE video chip) spends quite a bit of time doing nothing during active display. IIRC, it spends have the scanline doing nothing. It gives all those slots to the CPU. For an engineering standpoint, that's fairly wasteful. There's totally enough time to actually fetch and build another BG layer there. But more important than that, is how amazing fast the VDC fetches all the sprite pixels. It does it in the short amount of time of hblank. No other system does that. Other other systems from that era use the whole scanline to parse and fetch the sprite pixel data for the next line. Not the VDC, does it all in hblank. But here's the kicker... there's only 64words of memory for sprite line buffer. That's 256 4bit sprite pixels. The VDC is fast enough to fetch much more than that, and it tries - but there's no more space to store them so they get dropped. Considering they chose not to have a second BG layer or static under/overlay window, they should have AT LEAST increased this to double the size. They had to have known that developers were going to fake BG overlay parts with sprites. Making sprites all the more important. Plus, that means the sprites to scanline ratio with also scale with the increase resolutions (mid res, high res). But because of this limited buffer, it doesn't. That's more said than
any missing BG layer. Such power wasted and crippled by a small internal buffer. To me, that's the single best mist opportunity of the system design.
- Yes, the SGX could have been made an addon. But not as it is. The extra 24k of ram sits where it's normally mirrored on the PCE. If you try to make ram there either via cart or expansion bus, you'll get a bus conflict. Just won't work. But everything else, yes. But there's a simple solution for SGX software to see if it's running on the main console or as an addon. It tests the mirror ram, if present then it used alternate bank mapped ram. Simple as that. I came up with this idea because the CD system card does just this. There's a reserved bank number in the last few bytes before the vector address of the system card rom. CD software take this value and use it as the starting bank for CD ram. Oddly enough, Gate of Thunder actually tries to change this byte in rom. From what Charles MacDonald told me of the CD dev card, system rom and ram are in different places - so this starting bank number was put there for a reason. GOT have some left over dev card routine to change it, but since it's rom it doesn't change. Anyway, the very same method could have been used to play SGX games on the main SGX system or the addon SGX upgrade.
- CD addon. The CD addon was in development when the PCE was too. Though the PCE was release first (and a year apart IIRC). The initial faults of the PCE should have been clear in the first few months. The CD addon could have addressed some of these. Adding a second VDC to the CD addon is VERY doable. It doesn't even have to be as extravagant as the SGX. The original VCE output would be ignored and a new VCE inside the CD addon could have upgraded the RGB resolution to 12bit too. Or some other scheme ( a 10th and 11th bit for half intensity and double intensity in the RGB entry), etc turned on by a special reg otherwise left disabled for compatibility reasons.
Adding the video upgrades, even if less than what I suggested (maybe just a static overlay/underlay 8bit image and a new VCE palette expansion) - would have made the CD addon stand out even more. And when the Duo was released, it would no problem matching the level of the SFC and MD hardware wise.
Sega f*cked up. They didn't have even half what the PCE had for an expansion bus. Yet they tried everything they could to have the MegaCD more advanced. It was... no it IS hackish. If you even dev'd on the SegaCD then you know exactly how hackish it is. The PCE had all the right pins and access lines needed to make a real hardware addon.... and they squandered that opportunity. They squandered the opportunity to make the CD addon and incredible upgrade that it could have been, not just some addon with a few frills here and there.
