gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

ASM > code to play an AVI file - Works

#6669 - GbaGuy - Sun Jun 01, 2003 4:57 pm

This is what I have:

Code:

@arm
@fsize   32

@equ   oam_table   =   0x03000000

b start
@include screen.h
@include dma.h
@dup   dcb 0xba,0x0
start:

ldr r7,=0x4000000
ldr r8,=0x403
str r8,[r7]

ldr r2,=StartOfAVI
ldr r3,=0  ; offset from StartOfAVI
ldr r9,=0x63643030 ; means a video chunk, 0x63643030
ldr r8,=4
ldr r7,=1
ldr r10,=0
ldr r6,=240*160*2-2

playAVI:
   ldr r2,=StartOfAVI
   ldr r5,=0
   add r5,r2,r3   ; Add offset to r2 (base) give r5 the full addr
   ldr r4,[r5]     ; get data
   cmp r4,r9       ; see if a video frame is coming up
   bne NotAVidChunk  ; if not, goto NotAVidChunk
   add r5,r5,r8       ; add 4 to get past the chunk specifier and something else that I don't know what exactly it is.
   
   ldr r0,=0x4000006 ;0x4000006 is vertical trace counter it?s address is loaded into r0
scanline_wait: ;lable
   ldrh r1, [r0] ;move the value stored in the scan line register into r1
   cmp r1, 160 ;comp it with 160
        bne scanline_wait ;if it is equal then we are done else it jumps to scanline wait

   DrawMode3Pic r5    ; draw the picture with DMA.
   add r3,r3,r6
   add r3,r3,r7
   b playAVI

NotAVidChunk:
   add r3,r3,r7   ; add 1 to the offset
   b playAVI     ; try again

StartOfAVI:
   ; AVI file to be DOS Copy commanded to the end which will be here.
   ; AVI file hopefully will be uncompressed, no sound, 16bit color
   ; and 240x160. VirtualDub can be used to get it like that.

@endarea
@pool


Everything now works, except for the picture being upside-down and
the colors reversed.

Anyone want to help on this?

Thanks,
- Mike

PS: The headers can be retrieved if you take my website
http://k2pts.home.attbi.com/gbaguy/ and append the name of a
header.

Last edited by GbaGuy on Mon Jun 02, 2003 1:27 am; edited 1 time in total

#6682 - arundel - Sun Jun 01, 2003 10:17 pm

I can't find any major errors, but maybe I'm too newb. Could you post some screenshots of the output picture you mentioned?
_________________
http://www.nausicaa.net

#6683 - GbaGuy - Sun Jun 01, 2003 10:29 pm

The only problems with the picture (as outputted from the currectly posted
code), is that it's upside-down and red and blue are reversed, that's what
I'd expect.

What I want to do now is get it working on the read GBA. Here's output
taken from VisualBoyAdvance:

[Images not permitted - Click here to view it]

In the movie, the blue thing (it's a pyramid, but you can't tell from that
angle) spins. It's also supposed to be red. And the image is upside-down
of course.

Any ideas?

I was thinking maybe syncing with VBlank would have a better chance
of getting output on the real GBA...
[/img]

#6690 - arundel - Sun Jun 01, 2003 11:44 pm

I might have an answer to the wrong colour issue. I believe the GBA uses a different colour sceme, as used in the avi image data. The AGB uses BGR and it seems the avi data is using RGB. Try a right rotation by 5 bits and then exchange bits 5-10 with bits 11-15. This might become a bit tricky, since you'll have to be very careful with the bits. I think one of the colours uses 6 bits (blue?), the others 5 bits. Be sure to check out some docs concerning this matter.

EDIT:

The problem with the upside down image could be related to the endianess. Check all code to see, if this might be an issue. The GBA uses little endian, although natively the ARM CPU supports both memory models.
_________________
http://www.nausicaa.net

#6692 - GbaGuy - Mon Jun 02, 2003 12:39 am

I had a feeling that the GBA's color format was the reverse of AVIs.

As for the upside-down image, the frames are stored that way in AVIs
for some reason, that'll take a using the end of frame address and telling
the DMA to source decrement, I think that might work.

Right now, I'm more concerned about getting it working on the hardware.
I did some tests and discovered that absolutely nothing that I write in
ASM is working on the hardware and that the header is showing some
wierd stuff (header values are coming from the AVI that is at the end
part of the file!! I know because I've had the title of the ROM be RIFF
and 00dcd). ROMs that I've coded in C are working so there's something
wrong with the ROMs that are coded in ASM.

#6695 - DekuTree64 - Mon Jun 02, 2003 1:35 am

GBA's color is 5.5.5 BGR (meaning bit0-4 is red, bit5-9 is green, and bit10-14 is blue (when you write out a number, the upper bits come first, so that's why it's called BGR)), with the highest bit unused (most computers use 5.6.5 for 16-bit, which is what Arundel was thinking of). For the upside down problem, just set REG_BG2PD (or it might be PA, not sure which) to -256 and the hardware will flip it for you.
As for the not working on HW problem, use GAS. I've never used Goldroad myself, but with GAS you can link .o files compiled from ASM or C, so you can just use whichever language is best for the particular function you're writing, and if your C programs are working fine, then ASM programs shouldn't be any different.
I think the syntax is a little different though.

#6697 - GbaGuy - Mon Jun 02, 2003 1:46 am

Got it working on hardware now, it was a problem with the header.

Thanks for the flipping tip!

I tried using GAS and OBJCOPY, but for some reason some of
the branches got messed up.

I'm DMAing the frame directly from where they start to VRAM, so
I might have to write a PC program to do the color adjustment, as
I can't find an option in VirtualDub to reverse R and B.

#6735 - Ampersand - Mon Jun 02, 2003 1:10 pm

Hi,

I also noticed Goldroad to have problems with headers, some small files also need to be padded to 2kb file size.
_________________
www.iome.nl