Advent of Code on the Nintendo DS
sailor.li
sailor.li
I'll elaborate on anything in here if anyone wants to know things.
I think this was quoted from elsewhere within the post but, is this true? If by "up to" we're not including the 3DS, the DSi and DSi XL still don't contain a GBA slot. I don't _think_ they contain the hardware either b/c with homebrew I believe the GBA games are emulated on those newer devices.
Am I mistaken here?
Later, homebrew was able to sideload GBA titles [3], which essentially has perfect software compatibility. However, emulating GBA titles still has advantages over rebooting the device so software emulators are available for the 3DS. The New 3DS is fast enough to provide pretty high quality GBA software emulation.
I don't think a similar path to directly use the DSi's ARM7 to boot GBA games was ever found by homebrewers (it may just be that the DSi is not able to reboot in a "different mode", which Nintendo did release for the 3DS?). The best available on the DSi seems to be a "compatibility layer" solution that tries to run the ARM7 code on the main ARM9 CPU [4], which seems to work surprisingly well.
[1]: https://www.3dbrew.org/wiki/ARM7_Registers
[2]: https://nintendo.fandom.com/wiki/Nintendo_3DS_Ambassador_Pro...
[3]: through "Virtual Console injection" tools, or through https://github.com/profi200/open_agb_firm
[4]: https://emulation.gametechwiki.com/index.php/GBARunner3
From GBATEK:
"The memory regions and IRQ bits do still exist internally, but the DSi does basically behave as if there is no GBA cartridge inserted. Reading GBA ROM areas does return FFFFh halfwords instead of the usual open bus values though."
Since the memory map isn't flexible and GBA games expect to load data from the cartridge at the hardcoded area, games won't function on the ARM7. I assume the 3DS has special hardware to handle this properly.
I do feel like programmers are a bit of a masochistic lot when it comes to AoC, though.
> The logical way to output the solution for the AoC problem is to create sprites for every digit, upload them to video memory, and arrange the sprites on screen. I'm not going to do that and instead I will use Display Mode 2...
This guy - "I do actually know Rust, but I never learned how to use it. I just started writing it because I was born with an innate knowledge of the language, similar to how I know Java or Kotlin despite never having learned them."
My first words were "Dada!". This guys was "public static void main(String[] args)"
The article itself sums things up well "Most of the puzzles are in the realm of either string processing (somewhat applicable to programming), logic puzzles (not really applicable to most programming), or stupid gotchas in the input format (annoyingly, very applicable to most programming)."
I don't directly have experience with hacking on DS, but I had some experience with embedded programming. It first seems daunting and hard, and then you do some stuff and read example code and other code on github and you become "wait that's it?"
What seems hard becomes easy by actually doing it. (that means you need to have time, too, which is another thing)
Maybe. But for some it's really just the enjoyment of a good challenge that lets them explore and try out things. I personally love hardware like the DS simply for its accessibility. Modern PCs and consoles are way too complex, while the DS allows you to poke at its guts with no OS or virtualization in the way. It's fun to approach problems like those in AoC in completely novel ways on systems that require and allow you to do things differently.
It's not for everyone, sure, but it's certainly not torture for those who do it.
No, it's not better. The creator puts a lot of effort and user testing into making the problems as clear and specific as possible, and has given talks on that exact subject. There's absolutely nothing "intentional" about any difficulties you have understanding the problem text. Unfortunately there's only so much that can be done for people who simply can't read.
> Or are [you(?)] still offended by my opinion?
I never said that I was offended, I said that the creator would take offense to your accusation. I'm noticing a pattern here.
There was definitely something fun with making games for these very specialized and unique consoles. While it's natural and a whole lot easier to dev now that all consoles (and PCs) have converged to being almost identical, I can't help but feel a bit nostalgic for it.
By picking the DS, the author might also have ensured his application will work hundreds of years from now...
I know we have plenty of people here doing AoC with their own personal challenges/restrictions on top. What are yours? Solving in an eso-lang? Self-imposed resource constraints (runtime/memory)? Only using Excel? Let's hear 'em.
Ha, this is pretty much my favorite restriction too. I try to do one single-line expression for input parsing, one for the part 1 solution, and one for the part 2 solution (eg [1]). Thought sometimes I can't manage it and I just fall back to solving it normally.
[1] https://github.com/benhaney/Advent-of-Code/blob/master/2024/...
The first day started of quite challanging with number parsing, sorting and set intersection. I may have gotten sidetracked trying to beat the standard library sort for a week.
It's already half way into week three and I'm still at day 2 part 2.
Maybe next year I'll actually prepare some utility code for parsing grids and 2d vector math and such.
I continued in C++, but kind of lost interest. Next year I'll learn the language beforehand. hehe
There’s a decent VSCode plugin but I mostly use the online pad because it’s such a rich environment. Very active Discord, with an AoC channel for help and sharing solutions - the maintainer actively iterates on the language to help them solve AoC problems.
(I also fall back to Clojure when I’m struggling to come up with a uiua solution or banging my head against the stack, I kinda wish I had uiua-in-Clojure like how April is APL-in-CL)