A couple technical questions

[CrackTiger]

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?

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?


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.

[FraGMarE]

I don't know if most CD games do or don't use the 8kB of work RAM within the PCE, but to my knowledge, it *is* accessible to CD games.  The 64kB of ADPCM RAM can be loaded in addition to whatever it loaded into the IFU/System Card RAM.  The ADPCM RAM can even be loaded with graphics/data, rather than audio, but accessing it is rather slow compared to the IFU RAM.  I believe, if i'm not mistaken, the code within the IFU RAM can also self-modify, whereas the code in a ROM cannot.

[touko]

Yes the system card RAM, is RAM and not ROM, and you can use it like that you want, store datas/program or classic RAM to extend the 8ko of base RAM .
And yes, you can also use the AC as ram, this is not as practical as mapped ram, but easily doable,you can even use VRAM if you want  .

The adpcm RAM is 64ko, and store (usualy) 4 bit adpcm datas .Those are read by adpcm chip independently of PCE's CPU.
You just specify the start/length/frequency of sample that you want the adpcm chip plays .
Many frequencies are available between 2khz,and up to 32khz .

If you want some hardware infos : http://www.archaicpixels.com/MSM5205

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.

With SCD, you have 256ko available for each level, plus graphics datas you can directly download in VRAM.You have richer graphics, sounds and can have more levels for your game .

Nowadays, you can probably have a 64Mb hucard, but in 87->94 period it's 8Mb max (except SF2CE) .

[TurboXray]

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.