internet archive DS

LADIES AND GENTLEMEN i am very happy to announce that, INTERNETARCHIVEDS IS ALMOST FINISHED!!!! in the previous devlog, i was facing a guru meditation error. i figured out that it was because i misspelt “ITCM” as “ITC” and therefore the whole video parser didnt load. one letter. i know. now, i have had about a thousand different issues with macroblock alignment, and finally figured out the issue- the AUDIO. i know, the audion has nothing to do with the video, but it ACTUALLY DOES! you see, the audio is loaded in before every frame… and the way gericom did it worked for itag7, but doesnt work for any other mpeg4 version. that audio placement, sets the macroblock back by one frame every time, corrupting the video. but now, i put a filter into the php server to only search for videos 20MiB and under, so that they play fast fast. now that the whole pull echo flush system works, all i need to do is remove the debug code, (it takes forever) change the ui, and picture for the top screen, and internetarchiveDS will be ready for you to use!!! if you have a ds of course. also i encoded a video to test on it, here it is for you guys to see!

as stardance begins to come to an end, the time crunch begins to get more serious. in these past 5 hours, i have gotten search to work perfectly, and ran into a guru meditation error, with some very strange hexadecimal values. for example the first 3 rows are all 00000000 and address and pc are both 00000030. things like r8 are ffffffff, and the stackdump is very unusual. there is a photo for you to see the stackdump for yourself. so far im still trying to get the vidfeo to play, i havent even started on the json parser yet! im using a pre- encoded video! anyway stay tuned to see if my 10 day holiday lock in will let me finish this project, and obtain the ultimate prize from the shop.

ladies and gentlemen DO I HAVE A STORY TO TELL! i know, its been 20 days scince my last devlog… but ive made some uncomprehendable progress on the project. in these 7 hours, i have managed to get the proxy server to work with the archive, ive managed to get the dsi to not guru meditate, and actually connect to the wifi using the old wpa wifi protocol! that was the problem with the library im using, DSWIFI. the ersion of dswifi im using, is an old one, from 10 years ago. back befre the 2.0 update when they added calcio. back then dswifi didnt hav support for anything other that wpa, no wap, 1,2,3 nothing. after that, i actally managed to get working search results! i hosted the php proxy using msys bash, whatever works i guess, and the dsi is now recieving and transmitting requests and data through the proxy to the internetarchive. but my next bottleneck! back ten years ago, you tube was really weak, primitive, low quality. and even then, the dsi had do you every last rescource on te lowest data type, ITAG 7, to be able to run. but the project extracts RAW JSON METADATA, which as you know can be really bulky. so my next move will be to make a filter for my php server, to only show results under a certain size, so the json metadata will be processable.

today I spent a lot of time investigating the original YouTubeDS ROM to figure out what is missing and why my rebuilt version does not perfectly match the original.The good news: I was able to confirm that the ROM filesystem is not the issue. Using Tinke and ndstool, I extracted both the original ROM and my rebuilt ROM, then compared all of the files inside them. The fonts, keyboard assets, menus, logos, and other resources are identical.This means the problem is somewhere deeper: inside the compiled ARM9 binary.The original YouTubeDS ARM9 is around 447KB, while my rebuilt version is around 335KB. That missing size is not from assets or files — it is from the compiled code itself. Right now I do not know exactly what is different between the two builds, and without more information it is difficult to recreate the original binary.I have also been looking through the source code, build files, and compiler output to find possible causes, but the remaining possibilities are things like different compiler settings, missing build steps, or code that was present in Gericom’s original environment but is not available anymore.At this point, the biggest step forward is waiting for a response from Gericom. Since he created YouTubeDS originally, he may be able to provide information about the original build environment, missing files, or how the original ROM was produced.Until then, there is not much more I can safely change without risking moving further away from the original. The current goal is still to preserve YouTubeDS and make it usable again for InternetArchiveDS, since the original YouTube API it depended on shut down years ago.For now, the investigation continues — but we have narrowed the problem down from “the whole ROM is different” to “the compiled ARM9 does not match the original.”

Today I did something I genuinely did not think I would be able to do.I revived an old Nintendo DS homebrew project.The goal was not to remake YouTubeDS, but to bring the original project back to life so it could be preserved and used as inspiration for future projects like InternetArchiveDS. The journey was much harder than I expected.At the start, I had a folder full of old source code, but the world it was built for was mostly gone. Libraries were missing, build files were outdated, and the project depended on old versions of tools that were no longer set up correctly. I spent hours digging through Makefiles, finding missing dependencies, rebuilding libraries manually, and trying to understand how everything connected.There were so many moments where it felt like I was one error away from giving up. I had to rebuild parts of the devkit environment, compile libraries like libfat again, fix linker issues, repair paths, and figure out why the final ROM packaging step kept failing.The most frustrating part was that the code itself was fine. The challenge was rebuilding the entire devkitpro system around it.After around 14 hours of debugging, something incredible happened.The build finally completed.I copied the ROM onto my DSi, launched it, and saw it load exactly like the original compiled version. No extra steps, no broken menus, no weird crashes. It was the exact moment where every tiny fix, every error message, and every hour of searching suddenly became worth it.Seeing old code from years ago come alive again on real hardware was an amazing feeling. This project reminded me why I love programming: sometimes the biggest victories come from solving problems nobody else sees.

Today I spent my time trying to bring YouTubeDS, an open-source Nintendo DS homebrew application created by Gericom, back to life. While I expected to spend most of the session coding, nearly all of my progress came from reverse engineering and troubleshooting an outdated development environment. I tracked down missing source files, resolved linker errors caused by an absent API key, and compared my rebuilt binaries against the original ROM to understand why they behaved differently.After digging through Makefiles, compiler output, map files, and the generated ROM headers, I discovered that the project was originally built using an older version of devkitPro and libnds. Modern releases automatically link against the newer Calico runtime, producing binaries that differ significantly from the original build and refuse to run correctly. I experimented with build flags, linker specifications, and library configurations before confirming that the real solution is recreating the original toolchain rather than patching the project itself.Although I haven’t produced a working ROM just yet, I now understand exactly why the project fails on modern tools. The next step is installing an older version of the Nintendo DS development environment so the application can be rebuilt as it was originally intended. Even though this was a debugging-heavy session, I made meaningful progress toward preserving and reviving an abandoned piece of Nintendo DS homebrew.

TODAY: i tried to compile my 10 year old software, debug some binary, download gh repositories, TRY FOR ONE BLOODY HOUR TO FIGURE OUT WHY IT WOULDNT COMPILE figured out why it wouldnt compile, realize that linux is too hard, and fell asleep. then i decideed i would try again, debugged some code, and found that it wouldnt compile because it thought somthing didnt exist. im going to try to fix it, if anyone knows linux mesage me pleease