FAME Beta released!

[fox68k]

Hi everyone,

it was time to release a new version of FAME and ... why not a Beta one? ;D

It is just much more stable than previous one and it runs perfectly a considerable amount of Genesis games in GP/DC: Sonic 1-3, Golden Axe 2, Thunder Force IV, Rambo 3, Aladdin, Eternal Champions and Street of Rage 2 among many others :)

I would like to know about lastest development on GP/DC so if anyone is working in it out there, please let me know about progress ;)

Documentation and download here (http://perso.wanadoo.es/orayo/fame/).

Cheers.

[quzar]

Is this any faster than previous versions of fame? I tested fame from neo4all a2 against my newly compiled c68k and c68k was as fast as it.

[DARKGATE]

:D WOW, good possibility of see an AMIGA EMU and GENESIS work perfectly ::) ,
CHUIIIII, BLACKAURAAAA ;D worked :P . ;).

[fox68k]

Is this any faster than previous versions of fame? I tested fame from neo4all a2 against my newly compiled c68k and c68k was as fast as it.

I did not test my core against any other yet, sorry :(

But BA pointed out about speed in GP with FAME sometime ago here (http://www.dcemu.co.uk/cgi-bin/yabb/YaBB.pl?board=dcemu;action=display;num=1106437151; start=23#23).

[Christuserloeser]

Wow, that's fantastic news fox68k :)

[ron]

I'm sure that FAME is dramatically faster than C68K. Just think on arithmetics and calculations. Even Quzar if you are tuning as best as posible your C68K compilation , FAME seems to be a faster core. Anyway this doesn't meant that Stef´s core is worst than Fox68k, both cores are great glasses in wich look through :D

[quzar]

I'm sure that FAME is dramatically faster than C68K. Just think on arithmetics and calculations. Even Quzar if you are tuning as best as posible your C68K compilation , FAME seems to be a faster core. Anyway this doesn't meant that Stef´s core is worst than Fox68k, both cores are great glasses in wich look through :D

i made it so that NeoDC can interface with fame the same way that neo4all does, and have benchmarked c68k against FAME and they come out nearly identical with both leading by a ms or 2 at times, but on average going at the same rate. The difference probably is in the fact that c68k is 1/10 the size of fame.
I know this as a fact for i have seen it with my own eyes.

The only thing I really asked was wether or not this version was faster than the one included with neo4all alpha 2, because if it is, then maybe it would be noticably faster than c68k.

Also, what is this based on? Have you used c68k and fame side by side in the same application before? or is it from thinking that neo4all is 2x faster than neodc as most would be lead to believe?

[Stef]

If you want to test speed of C68K and FAME, you need to overclock *a lot* speed of 68000 CPU in NeoCD, because only in this case others parts become insignifiant.
Try to make it working at 240 Mhz (by multiplying number of cycles to do by 20) then compare how many FPS you have with C68K and FAME.
Normally FAME should anyway be faster, just think of flags calculations.
Making them in C can't be optimal, even if SH-X CPU assembly doesn't offers advantages of x86 CPU here...
If you measure C68K faster, then as mentionned Chui and Fox68K, there is probably a obscure bug in C68K which make it to leak some cycles.
But as C68K takes less memory than FAME, i guess FAME isn't a lot faster.

[quzar]

If you want to test speed of C68K and FAME, you need to overclock *a lot* speed of 68000 CPU in NeoCD, because only in this case others parts *become insignifiant.
Try to make it working at 240 Mhz (by multiplying number of cycles to do by 20) then compare how many FPS you have with C68K and FAME.
Normally FAME should anyway be faster, just think of flags calculations.
Making them in C can't be optimal, even if SH-X CPU assembly doesn't offers advantages of x86 CPU here...
If you measure C68K faster, then as mentionned Chui and Fox68K, there is probably a obscure bug in C68K which make it to leak some cycles.
But as C68K takes less memory than FAME, i guess FAME isn't a lot faster.

when i recompiled the version of c68k that you had compiled for ian and was distributed as a precompiled object, i was able to get it to run about 2x faster than it had been by compiling it at -Os -no-gcse. It's also about half the size as it was before.

I'll try that at some point though, running it at 10x the speed.

[Stef]

when i recompiled the version of c68k that you had compiled for ian and was distributed as a precompiled object, i was able to get it to run about 2x faster than it had been by compiling it at -Os -no-gcse. It's also about half the size as it was before.

I'll try that at some point though, running it at 10x the speed.

Be careful, sometime GCC just doesn't compile C68K correctly ! i know -Os flag does work on ealier 2.X version but not on 3.X for instance...
I'm really surprised you can even got the size code divised by 2 ! On my version, size down to 360 KB if i remember correclty, which is already pretty low...

[quzar]

3.3.x broke stuff for the SH, but 3.4.x fixed it. The size of the c68k.o that ian was passing out with neocd (which you made for him) was 608kb. I got it to 380 and its going faster than before by far.

[ron]

I got it to 380 and its going faster than before by far.

That's great job. How did u make it ?. It's almost the half of the size, and faster even ?. Those are other words. In fact, my opinion is always based on the idea of a versatile core but with three main addons, stability speed and portability. Now, with this new info, if C68K can perform so easily that speed, should be allright, preparing an emu with the two cores, including the option to run with one or with other, as Chui said a long time ago. It's a nice idea. Cheers

[Stef]

Ah yeah actually 350 KB is the obj size for x86 CPU, it takes about 600 KB here too for DC with -Os level.
Are you sure your 380 KB obj file is not corrupted ? Is it the version you're currently using in NeoCD ?
I'll try to grab GCC 3.4.X to do some tests *:)

[quzar]

Ah yeah actually 350 KB is the obj size for x86 CPU, it takes about 600 KB here too for DC with -Os level.
Are you sure your 380 KB obj file is not corrupted ? Is it the version you're currently using in NeoCD ?
I'll try to grab GCC 3.4.X to do some tests *:)

Its possible that its corrupted... but its what is in NeoDC v2-v2.1 and i've noticed no problems with it. One of the major factors to the increased speed was -no-gcse which turns off optimizations that may break or slow down programs using computed gotos (which both c68k and cz80 use right?)

I'm using 3.4.2, but i noticed some changes in 3.4.3, the newest release version, that may make it even better =P.

[Stef]

Its possible that its corrupted... but its what is in NeoDC v2-v2.1 and i've noticed no problems with it. One of the major factors to the increased speed was -no-gcse which turns off optimizations that may break or slow down programs using computed gotos (which both c68k and cz80 use right?)

I'm using 3.4.2, but i noticed some changes in 3.4.3, the newest release version, that may make it even better =P.

Hehe that -no-gcse flag seems really interesting ;)
C68K heavily uses of computed label and GCC optimiser doesn't like that much. Maybe even old version as 3.0.4 work correctly with that flag enabled :)
CZ80 can both use computed label or big "switch... case" statement. I first did it only for computed label, and that first implemented was even faster... but i wanted it to be portable and work on all C compiler, hopefully "switch ... case" performs already nice for Z80 emulation :)

