PDA

View Full Version : M68K for DC



Pages : [1] 2

ron
April 30th, 2004, 13:13
Greetings !

A new project is being created in order to bring M68K emulation to the DC.
In this case our bet, is to create an emu for the Dreamcast which will bring to our consoles the next systems:

Commodore Amiga 500
Atari ST
Apple Macintosh Plus.

The three computers uses the Motorola 68000 Cpu, and we're compiling info about the emus that already exists in order to port or redesign the cores and the related info.

A good name for this project could be the DC Triple A.
All knowlegde and efforts to convert this idea in a real project will be welcome and appreciated.

Anyway the main team is formed by: Ron, Pablo, Propeller and Mekanaizer. (JMD joins us ;-) )

Ideas and suggestions please, this will be great for all M68K lovers.

Thk Wraggster for all your support to the Spanish DC Scene

JMD
April 30th, 2004, 14:24
You can add the X68000 japaneese computer in your M68k computer list.
But the Triple A name not match anymore ;)

That's a great news because the 68k core is used in so many console/arcade/computer plateform.

What's kind of help do you need ?

ron
April 30th, 2004, 14:51
Yes, thats a circumstance that we have already taken. The X68000 is a great computer and an oppoprtunity for all of us. The name is just a suggestion, so, if You are able to colaborate ;D Welcome aboard. Thx for your post , hope to see you soon.

Ian_micheal
April 30th, 2004, 15:03
Mac, amiga , You do know m68k is also neogeo. And genesis what are you going to do? these cores are Around now C cores that work on dc. Are you going to rewrite the m68k in sh4 asm. If not what is the point Stef D is rewriting from scratch his m68k core for dc.

Or is this to port this emulators.. because the m68k is fully emulated on the dreamcast right now. You will not need to redo them the mame core works fine check the makefile and or source of the neogeo emu.

Amiga500 is very hard project of course any thing i can do to bring the worlds best 16 bit computer to dc i would try but i dont hold much hope of it.

Propeller
April 30th, 2004, 23:45
I'll collaborate too, Ian... Thanks for your work, you are a great comrade!

Propeller

Christuserloeser
May 1st, 2004, 11:02
And genesis what are you going to do? these cores are Around now C cores that work on dc. Are you going to rewrite the m68k in sh4 asm. If not what is the point *Stef D is rewriting from scratch his m68k core for dc

Is he? :-X

...


:o

wraggster
May 1st, 2004, 13:14
sounds like a great new project, i wish you well.

Amiga emulation on the Dreamcast would be quite a feat.

quzar
May 1st, 2004, 19:24
Is this going to be a modular m68k core? because as ian mentioned the m68k was also used in the Neo Geo systems, in the Sega Genesis (megadrive) and in many arcade machines.

Also, will this be from scratch, or a modification of an older core? Currently the Musashi v3.3 m68k core from MAME works fine on the dreamcast, and offers some emulation of m68k variant chips. if not, i assume there is no way you would make it API compliant eh? (hehe)

If you were planning on starting from an all C core and rewritting in in ASM then Musashi is probably the best place to start.

ron
May 2nd, 2004, 00:02
Good NIght from MadriDC.
We're going to meet tomorrow to discuss about how to organize the development of the EMU, and what elements are going to be used, about the cores, and to trace a plan to sort our purposes. You will be prefectly informed. Thx to all who are supporting this beauty project.

WHurricane16
May 2nd, 2004, 00:19
Good luck to you guys ;)

dr_Evil
May 2nd, 2004, 00:49
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
May 2nd, 2004, 01:27
only freely available roms/disk images, no illegal stuff please :P

ron
May 2nd, 2004, 09:49
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
May 3rd, 2004, 08:52
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
May 3rd, 2004, 09:03
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
May 3rd, 2004, 09:31
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
May 3rd, 2004, 10:32
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
May 3rd, 2004, 10:38
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
May 3rd, 2004, 14:42
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
May 3rd, 2004, 15:37
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 :p) 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 :)

Stef
May 3rd, 2004, 16:05
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.


I'm not a master of SH-4 assembly but i believe that it is quite simple to do a faster M68K core in SH-4 ASM than in C.
- First because a CPU emulator is really something where ASM will always keep a big advantage compared to C. For instance, emulating a ROR instruction with the correct flags need many C instructions where a few of ASM ones does the job...
Generally, just because of flags calculation stuff, ASM performs a lot better than C in CPU emulation.
- Second : the only SH-X C compiler we can use here is GCC, and unfortunatly it isn't the best C compiler for this CPU :-/ Generated code is somewhat a mess ... some values written in registers are never used later ...

IMO, a good knowledge of fast CPU emulation methods is more important than a good knowledge of SH-4 assembly :)




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....


That's true, almost time video code is the bottle-neck.
But i don't think ASM can bring a big speed boost here compared to CPU emulation. Just have to optimise code and maybe use hardware acceleration where it's possible :)




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


I agree ;)
I upgraded memory on my laptop just for that *:P

Propeller
May 3rd, 2004, 16:23
I totally agree with Stef.

One of the "outputs" of this project is going to be a quick manual to SH4 newbies, in an effort to provide the scene with more people familiar to SH4 asm. It's a necessary condition that would eventually guarantee the quality of the results of the Dreamcast scene in the next couple of years.

Propeller

DemoniusX
May 5th, 2004, 02:30
I just want to comment on a couple things, I am all for this project, but I don't think
amiga 500 would work on DC, I mean with full speed and sound because the amiga (this and
commodore 64 are best of the 80's cpus IMO} is too complex, but I can see atari ST and maybe
MAYBE the Apple but I don't see that either, not to be negative but I for one would be up on
amiga like a woman *whistles* but I just don't think the DC can handle a perfect amiga emu
if so I will so be shocked :}

Clessy
May 5th, 2004, 02:40
Let's be serious here son the DC and play PSX games with super Ehanced graphics and you dont think it can handle a 80's pc....? I Sadly think your mistakin. Once everyone knows Sh4 your gonna see alot of kick ass emu support for DC game almost like a rebirth.

wraggster
May 5th, 2004, 02:44
Its only a matter of time until we many coders who know sh4asm like the back of their hand.

wouldnt it be fitting for the homebrew scene to release something thaat stuns the software world.

Just remember what the donkey kong country games did for the snes.

Its like having a car and tweaking it everywhere to squeeze the perfomance out of it.

One day we will see smoe amzing releases, the neogeo cd emu is one such release.

DemoniusX
May 5th, 2004, 04:32
ok, if fullspeed and sound amiga emulation happens of the DC, I will probably have a heart
attack, cuz what I wouldn't do to play risky woods on the DC, Ian micheal knows how much I
love the amiga, heh. I tried using the amiga emu called "winUAE" (sorry for being offtopic}
and I cannot get the fudging thing to work right, it sux. I hope the "rebirth" if it is a reality
happnens, to play "never thought possible" on dc, that would be definately a dream on DREAMcast
:}.

Ian_micheal
May 5th, 2004, 06:05
Hmm i think your forgeting how complex the amiga is here. Your have to have cycle perfect emulation it's more complex then a snes in some ways more then a psx. Im sorry to say i dont beleive it could be done at a playable speed. Just because it's a 80's pc means nothing.. SH4 asm is not going to totaly fix or help you port a very complex emu that uses lots of c++ kos does not support.

I can go throu in detail if you dont beleive me but amiga cant be underclocked or messed around with has to be perfect emulation. *I dont think you guys know how complex an amiga is compaired with an atari st. It has masses of custom hardware the amiga for video and sound and many cpu's much like the saturn.

Stef
May 5th, 2004, 11:32
Hmm i think your forgeting how complex the amiga is here. Your have to have cycle perfect emulation it's more complex then a snes in some ways more then a psx. Im sorry to say i dont beleive it could be done at a playable speed. Just because it's a 80's pc means nothing.. SH4 asm is not going to totaly fix or help you port a very complex emu that uses lots of c++ kos does not support.

I can go throu in detail if you dont beleive me but amiga cant be underclocked or messed around with has to be perfect emulation. *I dont think you guys know how complex an amiga is compaired with an atari st. It has masses of custom hardware the amiga for video and sound and many cpu's much like the saturn.

Having CPU cycle emulation will improve a lot compatibility, but it's always possible to do a scanline based amiga emulator.
I think it's possible to have a full speed amiga emulator (without extras chips) with 80% software compatibility on Dreamcast... but is it really interesting to have a standalone amiga 500/600 emulator with only 80% compatibility rate ?
Remember Genecyst (a genesis emulator), Sardu made some choices, he volontary faked severals hardware features but then, he got about 85% of games playables at full speed with sound on a simple Pentium 100.
It was at this period the best choice ;)

Ian_micheal
May 5th, 2004, 11:51
Beleive it when i see it Stef. But ive run a lot of tests doing that breaks almost 80% of games not the other way around still was not fullspeed or even close to it.


Much easyer to do a gba emu then this. Amiga you need cycle perfect emulation or all games break not just a few like the genesis.

Stef
May 5th, 2004, 15:17
Well i though that WinUAE used a dynarec for the M68K CPU, how it can do perfect cycle emulation with a dynarec ? and WinUAE does work at fullspeed on old machine (i speak about amiga 500 or 600)...

Anyway i don't know the amiga hardware much... so you're probably true.

Stef
May 5th, 2004, 15:58
specs for the old machine it works on you have tryed are. Ive tryed it on a 200mhz p1 *about 30% speed with sound on. I can take a video of it to prove it.



http://eab.abime.net/showthread.php?t=13374

Olders version of WinUAE were faster... and from another guy, Fellow was even faster.
but i guess they were a bit optimist ;)

Ian_micheal
May 5th, 2004, 16:06
Check black aura's posts. At dcemu I post them. Most of these people saying fullspeed have never used a real amiga neogeo cd sdl dc some people say fullspeed it's hardly even close to it in real world.

Any way check black aura's post on it. Im an amiga fan i like it the most just not going to happen. Fellow is x86 asm not portable


Yeah lot of people on forums like to lie or confuse speed with whats real. Amiga in real life runs a lot better then UAE and FELLOW ever *does even on mu 850mhz AMD it's still Not perfect emulation or very speedy to me.

This week end im having an amiga week end ive got 500+ real games in box's to revist and my amiga 600/40 is going to get a dusting off. I love a dc one Stef really but i cant tell people. Fairy tales. We dont have fullspeed snes emulation, An amiga is up to 3 times more complex. Thats just the facts from a programing standpoint. No amount of SH4 is going to completely save you when the system is this complex.


|Now ive looked all over dcemulation for you anthor post about amiga emulation on *DC


BlackAura
DC Devver



Joined: 30 Dec 2001
Location: Nowhere
Posted: Mon Dec 16, 2002 6:25 am * *Post subject: * *

--------------------------------------------------------------------------------

karsten wrote:
Well now i'll ask a noob question: (don't flame please!)

why nobody tried the amiga emulation? Amiga had greats games, and the machine wasn't really powerful (a 133mhz pc emulates it well). Is it about the amiga OS or porting difficulties?


You've seen an emulator that runs well on a 133MHz PC? Where? Last I checked, they needed a 400MHz CPU to run well. The fastest I've seen was Fellow, which ran well on a 300MHz machine, but they need at least a 500MHz machine to run most games at full speed.

The problem is that the Amiga is a stupidly complex machine, and it's also pretty powerful. Complex machines are very slow to emulate, as are powerful ones. And they're also really hard to write emulators for. That means that you might see a port of UAE to the Dreamcast, but it'd be unusably slow, and it's not likely that anyone will write one from scratch because it'd take years to get it working well.


Case you missed the links i posted on the subject

http://www.dcemulation.com/phpBB/viewtopic.php?t=42998&highlight=uae whole topic.

http://www.dcemulation.com/phpBB/viewtopic.php?t=39234&highlight=uae

http://www.dcemulation.com/phpBB/viewtopic.php?t=34685&highlight=uae

many more at dcemu.. Black aura Knows what he is talking about one of the best programers i know dc or pc.

Im sorry i belevie him over some unknown people on emulation forums. Really is not that doable at all i dont see it being a chance at all.

But let all this info server some one to prove us wrong. No way i could do it even with a big team.

wraggster
May 5th, 2004, 19:03
Can i ask if older versions of emulators that worked on pentium 100s etc, would be far easier to port to the dreamcast than recently released sources?

for example snes/genesis emus than ran well on a pentium

Clessy
May 5th, 2004, 19:07
I dont know why people are so damn worried about amiga yet. One no ones even started on this Sh4 core and secondly we have tons of other emus much easier to make they arent anywhere near close to fullspeed.

Genesis should oe been done by now and I dont understand why some coders cant get together and finsh it up. Dont even say its to complexed to finsh it up when Ian's version with sound ran pretty decent and was just missing tons of features. Add in the frame skip by quazr and this new Optimized M86 C+ core then you'd have full speed.

Christuserloeser
May 5th, 2004, 22:08
@Stef D
I'd like to welcome you to the DC scene and I love to see you working on a Genesis/M68k emulator for DC! BlackAura is a nice guy and I am pretty sure that with IMRtechs help and the ppl working on the DC Triple A project this whole thing definitly will have a bright future...

For me u truly are a hero since I never had as much fun playing my Genesis games as with wGens! I wanna thank you for a long long very dark year that u brought some light into...


@Ian Micheal
I think you might be wrong because there definitly IS a way of emulating the AMIGA500 but I don't think that anyone has enough breath to do this til it's finished and playable with sound but even this could be proven as wrong...

Bleemcast, Genecyst etc are very good examples for fast and good programming!

...might be as hard as doing an N64 emulator 4 DC from scratch ;D but it could be done!

No one believed to ever see a good working NeoGeo(CD) emulator for DC too - but u and all the others working with you made it reality! Not to mention that it might be perfect within the next months :o
Everyone simply would have laughed at u if you'd announced that a year ago ;)

Damn I love NeoCD :)

So plz stop flaming :P and give them some helping hand ;)

DemoniusX
May 5th, 2004, 22:20
No wonder I can't run risky woods off winUAE I have a 500 mhz and it run but the sound goes
too fast and the game is slow. I need to track me down a real amiga and a copy of risky woods
the music in that game rocks and winuae and Fellow KILL IT. amiga without music is like
cake without frosting, AIN"T GOOD ENOUGH. now the atari st emu I am all for because I like
the ST despite its extremely weak sound chip, can't produce quality tunes.

Ian_micheal
May 6th, 2004, 05:02
Not to be a downer but Im not wrong and ether is Black aura on this subject

http://www.dcemulation.com/phpBB/viewtopic.php?t=42998&highlight=uae *whole topic.

http://www.dcemulation.com/phpBB/viewtopic.php?t=39234&highlight=uae

http://www.dcemulation.com/phpBB/viewtopic.php?t=34685&highlight=uae

http://www.dcemulation.com/phpBB/viewtopic.php?t=3608&highlight=uae


Christuserloeser *im not flaming but giving the facts to save people wasted time. Im a big commodore fan amiga port was my first project. I know it cant be done. ive tryed

Why dont we work on nogeo cd it's near perfect and only needs a little push from other people i cant seem to fix cd audio on all games or get sfx to work right. It's open source. If were working for the greater good then it's a good project. Many others that need finshing like wonderswan all of use working on it would be finshed.

Just a thought should we not finshes things that are unfinshed im only a porter and c code haker.

DemoniusX
May 6th, 2004, 05:30
an, you know your amiga, I also know that the Dc cannot handle the great power of the amiga
amiga in their games and apps, utilizes the different processors that the amiga has, the DC
just cannot do it, I wish people would realize it, Ian you explained it PERFECTLY. IF it happend
then I can call myself a liar, but until it does I still think the programmers that think
they can pull amiga off are living too damn much in the dream world.

Propeller
May 6th, 2004, 09:15
Anyway guys, emulating the Amiga 500 is not the only point on this idea. An asm done 68k core for the sh4 would undoubtely improve things. If it's possible to emulate Amiga, we'll do it, but it's not the only point I see on this proposal. There's a lot of fun hidden in here, and everyone is called to collaborate. And don't set the Amiga emulation as the only goal, because I think that the next step in dcemulation will be doing fast mean and sharp asm cores, starting from the most commonly used ones, and this means m68K.

