Line Scroll Screen

[RockinB]

To be able to transfer an image to screen with one call to slDMA(),

you can display it as a sprite. But this restricts you to 15 bit color depth.

The only method to display 24 bpp is by using the NBG0 scroll screen, but a bitmapped scroll screen got a fixed size. So you would need to transfer each line seperately.....or use the line scroll feature and call slDMA() once.

Okay, the big problem is to compute the line scroll table, vertical cell scroll table and setup the VDP2 correctly.

The most detailed description can be found in Sattechs.pdf, but also the VDP2 user manual got info on that. SGL and SBL support that feature, but none got a function to compute the tables.

Now CWX made the bm24bppls demo which implements the example from Sattechs.pdf.

But it doesn't work on Satourne, Saturnin or real Saturn (looks even more different like on emu).

SGL docs say, you must set the cycle pattern if using the vertical cell scroll table, so this might be the reason, but I'm not sure, since I don't know nothing about cycle patterns.

I tried to write a program to compute the tables needed and a tried to produce tables which are equal to those in Sattechs.pdf and CWX's example. But I paused the work, since the example itself is not working right now.

A second thing I noticed is: the format of the line scroll table in Sattechs.pdf(2 components per entry) and VDP2 manual(3 components per entry) differs!!!

So what the hell is the right format? The SBL uses the 3 component format.

These official SEGA docs are full of errors and partially hard to comprehend, since importand information is just "lost in translation". I don't even understand the table computation described in Sattechs.pdf...(back when I did RB_SaturnPCM, I experienced similar stuff with the motherfucking pitch value).

Help?

 

[antime]

No help for your line scroll problem, but if the SGL DMA functions support indirect mode you could use that to split the bitmap (SCU DMA to VDP2 memory was allowed, wasn't it?)

 

[CyberWarriorX]

The table used in my demo is indeed correct. I'm not sure why however it doesn't work on a real saturn though. I actually borrowed the table data from Lunar 2, which obviously does display the picture right. The demo also works with girigiri. I'll check it out later today though, probably missed initializing some registers or something.

No help for your line scroll problem, but if the SGL DMA functions support indirect mode you could use that to split the bitmap (SCU DMA to VDP2 memory was allowed, wasn't it?)

You could, but then you'd have to make a nice long dma transfer table to transfer each individual line. I'm also not sure what kind of speed hit you get from using indirect dma. The whole idea behind using line scroll was so you didn't have to do something like that, yet still be able to use a continuous image.

Cyber Warrior X

 

[RockinB]

I doubt that indirect DMA is possible, what I've read was just target & source decrement & increment. And if there was a DMA solution for the problem, they wouldn't give the line scroll method.

I've been wrong with the format of the line scroll table. It can vary according to the settings in the line scroll register.

What does fuck up the display is the vertical cell scroll function.

Without it, an image is displayed - slightly distorted.

With vertical cell scrolling, there is only garbage.

So anyone knows the correct cycle pattern settings, because that might be the reason according to SGL/DOC/SCROLL.TXT.

 

[antime]

SGL's own DMA functions seem to only support CPU DMA, but you can do it through the low-level SBL DMA functions (which are included in SGL). This way probably wasn't mentioned because as CWX said, you don't get the nicely-formatted bitmap in VRAM.

If you decide to investigate this, keep in mind that SGL normally uses SCU DMA for sound transfers. There's a list of precautions in one of the text files in the doc dir.