M68K for DC

[quzar]

yay! any chance that any of the timer issues have been fixed?

[Stef]

xBCD instructions are used for that, it's why i scanned xBCD code ;)
So all counter issues should be fixed now :)

[quzar]

yay! time to go try and compile NeoCD ;D

[ron]

May be using that new 68K core you got, why don't we try to port the CaSTaway emulator running actually in *GP32 *and bring it to DC, because all of it, is developed using SDL and with the Propeller's DCDevCpp could *be easy and fine to port. That's an idea to test how it does go !!! Nice to see u.

[quzar]

has your team abandoned the m68k in sh4 project?

[Christuserloeser]

May be using that new 68K core you got, why don't we try to port the CaSTaway emulator running actually in *GP32 *and bring it to DC, because all of it, is developed using SDL and with the Propeller's DCDevCpp could *be easy and fine to port. That's an idea to test how it does go !!! Nice to see u.

Sounds like a good idea and I think it would achieve a good speed if you stop using SDL while porting it.

But it would be sad if you would completly abondon the SH4 68K project, don't you think?!

...thinks of Sega Saturn Sega CD, Amiga 500, Capcom CPS1 / 2, System16 etc etc


Chris

[quzar]

think you could edit that down to just say the different systems using m68k s?

also, where can i find sources to 1.0.1? i can only see sources to CaSTaway versions .9.3 or something.

[Christuserloeser]

Done. A bit too enthusastic I am, sometimes... ;D

Would be too bad to not have a SHx 68K some day soon.


Chris

[wraggster]

May be using that new 68K core you got, why don't we try to port the CaSTaway emulator running actually in *GP32 *and bring it to DC, because all of it, is developed using SDL and with the Propeller's DCDevCpp could *be easy and fine to port. That's an idea to test how it does go !!! Nice to see u.

I would love to see the atarist emulated on the Dreamcast, anyone had any success

[wraggster]

any updates on the 68k core?

[quzar]

stef is now starting work on a z80 core along the same lines as C68k. He also has a few fixes he is planning to make to C68k, but they arnt major.

[wraggster]

wow so that really opens the doors to much more than just Genesis emulation :)

hows your Neopop port btw ;)

[Stef]

any updates on the 68k core?

I still not discovered new bugs in the last released version... it need some tweaks though but that's not really a must.


stef is now starting work on a z80 core along the same lines as C68k. He also has a few fixes he is planning to make to C68k, but they arnt major.

Unfortunatly, the speed increasement with a new Z80 core won't be significant as it was with C68K, because actuals Z80 cores aren't that slow, they already uses JumpTable... I'll first do some tests, if the new Z80 core isn't at least twice as fast as the current one used in Genesis Plus / NeoCD, it won't be worth the effort :-/

[quzar]

hows your Neopop port btw ;)

I made a lengthy set of posts about it over at DCemulation. Basically I have gotten it compiled and running, but cannot get it to do anything. Basically I feel that I simply dont know enough yet to complete it and am therefore setting it aside to try to do other things and gain some more experience before revisiting it. I do however have 2 game ports and a homebrew game coming out in the near future (august?) so Im not just sitting around ;)

@ Stef. At the speed that the Z80 emulation currently runs on the DC, it is safe to say that even 1.4 or 1.25 times faster would be very welcome, and would give almost everything using a Z80 the small bump it needs to acheive full speed.

[Christuserloeser]

@ Stef. At the speed that the Z80 emulation currently runs on the DC, it is safe to say that even 1.4 or 1.25 times faster would be very welcome, and would give almost everything using a Z80 the small bump it needs to acheive full speed.

Oh yes, that'd be very welcome for SMSplusDC (needs some speed up for the Yamaha FM2413 emulation), GenesisPlusDC, NeoCD, MDCNG etc.

[wraggster]

With the Knowledge from whats been learned in this and other topics, is a PSx emulator writtten with an sh4 cpu /graphics core a possibility now?

thats of course if anyone ever wanted to try.

[quzar]

PCSXDC is probably one of the least optimized emulators out there. Im sure 30fps is attainable without sound.

[Alexvrb]

I think its possible to make a PSX emu with moderate compatibility and playable speed, with sound. But it wouldn't be remotely easy. I wouldn't count on it, ever.

[wraggster]

i would say fpse is a better emu but are the sources available, i doubt it

[Eric]

i found sources but no to sure if its for that http://www.geocities.co.jp/Playtown/2004/fpse/download.htm

[Alexvrb]

i would say fpse is a better emu but are the sources available, i doubt it
Even if it was, is it any faster, because speed is the biggest issue. Also, even if THAT was true, it wouldn't matter because you'd eventually have to rewrite almost everything anyway.

[wraggster]

pity there wasnt a C to sh4 asm converter :P

[guymelef]

even if there was it would probably just be sloppy and break emulation.
but nice thought

[BlackAura]

pity there wasnt a C to sh4 asm converter :P

There is - it's called GCC.

[Alexvrb]

But guy was right, it IS sloppy and can break emulation. :P

[Mekanaizer]

Wraggster wrote:

pity there wasnt a C to sh4 asm converter :P

BlackAura wrote:

There is - it's called GCC.


Yes there is BlackAura i know you know the 'call' but here it is for those who don't know:

sh-elf-gcc -S C_input_file_name.c Asm_output_file_name.s

note: the 'call' is -S and not -s (anyway -s some times work may depende on the gcc version i don't know for sure). And the convertion needs work since gcc only output 'good' Assembly code for the sh4 geral registers and 'not so good' for FPU registers. Anyway it is a good help to help code Asm stuff. ;D

-Mekanaizer-

[wraggster]

any updates on the 68k core, it seems to have gone very quiet?

[fox68k]

Hello everyone,

i am new in this great community! 8)

Well, first of all, thanks goes out for all of you working on M68K for DC and specially to Ian and Stef for his hard work.

I wanted to help with my grain of sand and i have been working on a 68k emu for DC for a while. It is an interpreter written is SH4 asm and it is working right now :) but there are left many opcodes and management routines to get it completed.

I am sure this core will be faster than any C core. Some people were talking about that an asm core will not boost emulation too much but i'd say wait for results. I didn't test my core against Musashi or C68K so i won't say nothing at this moment. We will see (i hope ;)).

Finally, i'd like to get in contact with someone that can help me to get this core into Genesis Plus or NeoGeoCD in a near future.

Any idea or suggestion will be much appreciated.

Thanks!

[wraggster]

Blackaura / Ian you there:)

[quzar]

I can put it into NeoCD. I first put C68k into it, so im fairly familiar with the CPU interfaces.

[WHurricane16]

To fox68k - :o

This scene is getting technically very interesting lately. Can't wait to see Wraggster's yearly review in 1st qtr 2k5!

[wraggster]

so is stefs 68k core asm or C?