I also appreciate Ian's interest on this subject: Undoubtely, there's not an *easy* or *fast* way to emulate Amiga, but we may keep searching for a way to achieve a good compatibility combined with fast (but not complete) hardware emulation.

Thanks for all of your replies, I'm so happy that this topic suggested a hot, interesting discussion.

Propeller

Stef
May 6th, 2004, 10:05
@Stef D
I'd like to welcome you to the DC scene and I love to see you working on a Genesis/M68k emulator for DC! BlackAura is a nice guy and I am pretty sure that with IMRtechs help and the ppl working on the DC Triple A project this whole thing definitly will have a bright future...

For me u truly are a hero since I never had as much fun playing my Genesis games as with wGens! I wanna thank you for a long long very dark year that u brought some light into...


Thanks for your cordial accueil :) I'm happy to see you had fun using Gens, this is our reward *;)
I always followed the DC emulation scene but i never really had the time to involve myself inside ... until recently.

I know Ian and BlackAura, they are both great and talentued dever guys, I'm sure we will do nice stuff together ;) I don't know much "DC Triple A" team, but they seem to be really motived, it would be nice to join our effort on commons projects (who said M68K ? *;D )

Hopefully, i'll be able to complete something i started (speaking of the 68K core in C)... didn't happened from a long time !

About Amiga emulation on DC, well, i can't really estimate what the DC is able to since i never coded in pur SH-4 assembly using internal cache stuff ... nor i can't estimate how many CPU power requires amiga emulation since i don't know it's hardware much ...
But is it really important ? i don't think this debate will bring us somewhere... let's go coding instead *:D

I just realized i got the "DC coder" status *:-*

Ian_micheal
May 6th, 2004, 12:39
Anyway guys, emulating the Amiga 500 is not the only point on this idea. An asm done 68k core for the sh4 would undoubtely improve things. If it's possible to emulate Amiga, we'll do it, but it's not the only point I see on this proposal. There's a lot of fun hidden in here, and everyone is called to collaborate. And don't set the Amiga emulation as the only goal, because I think that the next step in dcemulation will be doing fast mean and sharp asm cores, starting from the most commonly used ones, and this means m68K.

I also appreciate Ian's interest on this subject: Undoubtely, there's not an *easy* or *fast* way to emulate Amiga, but we may keep searching for a way to achieve a good compatibility combined with fast (but not complete) hardware emulation.

Thanks for all of your replies, I'm so happy that this topic suggested a hot, interesting discussion.

Propeller

There is no way to do an amiga emulator with out complete emulation thats the catch. Every game uses every part of the hardware. DMA system is very complex. I think some of you should look at sh3 asm it runs on dreamcast and is more compact And runs slight faster. But The sh4 core's your talking about asm Have to be API complaint or were going to have to Totaly re do any emulators to match it leading to a lot of work.

I love to see MUSASHI Version 3.3 Re written in sh3 or sh4. API complaint. over night lots of project fullspeed or close to it neogeocd mame projects genesis plus many more use this core.

But sh4 asm is not going to help if the cpu is running fullspeed in c example snes emulation. SH4 and asm is not the god cure to hardware limts of the dreamcast.

Im only a c coder and porter. I know your main goal should not be the amiga. It's a waste of good time that could be spent doing some thing that can be achived.

Debate is fine but none understading of the machine your wanting to emulate and the dreamcast limts is going to end with a whole lot of people upset.


Atari st and mac plus sound good. Good luck to you guys but these new cores would have to be API complaint with c cores we used to be of a lot of use. Moding emulators back and forth to match the cpu cores is not allways easy or a nice thing to do can break things working.


Any way motvation needs to spring from some thing that can be achived and worked for.

Good luck guys ill leave it at that.

Propeller
May 6th, 2004, 13:36
Yeah, compatibility is not an option at this time, Ian. It *must* be compatible with the most often used core.

And about that problem you refer to, the cpu running fullspeed in C... if there are spare cycles on a CPU, one must use them. Maybe implementing multitasking, maybe doing another type of emulation (there are more than one or two type...) but that's a "must be".

Propeller

Ian_micheal
May 6th, 2004, 15:22
Must often used core is MUSASHI m68k. Used in almost every project on dc that uses a m68k. I think some optimzing tips from some of, you guys, would be handy. For these cores. Snes9x uses a tight loop checking functions and varys it depending on load as far as i understand it's turned on via a -D which works and brings 10% speed. type of vary-able unclocking depending on load or left over cpu cycles.

If thats what your talking about. There is Nothing much but setup and porting and compiler settings i can help with and basic c coding. ASM is not my strong point i leave that to the compiler. Sorting out the compiler to make better code for all of us, would help as well. Unless your an sh4 expert gcc is going to make code almost as fast as badly made hand tuned asm.

I lend any help i can on it. Mostly will be porting and setup. Asm is some thing i dont have the skill for at this time. Gcc compiler would beat me.

Stef
May 6th, 2004, 15:34
I think some of you should look at sh3 asm it runs on dreamcast and is more compact And runs slight faster.


What are you talking about ???
Do you mean there is a M68000 CPU emulator written in SH3 assembly ?



But sh4 asm is not going to help if the cpu is running fullspeed in c *example snes emulation. SH4 and asm is not the god cure to hardware limts of the dreamcast.



I guess we can emulate a 16 Mhz 68000 with Musashi on a DC, nice, this is actually twine as much we need for Genesis for instance, for that means it still take about 50% of CPU time just for the 68K emulation !
Then only half of CPU power is available to emulate the rest ... it's always better to have a faster core, then you have more time for the rest.
Of course, optimise the 68K core only isn't really usefull, i know Genesis Plus won't be fullspeed just by changing musashi, even without 68000 emulation, Genesis Plus DC doesn't run at full speed :-/

Propeller
May 6th, 2004, 15:43
Thanks for your support, Ian. By the way, I knew Musashi is the most often used C core for 68k, but it was just a way for me to refer to it, calling it "the most used" ;D

Now, it's time for documentation, after MadriDC (we're kinda overloaded for now) we'll start.

Propeller

Ian_micheal
May 6th, 2004, 17:38
[quote author=Stef link=board=dcemu;num=1083323639;start=30#43 date=05/06/04 at 15:34:22]

What are you talking about ???
Do you mean there is a M68000 CPU emulator written in SH3 assembly ?


No i wish :). Sh3 asm runs on the dreamcast it can run sh3 code sh4 chip is compatable with sh3 code. On some tests ive seen on docs sh3 runs faster then sh4 asm on the sh4 chip some times not allways. But it's intresting.

SH4 chip in the dreamcast can run sh3 code compiled for it.

Dont hold me to it. But Gleem used a sh2 asm core in the nes emu for example. So we could use sh2 or sh3 asm on the dreamcast that might give a wider range of coders a chance.

Gleem the first nes emu used a sh2 cpu core.

Christuserloeser
May 7th, 2004, 00:02
The DreamSNES team rewrote the 65c816 SNES CPU (clocked at 3,58Mhz) specific code only to SH4 assembler to get faster emulation results and IMO it really shows: After porting and further optimizations, emulation speed has almost doubled! Main prob with SNES were gfx and sound!

If M68k SH4 would take the CPU time under the 50% mark even SegaCD and AMIGA500 emulation could be possible!


Why dont we work on nogeo cd it's near perfect and only needs a little push from other people i cant seem to fix cd audio on all games or get sfx to work right. It's open source. If were working for the greater good then it's a good project. Many others that need finshing like *wonderswan all of use working on it would be finshed.

