-
Notifications
You must be signed in to change notification settings - Fork 3
Video
Video is very simple in the 32x compared to the Genesis VDP. First of all, only a frame buffer is used, so all drawing should be stright foreward, and linear. There has always been talk that the 32x has internal hardware for rotating and scaling, but this isn't true, all is done in software. The slave sh2 usually handles all complex video effects. The 32x video can also be appear on top, or on bottom of the Genesis VDP video, depending on 32x priority levels.
- PAL = 240 lines of video, screen is refreshed 50 times per second
- NTSC = 224 lines of video, screen is refreshed 60 times per second
In this mode, the CRAM is used to reference the RGB values for the colors used for each pixel. The data in the frame buffer points to the data in the cram to generate color. Each byte in the frame buffer corresponds to one entry in the cram.
In this mode, the Frame Buffer Data is used to reference the RGB values for the colors used for each pixel. Each word in the frame buffer corresponds to one pixel. The CRAM is unused in this mode.
This is a weird mode for the 32x, although there are many purposes for it. A pixel in this mode is generated by a CRAM entry reference, and a number to count how many times to display that given pixel, like RLE compression. This is almose like VDP MODE 1 using 8 BPP, except that each data display entry is 2 bytes.
The 32x can generate a maximum color palette of 32768 colors. There is also a priority bit, which selects priority between which will be drawn in front of the TV, either the Genesis layer, or 32x layer.
The 32x has two memory sets for displaying graphics. When one memory location is used, graphics are displayed from that location, and no graphics are displayed for the other. These two different locations are called frame buffers, and are 128k bytes each. The 32x selects between them by writing to the VDP Status register, and the frame buffer select can only be changed at any time. When one frame buffer is used, then that frame buffer is displayed on the screen, and the other frame buffer is not displayed, but reads/writes can be made from the frame buffer memory space.
The difference between the frame buffer and the overwrite areas:
- Frame buffer: writing bytes of zero ignored, writing words of zero okay
- Overwrite: writing bytes or words of zero ignored (also applies to Direct color mode)
The first 256 WORDS are the line table... well, the first 240 since that's the maximum number of lines the SuperVDP can output (in PAL mode). Each word is an offset for the related line in the frame buffer. It's a WORD offset, not bytes. This means that using the line table for scrolling moves 256-color pixels by two pixels at a time. Because of that, the SuperVDP has a one pixel scroll setting. Note that Sega specifies that lines start at word 256 or higher. Clearly, you cannot start a line at 0 as that's the line table itself. Starting the first line at 256 puts you beyond the line table.
The SuperVDP fill data is a single word that is repeatedly stored to the frame buffer. Please note that the fill cannot cross a 256 word boundary, and has a max length of 256 words. This makes it rather limited for use. With a little effort, you can use the fill hardware for solid poly raster line drawing... which is probably what Sega meant for the fill hardware. While the SH2 rasterizes the poly, the fill hardware actually draws the solid, single-color raster line. That's great for games like Virtua Racing. You can use it to clear the frame buffer, but you'll need to loop over filling sections of 256 words to fill the entire buffer. That may be the fastest way to clear the buffer, but whether or not it's the BEST way depends on the game. As mentioned before, you might not need to clear the buffer at all.
Another limitation: you cannot use SDRAM and fill at the same time. Only one SH2 can use the filler, MUST run from cart, and not access SDRAM while the fill is in progress. The other SH2 must not access SDRAM during that time as well.
Address 20004102H
When LSB is set to 1, the screen is shifted by 1 pixel to the left.
Switching is allowed at any time, but is only valid from the next line.
The shift bit becomes invalid when the lower byte of the base address set in the line table is $FF. Therefore, make sure the lower byte in the table is not $FF when using shift.
32X Technical Bulletin #14 - VDP shift bit precaution - [1994-09-23]