and welcome to the Dreamcast scene :)

[quzar]

stefs 68k core is in C, but it is very very well written. He says that by the way it works it would be hard to get more speed by using asm. There were still a few things he wanted to do to gain a bit more speed.

[fox68k]

Wraggster ask me about core completion, so i try here to write a brief report about:

What it is implemented:

- Interface functions: General purpose: initialize, reset, emulate, get_pc, get_cpu_state.
* * Hardware interrupt handling: raise_interrupt, lower_interrupt, get_interrupt_vector, change_interrupt_vector.
* * CPU context handling: get_context_size, set_context, set_register.
* * Timing: get_cycles_counter.
- Opcodes: 70% aproximately.
- Flag calculation on most of the implemented opcodes.
- Internal memory handling routines (fetch, read and write) in all data sizes.
- All addressing modes.

What it is not implemented:

- Interface functions: General purpose: peek, poke.
* * * Hardware interrupt handling: None.
* * * CPU context handling: get_context, get_register.
* * * Timing: trip_cycles_counter, control_cycles_counter, release_timeslice, add_cycles, release_cycles.
- Hardware interrupt execution.
- Error exception (bus error, address error, privilege violation, illegal exception) handling.

And that is all. I have written the function names too to show you core interfacing at a glance.

I hope you find my report interesting. *;)

Cheers.

[wraggster]

Nice

lets hope the other great coders here team up with you :)

[fox68k]

me too Wraggster cause i can't wait to see all our work mixed up ::)

[Eric]

Okay so if this is written in sh4 asm does this mean it would help for the GBA,N64 and Saturn emus on the dreamcast?

[fox68k]

Nope, those game consoles does not have a M68k processor inside so this core won't help at all. :(

This emu is intented to be used in Genesis or NeoGeoCD and in a good amount of arcade machines (CPS-1 for example) emus.

[Eric]

Okay what about SNES emulators then?

[Ian_micheal]

I can put it into NeoCD. I first put C68k into it, so im fairly familiar with the CPU interfaces.


Hmm if you did you never gave it to me working i worked with stefd he put the core in and to compile it needed precompiled files and 1 precompiled from me.

HLE stuff was not added when you attemped it no way it would work.

I dont want stef to read that becuase he put the core in neogeo cd and showed me the functions after that i understood it was able to get it to compile then helped him to get it to compile with some little setup problems in neogeo cd.


Stef put the core in it sent me the files which still would not compile due to some strange problems which i fixed.

I can show you how and were and what to do with the new core.

Sorry if this look mean or a reproch but stef d did it not you.

Dont mean any disrespect but if i was stef and seen your comment it would slightly piss me off.

[Eric]

Does this mean that Stef would leave the scene if we have you working in the scene. This is something thats been on my mind. Although in the real world if sh4 asm is way better then C++ and if that was how Sega was working i know they werent cause they were more complex with Katana but if they were they would probably go with a sh4 asm before C++.

I am not trying to pee off anyone but in the real world thats what could happen or even Stef could work with this guy and see what kinda ideas can run through to make althese emulators run quickly.

Am I right?

Eric

[BlackAura]

Does this mean that Stef would leave the scene if we have you working in the scene. This is something thats been on my mind. Although in the real world if sh4 asm is way better then C++ and if that was how Sega was working i know they werent cause they were more complex with Katana but if they were they would probably go with a sh4 asm before C++. Eric

I wouldn't think so. There's still lots of work to go around, and C68k did make a massive difference over Musashi.

Anyway, adding it to Genesis Plus shouldn't be that hard, becauase when Stef added it, he created a wrapper module which can be used to change the CPU core over fairly easily. At the moment, for the hardware accelerated version, we don't need that much extra speed. We're probably around 95% with sound, so we only need another ~5% somewhere.

[Eric]

Would people see a difference with that 5%?

[Alexvrb]

Okay what about SNES emulators then?
No. You must not have read through the early stuff here. C68k, m68k, Fox's 68k, or any other 68k emulator all emulate the Motorola 68k. That CPU is used in Genesis, NeoGeo CD, and a good amount of arcade systems. If a system doesn't have a 68k chip in it, the emulator for 68k isn't going to help. SNES, PSX, N64, etc, don't have 68k chips. So you aren't going to be using C68k or any other 68k emulator for them. You could always use www.google.com and find out more information about what hardware these systems use on your own.

Saturn actually *does* have a 68k in it, but it's part of the sound subsystem, not the main processor. I'm not even sure how important accurate emulation of it is, so you still might not need a full 68k emulator. Plus it wouldn't really help since the rest of the system needs to be emulated properly first.


Would people see a difference with that 5%?That depends. If your sound is breaking because the emulator is too slow, then the 5% would fix the sound. You might not notice the speed difference, but the sound wouldn't screw up on you anymore, and that is a BIG difference. Especially when you're working to retain authentic Genesis audio. Which is why Quzar told Stef that he'd be happy with a Z80 that is only a little faster, as both emulators would benefit from the speed - and probably from a more properly working Z80 emu, too.

Fox: What are you gonna call it? F68k? * 8)

[quzar]

Hmm if you did you never gave it to me working i worked with stefd he put the core in and to compile it needed precompiled files and 1 precompiled from me.

HLE stuff was not added when you attemped it no way it would work.

I dont want stef to read that becuase he put the core in neogeo cd and showed me the functions after that i understood it was able to get it to compile then helped him to get it to compile with some little setup problems in neogeo cd.


Stef put the core in it sent me the files which still would not compile due to some strange problems which i fixed.

I can show you how and were and what to do with the new core.

Sorry if this look mean or a reproch but stef d * did it not you.

Dont mean any disrespect but if i was stef and seen your comment it would slightly piss me off.

After stef gave it to you you asked me to replace all the memory functions because it wasnt compiling for you. He compiled the core and you gave me that, then i changed all the cpu calls to the different ones and got the cpu68k working with musashi correctly. If you recall there were issues because of the directory structure and where all the files were.

That dosnt matter though, in any case I am also capable of implementing it.

I want to see what stef would have to ask fox as to the design of the cpu core.

@Fox: I truely mean no disrespect from this, but what have you done before? Have you ever written 68k cores or something? I would reccomend looking to see how Stef's core works and keeping that in mind as you finish this, because just asm wont give miracle speedups.

[quzar]

Saturn actually *does* have a 68k in it, but it's part of the sound subsystem, not the main processor. I'm not even sure how important accurate emulation of it is, so you still might not need a full 68k emulator. Plus it wouldn't really help since the rest of the system needs to be emulated properly first.

Its not a standard 68000, i think its a 68020 or 68E20 or something like that, ATM I don't recall the exact lettering. But I'm pretty sure that would only be a small issue as the whole 68xxx line is very similar.

[guymelef]

no bickering it could only lead to ruin.
teamwork can get this thing of the ground without a hitch in a year easy