I thought u`d just take a break! I didnt know u were getting stucked with this! I`d like to help out since I realy love the NeoCD for DC but I can`t program :-[
Damn, look how much ppl are getting back to the scene after this great release! Its the currently most important project for the DC scene!


Chris

Clessy
May 7th, 2004, 04:54
If you cant go anywhere with speed on NeoGeo Cd emulation you can defanitly go much father in options and menu's.

Also I'm still trying to figure out why you never finshed WonderSwan Emulation. It need's saving and sound and Oswan for PC has really nice sound now too. Nothing compared to Wscamp still but its much better than it use to be.

quzar
May 7th, 2004, 05:47
that thing is hard. i tried to do things to the source, but ian has lost his old source anyways so anything would have to be a from scratch fix

Ian_micheal
May 7th, 2004, 06:41
Ok Maybe this is easyer .

3mhz cpu emulated on the super SH4 chip runs fullspeed Making it Converting it to SH4 would have little to no effect *when the emulated chip is running fullspeed.


Amiga is impossable to do on the dreamcast at any useable speed.

wraggster
May 7th, 2004, 08:37
most fans of retro gaming would love to see an amstrad cpc64 emu, even if it came from the mess sources.

a dragon 32 emu would be neat and theres an sdl source version of that.

Ian_micheal
May 7th, 2004, 09:05
CpC64 emu runs at 20% speed on mess dc sources. Dragon32 on the other hand i have not tryed. That's intresting as well. Lot of good projects to do..

Dream msx with a new menu and easy use would be one of the best. If only!

Stef
May 7th, 2004, 09:06
No i wish :). Sh3 asm runs on the dreamcast it can run sh3 code sh4 chip is compatable with sh3 code. On some tests ive seen on docs sh3 runs faster then sh4 asm on the sh4 chip some times not allways. But it's intresting.

SH4 chip in the dreamcast can run sh3 code compiled for it.


I prefer that ;)
I was just thinking "but what are we waiting for use it !" ...

Yeah the SH4 CPU is backward compatible with SH3 and SH2 instruction set :)
If someone want to start a ASM 68000 emulator for DC, i think he should use only the SH3 or SH2 instructions set, it's enough to do a 68000 emulator and that permit compability with others machines (pocket PC, Saturn, 32X :p)

Stef
May 7th, 2004, 09:23
If m68k SH4 would take the CPU time under the 50% mark even SegaCD and AMIGA500 emulation could be possible!


Optimist ;)
In Gens (PC version of course), M68K emulation represent only about 13-15% of CPU time !
VDP rendering and video blitting stuff almost take 50% of CPU time.
So having the M68K taking less than 50% on Genesis Plus DC is a must !
I hope to drop down the 68K part to 25-30% with my new core, but then, the VDP engine have to be optimised to have full speed, maybe the YM2612 core should be tweaked also...



3mhz cpu emulated on the super SH4 chip runs fullspeed Making it Converting it to SH4 would have little to no effect *when the emulated chip is running fullspeed.


I don't understand why you're saying that ...
Think about a 6502 CPU emulator written in C.
We want a 3,58 Mhz CPU, even in C, the DC will handle it at full speed, but with unoptimised code, maybe that'll take about 80% of the SH4 CPU time...
80% of a 200 MHz SH4 CPU to emulate a 3.58 Mhz 6502 is a big waste ! even if it does run at full speed, only 20% of SH4 time left for other part of emulation !
Now, if we use a very optimised 6502 core written in SH4 ASM, maybe that will take 10% of SH4 time, then 90% left for the rest, this gives a *very nice* speed boost compared to the C core... even if the C core was able to run at full speed when running alone !

Ian_micheal
May 7th, 2004, 10:01
True. Just a lot of effort. the speed change in dreamsnes with the asm cpu core and with out it was not that great. Depends how much the emulated cpu core is taking up . Your right of course thinking about it more it can be both way. Just have to try that i guess. Ive found on pc c and asm cores if they were running at fullspeed the speed change was next to nil if the system could do it with out losing any thing from emulating it.

BlackAura
May 7th, 2004, 11:45
Speeding up the CPU will definitely help for Genesis Plus. Without video emulation, it runs over full speed, but not all that much over full speed. If you render about one in eight frames, it runs around full speed. At a rough guess (very rough, and I can't be any more accurate without some kind of profiler), the VDP would need to be made eight times faster to get it to run full speed with no / minimal frameskip. That ain't going to happen.

They really both need a lot of work. If we could get the CPU emulation down to 30% or so, we'd only have to get the VDP emulation down to 60%, which is a lot more achievable than getting it down to 20%.

I really need to have a better look at how the VDP actually works. Were it not for the fairly complex (compared to a NES or an SMS) layering system, it'd be fairly simple to render quickly, because you could do it in one pass, instead of the three or four that Genesis Plus uses.

I think I can see a couple of potential speedups, but I don't think anything short of a complete rewrite will get it up to the kind of speeds we'd need at present (like 20% of the CPU time), and even that probably won't get us there without a faster CPU emulator, just as a faster CPU emulator won't get us there without a faster VDP emulator.

Generator allegedly has a retargetable binary translator for the M68K emulation, but I've looked in the source and couldn't see anything that resembled any of the parts needed to implement a binary translator. If it actually does have a DBT and it can be retargetted for the SH-4, that might give us a useful speed increase. However, the only evidence I see of that in Generator is a couple of comments like "hack to fix XXXX which was broken by the recompiler" or "hack to support recompiler".

One other thing... Could Musashi be modified (along with the rest of the emulator, obviously) to store words in host native byte order (little endien) rather than the M68k's native byte order (big endien)? I don't think it'd be that hard, since Musashi doesn't directly access any memory, but...

Stef
May 7th, 2004, 11:52
True. Just a lot of effort. the speed change in dreamsnes with the asm cpu core and with out it was not that great. Depends how much the emulated cpu core is taking up . Your right of course thinking about it more it *can be both way. Just have to try that i guess. Ive found on pc c and asm cores if they were running at fullspeed the speed change was next to nil if the system could do it with out losing any thing from emulating it. *

The example i taken in my previous post is exagerated just to show that it can make a big difference in the worst case ;)

The problem with DreamSNES is that the C 6502 core wasn't the only responsible of the poor emulator performance. I'm sure the VDP code was much more heavy than 6502...

If DreamSNES was running at 30 FPS (without frame skip) with the old 6502 core and if that core was taking about 30 % of CPU time, then optimise the 6502 will never bring fullspeed, since in the best case, we can gain less than 30% speed... i guess that's what you meant ;)

The best thing to do before start optimisations is a good profiling to see where cycles are spent ;)

Stef
May 7th, 2004, 12:18
Speeding up the CPU will definitely help for Genesis Plus. Without video emulation, it runs over full speed, but not all that much over full speed. If you render about one in eight frames, it runs around full speed. At a rough guess (very rough, and I can't be any more accurate without some kind of profiler), the VDP would need to be made eight times faster to get it to run full speed with no / minimal frameskip. That ain't going to happen.


Yeah, optimise the M68K core in Genesis Plus will make the frame skip option more efficient ;)



They really both need a lot of work. If we could get the CPU emulation down to 30% or so, we'd only have to get the VDP emulation down to 60%, which is a lot more achievable than getting it down to 20%.

I really need to have a better look at how the VDP actually works. Were it not for the fairly complex (compared to a NES or an SMS) layering system, it'd be fairly simple to render quickly, because you could do it in one pass, instead of the three or four that Genesis Plus uses.


I agree, as i said before, complete video emulation take a bit more than 50% in Gens and it's where i spent most time for optimisation...

VDP drawing in Gens work in 3 pass :
* Background color / Scroll B
* Window / Scroll A
* Sprites

Priorities and Shadow/Hilight effects are all handled without any extras pass.

I didn't checked how things are done in Genesis Plus, but from Charles McDonald, it's already quite optimised so i guess it work in the same way...
But anyway, i'm sure we can do something better for the DC ;)



... and even that probably won't get us there without a faster CPU emulator, just as a faster CPU emulator won't get us there without a faster VDP emulator.


Agree again, and after that maybe we can take a look on the YM2612 emulation, i was a bit dissapointed to see how my YM2612 emulator performed on dreamcast : faster in almost case, but can be slower in some case ...
I guess the code size overhead kill optimisations here :-/
But we can always check in olders MAME FM emulator version to gain some frame ;)



One other thing... Could Musashi be modified (along with the rest of the emulator, obviously) to store words in host native byte order (little endien) rather than the M68k's native byte order (big endien)? I don't think it'd be that hard, since Musashi doesn't directly access any memory, but...

Actually Musashi does that for speed reasons, then it doens't need to swap high and low byte when it is fetching next opcode... i guess it's not difficult to change that, just need to change the "direct read memory function".

C68K does work in host native order by default :)
I recently added a switch to allow the use of "byte swap" optimisation (actually it was more to be musashi friendly). Unfortunatly this doesn't speed up things a lot in C68K since it was originally designed for "normal" order :-/

Ian_micheal
May 7th, 2004, 16:41
Can any one tell me about this in detail.

/* If ON, the enulation core will use 64-bit integers to speed up some
* operations.
*/
#define M68K_USE_64_BIT OPT_ON

If this really works We should try to edit this to suit the dreamcast more.

Clessy
May 7th, 2004, 18:51
What I dont understand is why people give up on things. I mean i'd be using Gen+ now if blackaura would of worked on the underclock charts he wanted. That would of speed games up alot and also you could take Ian's sound support he add and finally add in saving. It would be as good as SegaGens and thats what i'm currently using. Then again we came across the point that theres no way its gonna support SegaGens save games so I dont know if i'd use it yet.

WaCk0
May 7th, 2004, 21:21
good read this topic ;D

its nice to see that people still working on emulation for DC.

Clessy
May 7th, 2004, 21:29
What are you talking about. We don't actually ever work on any of these things. We just kinda sit here and talk about how awsome it would be if anyone put more effort than a week into any project and how it would turn out great. This topics been brought up several times and everyones always like yeah thats awsome i'm gonna go work on it. 2 days later they've quit and moved onto a new project which they will give up on in another week or so.

miracleman
May 7th, 2004, 23:35
if thats the case how come we've got so many great emulators and homebrew projects? and why stick around the scene if it's so poor? Not a month has gone by in the last 3 years that i havn't tried a new piece of homebrew for my dc. for that i'm VERY grateful to the coders

LyonHrt
May 7th, 2004, 23:45
Please keep to the topic, and please do not talk about supporting warezed software.

DemoniusX
May 7th, 2004, 23:48
Too bad Gens can't be ported on DC, its the BEST Genesis emulator to grace the PC, runs
perfect, no hassle what so ever. runs PERFECT :}. Black aura just a quick question do
you plan on working on genesis plus anymore, it is good right now but I was just wondering
when you have time do you plan on working on it? thanks :}

quzar
May 8th, 2004, 06:15
Well, just so you all know, in the .82 sources of MAME there is a newly revised Musashi. it includes 68008 support and cycle counting fixes. Also there are supposedly some newly implemented ops but i dunno. I was gonna modify this to work in neocd/sdl but i wasnt sure what files were used since there are now like 15 files in the m68k folder for neocd and i cant get on MSN. I cant remember what uses 68008, but now that means the possibility of playing it on the DC =P

Ian_micheal
May 8th, 2004, 07:58
Check the virgin folder that is the cpu core and what files are used the other files are genrated. thats why i included the virgin folder. Any new cpu core would have to be patch with the bios calls. Msn is playing up for me i have to use DMSN just to sign in.

BlackAura
May 8th, 2004, 08:07
I mean i'd be using Gen+ now if blackaura would of worked on the underclock charts he wanted.

You expect me to go through hundereds (or is it thousands?) of games and work out appropriate clock settings by myself? I asked if anyone wanted to help out with it, and I got a couple of responses like "XXX and YYY work well on most games", which isn't really very useful.


WWe just kinda sit here and talk about how awsome it would be if anyone put more effort than a week into any project and how it would turn out great.

A week? Ha!

Are you aware that Genesis Plus was actually developed over a time period measured in years, and that's not including the time it took to write the CPU emulators (which would have been considerable, but they were written as part of MAME, not Genesis Plus)

To get GP working closer to full speed would require a load of modifications to that code, if not a complete rewrite in a number of places. We're talking about months here, not weeks, at the very least, probably a lot more considering that we aren't working on this full time like the guys at Sega were when they were coding the Smash Pack emulator.


Black aura just a quick question do
you plan on working on genesis plus anymore, it is good right now but I was just wondering
when you have time do you plan on working on it? thanks :}

I do intend to do some more work on it. I don't have time right now, and won't have time for at least a couple of months, but I intend to do some more work on it eventually.

DemoniusX
May 8th, 2004, 08:57
Thanks for the info black aura, I look forward to it. take your time like I tell my best bud Ian micheal, don't rush genius ;)

Christuserloeser
May 8th, 2004, 21:17
What are you talking about. We don't actually ever work on any of these things. We just kinda sit here and talk about how awsome it would be if anyone put more effort than a week into any project and how it would turn out great. This topics been brought up several times and everyones always like yeah thats awsome i'm gonna go work on it. 2 days later they've quit and moved onto a new project which they will give up on in another week or so.

:o

er... ???

...no comment >:(

Clessy
May 9th, 2004, 22:42
I didnt mean to lash out at you like that BA it's just that is so frustracting to see that you have all the parts you need to make a substacual update yet you dont have the time and no one else wants to help you out and make the next release. I mean we got sound but its only for the SGG which had offer a centered screen and only supported one game. If the sound was just added back to the orginal version which you release that would make a awsome release. I'd use it to play all my Genesis games that didnt require saving.

About the underclock chart. Would you like me to start testing with it? I mean I could test many games but as soon as you add sound those settings would become off again.

BlackAura
May 10th, 2004, 06:56
Don't worry about the Z80 or frameskip. The Z80 can't be significantly underclocked, because it'll screw the sound up on most games.

All I really need is the M68K clock speed. Basically, this value should be the minimum value before the game starts slowing down instead of speeding up. Some games need full speed, but many can get away with 200, especially the earlier games.

Ian_micheal
May 10th, 2004, 07:01
Ive put The same frameskip code into The sdl version now and centered screen. Workes a lot better then before bascaly it needs a menu. Ive got the sound working better it's inited when the frameskip happens seems to force it to synic.

Any way it does work about as well as dreamsnes but it needs a menu i never bothered with it Bacause Black aura is still working on it and he ported it first.

Kamjin
May 10th, 2004, 10:40
backtracking a bit..

Quzar,
the 68008 is a 68000 with a 8 bit data interface...
just as the 68K is a 32bit cpu with a crippled 16bit databus..
so the only thing that changes are the timings.. there's
also two packages.. one with enough address pins
to handle 1MB and the other for 4Mb I think..

as for what uses it.. arcade wise.. it's totally slipping
my mind.. but I'm staring at some chip's I've pulled out
of PCB's so something uses it????
Computer wise I think the Sinclair QL used it..

quzar
May 10th, 2004, 11:17
cool. maybe we will se some emulators for that soon then :P

BlackAura
May 10th, 2004, 15:33
Ive put The same frameskip code into The sdl version now and centered screen.

Really? I didn't think you'd seen the auto frameskip code...

Ian_micheal
May 10th, 2004, 17:23
It's an edited version of Quzar's Frameskip code From neogeo cd. If you check the sources to 6.5 you will see it. Thats were it's from And added to the SDL version of genesis plus. Works very well Sound and all on some games. Better then whats out there at the moment. Needs a menu.

BlackAura
May 10th, 2004, 19:07
Ah, I see...

The auto frameskip code I wrote allows GP to run pretty much at full speed, but with low framerate unless you start playing with the clock speeds. Personally, I think it's unplayable like that, but then again I was trying to play Sonic the Hedgehog. It's not exactly the most forgiving game when it comes to frameskipping. Rocket Knight Adventures (one of my favourite games on the Mega Drive) works pretty well. The sound is still crap (by my standards, anything less than perfect is crap), and I still need to work out a better way of handling it.

Ian_micheal
May 11th, 2004, 06:44
Yeah combine the auto frameskip , with Under clocker table for a lot of good games the sound seems to be fine to me i dont get any problems when i force it to init the same time the frameskip starts. Things blow up when they should.

Sample rate is low but it does not have sega smash pak sound it's has fm as well.

These things together it's very playable and with sound.

Clessy
May 11th, 2004, 17:28
Ian, I don't see why you can't release your newer version just because BA orginality ported it. I'm sure he wouldnt mind and i'd so like to play around with it. Did you ever add saving?

BlackAura
May 11th, 2004, 19:09
Saving would require changes to the emulator itself, because of the way Genesis games implement saving. They actually map the save RAM to part of the ROM area, which means you need to be able to swap the ROM out and replace it with SRAM. Genesis Plus can't do that at all at the moment.

DemoniusX
May 11th, 2004, 22:33
IMO, Black Aura and Ian Micheal should work together to make a great Genesis emu. I am saying
when you have time, you guys got lots of projects your working on, don't rush your genius :}
I think Ian an BA have the ability and determination to make genesis plus the BEST out of
the bunch right next to nester and Neo Cd (the two greatest at the moment IMO}.
I have total faith in you guys, your biggest fan is rooting for you!!!!

wraggster
May 11th, 2004, 22:47
I do like to see coders working together on projects and its nice to see such recognition as in the case of the neocd project.

If coders can work as a team where all are equal then we could have the makings of the greatest scene ever :)

what differences has you code that quzar gave you actually made ian?

Clessy
May 12th, 2004, 01:17
Yeah saving would require a total re write but why put it off if you can do it now? I'm talking to Ian because Ian has much loyality and put DC devolopment ahead of alot of things in his life and I respect him much for that.

wraggster
May 12th, 2004, 01:21
well i would see what speed can be gained first, then collaborate with other coders for saving hints.

I respect all the coders, damn smart buggers :)

ron
May 12th, 2004, 01:24
Dear Friends, I'm alive and kicking. Sorry for my ausence these days but you must understand that I'm very very busy with my work and have not enough time during this two weeks. I'll be back very soon with news and comments about this six pages thread. Thank You very much for your opinioins, good or bad, the idea is still going on, but as I said in the beginning we'll start M68K developmet after MadriDC Party. Best Regards. Ron

wraggster
May 12th, 2004, 01:35
Yeah i was about to say how goes the DC Triple A project :)

Ian_micheal
May 12th, 2004, 03:17
Well I could make A legal smash pack type thing with info for 6 games and make the emulator run at 95%aproxx with sound on about that many games. Clessy if you want to help on it, Art work i can code the menus and you could help pick 6 games that runs the best since your Chart also helps me. I can hard code it to load the games at new underclock settings each.

If we pick games with password saving it will be much better. It's a thought and might be fun. *So i would make it load each game at it's best.

Speed is as good as dreamsnes with sound at the moment rendering is SDL and 640x480 now Very clear. Sound Works quiet will much better then sega gen. Cpu has the throu output hacked it breaks some games but has a speed up. Might even try the new mame core in it. looking at optimizing it more small things all throu it.

Clessy if you want the offer is open for that style of genesis emu. *

Lot of games run very well like this and if done right with game info and on cd art with each game selected from the menu no roms included of course you have to worry about that but no change from any other emu.

It would expect right named roms to be placed in a directory. Since it does not have a cd loader menu it cant interfer with a Black aura's port.

Clessy
May 12th, 2004, 03:26
I'll bang up some art in my digital arts class tomorrow then and i'll look into games that are fun to play without needing saving.

Sonic 1 is a must seeing how that ran without frame skip at playable speeds with that 183 underclock.

Probably thinking streets of rage 2 also. I will test out alot more games tomorrow and get you 8. I dont wanna use 9 because with 8 I think I can make a cooler menu :D.

Clessy
May 12th, 2004, 03:29
Also one other thing we could do is host or choose a auto renamer program off zophar so everyone would have the correctly named roms.

BlackAura
May 12th, 2004, 03:50
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
May 12th, 2004, 07:56
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
May 12th, 2004, 11:03
Cool, thanks.

Stef
May 24th, 2004, 09:52
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
May 24th, 2004, 13:29
testing DC version with aladdin (arg 1.2 MB to upload instead of 350 KB for each test)...


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
May 25th, 2004, 13:31
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?

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
May 25th, 2004, 22:09
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
May 26th, 2004, 00:44
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
May 26th, 2004, 02:06
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
May 26th, 2004, 02:23
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.

GPF
May 26th, 2004, 02:30
it was with 3.0.4 gcc that it was using too much memory to compile for -02 up, so I can now compile at home with 3.4.0

Troy

quzar
May 26th, 2004, 05:51
oh wow? i know that in 3.3.x it was broken cause i was reading through gcc mailing lists today and read a bunch of things about how most things couldnt compile cause it was broken.

GPF
May 26th, 2004, 06:01
Yeah I researched it alittle and I believe the issue that was being discussed was supposed to be fixed in 3.4.X, and I read that Dan Potter was using 3.3.3 with a special compiler flag.

I have not tried to recompile KOS though, so maybe that would be broken with 3.4.0, I don't know. maybe I'll get a chance to try it soon.

I only built the binutils and the C compiler, as I decided Its a rare event when I compile something for C++, so I haven't tried to build that part yet.

Troy

Stef
May 26th, 2004, 09:17
I don't know if previous versions of GCC (i.e < 3.0.4) has better support of SH-x CPU...
Unfortunatly SH-x cpu aren't used that much compared to ARM or x86 cpus... i tested GCC for GBA (ARM) and actually generated code looks *a lot* better than SH-x generated one :-/

I tested C68K with -O0, -O1, -O2, -O3, -Os
only -O0 and -Os work !
I guess a switch used since -O1 to -O3 break C68K... probably because of computed label stuff, it's true i never meet any problems except with C68K :(

The memory problem i got with GCC is due to the structure of C68K, even with -O0 GCC will eat about 500 MB of memory and take about 2 mn to compile the file on a XP-2400+ !

C68K is about 3 time faster than musashi when compiled on PC, i think we have the same difference on DC but i'll confirm that soon :)

Ian_micheal
May 26th, 2004, 17:53
Use 2.95 Like me faster uses less memory to compile very stable. I can show you what flags all the levels enable it's a tut on my site.

I could test the core Till i find what breaks it making my own level. I understande what each flag does i dont need to mass group the flags using a predefined level.

See when you release it I can prolly find a lot of speed by using the right combo.

Study compiler settings on GCC for 2 years now.

quzar
May 27th, 2004, 01:28
why not add flags from O0 to O1 manually until it breaks then leave out the flag(s) that break it?

Ian_micheal
May 27th, 2004, 02:21
Yes exactly Thats how you do it. If you go to my site you can find out how to see what every level enables.

http://imrtechnology.sourceforge.net/phpBB2/viewtopic.php?t=205 vist and see how to do this. My programing part to my forum is very usefull..

Stef
May 27th, 2004, 09:08
why not add flags from O0 to O1 manually until it breaks then leave out the flag(s) that break it?

Yeah of course, i should do it to find the flag which break my code, but it takes about 5 mn to compile, add to that 2-3 mn for upload ...
It'll take me time a long time to figure out what flags are wrong (but i really need to know so...)

Ian>
I'll try to upload the sources of C68K today (after my job i think), i'll also upload a small cpu interface file (to easily change from musashi) and mem68k.c from modified Genesis Plus to show how memories functions are defined with C68K.
About interrupt ack callback handler, just leave it to NULL in C68K_Init(...) to start with.

BlackAura
May 27th, 2004, 09:47
Would you mind if I have a look at it too?

quzar
May 27th, 2004, 10:17
<= Can compile quickly ;) ;) ;D

Stef
May 27th, 2004, 12:53
Would you mind if I have a look at it too?

Of course you can ;)
And everyone else can also, but remember that's a *very* unstable version ;)

Edit : you can download it at http://gens.consolemul.com/c68k_.zip
When you extract the archive you'll se a main directory upload which contains :
- c68k & cpu directories
- mem68k.c, mem68k.h and types.h files

c68k directory contain the C68K core itself and cpu directory contain CPU interface files.
mem68k.c & mem68k.h show how memory handler should be declared for C68K, types.h add some typos as FASTCALL, u32 definitions etc ...

C68K is both composed of generator and emulator. Generator is handled by Gen68k.c (and gen68k.inc), you can activate it in c68k.h by uncommenting C68K_GEN definition... in this case a 'main' function will be actived and generate C opcode files (c68k.ini, c68k_op0.inc ... c68k_opF.inc)
Once the core has been generated, you comment C68K_GEN to use the emulator itself (files has already been generated in the archive...)
I know the generator looks like a big mess right now, i plan to clean that later ^^

wraggster
May 27th, 2004, 18:33
THanks for your help to the Dreamcast scene stef :)

we may yet see a full speed Genesis emu ;)

Ian_micheal
May 27th, 2004, 19:51
cpu/cpu68k.c: In function `M68K_C68k_Int_Callback':
cpu/cpu68k.c:14: warning: passing arg 1 of `m68k_irq_ack_callback' makes integer
from pointer without a cast
cpu/cpu68k.c:14: void value not ignored as it ought to be
cpu/cpu68k.c: In function `M68K_m68k_Int_Callback':
cpu/cpu68k.c:22: warning: passing arg 1 of `m68k_irq_ack_callback' makes integer
from pointer without a cast
cpu/cpu68k.c: In function `M68K_Init':
cpu/cpu68k.c:59: warning: passing arg 2 of `C68k_Init' from incompatible pointer
type

I gave it a fast go got that first up Not quiet sure How i should compile it.

Stef
May 28th, 2004, 09:15
cpu/cpu68k.c: In function `M68K_C68k_Int_Callback':
cpu/cpu68k.c:14: warning: passing arg 1 of `m68k_irq_ack_callback' makes integer
from pointer without a cast
cpu/cpu68k.c:14: void value not ignored as it ought to be
cpu/cpu68k.c: In function `M68K_m68k_Int_Callback':
cpu/cpu68k.c:22: warning: passing arg 1 of `m68k_irq_ack_callback' makes integer
from pointer without a cast
cpu/cpu68k.c: In function `M68K_Init':
cpu/cpu68k.c:59: warning: passing arg 2 of `C68k_Init' from incompatible pointer
type

I gave it a fast go got that first up Not quiet sure How i should compile it.

That's the famous interrupt callback stuff.
Well, just comment the M68K_C68k_Int_Callback and M68K_m68k_Int_Callback functions.

and replace :
m68k_set_int_ack_callback(M68K_m68k_Int_Callback);
by
m68k_set_int_ack_callback(m68k_irq_ack_callback);

and

C68k_Init(&C68K, m68k_irq_ack_callback);
by
C68k_Init(&C68K, NULL);


Ah yeah, something else, don't even try to compile c68kexec.c file if you don't have at least 512 MB of RAM (768 MB recommended :-/) and use -Os optimisation level, others just don't work (you can of course use -O0 too but it won't be really fast then :D)

Stef
May 28th, 2004, 09:16
THanks for your help to the Dreamcast scene stef :)

we may yet see a full speed Genesis emu ;)

No have to thanks, i'm taking many fun with that :)
Having full speed Genesis emu is just my wish :)

Christuserloeser
May 28th, 2004, 09:25
we may yet see a full speed Genesis emu ;)

;D Great thing that would be indeed!

DemoniusX
May 28th, 2004, 11:05
the day that Full speed genesis emu comes to use, sleep will no longer be apart of my life, LOL

Christuserloeser
May 28th, 2004, 11:17
You just wrote what I thought :)

Ian_micheal
May 28th, 2004, 22:25
That's the famous interrupt callback stuff.
Well, just comment the M68K_C68k_Int_Callback and M68K_m68k_Int_Callback functions.

and replace :
m68k_set_int_ack_callback(M68K_m68k_Int_Callback);
by
m68k_set_int_ack_callback(m68k_irq_ack_callback);

and

C68k_Init(&C68K, m68k_irq_ack_callback);
by
C68k_Init(&C68K, NULL);


Ah yeah, something else, don't even try to compile c68kexec.c file if you don't have at least 512 MB of RAM (768 MB recommended :-/) and use -Os optimisation level, others just don't work (you can of course use -O0 too but it won't be really fast then :D)


c68kexec.c file found out the hard way about that. Ok thanks.

Ian_micheal
May 29th, 2004, 14:25
genesis.o: In function `gen_init':
genesis.o(.text+0x5c): undefined reference to `m68k_set_cpu_type'
genesis.o(.text+0x60): undefined reference to `m68k_get_reg'
genesis.o(.text+0x64): undefined reference to `m68k_pulse_reset'
genesis.o: In function `gen_reset':
genesis.o(.text+0xf8): undefined reference to `m68k_get_reg'
genesis.o(.text+0x114): undefined reference to `m68k_pulse_reset'
genesis.o: In function `gen_shutdown':
genesis.o(.text+0x21c): undefined reference to `m68k_get_reg'
vdp.o: In function `vdp_reg_w':
vdp.o(.text+0x7ac): undefined reference to `m68k_set_irq'
vdp.o: In function `vdp_hvc_r':
vdp.o(.text+0x9ac): undefined reference to `m68k_cycles_run'
system.o: In function `system_frame':
system.o(.text+0x3c4): undefined reference to `m68k_execute'
system.o(.text+0x3ec): undefined reference to `m68k_set_irq'
mem68k.o: In function `m68k_lockup_w_8':
mem68k.o(.text+0x88): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x98): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_w_16':
mem68k.o(.text+0xc8): undefined reference to `M68K_GetPC'
mem68k.o(.text+0xd8): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_r_8':
mem68k.o(.text+0x104): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x110): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_r_16':
mem68k.o(.text+0x140): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x14c): undefined reference to `M68K_EndExec'
cpu/cpu68k.o: In function `M68K_Disassemble':
cpu/cpu68k.o(.text+0x48): undefined reference to `m68k_disassemble'
collect2: ld returned 1 exit status

