headkaze · 26376
.arm.text.global mainmain: b main
.arm.align.global initSystem.global maininitSystem: bx lrmain: mov r0,#0x04000000 @ I/O space offset mov r1,#0x3 @ Both screens on mov r2,#0x00020000 @ Framebuffer mode mov r3,#0x80 @ VRAM bank A enabled, LCD str r1,[r0, #0x304] @ Set POWERCNT str r2,[r0] @ DISPCNT str r3,[r0, #0x240] @ VRAMCNT_A mov r0,#0x06800000 @ VRAM offset mov r1,#31 @ Writing red pixels mov r2,#0xC000 @ 96k of them lp: strh r1,[r0],#2 @ Write a pixel subs r2,r2,#1 @ Move along one bne lp @ And loop back if not donenf: b nf @ Sit in an infinite loop to finish
.arm .align .global initSystem .global maininitSystem: bx lrmain: mov r0,#0x04000000 @ I/O space offset mov r1,#0x3 @ Both screens on mov r2,#0x00020000 @ Framebuffer mode mov r3,#0x80 @ VRAM bank A enabled, LCD str r1,[r0, #0x304] @ Set POWERCNT str r2,[r0] @ DISPCNT str r3,[r0, #0x240] @ VRAMCNT_A mov r0,#0x06800000 @ make r0 a pointer to screen memory VRAM is 0x06800000. ldr r1,=picBitmap @ make r1 a pointer to your bitmap data mov r3,#0x6000 @ Half of 96k (2 pixels at a time)loop: ldr r2,[r1],#4 @ Loads r2 with the next two pixels from the bitmap data (pointed to by r1). str r2,[r0],#4 @ Write two pixels subs r3,r3,#1 @ Move along one bne loop @ And loop back if not done nf: b nf @ Sit in an infinite loop to finish
The only thing that I find a bit confusing is makefiles and also how it knows where to find the bitmap (png) in the make (ldr r1,=picBitmap)I can see the png refs in the makefile but have no idea where the ldr picBitmap comes from as a memory reference.I bet I am being dumb again!!
ldr r0, =REG_BG0CNT_SUB @ Set sub screen format to be tilesldr r1, =(BG_COLOR_16 | BG_32x32 | BG_MAP_BASE(29) | BG_TILE_BASE(0))str r1, [r0]
Okay next up we have a demo to display text on the screen. It demonstrates using a tile mode.
ldr r0, =SCREEN_BASE_BLOCK_SUB(29) @ make r0 a pointer to screen memory bg bitmap sub address mov r3, #14 @ Our character counter (0-14 = 15 chars) adr r1, [text] @ Load the adress of our textMaploop: ldrb r2,[r1],#1 @ Load r2 with our current character code sub r2,#32 strh r2,[r0], #2 @ Store the result in SCREEN_BASE_BLOCK_SUB subs r3, #1 @ count down bpl Maploop
ldr r0, =OBJ_ATTRIBUTE1(0)ldr r1, =(OBJ_X(128) | ATTR1_ROTDATA(0) | ATTR1_SIZE_32)strh r1, [r0]
#define OBJ_Y(m) ((m)&0x00ff)#define OBJ_X(m) ((m)&0x01ff)
ADR produces position-independent code, because the address is program-relative or register-relative.Use the ADRL pseudo-instruction to assemble a wider range of effective addresses
I am having a look at your code now. It is a little difficult to concentrate on this a work though, but I can see problems. The wrong values are in r2 and r3 prior to store. This can be shown by altering the ror function and the result is the same, so it is adrift somewhere. I will have a proper look when I get home from work!
Looking great HK... So how hard to you think LDMPCMCIABBCSPQRRSVPTITTY sound is gonna be?
an interesting read at gbadev. There are a couple of things to be learnt there.Have you managed to understand the code fully That is always a tricky bit. I must admit, signed numbers are always a bit of a weak spot with me. Never really got to grips with them. On the C64, none of my games really used anything larger than a unsigned byte...
Everything was written from scratch so I do understand it. The changes I had to make were pretty minor so I actually had most of it right first time. Sorta reminds me of the sound code that didn't work - it was pretty much one line of code that was screwing everything up!
What I don't understand though is why fluBBa suggested I use asr instead of lsr. It didn't seem to make a difference. Also why use movpl instead of movgt? Again they didn't make a difference but I made those changes anyway.
