means that the user dont need to care about cached memory, the sound is working out of the box.
Mhh, lets see if i can change this...
try this...
// written 2004 Mirko Roller mirko@mirkoroller.de
#include "gp32.h"
extern unsigned char modfile1[];
extern unsigned char modfile2[];
extern unsigned char sample1[];
extern unsigned char sample2[];
static volatile int t3=0;
__irq static void timer3_isr( void ) //should be called @50Hz
{
t3++;
}
void InstallTicker( void )
{
unsigned long count;
u32 rtcon=rTCON;
count=gp_getPCLK(); //==PCLK Mhz/8bit prescaler+1/4bit divier/target freq 50Hz
count/=256;
count/=16;
count/=50;
gp_disableIRQ();
rTCNTB3 = count;
rTCFG0 |= (0xFF<<8);//255+1
rTCFG1 |= (0x3<<12);//16
rTCON |= (0x5<<17); //auto reload=1 + maunal update=1
rTCON = rtcon |(0x9<<16); //auto-reload=1 + manual update=0 +start=1
gp_installSWIIRQ(13,timer3_isr); //13=ISR for timer3
gp_enableIRQ();
}
int main() {
char time[20];
int t;
u16* framebuffer = (u16*) FRAMEBUFFER;
// If you get clicky sound, disable cache on framebuffer
gp_setMMU ( framebuffer, framebuffer+(320*240*2)-1, 0xFF2 );
gp_setCpuspeed(33);
gp_initFramebuffer(framebuffer,16,85);
//gp_startmod(modfile);
gp_startSoundmixer(22050,16); // start IRQ modfile
gp_clearFramebuffer16 ( framebuffer, 0xFFFF );
gp_drawString ( 1, 10, 35,"Mr.Mirko Mod/Mixer running @33Mhz ", 0xF800, framebuffer );
gp_drawString ( 20, 30, 25,"L = Play Sample1 ", 0xF800, framebuffer );
gp_drawString ( 20, 40, 25,"R = Play Sample2 ", 0xF800, framebuffer );
gp_drawString ( 20, 50, 25,"START = Start Modfile1 ", 0xF800, framebuffer );
gp_drawString ( 20, 60, 25,"SELECT= Start Modfile2 ", 0xF800, framebuffer );
gp_drawString ( 20, 70, 25,"A = RESET ", 0xF800, framebuffer );
gp_drawString ( 20, 80, 25,"B = Stop Soundmixer ", 0xF800, framebuffer );
gp_drawString ( 20, 90, 25,"UP = Start Soundmixer ", 0xF800, framebuffer );
atexit(gp_stopSoundmixer());
InstallTicker();
while (1) {
if (gp_getButton()&BUTTON_A) exit(1);
if (gp_getButton()&BUTTON_START) gp_startModfile(modfile1);
if (gp_getButton()&BUTTON_B) gp_stopSoundmixer();
if (gp_getButton()&BUTTON_SELECT) gp_startModfile(modfile2);
if (gp_getButton()&BUTTON_L) gp_addSample( (u16*)sample1,22050,GP32_STEREO,0,100800);
if (gp_getButton()&BUTTON_R) gp_addSample( (u16*)sample2,22050,GP32_STEREO,0,148160);
if (gp_getButton()&BUTTON_UP) gp_startSoundmixer(22050,16);
gp_clearFramebuffer16(framebuffer,0xffff);
t=gp_getRTC();
sprintf(time,"%d",t3);
gp_drawString(20,100,strlen(time),time,0xF800,framebuffer);
t+=64;//1sec
while(t>gp_getRTC());
}
}i change my rtcon writes, so other timer registers are not affected...
in
#define BITSET(a,B) (a|= (1<<b))
#define BITCLEAR(a,B) (a&=~(1<<b))
to gp32.hyes, Iam working on this part now...
Man, your SDK just gets more awesome with each release! What new features are you working on for the next release, and do you need any help?
HI,Man, your SDK just gets more awesome with each release! What new features are you working on for the next release, and do you need any help?
Actually, I ask because I'm planning on writing some functions that'll load sprite data from a file into the header+sprite format that your sprite drawing functions expect. That way, programmers can update their graphics easily without having to recompile their apps.
However, I figured that I should ask you if you're working on something similar, so I don't duplicate your work. Also, I wanted to run by a couple ideas of how to deal with this: I thought that perhaps it would be useful to modify the bmp2bin utility you wrote to create a binary file version of the image data... basically, take the u16 array it creates, and dump it bit-by-bit to a file. Then, not only would reading it in be easy (just read file into RAM, and then point the sprite drawing functions at it), but it would be easy enough to use your ZDA compressor to pack the graphics files, and then load the graphic's binary data from ZDA files.
What're your thoughts?
Hrm... but if I put a whole bunch of headerless sprites into a ZDA archive, how will I be able to figure out what their dimensions are when I read them back in? IMO, having the header makes it a lot easier to switch graphics on the fly, since then you don't have to hard code sprite sizes into your app.MrMirko said:
Ahh, I was confused about bmp2bin... I thought it just produced the *.c files. What you're telling me is that bmp2bin already does everything I want, and that I shouldn't worry about it.MrMirko said:
Yes, a zda container with header is a nice idear, it will make data handing a lot easyer... I write some next weekend...Hrm... but if I put a whole bunch of headerless sprites into a ZDA archive, how will I be able to figure out what their dimensions are when I read them back in? IMO, having the header makes it a lot easier to switch graphics on the fly, since then you don't have to hard code sprite sizes into your app.MrMirko said:
As well, I'd love to have ZDA archives that include a header, so that the program could just scan for files with a specific name inside the archive.
Ahh, I was confused about bmp2bin... I thought it just produced the *.c files. What you're telling me is that bmp2bin already does everything I want, and that I shouldn't worry about it.MrMirko said:
I should be good to go, thanks for producing such an awesome piece of code!
Awesome to hear about the ZDA stuff! That means that by the time I'm actually ready to get to file reading, you'll probably have that bit ready.
sounds very nice, and nice that you share your work laterAwesome to hear about the ZDA stuff! That means that by the time I'm actually ready to get to file reading, you'll probably have that bit ready.
I'm working on a higher-level set of C++ classes for working with your SDK... basically just some nice handlers for making layers (with nice parallax scrolling!), and handling animated sprites. Once I get it to the point that it actually does something useful, I'll release it to the community through my site.