[Stef]

stefs 68k core is in C, but it is very very well written. He says that by the way it works it would be hard to get more speed by using asm. There were still a few things he wanted to do to gain a bit more speed.

I don't remember where i said that ... There is always way to do better in ASM, specially with GCC and SH-4 code ;)

Here's what i said in a old post :



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.

So we can definitly do better with ASM, that's why fox68k's new SH-4 assembly core is welcome :)
You can easily test it in Genesis Plus DC or NeoCD by implementing it in the CPU interface (cpu68k.c file).
But as your core isn't very advanced (lack of interrupt) you should test it with a small test code and compore it against others cores :)
Are the sources availables somewhere ? or you want to first complete it before releasing anything ?

[quzar]

Im sorry i thought taht at some point you said something along the lines of "it would still take a well written asm core to match this one" or something like that... sorry :-/ i think i should take a break from posting for a bit.. sigh.

[Stef]

Im sorry i thought taht at some point you said something along the lines of "it would still take a well written asm core to match this one" or something like that... sorry *:-/ i think i should take a break from posting for a bit.. sigh.

Yeah i remember, i said that... a bad ASM core can be slower than a good C core, but i guess fox68k core has been disigned for speed :) And a good C core can't be as fast than a good ASM core, that's the idea ;)

[fox68k]

I can show you how and were and what to do with the new core.



Ian, your help is more than welcome. :D

[fox68k]

Fox: What are you gonna call it? F68k? * 8)

I don't know yet. I'd like to add something that remember the Dreamcast or the SH4.

[fox68k]

@Fox: I truely mean no disrespect from this, but what have you done before? Have you ever written 68k cores or something? I would reccomend looking to see how Stef's core works and keeping that in mind as you finish this, because just asm wont give miracle speedups.


Well, i started to write x86 asm 8 years ago, but nothing serious until i started a m68k asm emu for x86 3 years ago called FAME (http://www.emumega.com/s68k/english) (look for it there). I worked very hard to get a very optimized emulator and specially a very very ACCURATE one (you can check this out in my documentation).

But SH4 is very different to x86. I've been learning SH4 asm for a few months. It is RISC, that means the ISA is not as big as in x86 (CISC), the addressing modes are sometimes cumbersome and the whole architecture is different (flags and other things). The only advantage is the register set (more registers, but you can't access it in halves :-/).
All this makes 68k emulation harder than in x86.

I will work hard to get the new core working as soon as possible.

I recommend you to wait to see results about emulation speed.

Stef is a very talented programmer and did a great job with C68k, but i mainly interested in asm. I hope we can join forces soon, cause i want to learn more about emulation (graphics and others).

[fox68k]

You can easily test it in Genesis Plus DC or NeoCD by implementing it in the CPU interface (cpu68k.c file).
But as your core isn't very advanced (lack of interrupt) you should test it with a small test code and compore it against others cores :)
Are the sources availables somewhere ? or you want to first complete it before releasing anything ?

Thanks for the suggestions. I take note :)

Let me finish this thing and get it in GP or NGCD before i release sources. I want to release a complete source code. It will be much better for anyone interested in.

[Alexvrb]

Sounds good to me, Fox. You can always call it DC68k, Dream68k, SuperH68k, something along those lines.

[guymelef]

how about 86'd. like 86 the quarterback or 86 chicken parm

[Hola]

This is wonderfull :D
A z80 asm core would be kick ass too.

[Ian_micheal]

Neogeo cd needs quiet a few advanced function in the core. Genesis plus would be easyer to get runing with a new core.

[fox68k]

Ian, what do you mean by advanced functions? built-in memory handling support?

[Hola]

Is there a estimated release date plained for this sh4 68000?

[BlackAura]

Ian, what do you mean by advanced functions? built-in memory handling support?

It needs to be able to trap BIOS calls for the CD emulation to work. It doesn't actually emulate the CD drive itself, but it intercepts the BIOS calls to access the CD, and emulates them using native file operations.

[Hola]

Is that why the cd audio is about 5 seconds delayed?

[BlackAura]

I don't think so. That's probably related to something else entirely.

[quzar]

Audio problems in NeoCD mostly stem from the fact that the CD audio drivers used the Z80 to do some stuff(not processing, but like really basic things) and the z80 is turned off and broken.

[fox68k]

It needs to be able to trap BIOS calls for the CD emulation to work. It doesn't actually emulate the CD drive itself, but it intercepts the BIOS calls to access the CD, and emulates them using native file operations.

I am going to try to guess what you mean:

NGCD emu changes interrupt handler routine (BIOS) to point to a new one to avoid CD access. Instead, NGCD emu emulates those accesses doing native file operations like you said, but those accesses are performed out of the m68k core, right? So this way, m68k core remains the same. I saw some code in NGCD emu that changes data directly before emulation process start probably getting things up about CD acceses. Right again?

Thanks.

[BlackAura]

Pretty much, yeah. When an interrupt is called, the emulator calls some native code which does the same thing instead of jumping to the appropriate M68k interrupt handler. The actual file I/O is performed outside the CPU core, of course, but there needs to be some mechanism to supply a callback function that can be used instead of calling an interrupt handler.

[fox68k]

Is there a estimated release date plained for this sh4 68000?


Not yet. There is work to do and i don't know when i could release it. I will keep you informed about progress.

[fox68k]

Very interesting BlackAura. I'd never thought about that feature ::)

How could i implement that in the core in a cool fashion? (i mean function interface or any other kind of management).

Thanks!

[BlackAura]

I've never seen any CPU emulator that implements that cleanly. The ones that implement this kind of feature at all tend to be fairly tightly integrated with the system emulator.

[Stef]

The way is done in musashi and C68K is just to wrap some undefined opcodes 0xFxxx to internals emulators functions.
Quite simple to do but it's a hack...

[BlackAura]

That's a bit of a cheap trick, but I suppose it works.

[Hola]

Arent cheap tricks actually better for speed?

[quzar]

Arent cheap tricks actually better for speed?

At times. It all depends on what its doing. Usually cheap tricks replace really complex yet more appropriate code. It may or may not be faster but usually is not as 'proper'.

[Hola]

I remember back in the day when Gencyst was popular I remember everyone saying its sound core didnt even emulate the genesis at all but simulated it.
Would simulated sound or cpu improved speed yet keep the desired output?

[quzar]

have you ever heard of the Sega Smash Pack? It has simulated sound, but is fullspeed. It sounds horrible.

[Hola]

But Gencryst sounded just fine.

[Christuserloeser]