Got this now must be missing a file ive not included to compile or makefile is not correct.

DemoniusX
May 29th, 2004, 20:07
genesis.o: In function `gen_init':
genesis.o(.text+0x5c): undefined reference to `m68k_set_cpu_type'
genesis.o(.text+0x60): undefined reference to `m68k_get_reg'
genesis.o(.text+0x64): undefined reference to `m68k_pulse_reset'
genesis.o: In function `gen_reset':
genesis.o(.text+0xf8): undefined reference to `m68k_get_reg'
genesis.o(.text+0x114): undefined reference to `m68k_pulse_reset'
genesis.o: In function `gen_shutdown':
genesis.o(.text+0x21c): undefined reference to `m68k_get_reg'
vdp.o: In function `vdp_reg_w':
vdp.o(.text+0x7ac): undefined reference to `m68k_set_irq'
vdp.o: In function `vdp_hvc_r':
vdp.o(.text+0x9ac): undefined reference to `m68k_cycles_run'
system.o: In function `system_frame':
system.o(.text+0x3c4): undefined reference to `m68k_execute'
system.o(.text+0x3ec): undefined reference to `m68k_set_irq'
mem68k.o: In function `m68k_lockup_w_8':
mem68k.o(.text+0x88): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x98): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_w_16':
mem68k.o(.text+0xc8): undefined reference to `M68K_GetPC'
mem68k.o(.text+0xd8): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_r_8':
mem68k.o(.text+0x104): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x110): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_r_16':
mem68k.o(.text+0x140): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x14c): undefined reference to `M68K_EndExec'
cpu/cpu68k.o: In function `M68K_Disassemble':
cpu/cpu68k.o(.text+0x48): undefined reference to `m68k_disassemble'
collect2: ld returned 1 exit status

Got this now must be missing a file ive not included to compile or makefile is not correct.
??? ??? ??? when it comes to this stuff, I am duh!, coders are smarttastic.

Stef
May 30th, 2004, 00:55
genesis.o: In function `gen_init':
genesis.o(.text+0x5c): undefined reference to `m68k_set_cpu_type'
genesis.o(.text+0x60): undefined reference to `m68k_get_reg'
genesis.o(.text+0x64): undefined reference to `m68k_pulse_reset'
genesis.o: In function `gen_reset':
genesis.o(.text+0xf8): undefined reference to `m68k_get_reg'
genesis.o(.text+0x114): undefined reference to `m68k_pulse_reset'
genesis.o: In function `gen_shutdown':
genesis.o(.text+0x21c): undefined reference to `m68k_get_reg'
vdp.o: In function `vdp_reg_w':
vdp.o(.text+0x7ac): undefined reference to `m68k_set_irq'
vdp.o: In function `vdp_hvc_r':
vdp.o(.text+0x9ac): undefined reference to `m68k_cycles_run'
system.o: In function `system_frame':
system.o(.text+0x3c4): undefined reference to `m68k_execute'
system.o(.text+0x3ec): undefined reference to `m68k_set_irq'
mem68k.o: In function `m68k_lockup_w_8':
mem68k.o(.text+0x88): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x98): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_w_16':
mem68k.o(.text+0xc8): undefined reference to `M68K_GetPC'
mem68k.o(.text+0xd8): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_r_8':
mem68k.o(.text+0x104): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x110): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_r_16':
mem68k.o(.text+0x140): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x14c): undefined reference to `M68K_EndExec'
cpu/cpu68k.o: In function `M68K_Disassemble':
cpu/cpu68k.o(.text+0x48): undefined reference to `m68k_disassemble'
collect2: ld returned 1 exit status

Got this now must be missing a file ive not included to compile or makefile is not correct.

No this is normal, except maybe for genesis.o external not found...
First you have to change something in shared.h file :
replace
#include "m68k.h"
by
#include "cpu68k.h"

Since now you have the CPU interface, you have to use CPU interface functions (M68K_xxx) instead of the musashi specific ones (m68k_xxx)...

Do as in mem68k.c : m68k_releasetimeslice has been replaced by the M68K_EndExec function...you should do the same for all others m68k_xxx functions in Genesis Plus.

m68k_cycles_run --> M68K_GetOdo
m68k_execute *--> M68K_Exec
m68k_set_irq -> M68K_SetIRQ
....

Get a look in the cpu68k.c file to find the functions which replace old musashi function.

I hope you understand what i mean... cpu68k.c file has been done to easily switch between C68K and musashi, but for that, you'll need first to replace all specific musashi function by cpu68k ones :)

Edit : about m68k_disassemble, just comment it since it is not used in DC port of Genesis Plus, this method is from musashi disassembler and it is not included by default in Genesis Plus.

Sorry for all the matters, i should have clarify all that before uploading files.

quzar
May 30th, 2004, 02:41
Do you think it would be at all possible to write a small readme about the api differences between musashi and C68K?

Stef
May 30th, 2004, 14:39
I just uploaded complete DevCPP project of DC genesis Plus and PC Genesis Plus including C68K.

You can download them at :
http://gens.consolemul.com/download/GenPlus_DC.zip
http://gens.consolemul.com/download/GenPlus_PC.zip

they both include C68K, but if you want to downoad C68K alone go here :
http://gens.consolemul.com/download/c68k.zip




Do you think it would be at all possible to write a small readme about the api differences between musashi and C68K?

I'll do it when i'll have modified the way i'm handling IRQ... i think i'll also modify memory handler to make them as musashi.
Then, except function name and init, musashi and C68K will be really similar in use.

