> 1) WRAM decrease from 48K to 32K

Damn. I had also heard that too but was hoping it wasn't true. Sheeit!

> 2) Installation of 256K of CPU external WRAM

Ok. This confuses me, the data bus to cart memory is only 16-bit, right? And
I'm presuming this 256KB is on the cart also, so what happens when a company
decides to perform a cost cutting measure and remove the RAM from a cart and
consequently your entire game is running in 16-bit Thumb mode. Or worse, you
have to do the copy code function down to RAM and execute from there, ala
N64.

What strategies are people using so far for they code & data? Not working on
a GBA title at the moment I haven't thought about the best way to tackle
these issues. Are you copying down to WRAM and executing there?

> 3) Elimination of the IR communications function (but there will be an
> adapter accessory)
>
> (I personally think #3 was a bad idea)

Yeah, pretty bad, but IR was never used that much anyway. I'd rather see a
good serial comms support in hardware and a bundled cable than an IR port.
(The bundled cable is just pure conjecture).

>
> 4) Change of serial comm to 32bit from 16bit. SCCNT_L register interal
> shift clock will change: "0" 8KHz -> 256 KHz, "1" 256KHz -> 2MHz. Adding
> UART-based comms. Compatability with N64/Dolphin controller port

This is at least good. No more faffin' around handling your own clocking.
UART makes it a lot simpler. Plus using a minimum of 256KHz is a good thing
too.

> 11) Change in maximum simultaneous colouring numbering - Changing to 5:5:5
> (32768 colours) from 5:6:5 (65536 colours)

Now I wonder why they chose to do that... Simpler hardware decoding logic
perhaps.