Alright I have a conversion from C to asm. It is get pixel and is as fast as possible and can be no more optimized. Unless gcc automatically handles the zero extension which I'll have to check.

Is it just me or does this routine not handle multiplying by 2 to index the array?

I made a little optimization that takes advantage of the move with offset:
short GetPixel(short x, short y)
{
    MOV.W (width),R2          ;get screen width of 384 * 2
    MOV.L (VRAM),R0           ;get VRAM buffer location, usually 0xA8000000, but uses pre-initialized global variable just in case.
    MULU.W R2,R5              ;unsigned 16 bit multiplication
    SHLL R4                   ;single left bit shift which multiplies R4 by 2. Also used to fill slot before the MAC load
    STS MACL,R2               ;load result of multiplication into R2
    ADD R4,R2                 ;add modified x value to to the scaled y offset
    MOV.W @(R0,R2),R0         ;Load word from R2 offsetted from the VRAM base into R0. Sign extension
    RTS                       ;delayed branch and return. Note, R0 not touched because the result of the previous instruction is still be loaded
    EXTU.W R0                 ;safe to touch R0 now. Get rid of that pesky sign extension. May remove later if gcc handles this step on its own
    align.4
    width: word 384 * 2
    VRAM: long VRAM_address   ;global variable that was initialized earlier to correct address.
}

Nice job catching that there calc84. Sometimes I forget possible optimizations when I don't have the full instruction set in front of me.
btw on the instructions that you replaced, I wanted to know if you're aware of the hidden slow down when you try to access a register when the previous instruction loaded data from memory into it. The code is fine, but I was just wondering if it was by luck you had it formatted that way or if you knew the whole time because you seem to be very skilled with Super H asm.

I've gotten pretty used to ARM9 assembly at this point, which has similar memory load and multiplication delays. I studied up on SH3 when we started learning about the Prizm a while back (and personally I like ARM better, but that might just be me)

Edit: just for the lulz, here's how I might do this in ARM assembly:
GetPixel:
    ldr r2,=VRAM        @buffer = VRAM;
    add r3,r1,r1,lsl #2 @temp = y*3;
    add r3,r0,r3,lsl #7 @temp = x+temp*128;
    add r3,r2,r3,lsl #1 @temp = buffer+temp*2;
    ldrh r0,[r3]        @return *temp;
    bx lr

Just as a note you might want to keep your routines C compliant in their register usage that way other C coders can embed them in their programs. Such as on the first make sure you push r8 and r9 on the stack beforehand and on the second routine remember that args are passed in r4-r7 then stack and return data is in r0 and r1. There are a few exceptions when it comes to structs but for the most part it is pretty general. Leaving the routines the way they are now will force C coders to modify them which they may not be experienced enough to do.

So the first routine switches the mode from privileged to user it appears. I do have one question, how would you get back to privileged mode then if the instructions to access the SR are disabled?

No, it switches the register set that's currently swapped in. The Processor has two register sets in Privileged mode: Regular and banked (which map to r8-r15). The GCC doesn't use the banked registers, so they're free to the ASM programmer to mess with. I doubt the OS uses them much either with the probable exception of error handling.

Needless to say, I love abusing the banked registers 

That could be useful for the ex based instructions on my 83+ emulator. I currently store the z80 registers in the r8-r15 range so I would just have to preserve the non-shadowed registers.

You might want to run a test on those random routines due to a possible issue with the RTC. The problem is that the RTC ticks only 64 times a second so if you're calling that same routines multiple times in quick succession there may be some repetition. In Simon's random routine he used a static seed to contribute to the result which increased randomness. 

So, here I finally made a new routine that seems *really* random.  When I didrectly used it in my map generating routine to take the result of this routine seeded with 0 and mod 6, the tile output showed no patterns whatsoever.  However, I attained it by keeping the RTCtimer at bay for a *long*, *random*, time.  Anyways, the routine on it's own, which can even seed itself or get seeded by the RTC_GetTicks:

unsigned short random(int extra_seed) {
int seed = 0;
int seed2 = 0;
for(int i = 0; i < 32; i++ ){
seed <<= 1;
seed |= (RTC_GetTicks()%2);
}
for(int i = 0; i < 32; i++ ){
seed2 <<= 1;
seed2 |= (RTC_GetTicks()%16);
}
seed ^= seed2;
    seed = (( 0x41C64E6D*seed ) + 0x3039);
seed2 = (( 0x1045924A*seed2 ) + 0x5023);
extra_seed = (extra_seed)?(( 0xF201B35C*extra_seed ) + 0xD018):(extra_seed);
seed ^= seed2;
if(extra_seed){ seed ^= extra_seed; }
    return ((seed >> 16) ^ seed) >> 16;
}


It basically gets one bit from the timer at a time for the first seed, and then the second, "darker" seed (higher chance of filled bits), each bit gets 4 oppertunities to be seeded with a 1.  It then goes through the standard wacky operations to fill in the bitfield better, xors the available seeds together, and returns them as a short.  Very loosly based on simon's routine.

It's random *depending on how it's used*.  If you use it every now and then, it will be *surely* random, if you seed it with RTC_GetTicks or another varying number (even with a seed of 0 it will still be random, though).  In loops, it's fixed by slowing down operation in tradeoff for randomiscity:

for(int i = 0; i < 3600; i++) {
(*(map+i)).natural_cell = random(random(RTC_GetTicks()))%6;
OS_InnerWait_ms(random(0)%64);
}

As you see above, the actual random value is seeded by another random value that is not seeded, which worked really well.  For the OS_InnerWait_ms, I have it wait for an unseeded random time, mod 64 (so it won't wait a very long time, and since the RTC timer increments 64 times a second, it should give it long enough to increment in usual cases.

All because of a rand() and srand() linking error fun night spent.