New dev on Saturn ... need help

[witchyummy]

Hi. I'm new to Saturn dev but already have coding background.
I'm using jo engine. I did some tests to draw BG and Sprite. Thanks to XL2 code, I can draw 4bit sprites.

I wish to use 3 Plans of VDP for scrolling Background 1024*512 and one for the HUD. I read the VDP2 doc and push data directly in VRAM A0-1 and B0-1 in 8bit and 4bit.
So i have 4 plans showing and scrolling with Yabause. As I can't test now on real hardware, I also try my iso with Mednafen and .... I don't have the expected result.

So, I make a minimal code to test, only 4 tiles on NBG0 just for testing. A map of 4 tiles, a palette and a 4 cells 8x8 pixels (color 1,2,3,4).
I don't know why this can't work on mednafen or what I miss. Mednafen only show the Background Color. Looks like I don't load data at the good place or the plan is hidden! I tried to use debug but

#include <jo/jo.h>

static unsigned short nbgA1_map[] = {0x0000,0x0002,0x0004,0x0006};
static unsigned short bg_pal[] = {0x8000,0x801f,0x83e0,0xfc00,0xFFFF,0x8000,0x8000,0x8000,0x8000,0x8000,0x8000,0x8000,0x8000,0x8000,0x8000,0x8000};
static unsigned short cell_image[] =
{
0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,0x0101,

0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,0x0202,

0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,0x0303,

0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,0x0404,
};

#define NBG0_CEL_ADR    (VDP2_VRAM_A0)
#define NBG0_MAP_ADR    (VDP2_VRAM_B0)
#define NBG0_COL_ADR    (VDP2_COLRAM)

void            jo_main(void)
{
    jo_core_init(JO_COLOR_Blue); 
    jo_set_displayed_screens(JO_NBG0_SCREEN);
    slPlaneNbg0(PL_SIZE_1x1);    //slPlaneNbg0(PL_SIZE_2x1);  1024 * 512
    slCharNbg0(COL_TYPE_256, CHAR_SIZE_1x1);    //CHAR_SIZE_2x2);    Tile 16x16 pixels 
    slMapNbg0 ((void *) NBG0_MAP_ADR, (void *) NBG0_MAP_ADR, (void *) NBG0_MAP_ADR, (void *) NBG0_MAP_ADR);
    slPageNbg0 ((void *)NBG0_CEL_ADR, 0, PNB_1WORD); 
  
    jo_dma_copy((void *)cell_image, (void *) NBG0_CEL_ADR, 128*2);
    jo_dma_copy((void *)nbgA1_map, (void *) NBG0_MAP_ADR, 4*2);
    slDMACopy ((void *) bg_pal, (void *) NBG0_COL_ADR, 32);
    jo_core_run();
}

Spoiler: Debug picture

 

[witchyummy]

Finally after hours of debug with mednafen ^_^ I found my problem. I use the command jo_set_displayed_screens but that's work when using slScrAutoDisp(NBG0ON | NBG1ON | NBG2ON | NBG3ON);

So 4 plans with scrolling and sprite. I'm happy. All that remains is to create a game ...

I found Mednafen hard for debugging. I can't find a way to enable/disable Plan. Ram with lot of AA AA AA AA. Some weird Value like SCXIN2 = 0 but the scroll works.


Which emulator is the more accurate for testing on PC/Windows ?

 

[fafling]

It was a cycle pattern issue.

jo_set_displayed_screens calls slScrAutoDisp, which sets VDP2's cycle pattern register accordingly to the current settings of the layer that is to be displayed.

In your example, if jo_set_displayed_screens is called without having changed anything to the settings of NBG0, it sets the cycle pattern using SGL's default settings for this layer, which is an 8 bpp tilemap with cells and map in VRAM B1 :

A0 = FEEEEEEE
A1 = FEEEEEEE
B0 = FFFFEEEE
B1 = 044FEEEE

But then you set NBG0's cells to be in VRAM A0, and its map in VRAM B0. Since there's no timing set for those accesses in the cycle pattern, the console doesn't display the layer, and Mednafen as well because it checks the cycle pattern values contrary to Yabause.

So that code works if you move

jo_set_displayed_screens(JO_NBG0_SCREEN);

after

slPageNbg0 ((void *)NBG0_CEL_ADR, 0, PNB_1WORD);

Which gives this cycle pattern :

A0 = 44FEEEEE
A1 = FFFEEEEE
B0 = 0FEEEEEE
B1 = FFEEEEEE

Yabause's forks Kronos and Yaba Sanshiro have implemented controls of the cycle pattern. The cycle pattern value is displayed in Kronos VDP2 debug screen.

I found Mednafen hard for debugging. I can't find a way to enable/disable Plan.

ctrl + 1-7

