Versions of xmrs below 0.4.1 (unreleased, 0.4.2 is on crates.io but
0.4.1 is in the repo) have a bug where they swap linear and amiga
frequencies. This caused all old versions of agb (which were using
version 0.3) to use the amiga frequency table rather than the linear
one. Technically it sounds slightly wrong but it is kinda hard to tell.
Since agb 0.20.0, we are now using xmrs 0.5, which correctly reports the
frequency type for the XM file. That pointed out an error in the
note_to_speed method for linear frequencies (since those are now being
used). It turns out that the formula for calculating the frequency
expects a 0 based index for the note, but we were passing a 1 based
index for the note. Moving this down a note fixes the issue where things
were being played at the wrong frequency.
Implements a very basic backtrace and the ability to format them
If you run the panic example and press A, you get:
```
[ERROR] GBA Debug: [failed]
[ERROR] GBA Debug: debug data: ce3-1ee7-1fb7-24d-1ad
[FATAL] GBA Debug: Error: panicked at src/memory_mapped.rs:101:24:
index out of bounds: the len is 240 but the index is 240
```
which you can then prettify with:
```
> agb-addr2line ../target/thumbv4t-none-eabi/debug/examples/panic 0ce3-1f57-2027-024d-01ad
0: rust_begin_unwind <agb>/lib.rs:321
1: core::panicking::panic_nounwind <core>/panicking.rs:151
2: core::panicking::assert_failed_inner <core>/panicking.rs:321
3: agb::memory_mapped::MemoryMapped2DArray<T,_,_>::set <agb>/memory_mapped.rs:101
(inlined by) agb::display::bitmap3::Bitmap3::draw_point <agb>/display/bitmap3.rs:31
4: main /home/gwilym/Projects/agb/agb/examples/panic.rs:15
```
- [ ] Changelog updated / no changelog update needed