M68K for DC

[dr_Evil]

That's great, dudes... I hope you'll succeed, and I can help by putting on some links for roms(amiga). I have on my girlfriend's PC winuae emulator that I use to play some of my favorite games from my younger days... But on the dreamcast... What can I say, I've been waiting for this day!!!
8)

[LyonHrt]

only freely available roms/disk images, no illegal stuff please :P

[ron]

Yes please. We don't support Ilegal. warez or in any case copyrighted material. Just a couple of comments. Do not post links to ROMS or manufacturer contents, plz, follow the rules. We are sure that everybody knows prefectly how to get that kind of tools. If you don't own the original machine to be emulated, do NOT ask US where to get it. Try in a internet searcher. That's all folks, old friends.

[Stef]

As Ian said, i'm currently writting a new M68K core in C.
It nearly completed, it can already play some genesis games (some opcodes are still missing and some bugs need to be fixed though).

The good point : it's faster than current fastest C core (aka Musashi).
The bad point : it take a long time and memory to compile (600 MB and about 5 minutes with optimisations set to O1)... this is because GCC doesn't like to have so many switch case in a single function (unfortunatly i don't have choice ...). So we have to avoid useless recompilation of the core

I don't know if this can be of some help for your project, maybe you're directly writting an ASM core which is even better for the DC

[Propeller]

Well, thanks a lot for your info... I knew nothing about it! Of course, it will be a source of inspiration for us, there's a lot of research work that doesn't need to be performed if you already have done it. We're thinking of our core as an ASM one, because that's the point next to yours on the roadmap.

C core -> optimized C core -> asm core

Of course, this means lots of work and we'll not face it till the MadriDC eve is done, but we wait for further news on your core with a *big* hunger.

Propeller

[BlackAura]

Six hundered megabytes!

Wow... That's a lot. I guess that's because of the size of the data structures you'd need if you had one function with switch statements for the entire set of M68k opcodes. Still, sounds like there might be some issues with the compiler if it's that big.

Here's the big question - does it work on the Dreamcast yet?

[quzar]

To the team for the new project, what is this new thing gonna be? are you making a new core, or rewriting an old one? if you are rewriting an old one, which?

also, stef, is your new core gonna be at all API compliant with musashi? (crosses fingers) that would be nice... [ /is happy because has 1.25gb of ram ;D ]

[ron]

I would like to name Mekanaizer because he has lots of good and brilliant ideas. As We said days ago the project wouldn't begin until the party MadriDC is over, but all the views are oriented in the direction of the ASM core, to improve the highest performance and quality when emulating.
Keep it up this project, it's calling attetion for many many coders ,so if we can count with Ian Michael's knowlegde should be an extraordinary new for all DC coders community. THX !!!

[Clessy]

Not to be negitive but I dont see this going anywhere because hardly any coders actually know Sh4 ASM. Now even if you use the S4h book and look up string by string conversions you SH4 may be less optimized than the C core because it will most likly be sloppy if you're not use the the language.

Also even once you have this core in asm we all know this isnt the end all solve all problem for coding. DreamSnes is the best example of this. Writing the core in ASM gave extremly lack luster speed ups compared to what they thought it would. Most of the processing power is killed in sound and video. This is a huge problem because you cant use the same video code for every emu without having to change some of the code correct? And if you have to change SH4 code wouldnt that make it so only about 3 of you would be able to use these cores as only 3 of you know a hand full od Sh4....


BTW 600MB sound's exstordanily big for a simple core.....

[Stef]

Six hundered megabytes!

Wow... That's a lot. I guess that's because of the size of the data structures you'd need if you had one function with switch statements for the entire set of M68k opcodes. Still, sounds like there might be some issues with the compiler if it's that big.

Well, all opcodes are implemented in *one* function ... and each opcode is defined with its own scope, GCC doesn't like that much ... actually the main source file is "only" about (edit) 780 KB, but all that scopes make GCC to eat many memories !

Here's the big question - does it work on the Dreamcast yet?

Hehe
I didn't tried since a long time on DC, but it worked ... with optimisation level set to 1, anyway it was already really fast with that level of optimisation

also, stef, is your new core gonna be at all API compliant with musashi? (crosses fingers) that would be nice...

For the moment not really :-/
Musashi does use "byte swapping" stuff where C68K (name of my new core ) doesn't use it, but i'm thinking about adding "byte swap" optimisation as a switch in definition (shouldn't be too many work actually).
I'll also try to make others functions more musashi "friendly" but they will never be 100% compatible since i don't like how some stuff are done in musashi (IRQ and 'Exec' function).

I made an interface in the PC version of Genesis plus which allow swapping between Musashi and C68K "on the fly", sources will help to make change switch easier