M68K for DC

[BlackAura]

Ian - If you have any useful modifications you've made to GP, could you send them to me? I think I know what was wrong with the menu system from GP/DC (and how to fix it - yay!) so it might be possible to do another release fairly soon-ish (assuming I get some free time, of course).

[Ian_micheal]

Sure BA i can just send the whole source to you Put a link up mostly only code hacking that kind of thing. Might be some thing usefull.

[BlackAura]

Cool, thanks.

[Stef]

Well, i've some news about C68K (a new 68k core i wrote in C, designed for speed) :

I finally implemented all opcodes, but there are still many bugs to fix Â*:-X
I first tested it on a PC Genesis Plus version... i implemented "on-the-fly" core switch and it worked well, i succefully played with Sonic 1, Sonic 2, Sonic 3, Aladdin ... i had to switch to musashi sometimes because of multiples bugs in C68K.

Nice, it (almost) works on PC, what about the DC ?
So i implemented C68K in Genesis Plus DC, but just with inlines methods using musashi or C68K depending a #define (understand by that : no "on-the-fly" core switch as PC version).... then it failed
even with -O0 optimisation :-/

So i did a new PC build with inlines methods instead of the complete multi core support and i got the same result on PC version... weird, i finally discovered that sonic1 (my favorite test rom) didn't work with that implementation hopefully Aladdin did work

-> testing DC version with aladdin (arg 1.2 MB to upload instead of 350 KB for each test)...
Â* IT WORK ! at least with optimisation set to O0, and believe me, with O0, Genesis Plus DC doesn't run very fast (about 11-12 FPS)...

After severals tests, i discovered that -O1 optimisation level just break C68K
but -Os does work
unfortunatly, C68K wasn't designed for -Os optimisation, and i think it perform better with -O2 than -Os but at least i can get it to work with optimisation...

I don' really benched C68K versus musashi on DC, but i will do it that tonight and report result here...

For those who want to include C68K in their project just for testing purpose (remember the core is still in development), i can give a pre-compiled obj file (-Os optimisation level) with .h file and an interface which permit to use musashi or C68K depending CPU68K_USE_MUSASHI or CPU68K_USE_C68K definition... some stuff as memories handlers and interrupt callback need to be modified also, the current C68K interrupt callback is wrong, i'll redo it later as musashi one.

[GPF]

[quote author=Stef link=board=dcemu;num=1083323639;start=90#93 date=05/24/04 at 09:52:33]testing DC version with aladdin (arg 1.2 MB to upload instead of 350 KB for each test)...[/quote]


Just a suggestion, burn the rom to a cd and remove it from the romdisk, makes each test a lot quicker.

Anyway sound like great progress. What compiler version are you using on the dreamcast?

Troy

[Stef]

[quote author=GPF link=board=dcemu;num=1083323639;start=90#94 date=05/24/04 at 13:29:34]Just a suggestion, burn the rom to a cd and remove it from the romdisk, makes each test a lot quicker.

Anyway sound like great progress. What compiler version are you using on the dreamcast?[/quote]

I guess the best thing to do is to get a BBA since even the bin file alone is really huge (more than the rom actually)

I'm using GCC 3.0.4 and the least we can say is that SH-x CPU support is far from perfect... enabling optimisations sometime break the code.
C68K use a tricky feature of GCC (computed label), i think it's why optimisations can easily mess up code.

I did some tests, i have about 29 FPS with C68K where i had 24 FPS with musashi (with -Os switch), that is not really relevant about how many time C68K is faster than musashi... but that give an idea about how far we are from full speed :-/
Of course that depend *a lot* from the game, but anyway, there is still a lot of work to do

[quzar]

GPF asked the same question i would. its not that newer versions are better, but that every version after (iirc) 3.0.x has SH-4 support broken (problems with ?regression?)

this is however really great news ;D

[Alexvrb]

I was under the impression that the newest ones fixed the problems. No speed increase to speak of, but perhaps less likely to break code with -O2/3?

[GPF]

I am using 3.4.0 gcc for my gba emulator with -O4 with no problems so far. with binutils 2.14 , only had to change the sh-elf-objcopy parameters.

Troy

[Alexvrb]

Ah yes, was it you that mentioned you were going to compile at work? Something about it sucking up lots of memory when it compiled? Anyway, maybe Stef should give that a shot. I'm glad to see that he's been able to get it up and running, even if all the bugs haven't been ironed out.