Espozo wrote:
IREM wrote:
Rotation and scaling functions are good.
Oops, I misunderstood you because I got "VPC" and "VDC" confused... I still wonder how the second sprite layer can go over the first BG though. Also, one thing, is everything completely split up? I mean, is it like sprites 0-63 use color palettes 0-31, and sprites 64-127 use color palettes 32-64? I imagine so, if the color palettes are on the video chips and not external like on the Neo Geo. I wonder if vram is shared though.
The original PC-Engine setup has two video chips; a VDC and VCE. The VDC is what builds a raster display from the tilemap and sprite data. The VCE generates the NTSC frame timing and holds the color palette data. The two are connected via a digital pixel data bus. The VDC outputs a 9bit pixel/value on the bus, the VCE receives it, uses that as an index into 512 RGB ram. The VCE also outputs the clock signal to the VDC, so it's able to set one of three speeds for it; 5.37mhz, 7.16mhz, and 10.74mhz.
The VDC pixel format for the data bus, works in a way that the highest bit is used as sprite pixel indication. The VCE uses this for the upper 256 entries, with the lower 256 entries thus being for BG.
The VPC sits between the VDCs and the VCE. Both VDCs of the SGX output their digital pixel bus to the VPC, which can tell if the pixel is from a sprite or the BG - from either VDC. Thus it can create priorities knowing this information, and which pixel bus data packet to send to the VCE pixel bus. The VPC also has window clipping options (that you can change per scanline) in which you can turn each of the VDC outputs on and off. This is controlled with the definition of two window display regions and how they overlap (4 possible scenarios).
Here are some window exploit demos:
https://www.youtube.com/watch?v=75IdGO1I1o4https://www.youtube.com/watch?v=0dVFfrfvmeYThis one is just a priority exploit demo (similar to how the PCE does it)
https://www.youtube.com/watch?v=9N4xgkwm154 VRAM is not shared between the two VDCs; each have their own 64k(byte) of vram.
As to the question of hucard games, most PCE hucard games used RLE based compression. There isn't a lot of ram on the base system. 8k will get the job done, but there isn't enough memory to buffer decompressed graphics. So either you decompress the graphics for a stage/area all into vram (at the start of an area), which limits the animation and BG detail of an area, or you use a compression scheme that is fast enough to decompress realtime while the game is running. And that's basically why you see simple compression schemes for hucard games. Chris mentioned 3bit format. That was
very common (as well as 2bit). Because the graphics are planar, it's also fast as well as easy to implement.
SuperCD games could section off a portion of CD ram as a buffer, and run LZSS compression schemes to decompress into this buffer area (or if more fancy, run the decompression as a background process over a period of frames). I have yet to see any LZSS compression style schemes in hucard games, though the only hucard I suspect of using it is Parodius. So the additional ram of the SGX definitely helps in that respect, but I still don't know if what compression schemes the five SGX hucards employed.
The SGX also included a revision to the PCE audio chip. You can use a single channel's audio buffer to stream higher frequency samples at a much lower cpu overhead. Instead of feeding a single sample at 7khz, you can feed 16 samples every 1khz. You don't need to use all of the 32bytes of the buffer. I was able to do 43khz with a ~2.3khz interrupt feeding it 18 samples per call. It sounded pretty clear. You could interleave data for multiple channels at that rate.