1. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    I just found the direct sound limiter for the game I'm working on, but it still won't play more than 6 sounds. The series of bytes starts with (C6) and ends with (04) and when I changed it to (C0) samples would not play at all so I know that has something to do with how many direct sounds can be played. The problem I'm having here is that when I increase it the game only still play's 6 samples and no more. Is that a limitation of the hardware not being able to keep up with the game or is there something I'm missing?

    (One thing I forgot to mention is that when I changed that C? byte I noticed there was a little clipping than usual, but its not too bad.)
     
    Last edited by biolizardshadow, Sep 12, 2020
  2. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    33,485
    Country:
    United Kingdom
    Without looking at the game and how it handles things, and then figuring out if there is a way to get more out of the system/sound engine, I doubt anybody is going to be able to tell you.
     
  3. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    I'm sure there is a lot to this but what should I be looking for? I would like to learn how to modify the sound engine so I can preform these tasks. Is their some tutorial I could follow or some sort of guidance to be able to know what does what and how to change things cause at this point I am very invested in to the Gameboy Advance and have come a long way from when I started.

    Do I really need to worry about the game? As long as it uses the M4A sound driver things should be relatively the same but with different values. I used a Pokemon music hacking tutorial to find the direct sound sample limit and I'm not even hacking a Pokemon game. It's just that the bytes were similar thats all.
     
    Last edited by biolizardshadow, Sep 13, 2020
  4. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    33,485
    Country:
    United Kingdom
    Pokemon often stands somewhat aside.

    Anyway it sounds like you are going for a "top down, change anything and everything I might want to change" type approach where most work up from fiddling with instrument banks, changing tracks, changing loop points within tracks, changing volumes, changing what is played when... and eventually gain enough understanding that they can do most things, and maybe push it harder than it was originally.

    GBA audio hacking then has four main aspects.

    1) The Nintendo provided audio format. Usually known as sappy to most ROM hackers despite it not being the technical internal name for it.
    https://www.romhacking.net/documents/462/ for the general overview. romhacking.net generally having most tools on the matter too, sappy (which has various forks) then being the main tool most are introduced to all this wirth. Not quite as ubiquitous as the SDAT format on the DS (there are so few I maintain a list of exceptions https://gbatemp.net/threads/the-various-audio-formats-of-the-ds.305167/ ) but still used in an awful lot of games.
    Game wise then most people doing good work with it are either

    Pokemon (though pokemon has its own subtle tweaks, some will go with assembly and most are more interested in looping and injection of other tracks)
    https://www.pokecommunity.com/forumdisplay.php?fn=fan-games-hub is a good start, though hacking is available/discussed across several specific sites and has a few game specific tools also available.

    Fire Emblem
    https://feuniverse.us/t/music-insertion-guide-for-beginners/3791
    http://www.feshrine.net/hacking/musiceditors.php
    http://www.feshrine.net/hacking/Fire Emblem Music Hacking Tutorial.pdf

    Assuming it is not mired in drama then Golden Sun often has some nice stuff made for it, including the voice acting experiment
    http://forum.goldensunhacking.net/index.php?action=downloads;sa=view;down=4

    Mario Kart maybe but interest in this game dropped off somewhat. Castlevania had a few looking at things. The same guy that wrote the sappy notes documents above is also responsible for the various GBA sound improvements for the final fantasy games, though that is the extent of most things there.

    2) Krawall. Technically a XM/s3mplayer so might merge with below but was used in various commercial games, which it notes
    https://github.com/sebknzl/krawall

    3) Other known formats. I am not sure what examples I have but there are some games that are neither sappy nor krawall, or for other things like video playback will use other means. If it is not a known format a la MOD, midi or XM then chances are you will be getting familiar with 4) below.

    4) Those that look at the hardware and work backwards from there.
    http://belogic.com/gba/ (navigation at the top of the page)
    http://problemkaputt.de/gbatek.htm#gbasoundcontroller
    https://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm#Sound Controls
    http://www.coranac.com/tonc/text/sndsqr.htm
    and might as well have
    http://www.coranac.com/tonc/text/asm.htm
    Even once you have all that you might still find yourself playing within the confines of some software defined setup, though if you are good enough there you can usually then say screw it, disable or expand as much of the game's base sound engine as you need to and do it all yourself -- on the DS https://nsmbhd.net/thread/475-tutorial-nsmb-sound-and-music-hacking-guide/ then bypassing the sound engine at points to play back wave tracks that the hardware but not that compile of the engine.

    Other than Bregalad who did the sappy notes and final fantasy stuff I don't know that there are many that grasp the limits of the GBA audio hardware (I can do stuff but compared to things on the hardware I do know well then not even close for GBA audio -- ask me about GBA graphics, ROM handling, CPU oddities, graphics and program flow and yeah, ask me about audio and while I can do something... there is a reason https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ has had the GBA audio in depth hacking section be "coming soon" for the better part of a decade at this point, though I am also barely musically literate, completely without rhythm and my hearing is shot to boot) and are anything like active. Some of the folks that did GSF back in the day (Caitsith2 I saw around from time to to time https://www.caitsith2.com/gsf/ https://github.com/loveemu/gsfopt has a few things but mostly did other stuff and I don't know if anybody is still hanging around https://www.zophar.net/ )
    If I were to go looking I would go either to emulator forums (granted GBA audio is not quite as contentious as SNES and megadrive so less likely to find things there other than those that just implemented the hardware docs above), https://hcs64.com/mboard/forum.php (long regarded as one of the foremost forums covering game audio, and source of many great tools) and whatever people are doing audio plugin development for GBA/general game system sound rips ( http://vgmpf.com/Wiki/index.php/Highly_Advanced being a staring point for foobar2000 and gsf) as they will also be able to tell you about all the various decays, timings and whatever else their poor golden ears might discern, and oddities they might have encountered putting together rips.

    Playing with this will probably also see you develop a reasonable understanding of assembly driven hacking as well.
    https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial
    https://www.romhacking.net/documents/361/
    https://gbatemp.net/threads/crackers-ds-trainer-maker-tutorial.44410/
    http://fceux.com/web/help/fceux.html?Debugger.html
    Some of that is not for the GBA and what is might be rather old or more about cheats (often what people start with to figure out how games work, sounds then being something that happens all the time or in response to things, the latter you can control, the former usually having start points you can look to intercept, it all working within the hardware eventually too). Emulator wise then no$gba's debug option went free a while back and was long considered the best available, though vba (or indeed vba-sdl-h, http://web.archive.org/web/20130215155212/http://labmaster.bios.net.nz/vba-sdl-h/ ) still has some merit, and mgba also seems to be doing something of interest here.

    Even once you grasp the hardware you might find a specific instance within a game where some kind of software mixing gets done, or you might be able to combine two sounds that always play one after the other/at the same time. This before you get to doing things that are the audio equivalent of https://blog.quirk.es/2008/12/things-you-never-wanted-to-know-about.html or the equivalent of all the fun things I see people playing in NES audio are getting up to when they are let free on the hardware (or indeed not let free and forced to only play with a limited audio setup and no major work on the CPU but still make something fun).
     
    ChaosEternal and DarkDengar like this.
  5. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    Where would be the best place to start learning Arm assembly for GBA since I don't really know any programing languages?

    Also would learning Arm assembly help me to know what I'm looking at in a hex editor cause as of now I don't even know half of the things that I'm looking at.
     
    Last edited by biolizardshadow, Sep 14, 2020
    StrayGuitarist likes this.
  6. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    33,485
    Country:
    United Kingdom
    Hex editors are not something I suggest using as a general hacking tool.
    If you only need to edit a small bit, or get some sense of the format of the data then they can help but beyond that they are a lot of work for no great gain.

    http://www.coranac.com/tonc/text/asm.htm is about as good as it gets for specific GBA assembly and hardware introduction. You can look at emulator source code, the no$gba specs links earlier, cowbite and some other stuff ( http://members.iinet.net.au/~freeaxs/gbacomp/#BIOS Decompression Functions does well for some, I also tend to link https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf at the same time) to piece things together.
    The ARM7TDMI chip of the GBA is also open so you can read that.
    While many newer devices also use ARM (back on the GBA I remember wandering into an electrical engineering computer room/lab and seeing a "did you know what ARM powers" on the wall as it was doing lots but unknown) they are also quite a bit different in many regards -- the GBA has no divide (the BIOS provides it), no ability to handle fractional numbers (usually done as floating point numbers in computers, though certain things and the DS use fixed point for some things) and is rather limited in a lot of other regards (though perhaps not as much as the 6502 that powers the NES).
    Kicking it really old school then https://heyrick.eu/assembler/ and https://web.archive.org/web/20120628204500/http://www.reinerziegler.de/GBA/gba.htm might be of interest, though if doing that then the various https://gbadev.org/ http://www.loirak.com/gameboy/ https://patater.com/gbaguy/gba/ch1.htm http://www.devrs.com/gba/ https://www.darkfader.net/gba/ could also yield something for you.

    I have seen people come in completely cold and learn very good stuff from that. However something that also teaches programming along the way could also help.
    To that end going through the first 10 or so chapters of art of assembly https://www.plantation-productions.com/Webster/ if sticking with assembly

    or this lecture series if wanting some more general programming introduction and still some assembly and low level stuff.

    https://stuff.pypt.lt/ggt80x86a/asm1.htm is also good for a few things. Indeed it has some nice examples of how seemingly basic instructions can in turn add up to something good.

    "100% gold star can recreate the above from memory" will not likely have taught you things like https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true and http://hciweb.usask.ca/uploads/332-aim-assist-cameraReady-v8-final.pdf though so there is also that.

    You might have learned some things by osmosis as well -- if you learned about cheat making ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial and https://gamehacking.org/wiki/Hacking_Game_Boy_Advance because why not ) you would probably have something of an idea of how programs flow in games.
    Back to osmosis though then compare and contrast
    https://help.libreoffice.org/Calc/Mathematical_Functions
    with
    https://www.ict.social/c-language/basics/mathematical-functions-in-the-c-language-the-math-library
    and
    http://problemkaputt.de/gbatek.htm#armcpureference
    and
    https://developer.arm.com/documentation/search/5eec6e83e24a5e02d07b25aa
    https://developer.arm.com/documentation/ddi0029/g/
    and if you want to look at an introduction to digital electronics course (what are logic gates, how do I make them from transistors, what are adding machines, what are flip flops, building things from logic gates to compare multiple inputs (so karnaugh maps and maybe quine mccluskey) and what is circuit hazard) then something might also jog a memory there or become apparent when you meet it.

    Much like the camera things above there is always more to learn ( https://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php , and many things that https://www.gdcvault.com/ has to say, as well as hacker conferences in general). I already pimped my own guide to ROM hacking last time, though if you are after GBA audio stuff then it is a bit light.

    There is a part of me that wants to note getting you to learn assembly right off the bat is possibly a bit cruel for a number of reasons.
    1) It has quite the barrier to entry. It is considered hard for a reason, and there is similarly a reason all the high level languages that take up far more resources to do the same operations were invented.
    2) Assembly in and of itself is good for coding assembly. If you want to take your "I know it better than the original devs ever did" project and make a nice click and drag UI based editor for said info then you might come unstuck if assembly is your main thing, especially if it is just ARM assembly. Anyone that can learn assembly can probably pick up python or something in very short order (give or take wanting to break something as the "intro to [insert high level programming language]", holds your hand and goes exceptionally slowly through what is a pointer, what is memory, what is basic data representation and you can't skip it as it also forms the introduction to the syntax used, internal function names and basic flow of the language).
    To that end if you did want to learn C, python or some other popular high level language (hopefully that does not mean Java) and then transition out of it when you have the basics down there it could do something. The higher you go the harder the pivot to low level stuff becomes as high level stuff keeps so much complexity away from you.

    To answer the other question. Assembly in and of itself won't make a hex window make more sense -- converting from binary to assembly is a rare party trick ( http://www.catb.org/~esr/jargon/html/story-of-mel.html ). If however you do understand assembly then it in conjunction with a disassembler (emulators have them, crystaltile2 has a nice static one and plenty of other options are out there) will however allow you to approach a ROM and understand what it is doing regardless -- you can literally sit there and watch as it parses every byte along the way while it does what you are interested in altering/understanding and compare it to the hardware reference (hardware being fixed in silicon does mean you have a static target it gets to play to). There is much you can do in ROM hacking without assembly (indeed people have translated whole big script RPG games without it) but assembly makes it quicker, and if it is not going to be quicker you will know that and can use the easier methods when that becomes apparent, makes it assured that you can understand what is going on even if the original programmer was drunk and incompetent (game devs are not always the best devs) and might get slowed down but will never be stopped by devs doing something weird or annoying where those playing with other tools might be stumped.
    In this case I would likely find some instruction that sees a sound be played.
    Whether it is the start of a level for a simple to find place, or an action that sees a sound happen and thus can be replicated endlessly at will and will follow on from a very simple to find button press manager, even if the button press might be a few hundred instructions removed from the eventual sound bothering, might vary depending upon the game, my mood and what I have seen thus far in the game, sound tests are better still if the game has something here. Music and effects can be different though.
    Anyway so I have found something that causes a sound to be played. Now I get to understand what fetches the sounds, what it designates as a sound sample library and individual "instruments" and then consider what I might do as a basic alteration at first (no sense expanding the scope if you don't know the format, or at least the outline of it, though typically post processing is hard on a 16MHz ARM7 without a few hundred kilobytes of memory that is also running a game at the same time so probably going to look like what the hardware expects).
    After that I can look to see how I might expand it to play another sample (just one more at first, unless it is really obvious).
     
    DarkDengar likes this.
  7. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    Ah! I see what you mean. Are there any good disassemblers for the Arm series of processors or should I go with some disassembler I find online? That VBA-H looked very interesting.
     
    Last edited by biolizardshadow, Sep 14, 2020
  8. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    33,485
    Country:
    United Kingdom
    Most usually split it between some kind of static disassembler, emulators and maybe a nice all in one program like crystaltile2 (not so many people use IDA or radare2 for GBA hacking, but it is an option if you have money for the former or a masochistic tendency for the latter, on the PC for hacking then they are all the rage).
    Emulators have a massive perk in that they know what mode they are operating in -- the GBA ARM processor has two main operating modes called ARM and THUMB. ARM is much like you would expect and is 32 bit instructions using 32 bit registers, THUMB uses a smaller collection of 16 bit instructions but has access to a more limited but still 32 bit collection of registers which means smaller code (when most games are 8 megabytes or less then bytes do still count, especially if they are available for free) and potentially faster to fetch code (the no$gba stuff gives a good idea of the pipeline/cache, though it is nowhere near what Intel processors then and since were doing). Usually it is easy enough to tell when you are looking at the wrong mode as it will be gibberish, and even without that your emulator session directing you there in the first place will likely have told you as well.

    It is then usually the assembler you are concerned with. ARMIPS then being what most will probably look at ( https://github.com/Kingcom/armips ) but you could do something with the arm-eabi one from GCC (the DS trainer making stuff used it). Probably want to skip old stuff like goldroad unless you have some kind of old workflow that wants it.

    Emulator wise then even vanilla VBA should have one, the hacking/debug versions doing better still, would be surprised if the vba-m did not have something, no$gba debug is generally the gold standard to which all other GBA debuggers are compared and presumably mgba (I am less familiar with that one) will have something.
     
  9. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    Can crystaltile2 reassemble the rom as well or would I have to use something else for that? I also saw here https://gbatemp.net/threads/gba-rom-disassembler.52150/ that you recommend to people that they don't disassemble the whole rom and just parts of it they want to change so how would that work exactly?
     
  10. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    33,485
    Country:
    United Kingdom
    Very few people reassemble whole ROMS. Any that do usually only have that happen after they spend years recreating assembly code (see many pokemon disassemblies) or find it leaked (see recent events) or released (not sure what goes here, plenty of binaries get released but fewer code releases). In those cases you will usually have a target/setup specified.

    Most hackers also are more concerned with slight tweaks to existing code, or jumping to another area, doing their own thing with a bit more space and then jumping back (for most purposes you have 16+ megabytes available if you wanted when playing ROM hacker) which you can manually alter (changing sub life counter to ignore it is done in place, telling it not to take a code route after a check similarly done in place -- branch if equal becomes either no operation or branch always) or compile as almost a self defined code segment, paste it in a suitable blank/reclaimed spot, alter the earlier code to jump to it at a suitable time and have the last section of the former blank/reclaimed spot be jumping back with whatever data was generated).
     
  11. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    Are you saying that software like crystaltile2 can interpret the binary so you can know what you are looking at Cause I've never heard of disassembling part of a rom, reassembling, then it and putting it back in? I mean it sounds like you would have to know where the data you are looking for is first and then extract it to a more understandable state than the binary gibberish you see in a hex editor and then find a way to insert it again?

    — Posts automatically merged - Please don't double post! —

    (EDIT) Found the disassembler part of crystaltile2. Is this what you were talking about earlier where I use something like this to translate the binary into assembly code so I can understand what's going on?
     
    Last edited by biolizardshadow, Sep 15, 2020
  12. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    I've been messing around with the assembly code but nothing seems to happen. Is there something I should be looking for?
     
  13. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    33,485
    Country:
    United Kingdom
    This can end up in some confusing phrasing but as a quick rundown

    Binary. The whole 0 and 1 thing (aka base 2 in counting, base 10 being normal human numbers and base 16 being the hexadecimal seen in hex editors, there is also base 8 aka octal in some older computing stuff which is three binary digits rather than the 4 of hexadecimal). Also the technical name for a whole ROM but also used to refer specifically to the part(s) that the CPU ends up interpreting.

    Assembler/Assembly. This is the human readable equivalent of the binary the CPU runs. An assembler might have some minor ability to construct virtual instructions* but nothing like a higher level programming language. To that end there is a direct correspondence between human readable assembly instructions. Strictly speaking an assembler is the program that does the deed and assembly is the action but anybody playing ROM hacker will understand both terms just fine.

    *how do you get a 32 bit number (sometimes referred to as an immediate) into a 32 bit instruction? Answer is you don't. However if you wanted to say put all FFFFFFFF into a register you could do either something fun with shifts and add (add 0000 FFFF and then shift along so it is FFFF 0000 in there and then add FFFF), or in the case of ARM you can do movn 0 which would put the inverted (there is a reason I mentioned logic gates back there) form in there, some assemblers will then allow you to do that with a simple instruction rather than do all the steps.

    Disassembler/disassembly
    As there is said correspondence between things you can reverse it, unlike most high level languages (we are seeing some thanks to some incredibly advanced techniques but we will skip that one for now as the GBA lacks such toys right now and they are of limited practical use anyway).
    As mentioned on the GBA you have two sets of instructions, either of which can be running when you pick a random point in the ROM so there will be two disassembly files made if you just run a blind one. If you come from an emulator it will tell you where and what state it is in.
    More colloquially some use the phrase disassembly to refer to the act of unpacking a ROM much like you would unpack a zip file. Outside of GBA homebrew (which has stuff like GBFS) there is no option for the GBA (the DS and beyond however does have it, as do things that use floppy discs and optical media) as the GBA used what would generally be referred to as incbin (as in include in binary) methods to also pack in all the levels, audio, graphics, data tables, text and whatnot into one glorious blob. I try to discourage that use (you will usually see me use phrases like unpack or pull apart) but it is what it is. While we are on the subject of confusing words/phrases then to most ROM hackers if you say I want to edit this game's script or I need a script editor they will think you are referring to the text in a game, scripting in pokemon however tends to mean editing the events in a game (as in step on this tile and something happens, said something may also be the result of some custom programming), which can fit with more general programming as well (see scripting languages for one, python mentioned earlier being a good example of that) but still something to be aware of.

    Anyway a blind disassembler (which is what most static ones will be, static meaning not taken from a running program) will not know what is an instruction for the CPU and what is graphics and just acts blindly converting data in the ROM as though it was an instruction. Even if you restrict it to the "this part is what the CPU runs, I know the rest is plain graphics" the binary itself might include non CPU instruction data too; easy to include such things rather than kick it to an external resource when programming (it's only a table of stats after all, only a quick message that the menu needs...). This non instruction data being gibberish to a disassembler but possibly vital to the game means most things will not be able to blindly disassembled and then reassembled after the fact, not to mention you will also have to be overwriting data rather than inserting new lines unless you do it at the end of the ROM (every jump needs to have a destination, said destination will be a hardcoded value, move that on by a few bytes without changing all the references to it (which can be anywhere else, and might not be plain and visible -- add 500 to a base value to get to the real location being a perfectly valid and often done thing, see generated pointers. If say you have 6 player characters and need to operate on one but as all characters have the same type of stats you can then say +500 = character 1 +1000 = character 2....) and things break down very quickly, to say nothing of everything else that might reference something else later in the binary that is also now all shifted up (or backwards if you deleted) by a few bytes). This is one of the annoyances of assembly as the would be programmer gets to account for all of this when programming things, choose where things land in memory and all the rest, though assemblers used by programmers doing things for real will usually allow a reference value aka label rather than using a number all the time, plus have comments. This is but one of the things that mean making disassemblies like you might see for Pokemon, Mario, Sonic and the like take years to accomplish, the other being you also get to document what each part of the ROM does so someone can read it and have a chance of comprehending what goes. Even a more modest one where you don't detail what each and every thing does is a considerable feat. This apparent gibberish problem is also made worse by the ARM and THUMB modes of the GBA's ARM7TDMI (THUMB instructions maybe being gibberish to ARM mode and vice versa).

    You can find the binary (as in CPU instructions) in a GBA ROM pretty easily. The very first byte of a GBA ROM is an instruction, usually a jump to the end of the header which immediately follows it. From there you have a few instructions to set pieces of hardware up (when a machine turns on the data in various things might be random, you probably don't want that) and then you will see a jump to somewhere else in the 08?????? range which is the start of the binary the average hacker is interested in. I have a more graphical version in my hacking docs I linked earlier.
    However rather than going through a binary that does not have nice labels for things if you were playing with a debugging emulator then you can set things up such that it halts the whole emulation (breaks if you will, see also the pause break key on your keyboard usually somewhere near the print screen button -- vestige of such things from earlier times on the PC/IBM stuff) when a piece of memory is read or written to. This is what is called breakpoints, though you also have watch points/log points where a log of things are made instead such that you can peruse it as your leisure after the fact. You might find this memory with a VRAM/OAM/sprite viewer if concerned with graphics, maybe a tile viewer if you want to know when some graphics are being fished out of the ROM, you could set things up on the audio hardware if you want to go that way, some kind of normal memory location (a hit that takes health will also fire off audio cues, visuals, logic within the game, you can then find health values/bars with cheat searching methods)
    https://www.romhacking.net/documents/361/ is a nice introduction to finding data using such breakpoints but works much the same on any system really (just different instructions, memory layout and possibly phrases -- break on read might not always be bpr in every emulator/debugger). It is for the older, and command line based, vba-sdl-h but the general flow works for everything really, and if you can convert it such that you can do it on no$gba then you pretty much have the basics to start playing by yourself on other ROMs. Reading data on a ROM is not so very different to writing data to memory so now you have break on write, break on execute is another (stop when this instruction is executed by the CPU) and everything else is more or less just restrictions on those three (plus the watch/log equivalents) to narrow things down to stuff you care about (16MHz does mean 16 million per second, and while it might not be 1 cycle per instruction for all instructions it is usually between 1 and about 5, see instruction timings if you care about that at this point, naturally http://problemkaputt.de/gbatek.htm#arminstructionsummary includes a cycles count) or poke data into and read memory and registers (nice to be able to change things as it goes on after all).

    With this debugger you can then learn where something is, and what mode the CPU is in at the time (as well as other relevant info like contents of memory, other notes the CPU might have). Some more advanced ones** might even log what areas are run in what mode for you so you can have a slightly less blind disassembler (or build it up yourself by running the game a bunch to figure it out).
    Anyway if you know where and what more you can then use that info to direct something like Crystaltile2 (guides to CT2 are elsewhere but it will have a disassembly window, you can then set an address if you want to mirror what it will appear like in the device, and the top bar at the right will allow you to select between modes (ARM7, ARM9 and ARM and THUMB for both, ARM9 being the DS' main processor that most ROMs and homebrew have most of the interesting code in). There are some limited abilities to edit instructions in it but I usually find it somewhat buggy so tend to avoid that one in favour of writing my own list, assembling them and copy-pasting the relevant part via hex editor or something.

    **Might as well note code logging approaches. Not really available for the GBA at this point as far as I am aware, though I am a bit behind on some of the newer emulators and might be constructed in GDB bridge stuff, but on other systems and might appear one day is code logging. http://fceux.com/web/help/fceux.html?CodeDataLogger.html , here if you wanted to learn about the jump command in say Mario you would find a reasonably quiet point, start the log, do everything but jump, say next new thing that is executed please tell me about it and then jump in the game, the now new to this session jump command is used and it will know to ignore the basic background timer, any walk or idle, background music, background animations and all the rest as it has seen all that before now).

    Between the data being shuffled forward and back problem and general simplistic nature of most alterations this is why most will then choose to edit things leaving it alone as much as they can. If doing a simple one instruction tweak (can do seriously game altering stuff with that***, or just stop a failed check for a save hash/anti piracy check from executing the "hold up, go away filthy hacker" routine by making it ignore results or always go down the good path) then yeah. If not (or just needing a bit more space to play in) then find a blank spot, subvert the original code to go there instead, do the deed and jump back to where it would have landed/finished before along with whatever new data you generated and still need.

    ***Most cheats operate on one location. Now there might well be multiple things operating on that area (I usually use Mario as an example -- think of all the ways you might die, each of those might well have its own take one from the life counter) but still can change a sub to an add, or have it do nothing, or have it take 100 (useful in stats manipulation), or can have it ignore a shield/rings check in Sonic...

    Anyway I am now basically rewriting the intro to debugging which I have done elsewhere, as have others, with nice worked examples and pictures and whatnot so I will tie it off there for now.
     
    Ryccardo likes this.
  14. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    So I should use an emulator with debugging capabilities then?
     
  15. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    33,485
    Country:
    United Kingdom
    I will usually use one to find things initially and then consider transitioning to a static one for when I have to spend time contemplating what each instruction or group thereof does.
    If doing something more basic then it might be all in an emulator save for the final check over.
     
  16. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    Oh ok! My only other problem (and this comes from lack of experience) is finding where things are located. Here https://www.csie.ntu.edu.tw/~cyy/courses/assembly/10fall/assignments/proj3/GBA-debug.pdf it talks about some myfilter thing and adding breakpoints to find stuff but how is that gonna help someone find stuff if they don't even know where to look in the first place? Also VBA-SDL-H is not letting me type anything in the command prompt window that pops up when you open a rom.
     
  17. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    The no$gba debugger is beefy.
     
  18. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    I think I see what's going on here. How do you tell what each command is doing I can put break on a command but that hasn't really helped me so far find the direct sound limit thingy or how I can increase it, but it is helpful to have the memory addresses displayed so can see what is where within the rom. :) As someone who really had no idea what was really going under the hood I am very impressed with how everything is being processed.
     
    Last edited by biolizardshadow, Sep 16, 2020
  19. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    33,485
    Country:
    United Kingdom
    Finding things is kind of the whole trick. That PDF is rather basic, and "win 32 no longer supports debugging" (not that I would use/suggest gdb for most things here unless you otherwise know it well) means "go find an old version and use that instead" (GBA emulation has been a thing actually since before the GBA and has been more than good enough since around the time it hit the US, there was several years of development after that).

    I mentioned the elimination method and while it is not quite as nice as the fceux you can still note things and try to spot something new happening that did not happen before.

    The basic tracing method https://www.romhacking.net/documents/361/ can yield things but that is usually better for people looking for data than understanding the matter at hand. http://web.archive.org/web/20130215155212/http://labmaster.bios.net.nz/vba-sdl-h/ is a bit clunky for newcomers (it is how I would write a general manual though for those that already know, by the way try pressing F11). That said you will necessarily end up parsing that data somewhere along the way, and knowing where it is if it is going to be fetched several seconds into the future (though several million instructions later if you are thinking of stepping through them one by one) will do for the thing I am about to cover.

    Usually though I will go something that can induce things and move on from there.
    A button press might not be anything related to sound but if a sound happens as a result of say a character jumping then you have something that tickles the game's sound engine and can follow it through to the scene of the crash as it were. In my case I am usually not interested in sound as much as how the game handles gravity or something but sound also works in this.
    From there you get to understand how it designates samples and what the limit might be (if it only uses 2 bits to address/designate them and the rest does something else you have 4 samples max in that setup, figure out how to expand that to greater and also how to handle it further down the line). You get to be the one to figure out the stuff, ask if I wanted to push this to the limit how would I do it and what would break along the way.
    It might be that there is a simple "oh just change this byte" somewhere at the end of it all, however you might have had to put in several hours pulling it apart and going way up the chain to not just get it but be sure it will do what you want and not make everything fall over or slam into hardware limits (or maybe the code you were looking at is a means to dodge those).
    You don't necessarily have to know what each and every instruction does and can speed things up by grouping aspects together (if you care about sample limit the stuff handling volume might be less of a concern) or abstracting runs of instructions into higher level aspects (the thing earlier with getting a full 32 bit number into RAM, annoying but most of it is like that -- simply trying to get something out the ROM and into RAM might be a whole journey messing with DMA, checking to see if it the DMA is read, possibly tweaking the data once it is there (usually more about compression in graphics but something could happen here), as you can only fetch chunks at a time then you can then ultimately put a bracket around a chunk and say this bit is all about grabbing data. You might end up returning to something later if it turns out that fiddling with stuff between ROM and RAM means something but for the initial overview then you might end up not getting bogged down.
    If you also happen to understand the general hardware you are looking at ( http://belogic.com/gba/ ) and the nature of audio formats and what needs to be there, and what might be done for either contemporary devices or devices of similar potency then you will also have that to help you -- things don't generally spring from nothing and physics is a very harsh mistress that ultimately everything returns to (humans might have made up the idea of a musical scale and timings, 4 4 is just a number and all that, but the idea of a sine wave less so).
     
  20. biolizardshadow

    OP biolizardshadow GBAtemp Regular
    Member

    Joined:
    May 4, 2020
    Messages:
    110
    Country:
    United States
    I decided that I am going to use the no$gba debugger emulator since it has a lot of useful tools. The double edged sword here is that after i make the character jump I have to quickly click out of the emulator window before I miss the stream of data because I can't see the data as its being read from the emulator in real time until I click out of the emulator window which pauses the emulation and updates the debugging screen.
     
Draft saved Draft deleted
Loading...

Hide similar threads Similar threads with keywords - samples, limit,