defaultArm7 r4239 fails to support wifiInitDefault() ?

[PypeBros]

Hello, all.

I'm trying to get some code working with the latest libnds 1.4.8 and dswifi-0.3.13, but for some reason, the initialisation of the wifi on ARM9 remains stuck. I did a fall back running the latest default_arm7 on the ARM7 side and the access point selection example on the ARM9, but even that way, it never gets out of Wifi_InitDefault. tracing execution using GDB and desmume revealed that no IRQ handler seems invoked on the ARM7 side, even past the fifoSendAddress(FIFO_DSWIFI, (void*) wifi_pass) line.

It looks like, just before entering the main loop on the ARM7 side, the IE register only has value 0x85, that is enabling VCOUNT, VBLANK and NETWORK, but neither IRQ_WIFI, nor any of the IPC/FIFO-related IRQ seems enabled. Is that intended ?

-* edit *- I manage to build a working "httpget.nds" when using the makefiles provided with the sources rather than importing the sources into my own project tree ... so that could be something with my building process. I'll keep investigating that.

[elhobbs]

are you using palib? this is a common problem if you are using palib - it is not compatible with current versions of libnds and/or dswifi.

[PypeBros]

No, there's no PAlib around. I use libNTXM and converted my code to the version of NTXM that uses the fifo system appropriately, and I will have to integrate the "IPC_exec" function from GrizzlyAdams, but as far as I know, none of these were still effective in my tests.

Clearly, my initial suspicion that there was something wrong undetected with the latest version wasn't correct, so I'm rather looking at what such code is sensible about.

[WinterMute]

Using custom arm7 code from random people is generally a good way to break your project and make it unmaintainable.

I'm still at a complete loss to understand why people want to launch nds files from other nds files. Hbmenu works well and will continue to be improved and updated, as will dslink.

I'm also disappointed to see that you're still labouring under the misapprehension that devkitPro has versions - we're a toolchain vendor, not a software package.

[PypeBros]

What would the implication of an (accidental) extra call to irqInit() in that regards ? Iiuc, irqInit() is now part of the system initialisation code that is called before main(), right ? shouldn't it become a library-internal function to avoid chaos ?

@wintermute: yes, clearly, trying to do ARM7 integration myself produced a lot of trouble, but it was necessary at least when I did it (no tool of my knowledge integrated XM player on the ARM7 together with Wifi support back in 2007). I now want to move on, improve the manageability of the project as much as possible.

I'm still at a complete loss to understand why people want to launch nds files from other nds files. Hbmenu works well and will continue to be improved and updated, as will dslink.

