Shamefully noob question about 32x framebuffer sizes

Ask anything your want about the 32X Mushroom programming.

Moderator: BigEvilCorporation

Post Reply
djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Shamefully noob question about 32x framebuffer sizes

Post by djcouchycouch » Thu Feb 07, 2013 4:16 pm

From what I can see, the 32x frame buffer size is 128k with a resolution of 320 by 240 (PAL). Yet 320 * 240 * 2 bytes per pixel = 153600 bytes -> 150k.

I don't get it.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Thu Feb 07, 2013 4:55 pm

Indeed, when you use the 15bpp mode you don't have double buffering :!:

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Thu Feb 07, 2013 6:21 pm

Found this which enlightened me a bit. http://www.valpocl.com/SuperVDP/32x_hardware_manual.pdf

So, the 128k framebuffer is available for every mode and that's it?

Looks like if it's the 16 bit mode, you get one buffer of 320 x 204.

If it's an 8 bit mode, you get double buffering at 320 x 240? But that still takes 150k for both buffers. Or you just have 320 x 204 as double buffer?

What's the "overwrite" framebuffer for? I thought it was used as the second framebuffer for double buffering.

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Thu Feb 07, 2013 8:01 pm

So, the 128k framebuffer is available for every mode and that's it?
Looks like if it's the 16 bit mode, you get one buffer of 320 x 204.
Well there are two independent 128K framebuffers that you flip between on alternating frames. So in 16-bit mode each one can hold a 320x204-pixel image. In 8-bit mode there's enough to hold a 512x256-pixel image.

That's why the line table is useful in 8-bit mode, so you can scroll around the large framebuffer and see a portion of it through your regular 320x224 window.

Also if you mask part of the screen with the Genesis video layer, you could do other sizes like 256x512, etc and just hide the repeating part. ;D
If it's an 8 bit mode, you get double buffering at 320 x 240? But that still takes 150k for both buffers. Or you just have 320 x 204 as double buffer?

Oh, it's not like you have to split the 128K of a single framebuffer in half for double buffering, since you have two 128K framebuffers already.

In 8-bit mode, you do have enough RAM to hold two 320x204 screens _per_ framebuffer, so in theory you could do four-frame buffering:

1. Show framebuffer 1's first 320x204 area
2. Show framebuffer 2's first 320x204 area
3. Show framebuffer 1's second 320x204 area
4. Show framebuffer 2's second 320x204 area.

A bit like DOOM does.
What's the "overwrite" framebuffer for? I thought it was used as the second framebuffer for double buffering.
The overwrite area is a copy of the frame buffer where zero-value pixels aren't written. So if you have a sprite padded with zero value pixels, you can write the whole thing to the frame buffer without doing a read-modify-write operation to only plot the opaque pixels.

It's sort of a nice way to blast irregularly shaped objects to the framebuffer quickly.

About your original question, yes, there isn't enough RAM for the NTSC 320x224 or PAL 320x240 displays in 16-bit mode, so you have to letterbox the display slightly to 320x204 or smaller. Kinda sucks, but there you have it.

EDIT: Chilly said it better. :D
Last edited by Charles MacDonald on Thu Feb 07, 2013 8:07 pm, edited 2 times in total.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Feb 07, 2013 8:03 pm

EDIT: Ninjaed!

There are TWO 128KB banks of ram for video in the 32X. While the VDP is showing one bank, the CPUs can write in the other bank. If you are looking at the 32X Hardware Manual - look at pages 42 and 43 for how you switch which bank of 128KB is being show and which bank you will be drawing to.

Note that 128KB is only enough for 204 lines in 32K color mode. You either need to make your game 320x200, OR you can reuse lines. The line table offsets do NOT have to point to different lines... they can point to the same line. In fact, that's how you make a 320x200 display - you point the first 200 lines to where you are storing the actual display in the frame buffer, and the next 40 lines point to a spot in the frame buffer that is always blank.

In 256 color mode, you have plenty of space for 240 lines... 320x240 is only 75KB, and there are 128KB in each buffer. That allows for more space in 256 color mode which allows for scrolling. For example, if you were making a vertical shooter, 256 color mode gives you enough space for 408 lines to scroll through. Scrolling in either direction is done by changing the offsets in the line table. In 256 color mode, you scroll horizontally by one pixel using a register since the offset in the line table covers TWO pixels at 256 colors.

I expect you would allot the first 8 to 24 lines worth of space for a HUD/status panel, then use the rest of the frame buffer for scrolling. REMEMBER - the first 256 words in the frame buffer is reserved for the line table, and all the rest to 128KB is free to use in any manner you wish. For example, if you only used 320x240 in 256 color mode, the remaining space could be used to hold game data, like tile data used in drawing the 320x240 display. A 320x240 display would leave 128-75=53KB of space for tiles. :lol:

EDIT 2: One note on the frame buffer and overwrite areas - the fraem buffer is ALSO an overwrite area, but for byte writes! If you write data as bytes to the frame buffer, writing 0x00 does NOTHING AT ALL. If you write bytes and need 0x00 bytes, you must clear the frame buffer first. The overwrite area works on words - the part of a word that is 0 is not written.

This "odd" operation of the frame buffer caused me a little trouble when I first started Wolf32X since I was not getting 0x00 written in the frame buffer.

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Sat Feb 09, 2013 7:48 pm

In 256 color mode, you have plenty of space for 240 lines... 320x240 is only 75KB, and there are 128KB in each buffer. That allows for more space in 256 color mode which allows for scrolling. For example, if you were making a vertical shooter, 256 color mode gives you enough space for 408 lines to scroll through. Scrolling in either direction is done by changing the offsets in the line table. In 256 color mode, you scroll horizontally by one pixel using a register since the offset in the line table covers TWO pixels at 256 colors.
In my very humble opinion as a novice, scrolling on framebuffers doesn't get you much since you have to constantly redraw the entire screen anyway to account for the fact that the images of moving objects or animated things need to be redrawn over the background image. Maybe the technique is more useful if using the mode where the sprites or other layers are drawn by the MD on top of the 32X output. Or perhaps in special cases where you have some very static display and want to move the screen around for an effect.
For example, if you only used 320x240 in 256 color mode, the remaining space could be used to hold game data, like tile data used in drawing the 320x240 display. A 320x240 display would leave 128-75=53KB of space for tiles. Laughing
I think the idea of using the "leftover" space as extra memory to store things like tiles is an excellent idea! it was something I wanted to try, how would it perform vs reading from ROM or reading from normal RAM?

Post Reply