Youtube DS - Play Youtube videos on your DS!

Gericom · Apr 21, 2016

Coto said:
ah, about the red screen then it's a coincidence.?

for my homebrews i put most tables/read only code that do not hold any functions (because if i let the cpu to jump there then fetch/decode/executing opcodes cpu would crash), this for DTCM, then in ITCM hblank code, or dma, or whatever code that needs to execute from cache busses.

aside related:

i moved the youtubeDS project over the dual ARM cores template, removed the precompiled DSWIFI library linking on Makefile, and added compiling from DSWIFI sources directly, so you get access to ARM7 code, get DSWIFI support (not just linking), and well, ARM9.

this is extremely useful because:

1) this project itself is proof that DSWIFI is working again on HTTP stack.

2) thanks to that happyhttp socket, now DS emulators could use the internet stack for different purposes!
for example NesDS's NIFI is not working on localplay anymore on latest sources (or I had very bad luck with testing on 5 DS/3DS)
here:
http://www.mediafire.com/download/rbkcgz44o44nffr/youtube_dual_arm_wifisources.zip

The DTCM can indeed not execute code. To get the best performance, tables in dtcm and code in itcm should be combined. That should then not create any waitstates.

Ehm. I don't really get your point. Do you want to change these libraries?

pasc · Apr 22, 2016

<3 When ppl tinker with beloved hardware

Reminds me of chisholms tunavids...

Only that this looks way more complicated...

*Searches DS Charger"

Gericom · Apr 22, 2016

pasc said:
<3 When ppl tinker with beloved hardware

Reminds me of chisholms tunavids...

Only that this looks way more complicated...

*Searches DS Charger"

Yes, I love the DS because it's always a kind of challange to make stuff for it.