I will give a more in-depth look at hbmenu and see to what extent it fits my needs. So far, having programs that were capable of retrieving an updated version of themselves and launch that version proved to be superior for comfortable development against uploading the .nds through a general-purpose program, come back to whatever menu and boot the uploaded program.
Maybe it will help you understanding the why (regardless of whether it's actually a good idea) if i tell you I am actually working on a sprite editor, a map editor and a game engine together that I prefer to keep as separate binaries so that they remain (imho) manageable projects. I'm afraid I'm more a hacker than a "regular user", too, and I can't help messing up with the guruMeditation function when I think it will help me locating a bug.

I'm also disappointed to see that you're still labouring under the misapprehension that devkitPro has versions

Feel relieved: I have well understood that there is no such thing like "devkitpro-r32" outside of my own /home/pype/DS directory, and that's why I precisely pointed out the dswifi and libnds versions I use. Sorry if some of my posts made you think otherwise. I somehow do the software packaging into DS/dkp-r32 when I install all the latest version of the libraries together with dka-r32. I hope I'm not too much misunderstanding the way devkitPro project works when I assume that those libraries will work together better than if I upgrade libnds while keeping my old dswifi and randomly deciding to pick an intermediate libfat release.

PS: sorry, I've found hbmenu quite easily, but where (or what) is dslink ? All I do found is information about a SLOT-1 linker (I already have a R4, and it was hard enough to acquire).

[PypeBros]

I'm also disappointed to see that you're still labouring under the misapprehension that devkitPro has versions - we're a toolchain vendor, not a software package.

That being said, the project could use some clearer presentation of the motivation, what we do / what we don't do, who could use what. E.g. https://sourceforge.net/projects/devkitpro/files/ throws me tons of possible things to download, and at first glance, I wondered whether libogc would be an ogg/vorbis player, got surprised that the defaultArm failed to locate maxmod, etc. A quick reference sheet with one-line-per-console indicating which library is mandatory / recommended (useful for some examples, for instance) / not available / pointless (such as devkitppc for DS, obviously) for developing on some system could be a valuable hint for newcomers ... and respawning elders

[WinterMute]

What would the implication of an (accidental) extra call to irqInit() in that regards ? Iiuc, irqInit() is now part of the system initialisation code that is called before main(), right ? shouldn't it become a library-internal function to avoid chaos ?

Currently none of the interrupt handlers installed by the libnds startup code will work if you do that. I toyed with making it an internal function but there are situations where I want to override the startup initialisation and work with something a bit more bare metal.

I will give a more in-depth look at hbmenu and see to what extent it fits my needs. So far, having programs that were capable of retrieving an updated version of themselves and launch that version proved to be superior for comfortable development against uploading the .nds through a general-purpose program, come back to whatever menu and boot the uploaded program.

That's an interesting approach. I have a background in commercial game dev though so I've been used to uploading code to a devkit or debug station using tools made for that purpose. DSlink is part of the way towards something similar & I have plans to make it a lot better. Generally I tend towards avoiding specific development related features/code in games I'm working on - they take memory that may be needed by the game and add complexity which may have a detrimental effect on the game. Not that your approach is particularly awful, just something I might think about and then discard. If you already know there's an updated version of your binary then why bother with pulling from the DS when you can just as easily push from your dev box?

Maybe it will help you understanding the why (regardless of whether it's actually a good idea) if i tell you I am actually working on a sprite editor, a map editor and a game engine together that I prefer to keep as separate binaries so that they remain (imho) manageable projects.

Having sprite & map editors that run on the DS can be useful for getting colors right or even simply editing on the move. I'd probably integrate the sprite and map editors rather than having separate tools and maybe even keep them in the final game as a feature. Something that would probably be more useful would be overlays which I want to find the time to look at in the future.

I'm afraid I'm more a hacker than a "regular user", too, and I can't help messing up with the guruMeditation function when I think it will help me locating a bug.

How do you need to modify libnds for that?

I'm also disappointed to see that you're still labouring under the misapprehension that devkitPro has versions

Feel relieved: I have well understood that there is no such thing like "devkitpro-r32" outside of my own /home/pype/DS directory, and that's why I precisely pointed out the dswifi and libnds versions I use. Sorry if some of my posts made you think otherwise. I somehow do the software packaging into DS/dkp-r32 when I install all the latest version of the libraries together with dka-r32. I hope I'm not too much misunderstanding the way devkitPro project works when I assume that those libraries will work together better than if I upgrade libnds while keeping my old dswifi and randomly deciding to pick an intermediate libfat release.

Yeah, it's generally best to use the latest versions of the libraries and tools - they're mostly independent but there can be some issues caused by using random versions which haven't been tested together or where libfat/dswifi/maxmod have been updated for changes in libnds. libnds sometimes also depends on modifications made to devkitARM.

It's probably worth noting that devkitARM isn't specifically a DS toolchain but has been designed to be as generic as possible to allow writing code for a sizeable variety of ARM based machines and experimenter boards. I've been using it recently to play with code for the Cortex chip in SmartFusion FPGAs.

PS: sorry, I've found hbmenu quite easily, but where (or what) is dslink ? All I do found is information about a SLOT-1 linker (I already have a R4, and it was hard enough to acquire).

DSlink was the wifi uploader I created for sending code to a DSi - http://davejmurphy.com/dsi-mode-homebrew-anyone/ It needs a bit more work to be generally useful but quite a few people have told me they're now using it as their default boot code for dev on DS. Right now it's closed source but that will change in the future - there are a few parts of the current source that should be integrated into libnds.

I'm also disappointed to see that you're still labouring under the misapprehension that devkitPro has versions - we're a toolchain vendor, not a software package.

That being said, the project could use some clearer presentation of the motivation, what we do / what we don't do, who could use what. E.g. https://sourceforge.net/projects/devkitpro/files/ throws me tons of possible things to download, and at first glance, I wondered whether libogc would be an ogg/vorbis player, got surprised that the defaultArm failed to locate maxmod, etc. A quick reference sheet with one-line-per-console indicating which library is mandatory / recommended (useful for some examples, for instance) / not available / pointless (such as devkitppc for DS, obviously) for developing on some system could be a valuable hint for newcomers ... and respawning elders

The recommended way to install the toolchains on windows is using the devkitPro installer/updater which is linked from every update post in the announcements section. I also link to the getting started section on the wiki for devkitPPC/devkitARM as appropriate which lists the libraries.

Having said that, there is obviously a need for better documentation and more guides on DS programming - the rest of the consoles we program for too. The wiki needs a plan for population, I'm still not 100% sure on how best to present the wealth of information there is available. Any suggestions are much appreciated.

The motivation behind devkitPro was once to put together a halfway decent toolchain to mess around with GBA programming. Somewhere along the way that's mutated into making console homebrew as accessible as we possibly can.

[PypeBros]

Thanks for taking the time to read & respond. Not so many people around me have an opinion on those subjects ^_^

How do you need to modify libnds for that?

Hmm ... now that you ask ... I might have just copy-pasted the libnds gurumeditation function into myguru.C and then alter that.
.. I'll think about it next time.