PCE is unique in that it has an internal buffer and 16 hardwired registers for each sprite on a scanline. The sprite table is transfered into the a special area of the chip right before the start of the frame. What ever changes one makes to the sprite table isn't updated until the next frame. Since the video processor doesn't have to "fetch" sprite info entries from vram like the position, size, flipped modes, palettes, sprite number (etc), it is able to give the CPU read/write access to VRAM during "active display". In 7.16mhz or 10.5mhz mode of the VDC, it has enough speed to handle more sprites and still have resource to let the CPU read/write to VRAM, but there aren't anymore internal registers to handle them. They could have increased the internal registers to more than 16, but such type of registers are a cost issue. Note: 5.37mhz mode is 256 pixel mode.
The NES, SNES, Genesis, and other systems are different. They have a buffer that they fetch all necessary sprite data per scanline into. Once the buffer is full OR it runs out of time, it stops fetching sprite data. There are *no* slots open for the CPU to access VRAM during active display on those systems because the processor is tied up busily reading from vram for both the sprite table and sprite data (among other things). These systems make all changes during what's called vblank. Vblank for consoles loosely means the area outside of the active display. If the SNES/GEN display is 256x224, then it has 38 scanlines of vblank. Some SNES and Genesis games turn off the display even earlier to gain more vblank time. To aid them the SNES and Genesis have a memory controller(DMA) that stops the CPU and transfers data from the CPU memory to VRAM for vblank because neither CPU is fast enough to transfer the data themselves considering a games structure.
The PCE has something similar in the form of CPU instructions though not quite as fast, but is not limited to vblank window of time. You can decode/decompress tilemap areas directly to VRAM without having to use main ram as a buffer,i.e. scrolling. Another advantage is that the PCE can have more than 64k if graphic data shown on screen at once even though VRAM is only 64k. It can write to VRAM ahead of the display as the display is drawing. I don't know of any games that uses this though. There are still some tricks you can do with the PCE's video system that no developer has done. Like reading out X/Y scroll tables from VRAM for hsync effects or using VRAM as buffer to store and play a frames worth digitized PCM samples at 16khz with less overhead. And still another advantage is that you can directly output to VRAM from a renderer, like a scaling routine or a raycaster engine. I have a test engine that converts bitmap or rendering on the fly directly to VRAM and automatically converts the pixel data to planar using clever arranged tiles and setting the vram write incrementor. Did I mention it's really fast too?
Maybe you could find some hot college girl to read that to you
Topic: Technical question about PCE resolution choices (Read 485 times)