That's an interesting project aswell, I didn't know it existed. He used an existing xvid decoder though it seems, while I wrote a simple mpeg 4 decoder from scratch (first in c# and then ported to arm assembly).

Gericom · Apr 23, 2016

I updated github again. I fixed a couple of (stupid) bugs and I started implementing searching using the youtube api. I have not been able (yet) to do https request, so I made a simple https->http proxy to still be able to make the api requests.

For the gui, I am thinking of something similar to the android youtube app (material design).

Gericom · Apr 25, 2016

I am making some progress on the gui:

The back and search button are clickable.

The keyboard does not work yet though.

TecXero · Apr 25, 2016

I thought it was insane you created a basic working client in the first place, but now you're improving it to something user friendly? You, my friend, are insane and amazing. :grog:

VinsCool · Apr 25, 2016

Damn, it already looks better than the official 3ds app. God job man!

Gericom · Apr 26, 2016

I made some more progress on the keyboard today:

I've attached a rom with the menu only (well, the other code is in it aswell, but the menu is just an endless loop for now), so you can try it out if you want. I still need to add optical feedback to the space bar (which will make typing easier).

Gericom · Apr 30, 2016

I updated github to the latest version! (the link in the first post points to the latest NDS file)
- Nice GUI; you can search for videos now

- Increased the frame queue from 6 to 9 frames (I found a way to display pictures with a stride of 176 on a bg layer (two actually) with a stride of 256)

A lot of videos don't seem to work yet, I don't exactly know why. Sometimes you have to click a video a couple of times before it starts also. The display of the search results is only tempoarly of course. I want to show the thumbnails later on and show video information when clicking a video aswell and browsing channels and stuff.

Some pictures:

Coto · Apr 30, 2016

since you are using background vram memory, have you tried dma'ing the converted frame on channel 3 on vblank? seems like the DS really likes this interval for updating frames..

Gericom · Apr 30, 2016

Coto said:
since you are using background vram memory, have you tried dma'ing the converted frame on channel 3 on vblank? seems like the DS really likes this interval for updating frames..

Why would I do that? The frame queue is currently completely in vram, saving a lot of main memory and by not using vsync, no time is spent waiting for vblank (this however causes small in middle of screen frame swapping glitches). I am using a timer interrupt at the framerate that alters the screen base address to point to the next frame in the queue. The function that converts yuv to rgb also writes to the vram directly, preventing yet another useless copy.

migles · Apr 30, 2016

Gericom said:
I made some more progress on the keyboard today:
View attachment 47050
I've attached a rom with the menu only (well, the other code is in it aswell, but the menu is just an endless loop for now), so you can try it out if you want. I still need to add optical feedback to the space bar (which will make typing easier).

the DS has 4mb of ram and does this...
my phone has 1 gb of ram, it's quad core and got a nice gpu capable of running great games, yet the keyboard sometimes stops working for ~~sending keylog information to companies~~ whatever reason sometimes it freezes for some seconds or refuses to open

SANNIC789 said:
YEASSS TIME TO WATCH PORN BRB GUYS

well, since i internet a lot, i know about more desesperate people who do the weirdest things like using a couple sponge scourers and an elastic...
so i give you my thumbs up

Coto · Apr 30, 2016

Gericom said:
Why would I do that? The frame queue is currently completely in vram, saving a lot of main memory and by not using vsync, no time is spent waiting for vblank (this however causes small in middle of screen frame swapping glitches). I am using a timer interrupt at the framerate that alters the screen base address to point to the next frame in the queue. The function that converts yuv to rgb also writes to the vram directly, preventing yet another useless copy.

If you are writing directly the converted chunks in vram then the memory waitstates can cause graphical glitches if image is not sync (this is VBLANK period copies), this because you will use the main CPU <-> ewram bus through an external interrupt trigger.

Or if you use the alternate data/instruction busses, the flush/invalidate -> opcode ->drainwrite method is preferred. its just frames sent using dma3 tend to have fewer waitstates while grabbing data from ewram thus, causing less graphical bugs.

using dma3 for copying a frame is no useless imho. And I was just giving an opinion based off emulation tests.

Using a timer interrupt means it will ask for EWRAM bus time in a way that I believe the DS was not meant for. But whatever.

Gericom · Apr 30, 2016

Coto said:
If you are writing directly the converted chunks in vram then the memory waitstates can cause graphical glitches if image is not sync (this is VBLANK period copies), this because you will use the main CPU <-> ewram bus through an external interrupt trigger.

Or if you use the alternate data/instruction busses, the flush/invalidate -> opcode ->drainwrite method is preferred. its just frames sent using dma3 tend to have fewer waitstates while grabbing data from ewram thus, causing less graphical bugs.

using dma3 for copying a frame is no useless imho. And I was just giving an opinion based off emulation tests.

Using a timer interrupt means it will ask for EWRAM bus time in a way that I believe the DS was not meant for. But whatever.

I don't think you fully understand how my code works. You should have a look at main.cpp. It decodes the mpeg4 to yuv buffers in main ram, then immediately converts yuv to rgb, writing to the next free queue block in vram. The timer interrupt does not copy any data.

Coto · Apr 30, 2016

I already did.

My main point is:

If you are already in a interrupt state that means waitstates-compatible memory can read/write such the ITCM/DTCM (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0198e/Cihffjgb.html) thats all OK, but you still force an external interrupt (by using memory whose waitstates are way worse, or by programatically calling an external interrupt through a timer, ignoring the memory waitstates) you have one out of two possibilities:

1) poll the waitstate of target memory controller until the last hardware timer interrupt to frameHandler(); accesses it.

2) will sometimes cause the slower memory to force waitstates or override them, and if overriden, you will get lockups (not just because you move the frameHandler(); to itcm means the AHB bus will gracefully accept overriden waitstates told by the timer interrupt unless the above ARM Core setup)

This explains pretty well the AHB connections with DMA controllers, the processor is a newer one, but the design is kept as ive seen myself the frame differences when causing a dma controller copy from ewram/dtcm/itcm (those last two by reserving a .global buffer before) to vram async, against a ewram + timer copies, with the last one always causing lockups.

