GenesisPlus DC DL's + Discussion

uncleben · Post by **uncleben** » Fri Dec 03, 2004 12:31 am

Sorry if this has been asked before,
but why exactly does it take so much more CPU time to emulate a Z80 than a 68k.
I thought the Z80 is much simpler a processor than a 68k?

uncleben

DcSteve · Post by **DcSteve** » Fri Dec 03, 2004 1:01 am

The Z80 is still the slowest emulated part, taking up at least as much CPU time as the software rendering does, or as much CPU time as gained by switching to C68k instead of Musashi. Since we dont have a working profiler, we cant accuractly ssee how much CPU time each part is using. Ba guesses that c68k in practice, is nowhere near fast enough to run at 12MHz and leave enough time left over to emulate the rest of the system, which includes the Z80.

Post by **Quzar** » Fri Dec 03, 2004 1:09 pm

He already knew that. uncleben, i am not sure if this answer is completely correct, but it seems fro what ive looked at that all the fast z80 cores out there are written in assembly (since the PC is usually the topic system). That leaves the ones made in C to have the goal of high accuracy instead of speed. And they are therefore slower.

abydos1000 · Post by **abydos1000** » Fri Dec 03, 2004 5:26 pm

I would imagine that writing something like that in SH4 assembly would not be trival (and unfun). I doubt the people that wrote some of these things in x86 or PPC assembly had a whole lot of fun doing it.

I guess what is "fun" is all relative though.

Alexvrb · Post by **Alexvrb** » Fri Dec 03, 2004 7:36 pm

quzar wrote:He already knew that. uncleben, i am not sure if this answer is completely correct, but it seems fro what ive looked at that all the fast z80 cores out there are written in assembly (since the PC is usually the topic system). That leaves the ones made in C to have the goal of high accuracy instead of speed. And they are therefore slower.

Accuracy as a goal, but also perhaps they simply didn't CARE about speed regardless, both because PCs tend to have enough speed, and because of the availability of x86 asm cores. Not to mention that the compiler "of choice" for the Dreamcast tends to kind of suck at optimizing code. Even so, a really well written C core would provide a good boost. Something in SH4 asm would potentially yield even better results, but who would undertake something like that just for Z80? I'm looking forward to Stef's future C Z80 core. He did a good job with C68k, even though it obviously is new and not perfect yet.

uncleben · Post by **uncleben** » Sat Dec 04, 2004 12:31 am

okay that makes sense

DcSteve · Post by **DcSteve** » Sat Dec 04, 2004 6:51 pm

out out of curiosity, how much of the incorrect gfx blending or gfx fixes when it comes the playable chars, have been corrected/fixed/recoded since the last source release..

Also, BA you have a very important pm coming with something that could make you, and many other people extremely happy.

BlackAura · Post by **BlackAura** » Sat Dec 04, 2004 7:56 pm

Well, the sprite corruption should be gone (not tested yet, but I've made the appropriate modifications). The tile cache code still needs cleaning up / speeding up though.

Assuming everything goes to plan, per-line scrolling should end up working, as should mid-frame palette changes. That'll fix most games that have minor graphics issues.

Link2k4 · Post by **Link2k4** » Sat Dec 04, 2004 10:33 pm

is it possible to add saving to it too?not to be like "hey put this and this" on it, I was just wondering if you could do that.

BlackAura · Post by **BlackAura** » Sat Dec 04, 2004 11:05 pm

At this stage, no. Find me some documentation on how the saving works, and I might do it.

Clessy · Post by **Clessy** » Sat Dec 04, 2004 11:50 pm

What do you mean BA. Saving for DC find you documention on DC saving?
Cause you could probably try one of like billion open source PC emus if your just looking for PC saving code for genesis.

InternetAddict · Post by **InternetAddict** » Sun Dec 05, 2004 12:45 am

BlackAura you truly are creator of a master piece of emulation software or port of a software rather

You keep dcemulation exciting and worth visiting for me, I thank you for that. Genesis Plus/DC PVR preview 3 has to have the most potential like maybe in future online kaillera type play just imagine that would be awesome. I check everyday to see if you've released anything yet hehe

DcSteve · Post by **DcSteve** » Sun Dec 05, 2004 12:53 am

he wanted to have a release ready by the end of this month, with the contribution i sent him from mekaniazer, it is possible that a release can be done earlier.

InternetAddict · Post by **InternetAddict** » Sun Dec 05, 2004 1:03 am

sweet!!!!

DcSteve · Post by **DcSteve** » Sun Dec 05, 2004 2:52 am

Generator, which is portable- Supports SRAM saves and saved states (which are compressed) maybe u can take the code instuction from there?

This is the closet tech instruction i can find...

http://home.hiwaay.net/~jfrohwei/sega/genesis.html

look under sram

Clessy · Post by **Clessy** » Sun Dec 05, 2004 3:18 am

Yeah thx for mention where you got those ideas from steve *rolls eyes*

BlackAura · Post by **BlackAura** » Sun Dec 05, 2004 3:59 am

Cause you could probably try one of like billion open source PC emus if your just looking for PC saving code for genesis.

Not really. Looking at Gens, for example, doesn't really reveal too much about how the saves work. They overlap the ROM in memory (which makes sense, because the save RAM is in the cartridge), there's some kind of switching mechanism to switch between ROM and SRAM (which I can't find), and there's a load of code to work out if the CPU is trying to read/write SRAM or the ROM.

Two problems - I can't isolate enough of it to understand how it works. I can't implement it without a (massive) drop in execution speed. At least, not the same way that Gens does it.

Same goes for other emulators - I can't just copy the code across, and generally the code is not particularly obvious because there are bits and pieces strewn throughout the emulator. If I actually knew what pieces I was looking for, I'd likely be able to find them all, but I don't, so I can't.

he wanted to have a release ready by the end of this month, with the contribution i sent him from mekaniazer, it is possible that a release can be done earlier.

Doubtful. There's still a lot of work to do.

This is the closet tech instruction i can find...

http://home.hiwaay.net/~jfrohwei/sega/genesis.html

look under sram

That's scroll ram, which is part of the VDP.

Post by **Quzar** » Sun Dec 05, 2004 5:05 am

although this might be obvious or not helpful at all, maybe just look for any writes to adresses within the cartridge address space? that would automatically have to be SRAM since ... afaik, the ROM is...well rom =P.

BlackAura · Post by **BlackAura** » Sun Dec 05, 2004 6:11 am

I've managed to cobble together enough information (from around five different sources, along with some experimentation) to get basic saves working. Just a few problems with it...

First, it works for Sonic 3, but not Sonic 3 and Knuckles, because it relies on the ROM header. To load the save, I need to know that the game has one before the game starts. The Sonic 3 ROM has that information, but the Sonic and Knuckles ROM does not (because it doesn't have any). When you combine the ROMs, the Sonic and Knuckles ROM goes first, and thus no save is detected. It will also not work if the ROM header is incorrect, or if it doesn't specify that the cartridge has save RAM.

Second, it will slow down emulation for any ROM greater than 2MB.

Third, it will only work for games that use the same kind of save RAM as Sonic 3. Not all games do. Games that use an EEPROM just won't work.

The first one can be partially fixed using a ROM database, but I'd need a complete list of every game that uses battery-backed RAM in the cartridge. The others can't be fixed.

DCmad · Post by **DCmad** » Sun Dec 05, 2004 4:01 pm

May i presume DreamSNES docs don't help at all?