Yeah, but the Smash Pack didn't ;D It's a shame that it even exists - and it was officially coded by SEGA... >:(

BlackAura told me that it was some kind of a cheap MIDI styled hack for sound emulation. It only 'worked' halfway decent on Shining Force & Phantasy Star but still sounded bad.

Chris

[BlackAura]

As far as I can tell, the Smash Pack's sound emulation wasn't. It emulates the programmable part of the sound chip correctly (like the registers and the timers), but that's about it. Beyond that, it seems to just take the frequency parameters for each channel, and play a sine wave at that frequency. That's certainly what it sounds like anyway.

[Hola]

So how goes that Sh4 core?

[fox68k]

The core is in the right way and i hope to get it finished in the first half of september, but i do not promise anything cause debugging work could delay it.

Cheers.

[Hola]

Thats very exciting to here. Also how much faster will it be than Stef C core?

[Omicron-Delta]

You guys are in luck... I've been working on porting the Starscream intel asm version to SH4 asm for the last two months... I'll give a progress report and put a site up soon... 8)

[Hola]

Thats 2 Sh4 engines now eh? Wow.

[fox68k]

Thats very exciting to here. Also how much faster will it be than Stef C core?

That's difficult to answer before test results. I said it will be faster than a C core but not how much. I hope we can see results soon but, until then, be patient.

I will try to report core progress within a few days.

Greetings.

[wraggster]

Nice to hear of 2 SH4 asm projects :)

[quzar]

let us not forget the original one with which the topic started eh?

[Ian_micheal]

If it's 5% to 10% faster then c68k core it would allow full sfx music on neogeo cd i need about 10% This is for over clocking it not for normal speed as it's fullspeed with the curret core with sfx disabled.

Most mame drivers need about 10 to 15% more speed to have proper music TMNT sga for example 10% would be totaly fullspeed 22kh sound. Same for outrun and space harrier. And other's.

Let me know if you get it working well [email protected]

[Hola]

Wouldnt adding a real z80 core for also make the cd sound work?

[Alexvrb]

Wouldnt adding a real z80 core for also make the cd sound work?
They already have a real one, its just not very fast and may have other problems. He isn't enabling it because it kills the speed of the emulator. Also, many games have working CD sound without it.

Quzar: Have you heard anything about their project recently?

[Hola]

I thought they said the way they where doing sound without the z80 for cd sound might be the cause of it not working on everygame and just few.

[Ian_micheal]

Thats been fixed by the ps2 port author who debugged it for me z80 runs ps2 runs. Im in contact with this person. Sfx works but slows it down.

[Hola]

So theres cd sound for every game now?

[quzar]

They already have a real one, its just not very fast and may have other problems. He isn't enabling it because it kills the speed of the emulator. Also, many games have working CD sound without it.

Quzar: Have you heard anything about their project recently?

not a thing. just felt like it should be mentioned.

[DemoniusX]

I think NG\DC is fast enough why not work on a sound core, all it really needs is some SFX, everything else about the emu is optimized. Full speed is nice and we already have it. it just needs a tweeked Z80 core that runs without slow speed and messed up sound, I hope it happends soon, but my two cents never matters to anyone here cuz all I get is smart ass remarks.

[Alexvrb]

It's no wonder when you act like that all the time. FYI someone already is working on a new Z80 core.

[quzar]

Yea, stef has been working on one.

EDIT: since this is on a new page and i didnt quote the previous message i thought it would be nice to clarify what i meant.

Yes, there is a new Z80 core being worked on. Stef D. has been working on it for some time, and it should give some speedup, which is all many projects need to be fullspeed.

(one example would be SMS, which is almost there but cant quite get fullspeed with full FM emulation)

[DemoniusX]

regardless I think SMS is perfect needs no tweeking expect the "3-d" game perhaps but its perfect has saving and everything.

[quzar]

regardless I think SMS is perfect needs no tweeking expect the "3-d" game perhaps but its perfect has saving and everything.

not to get off topic, but SMS emulation does not exist on the dreamcast at full speed with FM sound.

[Hola]

I think the point DemoniusX was trying to make is we worry about perfecting emulators are perfectly good enough such a SMS instead of worrying about "more important things"

[MetaFox]

I think the point DemoniusX was trying to make is we worry about perfecting emulators are perfectly good enough such a SMS instead of worrying about "more important things"The important things are what the coders want to do, not what the users want the coders to do.

[quzar]

I think the point DemoniusX was trying to make is we worry about perfecting emulators are perfectly good enough such a SMS instead of worrying about "more important things"

The thing is though, this will make those still far from perfect (the emulators you are thinking of). SMS emulation is actually really really close to being completely full, moreso than the emulation of the other systems this would help with.

[Alexvrb]

Not to mention updating an SMS emulator to use a new Z80 core wouldn't exactly be an epic undertaking - not after someone else writes the core, and it becomes implemented in a couple of other emulators. I agree that SMS Plus is damn near perfect now, before it SMEG was about as good but had no saving. Still, if you can make it better thanks to an excellent new Z80 core, why not?

Of course as Meta said its still up to the coders to decide what they want to do. If nobody wanted to tinker with SMS Plus ever again, I'd be content with that decision as well.

[wraggster]

any news on the progress on the 68k cores ??

[fox68k]

Well, my 68k core is nearly completed :)

Interesting features available now:

- Accurate opcode timing (even MULX, for DIVX 5% inaccurate timing).
- Undocumented flag calculation (CHK instruction).

Not implemented yet:

- xBCD instructions.
- ADDX y SUBX instructions.
- Partial hardware interrupt support.
- Some API functions (set_register, fetch, peek, poke).
- Some capabilities like custom interrupt handling (for NeoCD/SDL DC).

Not tested yet:

- Roughly 40% of implemented opcodes.
- Hardware interrupt handling (some code left as i pointed above).

I have tested some little programs and it worked successfully, like the following one. It sorts a table of integers by the bubble sort algorithm:

************************************************** *******
Bubble Sort example: Numbers
************************************************** *******

absolute
org $500

zero equ $0
one equ $1

* Bubble

start lea.l e_table,A1 * End of the table
bubble lea.l table,A0 * Initialize table pointer
move.b #zero,D1 * D1 change flag

contb move.b (A0)+,D2 * One element
move.b (A0),D3 * Next element

cmp.b D2,D3 * Compare
blt greater * D3<D2
bra test * D2<=D3, do not change

greater move.l A0,D0 * \
sub.b #one,D0 * } recover the pointer
move.l D0,A0 * /
move.b D3,(A0)+ * D2>D3
move.b D2,(A0) * invert and go forward
move.b #one,D1 * Flag change
bra test

* Miramos a ver si acabamos o no
test cmpa.l A0,A1 * Compare with the end
beq endtab * Finish
bra contb * Continue with the bubble

* Changes?
endtab cmp.b #one,D1
beq bubble * There was changes, come back to start

* Program end
endp jmp endp

* Data initialation

table db 5,7,8,5,6,3,2,1,1
e_table db 0

end

I know there is not too much yet, but i hope to finish it (with all the required capabilities) within the first half of september.

Greetings.