Ian_micheal
May 30th, 2004, 15:12
genesis.o: In function `gen_init':
genesis.o(.text+0x50): undefined reference to `M68K_Init'
genesis.o(.text+0x54): undefined reference to `M68K_GetPC'
genesis.o(.text+0x58): undefined reference to `M68K_GetSP'
genesis.o: In function `gen_reset':
genesis.o(.text+0x100): undefined reference to `M68K_Reset'
genesis.o(.text+0x104): undefined reference to `M68K_GetPC'
genesis.o(.text+0x108): undefined reference to `M68K_GetSP'
genesis.o: In function `gen_shutdown':
genesis.o(.text+0x208): undefined reference to `M68K_GetPC'
genesis.o(.text+0x20c): undefined reference to `M68K_GetSP'
genesis.o(.text+0x210): undefined reference to `M68K_GetSR'
genesis.o(.text+0x218): undefined reference to `M68K_GetDReg'
genesis.o(.text+0x21c): undefined reference to `M68K_GetAReg'
vdp.o: In function `vdp_reg_w':
vdp.o(.text+0x7ac): undefined reference to `M68K_SetIRQ'
vdp.o: In function `vdp_hvc_r':
vdp.o(.text+0x9ac): undefined reference to `M68K_GetOdo'
system.o: In function `system_frame':
system.o(.text+0x3cc): undefined reference to `M68K_Exec'
system.o(.text+0x3f4): undefined reference to `M68K_SetIRQ'
mem68k.o: In function `m68k_lockup_w_8':
mem68k.o(.text+0x88): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x98): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_w_16':
mem68k.o(.text+0xc8): undefined reference to `M68K_GetPC'
mem68k.o(.text+0xd8): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_r_8':
mem68k.o(.text+0x104): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x114): undefined reference to `M68K_EndExec'
mem68k.o: In function `m68k_lockup_r_16':
mem68k.o(.text+0x140): undefined reference to `M68K_GetPC'
mem68k.o(.text+0x150): undefined reference to `M68K_EndExec'
cpu/cpu68k.o: In function `M68K_Disassemble':
cpu/cpu68k.o(.text+0x7c): undefined reference to `m68k_disassemble'
collect2: ld returned 1 exit status
make: *** [dreamcast/genplus.elf] Error 1
BASH-2.05b$

I got this trying to compile the DC version from your link.

Stef
May 30th, 2004, 15:32
Strange, it seems like your shared.h file isn't updated.
I just downloaded archive, extracted it in a new directory, and except the include directories which aren't relative, all compiled normally :)

I reuploaded the project with fixed includes directories ...

JMD
May 30th, 2004, 16:22
Just tried to compile and compile fine for me, without any warning/error (I'm not used to have a so nice compile log lol:).

16Bits
May 30th, 2004, 17:31
well, I'm currently working on a sh4 asm motorola 6502 cpu emulator, although it's going slowly since I just recently built me a serial cable and got the toolchain up and running (gcc3.04). anyway, my main gripe just now is getting the hang of the sh4 cpu and the general dreamcast hardware. I've never programmed assembly on a risc cpu before and it differs somewhat from my previous experiences (6502, z80, 65816, 68000, x86) and takes some getting used to. my main gripe with the dc sofar is the lack of an l2 cache, as a 16kb data l1 cache means you'll likely trash the lines constantly unless you use carefully prepared data (which is a luxury we don't have in emulation). however, that the dc seems uncapable to emulate a snes in fullspeed wasn't a surprise, since the snes is a VERY hard machine to emulate, more difficult than say Sega genesis/megadrive. one of the things I remember from programming the snes that I imagine is hard to emulate fast is the cpu's rep/sep instructions that allows it to switch from 8/16bit accumulator register sizes (quick note, someone in this thread stated 6502 as the snes cpu, it is in fact 65816), this means that the emulator must constantly check wheter it is in 8 or 16bit accumulator state before decoding each instruction, not to mention it's graphics hardware (unless I remember this incorrectly, it was a looong time since I programmed the snes)

anyway, I read that the dreamsnes team will release the dc specific parts of the snes9x source and I am really looking forward to examining their sh4 65816 code.

enough of that though, the reason I opted for a 6502 emulator was because it's a cpu that I know very well and since I am to learn sh4 assembly while programming it, it definately helps if I don't have to spend time remembering how the cpu i'm emulating works. that said, when the 6502 emulator is done, I'm planning on making a z80 and a 68000 (yes, here is the reason I posted), however, wheter or not that will happen depends on just how much extra speed can be gained from programming the sh4 in pure asm as opposed to letting the compiler do the job. risc cpu's are generally the compilers dream, since it has plenty of registers, and the instruction set is very basic. so I'm wondering if there have been any benchmarks/efficiency tests done previously comparing sh4 optimized asm towards compiler generated code?
(this would save me alot of gas output examination ;) )

quzar
May 30th, 2004, 21:32
there has been but only hand done bigO examination caparing the instructions one gives compared to the other and figuring theoretical results. in practical uses though the sh4 snes core was around 10-15% faster(?) than its C equivilant. OT: Welcome to the forums and the scene ;D

Christuserloeser
May 30th, 2004, 22:54
Yeah, 10-15% faster with 65c816 CPU ported to SH4, there's a open source core out for the 6502 in SH2 too:

quoting myself ::)


As Ian Micheal posted here (http://www.dcemu.co.uk/cgi-bin/yabb/YaBB.pl?board=dcemu;action=display;num=1083323639; start=45) that Gleam (http://www.dcemulation.com/dcemu-gleam.htm) used a 6502 SH2 ASM cpu core for NES emulation. The source is available. Maybe that'll help to get a NesterDC speed up too ?

I am not sure how fast this core is. Maybe the optimized NesterDC C core is faster than this old SH2 ASM core?

Don't know if that emu (Gleam) runs at a reasonable speed but one should not only judge by its end result anyway, as the core could be fast even if the emulation speed wasn't fast at all.

The NES uses an older version of this 65c816 CPU too, don't know if it's interesting at all cause they might differ on some key issues.

I wonder because I thought Nintendo had the idea of an downward NES compatible SuperNES so they modified the NES core for the SNES a bit but it is almost the same CPU as far as I know.

So it could be possible/usefull to implement the SH4 65c816 CPU core to NesterDC...!?


So one could take either the SH2 Gleam CPU or the DreamSNES SH4 CPU for a NesterDC update as I could imagine. Any comments?

PS: 16Bits, I'd like to welcome you to the DC scene and the DCEmu forums too :)

Alexvrb
May 31st, 2004, 00:24
there has been but only hand done bigO examination caparing the instructions one gives compared to the other and figuring theoretical results. in practical uses though the sh4 snes core was around 10-15% faster(?) than its C equivilant. OT: Welcome to the forums and the scene *;D

I thought that DreamSNES as a whole was %10-15 faster. That would indicate that the CPU core by itself was significantly faster than the old C core, because just comparing DreamSNES before and after doesn't take into account the video or sound emulation (which were still sucking up lots of cycles).

Basically, SH is not a primary target for GCC, so GCC produces shoddy code for the SH series. Also, 3.0.4 works, but all the versions after that until 3.4.0 produced broken code. So they just fixed it again recently. Speaking of which, has anyone tried compiling C68k with 3.4.0? I am curious to see whether -O1 or above still breaks it (I know its not quite done anyway, but it'd be interesting to see).

Ian_micheal
May 31st, 2004, 00:53
Was not much faster then c core at all. Hardly changed.

Christuserloeser
May 31st, 2004, 01:15
compare sfc v01 + sound to sfc v02 + sound. it is faster.

Ian_micheal
May 31st, 2004, 01:28
Hmm to you maybe. Every so slightly to me.

Christuserloeser
May 31st, 2004, 01:42
:'( Yeah, very slightly that is...

Too bad, better then nothin' bu video & sound is the real problem with SNES emulation 4 DC other then with the Genesis/MegaDrive. Its M68K is a really powerful beast.

quzar
May 31st, 2004, 05:42
its weird i use 3.3.1 cygwin special edition of gcc and my code is usually not broken. (i think there was one thing that was broken) can anyone help teach me how to update gcc? i have no clue at all lol.

Ian_micheal
May 31st, 2004, 05:57
well, I'm currently working on a sh4 asm motorola 6502 cpu emulator, although it's going slowly since I just recently built me a serial cable and got the toolchain up and running (gcc3.04). anyway, my main gripe just now is getting the hang of the sh4 cpu and the general dreamcast hardware. *I've never programmed assembly on a risc cpu before and it differs somewhat from my previous experiences (6502, z80, 65816, 68000, x86) and takes some getting used to. my main gripe with the dc sofar is the lack of an l2 cache, as a 16kb data l1 cache means you'll likely trash the lines constantly unless you use carefully prepared data (which is a luxury we don't have in emulation). however, that the dc seems uncapable to emulate a snes in fullspeed wasn't a surprise, since the snes is a VERY hard machine to emulate, more difficult than say Sega genesis/megadrive. one of the things I remember from programming the snes that I imagine is hard to emulate fast is the cpu's rep/sep instructions that allows it to switch from 8/16bit accumulator register sizes (quick note, someone in this thread stated 6502 as the snes cpu, it is in fact 65816), this means that the emulator must constantly check wheter it is in 8 or 16bit accumulator state before decoding each instruction, not to mention it's graphics hardware (unless I remember this incorrectly, it was a looong time since I programmed the snes)

anyway, I read that the dreamsnes team will release the dc specific parts of the snes9x source and I am really looking forward to examining their sh4 65816 code.

enough of that though, the reason I opted for a 6502 emulator was because it's a cpu that I know very well and since I am to learn sh4 assembly while programming it, it definately helps if I don't have to spend time remembering how the cpu i'm emulating works. that said, when the 6502 emulator is done, I'm planning on making a z80 and a 68000 (yes, here is the reason I posted), however, wheter or not that will happen depends on just how much extra speed can be gained from programming the sh4 in pure asm as opposed to letting the compiler do the job. risc cpu's are generally the compilers dream, since it has plenty of registers, and the instruction set is very basic. so I'm wondering if there have been any benchmarks/efficiency tests done previously comparing sh4 optimized asm towards compiler generated code?
(this would save me alot of gas output examination ;) )

Best news ive herd all do i which you luck and no ive not seen any reports other then the offical docs that say sh4 asm is up to x3 faster then c on the dreamcast. Avoiding pipeline stalls and cache misses is a major problem.

obelisk
May 31st, 2004, 22:16
Awesome! I'm not a coder, or programmer, but I'm really happy all you guys are kickin' butt on this stuff. Hey, I have a quick question, please pardon the lack of knowledge... will / could this 68k stuff help out TG16 emulation on the DreamCast? Keep up the good work on all this kewl stuff!!!

quzar
May 31st, 2004, 22:27
68k is named because it is the name of a processor. the Motorola 68000. this may aide the emulation of any hardware that used that processor.

Stef
May 31st, 2004, 22:29
well, I'm currently working on a sh4 asm motorola 6502 cpu emulator, although it's going slowly since I just recently built me a serial cable and got the toolchain up and running (gcc3.04). anyway, my main gripe just now is getting the hang of the sh4 cpu and the general dreamcast hardware. *I've never programmed assembly on a risc cpu before and it differs somewhat from my previous experiences (6502, z80, 65816, 68000, x86) and takes some getting used to. my main gripe with the dc sofar is the lack of an l2 cache, as a 16kb data l1 cache means you'll likely trash the lines constantly unless you use carefully prepared data (which is a luxury we don't have in emulation). however, that the dc seems uncapable to emulate a snes in fullspeed wasn't a surprise, since the snes is a VERY hard machine to emulate, more difficult than say Sega genesis/megadrive. one of the things I remember from programming the snes that I imagine is hard to emulate fast is the cpu's rep/sep instructions that allows it to switch from 8/16bit accumulator register sizes (quick note, someone in this thread stated 6502 as the snes cpu, it is in fact 65816), this means that the emulator must constantly check wheter it is in 8 or 16bit accumulator state before decoding each instruction, not to mention it's graphics hardware (unless I remember this incorrectly, it was a looong time since I programmed the snes)

anyway, I read that the dreamsnes team will release the dc specific parts of the snes9x source and I am really looking forward to examining their sh4 65816 code.

enough of that though, the reason I opted for a 6502 emulator was because it's a cpu that I know very well and since I am to learn sh4 assembly while programming it, it definately helps if I don't have to spend time remembering how the cpu i'm emulating works. that said, when the 6502 emulator is done, I'm planning on making a z80 and a 68000 (yes, here is the reason I posted), however, wheter or not that will happen depends on just how much extra speed can be gained from programming the sh4 in pure asm as opposed to letting the compiler do the job. risc cpu's are generally the compilers dream, since it has plenty of registers, and the instruction set is very basic. so I'm wondering if there have been any benchmarks/efficiency tests done previously comparing sh4 optimized asm towards compiler generated code?
(this would save me alot of gas output examination ;) )

Hello 16bits, i'm sure we already had some talks together or maybe i'm confusing with someone else...

It's true than RISC assembly is somewhat different from CISC one and specially x86, it appears far more limited !
But i had fun with ARM assembly, i know *a bit* about SH-X assembly (from what i learnt by making my SH-2 emulator)... but i expect to have fun too :)

You said SNES is complex, i agree, but not about the 65816 CPU which is (imo) simpler than 68000 cpu, the 8/16 bits trick of 65816 isn't a big problem really...
sound is complex, video is complex, but SNES cpu is easy :)


Then about SH-4 assembly versus C generated code.
First GCC isn't really a master about SH-X code optimisation, it does some weird stuff sometime and code is far from being optimal.
Second, when you're emulating a CPU, asm always help a lot compared to C, because you have access to some low level instruction as ROR / ROL which need several instruction in C.
So, even with the best C code, i think you can at least do 3 time faster in ASM.

C68K is definitly not the ultimate 68k emulator for the DC, we can do really better in ASM, but, that's really needed ? if C68K is already capable of emulating a 68000 running at 80/100 Mhz on the DC, then an ASM 68000 emulator isn't really a must.

quzar
May 31st, 2004, 22:43
yes, i dont understand why there has been a major flock recently towards sh-4 asm as being a holy grail that will magically make everything work. yes it will speed things up, is it worth it compared to fixing the real bottlenecks first. probably not.

wraggster
May 31st, 2004, 22:51
Stef, with the core you have now, would a faster genesis emu bemade with it as it stands?

Christuserloeser
May 31st, 2004, 23:26
will / could this 68k stuff help out TG16 emulation on the DreamCast?

Not at all.
PCEngine uses a NES/SNES similar CPU type, knowledge about SHx and the DreamSNES CPU core code could help porting an C emu to DC with a SHx PCE CPU core.

Until then DreamEngine is the best choice for playin PCE games on DC

http://www.gamer.uk.com/gamefaqs/tg16+duo.faq

Specs (http://www.iespana.es/emulair/specs/turbografx.html)
Manufacturer NEC
Year 1988
CPU HuC6280 - 7.19509 Mhz
RAM 64 Kbytes
Sound 6 cn.
Video 360 x 256 (H)
Colores/Colours 512
Sprites 64
Card (8 Mbits)

Christuserloeser
May 31st, 2004, 23:39
yes, i dont understand why there has been a major flock recently towards sh-4 asm as being a holy grail that will magically make everything work. yes it will speed things up, is it worth it compared to fixing the real bottlenecks first. probably not.
Hm. If someone's able to program in SHx most speed issues with DC will be fixed. The current situation is stucked. There isn't any room for improvements atm. Read blackaura's interview (http://www.dcemu.co.uk/blackaura.shtml) here at DCEmu.co.uk - he says it. Nothing to do, everything done, no big improvements... Not his wording though ;) but reflects the scene very good.

As I can't code at all I cannot say very much about facts, so everything's just *theoretical*:

Using SHx it should be possible to get the following systems emulated using the DC with 44khz sound, bilinear filtering, full speed:

SNES
Genesis (with the new C68K that will be possible without SHx)
Genesis + SegaCD
NeoGeo(CD)
GBA
PSX (hi res)
N64 (lo res)
Saturn (using SH2 directly for the main CPUs, SHx for the VDPs and other units)
Amiga 500 (I know some don't agree with that :P)


Chris

quzar
May 31st, 2004, 23:46
it is possible to do that with good C coding, not with spiffy effects but fullspeed emulation yes. just requires better code =\

Christuserloeser
June 1st, 2004, 00:21
Now that would be a lot of code optimizing ;D
And afterwards someone comes up with some good SHx ASM code and it's three times faster ;)

But I guess til someone coded a SHx ASM core for the M68K it will take a year :P

I guess that won't be possible without Stef's help anyway! We'll see a serious speed up for NeoCD and GenesisPlusDC if Stef's C68K is implemented!

vipor231
June 1st, 2004, 00:40
im wondering if it would be possible to emulate a sega saturn on the dreamcast.that would be nice playing those games and not having to pull the saturn out all the time :)

Christuserloeser
June 1st, 2004, 00:43
Would be nice! But I guess that won't happen til 2006 ;D

Ian_micheal
June 1st, 2004, 04:20
Well when i compiles your source code you released i get bascly the same undefines as before.


Im thinking 1 it works for you. 2 im using my make not yours as i use cygwin.

I dont know whats up i understand most of how it works it just will not compile for me

Stef
June 1st, 2004, 10:20
yes, i dont understand why there has been a major flock recently towards sh-4 asm as being a holy grail that will magically make everything work. yes it will speed things up, is it worth it compared to fixing the real bottlenecks first. probably not.


I agree, we should first focus on bottlenecks.
Now we will be able to switch to C68K on Genesis Plus, frame skip should be a lot more efficient... if it's the case, that mean VDP render code is still really slow and need to be optimised.



Stef, with the core you have now, would a faster genesis emu bemade with it as it stands?


Yes and no, without frame skip, speed improvement isn't impressive because video code is still really slow... i didn't tested with frame skip, but i think games can now run near full speed with frame skip 1 or 2 with correct 68000 speed (understand by that, no underclocking)



But I guess til someone coded a SHx ASM core for the M68K it will take a year *


Depend about how many free time we have, it taken me many time for C68K (about 6 months) because i'm really busy with my job...



I guess that won't be possible without Stef's help anyway! We'll see a serious speed up for NeoCD and GenesisPlusDC if Stef's C68K is implemented!


Actually C68K won't be sufficient alone in Genesis Plus DC, we also need to speed up video render part.

I never tested NeoCD since i don't have NeoGeo CD games :-/ but i follow with many interest development of NeoCD, speed is almost improved in each version, i guess C68K can bring a big speed improvement since 68000 is clocked at 12 Mhz on NeoGeo...
I should have a look in the source to see if we can easily implement C68K as i done in Genesis Plus



im wondering if it would be possible to emulate a sega saturn on the dreamcast


No, i don't think it would be ever possible... Saturn is far more complex than a PSX, many CPU are working together, VDPs are very complex, specially VDP2 which have strong 2D capabilities ! It's definitly impossible to get a correct Saturn emulator on DC...



Well when i compiles your *source code you released i get bascly the same undefines as before.


Im thinking 1 it works for you. 2 im using my make not yours as i use cygwin.

I dont know whats up i understand most of how it works it just will not compile for me


Can you give me your error log ?
If it's the same than last time (i.e: M68K_xxx undefined ...), it means your cpu68k.c file isn't linked correctly in your makefile...
and you can comment m68k_disassemble call, not needed in the DC version ;)

16Bits
June 1st, 2004, 17:45
Stef wrote

Hello 16bits, i'm sure we already had some talks together or maybe i'm confusing with someone else...
hi there, hmm I haven't posted anything on dc related forums before, since I just recently got hold of a dreamcast (with mouse and keyboard) courtesy of my brother!


It's true than RISC assembly is somewhat different from CISC one and specially x86, it appears far more limited !
yes and no, it generally takes alot more instructions in risc to do the same thing as in a cisc, that said, it does have alot of clever instructions such as the indirect addressing with post increment, however, in most cases it just requires alot of extra typing, such as the shift instructions that only handles 1, 2, 8 or 16 bit shifts.


You said SNES is complex, i agree, but not about the 65816 CPU which is (imo) simpler than 68000 cpu, the 8/16 bits trick of 65816 isn't a big problem really...
well, actually I didn't say it's complex, only that it's hard to make fast, which I base on the fact that it has to check the accumulator/x,y registers for 8 or 16bit which slows the emulation down. in 16 bit mode the following would be decoded:
a9 00 00 lda #$0000
8d 00 10 sta $1000

in 8bit mode it would be:
a9 00 lda #$00
00 brk
8d 00 10 sta $1000

however, you are right that the video/sound hardware is the big problem of snes emulation


Second, when you're emulating a CPU, asm always help a lot compared to C, because you have access to some low level instruction as ROR / ROL which need several instruction in C.
So, even with the best C code, i think you can at least do 3 time faster in ASM.
well, usually one of the benefits of programming in assembly is that you can designate registers for specific purposes and thus avoid pushing and poping parameters from stack between calls, which helps speed things up alot in tight loops with calls (such as cpu emulators with it's fetch->decode where the instruction opcode value is usually used as an index into a list of function pointers corresponding to the decoding of that instruction), if I could get it 3 times faster in asm than in gcc -O2 then it would definately be worth the work of programming in sh4 asm. I guess the only way to make sure is to compare c code gas output towards my own assembly and see how much better I can make my code. too bad the weather is so great here in sweden now, that I'm spending far too much time on tennis and soccer, barbeque's and beer instead of programming... hmm.. maybe we'll get some rain soon...

btw, how far is the neogeo cd from full speed?

one of the drawbacks of a general system emulation (such as consoles) versus single game emulation (such as arcade games) is that in for example arcade emulation you map out all the graphics/sound banks and can then modify that data in accordance to your needs before the actual emulation starts, whereas in a general emulation system you don't know where the graphics and sound will reside and thus must do all conversion on the fly. one idea I had for my 6502 emulator was to use it to emulate the cpu of the c64, but instead of emulating the c64's graphics hardware strictly, I was thinking of applying a high level emulation of it, allowing to enhance the graphics and sound by simply mapping the video memory, sprite and sound registers to my own handlers that would examine the contents of the memory/registers and update with my own graphics and sound. naturally, this mapping would have to be done on a game per game basis, and would likely take a bit of effort, but the result would be a game with the exact "feel" of the original c64 game, but with enhanced graphics and sound, ahh, it would be sweet!

well, enough babbling from me! I like this place though, nice people who likes to share information and allows people to throw out ideas without getting trashed! and also the dc scene seems to have alot of people looking to push the dreamcast's boundaries, which is I feel it's greatest aspect, as this is to me the greatest charm with a standarised hardware platform.

Christuserloeser
June 1st, 2004, 20:46
btw, how far is the neogeo cd from full speed?

@Stef & 16Bits: Give it a try! It runs with backups as far as I know (not tested). I've tested it with my Pulstar and it runs at a very playable speed and with full CDDA support! It is faster than DreamSNES in every way, a good reason to buy all the great NeoGeoCD games out there! Fantastic work by Ian Micheal, Fosters and the team that is!

quzar
June 1st, 2004, 21:44
right now it is being run underclocked by quite a bit ( double cycles ) as well as frameskip that i have come to realize is automatic maxed at 4 (or something close to that).

wraggster
June 1st, 2004, 22:03
Quick question, is PC Engine cd emulation a reachable target for emulation?

quzar
June 1st, 2004, 22:11
yes.

wraggster
June 1st, 2004, 22:13
and ahem hows the Neopocket emu going :)

quzar
June 1st, 2004, 22:18
:-[ thats all i have to say. well maybe this. i will get it working. i had one month struggling trying to get it to load roms. methods working on every other test would not respond in it, in this time i hacked up soo much of the code that when i got rom loading working, the emulation was broken. so yes. reset for me :P

Christuserloeser
June 1st, 2004, 23:17
Oh, I'd love to play that Cotton game... :)

I wish you success ;D

quzar
June 2nd, 2004, 03:28
;D

Stef
June 2nd, 2004, 09:26
hi there, hmm I haven't posted anything on dc related forums before, since I just recently got hold of a dreamcast (with mouse and keyboard) courtesy of my brother!

Not here, actually it's because of your nick... i'm the author of Gens and i though you were from "16bits" site ;)



yes and no, it generally takes alot more instructions in risc to do the same thing as in a cisc, that said, it does have alot of clever instructions such as the indirect addressing with post increment, however, in most cases it just requires alot of extra typing, such as the shift instructions that only handles 1, 2, *8 or 16 bit shifts.


Yeah, but the most irritating for me is loading immediate data in register ;) of course (and hopefully), we can do the same as CISC cpu except it takes almost time more instructions.



well, actually I didn't say it's complex, only that it's hard to make fast, which I base on the fact that it has to check the accumulator/x,y registers for 8 or 16bit which slows the emulation down. in 16 bit mode the following would be decoded:
a9 00 00 * * lda #$0000
8d 00 10 * * sta $1000

in 8bit mode it would be:
a9 00 * * * * *lda #$00
00 * * * * * * * * * * * *brk
8d 00 10 sta $1000


Here's a way to handle that without any significant speed loss :
i guess base opcode are 8 bits length on 65816 CPU... so we can use a 256 jump table as dispatch method.
If EBX register (x86 cpu) contains opcode in low 8 bits (jmp dword [JumpTable + ebx * 4] for dispatch), we can use bit 9 to store the current operating mode :
0 = 8 bits and 1 = 16 bits...

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.



well, usually one of the benefits of programming in assembly is that you can designate registers for specific purposes and thus avoid pushing and poping parameters from stack between calls, which helps speed things up alot in tight loops with calls (such as cpu emulators with it's fetch->decode where the instruction opcode value is usually used as an index into a list of function pointers corresponding to the decoding of that instruction), if I could get it 3 times faster in asm than in gcc -O2 then it would definately be worth the work of programming in sh4 asm. I guess the only way to make sure is to compare c code gas output towards my own assembly and see how much better I can make my code. too bad the weather is so great here in sweden now, that I'm spending far too much time on tennis and soccer, barbeque's and beer instead of programming... hmm.. maybe we'll get some rain soon...


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.




@Stef & 16Bits: Give it a try! It runs with backups as far as I know (not tested). I've tested it with my Pulstar and it runs at a very playable speed and with full CDDA support! It is faster than DreamSNES in every way, a good reason to buy all the great NeoGeoCD games out there! Fantastic work by Ian Micheal, Fosters and the team that is!


Is the bios working ? is it sufficient to test emulator speed ? i'll probably give a try anyway...

quzar
June 2nd, 2004, 12:06
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

16Bits
June 2nd, 2004, 14:54
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?

Ian_micheal
June 2nd, 2004, 15:40
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

Christuserloeser
June 4th, 2004, 13:28
Any way good luck im not going to be on forums much any more i find it distracting and un help full to me

....?


Guess, we'll have to respect that.


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

GPF
June 5th, 2004, 14:35
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

GPF
June 6th, 2004, 03:32
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

Stef
June 7th, 2004, 09:17
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

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...

GPF
June 7th, 2004, 15:36
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;


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

Stef
June 7th, 2004, 15:59
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

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 :p

GPF
June 7th, 2004, 16:43
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 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

Alexvrb
June 7th, 2004, 20:49
Sweet, excellent work Troy. Looks like GCC 3.4.0 isn't as likely to break code. If you can compile ym2612.c with any optimizations at all, and the rest with -O2 or even -O3, I think speed would improve quite a bit with frameskip.

GPF
June 8th, 2004, 11:15
I made a mistake when I compiled the ym2612.c file, I forgot a space so was ignoring the optimization parameter. I was only able to do up to -O1 for it.

for c68kexec.c file I was only able to do up to -O2, I believe I could do -O3 but I don't have enough memory -384 MB.

Everything else was at -O3.

The musashi speed was between 19-21 FPS while the c68k was around 26-28 fps.

Troy

Christuserloeser
June 8th, 2004, 12:01
The musashi speed was between 19-21 FPS while the c68k was around 26-28 fps.

:o That's just great! I can't wait to see a release of GenesisPlusDCv02 *;D


I'd like to thank you all for your outstanding work for the DC scene :)


Chris

Stef
June 8th, 2004, 14:26
Thanks for your report :)
I'll post my report with GCC 3.0.4 soon, then we will be able to compare generated code versus GCC 3.4.0 :)

I'll use Sonic 1 as test rom, FPS will be taken from in-game where you start level 1, without touching controller.


I made a mistake when I compiled the ym2612.c file, I forgot a space so was ignoring the optimization parameter. I was only able to do up to -O1 for it.


Strange, this file compile fine with -O2 and-O3 with GCC 3.0.4 ... weird it looks like all my sources files act strangely with GCC.



for c68kexec.c file I was only able to do up to -O2, I believe I could do -O3 but I don't have enough memory -384 MB.

Everything else was at -O3.

The musashi speed was between 19-21 FPS while the c68k was around 26-28 fps.

Troy


19-21 FPS versus 26-28 FPS ?
so much ? without frame skip ?
maybe -O2 perform really better than -Os for C68K.
Actually even musashi work better with -O2 with GCC 3.0.4 than -O3...

You should also try to compile with -Os flag for all, it almost time give best results :)

BlackAura
June 8th, 2004, 15:50
Stef - I have a thread over on the other DCEmu about possibly using the Dreamcast's PowerVR hardware to do accelerated rendering. Since you know more about the Genesis VDP than anyone here, any ideas would be appreciated.

At the moment, I'm not going to attempt to implement every little quirk of the VDP, nor all possible mode. Just enough to start displaying some graphics on screen, to see if it's worth trying to do a full hardware-based VDP emulator.

Stef
June 8th, 2004, 16:19
Stef - I have a thread over on the other DCEmu about possibly using the Dreamcast's PowerVR hardware to do accelerated rendering. Since you know more about the Genesis VDP than anyone here, any ideas would be appreciated.

At the moment, I'm not going to attempt to implement every little quirk of the VDP, nor all possible mode. Just enough to start displaying some graphics on screen, to see if it's worth trying to do a full hardware-based VDP emulator.

Yeah i know ;)
But i'm currently at my job and i prefer to take my time to reply to your topic, there is many points to see and talk about :p
I'll reply right after i'm back to home :)

GPF
June 8th, 2004, 16:28
I'll use Sonic 1 as test rom, FPS will be taken from in-game where you start level 1, without touching controller.

If I do that the FPS is 30 - 31 for c68k. Unfortunetly I didn't save the m68k elf file, I have to rebuild it tonight to test it for that test case.



19-21 FPS versus 26-28 FPS ?
so much ? without frame skip ?
maybe -O2 perform really better than -Os for C68K.
Actually even musashi work better with -O2 with GCC 3.0.4 than -O3....

How do I turn on frame skip?



You should also try to compile with -Os flag for all, it almost time give best results :)

I give that a try to tonight.

I can compile it at work, and post it up somewhere if someone wants to test it with a coders cable, so you can report the FPS back here today.

Troy

BlackAura
June 8th, 2004, 16:53
GPF - What compiler are you using - GCC 3.0.x or something else? I have 512MB of RAM on my main machine, so I could try compiling it.

That seems like an unbelievable difference in speed. If the version of GP/DC that Stef's working on has the same settings that it did last time I saw it, the frameskip is hard-coded to 1. If the frameskip were 0, I'd expect both the FPS numbers to be the same.

Stef - Take your time - there's no rush. I've been reading up on the VDP and the SH-4 (along with a bit about the PVR, but I'm not too worried about that yet), trying to work out how to actually try to do it anway. I'm getting the impression that it's going to be quite tricky to get right, but the same is true of a software-based VDP emulator. Last time I tried that, I got about as far as emulating the VDP<->68K interface and (badly) displaying some sprites.

Oh, and I managed to get the GUI code working again. I'm just not sure if it's worth keeping. I can think of a much better way to do it now, especially having seen SMS Plus and Super Famicast.

Alexvrb
June 8th, 2004, 19:43
GPF - What compiler are you using - GCC 3.0.x or something else? I have 512MB of RAM on my main machine, so I could try compiling it.He's using GCC 3.4.0, which seems to let him compile at different optimization levels vs people using 3.0.4. Of course, RAM limitations can always make compiling stuff a PITA.

Troy, what kind of RAM do you use? I think I've got a 256MB stick of SDRAM around here, but its either PC100 or PC133.

Oh, and I managed to get the GUI code working again. I'm just not sure if it's worth keeping. I can think of a much better way to do it now, especially having seen SMS Plus and Super Famicast.Keep it until you have a replacement, no point in stripping it out before the next release if there's nothing else. I'd rather you guys worked on more important things, which you are, which rocks.

GPF
June 8th, 2004, 22:28
He's using GCC 3.4.0, which seems to let him compile at different optimization levels vs people using 3.0.4. Of course, RAM limitations can always make compiling stuff a PITA.

Thats the truth :).
I have the complete 3.4.0 toolchain in a rar thats about 10 megs for both gcc and g++, for mingw. but my storm-studios site seems to be down right now.



Troy, what kind of RAM do you use? I think I've got a 256MB stick of SDRAM around here, but its either PC100 or PC133.

I use pc133, on my athlon 700 .

Thanks,
Troy

GPF
June 8th, 2004, 23:22
quick update I was able to compile the c68kexec.c file with -O3 since the machine here at work has 512mb(lot faster too)

also here is the error I get if I try to compile ym2612.c with an optimzation greater than -O1



make.exe -f "c:\Dev-Cpp\Examples\Dreamcast\Genesis Plus DC\Makefile.win" out/ym2612.o
sh-elf-gcc.exe -fno-builtin -fno-strict-aliasing -fomit-frame-pointer -fno-optimize-sibling-calls -fno-exceptions -O3 -ml -m4-single-only -D_arch_dreamcast -D_GENS_SOUND_ -c source/sound/ym2612.c -o out/ym2612.o -I"c:/Dev-Cpp/dcinclude" -I"include" -I"include/sound" -I"include/cpu" -I"include/m68k" -I"include/dreamcast" -I"include/c68k" -I"source/c68k"

c:\DOCUME~1\DAVIST~1.ACC\LOCALS~1\Temp/ccm8baaa.s: Assembler messages:
c:\DOCUME~1\DAVIST~1.ACC\LOCALS~1\Temp/ccm8baaa.s:7529: Error: pcrel too far
c:\DOCUME~1\DAVIST~1.ACC\LOCALS~1\Temp/ccm8baaa.s:8764: Error: pcrel too far

make.exe: *** [out/ym2612.o] Error 1

I just can't test it at work :( , I tried chanka but I only have the built in intel onboard video, so I am guessing that why it crashes after I press init.

Troy

guymelef
June 9th, 2004, 07:13
chanka only seems to wanna work with xp or at lest anybody that i talk to on the board with 2000pro like me just can't get it to recoginize a disk no matter what.
I really wish I could use chanka instead of coastering cd that was supposed to work all because I had files wrong before I started the selfboot process.

guymelef
June 9th, 2004, 07:15
oh and keep up the hard work with cpu core. can't wait until some of the other coders can reap the benefits of all your hard work by putting in some of their hard work and politely using your core for other systems

GPF
June 9th, 2004, 18:33
quick update I was able to compile the c68kexec.c file with -O3 since the machine here at work has 512mb(lot faster too)

Ok the -O3 didn't seem to make much of a difference, maybe 1 frame faster.

Stef, I sent you a PM, with the location of my GCC 3.4.0 toolchain.

GuyMelof, yeah I only use XP. and Stef is doing an awesome job on this project. Its been years since I have played a sonic on the genesis.

It was funny my daughter saw me playing Sonic and was wondering what it was, she loves the Sonic 1,2 and Shuffle on the dreamcast. I told her it was the game I played when I was a kid :) .


Troy

dcsteve
June 9th, 2004, 19:27
Gpf- now that you got the display to work properly, do the games still run b/w 25-30 fps? Also, this is w/o sound correct?

GPF
June 9th, 2004, 19:38
yeah based on the fps output from the dc-tool window its running around 25-30 fps with sound. I would say the avg is about 26 fps. but Sonic has a lot of sprite corruptions and really is unplayable, stef is still working on that with c68k emulation. I haven't tried anything other than sonic yet.

Troy

Christuserloeser
June 9th, 2004, 21:30
It was funny my daughter saw me playing Sonic and was wondering what it was, she loves the Sonic 1,2 and Shuffle on the dreamcast. I told her it was the game I played when I was a kid :)

That's so sweet :)

Sonic the Hedgehog 1 still has an incredible charm 8)

Can't wait to play it on DC again with this awesome project ;D

Chris

obelisk
June 10th, 2004, 08:54
magicians! you guys are fn awesome! woohoo... (bounces about in ones chair and looks strange to his cat)... yay!

Stef
June 11th, 2004, 09:44
I uploaded an updated version of C68K, actually i just upload the complete Genesis Plus DC sources :)
You can grab it here :
http://gens.consolemul.com/download/GenPlus_DC.zip

Here are the majors changes in this new version of C68K :
- IRQ callback stuff modified.
- Memory read / write functions prototype modified.
- removed need of dword read / write handler.
- MOVEM instructions fixed (sonic garbages fixed :p)
- others minors tweak or changes...

Now, the core is really close to musashi, you can really easily change from musashi to C68K.
The only difference is that it uses FASTCALL convention...
so if you have a function as :



void write_byte(unsigned int adr, unsigned int value)
{
*// write byte stuff
*....
}


just do that instead :



void write_byte(unsigned int adr, unsigned int value)
{
*write_bytef(adr, value);
}

void FASTCALL write_bytef(unsigned int adr, unsigned int value)
{
*// write byte stuff
*....
}


I tested quickly yesterday Genesis Plus DC (optimisation set to -Os for C68K and musashi and -O2 for the rest) :

* frame skip set to 0 :
*- musashi : 24 FPS
*- C68K : 29 FPS (game speed too slow)

* frame skip set to 3 :
*- musashi : 11 FPS (game speed too slow)
*- C68K : 15 FPS *(game speed ok, a bit fast maybe)

* frame skip set to 4 :
*- musashi : 8 FPS (game speed too slow, but close ok)
*- C68K : 12 FPS *(game speed too fast)

I'm a bit disapointed, C68K doesn't seems that fast, or maybe something else than VDP is eating CPU time (i tried to disable sound but that didn't make any difference since anyway, for some weirds reasons, the sound didn't worked during my tests :-/)

An auto frame skip option would be great imo, i'll see what i can do about that :)

guymelef
June 11th, 2004, 15:57
I feel the need for speed. it looks like some speed ups are kicking in that's hella cool.

Ian_micheal
June 11th, 2004, 16:35
I have Auto frameskip on the SDL version it's running about the same speed if that helps. For me to be of any help it will need to be able to be compiled with cygwin and normal setup.


I cant get dev c++ set up to work right and i find it much harder to use.

Since i use dev C++ for my edtor and just type make there is no need for me to change.

BlackAura
June 11th, 2004, 17:10
The Z80 seems to eat massive ammounts of time. Much more than I would have thought.

I've currently got a version of GP/DC with pretty much all of the graphics code #ifdef'ed out (playing with hardware acceleration, and haven't managed to work out paletted textures yet), and it runs at around 40-50FPS (consider that to be infinite frameskip), peaking at around 55. If you underclock the Z80 to 25 cycles per scanline, the speed jumps to 65-70FPS, peaking at around 80FPS. Sound seems to do just about nothing (turning it off gets me an extra 2FPS)

Paletted textures are being a pain though. I just get a little black square where I should be getting a display of the first colour palette.

Christuserloeser
June 11th, 2004, 18:00
Double post ;)

I am not sure about this but it seems that they already have ported or at least optimized the Z80 by Juergen Buchmueller (SMEG, SMSplusDC) to SH2 if I understand it correctly. SH2 basicly should be compatible to SH4:

http://smsemu.emuunlim.com/misc.htm


excyber.txt - ExCyber thoughts on optimizing Z80 emu core for Saturn's SH2s
z80sh2.txt - Just an useless comments on x86 asm optionally used in Z80 core and how it can be rewrited to sh2

PS Hey MetaFox, I didn't know that u are/were part of the Saturn emu scene :)


Chris

Alexvrb
June 11th, 2004, 23:55
Stef, like BlackAura said, the current Z80 is having a big impact. Your C68k is much faster than mushashi by itself. Combine that with other improvements, and I think we'll see some serious speed. Also, with GCC 3.4.0, GPF has been able to compile C68k with different -O levels than other people. So I think it is quite possible that speed would improve just by that.

WHurricane16
June 12th, 2004, 12:08
I have the complete 3.4.0 toolchain in a rar thats about 10 megs for both gcc and g++, for mingw. but my storm-studios site seems to be down right now.

I'll try to fix this ASAP.

Christuserloeser
June 12th, 2004, 13:55
Good to see you (er or read you ;) ) Will, we all missed you ;D



Chris

Stef
June 12th, 2004, 20:36
Just results of a quick bench :

I tried to desactive Z80, video and sound emulation to test as best i can C68K performance versus musashi on DC
Still memory functions and basic VDP/sound chip read/write which are outside but not very significant.

I overclocked the 68k core to 55 Mhz and here are the result :
musashi gives between 16-23 FPS (with an average 20 FPS) where C68K give between 43-50 FPS (with an average 46 FPS)

Well, we can see than C68K is about 2.3 time faster, if we take in account other part of emulation (as memory read/write function), i think C68K is about 3 times faster than musashi.
but that also means that 68000 emulation alone take a bit more than *20% of complete CPU time, not that bad but not so good too ...

quzar
June 13th, 2004, 00:30
wow, almost 3 times faster. that is amazing! so many things use the 68k that this will have a huge impact on them all ;D

Hola
June 13th, 2004, 06:15
If its 3 times faster that means all you need to do is add this to Reapers Gen + and add saving and a menu and we have a perfect Genesis emu. So pretty much all where doing is waiting for someone to compile a perfect genesis emu now...

Alexvrb
June 13th, 2004, 08:00
Err, there's a little more work that needs to be done first.

Anyway, C68k could provide a good boost to NeoCD DC as well.

BlackAura
June 13th, 2004, 08:07
Hola - Not quite. Aside from the compatability problems, the rest of the emulator still isn't fast enough. The VDP emulator is still taking up a huge ammount of time, as is the Z80. Those need to be improved a lot before we're anywhere near full speed.

Stef - How fast does the thing run if you disable the VDP and Z80, but leave the 68k clocked at 8MHz?

wraggster
June 13th, 2004, 10:50
does the atari st use the 68k too?

Stef
June 13th, 2004, 11:06
As said BlackAura, unfortunatly 68k isn't all in genesis.
The VDP engine is still really slow, Z80 isn't really fast too :-/
We can have full speed game with frame skip set to 2 or 3... but the goal is to have full speed without any frame skip :)

Yeah, Atari uses 68000...

BlackAura> I'll test and report you results...

dcsteve
June 13th, 2004, 11:30
edit- prob fixed

wraggster
June 13th, 2004, 11:32
would this new core now make atari st emulation a serious possibility, ? /me looks for an sdl atari st emu

Stef
June 13th, 2004, 13:12
By disabling VDP, Sound and Z80 (22 cycles by line instead of 228 ). PVR display is also disable, i have FPS from serial port :

C68K : between 120-190 FPS with an average 141 FPS
musashi : between 43-95 FPS with an average 63 FPS

WHurricane16
June 13th, 2004, 14:55
Good to see you (er or read you ;) ) Will, we all missed you ;D

It does seem like I've been gone for a long time :)

Anyhoot, I'm trying to get the source for GenPlus (from the link above) compiled but I'm getting too few arguments for 'pvr_txr_load_dma'. What version of KOS should I be using?

BlackAura
June 13th, 2004, 18:41
I'm having trouble getting any kind of timing information out of my PVR-based renderer. Using KOS's built in timing functions, it's taking 4ms to submit an empty display list, and 5ms to submit a display list containing 3000 polygons. Obviously something's not right there, either in my code (why would it be waiting for 4ms?) or in the way KOS is timing it. Considering that Musashi + everything else is taking around 14ms by itself, there's no way my code is taking 4ms and not dropping down to 30FPS.

Assuming KOS is wrong, or I've made some stupid mistake somewhere, I think it might be possible to send the display list for an actual screen out in around 3-4ms, which would leave 13ms for everything else. If c68k is taking around 7-8ms, which is what it looks like based on your results, that gives us around 5ms for the Z80 and sound code.

That is, of course, assuming I can get the PVR-based VDP emulator working acceptably. At the moment, I'm having trouble parsing the sprite table and getting any meaningful result. Basically, I'm getting large quantities of garbage.

Unfortunately, I don't know any way to benchmark the Z80 without the 68k, because the Z80 relies on the 68k to be able to do anything. Maybe try with the Z80 at very low clock speed and time each frame, then try with the Z80 at full speed and time each frame, then subtract one from the other...

Also odd - I tend to get a framerate of 60-70FPS with Musashi and nothing else enabled, where you seem to be getting 60-90FPS. Very weird. I'm using Sonic 1 as a test game, compiled against KOS 1.2.0 using GCC 3.0.4

Stef
June 13th, 2004, 22:06
I'm having trouble getting any kind of timing information out of my PVR-based renderer. Using KOS's built in timing functions, it's taking 4ms to submit an empty display list, and 5ms to submit a display list containing 3000 polygons. Obviously something's not right there, either in my code (why would it be waiting for 4ms?) or in the way KOS is timing it. Considering that Musashi + everything else is taking around 14ms by itself, there's no way my code is taking 4ms and not dropping down to 30FPS.

Maybe only the first DL sent take a minimum time, for init stuff... no other idea :-/



Unfortunately, I don't know any way to benchmark the Z80 without the 68k, because the Z80 relies on the 68k to be able to do anything. Maybe try with the Z80 at very low clock speed and time each frame, then try with the Z80 at full speed and time each frame, then subtract one from the other...


We can do that :
downclock 68000 at 50 cycles by line, then overclock Z80 *a lot* (something as 3000 cycles by line), others part will be insignifiant... but first we should find a game where Z80 is always used, i think it's ok for Z80 :)



Also odd - I tend to get a framerate of 60-70FPS with Musashi and nothing else enabled, where you seem to be getting 60-90FPS. Very weird. I'm using Sonic 1 as a test game, compiled against KOS 1.2.0 using GCC 3.0.4

Don't worry, i said between 43-90 FPS ;)
with an average 63 FPS ... and i just noticed i tested that with Castlevania Bloodline :p
i guess i'll have the same result as u with Sonic 1... i compiled both core with -Os, others parts are complied with -O2 since i can't link with -Os :-/

Hola
June 14th, 2004, 06:45
I could care less if its using a little frame skip of 2 if it has fullspeed with sound and saving. I doubt many people would.

Ian_micheal
June 14th, 2004, 07:45
Hmm whats the compatabilty like with it ? Speed is great but does it perform with out games breaking? Or is that fixed. I have fullspeed now on neogeo with out frameskip on most games after pvr dma rending it was fast enff for me to take frameskip 4 off and underclocking.

So this core would push it to fullspeed with SFX if it's that fast and does not break any thing in the emulator.

Worth a try but can some one make it so it compiles with a normal kos make file for me just cant seem to get it to compile might be im using GCC 2.9.5

Stef
June 14th, 2004, 08:38
Hmm whats *the compatabilty *like with it ? *Speed is great but does it perform with out games breaking? Or is that fixed. *I have fullspeed now on neogeo with out frameskip on most games after pvr dma rending it was fast enff for me to take frameskip 4 off and underclocking.

So this core would push it to fullspeed with SFX if it's that fast and does not break any thing in the emulator.

Worth a try but can some one make it so it compiles with a normal kos make file for me just cant seem to get it to compile might be im using *GCC 2.9.5


I guess C68K can bring NeoCD to complete fullspeed, maybe you'll be even capable to add a 68000 overclocking feature for game as Metal Slug which has slowdown even on real hardware ;)
Compatibility of C68K is better since i fixed MOVEM instruction, but i'm sure it still contains bugs, i tested about 10 genesis games and they all worked perfectly, so compatibility isn't that bad, but not perfect too ... of course, it'll become perfect, it just requires me sometime to fix the last bugs :)

And now C68K is really close to musashi in use, except you still have to define a "fetch area" (area where code is fetched)...
I uploaded the last version of C68K here :
http://gens.consolemul.com/download/GenPlus_DC.zip

It's the complete source of Genesis Plus with C68K included so it also contains CPU interface (cpu68k.c & cpu68.h files) to easily change from musashi to C68K :)

If you have some time to look into that, i would love to know how C68K perform with NeoCD :) i didn't had the time to test it myself :-/

For compilation, i'll upload the C68K objects files (.o) after my job :p

BlackAura
June 14th, 2004, 10:05
Hola - At the moment, it simply won't run at full speed with sound at all, even if you completely disable the video system. I've tried. The sound CPU (Z80) emulation is just way too slow. Stef's main CPU (68k) emulator will help, but the Z80 emulator still needs work, and nobody's touched it yet. Sound is really a pretty low priority at this stage.

I have exams starting tomorrow, so I probably won't be able to do much. There's only one exam I'm at all worried about ("IT Professional Studies", which is the most stupid subject I've ever had to do), and that's on Wednesday, so after that I'll have a muck around with c68k, and see what happens.

quzar
June 14th, 2004, 21:34
Isnt the z80 core in some other emulator written in sh-2 asm? if so then that should be switched in as it is probably the most advanced z80 core that the DC could use.

Hola
June 15th, 2004, 05:06
Nope there's no Z80 core in Sh2 or trust me people would be using it.

Christuserloeser
June 15th, 2004, 05:23
@quzar: You mean the one for the SEGA Saturn SMS emu, am I correct?

http://smsemu.emuunlim.com look under misc


excyber.txt - ExCyber thoughts on optimizing Z80 emu core for Saturn's SH2s
z80sh2.txt - Just an useless comments on x86 asm optionally used in Z80 core and how it can be rewrited to sh2

Edit: There seems to be no source available...

sludgeNOSPAM@zmail.ru

old hp: phemusat.tripod.com



Chris

Alexvrb
June 15th, 2004, 09:46
I'm pretty sure that core is portable C with optional x86 asm, no SH2 asm at all. What Z80 core are you guys using right now for GP/DC and NeoCD/SDL DC? It could be better anyway.

Coagulus
June 15th, 2004, 10:13
Wasn't SMEG written in SH4? That would have a Z80 core in it. Is the author (Heliophobe?) still around or is the source available for that?

Christuserloeser
June 15th, 2004, 11:20
No, SMEG wasn't written in SH4 - though I am not sure, maybe Heliophobe can do sth like that. He is a very talented devver and, yes, he is still around :)


Chris

BlackAura
June 15th, 2004, 14:24
Smeg used the same Z80 emulator that Genesis Plus and MAME use. The Saturn stuff used a different one, which may or may not be faster. Worth a try.

WHurricane16
June 15th, 2004, 16:09
No one answered my question :/

Stef
June 15th, 2004, 16:21
I'm using KOS 1.2.0 here and it work :)

Ian_micheal
June 15th, 2004, 16:30
I dont use dev c++ i use bash for compiling and cygwin your makefiles are not in a format i use.


Neogeo uses the same z80 thats in genrator. with some changes and it's slow. I had SFX working today ok like buzzing badly but perfect when the sound effect played the buzzing would stop then start after. It was with the z80 and the sfx on running at 40|% or less speed.

So looking like i need to gain 50% speed out of the 2 cpu cores not looking good is it. Sound had a much bigger impact then it did on genesis plus.

JMD
June 15th, 2004, 16:52
May be you can find any faster Z80 core at the home of Z80 CPU (http://www.geocities.com/SiliconValley/Peaks/3938/z80_home.htm).
All the z80 emulator should be referenced here.

fackue
June 15th, 2004, 22:16
Also, I updated the Z80 core with the CottAGE one (which is actually just a newer version of the JEmu Z80 core) and this resulted in a major performance boost.

Maybe this one is modified and is a bit faster? I found this quote, over here - http://www.home.zonnet.nl/duijs24/jemu/.

Maybe this will help too? http://little-bat.de/prog/download/z80_68k/z80_68k.html

quzar
June 15th, 2004, 23:08
lol, if c68k is fast enough we could just have it run emulating the z80 faster than the sh4 can run just the z80 core :P

Ian_micheal
June 16th, 2004, 08:13
Quzar i dont have the ram to compile his core and we need to patch it and recompile it my machine just crashes when i try. We cant use the precompiled there are things we need to ad to the core..


#include "m68kcpu.h"

/* NeoCD declarations */
void cdrom_load_files(void);
void neogeo_cdda_control(void);
void neogeo_prio_switch(void);
void neogeo_upload(void);

extern int img_display;



M68KMAKE_OP(1111, 0, ., .)
{
switch (REG_IR) {
case 0xfabe: neogeo_exit(); break;
case 0xfabf: img_display=1; cdrom_load_files(); break;
case 0xfac0: img_display=0; cdrom_load_files(); break;
case 0xfac1: neogeo_upload(); break;
case 0xfac2: neogeo_prio_switch(); break;
case 0xfac3: neogeo_cdda_control(); break;
default: m68ki_exception_1111(); break;
}
}


this need to go in m68kcpu.c in the other core i dont know where to put them in the new core yet.

So we cant just use the precompiled one's and i cant compile it with my machine some one with over 512 meg has to compile it.

quzar
June 16th, 2004, 08:18
i have plenty of ram, if you want ill compile and test it, all you have to do is send me the sources and makefile

Stef
June 16th, 2004, 08:50
Quzar i dont have the ram to compile his core and we need to patch it and recompile it my machine just crashes when i try. We cant use the precompiled there are things we need to ad to the core..

#include "m68kcpu.h"

/* NeoCD declarations */
void * *cdrom_load_files(void);
void * *neogeo_cdda_control(void);
void * *neogeo_prio_switch(void);
void * *neogeo_upload(void);

extern int img_display;



M68KMAKE_OP(1111, 0, ., .)
{
* * *switch (REG_IR) {
* * *case 0xfabe: neogeo_exit(); break;
* * *case 0xfabf: img_display=1; cdrom_load_files(); break;
* * *case 0xfac0: img_display=0; cdrom_load_files(); break;
* * *case 0xfac1: neogeo_upload(); break;
* * *case 0xfac2: neogeo_prio_switch(); break;
* * *case 0xfac3: neogeo_cdda_control(); break;
* * *default: m68ki_exception_1111(); break;
* * *}
}

this need to go in *m68kcpu.c in the other core i dont know where to put them in the new core yet.

So we cant just use the precompiled one's and i cant compile it with my machine some one with over 512 meg has to compile it.

That look as HLE for the bios right ?
I need to modify the C68K generator (c68kgen.c) to take in account these specials commands, but that souldn't be too difficult :)
I was very busy with my personnal life these last 3 days but i'll try to look in that today...

Ian_micheal
June 16th, 2004, 15:47
Thanks yeah thats right. My machine i cant do it so im stuck got no webspace to put any thing up right now hope some one mirrored the source of v8.0 for every one.


ngemu dns is down right now.

Stef
June 20th, 2004, 15:57
Ian>
I uploaded the special NeoCD version of C68K (it include your HLE stuff) :
http://gens.consolemul.com/download/C68K_bin_neocd.zip

It's directly the binaries files :
- c68k.o
- c68kexec.o

both has been compiled with -0s switch

Don't forget it's only for NeoCD, it need Neoxxx externals... you can't use it for Genesis Plus etc ...

have fun :)

Ian_micheal
June 21st, 2004, 04:47
Im sorry im lost or have lost it take your pick. i have to say *i really have got no clue about adding this now. I thought i did but i get these and i dont know what else to add. I was told your core is now api complent that means to me i dont change the emulator at all and can drop the core in. But i just dont get what you want me to do to make this compile. For the old core it's easy 2 make files it makes the m68k.a i link it in.

Help sorry for being a pain *


thanks for all your work stef.

:-[

Can you tell me *what files but these do i need to add.??????


c68/c68k.o c68/c68kexec.o z80/z80.o *z80/z80intrf.o *neocdc.o vmu/vmu.o

memory/memory.o cdrom/cdrom.o cdrom/dc.o *cdaudio/cdaudio.o *sound/sound.o sound/streams.o

sound/2610intf.o sound/ay8910.o * sound/fm.o *sound/timer.o sound/ymdeltat.o *video/videopvr.o

video/draw_fix.o *swab.o input/input.o pd4990adc.o *

thats all i have what more do i need to add so i dont get the errors





neocdc.o: In function `neogeo_init':
neocdc.o(.text+0x8a8): undefined reference to `m68k_pulse_reset'
neocdc.o: In function `neogeo_hreset':
neocdc.o(.text+0xac8): undefined reference to `m68k_set_reg'
neocdc.o(.text+0xad0): undefined reference to `m68k_pulse_reset'
neocdc.o: In function `neogeo_reset':
neocdc.o(.text+0xd1c): undefined reference to `m68k_pulse_reset'
neocdc.o(.text+0xd20): undefined reference to `m68k_set_reg'
neocdc.o: In function `MC68000_Cause_Interrupt':
neocdc.o(.text+0x1088): undefined reference to `m68k_set_irq'
neocdc.o: In function `neogeo_run':
neocdc.o(.text+0x1264): undefined reference to `m68k_execute'
neocdc.o(.text+0x126c): undefined reference to `m68k_set_irq'
neocdc.o: In function `neogeo_prio_switch':
neocdc.o(.text+0x1424): undefined reference to `m68k_get_reg'
neocdc.o: In function `neogeo_cdda_control':
neocdc.o(.text+0x152c): undefined reference to `m68k_get_reg'
cdrom/cdrom.o: In function `cdrom_load_files':
cdrom/cdrom.o(.text+0x1374): undefined reference to `m68k_get_reg'What should i change these functions to is there news names do i need the m68k old core and this one.

