This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - MPoupe
Pages: 1 ... 4 5 [6] 7 8 ... 12
76
« on: February 22, 2012, 04:01:28 am »
It is really slow compared to the real video. Are you sure there isn't a way to make it faster?
Yes, the jpeg based player (CGPlayer2) is very slow, it runs about 2 fps.
77
« on: February 16, 2012, 03:47:10 am »
I'm glad you allow multiple qualities actually. On the 84+SE if you use a 8 KHz file, it plays 3 times faster or so. 
I'm afraid it was some misunderstanding. The fxPlayer supports only 1 format - 22 KHz, 8bit. My previous post was only about different wav formats and sizes. But support for 11 KHz should be easy, 8 KHz can be supported only approximately.
78
« on: February 15, 2012, 05:17:53 am »
It probably depends. I know a full WAV song around 5 minutes long takes roughly 60 MB of space, and if it's converted to 22 KHz it's 30 MB. Not sure if changing it from 16 bits to 8 halves the size once more, though. On the 84+SE we roughly had the same sound quality and we could store around 1 minute of audio in 1.54 MB.
I just did some measurement by winamp. Have music file 8:15 of length. 22KHz, 8bit (format for fxplayer) - 10,929,955 B 11KHz, 8bit - 5,465,000 B 8 KHz, 8bit - 3,965,932 B, but sound quality is like from analog telephone The fxplayer uses only 5 bits so we can go to 11 KHz, 4 bit - 2732500 B (not tested) How much music can be stored on 16MB?
So 16 MB storage would hold 5.85x more -> 48 minutes BTW: why do you ask for 16 MB storage ? 9860 has 1.5 MB and SD card can be up to 2 GB (for the models where fxplayer works)
79
« on: February 14, 2012, 11:04:22 am »
I did a search, what you think of this?
Interesting, but the conversion / porting would be difficult for some (or all :-( ) libraries. It seems you use the size of the archive - this may be irrelevant, because some libraries include huge autoconf scripts which we do not use, contrariwise sources are good to be compressed so compilation may produce bigger result than compressing. SD card would NOT help, because you cannot run code from SD card. But you can run code from flash, which is 1.5 MB.
80
« on: February 13, 2012, 08:21:17 am »
Does this play mp3's? Not yet. But if you know some nice free small mp3 decoder library, I would integrate it to the player.
81
« on: February 09, 2012, 12:28:35 pm »
See fx_calculators_SuperH_based_10.chm
(http://ourl.ca/8207/238670).
Try topic: fx-CG20...Registers, MPU...Accessing the 3pin serial lines directly
That's what I found. Hello Simon, good to see you here :-) Do you plan any update of your documents / SDK?
82
« on: February 09, 2012, 10:05:41 am »
and register i? The delay is in "com_transmit(0);" Communication with hardware is always much slower than memory access.
83
« on: February 09, 2012, 09:12:50 am »
...
What kind of movies does it play, and does it need an SD card?
it play special converted movies, and the app needs SD Card for save the video (video file is too big for non SD models) ...
more info here: http://martin.poupe.org/casio/scvp/index.html
I thought the PRIZM does not have an SD card slot. How will that work out?
There are 2 video players. The Prizm player (CGPlayer) is at http://martin.poupe.org/casio/cgplayer/index.html. Of course it doesn't need the SD card, the video should be saved to the internal flash. The fx9860G player (fxPlayer) is at http://martin.poupe.org/casio/9860player/index.html. I updated it so it allows, but doesn't require SD card. Video should be saved on the SD card (if available) or in the internal flash.
84
« on: February 09, 2012, 09:06:00 am »
Given the Prizm and FX-9860G series got much faster CPUs than the 84+, I wonder if better sound than the 8 bit chiptunes from some 83+/84+ programs could be produced, such as Sega Genesis, Turbografx-16/PCEngine or PC88? What quality do you expect ? The uart running 1 bit D/A mode (without any HW support) is very expensive. Assume we want output 8bit samples on 22 KHz mono (the worst quality which may be acceptable). So we have 8 bit samples => 256 different values, so to send 1 sample we have to transmit 255 bits (round up to 256 bits => 32 bytes). This means we need to prepare 704000 bytes each second and overclock uart to 7040000 bps (count 10 bits for byte because of start bit and stop bit). The uart has fifo of 64 bytes, so the interrupt should fire each (less than) 90 us. This all seems to be OK, but the 9860 is simply not capable of doing this. My player runs uart on ~ 1.8 Mbps well, I tried double speed when measuring, but simple loop like volatile i;
...
while(i) //timer will reset after 1 second
{
com_transmit(0);
count++;
}was not able to push bytes quick enough.
85
« on: February 08, 2012, 12:14:31 pm »
How? With over locking? Look at the source code of the fxPlayer. There is everything. (It must be :-) ) AHelper has been doing a ton of work on learning to make the link port on the Prizm do more nifty tricks, and I'll soon be trying some stuff of my own. I believe AHelper has been documenting his work over at Cemetech, so you're welcome to double-check his topic. I'll try to remember to return to this topic as well.
Please post a link.
87
« on: February 08, 2012, 05:29:03 am »
I have all of my jpegs stored in a folder, now what do I do to compile them together into a .mjp file? The mjp file format is simple, it is an array of "frames". Each frame is length of the jpg file (rounded up to be dividable 4; 32 bit value in little endian) and the jpg file itself. I attached simple program which does exactly this compilation to the package (streamer.cpp). For your convenience I dump it here : #include "stdio.h"
const char *pszInputFmt="%04u.jpg";
const char *pszOutputfile = "demo.mjp";
char gBuf[65536];
int LoadFile(int index)
{
char sName[1024]={0};
FILE *f;
int len;
sprintf(sName,pszInputFmt,index);
f=fopen(sName,"rb");
if(!f)
{
return -1;
}
len=fread(gBuf,1,sizeof(gBuf),f);
fclose(f);
len = (len+3) & ~3;
return len;
}
int main(int argc, char* argv[])
{
FILE *f = fopen(pszOutputfile,"wb");
int i,len;//max 5 240
for(i=1;;i++)
{
len = LoadFile(i);
if(len <=0)break;//read failed
if(i % 5)continue;//25 fps --> 5 fps conversion
fwrite(&len,4,1,f);//each frame (= jpg file) has 4 byte length (int32, little endian)
fwrite(gBuf,len,1,f);//the file itself
printf(".");
}
fclose(f);
return 0;
}
88
« on: February 08, 2012, 05:16:43 am »
Yup, And we could use bits sensed like PWM, couldn't we? Yes, but will have to increase the communication speed. I use ~ 1.8 Mbps
89
« on: February 07, 2012, 04:20:44 am »
If we can send a certain frequency a a certain time withouts problems, we'll reached the first milestone.
This should be easy on both calculators. Just open the COM port on 9600 bps, no parity, 8 bits and output byte 0x55 in a loop. This would produce square sound on 4800 Hz, time is driven by the loop (it sounds until you loop :-) ). Use syscalls for opening port and sending data. For prizm see Simon's Mini SDK and for 9860G see (for example) revolution-fx at http://revolution-fx.sourceforge.net/You can produce only some frequencies this way. But I think you mentioned that this is enough for the first step.
90
« on: February 06, 2012, 12:18:36 pm »
Hello, I have written the fxPlayer - multimedia player for 9860G calculators. It can play wav sound through COM port. Sources are on my page ( http://martin.poupe.org/casio). How can I help you ? Martin
Pages: 1 ... 4 5 [6] 7 8 ... 12
|
Show Posts