http://cliffle.com/article/2015/06/11/matrix/

-

So my base point: setting a VBLANK handler, and when the frame is received/converted, use DMA to move on VBLANK to vram. this is how the AHB was constructed around somehow and the reason ninty I think decided to go with. Just a word of "why not just the design the DS has already".

I see you excluded as much as EWRAM as possible, by using static, the variables are set on stack (DTCM).

But like again i will say, whatever.

Clector · May 1, 2016

Looks amazing.
Good work!

Gericom · May 1, 2016

Coto said:
I already did.

My main point is:

If you are already in a interrupt state that means waitstates-compatible memory can read/write such the ITCM/DTCM (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0198e/Cihffjgb.html) thats all OK, but you still force an external interrupt (by using memory whose waitstates are way worse, or by programatically calling an external interrupt through a timer, ignoring the memory waitstates) you have one out of two possibilities:

1) poll the waitstate of target memory controller until the last hardware timer interrupt to frameHandler(); accesses it.

2) will sometimes cause the slower memory to force waitstates or override them, and if overriden, you will get lockups (not just because you move the frameHandler(); to itcm means the AHB bus will gracefully accept overriden waitstates told by the timer interrupt unless the above ARM Core setup)

This explains pretty well the AHB connections with DMA controllers, the processor is a newer one, but the design is kept as ive seen myself the frame differences when causing a dma controller copy from ewram/dtcm/itcm (those last two by reserving a .global buffer before) to vram async, against a ewram + timer copies, with the last one always causing lockups.

http://cliffle.com/article/2015/06/11/matrix/

-

So my base point: setting a VBLANK handler, and when the frame is received/converted, use DMA to move on VBLANK to vram. this is how the AHB was constructed around somehow and the reason ninty I think decided to go with. Just a word of "why not just the design the DS has already".

I see you excluded as much as EWRAM as possible, by using static, the variables are set on stack (DTCM).

But like again i will say, whatever.

So you think it would be faster to convert yuv to rgb to a frame queue in main memory and then dma to vram on the vblank following the timer interrupt?

Edit: I synced github, so the new rom can be downloaded now
Edit2: I tried what you said and I also moved some tables from ITCM to DTCM and it's much faster now indeed! The display accessing the VRAM was indeed slowing it down a lot. Thanks for pointing that out.

Coto · May 1, 2016

see? glad you got it sorted out fast. : )

Gericom · May 1, 2016

Coto said:
see? glad you got it sorted out fast. : )

Yes. I also updated github now to include the speed improvements. I also added partly support for mpeg4 slices. It's not complete yet (it simply discards everything after the first slice for now), but some videos seem to use it. There also seem to be some memory issues, with videos only working when you startup the rom and not after playing another video.

Coto · May 1, 2016

dtcm / itcm can cause section conflicts if you for example call some function located in itcm, then you use a literal pool located in the same place. Compiler warns about this if you try to explicitely try to do it through the preprocessor. If you skip that by using some tricks, you will get that behaviour

so the best results ive got so far is to use all not executable, but read / writeable code in dtcm, and just functions in itcm, and trying to not to use the itcm for anything but functions

also have you tried drain buffer operation prior DMA copy? NDS's CP15 opcode is:

Code:

asm("mcr p15,0,r12,C7,C10,4");

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0198e/I1014942.html

this allows the ARM9 to sync the memory across master/slaves in AHB (like DMA controller)

Well-Known Member

pasc

Guest

Well-Known Member

Well-Known Member

Well-Known Member

Technovert

Persona Secretiva Felineus

Well-Known Member

Attachments

Well-Known Member

-

Well-Known Member

All my gbatemp friends are now mods, except for me

-

Well-Known Member

-

Well-Known Member

Well-Known Member

-

Well-Known Member

-

Similar threads

Popular threads in this forum