1. FAST6191

    OP FAST6191 Techromancer

    Nov 21, 2005
    United Kingdom
    Back around this time in 2009 we had a quick discussion on the sort of programming languages it might be worth looking at as a ROM hacker. The DS ROM hacking world, much like general programming, has moved on in recent years so an update of the discussion was in order.
    As well as that we also want to use this to provide a quick overview on the state of DS assembly level hacking. Several assembly tools are probably missing and it looks like I should be a bit more link happy and/or have adopted a somewhat consistent formatting so feel free to suggest more for the list and discuss any aspect of ROM hacking related programming.

    Part 1- programming for tools

    Then as now though the requirements are pretty similar
    1) Has to be able to open any file of any type and maybe even into memory (realistically you are probably not going to need a 3 gig file in there for DS hacking but some of the iso stuff might so how you play it is up to you). This means the while some of the database/application specific stuff or the likes of R (a statistics focused language) and matlab might be able to bashed into form here it is not as easy as one line saying to open a file so probably best not to use those.

    2)Has to be able to do binary manipulation and preferably have it also able to work at a 1 bit level. Everything from shifts, rotations and flips to standard boolean operations (NOT/inverse, OR, NOR, XOR, AND and NAND*) is quite nice is necessary. This is important for unlike some higher level programming languages and similar things the methods ROM images use are still not inclined (which in and of itself is no bad thing) to declare an 8 or 16 bit entry for something that can be done in 1 bit. Remember 31 bits can easily address pretty much any file the DS will ever see and that leaves one bit free to do what it likes; NARC files using high bits to signify subdirectories being a good example.

    *chaining operations (NOT and OR operation and you get NOR) is not ideal but a perfectly acceptable solution.

    3)Is going to want to be reasonably able to make a GUI- sure you could build something as a command line tool and toss in an autoit frontend but this is more for when you are decoding 3d model files, 2d images and wishing to display a properly parsed info list.

    Strong or weak typed, dynamic vs static typing, support for object oriented (or one of the 2000 other ? oriented or paradigms) is probably not that important, however object oriented support is quite nice to have (not almost vital as it is for some program types but nice) and a bit of garbage collection is nice; having your program leak its way into a crash after someone spent half an hour redoing things might not endear you to the users of your program.

    Following on from that would be having existing libraries and classes in the base library or some permissive ones outside that. For reasons unknown there can be quite a gap between "ROM hacker able to pull apart complex formats" and "programmer able to do something to deal with complex formats" (even if they otherwise can rock some assembly and get stuff done there for assembly is really not a general use language these days) so it is nice if you, say, do not have to make your own libraries/classes/whatever for the stuff in the 2) requirement before you are able to start getting stuff done.

    Outside of compression and some of the more fun relative searching/other searching methods (an almost direct quote of various docs but this would be the underlying reason) the language does not really need to be that high performance. This is nice as many of the "easier" high level language languages do away with the complex but very potent/speedy in the right hands concepts that often trip less experienced programmers; think operator overloading, some of the more fun parts of inheritance and pointers. Sidenote, programming pointers and ROM hacking pointers stem from the same idea, however where ROM hacking pointers are absolutely essential to understand to be able to call yourself a ROM hacker the need to have more than a basic appreciation for C type pointers and such concepts is probably not that important unless you are actually using the language.

    Open source vs closed source. This is left to you to decide and although open source is always welcome it is by no means a social faux pas to keep sources closed in ROM hacking circles.

    Although much of hacking related programming is fairly self contained the popularity of things will factor into this as there are now nice compression libraries and similar sorts of things under various permissive licenses and integration between languages is often tricky.

    Visual basic finally seems to have fallen out of favour (probably to be replaced with VB.net or general .net) but if you are going to try bashing some older tools into shape it tends to be helpful to know a bit (remember visual basic and c# have some fair decompilers these days). Back on topic though the usual suspects

    C++ a nice site. Plain C has more or less fallen out of favour here but C++ still gets used often and is good to know. If you already know a bit about hacking and so a bit about programming and find having your hand held through basics puts you off learning the book "Apress Beginning C From Novice to Professional" ISBN13: 978-1-59059-735-4 is well worth checking out, indeed what has been seen of the Apress Beginning series is good for most languages. It is occasionally nice to know how to work cygwin.

    C#/.net and various related languages/frameworks (VB.net for instance). The languages falling under the .net umbrella are quite nice, quite easy to pick up, quite fast and still very powerful which is all made even nicer by .net now being standard on most windows machines. There is also mono (see also MoMA) for unix like operating systems but ROM hacking is still a bit of a windows only game (although nobody will object to you trying to change that). Doubly nice is C# can often be decompiled or something very close to it.

    Python. Good book on it although the bundled help files are pretty good as well. A very high level language (it actually has a sort of active interpreter if you want) and one of the many people had half expected to see take off as it is almost tailored to the needs of ROM hacking. Indeed using it for everything from basic binary work right up to format translation/intermediate programs to small database parsing/conversion is quite common outside ROM hacking and it does have the likes of py2exe to make standalone tools with no need for frameworks or runtimes.
    Still it has seen a fair bit of use around the place with Deufeufeu doing a lot in it up to and including some custom animation formats seen in Phoenix wright, some of the fire emblem hacking crowd have made nice tools in it, vgmtoolbox (one of the best audio rippers for the DS) has a bunch of stuff in python and somewhere along the lines I grabbed a bunch of parsing/specs for some of the common DS formats written in python when traversing some of the Brazilian ROM hacking sites written by a guy named DiegoHH* so as such I am not prepared to drop it from the list. Back when I might have also included similar languages to python (very high level but with all the requirements met, quite easy to pick up and not terribly high performance) like perl, lisp, Ruby, scheme and lua but they are not that well represented, by all means use them though and they are used in such scenarios for other systems. It should be noted that Lua is the favoured scripting language of several emulators (including Desmume) and tool assisted speedrun tools (which can be good for hacking as well) and has been seen in commercial DS games as well.

    Java- despite often being taught to programmers as a primary use or even sole language for a decade or more, a time that has seen many new ROM hackers appear, and fulfilling all the requirements it was under represented then and now (which is nice as it means my machines tend to no longer rock the java interpreter). Still a few very noted tools like low lines' console tool use it.

    php- mainly used for online save editors, cheat makers (where there could be thousands of possible cheats) and similar tools (in short manipulation of documented custom and highly specific formats). Not something people would suggest for day to day work and certainly not as a "learn this language to make hacking tools" option but possibly worth knowing about. Similar story for JavaScript.
    Little has been seen to use autoIT of late (and although it can manipulate at a binary level there are better options really) as far as ROM hacking tools go other than some very quick and dirty command line wrappers so that loses out.
    A handful of things do use actionscript and/or Adobe AIR- romhacking.net topic for a DS audio tool and Atrius' GBA audio player which is interesting although actionscript/flash might not be everybody's cup of tea as it has to use runtimes and is not that respected as a serious general purpose programming language (interfacing with other things is not as easy as it might be for one).

    I have not seen anything use one of the more trendy languages like node.js or something.

    Finally a site with a lot of links to things you might be interested in, it covers many languages, frameworks and more.

    Probably very crude but it gets the job done and certainly worth knowing-
    batch files and bash/shell scripts- most lower level DS ROM hacking tools if they are not entirely command line driven at least have command line options and when combined with the likes of filecutter (http://crackerscrap.com/ - get it under projects), some compression tools (dsdecmp and Cue's GBA and DS compressors) and if your hex editor lacks a nice search or indeed you want a really custom thing then with astro grep, gsar (binary grep is now a thing thing really but not quite as widespread as you might imagine), WordCount and Monkey-Moore (granted not really a command line program) you can do some serious damage.
    Couple this with a spreadsheet which tend to have hex to decimal conversion, a nice fill command and basic maths you can often get files and formats decoded well enough to allow work to happen on them as you start building tools to put it back together or finish reverse engineering the format; for instance you can quite often tell a file is compressed and where it is but you might not know how or indeed if the format keeps a track of locations or has flags for things all of which needs to be solved but is not of great interest to the person doing the translation.
    Going further there is the likes of powershell which is an optional addon for windows aimed at system administrators, where the regular shell is quite potent in the right hands this is more or less a full programming language.

    At not quite full programming but still very nice and quite happy to be wound into the batch file stuff is radare2 http://www.radare.org/y/

    Some of the ROM hacking, for want of a better term, "IDE programs" like console tool, MKDS course modifier (nowadays a potent general purpose tool) and Tinke are getting some fairly powering scripting engines/plugin options. Equally stuff like hex workshop file formats/structures still make an appearance and hex editors like XVI32 and tiny hexer (two of the three suggested freeware editors) can have some scripting options built in.

    Also worth a mention is the likes of the susie plugins for some of the graphics formats.

    *for the curious (I am presently collecting such things to upload in one massive collection/parse for something nice)
    narc.py ncer.py ncgr.py nclr.py nftr.py nsbmd.py nsbtx.py (those not so familiar with SDK formats those are an archive format, a selection of 2d formats, nftr is a common font format and the nsb stuff is SDK 3d formats). nvwr googlecode has them for the curious.

    Part 2- assembly hacking
    The other side of this is assembly hacking and some basic tools here.
    First the general overview of DS commercial games and how their assembly works. This is not intended to be a full tutorial but if you know some assembly for another system or need something to point you in the right direction hopefully this will do it. The GBA and DS are fairly straightforward without much legacy stuff, omitted functionality (the big two being memory being handled by a specific instruction rather than by any instruction or DMA and no divide in processor- maths functions are available at BIOS and hardware level for the GBA and DS), workarounds, modern concepts like branch prediction/heavy pipelining and seemingly illogical practices to drag it down.
    You have four main classes of binary
    arm9- the main workhorse of commercial games (homebrew can and does do things differently on occasion). They tend to run from a given location in the ram but occasionally it is different (check every time basically), any half decent header parsing tool (like NDSTS) will tell you where it is found and the entry point for it all.
    arm7- almost a precompiled binary included with DS ROM images (you can almost always swap them between ROM images of a similar age with no ill effect). Usually nothing of great interest to ROM hackers is found here (it mainly being used for basic donkey work, IO and such) but sometimes if you are dodging AP or wanting to hook something then look here.
    arm9 overlays - the DS can set aside sections of memory (from none to several) for these binary fragments that can be loaded in and dropped as necessary. Essentially what your computer does when it uses DLL files but a lot more crude. Most header viewers will not tell you what goes but Crystaltile2 will tell you where they will be loaded to and how large they are. A handful of games have been seen to use binaries and overlays exclusively for everything up to and including media assets but they are rare.
    arm7 overlays - courtesy of the arm7 stuff above these do not really exist.

    The ARM9 and ARM7 are in memory from power up of the ROM to when it powers down, overlays can appear and vanish at any time so if you are making cheats to change the binary be aware of this if you have to edit an overlay as you will probably need some kind of check.

    They are found in 3 main locations-
    1) as what the ROM itself uses and every self respecting file system parsing tool will get them.
    2) as part of the utility.bin (especially if found in a dwc directory) aka the download play component*.
    3) within a SRL file, these are usually part of debugging and not usually seen in ROM images but some exist and can be useful to look at.

    All three should be able to be extracted with something that can unpack DS ROM images but realistically you will spend most of your time editing the files from 1) as altering the download play components completely breaks signing, this means if you edit them you need flashme on the receiving DS and with flash cards as cheap as they are you might as well get another to play proper multiplayer with and the srl stuff is usually a leftover from development.

    *most of the time download play is in utility.bin files but not always.

    Some ROM images like puzzle quest have been seen to use odd compiled/"bytecode" forms of lua and plain lua was seen in Theta but most seem to come from the C family of languages and thus are capable of being disassembled at some level, homebrew on the other hand has a long list of supported interpreted languages. Graphics subsystems and pointer maths aside (both for obvious reasons) dynamic recompilation or indeed anything resembling polymorphic code tends only be limited to those using cheats to tweak the binary but AP aside* there is nothing to stop it; no real memory encryption or hashing to speak of outside of those things that frustrate cheat makers (mirrored, complementary, tweaked and other such tricks you learn about once you start making more complex cheats), save editors (saves will often have a basic hash/checksum) and flash card makers (the DSi and 3ds added a measure of binary verification but this only applies to the ROM they use to bypass the checks and nothing once the console is under their control which is where the ROM hacker steps in).

    *one of the main methods is doing checksums/hashes on the binary in memory to see if it has been changed.

    Unless it is in a download play component then ARM7 tends not to feature it but the ARM9 and ARM9 overlays can and do use a custom form of LZ compression (where most LZ starts at address 0 and goes from there this tends to start from the end of the file and works backwards). Decompression tools like those mentioned above in batch files are now available and if not you could always snatch the binary from the RAM; binaries are copied to the DS ram to execute which naturally means they need to be decompressed. Tools like crystaltile2 should be able to detect binary compression with the filesystem viewer changing the icon accordingly but if you plan to edit the file you are advised to manually unpack (just use Crystaltile2's export option rather than decompress) and use one of the standalone decompression tools to handle things here. The overlay table itself will contain a listing of what is compressed meaning you can dodge having to recompress if you want.
    Equally binaries are not mandated to only be for executable code and executable code alone; text* (overlays are quite fond of this), graphics, fonts and more have been fished out of arm9.bin and overlay files over the years as well as the general things that come with coding in general (create an array and it will end up as a bunch of hex in the binary and similar such things). Along the same lines although the good programmer would reference and return memory values to proper memory some values have been seen to live and operate on the stack/in registers for a long period of time.

    *unlike say the GBA where it was common or indeed almost mandated when it comes to the the DS this will be one of the few times your text pointers will be memory addresses or operate on them. This said there is nothing to stop the programmers setting a base address and then using some lengths as you see in file level pointers when it comes to dealing with the game proper, whether that scenario will see pointer arithmetic as seen in C or not is a different matter.

    The DS ARM9 and ARM7 (and GBA ARM7 for that matter) have two operating modes known as ARM and THUMB where ARM is 32 bit instructions and quite powerful (it is still RISC after all) where THUMB uses a more limited (both in number and increased restrictions) set of 16 bit instructions (give or take extras* for operands and offsets) to hopefully make for smaller code and faster executing code.
    Both modes and both processors can access the memory proper (although not in every instruction a la X86 - ARM has instructions explicitly aimed at memory manipulation) and DMA does exist, does not have too many quirks and is used extensively (standard reads are fast but DMA is faster and generally better) as are BIOS/SWI calls that can also access memory. Most things are mapped to memory somewhere but some of the DS extras (most notably 3d and touchsceen stuff) can be unmapped or write only and quite notably the DS game cart itself is not mapped to memory and instead uses a read command. The GBA cart has several mappings at different waitstates/priorities for the GBA and is still mapped on the DS although just the single one (0800000 through 09FFFFFF).

    *for some instructions this does mean a limited amount so some arithmetic can and may have to be done across several instructions to generate "large" numbers (the go to example is usually add 00FF to a register, shift it by 8 bits and add FF to the result- you now have FFFF in a register).

    ARM itself provides CPU listings ( DS and GBA ARM7 and DS ARM9) and architecture discussion but in addition to that
    The-Smallest-NDS-File is often worth a look as it part of the thought exercise that it is drills right down into what makes a DS ROM tick.
    ARM-Opcode-Map is also nice. Naturally gbatek specifications ( http://www.romhackin.../documents/542/ if that is down) has opcode listings, descriptions and encoding methods.
    More links
    Cracker's DS hooking tutorial (do have a look at the various other guides there).
    Quirky's Things you never wanted to know about assembler but were too afraid to ask
    Tonc's ASM section (aimed the GBA but the DS is not a great leap of logic away and it covers some very nice stuff).
    pineight.com GBA VRAM guide Developers often push VRAM to the limits and this can help you think like one that is doing the pushing.
    http://answers.drunkencoders.com/what-sort-of-sprite-hardware-does-the-ds-have/ A nice overview of the DS 2d hardware.
    http://drunkencoders.com/files/2013/03/unequivocal-answer.html What memory copy method is fastest and some tests, covers a lot of general memory manipulation which is often what trips up new assembly programmers.

    Three main classes of tools
    Several options really
    Many would argue wonder program reverse engineering tool IDA (IDA homepage) is the best option and they might even be right as it is certainly very powerful and there have long been plugins for extras like DS file system parsing (not sure where these stand right now as far as loading them into the current versions goes). It is payware though and entry level for non X86 is several hundred dollars (as of December 2013 "IDA Starter Licenses start at 589 USD or 449 EUR. IDA Professional Licenses start at 1129 USD / 869 EUR.", you only need the starter for GBA and DS purposes though). The standard/free edition does not comes with ARM? support.
    *ARM9 is nominally different to ARM7 and those differences are rarely used so by all means give it a go.
    ndsdis2 was a more historical disassembler (it was one of the first standalone ones) but did get a few updates back in April 2010
    ndsdis2 homepage and filetrip download
    Crystaltile2- naturally the DS wonder hacking tool has a disassembler. It is quite rough around the edges though like for instance in earlier versions at least (read not entirely sure if it is still there) the -1 flag that tends to signal a switch to THUMB actually got interpreted as -1 making for some odd addresses and values. It is also tied into the file system and header parsing options of crystaltile2 which can be nice as it lists what locations the overlays will end up at as well unlike many other tools.
    Crystaltile2 filetrip download

    objdump which is part of the GNU development kits (the ARM specific version being arm-eabi-objdump). Very basic (will probably not seek out things inside a DS dump, deal with compression and such like) but by no means does basic mean bad here.

    Emulators- often some of the nicest tools for getting a plain disassembly- as they are running the ROM at the time they usually can make sure you get THUMB where it is at and ARM where it is at, the others might have a tiny bit of logic at the best of times but not much (read never expect it on a standalone disassembler). Debugging grade emulators on the DS are not quite at the level of no$gba and VBA-sdl-h for the GBA but the DS features of no$gba (the debugging version is free as of July 2014) are almost at the level of GBA debugging tools, and to a lesser extent both desmume dev options and iDeaS have some things (iDeaS has some slightly nicer abilities on the assembly front like run to lines/selection).

    Equally there is something to be gained by coupling those with a hook like that of crystaltile2, emuhaste or renegadeEX as these have some debugging and assembly abilities but are aimed more at more basic cheats and when making the more advanced/far reaching cheats many cheat makers will have a toolkit that resembles this section more than a basic memory scanner).
    Datel's Trainer Toolkit probably should be mentioned as well- it does have some nice disassembly abilities.
    Probably worth noting is the NEF file format which started life as a Nintendo internal debugging aid but eventually got supported by no$gba (for a long time the premier publicly available (and by many accounts better than much of the private stuff) debugging emulator for the GBA and DS) and later crystaltile2. Personally I tend to describe it as something between a comments file and a more human readable memory locations option like you get in a proper/developer grade assembler.

    Assembler for full programs/routines
    Occasionally you will need to jump away from a function and make your own one (things like adding a variable width font where a Japanese game only needed to space characters/glyphs a set number of pixels from each other and indeed could use a simple multiplication to figure out when the line was done). Nobody ever really reassembles entire disassembled binaries though for the GBA and DS* (far too much effort to get right- any non binary stuff will have to be converted to and from hex to something noted for it and that is before you even get started on ARM and THUMB).
    *some older consoles have nicely formatted and commented disassembly files that should be able to be assembled.

    Naturally IDA has some serious abilities here but in the meantime

    armips- not that well known around here it would seem but one of the premier ROM hacking ARM and PS1 assemblers.

    armish- appeared quite early on and is mainly here so it could be said I snubbed lisp up above.

    FASMARM- a more recent addition to the crowd and as yet untested for this thread but is designed as an addon for FASM for those that prefer that.

    Assembler for fragments or maybe even instructions.
    More useful if you are just changing a handful of opcodes and do not fancy hand encoding them (although the feeling of making a radical change to the ROM by flipping a couple of bits is pretty good, again see the links at the start of the ASM section for listings/encodings).
    Crystaltile2- crude and possibly quite dangerous to use given tendency for crystaltile2 to see a bit of falling debris but find the instruction you want and press f10 and start typing a command and that should allow you to edit the instruction or sub in a new one. Syntax is fussy though which is probably a good thing.

    arm eabi- the assembler from devkitarm (although it is a general ARM assembler used by the GNU project). Although it can certainly do full routines and programs it is more commonly used for fragments and such.
    A workable frontend to it can be found http://gbatemp.net/up/cr-dstmt.zip (note this is part of a very old tutorial- http://gbatemp.net/t...maker-tutorial/ and you are better off looking at the hooking tutorial and the related ones there up above if you want something there). Also http://crackerscrap.com/ has some usage and a better download.
    "gARMy" is another frontend that might prove slightly more useful http://www.romhacking.net/utilities/456/
    http://microcross.com/GNU-ARM-Assy-Quick-Ref.pdf details some of the commands and expressions available for the things that we have grouped under "arm eabi" and is useful to keep around.

    For the GBA but something a bit more self contained

    There are a handful of other emulators mainly on the GBA that have a measure of ability here and a few more older programs like goldroad which is not really recommended. If going into homebrew you might also want to see liards and maybe some of the proper ARM stuff like the armSDT- it is one of the reasons moonshell stopped being developed at one point and why the likes of pocketnes and some other emulators that started life as one of the Loopy's projects can be a pain to assemble/"compile"; syntax changes are one thing (opcode, operand and offset ordering is almost trivial to sort by machine even if it is the cause of much high volume swearing when taking to a new assembler/system) and can be worked around easily enough but this adds a lot of niceties and it comes with a serious pricetag. Links are somewhat questionable but demos and old versions can be obtained relatively easily.

    Other binary tools.
    Earlier versions of DSATM allowed you to flood the ram with DEADBEEF and then you could watch it to see what areas were not used so many minutes in (do note some ROM images clear the ram at various points so you might have to drop that instruction) and thus could potentially be used for your cheats, expanded sections or new routines.
    4.3.4 was the last version to have it and you can find it on the link below
    http://crackerscrap.com/ has current versions and other nice tools.

    A header viewer and general ROM information tool. Although it does not feature some of the overlay information of crystaltile2 if you just want a quick dump of where the main binaries are loaded from, loaded to and initial execution position (it is rarely the start of the whole binary file) this tool will give it to you.

    Also probably they probably wanted to be somewhere else in this but VBA-SDL-h and some guides to it. Tracing on the DS kind of exists but with the ROM not be addressed in memory like the GBA you get to watch for card read commands (or the read function within the game) which is fine but at various points headers are loaded and then things calculated from them meaning you more often than not have several steps to work through (more if compression is involved) where on the GBA you are probably just looking for a simple read, DMA read or SWI call that bothers something in the 08XXXXXXh memory range (it does get slightly more complex as the GBA ROM starts at 08000000 and goes to 09FFFFFF if it is the full 32 megs and has mirrors that work as higher waitstates- 08 is the standard/most common and also kind of drop everything and do it/do it and damn the consequences)

    Over to you.
  2. StorMyu

    StorMyu "I'm too old for this"

    Jan 2, 2010
    I'd like to say that Part 1 doesn't necessary need an Object-oriented program, GUI can be good okay, but for 3D or 2D image I'd rather make a converter to a well known format and modify them using something.... let's say better, like Maya/Noesis/3ds Max for 3D Model, or Photoshop/Gimp/Photofiltre for 2D.
    But everyone can do whatever he wants, I'm just saying that a GUI is really optionnal.

    Very good read, there's stuff on the assembly part you need to talk about though, even if people who're doing them already know, but it's essential that you know how the DS works and lots of stuff (as described in Gbatek), if you come across a DMA transfer and you don't know what the hell is going on, you can be stuck for a while.
  3. FAST6191

    OP FAST6191 Techromancer

    Nov 21, 2005
    United Kingdom
    I had not really intended it as reference/sticky material at this point but thanks and I will try to bash into better form.

    Believe me when I say I consider object oriented somewhat overrated (probably as the first languages I took anywhere were C, ASM and various older flavours of basic- old commodore and similar consoles, qbasic and whatever my old vtech had) but it is quite nice to have around when you are doing many operations on a given value (even if the header is a fixed length or effectively fixed length I will still tend to want to declare a new variable rather than hardcode a value somewhere* unless perhaps I am doing a rebuilding stage and can almost call it a set string) and if you are going to be learning a language (and not for say drivers, embedded, legacy work or something in which case you probably would be learning C) then avoiding object oriented would probably do you a disservice in the long run.

    *probably not the best example as it would be hard to argue say ten (a generous amount of potential different variables for any one subsection- different subjections I prefer to have as different functions) probably obvious/clear and separate lines (commented naturally) is any worse than a long/split line containing a lot of variables all interacting.

    Conversion and GUI... it is probably more my overcompensating for the times I make the lives of any artists or translators I might be working with a bit harder by say leaving some programming hangovers in the text (necessary sometimes unless you want to head down the note wherever everything is and try to remake it later or fully custom editing tool route but I could go a step further and turn it into a nice XML a like tag instead of the lots of binary mess but with a nice note on what goes that it often ends up being). Also I was thinking more along the lines of the times we might abuse the command line output of a tool to direct a more general purpose tool to display the file you want (me doing it for a 3d format http://gbatemp.net/topic/319635-extracting-textures-from-an-nsbmd-file/ ) or to display the data to direct a hex editor to do what needs doing (see SDAT repointing where I am probably going to be too lazy to parse the header manually and will instead get crystaltile2 to do it and then use that data to carry on). I shall have to look more at Photofiltre though (seems like a nice middle ground between paint.net and gimp).

    I should also say if you are going down this path try to make sure your language or setup for it sports a nice library as trying to implement a spec compliant output (let alone all the "forks", broken implementations and "enhancements") is not a nice thing. JPEG for example http://www.w3.org/Graphics/JPEG/jfif3.pdf and I guess also see how despite HTML, CSS and javascript being pretty straightforward as far as things go there is still such a thing as a less than perfect score on acid3 tests.

    As for the ASM section I was very much trying not to make it an ASM tutorial (indeed I am actively trying not to write an ASM tutorial right now) and rather have it so someone that knows ASM for something else (mainly other rom hackers that might be used to other platforms but someone that uses inline assembly, such that it still exists, I guess too) could get something done or maybe someone new and wanting to learn could have it as a jumping off point. I did make a quick edit just now to add a tiny bit on tracing though.
  4. StorMyu

    StorMyu "I'm too old for this"

    Jan 2, 2010
    Oh yeah, but I was more thinking "Romhacking", if you're programming for the game itself, of course it'll be better to have a nice GUI for that, as far as I'm concern, I really think it's simpler for any graphic editor to have a common format and if there's something to take care of, I make them aware of (like taking care of the Color depth or something).

    And I do C btw, I'd like to learn C++ but I don't have much time and I'm good with C for what I'm doing.

    Yeah, trying to make an ASM tutorial is really tricky, because people are not aware that you actually have to learn a lot about the console you're actually hacking. (02000000h Main Memory, if you didn't know that you really have to learn about Memory maps for example.)
    Or even how the Vram works (all the BG modes with the two different Engine for the 2 screens.)

    Anyway, thanks for it it helps a lot.
  5. loco365

    loco365 GBAtemp Guru

    Sep 1, 2010
    Holy hell lotsa stuff there. I plan to read this later when I get back from handing in resumes.
  6. Ziggy Zigzagoon

    Ziggy Zigzagoon GBAtemp Fan

    Aug 6, 2010
    I.... have a question regarding this:
  7. Kajitani-Eizan

    Kajitani-Eizan GBAtemp Regular

    Feb 4, 2013
    United States
    armips is great.

    and did you say the no$gba developer resurfaced recently? where did you hear of this? :P
  8. FAST6191

    OP FAST6191 Techromancer

    Nov 21, 2005
    United Kingdom
    He came back and released a pretty good SNES emulator (still early beta but I would put it alongside ZSNES, snes9x and BSNES for a few games) and some hardware docs that might one day sit alongside gbatek and GB/GBC pandocs as the hardware reference documents for those consoles.

    I do not know about and have not heard anything about anyone being able to get their hands on the developer/debugging versions of no$gba though which is a pain as it is by some way still the best debugging emulator for the DS.

    As for the python question I highly rate the former and is available as a download for free http://greenteapress.com/thinkpython/thinkpython.html but I have not checked out the second beyond reading the first few chapters and some other stuff just now. It seems a lot more 3.0 focused (although the former by no means ignores it) and I reckon is more for businesses that have to get their programmers up to speed (good at it though) although others will probably do OK as well.
    Edit- actually the former does not seem to be an O'Reilly book so I might be way off.
  9. SteelLord
    This message by SteelLord has been removed from public view
    Sep 8, 2012
  10. FAST6191

    OP FAST6191 Techromancer

    Nov 21, 2005
    United Kingdom
    Visiting drunkencoders for the first time in quite a while it seems they have some interesting things up there

    What memory copy method is fastest and some tests
    As the complexity of ROM hacks increase the need to stream data from memory is useful, already seen in things like http://gbatemp.net/threads/telling-the-game-to-play-a-strm-instead-of-sseq.340692/#post-4511267

    A nice little guide to the DS 2d Video setup, previously I had used http://www.coranac.com/tonc/text/video.htm (made for the GBA really), http://nocash.emubase.de/gbatek.htm#dsvideo (obviously) and my own attempt at the matter.
  11. takeya yuki

    takeya yuki I am now someone waifu.

    Feb 27, 2016
    Hello sir, can I know what sbb file and txg file use for? I find that file on extract file from PSP games.
Draft saved Draft deleted

Hide similar threads Similar threads with keywords - programming, programming, languages