totaly lost

Ian

Stef
June 21st, 2004, 08:12
No problems :)
Well, when i said C68K is musashi complient, actually there are still some differences...
and the least, the fonctions names are different !
where musashi is : m68k_xxx
C68K is : C68K_xxx

and anyway some functions has complete different name, but they do the same work, and take sames parameters :)
Well, actually i think you still should keep musashi in your NeoCD sources, C68K should stay an alternative, just for experiment purposes :)
So you should take the CPU interface i made with Genesis Plus : cpu68k.c and cpu68k.h file
also don't forget to include the C68K header file (c68k.h) in your project, you can take all that from my last sources of Genesis Plus DC :
http://gens.consolemul.com/download/GenPlus_DC.zip


Well, as you added that to the project, you'll have to replace all m68k_xxx functions by M68K_xxx functions (which are from the CPU interface).
depending current CPU core definition in cpu68.h file, the CPU interfacer will use musashi or C68K methods :)

You will have to modify the M68K_Init function as well to add the good prefetch area in C68K...
Hmmm... actually i'm thinking they are many changes to do :-/ also the memory functions, interrupt callback ...
Well, just try to do the first points, then post as soon you're lock ed somewhere and i'll help you... you can also get me in touch with ICQ or MSN if you want :)

quzar
June 21st, 2004, 08:19
I was able to get it mostly in, but i was using the first c68k sources you posted, not the ones from Genplus, maybe that makes a difference. I think it would have worked except the main neocd file had to be rewritten in a lot of parts.

