GP32 Mr Mirko Sdk Gp_setframebuffer Problem

[Reesy]

Hi,

I'm now using Mr Mirko's great SDK. The only problem I'm having is with switching the frame buffer. I'm using the gp_setFramebuffer function. An occasionally the screen is displayed incorrectly, ie it looks like the screen is wrapped around.

I've read in the official Samsung document that you should not set a new frame buffer location by using the line counter (rLCDCON1) as a guide to when the frame starts because the LCD FIFO is setup before the new frame.

I've looked at the source for the gp_setFramebuffer function and it does not check the current status of the LCD, it just updates the LCD registers straight away. I originally thought this could be the problem and thought that maybe gp_setFramebuffer was being executed at the same time the LCD FIFO is being setup. So I added code to make sure that gp_setFramebuffer never modified the LCD registers in the line was between 05 and 315. But the screen still get corrupted.

I'm guessing the FIFO is always setup at the same point during the frame, I just need to work out where it is. Anybody have any ideas?

Thanks

Reesy

 

[foft]

I don't know why your protection around 315/5 does not work - it is updated during that point AFAIK. I found doing this worked in my atari800 port...

                       while (((*LCDCON1 >> 18)&0x1ff) == 1);
                       while (((*LCDCON1 >> 18)&0x1ff) == 0);
                       *LCDADDR1 = someadr1;
                       *LCDADDR2 = someadr2;

Though I'm using the GP SDK...

Mark

 

[Reesy]

Ahh I see you mask of the LCDCON1 register. I've just checked my code and I was not doing that. I've just read the samsung doc again to confirm and the line value is only bit 18 to 27. Thanks for the heads up, I've stuck your code in now hopefully it should be fine now.

Thanks for your help, this has been really bugging me.

Reesy

 

[mr.spiv]

One thing you could check is that the framebuffer update always happen at the very beginning of the line 0 (or preferable on line 1). An interrupt occuring in a middle of your LCDADDR1 & LCDADDR2 update might cause the other register write to "miss" one frame or such. That causes also problems you described.

As a side note you can trigger the LCD DMA to change the frame buffer on each scan line. Actually several times during a scan line -- not particularly useful unless you want to make some C64 style raster effects :blink:

 

[Reesy]

Well it was still happening even with the foft's new code. So now I'm not updating the frame buffer location between lines 32 and 0. This "seems" to be working and does not appear to have affected the FPS that much, so I'm happy.

The problem is that I can not guarantee that the change to the frame buffer location will be at a particular line. Doing so causes a serious drop in FPS of my emulator.

I will run some tests though with the interrupts in my code disabled and see if it makes a difference, thanks for advice mr.spiv.

 

[mr.mirko]

I've looked at the source for the gp_setFramebuffer function and it does not check the current status of the LCD, it just updates the LCD registers straight away. I originally thought this could be the problem

????
void gp_setFramebuffer(void *add,int vsync);

vsync = 1, and the function is waiting, until the framebuffer is changed.
vsync = 0, the registers are changeing directly ( no waiting )

There is no need to wait, before setting the registers, you only need to wait,
until the framebuffer is changed ( with vsync )

 

[Reesy]

Well I've tested the code again, this time with no interrupts firing and the screen still gets screwed up. So its not the interrupts.

I must have a problem somewhere else in the code, I'll have to dig about abit more.

Thanks

Reesy

 

[foft]

Well I've tested the code again, this time with no interrupts firing and the screen still gets screwed up. So its not the interrupts.

I must have a problem somewhere else in the code, I'll have to dig about abit more.

Thanks

Reesy

​

I see you released DrMD 1.0 (Just trying it now). Did you work out what the issue was? I'd be interested to know...

Thanks,

Mark

(edit) P.S. Just running it. Like the changes very much!