[plutox]

i need help burning a neogeo cd rom disk. i am using neo4all v2 1st question do i need to put the neogeo bios on the rom cd? 2nd question the roms i have the music files are in mp3 format do i need to change them to cdda?

[Darksaviour69]

1: wrong topic
2: NeoGeo CD emu does not use roms!! as its name suggests, it plays only neogeo CDS!

[fox68k]

I have updated FAME with some bug fixes/improvements:

- Sign flag calculation in inmediate logical instruction fixed.
- Carry flag calculation in NEG instruction fixed.
- Overflow flag in operations with X flag fixed.
- Fixed CPU state stop bit.
- Speed up by about 20%.
- Tiny tweaks here and there and everywhere.

As usual, you can find it here (http://perso.wanadoo.es/orayo/fame/) :)

[Christuserloeser]

I have updated FAME with some bug fixes/improvements:

- Sign flag calculation in inmediate logical instruction fixed.
- Carry flag calculation in NEG instruction fixed.
- Overflow flag in operations with X flag fixed.
- Fixed CPU state stop bit.
- Speed up by about 20%.
- Tiny tweaks here and there and everywhere.

As usual, you can find it here (http://perso.wanadoo.es/orayo/fame/) :)

20% is just awesome!

I'll send you a PM in a few seconds :)

[fox68k]

Another FAME update comes here... :)

Here is what is new:

- Lightweighted entry/exit code.
- Fixed sign/zero flag calculation when moving long data from memory to memory.
- Privilege violation exception fixed.
- Faster interrupt/exception management.
- Timing fixed in MOVEM instructions.

It is pretty stable and fast now and has a very good level of accuracy. Almost every NeoGeo game work in Neo4all (next Neo4all release will demostrate this :D).

Quzar describe it as "BUG FREE and SAVE TO RUN". Thanks Quzar ;)

I would love to get some feedback as well as some news about Genesis Plus running with FAME.

P.D: Next Neo4all release will be really amazing! Keep tunned!

[JMD]

Great :)

[quzar]

Yea, from all I can see, fame has nothing to do with the low compatability of neo4all. Now that I have a BBA and can afford to be sending a 1mb larger file, I have been using fame.