Sega Genesis Dev Kit (SGDK)

SGDK only sub forum

Moderator: Stef

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

Post by djcouchycouch »

Something seems off about where the sprite table and window plane are located. The sprite table seems to be placed into the window plane. If I set the window to be the entire screen, the tiles get corrupted when there's scrolling and when sprites get created and destroyed.

Image

The brown striped tiles are good, the green stripped ones are not. The corrupted line underneath the green tiles seem to be where the sprite table is located. It changes when sprites are created and destroyed.

I don't know what the block of green striped tiles could be.

Memory locations are SGDK defaults.

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

Post by Stef »

Here're the default memory location of SGDK :

Code: Select all

#define WPLAN                   0xB000
#define HSCRL                   0xB800
#define SLIST                   0xBC00
#define APLAN                   0xC000
#define BPLAN                   0xE000
I do not allocate much for window to keep more memory for tiles.
Window is limited to 1024 tiles with default allocation, i do not remember if window width is aligned to plan A width or not.
Let's see, if we have plan A width set to 64 tiles, then having 1024 tiles allow a window of 16 tiles in height...
If you want to have bigger window, i guess you will need to change the default allocation (you can just change them in SGDK then recompile the library). Currently trying to writing data for a bigger window will corrupt your sprites data (and not the contrary).
djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch »

I only really need three or four rows of tiles for the Window at the bottom of the screen. Is there a way to configure it so that it only uses that much? Or, if I want to have a Window at the bottom, even partially, the Window plane in memory has to be the entire size of the screen?
Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef »

If you just use a small window it should work, do you correctly set the window position in VDP registers ?
I don't remember how window data are fetched but it would make sense to store data for only the window itself, at worse, the width of window plan can be taken from plan A as it should probably be a power of 2.
There is maybe some bugs in SGDK but after all i do not see what can happen as window is only an adress after all.
djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch »

From what I can see from the sega docs, the Window plane register settings are pretty limited. They just decide which section of the window plane to show. So it seems to assume that the window plane is at least the size of the screen, 64x64 or the same as plane A.

Seeing this, I can either move the window to the top of the screen or make the window memory larger to put the window at the bottom.
djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch »

I was working out the memory map. Looking at the VDP_Init() and the image, looks like the big green stripe section is actually the HScroll table at B800. Knowing this, it's not surprising that it changes when the game scrolls around :)
Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef »

I think you're right, the window use the same size as plan A... that is not very convenient as it requires many vram to use window :-/
I will probably change the window address in future version. I guess you can display it in the first 16 vertical tiles but not in bottom (or it will display hscroll and sprite data).
djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch »

If you allocated the full memory for the Window, you'd lose space for about 40 tiles?
Chilly Willy
Very interested
Posts: 2994
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy »

djcouchycouch wrote:If you allocated the full memory for the Window, you'd lose space for about 40 tiles?
A LOT more than that. It would be H*W*2/32, which for a 64x64 plane size would be 256 tiles.

It seems to me that since layer A and Window are mutually exclusive that you could point them to the same memory. You just have to remember when setting pattern names in A to skip over those names that are for the Window instead of A. If you do something like making W columns as tall as the display, or rows as wide as the display, it should be fairly easy to skip over what is A and what is W. Scrolling would make it a little harder, as would making W a corner of A instead of columns or rows.
djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch »

I think I only really need to use less than half the Window memory since it only needs to go down to as far as the 28th row. So even if the plane size is set to be 64x64, I'd only need memory for 64x32, (really using 40x28) so 4k. And the current setup uses 2k already, so I'd lose an additional 2k which is 64 tiles?

As a quick test, I tried moving around the memory locations for the sprite table and the hscroll table but it didn't quite work.

I used the same values as from the Sega doc, under VRAM Mapping, 40 tile mode.