Stef
June 21st, 2004, 09:10
I was able to get it mostly in, but i was using the first c68k sources you posted, not the ones from Genplus, maybe that makes a difference. I think it would have worked except the main neocd file had to be rewritten in a lot of parts.

The first C68K files are even less friendly with musashi ...
Futhermore, you don't have the HLE stuff included :-/
To make NeoCD working correctly you should use the C68K_bin_neocd.zip obj files :)
Of course, you also need to take c68k.h file and cpu niterface from GenPlus_DC.zip archive ...
then some work is needed to succefully include it in NeoCD ...Where is the last NeoCD sources archive ? if i've some free time, i'll try to look into that...

Christuserloeser
June 21st, 2004, 09:36
That's the latest public archive I believe:

http://imrtechnology.ngemu.com/emulators.htm

http://imrtechnology.ngemu.com/downloads/v8.1src.rar

:) It's really nice to see you people working so close together!


Chris

quzar
June 21st, 2004, 11:26
The first C68K files are even less friendly with musashi ...
Futhermore, you don't have the HLE stuff included :-/
To make NeoCD working correctly you should use the C68K_bin_neocd.zip obj files :)
Of course, you also need to take c68k.h file and cpu niterface from GenPlus_DC.zip archive ...
then some work is needed to succefully include it in NeoCD ...Where is the last NeoCD sources archive ? if i've some free time, i'll try to look into that...

