Nintendo DS Hearsay - things people have said about homebrew development for the ds

[[website|http://www.btinternet.com/~ahcox/]]

''wintermute:''\n<<<\nWe don't default to -mhard-float, we actually default to soft float libraries but the resulting object files are marked as hard float for various historical reasons. This is actually a long standing problem with the marking of arm elfs and one that's difficult to address without breaking compatibility with various libraries. \ndevkitARM is in use by some official developers in conjunction with the official libraries which are marked this way. Defaulting devkitARM to mark objects as soft-float would remove the ability to work with all of the licensed libraries which are available for GBA or require them to provide another set built with devkitARM.\nSince the official toolchain and all other toolchains provided for the GBA ( HAM, devkit advance etc) use hard float marked object files it would be counter productive to make devkitARM behave differently.\n{{{\nARCH := -mthumb -mthumb-interwork \s \n -march=armv5te -mtune=arm946e-s -Wa,-mfpu=fpa \n\nCFLAGS := -save-temps -g -Wall -O2\s \n -fomit-frame-pointer\s \n -ffast-math \s \n $(ARCH) \n}}}\n[The above options in your app's makefile-andy] allow everything to link. Note the -Wa,-mfpu=fpa - this passes the parameter to the assembler, forcing it to mark the output as hard fpa while leaving the compiler in the default soft float ( but marked as hard ) . You don't want these parameters being used on the compiler as it will generate hardware floating point instructions. \n<<<\n

[[Introduction]]

''poslundc wrote:'' \n<<<\n*Reciprocal LUT (only works within the range of your LUT) \n<<<\n''kusma wrote:''\n<<<\nJust a quick note: if you count the leading zero-bits, then you can quite easily normalize the number, and use a lut for the entire range. you don't really need a big lut to get acceptable results for stuff like 3d-projections either. \n<<<\n''poslundc wrote:'' \n<<<\nInteresting idea. So is it pretty much as follows: \n*Count the leading zeros in your denominator \n*Obtain the difference between that value and the range of your table (say it has 256 entries, you'd subtract 8) \n*Downshift the denominator by that value, and look it up in your table to obtain the reciprocal \n*Upshift the reciprocal (presumably into a long-long) \n*Multiply \nPresumably you'd have to throw in a test for negative denominators as well and negate your numerator if you encountered those values. And depending on the precision of your LUT's values and the size of your terms it might be necessary to save the upshift until after the multiply. How does this work out in practice, and how does it stack up against other techniques, like interpolating between LUT values? \n<<<

Compression tool for hardware decompress on GBA and DS.\n\n[[http://members.cox.net/jsensebe/gba/]]\n[[http://members.cox.net/jsensebe/gba/GBACrusher.zip]]

pan69:\n<<<\nI've been using the GNUARM toolchain ever since (www.gnuarm.org), which is quite up to date if I may say so, and I never had any problems with (other then stupid mistakes I made myself :)\n<<<\nsasq:\n<<<\n....works great, with all the benefits of 3.4 optimization, and it has a java and Insight. Hadn't heard about it before but looks like I'm switching, thanks :)\n...well it worked great in linux anyway, in windows I get this problem: \n/cygdrive/c/program files/gnuarm/bin/../lib/gcc/arm-elf/3.4.3/../../../../arm-elf/bin/ld: ERROR: demo.o uses software FP, whereas gbademo.elf uses hardware FP \nfor basically all my files. So its strange because it seems all my objectfiles and libraries are compiled as softfloat and still it complains\nFound the problem. You need to specify \n-mfpu=softfpa \nfor ass assembly files or it wont link.\n<<<\n

This page contains things scraped off forums and blogs, compiled, tagged, summarized, edited and generally messed with. It does not constitute [[documentation]] and the standards applied in it's compilation are very low. Neither the original information nor the changes I have made are guaranteed to be correct but they are likely to contain some grains of truth.\n\nWhile this is a wiki, there is no back-end so your edits are local only. Feel free to send me your content by email though.

LiraNuna said:\n<<<\nIf you want to extract to VRAM, it will take some damn tricking... \n{{{\nint getSize(uint8 * source, uint16 * dest, uint32 r2) \n{ \n u32 size = *((u32*)source) >> 8; \n return (size<<8) | 0x10; \n} \n\nuint8 readByte(uint8 * source) \n{ \n return *source++; \n} \n\nvoid decompressToVRAM(const void* source, void* dest) \n{ \n TDecompressionStream decStream; \n decStream.getSize = getSize; \n decStream.getResult = NULL; \n decStream.readByte = readByte; \n swiDecompressLZSSVram((void*)source, dest, 0, &decStream); \n} \n}}}\nAll you call is decompressToVRAM, the others are "Helper functions" needed by the decompression stream. \nBe sure to compress with GBACrusher with the option ~LZ77 (VRAM safe)\n<<<

[[profile|http://forum.gbadev.org/profile.php?mode=viewprofile&u=4241]]

[[Home|http://www.btinternet.com/~ahcox/]]\n----\n[[Introduction]]\n----\n[[gbadev|http://forum.gbadev.org/viewforum.php?f=18]]\n[[TiddlyWiki|http://www.osmosoft.com]]\n

things people have said about homebrew development for the ds

[[Nintendo DS Hearsay|http://www.btinternet.com/~ahcox/DS/]]

Where to go to look something up with some confidence that facts have been checked:\n*[[NDSTech|http://www.bottledlight.com/ds/index.php/]]