SNESDEV

I just landed on this site while looking for software debugging info on the 65816

http://6502org.wikidot.com/software-65816

The wiki  is more about the 6502 but is some pages dedicated to the 65816.

++ Lint

It’s been a while that I’m working on various optimisation to some functions to copy tables of data. I found out that the C compiler wasnt optimizing it at all. Here is the original piece of code :

    counter = data[frame].spriteNum;
    for(i=0; i<counter; i++) {
        //x = data[frame].data[i].nameLow & 0x0f;
        //y = data[frame].data[i].nameLow >> 4;

        spriteData.data[i+offset].HPos =
            data[frame].data[i].HPos + 0x76;
        spriteData.data[i+offset].VPos =
            data[frame].data[i].VPos + 0x80;
        spriteData.data[i+offset].nameLow =
            data[frame].data[i].nameLow;
        spriteData.data[i+offset].priority =
            data[frame].data[i].priority;
        spriteData.data[i+offset].color =
            data[frame].data[i].color;
    }

    // set big sprite
    spriteData.prop[offset].properties = 0xaa;
    spriteData.prop[offset+1].properties = 0xaa;

This was consuming almost 25% of the cpu time between each Vblank. The new code is going about 30 times faster :

    heroPreparedSpriteData *myData;
    OBJECTData *myObjectData;
    OBJECTData *currentSpriteData
    OBJECTProp *currentSpriteProp;

    // init with base address
    myData = data;
    // set to current frame
    for(i=0; i<frame; i++) {
        myData++;
    }

    // init with base address
    currentSpriteData = (OBJECTData*) &spriteData.data;
    currentSpriteProp = (OBJECTProp*) &spriteData.prop;
    // set to current frame
    for(i=0; i<offset; i++) {
        currentSpriteData ++;
    }

    counter = myData->spriteNum;

    // init start of the data array
    // we assume we always starts at 0 index
    myObjectData = (OBJECTData*) &(myData->data);

    for(i=0; i<counter; i++) {
        currentSpriteData->HPos = myObjectData->HPos + 0x76;
	currentSpriteData->VPos = myObjectData->VPos + 0x80;
	currentSpriteData->nameLow = myObjectData->nameLow;
	currentSpriteData->priority = myObjectData->priority;
	currentSpriteData->color = myObjectData->color;

	// update myObjectData Adress
	myObjectData++;
	currentSpriteData ++;
    }

    // set big sprite for the 8 first sprites
    currentSpriteProp->properties = 0xaa;
    currentSpriteProp++;
    currentSpriteProp->properties = 0xaa;

C compilers seems to something really handle the table really badly.

So now I’m going to finish writing the sprite routines since now I have acceptable performance going on. Why acceptable ? Because I’m sure there is a relly more effecient way to perform all this. It’s basically just copying data, so I should get myDta in ROM and DMA it to RAM and from there just updating some values like HPos and VPos.

I keep you updated anyway …

See ya, Lint

It’s been almost 5 days that I’m back from vacation.I have almost no time for myself …

Hard time at work since we have a major release on next wednesday. I’m still able to find some time while on the train. So I’m still optimising sprite stuff. I dicovered that the WDC Compiler is very bad at handling structure and tables. It’s don’t optimize the code at all and it’s a real loss of CPU cycle for nothing and finally always recalcaulating the exact same memory offsets.

I’m in the process to completely rewrite that code in pure ASM.

++ Lint

It’s been a while that I haven’t posted anything. So here is a little update on my work.

It’s now almost 2 weeks that I’m working on a better way to handle sprites and trying to do it the most effective way. Thing are starting to work so i might have it finished in about 1 week.

Then I’m not really sure what to do next. I was thinking about implment ennemies with scripting, but I feel like it’s going to be boring for me. The other thing that still need work is the NSF Replayer port. That is going to be a good challenge and something that other people will find interest in it …

That’s all for this time,

See ya later, Lint

It’s been a while I’m busy preparing my “end of July release”. That release may not be the complete level 1 as expected. I have loose a lot of time and energy to try making the NSF Replayer to work without success. After that I got stuck with my Gfx converter and switched to mappy (so I needed to write the lua script to export the map and tile correctly). And then again getting problems with BG mode 3 that I decided to use.

