VIC-III and VIC-IV information

append delete pmprog

I've been searching the c65gs blog and general internet, but I can't actually find anything about these graphic chips.

Does anyone have any documentation/links?

Reply RSS


append delete #1. adtbm

That's all i have found. No Data sheet or so....

CSG 4567 VIC-III chip:
Operates at either CSG 4510 clock speed without blanking.
Digital foreground/background control (using genlock).
Access to optional expansion RAM.
Horizontal and vertical screen positioning verniers.
Display Address Translator (DAT) allows direct access to bitplanes.
RGBA output with either synchronisation on all colours or digital synchronisation.
Composite NTSC or PAL video colour output with separate chroma/luma.
Composite NTSC or PAL digital monochrome output.
RF colour output via NTSC or PAL TV modulator.
Maintains the original C64 video modes:
40 x 25 standard character mode.
Extended background colour mode.
Bitmap mode.
Multi-colour mode.
8x sprites of 24x21 pixels.
Adds new C65 video modes:
40 and 80 character columns by 25 rows.
Colour, blink, bold, inverse video, and underline attributes.
True bitplane graphics:
320 x 200 x 256 (8-bitplane) non-interlaced.
640 x 200 x 16* (4-bitplane) non-interlaced (plus sprite and border colours).
1280 x 200 x 4* (2-bitplane) non-interlaced (plus sprite and border colours).
320 x 400 x 256 (8-bitplane) interlaced.
640 x 400 x 16* (4-bitplane) interlaced (plus sprite and border colours).
1280 x 400 x 4* (2-bitplane) interlaced (plus sprite and border colours).
Colour palettes:
Standard 16-colour C64 ROM palette.
Programmable 256-colour RAM palette, with 16 intensity levels per primary colour (for a total of 4096 colours).

System Specification for C65 Fred Bowen March 1, 1991

Display Address Translator (DAT)

The C4567R6 contains a special piece of hardware, known as the Display Address Translator, or DAT, which allows the programmer to access, the bitplanes directly. In the old VIC configuration, the bitmap was organized as 25 rows of 40 stacks of 8 sequential bytes. This is great for displaying 8 x 8 characters, but difficult for displaying graphics.

The DAT overcomes the original burden by allowing the programmer to specify the (X,Y) location of the byte of bitplane memory to be read, modified, or written. This is done by writing the (X,Y) coordinates to the BPX and BPY register, respectively. The user can then read, modify, or write the specified location by reading, modifying, or writing one of the eight Bitplane registers. There is one bitplane register for each bitplane.

The DAT automatically determines whether to use 320 or.640 pixel mode, and whether to use 200 or 400 line mode. It will also use the areas specified ir the bitplanes, using the Bitplane Address registers.
Horizontal and Vertical Positioning

The C4567R6 has two registers to allow the programmer to alter the positioning of the display relative to the borders of his CRT (television or monitor). Initially the positioning registers are set to zero, to give C64 standard positioning. These registers are signed, two's complement values which specify an offset from the default positions.
Chroma Killer

The C4567R6 provides analog RGB video, with sync on all colors, an analog luminance output, with sync, and an analog NTSC (or PAL on PAL versions) chrominance output. It also provides a separate digital video signal, and a separate digital sync. When using the C4567R6 with a black and white television receiver , it may be best to suppress the chrominance information. This can be done by setting the MONO bit in control register "B".
Additional ROM

The C4567R6 does all decoding for ROMs. It supports a total of 32K of ROM, which is 12K over what the C64 is configured for. This 12K of extra ROM is available in one 8K block at 8000 (hex), and one 4K block at C000 (hex). To enable ROM at these areas, set the ROM@8000 or ROM@C000 bits in Control Register "A". (Note that there are other chips in the C65 which extend this addressing limitation. The C65 has a 1MB ROM built-in.)
Alternate Character Set

Ordinarily, the C4567R6 will always fetch ROM-based character data from addresses DOOO-DFFF. If the CROM@9000 bit is set in control register "A", ROM-based character data will be fetched from addresses 9000-9FFF. This allows for an alternate ROM-based character set.

append delete #2. adtbm

The VIC-IV is an upgrade of the VIC-III done by the MEGA65 team.

One feature of it is i.e. bigger Sprites. But i think the Mega65 guys can give you a deeper insight.

append delete #3. LGB

See from section 2.4. However I am not sure if it gives more information.

What I could found for example, it contains some of the VIC-III information as well. VIC-IV indeed is a further-extension of VIC-III (which was the original chip in C65,CSG 4567, according to the documentation, as you've quoted too) for c65gs/mega65.

append delete #4. gardners

That's all generally right. For the VIC-IV, iomap.txt and viciv.vhdl are the effective documentation, which I freely admit is rather light-on at the moment.


append delete #5. LGB

By the way, what is not clear from me (even that document is confusing - for me, at least): where are the sprite pointers in bitplane mode, and what kind of memory is used to fetch sprite data then according to the sprite pointers? I guessed it's maybe bitplane 2 area (as it seems to be the one which is used with "classic" sprite features, ie collision, sprite-background priority, etc). However document states that sprite pointers are always at the high end of the video matrix .... Ok (natural stuff in case of VIC2 notion), just with bitplane mode you don't have classic video matrix too much, also the bitplane itself can be 8K or 16K (H640 bit) as well, so it's kinda unclear. Or maybe it is only for me :)

append delete #6. gardners

I think they are where the normal video matrix would still be pointing to, even when bitplane mode is enabled. When you think about it from the hardware perspective, that is the simplest solution. But I don't remember for sure. Perhaps the C65 demo will reveal this implicitly.

append delete #7. pmprog

Hmmm, are the source code to the demos on that YouTube video available?

append delete #8. Meshuggah333

Are VIC-IV specs set in stone or are they still in flux?

append delete #9. Deft

Not stone yet but they are moving only very slowly...lava has almost cooled down :)

I will clean up my Raster65 source code and post it here so you can get a good idea on how to code the beast ;)

append delete #10. gardners

Once VIC-III bitplanes are fixed, there may be one final round of VIC-IV fiddling and some residual bug-fixing, but after that we expect the spec to be more or less settled.

I did discover a funny little quirk with the screen background colour when behind text, however. We currently latch and buffer the border colour for the whole row of pixels in the character, instead of reading it afresh every video clock tick. Not sure yet whether to call this a bug or a feature...


(Leave this as-is, it’s a trap!)

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: Deft, gardners, Ralph Egas