New Super Famicast & NesterDC SE releases imminent

[Kamjin]

sure no prob,

for instance in Â*video.c video_draw_spr()

Â* Â* Â*if (flipy) Â* Â* Â*// Y flip
Â* Â* Â*{
Â* Â* Â* Â* Â* Â*dy = -8;
Â* Â* Â* Â* Â* Â*//fspr += (code+1)*128 - 8 - (sy-oy)*8; orig line
Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â*
Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â*fspr += ((code+1)<<7) - 8 - ((sy-oy)<<3);
Â* Â* Â* Â* Â* Â* Â* Â*}

I had to add brakets to maintain the proper order, since the compiler
doesn't treat the shift like a normal math routine..
if I just left (code+1)<<7 - 8, it would perfrom the 7-8 first.. and
here (sy-oy)<<3 if the brackets would be left out it would shift
the entire equasion and not just sy-oy. when you swap the mults
for the shift be careful to bracket them..

just in case you're not fammiliar with shift ops.. they're an east way
to do div/mult, shifiting simply shifts over the bits by the count you
specify.. each shift is a power of 2 so
<<1 = multiply x2 Â* Â* Â* Â* Â*>>1 = divide by 2
<<2 = *4 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* >>2 = /4
<<3 = *8 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* >>3 = /8
<<4 = *16 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* >>4 = /16
<<5 = *32 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* >>5 = /32
<<6= *64 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* >>6 = /64
and so on..

example:
0x05<<1 Â*which is the same as 5*2
5=00000101b shift all the bits left by one
it becomes 00001010b = 10 or 0x0a
and the opposite
8>>1
8=00001000b shift all right by 1
it becomes 00000100b = 4

to handle non power of two.. for instance 640
as in a plot pixel routine.
y=y*640
we divide the 640 into powers of 2
512 and 128 Â*(512+128=640)
*512 is the same as <<9
*128 is the same as <<7
so y=((y<<9)+(y<<7)); Â*//this saves 1-2 cycles over the mult

For divsion just shift the other way, but
y=y/640 isn't the same as y=((y>>9)-(y>>7));
so just use shifts for div's when using powers of
2.

[scherzo]

Well, I stayed up 'til 3am last night and basically ditched work today(don't worry, it's cool). I've got it all to compile but that doesn't mean that it's working. Right now I just get a black screen, no runtime errors. I can, however, see the FPS display. So part of it is working. I've quadruple checked things that were required to glue it all together. I also tried turning off the speed hacks CPU_SHUTDOWN and VAR_CYCLES. Nothing. I wrote Marcus to see if he has any insight. No response yet. There's a whole bunch of asm that's disabled in #if 0 blocks. Before I go touching anything in the asm and editing things I have no clue about, I wanna see what Marcus says first. I'll keep you guys posted.

[wraggster]

Lets hope for a quick fix to whatever is causing you problems

[mastakilla]

minor setback. Scherzo will overcome.

[wraggster]

hey i wonder how far Scerzo has got since we last were online

[Kamjin]

Probably re-wrote the whole thing in assembly by now
with the burst of energy he's got Â*;D

[wraggster]

hey hes a great coder, and learning fast too

[Ian_micheal]

[quote author=Kamjin link=board=dcemu;num=1082494155;start=90#100 date=05/14/04 at 20:52:12]sure no prob,

for instance in Â*video.c video_draw_spr()

Â* Â* Â*if (flipy) Â* Â* Â*// Y flip
Â* Â* Â*{
Â* Â* Â* Â* Â* Â*dy = -8;
Â* Â* Â* Â* Â* Â*//fspr += (code+1)*128 - 8 - (sy-oy)*8; orig line
Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â*
Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â*fspr += ((code+1)<<7) - 8 - ((sy-oy)<<3);
Â* Â* Â* Â* Â* Â* Â* Â*}

I had to add brakets to maintain the proper order, since the compiler
doesn't treat the shift like a normal math routine..
if I just left (code+1)<<7 - 8, it would perfrom the 7-8 first.. and
here (sy-oy)<<3 if the brackets would be left out it would shift
the entire equasion and not just sy-oy. when you swap the mults
for the shift be careful to bracket them..

just in case you're not fammiliar with shift ops.. they're an east way
to do div/mult, shifiting simply shifts over the bits by the count you
specify.. each shift is a power of 2 so
<<1 = multiply x2 Â* Â* Â* Â* Â*>>1 = divide by 2
<<2 = *4 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* >>2 = /4
<<3 = *8 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* >>3 = /8
<<4 = *16 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* >>4 = /16
<<5 = *32 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* >>5 = /32
<<6= *64 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* >>6 = /64
and so on..

example:
0x05<<1 Â*which is the same as 5*2
5=00000101b shift all the bits left by one
it becomes 00001010b = 10 or 0x0a
and the opposite
8>>1
8=00001000b shift all right by 1
it becomes 00000100b = 4

to handle non power of two.. for instance 640
as in a plot pixel routine.
y=y*640
we divide the 640 into powers of 2
512 and 128 Â*(512+128=640)
*512 is the same as <<9
*128 is the same as <<7
so y=((y<<9)+(y<<7)); Â*//this saves 1-2 cycles over the mult

For divsion just shift the other way, Â*but
y=y/640 isn't the same as Â*y=((y>>9)-(y>>7));
so just use shifts for div's when using powers of
2.


[/quote]

big thanks just wondering if this is the complete post over at dcemu you said some thing about it being fully complete.

[wraggster]

any newsworthy updates Scherzo

[scherzo]

Yeah, I'm ready to make a release, I just want to test self booting. I tried last night but I made several CD coasters. I think it's because I'm using the newest version of Nero. I've read that some people can no longer burn good selfboot CDs after they installed Nero 6 and above. I'll get it worked out.

Other than that, the asm core is working. The speed increase is not as big as I would have wished. It's still slower than DreamSNES, but at least more games are playable with sound enabled. I also put in the option to change the sound quality. The lower settings produce rather buggy sound. I thought this was because of the asm core but it happened in the C core too. I put in mouse support a long time ago so you all can draw retarded pictures with Mario Paint or something. You can also disable the various background and sprite layers for added speed when certain layers are not that important.

After this release is out the door, I plan to rewrite the graphics rendering code in assembler and possibly use the Dreamcast ARM sound CPU to emulate the SNES sound CPU.