P.D: Wraggster, it'd be nice if you post this in the front page. Thanks.

[wraggster]

nice to hear of the progress :)

[Hola]

Its great to know that Genesis and NeoCD will have more than enough power to be fullspeed now.

[quzar]

Its great to know that Genesis and NeoCD will have more than enough power to be fullspeed now.

Dont jump to conclusions. I=There is no way of knowing how much faster the asm core will be than stef's c68k.

[Hola]

True but the new Z80 comes out and this new core is gonna be faster or so its said. So with the new Z80 and the new Sh4 there should be plenty enough power to emulate these 2 systems perfectly.

[Alexvrb]

True but the new Z80 comes out and this new core is gonna be faster or so its said. So with the new Z80 and the new Sh4 there should be plenty enough power to emulate these 2 systems perfectly.
Maybe so. But what he said still holds true... you're not coding the cores or the emulators in question, so how can you automatically assume these things? Basically let's just wait and see.

[Hola]

I'd beat $50. NeoCD is already fullspeed and genesis needs about 8% more speed and a better sync on music.

[quzar]

By the fact that you just called it 'the new Sh4', at least i can infer that you have no actual basis for those statements other than loose conjecture of what you think things mean.

Not to say that it may not be true, its just that you arn't the one in a position to be making statements like that.

edit: damn, i posted this like an hour ago, but forgot to hit send :-X alex beat me to it =P.

[DemoniusX]

well geez sorry if I gave coders what a "FAN" of emulation would like. its true though, if a new sms plus came out I honestly wouldn't care for it.the reason is because its perfect enough for me to enjoy, I don't care for FM sound cuz sms sound has too much HIGH PITCH in it., but having played the actual sms I don't see a difference. I care if a nester version comes out because the control lag was bad and the button setup sucked for games like "track and field" or "american gladiators" not to say those are find titles but I play them now and again cuz hey, I love the gray box. Neo cd is nice if we had sound fx in it, I would be happy but like you guys say Coders want what coders want. oh well that said back to playing mega man and bass on my GBA SP.

[fox68k]

Since looks like everybody is talking about the speed of the cores, i took a moment to do a speed test. 8)

First, you have to take in account the core is not completed, and i have not done any optimization yet, so consider it as VERY PRELIMINARY, only to have a light idea about performance.

The program chosen is the following. It is a simple program to calculate prime numbers:

main MOVE.L #10,D0 ; first number to analize
cont ADD.L #1,D0
BSR prime ; jump to prime routine
CMP.B #$FF,D4 ; if D4=FFh -> prime number
BNE cont ; if not prime number, jump to next number

isprim MOVE.L D0,D5 ; result from routine to D5
CMP.L #60000,D0 ; if result is greater than 60000 exit program
BLT cont ; if not, continue

final BRA.S final


************************************************** ******************
* prime - Returns if the number is prime or not
* D0 - number to analize (parameter)
* Returns D4 equal to FFh if prime, otherwise it is not prime
************************************************** ******************

prime MOVE.L #1,D1 ; D1=1

loop ADD.L #1,D1 ; increment D1
MOVE.L D0,D3 ; move number to analize to D3
DIVU D1,D3 ; divide numbers
ASR.l #8,D3
ASR.l #8,D3
CMP.l #0,D3 ; look if remainder is equal to zero
BNE loop ; if not, continue
CMP D0,D1
SEQ D4
RTS

END

Cycle slicing sent to the "emulate" function is 400 (the longer the better because increases throughput).

I put it inside a for loop and i timed the job with the KOS function timer_ms_gettime.

The result was a roughly 100 MHz 68000 emulated CPU.

Anyway emulation speed depends upon several factors and this result could change notably in other circunstances (other instructions, other cycle slicing, etc).

I read some lines from Stef D saying it could be possible to make a Z80 emulator running at 40/50 MHz in C. I know Z80 and 68K are different, but, again, consider this info carefully to evalute performance.

Cheers.

[Hola]

So your 68 runs at 100 and stef's ran at what?

[Stef]

I believe C68K speed was ~ 50 Mhz (a bit more) ... so Fox68k ASM core seems to be 2 times faster here.
But as Fox68k mentionned, comparaison depends on severals factors (here the loop test contains a DIV instruction which eat many cycles on a 68000 CPU)... we should wait for a reals conditions test to be sure about performance... 2 times faster than C68K would be really nice :)

[ron]

Hi. There was a long time without pass over here. Actually I have a little bit of time more and this is my idea. ;D ;D

I need somebody *8) helping me porting a common ATARI ST emu to the DC. *;D

As I mentioned time ago, the castaway means a nice bet for porting due to the SDL implementation. All GP-32 owners are very happy running the emu with games and progs. Why can't we have a port too ?
OK the original project is here: http://castaway.sourceforge.net/st.html

And also a lot of references and docs about the Atari ST.

My Idea is: Make a port called DCaSTaway, but the most important challenge is to use the cores developed in this thread. Our team had not success because all of our were really busy, so, this is a great opportunity for a nice autum, running ATARI ST on DC with your M68K CORES.

Also there are more opensource ATARI ST emus that can be easily ported to the DC, our conclusions between HATARI, ARANYM, CASTAWAY, STonX, PacifiST, STeem, WindSTon, and others was castaway due to the SDL. Most of them uses Open68K core, thats the key of the project. I have readed that your cores can accurate 100 Mhz.

Tech DATA:

The ATARI 520 ST. CPU M68000 at 7,8336 Mhz.
RAM 512 Kb + 192 Kb ROM
Video: 640 X 400. Monochrome 320 X 200. 16 colours. 640 X 200. 4 Colours
Sound. AY-3-8910 3 Channel FM
3 1/2 " Floppy Disk Drive , 320 & 720 Kb
Expansion : Midi In / Out. Centronics, Serial, Floppy, HD, Mouse and Joystick

NAME * 520 / 1040 STf / STfm
MANUFACTURER * Atari
TYPE * Home Computer
ORIGIN * U.S.A.
YEAR * 1986
KEYBOARD * Full stroke keyboard with numeric keypad, editing keypad and 10 function keys
CPU * Motorola MC 68000
SPEED * 8 mHz
RAM * 512 KB (up to 4 MB)
ROM * 32 KB with TOS on disk / 192 KB with TOS on ROM
TEXT MODES * 40 or 80 chars. x 25 lines (bitmapped graphics)
GRAPHIC MODES * 16 colors among 512 (320 x 200) / 4 colors among 512 (640 x 200) / monochrome (640 x 400) this last mode needs a special monitor.
COLORS * max. 512
SOUND * 3 voices + 1 noise channel, 8 octaves (Yamaha YM-2149)
I/O PORTS * Cartridge, Midi (in, out), Centronics, RS232c, Hard Disk, Floppy disk, RGB, Joystick, mouse
BUILT IN MEDIA * 3.5'' disk-drive
OS * TOS + GEM


More info: * http://linuxgazette.net/issue73/arndt.html
http://www.lowendmac.com/clones/atari.html
http://www.atarimuseum.com/computers/16bits/stmenu/atarist.htm
http://www.atari-st.lovely.net/

THANK YOU

[ron]

ATARI ST DOCUMENTATION

http://www.atari-st.lovely.net/atari-st-docs/index.html

[quzar]

iirc 138 is already working on a port of CaSTaway.

what ever happened to the m68k core you were working on?

[ron]

The idea didn't go ahead , we had not enough time and were very busy, actually i'm impressed about the work you have done. I'm glad to see that iirc138 is working on the castaway port, anyway congratulations for maintaining this thread with lots of hours of great works and thank you .

Can you please give us more information about that port of onethirtyeight ? Your info is really appreciated

[ron]

Congratulations Stef, I know your core is just AMAZING !!!!! should be nice to have your core running on a computer emu for DC.

[OneThirty8]

Can you please give us more information about that port of onethirtyeight ? Your info is really appreciated
My port doesn't work... that's about all the info there is at the moment. I think I was running out of memory. I've been working on a port of Wolfenstein3D/Spear of Destiny lately, and put CastAway on the back burner. The plan ATM was to try starting over on CastAway, starting from the GP32 port. That version is based on CastCE which is supposed to have more features than the original, which is what I was working from.

Anyway, I just thought this would be a cool emu to have, and one that some people wanted, which is why I started working on it. If you can get it working, don't feel like you're stepping on any toes. I'm afraid I won't be much help, though. I'm not very experienced with C, and half the time I have no clue what I'm doing anyway. ;D I just keep plugging away at stuff until I get it to work. I may also take another look at Hatari and see if I can get anything going there. Some stuff would have to be rewritten, but that might be another candidate.

[ron]

dear OneThirty8 and other interested people. Let's join our knowledge and let's share and join in a team to cover that purpose, one ST emu for the DC.
I'll be waiting your comments. Thank You

[quzar]

I'm not very experienced with C, and half the time I have no clue what I'm doing anyway. ;D *I just keep plugging away at stuff until I get it to work.

You and i have something in common ;)

[fox68k]

My new SH asm core is almost complete. Here is what is new:

- 100% opcodes implemented.
- Nearly 60% opcodes tested.
- Interrupt handling support implemented.
- Exception processing implemented (even group 0).
- Few optimizations performed.

More news about progress soon.

Ron, i could help you in your idea about the ST emu covering m68k emulation ;) but my core has to spent a little more in the oven.

Greetings.

[wraggster]

Thanks for the news :)

[ron]

Great news for my ears. Dear Fox68K, we have to talk about. I'm very interested as I said, in the cores developed over here. Also to count with Stef and quzar and 138 and all the friends with a lot of wishes to have at the end an emu so much like me. We'll be in touch

[Ian_micheal]

My new SH asm core is almost complete. Here is what is new:

- 100% opcodes implemented.
- Nearly 60% opcodes tested.
- Interrupt handling support implemented.
- Exception processing implemented (even group 0).
- Few optimizations performed.

More news about progress soon.

Ron, i could help you in your idea about the ST emu covering m68k emulation *;) but my core has to spent a little more in the oven.

Greetings.

Great news Would you be so kind to Include a version with the HLE stuff included for my project i love to test it out with it. Nothing much i can do but i can post what is needed. Hows the function naming of them are they compatable with M68k or c68k?

Thanks for your work it would greatly help my project.

[fox68k]

Hi Ian,

give me some days to finish some bits.

