Weird problem with SGDK on REAL hardware

SGDK only sub forum

Moderator: Stef

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

Post by Stef » Wed Oct 10, 2012 8:22 pm

doragasu wrote:Good to know, thanks.

Other test I have done: Commenting out everything (but including inside the ROM the resources), makes the ROM boot.

I have also tested Angry Birds ROM: With Picodrive 1.80, it exits the emulator 1 or 2 seconds after starting. With Everdrive, it boots perfect. With my flashcart it doesn't boot in my MD1! Could the problem be related? Maybe a bug in SGDK?
For sure it is related to SGDK as Angry Bird is also done with SGDK.
I guess that all the samples provided in SGDK does not work too.
Well, this is probably something related to boot code, but it could be the complete init process which make something wrong...
What is surprising is that everdrive itself use piece of SGDK but i guess it does not use it for initialization..

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

Post by Chilly Willy » Wed Oct 10, 2012 10:20 pm

Maybe this...

Code: Select all

NoCopy:
        move.w  #0,%a7
        move.w  #0x2300,%sr

* Jump to initialisation process...

        jmp     _start_entry
You're enabling ints before the hardware has been initialized. I leave the sr at $2700 until the hardware is initialized on my code. Setting the sr to a run level should be the LAST thing you do. Same issue on reset - you set the sr to $2300 almost instantly instead of after doing all the reset stuff.

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

Post by Stef » Thu Oct 11, 2012 9:24 am

Chilly Willy wrote:Maybe this...

Code: Select all

NoCopy:
        move.w  #0,%a7
        move.w  #0x2300,%sr

* Jump to initialisation process...

        jmp     _start_entry
You're enabling ints before the hardware has been initialized. I leave the sr at $2700 until the hardware is initialized on my code. Setting the sr to a run level should be the LAST thing you do. Same issue on reset - you set the sr to $2300 almost instantly instead of after doing all the reset stuff.
I agree on reset it can be an issue but on cold start i guess the VDP does not have interrupt enables ? Anyway it can be the problem and you are right, interrupts should be enabled only at the end of the initialization process !

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Post by doragasu » Fri Oct 12, 2012 10:38 am

I don't know 68k asm, but I can try making some changes to sega.s

What's the fastest way to test changes in sega.s? If I add sega.s to my codeblocks project and build the ROM, the startup code used in the ROM will be the one built from my sega.s local copy or the one inside libmd.a?

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

Post by Stef » Fri Oct 12, 2012 11:55 am

Afaik sega.s is never included in the libmd.a as it should be the first linked object it's recompiled with the project makefile (makefile.gen).
So if you directly modify it, recompiling your project is enough to test your changes.

notaz
Very interested
Posts: 193
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Re: Weird problem with SGDK on REAL hardware

Post by notaz » Fri Oct 12, 2012 3:24 pm

doragasu wrote: We have only found one emulator the game doesn't work with: Picodrive 1.80 (used on a OpenPandora, I suppose Wiz/Caanoo versions behave the same).
Check /tmp/pndrun* file after running on pandora, it might have some information about what happens to the emu.

In general it sounds like an interesting problem, if you send me the ROM I could check what's going on in the emulator.

notaz
Very interested
Posts: 193
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Post by notaz » Fri Oct 12, 2012 4:10 pm

Well I've just checked what happens to angrybirds - it somehow ends up executing Z80 code on ROM window, which trips out drz80 (the z80 asm core). So maybe SGDK starts Z80 without loading Z80 program first, or something like that, haven't looked in detail.

Off topic: can Z80 run from the ROM window at all? I have never seen any games do that.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Fri Oct 12, 2012 4:25 pm

it can run out of ROM but it has significant effect on 68K performance and makes life harder on Z80 side as you only gon a single bank
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

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Post by doragasu » Fri Oct 12, 2012 5:08 pm

Wow notaz, nice to see you here. We have tracked down the problem. The function to copy data from RAM to VRAM (copied from Shiru) was randomly causing the problems:

Code: Select all

u16 vram_copy(u16 adr,const void *data,u16 size)
{
    volatile u16 *pw;
    volatile u32 *pl;
    u32 src;

    pw=(u16*)GFXCNTL;
    *pw=0x9300+((size>>1)&0xff);
    *pw=0x9400+((size>>9)&0xff);
    src=(u32)data;
    *pw=0x9500+((src>>1)&0xff);
    *pw=0x9600+((src>>9)&0xff);
    *pw=0x9700+((src>>17)&0x7f);

    busreq_on();

    pl=(u32*)GFXCNTL;
    *pl=GFX_DMA_VRAM((u32)adr);

    busreq_off();

    return adr+size;
}
I replaced the code to copy data with a DMA transfer, and all the problems are gone!

Code: Select all

u16 vram_copy(u16 adr,const void *data,u16 size)
{
    VDP_doVRamDMA((u32)data, adr, size>>1);

    return adr+size;
}
About the fail in Picodrive, this is de PND log:

Code: Select all

