Quotesorgekeeke, you can check thread in libwiikeyboard (keyboard.c).. Yes, unless I don't understand the code, this seems to be an error static u8 *_kbd_stack ATTRIBUTE_ALIGN(8); static u8 *_kbd_buf_stack ATTRIBUTE_ALIGN(8); This should not be declared as an array of pointer but an array of bytes, right ? This shouldn't lead to any problem though , the reserved memory is jusby ekeeke - Coding
QuoteI saw in some places of libogc: it sets stack for some threads using static allocation inside data section of binary which looks terrible for me. Probably libogc does some similar nasty things while IOS reloading... hum, where did you see libogc doing that ? Data section is copied from the .dol by the loader and left untouched by libogc, otherwise NO application would work correctly. Theby ekeeke - Coding
This is very simple: those emulators were released BEFORE the new HBC update, they need to be recompiled to take libogc changes in account regarding USB, the fact they are the "last stable release on Wiibrew" does not mean very much, what matters is the release date. And FYI, you could have read my comments on your issues and you would have noticed that it got "invalidated" because technicallby ekeeke - Homebrew Applications
yes, this is the cause of the problem, your loader should be running from 0x81200000 and it isn't it must be a problem with your makefile, it should have this line: LDFLAGS = $(MACHDEP) -Wl,-Map,$(notdir $@).map -Wl,--section-start,.init=0x81200000by ekeeke - Coding
I am out of ideas, sorry. maybe post infos from doltool for your loader .dolby ekeeke - Coding
well, I'm not really sure if using read works, in theory it should but I never tried it. again, you should really use a loop to read file in smaller data chunks; like this: /* Open file */ FILE *fp = fopen("sd:/apps/pngmove/boot.dol", "rb"); if (!fp) { printf("null dol\n"); sleep(1); return 0; } /* Read size */ fseek(fp, 0, SEEK_by ekeeke - Coding
Beware that IOS is using the upper 12-16MB of MEM2, if your code is running from there it obviously can cause issues with running IOS. Also, DOL loaders (like the HBC) uses MEM2 as data holding space so it's generally not a good idea to make the DOL you are loading use this area as well, when it will be copied in memory, it could overwrites the loader data. I guess that more details on thby ekeeke - Coding
Have a better look on how to use the "read" function, your code actually makes no sense at all. But anyway, the best way to handle this is, as I told you, to call multiple fread on smaller data chunks, in a loop. And you are still not checking the result of "fopen" before continuing, you should REALLY do it. I don't want to be mean but honestly, I think you should first be fine with Cby ekeeke - Coding
1/ don't allocate and don't free bufptr, just make it point in MEM2 like you are doing, this is fine 2/ don't use a fixed size when reading your .dol file, revert into using fseek + ftell, this works and this is what it is for 3/ I/O read are now unbuffered in devkitppc/libogc, this means that reading too big chunk of data with fread can fail: use the read function or make a loopby ekeeke - Coding
Most likely, your loader is compiled to be executed from the same memory address as the dol you are trying to load, the result is that the relocate function, which copy the .dol into memory, will overwrite the currently executing code, resulting in application crash. You need to modify your makefile, adding --section-start,.init=0x81200000 to LD_FLAGS should work. You can adapt this aby ekeeke - Coding
One of the first thing to take care when you port some existing code is the endianness. If the information in files header (id for example) is larger than one byte , you might need to do some byte swapping first.by ekeeke - Ideas, requests
this version of smsplus gx is too old , there wasn't any SDHC support at that time for homebrew. there is a pre-release version here that you can test, it has been compiled with up-to-date libraries .by ekeeke - Homebrew Applications
This is how I understood the whole issue (please someone more competent correct me if i'm wrong) By default, homebrew compiled with the old libogc automatically reloads IOS36 on startup (if not found it uses IOS35, IOS34, etc..) so what the loader did before is trashed anyway, be it last HBC that reloads (or keeps) IOS61 in memory. I think that the code that has been used to reload IOS sby ekeeke - Homebrew General
95% of time, this issue arises with people who have "soft-modded" their Wii and modified their IOS, it seems that uninstalling DVDX then reinstall it using last Hackmii Installer usually fix it. If it still doesn't work, try removing DVDX completely.by ekeeke - Getting Started
Someone should remove this from Homebrew Browser, it's definitively not an official update but a mistake from one commiter: he uploaded the current SVN (unstable) version after adding SMB support and labelled as official one. There are lot more changes than just SMB support in the current SVN and lot more things to do (including proper documentation of the changes) before releasing it officby ekeeke - Homebrew Applications
Regarding Wii homebrew, calling exit() is actually cleaner since it properly handles libogc exit (threads shutdown, memory freeing, return to HBC, etc). Remember there is no OS, if you just use "return", your application will hang and your only choice is to reboot the wii manually (well, I think so, never really tried). Actually, there is absolutely no advantages in using "return", you can fby ekeeke - Coding
The copy operation is not immediate, you need some synchronization to tell you when it's finished. GX_PixModeSync(); GX_Flush(); usually do the job Don't forget to also flush texture data from cache before using it since it was modified externally by the GPU DCFlushRange(renderScreen3D, 256*224*4);by ekeeke - Coding
What version are you using ? There shouldn't be any problem here if the wiimotes can be used in other emulators. If they don't, it means they are not properly synced (again, they must be synced permanently using the buttons on the Wiimotes and WIi) QuoteI tried that before, but the configuration of the first controller is disabled if I configure 2P. I don't understand, what doby ekeeke - Homebrew Applications
you need to: (1) make sure all wiimotes are registered in the system menu using the "red sync button" (this is a requirement for all homebrew applications) (2) configure controllers in the emulator option menu (by default, if two controllers are detected, they would automatically be assigned). If you only have one wimmote+classic controller, you can also configure the emulator so player 1 uby ekeeke - Homebrew Applications
I am not sure what GPGPU really means to you or what you believe it would brings for Wii programming but I'm pretty sure the Wii/GC GPU is already a very well known picece of hardware since official leaked documentation is very detailled about what you can do and what you can not do and quite everything is already handled by libogc for years (including hardware antialiasing and the Commandby ekeeke - The Junkyard
QuoteEven if the roms were not in the correct location, wouldn't the emulator still run? Or would it still freeze on a black screen? I see, I missed that part ... if the emulator just give you a black screen when launching it from HBC then it has nothing to do with the location of your ROM files, it's a problem that occurs way before you can even attempt to load a game. Try to reinby ekeeke - Homebrew Applications
Don't you guys never read the README included with apps ? There is no "magical trick" ,setting up various emulators the "same way" or placing ROM files in multiple directories to get this working has no logical meanings. (1) genplus will look for roms in sd:/genplus/roms or directly let you browse from the root if this directory does not exist (2) snes9x/fceugx,vbagx will also look inby ekeeke - Homebrew Applications
It should already be supported automatically (if it detects MPAL setting in Wii configuration, libogc will use MPAL video mode by default), what issues do you have ?by ekeeke - Homebrew General
well, you didn't search very hard: first link in the Starlet wiibrew page ;-) QuoteChapter 2 Programmer’s Model This chapter describes the ARM926EJ-S registers in CP15, the system control coprocessor, and provides information for programming the microprocessor. and, further in that chapter: QuoteTable 2-18 Cache operations c7 Function/operation Data format Instruction Invaliby ekeeke - Software
It's in /shared2/sys/SYSCONF which contains other configuration settings as well. The entry you are looking for is "BT.DINF". Note that this is directly taken from conf.c in libogc.by ekeeke - Software
I've been researching the same thing some time ago. coprocessor 15 is used for system configuration. cr are coprocessor registers. You can find register descriptions in the official ARM9 documentation (I don't think it's Wii specific, please correct me if I'm wrong), see links on the Starlet Wiki .by ekeeke - Software
Well, this build is quite old, current revision is now 410 On that matter, there have been some major improvments to the core recently regarding emulation accuracy and audio/video sync issues. Nothing really much worth the interest for most users I guess but still, the gui is also being regularely worked on, so I can only suggest you to learn how to grab the code from SVN and compile it yourseby ekeeke - Homebrew Applications
You need to permanently register the wiimotes in the System Menu, this is different from the temporary synchronization that you got by pressing 1+2. Read your Wii user manual to know how to register additional wiimotes (using the red sync buttons). The reason is that wiimotes are shutdown when leaving the system menu and homebrew applications need to retrieve bluetooth informations to be ableby ekeeke - Homebrew Applications
genesis plus does not not emulate the Sega CD, the option is to load roms from DVD you might also read the user manual that was (well, should have been, apparently) coming with, everything you need is explained, including what the emulator does and does not.by ekeeke - Homebrew Applications
I've added him as project contributer on both projects but didn't heard of him anymore. Generally speaking, there are a lot of "motivated" people out there who wants to help or just do something but unfortunately it's one thing to be willing to add support for complicated things and another one to actually be able to do it .by ekeeke - Homebrew Applications