SkyLyrac wrote:

Yet another reason I think it's a better idea to start out with optimizations off - you have more code massaging your code, which means more code that can fail.

As I've mentioned in here https://forum.gbadev.net/topic/29-can-t-build-in-programmer-s-notepad?page=1#pid175 I think it's generally a good idea to use optimizations always so that you're always testing the code you will eventually run in the final build.

Well, I think it's best if we agree to disagree on that one. (I did read your whole post over there, thank you for elaborating.)

I did have to use the ARM compiler and linker from devkitPro as running the vanilla makefile didn't work though.

Yes, when building old code in general you should replace the makefile by the new one of devkitPro, they don't update it often, but over the years it tends to change, and you really don't want to waste your time fixing an old makefile when you can just take the new one.

The Makefile in that tutorial was no big deal because I knew what binaries to point to but I'll keep that in mind. Thanks.

exelotl wrote:

Hmm, I imagine your Makefile is fine and there's something wrong with the code itself.

Oh god, yeah, this tutorial was part of a course which expected students to use 'devkitAdvance', a toolchain which hasn't been updated since 2003.

It's possible that the code was never correct, but happened to work because the compiler optimisations weren't very good back then.

Yet another reason I think it's a better idea to start out with optimizations off - you have more code massaging your code, which means more code that can fail.

Thanks. Anyway, the example project in this tutorial worked for me:

https://deku.gbadev.org/program/sound1.html

I did have to use the ARM compiler and linker from devkitPro as running the vanilla makefile didn't work though.

SkyLyrac wrote:

Most people take the makefiles as they are, and use them right away. I think it's a good idea to leave optimizations on, as most people aren't actually going to step line by line in a debugger.

In fact, I created the libtonc-examples repository because the original examples were using a few different makefiles with more or less features, and a reduced version of libtonc called "toolbox" or something like that.

Most people take the first example they build and start building their game on top of it, it's important that all examples are decent enough to use them as base.

I'm going to have to strongly disagree with you on that one - I think being able to step through every line is extremely important - but no big deal, I can always write my own tutorial.

Does anyone know how to build the code in this tutorial?

https://ianfinlayson.net/class/cpsc305/notes/19-sound

It claims that the "complete program including the data files" can be downloaded via the link at the bottom, but there's no makefile there. When I tried to use the makefile from TONC's basic first example, and loaded the .gba file in mGBA, I got this error:

The game has crashed with the following error:

Jumped to invalid address: 783BD1F6

This page contradicts itself, it says the default bias level is both 0200h and 100h:

http://problemkaputt.de/gbatek-gba-sound-control-registers.htm

Cool. One thing I didn't like about TONC is that optimizations are on in the demo makefiles. I think it's more important for people who are learning to be able to step through every line of code and understand it than it is to squeeze out every last drop of performance.

short for "character block" - as far as I can tell, this isn't official Nintendo terminology. It doesn't seem to be in either the Game Boy original or the Game Boy Advance dev manuals. But there is a consensus online that it is 16KB:

https://www.copetti.org/writings/consoles/game-boy-advance
https://ianfinlayson.net/class/cpsc305/notes/13-tiles
https://www.coranac.com/tonc/text/regbg.htm

Does anyone know who introduced this term and what the motivation was? I notice that the size of VRAM_B and VRAM_C are also both 16Kbyte - could this be the reason?

Ah, ok then. I did just find my GBA and need a way to connect it to test. Nocash describes four methods for connecting an Xboo cable to a GBA, but unfortunately all of them are invasive or destructive in some way:

https://problemkaputt.de/gbatek.htm#auxxboopctogbamultibootcable

I definitely feel more comfortable destroying a third-party link cable than a Nintendo one, so I'll probably go that route.

Any idea what AUTOLF means? Automatic linefeed?

Well, I hope it isn't so bad that there are ambiguous names floating around, which mean one register to one person and a different register to someone else.

If there aren't any like that, we could put a big table together with all the different naming standards so people can lookup the register address and see the name for their preferred style.

SouNd Register fits, but I think NR is too terse for people unfamiliar with the hardware.