HuC6270 is a video display controller

Video Display Controller

A Video Display Controller or VDC is an integrated circuit which is the main component in a video signal generator, a device responsible for the production of a TV video signal in a computing or game system...

 (VDC) developed and manufactured by Hudson Soft

Hudson Soft

, formally known as , is a majority-owned subsidiary of Konami Corporation is a Japanese electronic entertainment publisher headquartered in the Midtown Tower in Tokyo Midtown, Akasaka, Minato, Tokyo, Japan, with an additional office in the Hudson Building in Sapporo. It was founded on May 18, 1973...

. The VDC was used in the PC Engine game console produced by NEC Corporation in 1987 and in the SuperGrafx

SuperGrafx

The SuperGrafx video game console is an upgraded version of NEC's popular PC Engine system. At first it was known as the PC-Engine 2—which was purported to be a true 16-bit system with improved graphics and audio capabilities, not expected to see release until 1990...

 and TurboGrafx 16 also developed by NEC.

Besides NEC, the VDC was used in two arcade games. The arcade version of Bloody Wolf ran on a custom version of the PC-Engine. Arcade hardware is missing the second 16-bit graphic chip known as the VCE, that is in the PC-Engine. This means the VDC directly accesses palette RAM and builds out the display signals/timing. A rare Capcom quiz-type arcade game also ran on a modified version of the SuperGrafx hardware, which used two VDCs.

The HuC6270 is responsible for building the main image of the system (background and sprites). The chip itself is able to create or generate all the timings needed to build an output signal, but in the PC-Engine is works in slave mode. Where the VCE builds the frame timings for the video signal and the VDC uses the H and V sync lines as input (rather than output) to keep things in sync. But the VDC is still able to define its own video frame inside the VCE's output frame. Both horizontally and vertically. It is possible to define multiple frames both vertically and horizontally. Coryoon does this when you enter in the 4 split screen mode of the sound test option.

While the VCE supplies the H sync signal for the VDC to generate an interrupt for the CPU (for scanline effects/changes), the VDC can also define its own H sync interrupts, causing multiple H interrupts on a single scanline. The VCE also sets the resolution of the VDC. It supplies the divided clock signal, of the master clock. The VDC runs either faster or slower, depending on this 'dot clock' setting. But it doesn't know what speed it's running. It's up to the programmer to correctly set/match up the VDC horizontal settings to be in sync with the VCE.

The VDC has a number of VRAM read/write slots open for the CPU to use during active display. The number of slots are actually faster than what the CPU could possible use/fill. But if the CPU was fast enough, the VDC has a means of stalling the CPU. This is attached to /RDY pin of the HuC6280. This is a unique attribute of the VDC, as other systems of that era (both 8-bit and 16-bit) had extremely restrictive and/or no access to vram during active display (doing so usually corrupts the display). This means the CPU as the option of updating vram outside of the normal and relatively small vblank time.

Sprite pixels are fetched hblank time, not during active scanline like similar systems. Relative to other systems, the VDC both parses and fetches all the sprite pixel data in tiny amount of time at a impressive speed for its era. The VDC has an internal buffer that hold all the sprite pixels for the scanline. This holds a maximum of 256 4-bit pixels. The VDC can not display more than this on a single scanline and any sequentially placed sprites on the line won't be shown. The order of which sprites have priority in the scanline buffer, is direct relative to the top down list of the SAT (sprite attribute table). An alternative to sprite 'drop out' is to cycle between two sets of SAT lists as 60 Hz. This is known as 'flicker'; a common display artifact effect of the time. This isn't automatic, but handled by the programmer. There's a sprite overflow detection flag which is set when sprite drop out happens. The programmer can then decide what to do about the problem based on the state of this. Most games handle the problem with the flicker method. Some games do not. VRAM read/write by the cpu is off limits when the VDC is filling the sprite scanline buffer during hblank. Depending on how many pixels are fetch, is how long the wait is. But in terms of transfer, it's fairly unnoticeable. If accessed during this time by the CPU, the VDC delays it after the one-WORD FIFO is filled. The if the frame settings are too wide, too much active display is set into the overscan area, this will cause the VDC to not have enough time to fill the 256 pixel buffer and will start dropping off sprite cells per 8 cell segment frame define.

