Uzeamp Movie Player Demo

[uze6666]

What about GIMP's batch processing mode? You can resize and apply processing on many pictures at once, that would save you a bunch.

-Uze

[Jhysaun]

If you have the GIMP GAP you can export the movie with the uzebox palette.



>J

[JRoatch]

I ended up converting all the frames to PPM:P6 (portable pixmap with a file descriptor of P6) and wrote a quick c program to multiplex everything together.

For sound I used 15700hz and it syncs perfectly for me, and for video I choose 29.97fps not 30.

[uze6666]

Can you post that tool? I'd add it to the toolset in SVN...

-Uze

[rlaw]

Although I got the SD card boot loader to work by switching to a 644 instead of a 644P, the movie player still doesn't work. I get horizontally scrolling lines, as if there was a sync problem. I get some hints of an actual movie playing, but most of it's a garbled mess. Could it be the Uzebox is really sensitive to what kind of SD card you're using?

[uze6666]

Yes some card won't work at all being too slow, while other will somehow screw up the image. At the present time I can't explain why. Check out this thread for some possible solutions: viewtopic.php?f=1&t=697&p=5537. Some experiments your can try: Insure the card is not SDHC, formatted in FAT16 and have the movie being the first file written or the second one.

-Uze

[mast3rbug]

I know this post is old...

But just for information, In my movie player made on AtXmega, I used the same process (exporting all the frames in .BMP, resizing ect...). But I used VirtualDub (a freeware video software coded in ASM.) It really fast, and it can resize, retime, and do all of modification in one shot, and the export is really fast.

If it can help someone...

Mast3rbug

[HardlyUnique]

I finally got around to getting an SD card for my uzebox and I have to say, I'm VERY impressed!

Seeing 8-bit Trip on an 8-bit system is a trip, indeed.

I was able to easily reproduce the problems of the image losing sync when the .uzm file is not the first on the card. I noticed that it maintains HSYNC perfectly, however, so I think there's probably some way to correct this with software.

I was thinking that "read_filler" could ensure that what it's reading is all black and if not... I'm not sure yet . Sync it up somehow...

Anyway, what I'm really posting about is to ask if the video demo is broken for anyone else with the latest source? I can build it with the 3.0 and 3.1 tags and it works great, but 3.2 and the trunk build w/o issue but give me a garbled, sync-less, colorless mess. This is from uzebox.googlecode.com/svn.

EDIT: Beta4 doesn't build but I see now that you knew that.

[HardlyUnique]

OK, compilation issues aside, I've made some progress!

Until I relearn AVR assembler, here's a "human-assisted," workaround :

Using the 3.1 tag, open Demos\VideoDemo\VideoDemo.c. Replace main() with:

Code: Select all

int main(){

	init();

	LoadRootDirectory(sector.buffer);

	//find the first .uzm file
	for(unsigned char i=0;i<16;i++){
		if((sector.files[i].fileAttributes & (FAT_ATTR_HIDDEN|FAT_ATTR_SYSTEM|FAT_ATTR_VOLUME|FAT_ATTR_DIRECTORY|FAT_ATTR_DEVICE))==0){
			if((sector.files[i].filename[0]!=0) && (sector.files[i].filename[0]!=0xe5) && (sector.files[i].filename[0]!=0x05) && (sector.files[i].filename[0]!=0x2e)){									
				
				if(sector.files[i].extension[0]=='U' && sector.files[i].extension[1]=='Z' && sector.files[i].extension[2]=='M'){

					fileSector=GetFileSector(&sector.files[i]);
					break;

				}
						
			}				
		}
	}

	// send the multiple block read command and logical sector address
	mmc_send_command(18,(fileSector>>7) & 0xffff, (fileSector<<9) & 0xffff);	
	mmc_datatoken();

	StartPlayback();

	while(1)
	{		
		// if the player presses any button
		if( ReadJoypad(0) )	
		{
			// wait for key release
			while(ReadJoypad(0)!=0);
			
			// and restart playback
			StopPlayback();
			StartPlayback();
		}
	}
}

Then, compile the project, feed it to your boxen and just mash buttons until it works!

Using the 3.1 kernel and this ugly hack, I wonder if any sd cards truly don't work anymore? (besides SDHC, of course!)

I really think this can be implemented in software. I believe the worst-case scenario would involve re-encoding the source files, possibly using a special value for the filler (I'm not sure it's possible to distinguish between filler and border on 8-bit trip, for instance).

[uze6666]

I finally got around to getting an SD card for my uzebox and I have to say, I'm VERY impressed!

Thanks! Timing on this one was hard at hell and would unfortunately not work on all SD card brands due to varying inter-block delays. It's been quite a while since I coded this thing and can't recall the specifics of the filler hack you're mentioning. And It's interesting that it seems to work. In that case, indeed, a software patch could well work. We would need to gather the manufacturer code and/or model from the card dynamically and match against a table of delay values.

Regarding the compilation issues, I also noted when preparing for Maker Faire that the video player stopped working with the latest kernel release. I have to use the HEX attached to this thread for it to work. So something changed somehow, but I have no clue so far.

-Uze