New Super Famicast & NesterDC SE releases imminent

[Christuserloeser]

[quote author=scherzo link=board=dcemu;num=1082494155;start=45#49 date=05/12/04 at 15:44:53]Now I finally understand the DSNES team's silence.[/quote]

Me too Â*


...a bit late and a really really bad start too, but I'd like to say "Welcome" to you to the DCEmu message boards! It's nice to see you round here!


PS:

I'd love to see a NesterDC update done by you with a new menu system and maybe new mappers and a slight speed up or so! I hope that you'll be able to contact Takayama Fumihiko so he could help you working on it.

Wish you all only the best,


Chris

[scherzo]

Thanks for the welcome. I recently wrote both Ken and Takayama emails formally asking for their blessings. Ken's email address is gone and I haven't heard from Takayama yet.

I also wrote a message to Marcus Comstedt in the DCDev Yahoo Group to refresh his memory about our email conversation many months ago. I had previously asked him if he would consider allowing me to use all or parts of DreamSNES to improve Super Famicast and, as I remember correctly, he said he'd talk about it with the others. I'm anticipating he'll say no, but it is worth a try. Even though DreamSNES and Super Famicast use different snes9x versions, I'm sure it could help. We shall see.

[Kamjin]

Ian,
When I get back home I'll take a look over the code, and see if there's anything obvious, but I've already looked it over quickly and
didn't see anything that stuck out..

Scherzo, Yup the KOS threads do appear to eat alot of time, also
I've noticed that accessing the vram while not in a Vblank, even
when just writing frames eats alot of time. I guess this is probably
why a PSX emulator would be capable of reaching descent speeds..
If the 3d calls are translated directly to PVR functions.. there's no
penalty.. (Sorry just a little brainstorming)..

Back to the topic.. I had noticed alot of Byte access in the emulated
DMA engine, It would be a good idea to check , and get an idea of
the avrage tranfer sizes the functions are doing. Then see if it's
worth converting them to Dwords xfers, if they're used heavily
enough that might gain you a few hundred cycles /frame.

[scherzo]

Thanks, Kamjin, I'll check the SNES DMA reads out.

[scherzo]

I might have some very good news soon...

[wraggster]

oh yeah

a pdrom image for any new release would be cool

[scherzo]

This is better than that.

Here are my email transcriptions with Marcus Comstedt

"scherzox" <[email protected]> writes:


>> Hi, I'm Scherzo of Super Famicast. I talked to you quite a while back
>> about coding tips, DreamSNES status, and the possibility that I could
>> integrate some of what you've done with DreamSNES into Super Famicast.
>> You said you would talk with the rest of the team regarding this. I
>> was just wondering if you guys have considered it. If the answer is
>> no, that's fine.


Hi!

Thanks for reminding me. We discussed this and decided that the best
course of action would be to simply contribute our stuff to the
regular snes9x distro. That way anyone can use it just like the other
snes9x code.

We are in the process of commiting the code to the snes9x CVS, but
this will take some time as there is a bit of cleanup needed. 
I can send you the CPU core right away if you like. Is there any
other part you were immediately interrested in?


 // Marcus

Scherzo <[email protected]> writes:


>> Interesting. So you'll be merging in your sh4 cpu core and other sh4
>> specific code into the official snes9x code just in case someone,
>> besides us DC devers, needs to compile for that platorm? Pretty cool.


Yeah. Only the CPU core (and SA1) is SH4 specific, the other stuff is
written in C(++).



>> Yes, it would be great if I could get my hands on the cpu core before
>> you commit those changes.


Ok, I'm attaching it to this mail.



>> Also, if you have written any optimized sh4
>> routines for the functionality in gfx.cpp and it's related files, the
>> tile and sprite renderering routines, that would be nice too.


Nope, there we basically use the original C++ code as it is. Except
that we #ifdef out the parts that aren't used to avoid some runtime
checks.

I did a bugfix to the original sprite renderer (which dealt with
sprites in high-res mode, you could only see the bug in Tokimeki
Memorial's menu screen), but no optimizations that I can remember.


 // Marcus

Again, thanks a lot. I really can't wait to try this out when I get home tonight. Do you think I'll have many problems dropping this into the 1.42 source tree that I've been using for Super Famicast? Do you know of any global functions or variables that have been added since 1.42 that is referenced in the code you provided? Of course, I'll find out when I get home and try it out, but I'd thought I'd just ask.

 - Scherzo

[wraggster]

Holy smoke this is mAjor news, can i post on the front page?

Nice going my man

and a big thanks to the Dreamsnes team.

[WaCk0]

whoooa!!

Amazing news. Thats all that DC scene needs... teamwork! ;D

[wraggster]

Had to post this great news