Page 17 of 43 FirstFirst ... 713141516171819202127 ... LastLast
Results 161 to 170 of 427

Thread: M68K for DC

                  
   
  1. #161
    Dream Coder
    Join Date
    Apr 2004
    Location
    Miami, FL
    Age
    38
    Posts
    4,675
    Rep Power
    50

    Default Re: M68K for DC

    right now the way the autoloading works i dont think you can do that. the emulator dosnt start until it finds a real neo geo CD. or a CD that has the file IPL_TXT on it. make a mixed mode CD that has one datafile IPL_TXT and some audio tracks. it should boot fine then you can go to the bios if it hasnt crashed yet =P
    If anyone is looking to buy, sell, trade games and support a developer directly at the same time, consider joining Goozex. Enjoy!

  2. #162

    Default Re: M68K for DC

    Stef wrote:
    then we have a 512 lenght jump table, where firsts 256 entries are for 8 bits instructions and lasts 256 for 16 bits ones
    I don't know if that could be really applied to the 65816 cpu, but anyway i'm sure we can always find a solution.
    yes, that's one of the first things that came to my mind aswell, however, I shunned it because you would need a 1024 lenght jump table, since the combinations are 'a8 xy8', 'a16 xy16', 'a8 xy16', 'a16 xy8', but thinking about it, you're right, you could designate a register for the instruction table offset and set that offset to the correct jump table index (256*n) at each sep/rep instruction (if I remember the sep/rep stuff, this was ages ago).

    either way, I'm sure the dreamsnes guys thought of a smart way, looking forward to examining their sh4 65816 emulator.

    I already compared asm generated by GCC against my own asm file and really, we do easily better... specially for the SH-4 cpu where we have many available registers.
    sounds great, btw what toolchain are you using, and is anyone using gcc3.4.0 branch/snapshots and has examined output of -O4? does any optimization increases carry over to the sh4?

  3. #163
    DCEmu Regular
    Join Date
    Apr 2004
    Location
    Posts
    351
    Rep Power
    79

    Default Re: M68K for DC

    You cant enter the bios by Pressing all the buttons together. even use the memory card manager.

    Any-way Â* it's fast enff to enjoy right no only been 3 months. People will just have to wait for a perfect verison of it.

    Ive not had a lot of chance to do what i want to it. Some times team work does not work at all. End up leting people do what you want to ans sit around doing nothing.

    Every one is welcome to help on Neo Geo CD please send me any stuff that may help or email it to me you will get full credit.

    Speed is 100% aproxx looking due to frameskip and Â*Pesudo frameskip i like to apply to it. Â*Some people call it underclocking it's not really just that.


    Any way good luck im not going to be on forums much any more i find it distracting and un help full to me.

    So you can report any thing to the offical forum of the neogeo cd project or me.

    Back on topic i would think.

    This is LGPL code not gpl people get it mixed up.

    So good bye

  4. #164

    Default Re: M68K for DC

    [quote author=Ian_micheal link=board=dcemu;num=1083323639;start=150#162 date=06/02/04 at 15:40:11]Any way good luck im not going to be on forums much any more i find it distracting and un help full to me[/quote]

    ....?


    Guess, we'll have to respect that.


    His message board is at http://imrtechnology.sourceforge.net/phpBB2/

  5. #165
    DCEmu Coder GPF's Avatar
    Join Date
    Apr 2004
    Location
    Texas
    Age
    53
    Posts
    796
    Rep Power
    82

    Default Re: M68K for DC

    I just tried to compile the Genesis Plus DC code from the thread, I had some difficulties but I got it to compile. But when I uploaded the bin, I just get a black screen, so I will have to look into it some more when I get some more free time.

    I am using SH-elf GCC 3.4.0 and tried to compile it with -O3, but had a problem with the sound file ym2612.c didn't like the compiler flags, so I had to compile it seperately with no optimization or -f flags. I then tried it with -02 same problem with ym2612.c , so I compiled it seperatly and also I had to remove the linking to -lstdc++. and remove the -fno-operator-names -fno-rtti flags as it complained that since I was compileing with a c compiler and not a c++ compiler. But then after uploading the GenPlus.elf, it stopped at a black screen and my dc-tool console, last 2 lines were something like pvr_wait_timeout
    fps ....

    Troy

  6. #166
    DCEmu Coder GPF's Avatar
    Join Date
    Apr 2004
    Location
    Texas
    Age
    53
    Posts
    796
    Rep Power
    82

    Default Re: M68K for DC

    well I tried again and got a lot closer This time I just set dev-cpp to compile ym2612.c by itself and it worked with -O2, and when I uploaded the elf , I could hear sonic in the background and the level screen , but when it went into the demo/started the game(I couldn't tell) the screen was mostly black, the first couple of line would render but then the screen would go black.

    My dc-tool console was spitting out this message
    FPS : 26 SPD : 32

    over and over again , then FPS changed but it was probably averaged around that number. but it could be because it wasn't fully rendering the background. I'll try again later

    Troy

  7. #167
    DCEmu Coder
    Join Date
    Apr 2004
    Location
    FRANCE
    Posts
    80
    Rep Power
    0

    Default Re: M68K for DC

    [quote author=GPF link=board=dcemu;num=1083323639;start=165#165 date=06/06/04 at 03:32:47]well I tried again and got a lot closer Â*This time I just set dev-cpp to compile ym2612.c by itself and it worked with -O2, and when I uploaded the elf , I could hear sonic in the background and the level screen , but when it went into the demo/started the game(I couldn't tell) the screen was mostly black, the first couple of line would render but then the screen would go black.

    My dc-tool console was spitting out this message
    FPS : 26 Â* Â*SPD : 32

    over and over again , then FPS changed but it was probably averaged around that number. but it could be because it wasn't fully rendering the background. I'll try again later

    Troy[/quote]

    This is normal with the sources you downloaded, there is a small bug in interrupt which make sonic game to not display correctly...

    Here's how to fix the problem : in the m68k_irq_ack_callback function (end of genesis.c file), just delete these 2 lines :
    if (vint_pending) return 6;
    if (hint_pending) return 4;

    Anyway C68K has some others bugs with sonic, you won't be able to play it anyway...

    But i'm thinking... you said you compiled with -O2 flag right ? When i'm compiling with this level of optimisation, C68K doesn't work at all, i have to compile with -O0 or -Os, others just don't work

    I made some modifications to C68K, now it's a lot more musashi compatible, functions use same parameters ... just need to add FASTCALL

    I still have some bug fixs to do though...

  8. #168
    DCEmu Coder GPF's Avatar
    Join Date
    Apr 2004
    Location
    Texas
    Age
    53
    Posts
    796
    Rep Power
    82

    Default Re: M68K for DC

    [quote author=Stef link=board=dcemu;num=1083323639;start=165#166 date=06/07/04 at 09:17:11]

    This is normal with the sources you downloaded, there is a small bug in interrupt which make sonic game to not display correctly...

    Here's how to fix the problem : in the m68k_irq_ack_callback function (end of genesis.c file), just delete these 2 lines :
    if (vint_pending) return 6;
    if (hint_pending) return 4;
    [/quote]

    Ok removed those lines and now the display is fine.

    Anyway C68K has some others bugs with sonic, you won't be able to play it anyway...

    But i'm thinking... you said you compiled with -O2 flag right ? When i'm compiling with this level of optimisation, C68K doesn't work at all, i have to compile with -O0 or -Os, others just don't work
    Other than some sprite glitches and missing graphics and a little slow, it appears to be running with -O2 flag , I am compiling with sh-elf GCC 3.40

    Troy

  9. #169
    DCEmu Coder
    Join Date
    Apr 2004
    Location
    FRANCE
    Posts
    80
    Rep Power
    0

    Default Re: M68K for DC

    [quote author=GPF link=board=dcemu;num=1083323639;start=165#167 date=06/07/04 at 15:36:07]
    Other than some sprite glitches and missing graphics and a little slow, it appears to be running with -O2 flag , I am compiling with sh-elf GCC 3.40
    Troy[/quote]

    Sprite glitches and missing graphics are because of internals C68K bugs...
    did you tried to compare C68K speed versus musashi ?
    You just have to uncomment
    CPU68K_USE_C68K / CPU68K_USE_MUSASHI in the cpu68k.h file.

    I guess speed without frameskip is almost same since VDP rendering is the bottleneck, we should with frame skip as 3 or 4 to see how different is

    I'll try to upgrade my GCC version, i'm still with 3.0.4

  10. #170
    DCEmu Coder GPF's Avatar
    Join Date
    Apr 2004
    Location
    Texas
    Age
    53
    Posts
    796
    Rep Power
    82

    Default Re: M68K for DC

    [quote author=Stef link=board=dcemu;num=1083323639;start=165#168 date=06/07/04 at 15:59:50]

    did you tried to compare C68K speed versus musashi ?
    You just have to uncomment
    CPU68K_USE_C68K / CPU68K_USE_MUSASHI in the cpu68k.h file.
    [/quote]

    I try to give it a try tonight when I get home from work, If I remember right the fps for C68K was about 26-27.

    Troy

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •