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.
Printable View
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.
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!
I prefer that ;)Quote:
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 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)
[quote author=Christuserloeser link=board=dcemu;num=1083323639;start=45#46 date=05/07/04 at 00:02:16]If m68k SH4 would take the CPU time under the 50% mark even SegaCD and AMIGA500 emulation could be possible!
[/quote]
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...
I don't understand why you're saying that ...Quote:
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.
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 !
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.
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...
[quote author=Ian_micheal link=board=dcemu;num=1083323639;start=45#54 date=05/07/04 at 10:01: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. Â*[/quote]
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 ;)
[quote author=BlackAura link=board=dcemu;num=1083323639;start=45#55 date=05/07/04 at 11:45:36]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.
[/quote]
Yeah, optimise the M68K core in Genesis Plus will make the frame skip option more efficient ;)
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...Quote:
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.
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 ;)
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 ...Quote:
... 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.
I guess the code size overhead kill optimisations here :-/
But we can always check in olders MAME FM emulator version to gain some frame ;)
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".Quote:
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...
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 :-/
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.
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.