You could see function naming here (http://www.emumega.com/s68k/doc/fame.html#FunctionReference).

What do you mean by HLE stuff? NeoCD project?

Cheers.

P.D: Excuse me for my reply delay but i am taking some days of holidays.

[BlackAura]

I guess it's supposed to be compatable with FAME, right?

In that case, if we made the PC version on an emulator work with FAME, would it be fairly easy to get the DC version working with the SH-4 one?

[Ian_micheal]

Ok in m68k_in.c we have to have this HLE functions.

/* 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;
}
}


So yes with out this it would not work for neogeo cd.

[BlackAura]

Basically, it's to avoid having the original BIOS image. Instead, the code for an invalid instruction is inserted into the locations where the BIOS functions normally reside. When the NeoGeo CD game calls a BIOS function, it hits the invalid instruction. The emulator then calls some native code depending on which invalid instruction was issued.

[fox68k]

I guess it's supposed to be compatable with FAME, right?

In that case, if we made the PC version on an emulator work with FAME, would it be fairly easy to get the DC version working with the SH-4 one?

Exactly. Fully compatible. API will be the same.

[fox68k]

Ok in *m68k_in.c we have to have this HLE functions.

/* 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;
* * *}
}


So yes with out this it would not work for neogeo cd.


I would like to figure out a pretty way to accomplish that task. I can think of an array of pointers to customize interrupt handling. This is, NULL meaning normal autovectored handling and a function pointer for custom processing.

Tell me about this idea and how good could it be in NeoCD.

And thank you for your GREAT work on the DC emu scene. I hope you find my emu useful.

Cheers.

[Eric]

this is wicked i cant wait to see this update on the emus no offense it was still amazing with Stefs work cause the coders were able to bring emu's more speed and its thanks to you 2 for these great updates and hopefully in the future we are able to bring more to emu's like a fullspeed SNES emu and i know M68k wont work for SNES but there has to be away of speeding that up

[Alexvrb]

Both SFC and DSNES are already using the same asm CPU core written for DSNES. So unless someone starts working on amazingly hard on optimizing sound or video, don't count on speed boosts for a while.

[ron]

Yesterday CHui and Me have released the first port of DCaSTaway, using OpenM68K core. The emu runs and emulates games 100 % and you can use the mouse and the joy for playing games or software. Many other better things will come up and of course, let's talk about the availability of your M68K cores for SH4. In www.talfi.net and here self you can follow the progress of the emu and download a version to tryout. It's Still very WIP and needs more speed. Actually we're getting almost 85% speed comparing with an original ST. Thats a good new and at the end an ATARI ST EMU for our Dreamcasts. Cheers

[DemoniusX]

now I just need a DC keyboard.

[ron]

I NEED YOUR M68K CORES FOR A GREATEST M68K COMPUTER EMULATOR PROJECT.

Dear friends, is time to ask the experts in M68K and, after seen the ability for porting software and emulators to the DC. I need your help . Please send me a private, for contact.

[Ian_micheal]

I would like to figure out a pretty way to accomplish that task. I can think of an array of pointers to customize interrupt handling. This is, NULL meaning normal autovectored handling and a function pointer for custom processing.

Tell me about this idea and how good could it be in NeoCD.

And thank you for your GREAT work on the DC emu scene. I hope you find my emu useful.

Cheers.

What i need is 5 to 10% more speed from this core c68k gave me fullspeed with out sfx with sfx running it's taking 15%. If the m68k was 5 to 10% better i would be geting near fullspeed with sfx meaning totaly finshed neogeo cd port for dc same speed *and sound. Im not fussed how it's done im going to have to learn the function naming maybe it might be a good idea to show a FAQ chart on how each function is compared to m68k in mame or c68k from stef.

I was thinking about Making neogeo cd work on the pc with your core sounds like a good idea.

I dont want to use any frameskip at all refuse to for this project. We need full frame anmation like 9.3 fighting games need to be smooth and fluid.

[Stef]

I NEED YOUR M68K CORES FOR A GREATEST M68K COMPUTER EMULATOR PROJECT.

Dear friends, is time to ask the experts in M68K and, after seen the ability for porting software and emulators to the DC. I need your help . Please send me a private, for contact.

Mine is always available at http://gens.consolemul.com/download/c68k_src.zip

You'll probably need some help to use it, don't hesitate to ask here :)

[fox68k]

What i need is 5 to 10% more speed from this core c68k gave me fullspeed with out sfx with sfx running it's taking 15%. If the m68k was 5 to 10% better i would be geting near fullspeed with sfx meaning totaly finshed neogeo cd port for dc same speed *and sound. Im not fussed how it's done im going to have to learn the function naming maybe it might be a good idea to show a FAQ chart on how each function is compared to m68k in mame or c68k from stef.

I was thinking about Making neogeo cd work on the pc with your core sounds like a good idea.

I dont want to use any frameskip at all refuse to for this project. We need full frame anmation like 9.3 fighting games need to be smooth and fluid.

I understand your goal perfectly.

Last days i was on holidays so i will try to release my core before next weekend. This way you can take a look at this and how it will perform some operations.

I take note about adding the FAQ chart to my documentation to get my core up easily.

About the PC version i will make some changes in order to support customized BIOS calls in NeoGeo CD emulator.

Cheers.

[ron]

Mine is always available at http://gens.consolemul.com/download/c68k_src.zip

You'll probably need some help to use it, don't hesitate to ask here :)


THX very Much. Let's take a look. I'll tell you whatever. At the moment we're using the last CVS version of OpenM68K with some modifications, and now the speed is amazing.

[warmtoe]

THX very Much. Let's take a look. I'll tell you whatever. At the moment we're using the last CVS version of OpenM68K with some modifications, and now the speed is amazing.

So - could this same 68k core (your modified OpenM68K) be used in the Genesis EMU too?

[wraggster]

makes you wonder if the OpenM68k can be used in other emus that use that core :)

[Ian_micheal]

The ST does not need that fast a core to gain fullspeed. With the c68k core in ST the SDL emu it be a lot faster again.

Run fullspeed and sound on a gp32 for example. I doubt the core is as fast as stefs.

[GPF]

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.


I just tried it out with the latest 9.3 source. But I am upporting it to use kos 1.3 and gcc 3.4.2 with newlib. I got Puzzle Bobble working, with the above c68k source but Metal Slug 1 doesn't work, it crashes after starting to display the first menu screen.
its crashing at c68k/c68k_op2.inc:1052

Wow that did take a long time to compile the c68k :)

I tried it again with the c68k precompiled and Metal Slug 1 works. Is this a problem with the way I compiled the c68k or is the precompiled version a different codebase?

thanks,
Troy

[Stef]

I just tried it out with the latest 9.3 source. But I am upporting it to use kos 1.3 and gcc 3.4.2 with newlib. I got Puzzle Bobble working, with the above c68k source but Metal Slug 1 doesn't work, it crashes after starting to display the first menu screen.
its crashing at c68k/c68k_op2.inc:1052

Wow that did take a long time to compile the c68k :)

I tried it again with the c68k precompiled and Metal Slug 1 works. Is this a problem with the way I compiled the c68k or is the precompiled version a different codebase?

thanks,
Troy

Well, there is not anything special at line 1052 of c68k_op2... a read in memory.
The precompiled version just has some defines uncommented to enable HLE stuff for NeoGeo CD.

[Eric]

do we see some interesting changes since the last version

[Alexvrb]

Who said there's a new version? GPF was talking about his using C68k with the last NeoCD sources.

[Eric]

i meant a the new C68k edited! use appropiate language!

[quzar]

i meant a the new C68k Alexvrb you stupid moron i am sorry i had to say it cause this guy is really pissing me off delete if you want to but this guy thinks he is so damn smart and loves to insult people who may not have the brains for this stuff sorry if i dont have brains Alex
There is no new version of c68k.

[Eric]

oh i thought fox's version is new?

[GPF]

Well, there is not anything special at line 1052 of c68k_op2... a read in memory.
The precompiled version just has some defines uncommented to enable HLE stuff for NeoGeo CD.

Thanks, the new KOS changes required changes to the Makefile and I missed that. I'll give it another try.


oh i thought fox's version is new?

I am only compiling the last source that Ian released on his site. with Stef's c68k cpu, not Fox's. I wasn't able to download Fox's from the last link I could find.

I just wanted to play it again, and wanted to see the improvements made since I stopped working on it.

Troy

[Eric]

Oh okay thanks GPF so whats going on now with this stuff and even though Ian isnt working on Neo Geo CD anymore is it going to be worked on by someone else now sorry if i am offtopic

[Alexvrb]

Thanks for ripping into me for trying to be informative. Should I just let you remain in the dark in the future?

[quzar]

Oh okay thanks GPF so whats going on now with this stuff and even though Ian isnt working on Neo Geo CD anymore is it going to be worked on by someone else now sorry if i am offtopic

ive talked to evilo the ps2 porter, and once the new version comes out for ps2, he is going to point me to where i can modify things to get sfx working.

[evilo]

ive talked to evilo the ps2 porter, and once the new version comes out for ps2, he is going to point me to where i can modify things to get sfx working.


I can already send you what I've done (sound part of the emu) if you want.. Note that FM emulation is consuming a lof of cpu, and I don't speak of the ps2 spu, but the cpu needed to emulate the ym2610 core :(

games with sfx sounds only are ok, but games like bust a move currently have difficulty to reach a constant correct framerate with emulated music running... okay there is of course room for optimisation, but they are ps2 specific now...

then I still have a few others pb, some games don't have sounds, don't know why.. but I also found out that the z80 was overclocked to 6Mhz instead of running at 4Mhz and there is surely some syncho/timing issue between the two cpus...

talking about cpu cycles, and not sound related, note that cycle count for both cpu is not correct for PAL, making the 68000 running at 10Mhz in a PAL console.

[quzar]

I can already send you what I've done (sound part of the emu) if you want.. Note that FM emulation is consuming a lof of cpu, and I don't speak of the ps2 spu, but the cpu needed to emulate the ym2610 core :(

games with sfx sounds only are ok, but games like bust a move currently have difficulty to reach a constant correct framerate with emulated music running... okay there is of course room for optimisation, but they are ps2 specific now...

then I still have a few others pb, some games don't have sounds, don't know why.. but I also found out that the z80 was overclocked to 6Mhz instead of running at 4Mhz and there is surely some syncho/timing issue between the two cpus...

talking about cpu cycles, and not sound related, note that cycle count for both cpu is not correct for PAL, making the 68000 running at 10Mhz in a PAL console.



awsome. you have my email address, so if you could send it to me (or IM me on msn or aim, I would appreciate it)

[guymelef]

this sucks. why doesn't ian want to finish this stuff, and for that matter anyone else? is it true that coding is a cut-throat scene.

[quzar]

im coming out with an updated version of ian's port soon. bugfixes galore. a few performance enhancements to prepare for the addition of a working z80 core.

[Alexvrb]

Working! oh em gee teh aech four ex!

[wraggster]

did anyone get anywhere with mac emulation ?

[quzar]

ron is suppsoedly putting a lot of work into it.

[ron]

Yes, the emu is on the way. The emulator now runs, so i'll have to spent some time implementing the audio , video and IO. Will take a time, at least I got quzar's and chui's help. In other words, Thx.

Note from RON: I do agree with Quzar.

[ron]

On April 30th, 2004, I opened this thread with a lot of illussion and wishes, most of them are completed , others are just to come.

I would like to thank you to: Wraggs, JMD, Mekanaizer, Quzar, BlackAura, Stef, Propeller, Christuserloeser, LyonHrt, Chui, Fox68K, OneThirty8

Those DC Coders, are really who have created, designed, apported, helped and supported M68K development for DC, and DCaSTaway, Neo4All, UAE4all, NeoCD, and Genesis Plus /DC emulators. To Stef and Fox my personal congratulations.

As you can se in the 42 pages lenght of this thread, I want to make clear that I absolutely don't approve the attitudes and aptitudes of Reaper/Ian Micheal, I disapprove totally what he has done, being the break of the DC Comunity. I hope that this doesn't mean an one step back in the development of this thread, but the triple A, plus the NeoGeoCD already is reality and that is what matters.

[Starscream]

It's a very cool development, I never expected to play Neo-geo on my DC. Or that someone would port UAE to it.

Now even Mac emulation is supposed to be coming, that's great. Any concrete plans for the x68000 yet? To my knowledge there is only one open-source emulator available for it.

[BlackAura]

Fox68K - Having a slight problem with the latest FAME. Basically, the damned thing doesn't work. Only tried the PC version thus far, but the newer version crashes, while the older version works fine. Just shows how long it's been since I had a chance to do some serious work on GenPlus, doesn't it?

Older version is 1.2 (2004-12-17)
Newer version is: 1.23 (2005-04-05)

I can give you a copy of the code if you like. Basically, it's a (slightly) modified version of Stef's GP/DC CPU interface and the FAME interface that I did before.

[BlackAura]

Doesn't work with 1.21 (2005-02-19) either. I'm using the x86/Linux version at the moment, in case you were wondering. Not even tried the DC version. So, something that you did between 1.2 and 1.21 appears to have busted by copy of GP/DC...

Some more info. According to GDB, it crashes at m68k_get_cpu_state, which doesn't appear to be anything publically accessible, so I assume it's some internal FAME thing.

Backtrace:
#0 0x0805b4a2 in m68k_get_cpu_state ()
#1 0x080747dc in m68k_get_cpu_state ()
#2 0xb7eed330 in timezone () from /lib/tls/i686/cmov/libc.so.6
#3 0xbffff7b4 in ?? ()
#4 0xb7eec038 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5 0xbffff688 in ?? ()
#6 0x080525a3 in M68K_Exec (cycles=64356352)

Just looking at that, I get the impression that there's some stack corruption going on there. Either that, or something wasn't built with any kind of debugging support.

I don't suppose you have a working cpu68k.c for Genesis Plus laying around anywhere, do you?

[fox68k]

Very few changes have been done from 1.2 to 1.23 in the PC version, so i guess the problem is caused by a tiny detail by my own. I guess it should be any of the changes from 1.2 to 1.21:

- set_irq_type function changed for flexible use.
- Pointer to data structure parameter removed from memory handlers to increase throughtput.

Both of them affect the way the old code works (in the set_irq_type function and in the memory layout definition).

I leave you here my latest cpu68k files (http://perso.wanadoo.es/orayo/gp/cpu68k.zip) and my own GP sources (http://perso.wanadoo.es/orayo/gp/gpdc-pvr5c-fame.zip) for testing purposes.

Cheers.

[fox68k]

One last thing to be considered. I did not update the GP sources with the latest fame header, but since i do not call set_irq_type function anymore in my GP code, the new one is not needed (stuff related with define's used by set_irq_type in fame.h).

[BlackAura]

Thank you very much. I'll see if I can get this thing running again.

Edit: Alright, it works fine. Interestingly, your version has everything prefixed with "f68k", but everything you've given me is prefixed with "m68k", so I had to do a little bit of renaming. There certainly aren't any name clashes in the GP/DC code, because Musashi is long gone.

Doesn't speed things up much though. I suspect that we're being limited by other bits - the video rendering (not the CPU side stuff - the PVR itself isn't keeping up) and the sound output. Both need major work.

[fox68k]

Thank you very much. I'll see if I can get this thing running again.

Edit: Alright, it works fine. Interestingly, your version has everything prefixed with "f68k", but everything you've given me is prefixed with "m68k", so I had to do a little bit of renaming. There certainly aren't any name clashes in the GP/DC code, because Musashi is long gone.

I forgot that bit, sorry.


Doesn't speed things up much though. I suspect that we're being limited by other bits - the video rendering (not the CPU side stuff - the PVR itself isn't keeping up) and the sound output. Both need major work.

Agree. We need to speed up the slower parts of GP to get the best from the CPU cores.

Thank you so much for your work BlackAura.

[BlackAura]

We have a discussion about GP/DC going on over at DCEmulation, if you want to drop by.

Thanks a lot for your work on FAME too. The thing absolutely flies...

[Darksaviour69]

i know i'm bumping an old topic (i'm an admin i can ;) )
but this the biggest dcemu topic of all time!

[quzar]

This topic is the sole reason I have this page open all the time along with dcemulation. Before it I only visited dcemu instead of being a permanent resident =P.

[JeffTweedyIsGod]

How did this topic get so large, I'm curious. Would anyone care to give a breif summary? 442 posts is a little hefty to read through.

This is a stupid request.

[Christuserloeser]

How did this topic get so large, I'm curious. Would anyone care to give a breif summary?

Because emulating something has never been easy ;)

=> Very brief summary <=