=======================================================================================
PND             : /media/IORI_PANDORA/pandora/menu/PicoDrive_180pxml_tv.pnd
PND_FSTYPE      : Squashfs
APPDATADIR      : /media/IORI_PANDORA/pandora/appdata/picodrive.notaz.1.80
APPDD_FSTYPE    : ext2
PND_CPUSPEED    : <unset>
EXENAME         : PicoDrive.run
ARGUMENTS       : <unset>
=======================================================================================
[ START ]--- Mount the PND ----------
Mounting : mount -t squashfs -o ro "/dev/loop0" "/mnt/utmp/picodrive.notaz.1.80"
Mounting the Union FS : mount -t aufs -o exec,dirs="/media/IORI_PANDORA/pandora/appdata/picodrive.notaz.1.80=rw+nolwh":"/mnt/pnd/picodrive.notaz.1.80=rr" none "/mnt/utmp/picodrive.notaz.1.80"
[SUCCESS]--- Mount the PND ----------
[ START ]--- Starting the application (PicoDrive.run ) ----------
oshide: open /dev/tty: No such device or address
Segmentation fault
open /dev/tty: No such device or address
[ FAILED]--- Starting the application (PicoDrive.run ) ----------
[ START ]--- Restoring the frame buffer status ----------
[SUCCESS]--- Restoring the frame buffer status ----------
[ START ]--- uMount the PND ----------
[ START ]--- Waiting the Union to be available ----------
[SUCCESS]--- Waiting the Union to be available ----------
auplink:plink.c:223: AUFS_CTL_PLINK_MAINT: Inappropriate ioctl for device
rmdir: failed to remove `/mnt/utmp/picodrive.notaz.1.80': Device or resource busy
[ START ]--- Waiting the PND mount dir to be free ----------
[SUCCESS]--- Waiting the PND mount dir to be free ----------
cleanup done
[SUCCESS]--- uMount the PND ----------
=======================================================================================
Return code is : 2
I can't see how the vram_copy function code could depend on something done at initialization. In the tests we have done, the function worked perfect for some segments of the game, and halted the system other times. Why it always worked with Everdrive and most emulators? Why it always worked when doing hotswap with a commercial game? It's a really really weird problem.

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

Post by Stef » Fri Oct 12, 2012 6:58 pm

I guess this is something to do with Z80 bus control register.
I modified the boot process so now on hard reset the Z80 bus is taken by 68K, preventing Z80 to execute something... then later the default Z80 driver is loaded.
Also i moved enable interrupt at end of initialization to avoid any side effects.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Fri Oct 12, 2012 7:01 pm

i remember DMA being somehow tricky on real hardware
for example, VDP register 23 seems to always (?)been initialized to $80 by startup routine and i think i read somewhere on the forum it could crash if not initialized properly, not sure why but it might be related to DMA circuitry state on startup or what happen when you enable DMA through register $01 ...

Also remember that docs tells you not using DMA from 68k bus to VRAM when executing code from ROM, that RAM must somehow be used when triggering DMA. There were mixed reports about that and i remember people writing they never had problems with this but you never know, it might as well depend on DMA registers initialization and eventually hardware implementation ( which could also explain why it works on some flash carts and not others ?)

the strange thing about your fix is that you replaced a DMA function by another one.
Is there any ROM we could test or debug ? i am curious about this as well

Edit: found the thread talking about dma init issues
viewtopic.php?t=755&postdays=0&postorde ... a&start=15
actually it was something i figured when trying to run that game on my everdrive so it might not be the same issue here :roll:

notaz
Very interested
Posts: 193
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Post by notaz » Fri Oct 12, 2012 7:58 pm

doragasu wrote:The function to copy data from RAM to VRAM (copied from Shiru) was randomly causing the problems
The function you removed looks ok (and also does DMA), the only real difference this causes is that z80 bus is no longer requested during the DMA transfer. Is z80 running valid code when this is called? Sounds more like this is a timing issue to me, or it could be that this code was starting Z80 when you didn't want it, perhaps before loading Z80 program.

Curiously SGDK also has busreq code in VDP_doDMA, but it's commented out.

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

Post by Stef » Fri Oct 12, 2012 8:09 pm

I removed it just because it was not needed but i don't remember it was causing any problems so far.

Hik
Very interested
Posts: 68
Joined: Thu Jul 30, 2015 11:39 pm
Location: Iceland

Re: Weird problem with SGDK on REAL hardware

Post by Hik » Sat Sep 24, 2016 9:41 pm

I had a friend try out my rom on real hardware but there was just a blackscreen.
The code looks pretty similar on the latest version as before doragasu's fix so I think it might be that.

It would be great if it were fixed in SGDK builds so that it works on real hardware without issues.

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

Re: Weird problem with SGDK on REAL hardware

Post by Stef » Sun Sep 25, 2016 9:02 pm

What is the code causing the problem exactly ? I tested a lot of code on real hardware but maybe behavior differ depending hardware revision.
Do you mean requesting Z80 before doing DMA fix the issue ?

Post Reply