I did have the NeoCD object files ;) I was close but just tired (it was like 6am). Also i was using the outdated first release c68k headers. Ill try it now with the files from GenPlus and the neocd object files.

quzar
June 21st, 2004, 12:47
Sorry for the double post, but also, how can i compile the GenPlus with c68k? The makefile included says nothing about c68k =(

Ian_micheal
June 21st, 2004, 14:19
Hmm ive looking at it cant sleep im now having nitemares about adding this.

Interface headers
// 68K CPU interface

#include "types.h"
#include "cpu68k.h"
#include "c68k.h"
#include "m68k.h"
#include "m68kcpu.h"
#include "mem68k.h"
//#include "genesis.h" *i dont think i should include this.


problem do i have to compile and edit the files that are the same names as these headers but c files there heavly baised to genesis plus if i compile them c files it conflicts with functions and i endup including most of genesis plus in neogeo cd. *

Just want to know do i have to compile any more files then what you have told me???.

c68/c68k.o c68/c68kexec.o c68/cpu68k.o *cpu core correct?

headers to included in the cpu interface file.

change the define *in *cpu68k.h

#define CPU68K_USE_MUSASHI
//#define CPU68K_USE_C68K

errors now


c68/cpu68k.c:32: warning: static declaration for `M68K_Init' follows non-static
c68/cpu68k.c: In function `M68K_Init':
c68/cpu68k.c:37: `m68k_irq_ack_callback' undeclared (first use in this function)

c68/cpu68k.c:37: (Each undeclared identifier is reported only once
c68/cpu68k.c:37: for each function it appears in.)
c68/cpu68k.c: At top level:
c68/cpu68k.c:58: warning: static declaration for `M68K_Reset' follows non-static

c68/cpu68k.c:69: warning: static declaration for `M68K_Exec' follows non-static
c68/cpu68k.c:80: warning: static declaration for `M68K_SetIRQ' follows non-stati
c
c68/cpu68k.c:91: warning: static declaration for `M68K_GetOdo' follows non-stati
c
c68/cpu68k.c:102: warning: static declaration for `M68K_EndExec' follows non-sta
tic
c68/cpu68k.c:114: warning: static declaration for `M68K_SetFetch' follows non-st
atic
c68/cpu68k.c:126: warning: static declaration for `M68K_GetDReg' follows non-sta
tic
c68/cpu68k.c:137: warning: static declaration for `M68K_GetAReg' follows non-sta
tic
c68/cpu68k.c:148: warning: static declaration for `M68K_GetSP' follows non-stati
c
c68/cpu68k.c:153: warning: static declaration for `M68K_GetPC' follows non-stati
c
c68/cpu68k.c:164: warning: static declaration for `M68K_GetSR' follows non-stati
c
c68/cpu68k.c:175: warning: static declaration for `M68K_SetDReg' follows non-sta
tic
c68/cpu68k.c:186: warning: static declaration for `M68K_SetAReg' follows non-sta
tic
c68/cpu68k.c:197: warning: static declaration for `M68K_SetSP' follows non-stati
c
c68/cpu68k.c:213: warning: static declaration for `M68K_SetSR' follows non-stati
c



What step im i missing i just want to get this to compile for a change so i can work on *rewriting the functions.

EDIT ok found one error

int m68k_irq_ack_callback(int int_level);

s32 FASTCALL m68k_irq_ack_callbackf(s32 int_level);

in genesis.h i need to move that dont know what else i need from the header yet.

Now i get this i went past the first error


rnel/arch/dreamcast/include -c z80/z80intrf.c -o z80/z80intrf.o
In file included from neocd.h:19,
* * * * * * * * from z80/z80intrf.c:6:
c68/c68k.h:82: parse error before "FASTCALL"
c68/c68k.h:82: parse error before "adr"
c68/c68k.h:82: warning: data definition has no type or storage class
c68/c68k.h:83: parse error before "C68K_WRITE"
c68/c68k.h:83: parse error before "adr"
c68/c68k.h:83: warning: data definition has no type or storage class
c68/c68k.h:85: parse error before "FASTCALL"
c68/c68k.h:85: parse error before "level"
c68/c68k.h:85: warning: data definition has no type or storage class
c68/c68k.h:86: parse error before "C68K_RESET_CALLBACK"
c68/c68k.h:86: warning: data definition has no type or storage class


??

#define FASTCALL *?

#define FASTCALL
#define C68K_READ
#define C68k_Get_MSP
#define C68K_INT_CALLBACK

so make defines for every error? removes them but hmm..

Ok i got it to this


c68/cpu68k.o: In function `M68K_SetPC':
c68/cpu68k.o(.text+0x6c): undefined reference to `m68k_set_reg'
c68/cpu68k.o: In function `M68K_Disassemble':
c68/cpu68k.o(.text+0xa4): undefined reference to `m68k_disassemble'
neocdc.o: In function `neogeo_hreset':
neocdc.o(.text+0xac8): undefined reference to `m68k_set_reg'
neocdc.o(.text+0xad0): undefined reference to `m68k_pulse_reset'
neocdc.o: In function `neogeo_reset':
neocdc.o(.text+0xd1c): undefined reference to `m68k_pulse_reset'
neocdc.o(.text+0xd20): undefined reference to `m68k_set_reg'
neocdc.o: In function `MC68000_Cause_Interrupt':
neocdc.o(.text+0x1088): undefined reference to `m68k_set_irq'
neocdc.o: In function `neogeo_run':
neocdc.o(.text+0x120c): undefined reference to `m68k_execute'
neocdc.o(.text+0x121c): undefined reference to `m68k_set_irq'
neocdc.o: In function `neogeo_prio_switch':
neocdc.o(.text+0x13c4): undefined reference to `m68k_get_reg'
neocdc.o: In function `neogeo_cdda_control':
neocdc.o(.text+0x14cc): undefined reference to `m68k_get_reg'
cdrom/cdrom.o: In function `cdrom_load_files':
cdrom/cdrom.o(.text+0x1374): undefined reference to `m68k_get_reg'

quzar
June 21st, 2004, 18:47
I know how to fix those. ill tell you on msn

quzar
June 21st, 2004, 21:56
i tried to compile GenPlus again and got far until i got this error in c68kexec.c:1928 - Internal Error: Segmentation Fault.

Stef
June 22nd, 2004, 01:55
i tried to compile GenPlus again and got far until i got this error in c68kexec.c:1928 - Internal Error: Segmentation Fault.

It sometime happened to me... did you overclocked your CPU ? ^^
Just try to recompile it and be sure you have enough memory ;)
Normally you can compile the GenesisPlus DC soucrs without any changes, the last archives is here :
http://gens.consolemul.com/download/GenPlus_DC.zip

It include the last version of C68K and cpu interface :)

I just downloaded NeoCD sources... i'll see what i can do with it :)

quzar
June 22nd, 2004, 02:48
How do i compile it? Maybe there is something I dont have... I see a standard makefile in here, but it says nothing about c68k and the makefile for the m68k that this makefile requires is missing... maybe GenPlus.dev is what im supposed to use?

BlackAura
June 24th, 2004, 00:10
Stef - I'm trying to integrate C68k into a modified version of Genesis Plus using hardware VDP emulation. Just a quick question - do I need to link to any of Musashi, or is it enough to just link to C68k? As far as I can see, nothing should still be using Musashi, but I can't really be sure.

quzar
June 24th, 2004, 01:06
the interface he created allows for musashi and c68k to be switched with one define change. but as long as you have it defined to use c68k you dont need anything from musashi (to be linked in)

BlackAura
June 24th, 2004, 01:19
Got it working now (Musashi is linked in at the moment)

Stef
June 24th, 2004, 02:02
As said Quzar, Musashi is still linked in the project since i'm passing by a CPU interface (cpu68k.c) to easily change from musashi to C68K...

You're making a really nice job with your PVR accelerated VDP core :) i think your version with C68K should be pretty fast without sound enable (always >= 60 FPS).. i think now the slowest part is the sound generation ;)

BlackAura
June 24th, 2004, 02:10
The Z80/Sound is definitely the slowest part now. Without sound, every single game I've tested runs at 60FPS, with varying degrees of graphical incorrectness.

I'm going to have another crack at the sound code (the bit that interfaces with the DC sound hardware), and try to make it more tolerant of changes in framerate. Combined with limited auto frameskip (mostly to smooth out the odd frame which takes just over 1/60th of a second), that should make most games playable with sound enabled. And it sound so much better than Sega's Smash Pack...

Christuserloeser
June 24th, 2004, 08:30
@both of you: please get in contact with Heliophobe as he's working on some YM sound optimizations for DC:


That said, I am rewriting a bunch of it... I realize the way I'm doing it drums are going to slow things down a lot more than I had anticipated. Not that it needs to be really fast but I'm hoping to come up with some speedup techniques that could be applied to emulation of the 4-op family of Yamaha synth chips (as used in the YM2612 and YM2151(?) in the Genesis, Neo Geo, and many arcade systems). --no guarantees of course.

Maybe his findings could be implemented in the Gens YM2612 core?

Chris

Stef
June 30th, 2004, 11:59
I uploaded a new version *of the C68K sources here :
http://gens.consolemul.com/download/c68k_src.zip

I also updated the precompiled version for NeoCD :
http://gens.consolemul.com/download/c68k_bin_neocd.zip

Here's what is new in this version :
- RTE instruction fixed (change user mode)
- xBCD instructions fixed.

I made the fix really quickly so i hope it's ok... i'm really busy with my personnal life these last days... sorry for being so long for the update.