So now .. It’s the perfect time for a pre-realease. I got all I need for the score board to run and got the entire level 1 in rom and got it scrolling. The pre-release is just that… Enjoy !

The rom is available here is usual.

Next step is putting the main character sprite back with all possible movement. That mean a lot of Gfx work, so I hope that it will be ready by sytart of next week.

See ya, Lint

Yesterday I returned to the PPU.c code. I knew that the VRAMLoad and CGRAMLoad needed to be reworked. The DMA transfer routine we were always getting data from bank $01. Since I start to having lots of ressource, I got stuck while implementing the score/status board. Here is the revised code :

void VRAMLoad(word far *src, word vramDst, word size) {
	// set address in VRam for read or write ($2116) 
	// + block size transfer ($2115)
	*(byte*)0x2115 = 0x80;
	*(word*)0x2116 = vramDst;

	
	// set DMA control register (1 word inc)
	// and destination ($21xx xx -> 0x18)
	*(word*)0x4300 = 0x1801;	

	// DMA channel x source address offset 
	// (low $4302 and high $4303 optimisation)
#asm
	lda %%src;					
	sta $4302;					
#endasm
	// DMA channel x source address bank
#asm
	lda %%src+2;				
	sta $4304;
#endasm

	// DMA channel x transfer size 
	// (low $4305 and high $4306 optimisation)
	*(word*)0x4305 = size;	

	// Turn on DMA transfer for this channel
	setINIDSPDirectValue(0x80);
	*(byte*)0x420b = 0x01;
	setINIDSPDirectValue(0x00);
}

I’m now using far pointer, here is a part of the ressource.h :

extern word far score_pic[];
extern word far score_pal[];
extern word far score_map[];

So now I can copy from anywhere in ROM to VRAM or CGRAM  without any problem.

++ Lint

I finished the level 1 map this morning and really wanted to share it with you (click for full level) :

It’s now been a few days that I’m mostly playing with MAME and Gimp to rip the gfx and create the tiles to use on my Kung Fu Master port for the SNES. I still need to do some work in the score to create the tile and be ready to write them on the screen.

I just discovered that the tool I use to convert my pcx isnt supporting big files like the one i show you here. Anybody know a good map editor compatible with the SNES ? I will anyway first concentrate on the scoring part.

NSF Replayer status : The code is now more stable but i still have issue with the NES code that is accessing some part of memory that should remain untouched. I need to trace it more deeply … I keep you updated anyway but I will not work on that issue that much or I will never have something to show on the end of July.

++ Lint

A received a few suggestion after yesterday post. The switching of player and ennemy life bar was causing some trouble to some of my friends, so I switched it back and changed the life counting. Here is the full screen redesign of the Level 1 start.

I will now start to rip the full Level 1 gfx and start to implement the background scroll and update of the score and status. I think it can be done for start of next week.

See ya, Lint

Yesterday night I redesigned the top part of the game screen si the whole play area fit in the SNES screen. The original arcade title have a 256 x 256 screen while the SNSE have 256 x 224. I need to crop 32 pixels. SO here is the result of my work :

I still need to finish the map of the first level. I hope to finish that by tomorow or later if i decide to implement the score part first.

See ya,

Lint

This morning I think I finally found why the NSF Replayer isn’t working. Here is the piece of code :

        sec
        xce             ; 6502 mode
        ldx #0
        txy
        ;jsr ($1013,x) <- commented for testing purpose
        clc
        xce             ; native mode

The problem is when I switch the 65816 execution mode from native to emulation (6502). This code is part of a routine that is called in memory at address 7F5006 with a jsl instruction and the routine return with a rtl to code in bank 0. When I’m removing the xce instruction everything run fine, with the xce instruction the rtl return in the middle of nowhere. Is there something that xce instruction modify that I’m not aware of ?

I will continue to investigate, but usual shoot your ideas in the comments section.

++ Lint

EDIT: The problem is that when comming back emultation mode the stack address is modified. So now as a quick patch I’m saving it somewhere in RAM and restore it. Thanks D4S for spotting this.