Which emulator is the more accurate for testing on PC/Windows ?

Mednafen is more accurate, but Yabause and its forks have better debugging screens.

 

[witchyummy]

Thanks you so much for this usefull explanations. It's more logical now.

I look for the VDP2 debug and I don't see the cycle pattern. I compare Yabause and Kronos (and Yaba Sanshiro too)

Spoiler: Debug ScreenShot

 

[fafling]

Cycle pattern display was added in Kronos v2.3.1 in the General Info pane of VDP2 debug screen.
Kronos 2.3.1 - 32/64 Bits : debug tools are back :)

 

[witchyummy]

Thanks. I didn't check the version ^_^

I coded today the 4 bit sprites with the help of XL2 code. I use my own encoder tool and everything seems working.

With the doc, I found information for flipping sprite : sprNoflip | (1 << 4) for Horizontal flip and remove SPdis for using color transparency.

FIXED pos[XYZS];    pos[X]=toFIXED(x); pos[Y]=toFIXED(y); pos[Z]=toFIXED(z); pos[S]=65535;
    //SPR_ATTR spr_attributes = SPR_ATTRIBUTE(id, LUTcramIdx(id), No_Gouraud, CL16Bnk | ECdis | SPdis | HSSon , sprNoflip  );
    SPR_ATTR spr_attributes = SPR_ATTRIBUTE(id, LUTcramIdx(id), No_Gouraud, CL16Bnk | ECdis | HSSon , sprNoflip | (1 << 4)    );
    slPutSprite(pos, &spr_attributes , 0) ;

Now I have a problem for ordering the sprites (Depths). By default, the VDP draw in order of sprite insertion.
The z ordering works when changing z value but this scale the sprite. So I change the Size value too.

Spoiler: Test Depth

Is there a function for z depth ?

EDIT : I just saw in the vdp1 debug than the sprites are "Scaled Sprite". I'll look inside the jo Engine to change to "Normal Sprite" and also change "Local coordinates" to 0,0 ^_^

 

[witchyummy]

I continued development. I made my own tools to convert and compress the data. phew!

Before going any further, I have 2 questions.
1. I tried on emulator to check the resolutions to test the display according to the origins of the console.
When I compile in "PAL" with jo-engine, I have a resolution of 320*256 on Pal console and 320*224 on ntsc console. I tested with mednafen because yabause always shows me 320*256.
If I compile in "NSTC", I always have 320*240. Is it consistent on real hardware machines ?

Spoiler: Screen resolution PAL

2. I want to load data in WORK RAM. The low work ram seems empty. The high work ram is using for main code. Are there specific spaces occupied by hardware or bios? Never to touch.?

 

[fafling]

1. Mednafen is correct regarding 320*256 display. It is displayed correctly only on a 50 Hz console. It is shown as 320*224 on a 60 Hz console, the lower part of the 320*256 picture being truncated.
The resolutions that Jo engine sets are hard-coded for each PAL/NTSC settings. There are other possibilities listed in enum tvsz in SL_DEF.H.

2. SGL doesn't use low work ram, and afaik Jo engine doesn't touch it, so it's all available.
Reserved areas for the system or for SGL are all in high work ram. There's a map of high work ram at the end of SGL developer's manual reference, chapter "WORK RAM-H".
2 things of note about low work ram :
- It is slower than high work ram.
- DMA transfers to or from low work ram must use CPU DMA because SCU DMA doesn't work on that area.

 

[witchyummy]

1. Mednafen is correct regarding 320*256 display. It is displayed correctly only on a 50 Hz console. It is shown as 320*224 on a 60 Hz console, the lower part of the 320*256 picture being truncated.
The resolutions that Jo engine sets are hard-coded for each PAL/NTSC settings. There are other possibilities listed in enum tvsz in SL_DEF.H.

2. SGL doesn't use low work ram, and afaik Jo engine doesn't touch it, so it's all available.
Reserved areas for the system or for SGL are all in high work ram. There's a map of high work ram at the end of SGL developer's manual reference, chapter "WORK RAM-H".
2 things of note about low work ram :
- It is slower than high work ram.
- DMA transfers to or from low work ram must use CPU DMA because SCU DMA doesn't work on that area.

Thanks for the information.
With the reference file, I can now load data in RAM-L or RAMCART. I use cpu dma by default. I mainly use low ram for stocking compress data and push them to a buffer.

 

[witchyummy]

GOOD. it's time to do something bigger than just mini-tests.

As I'm bad at level design, game design why not making a port of a game or emu. I love computer so maybe a xrick port but already done. It's hard to find information on port or homebrew. All I found is a link at SegaXtreme - Saturn Sample Programs, the Anniversary Game Competition and of course fbneo i found here. Maybe nothing more exist ... ^_^

Maybe begin with a gb emulator before doing computer emu.