SCROLL A PATTERN NAME TABLE
8K Bytes from 0C000H : REG. #2 = $30
SCROLL B PATTERN NAME TABLE
8K Bytes from 0E000H : REG. #4 = $07
WINDOW PATTERN NAME TABLE
4K Bytes from 0B000H : REG. #3 = $2C
H SCROLL DATA TABLE
2K Bytes from 0AC00H : REG. #13= $2B
SPRITE ATTRIBUTE TABLE
1K Bytes from 0A800H : REG. #5 = $54

Plane A, B and Window already have the same values as SGDK. For the HScroll table, it went from 0x2E to 0x2B and Sprite Attribute table went from 0x5E to 0x54.

Side question: any idea why the registers only take multiples of memory sizes? And inconsistently? Plane A is in multiples of 0x400 while Plane B is in multiples of 0x2000.

Back to the topic, from what I see with the new values it doesn't quite work. I'm writing all over the H Scroll table so the backgrounds are all shifted randomly at every line. Have I forgotten something to set?

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

Post by Chilly Willy »

Well, you did say FULL size, but yes, just the display area would be less. :lol:

IO chips often use fewer bits for pointers and such to save on hardware. Even when they provide more bits for the initial pointer, often, many of them won't increment/decrement under use, which leads to alignment issues even where the pointer doesn't have a problem. The DMA is an example of that - while you can start the DMA anywhere, crossing a 128KB boundary requires two separate operations because only some of the bits are affected by the INC register. Back at the time, every single gate counted. There are numerous instances in the Genesis hardware where just a few more gates would have made some things far better, like the Z80 bank register being serial when parallel would have been FAR better.
TmEE co.(TM)
Very interested
Posts: 2452
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) »

I have window and Hscroll or sprites share same arena. One does not reach the other so things don't blow up.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef »

djcouchycouch wrote:I think I only really need to use less than half the Window memory since it only needs to go down to as far as the 28th row. So even if the plane size is set to be 64x64, I'd only need memory for 64x32, (really using 40x28) so 4k. And the current setup uses 2k already, so I'd lose an additional 2k which is 64 tiles?

As a quick test, I tried moving around the memory locations for the sprite table and the hscroll table but it didn't quite work.

I used the same values as from the Sega doc, under VRAM Mapping, 40 tile mode.

...

Back to the topic, from what I see with the new values it doesn't quite work. I'm writing all over the H Scroll table so the backgrounds are all shifted randomly at every line. Have I forgotten something to set?

DJCC
If you're corrupting the H Scroll data, it means you're still writing to H Scroll table... did you modified SGDK and recompiled it and just overriden default SGDK setting by writing registers after VDP_init() ?
I think your H Scroll table address is not correctly updated for some reasons...
As you can see using the window need to waste a bit of VRAM, as you said, 64x28 cells at least, depending the width of your plan A...
Chilly Willy suggested to locate the Window at same position as Plan A, i though about it but the problem is then you cannot use anymore part of plan A which is used in window, if you use a bottom window then a complete screen of your plan A is not more usable for scrolling :-/
djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch »

I figured that some of the VDP functions might be using fixed values for memory address. Found these.

Code: Select all

#define WPLAN                   0xB000
#define HSCRL                   0xB800
#define SLIST                   0xBC00
#define APLAN                   0xC000
#define BPLAN                   0xE000
I changed the values to the ones in the sega doc (and recompiled the lib) but it didn't change anything. Hmmm. I must be missing something.
Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef »

djcouchycouch wrote:I figured that some of the VDP functions might be using fixed values for memory address. Found these.

Code: Select all

#define WPLAN                   0xB000
#define HSCRL                   0xB800
#define SLIST                   0xBC00
#define APLAN                   0xC000
#define BPLAN                   0xE000
I changed the values to the ones in the sega doc (and recompiled the lib) but it didn't change anything. Hmmm. I must be missing something.
Yeah that is the default location for plan and tables in SGDK.
I agree that not linking them in VDP_init() is a bit stupid and i will fix that soon.
So if you want to change plans and tables location you have to change both these definitions and the vdp_init() code.
Then you need to recompile the library as definition are constants.

Then try to recompile your project and it should work.
Post Reply