Sprite size are made up of a matrix of 16×16 sprite 'cells'. When sprite dropout happens, it happens on a sprite cell basis; not at a matrix defined level. The sprites sizes are: 16×16, 16×32, 16×64, 32×16, 32×32, 32×64. The larger size sprites have a memory alignment requirement that must be met, else parts of the sprite won't show. The sprite attributes are defined in the SAT (sprite attribute table). The size, the sub palette #, BG priority, and the X/Y flipping options. The subpalette value ranges from 0 to 15 and are separate from the BG subpalette range of 0 to 15. Flipping options apply to the sprite as a whole (matrix), and not individual cell basis. Inter sprite sprite is directly based on first in line. The sprite defined in a top position of the SAT will always show above sprites lower in the attribute table. The BG priority flag tells of the VDC if the sprite should be shown above or below the background layer. No sprite can be made to be shown behind BG color #0 (which is considered its own layer because of this). The priority of the sprite in relation to the BG layer, does not change inter sprite priority. Maybe PC-Engine games use this exploit for force sections of the background to appear above sprites, in a pixel level basis. Ys I & II whenever a sprite appears behind a section of the background. The common method is just to use a simple pixel mask, instead of having to store redundant pixel data of the BG as sprite. This saves space and also allows the mask to be use for multiple BG sections, if the outline is the same but different color/pixel detail. Another game exploits this to get a translucent graphic effect; Jackie chan. The exploit is where the logic of the per sprite priority causes the sprite underneath the BG layer to show instead of the high BG priority sprite. But since the sprite is being masked by BG pixels, the BG pixel data is pushed to show on top of the top-layer sprite - when passing underneath/top of it.

The sprite pixel data is a different format than the BG tile format. The sprite data is stored in sequential 1-bit planes and not interleaved like tile planes. The reason for this is that the VDC is a complete 16-bit memory device. All memory (registers as well as vram) is accessed as WORDs. The VDC fetches 16 pixels at a time, four times, Once from each plane. That's wide the cell size is 16 pixels wide. By comparison, the tile data is 8 pixels wide. So when the VDC fetches a WORD for tile data, it grabs 8 pixels for plane 0 and plane 1 at the same time. Hence the composite nature of the tile format, in contrast to the sprite format.

The VDC outputs 9-bit digital pixel data to the VCEs pixel bus. The 9th bit is set when the sprite pixel is being sent by the VDC, instead of the tile layer or BG color #0 layer. This is how the VCE knows what section of palette ram to assign to have pixel. The logic is as follows: tile pixel = (palette # * 16)+tile pixel, sprite pixel = (palette # *16)+tile pixel+$100. This assumes tile pixel != 0 and sprite pixel != 0, else output pixel = 0 (BG color #0 layer).

The SAT is located in a special register set in the VDC. But a copy of the SAT must be in VRAM, in order for the VDC to transfer it. This is referred to as the SATB (Sprite Attribute Table Buffer). If the DCR register has the specific flag set, the SATB to SAT DMA will automatically happen once the defined displayable frame has ended. Otherwise it is not possible to change the internal SAT registers during active display (unless the VDC is set up to display multiple frames). The location of the SATB can be anywhere in vram. The maximum size of SATB is 64 entries or 512 bytes (256 WORDs). The SAT size or sprite scanline buffer do not change with changing of the 'dot clock' resolution, like with the Genesis and other similar systems. Giving it a disadvantage for higher resolutions for sprite to scanline pixel ratio.

Only one background layer can be shown by the VDC. This is the tilemap. It can be configured to a number of sizes; 32×32, 32x64, 128x32, 64x32, 64x64, 128x64. The X and Y size are multiples of 8 pixels. For example, a 32×32 setting is a 256×256 pixel map. The tilemap mirrors/wraps both vertically and horizontally and are independent of the display frame for that given scanline. The tilemap position relative to the display frame, starting from the top, is controlled by the BXR and BYR registers. These registers are latched at the start of every 'VDC' scanline. At using a horizontal scanline interrupt, it is possible to change both the X and Y offset of the tilemap on any scanline. This is how many games divide the display into different scrollable areas (see Air Zonk for example). Other effects can be made with this method, including stretching or shrinking the background layer vertically or distortion effects.

The VDC registers are independent are of VRAM access. They also aren't shared for building the display like the Famicom display registers, making mid-frame effects stable. The latch systems facilitates in this as well. But certain registers are latch as specific points. Some are latched per scanline, some are latched per frame end. Horizontal frame build registers are latched per scanline and vertical frame build registers per frame end. All the VDC registers are 16-bit, but registers themselves are buffered with no latch systems. This means either the upper or lower byte can be changed without writing a whole WORD update.

VDC memory range is 64 kWORDs (128 kbytes), but only 32 kWORDS (64 kbytes) are installed. Access to the upper range is open bus. The tilemap entry is 16-bit or a single WORD. 12-bit is the tile address (in 16 WORD offsets), 4-bit is the subpalette assignment. There is not support for tile flipping or per tile priority. The tilemap can address tiles anywhere in vram, including the tilemap location itself, which is fixed at starting point of $0000 and unchangeable.

Lastly, the VDC only has two DMA modes. One is the SATB to SAT DMA. The other is vram to vram DMA. The DMA is separate from the CPU other than the setup/request time. Neither DMA's can happen during active display. The dot clock/speed of the VDC directly affects the speed of these DMA operations. Not only it is possible to switch to any resolution mid-screen (on any scanline), but also during vblank area as well.

The VDC builds a total of four graphics layers: G/S'/B/S. G = BG color #0. S' = low BG priority sprite. B = tilemap/background layer. S = high BG priority sprite. There are no known revisions to the HuC6270, like the HuC6280A and HuC6260A.