when I try and generate a set of 500 random points in the screen area. Eventually I figured out why I was seeing strange patterns of points on the screen. Instead of 500 random points I expected.

The code for the broken version looked like

Vector2[] v= new Vector2[500]
for (int i = 0; i < v.Length; i++)
{
Random r = new Random();
v = new Vector2((float)(r.NextDouble() * Width), (float)(r.NextDouble() *Height));
}


and the fixed version


Vector2[] v= new Vector2[500]
Random r = new Random();
for (int i = 0; i < v.Length; i++)
{
v = new Vector2((float)(r.NextDouble() * Width), (float)(r.NextDouble() *Height));
}


It looks to me like the initial randomisation of the random number generator is a bit suspect.

Now I get this

First I tried building with O3, inline functions and packed structures. This didn’t gain me enough ram so I had a look at what nm said was going on in the binary. The one chunk of the output which stood out was the following.


0000072a T __divmodhi4
0000072a T _div
0000073e t __divmodhi4_neg2
00000744 t __divmodhi4_exit
00000746 t __divmodhi4_neg1
00000750 T __udivmodhi4
00000758 t __udivmodhi4_loop
00000766 t __udivmodhi4_ep


GCC was inserting a load of division routines into the code as the chip doesn’t have the hardware to do division. I wasn’t doing any division in my code as such but I was using the mod operator for calculations in a ring buffer implementation. These routines which were causing registers to be pushed onto the stack along with return addresses. One ISR was pushing 14 registers onto the stack (partly because of this) along with the return addresses for the division functions.

To reduce stack usage I created a replacement macro for doing mod operations to avoid having to use the built in functions. All values used are unsigned values. This would need to be adapted to work on signed values and only works in my implementation because a is guaranteed to be less than 2b.


#ifdef LSMOD
#define MOD(a,b) \
((a>=b) ? a-b : a)
#else
#define MOD(a,b) \
(a % b)
#endif


The resulting binary was a few bytes bigger (as it was output in multiple places unlike the function which was just called in multiple places) but only caused the ISR mentioned before to push 9 bytes onto the stack and it doesn’t call any other functions so no return addresses need to be stored.

After spending a lot of time trying to find somewhere that either still sells a multiboot cable or good diagrams / documentation on the multiboot protocol or even code for making a multiboot cable which doesn’t require dos / a parallel port to upload data I stumbled across Matt’s Multiboot Serial Cable (http://www.axio.ms/projects/GBA/) which was one of the few sites which wasnt full of dead links.

The MSMC implements a smart serial cable (serial <-> microcontroller <-> GBA) to convert between standard 8 bit serial and the the GBA’s strange 16 bit serial format. The only slight problem being that it was written in asm for the 8051 and I didn’t have anything 8051 based. I did however have an arduino and several bare ATMega168 ICs in my parts box (the microcontroller code is ~ 1.5k so this overkill to a silly extent).

To cut a long story short I ported his microcontroller code (mainly using the comments) to my Arduino prototype board and now have it running on a bare atmega168 using the internal oscillator. I have also made a few tweaks to the upload tool.

Download the microcontroller code and upload tool here

To upload a GBA multiboot image using an arduino

• wire the GBA pins up to the arduino (instructions at the top of the source in the arduinocable directory)
• flash the code in the arduinocable directory onto an arduino / atmega168
• compile the upload tool and run gbl -p/dev/ttyUSB0 -d1 ./image.gba

(Note: I haven’t tried it on anything other than an x86 box running ubuntu 9.10 but it works for me)

I’m thinking about adding a way upload code directly from the microcontroller to the GBA without the PC getting in the way. It should have enough spare flash for at least a 10k gba binary / I could read it from an SD card and is a shedload easier to get hold of than a writable GBA cart.

A big thanks to Matt Evans (http://axio.ms) for writing the original and keeping the source on his website for nearly 8 years.

7 for 1024×768
8 for 1152×864
9 for 1280×1024
a for 1600×1200

These do make the targeting bug I posted a fix for much worse and the game will crash if you press escape during a mission.

This was completely unmaintainable and didn’t work for some people so I went back to the drawing board and created a loader which injects a DLL into the EXE and replaces the dodgy bit of code.

Sadly the loader still doesnt appear to work for everyone so heres the fixed exe, loader+dll and source code for the loader+dll. The code is fairly horrific so if anyone wants to have a play and fix it please do.

Loader + src

Fixed exe