1: Do PCE CD games use the IFU/System Card ram (.5/2/18 megs) instead of the base PC Engine's 8kB of work ram in order to run games, therefore making the CD games which do, technically impossible as-is on HuCard (aside from adpcm/redbook)? In other words, does the Arcade Card upgrade the PC Engine's 8kB of work to <18+ Mb of work ram?
The 8k of system ram is used as it normally is for hucards, as it is for CD games. It's just that CD games have the option of expanding what is 'ram' and what is 'rom' (storage). It's common for SCD games to use 16k or 24k reserved as 'ram' (that includes the original 8k system ram). This needed for when you have compressed data that needs to be unpacked on the fly and such. For CD 2.0, this is a tough choice to make since there's very little CD ram to spread around. So for CD 3.0, it's doesn't carry as much consequence for that layout.
I wouldn't say that it's impossible, though. The part of CD ram that's being used as general purpose ram, is done so more for decompression than variables. If that was on hucard, you could simply add that ram to the hucard (which is what Populous does), or you could use large ROMs to offset the requirements - or do what SNES does and put co-processors or special chips that do realtime decompression. Either way, aside from ADPCM and CDDA - nothing is impossible on hucard that's done on CD. Matter of fact, hucard offers more options since each hucard project allows unique hardware advances on the hucard itself - where as CD is fixed by its environment.
2: How exactly does adpcm work in CD combos? I've been led to believe that all samples used within a single load have to fit inside the adpcm's 32kB of memory. Do CD games instead actually use the IFU/System Card's .5/2/18 megs of memory to store samples and then just run them through the adpcm chip when needed?
ADPCM is 64kbyte, it's the samples that are nybbles (thus 131,072 total samples possible). ADPCM ram sides outside the CPU direct access, unlike CDRAM. It's also the only ram in the system that you can request the CD unit to DMA to (transfer from the CD to ram without any CD intervention with manual copying labor). The CPU on the PC-Engine side has access to this memory through a port; you can read and write to this port (1 byte at a time). You can do this while it's playing too. So yes, the CPU can write to ADPCM ram, and can read stuff out of ADPCM ram. The data is byte sized and is just data. Some games put TEXT or graphics and other stuffs in there at load time (the first Spriggan games does this, Ys 4 also does this). It's just that access to this ram is slow, even for linear/sequential access (there's a 24 cycle delay between reading or writing of each byte). ADPCM ram is used as storage in both context/situations, not as makeshift ram. It's waaaaay too slow for that and access is limited to fixed 1 byte increment to the offset (positive only). Maybe there's a game that's an exception to the rule, but none that I've see and given anyone that's coded for the system - it's pretty apparent why it's not use as general purpose ram, but as storage for samples or data (slow access cart space or serial "far ROM").
I thought that the only difference between between CD and HuCard games was the two extra sound channels which play adpcm and redbook exclusively and that the IFU/System Card memory is strictly used to store regular game content, like a temporary HuCard rom.
That's basically it, but later SCD games do allocate some of the ram for general purpose (or rather, decompression buffer). This is from my experience of debugging CD games and tracing through game code (I've looked at quite a few games).
The Arcade Card adds additional memory and the cpu accesses it similar to the way ADPCM is accessed, but it provides a specialized interface to allows much more flexibility; four address vector registers. And unlike ADPCM ram, you can access it by windowing, and auto-incrementing as both positive and negative values: much more flexible. But even then, using it as
general purpose ram is slow and not the norm. You can use it as a decompression or whatever type of buffer (as long as it's not random access, else it's slow), but given that it's soo large - game makers just load it as the start of an area/stage and treat it as 'cart space'.
So from what I've seen, and apparent reason, is that it's basically used as port ROM. You use it as read only memory from the game logic point of view (cart space for the level), but all that's really there is graphic data and maybe map data. Load from the CD to ADPCM ram, and treat it like "far ROM". But it's setup in a way that makes it as fast as reading regular memory (in linear step increments), which is great for directly copying moving stuff to VRAM. The ports make the access feel more transparent (treat them like ZP address vectors). But again, there's nothing like this that can't be done on the hucard side, or that SNES or other systems haven't done (snes has co-processor setups for when 'far rom' isn't directly accessible by the main/original processor).
Stock ram setup does make hucard projects more limiting, but nothing that added ram couldn't fix. NES had extra ram on carts to make up for it's small stock ram. But you have to think about how ram is used; hucards suffered more because they lacked a buffer to pool data from - thus didn't use better compression algorithms for more animation and detail. One could argue that when they did use weaker compression schemes that lent to decompressing on the fly, that this added cpu overhead in realtime. But I see that as a design limitation around rom space, than anything else. So technically hucards could do anything CD games were doing, but in practicality.. given only one game used added ram and most were under 8 megabit, CD games did have an advantage in that respect. CD 2.0, not so much, but SCD 3.0 they did - because hucards didn't scale as well (only in limited rom size). Just look at Parodius on SNES vs PCE, right? IIRC, both are 8megabits. But the SNES has the added advantage of 128k of ram to work as a decompression buffer/cache, allowing more efficient (non real time) compression schemes.
Anyway, that's my feedback based on my experiences with the system and the two formats.
Topic: A couple technical questions (Read 316 times)
