Sign in to follow this  
  • entries
    2
  • comments
    2
  • views
    2525

About this blog

Caffinated musings in ARM assembly

Entries in this blog

Segmented
Hello all. I promised myself I would post the progress on my game before starting to work on the PUTT contest, so here it goes =) When I came to the question of input for the raspberry pi, my first assumption was that the easiest method would be to use the USB port. However, I reached dead-ends everywhere and eventually decided it was better to wire up my SNES controller to the GPIO port instead, because even if it required I do a bit of soldering it couldn't possibly take longer than writing even a small USB driver.

I ended up using jumper connectors on the pi end, and nails of sufficient diameter on the other.

lu1sRD1.jpg

Major shout out to a guy named Peter Lemon. He has a demo here which is actually exactly what I was trying to accomplish, and most of this was just essentially a replication of his work.

The SNES controller seems to work in two stages. First, you toggle the "latch" high and then low. I presume this updates the controller's internal state. Next you read in the "data" value, and toggle the "clock" high and then low. Repeat this step until all 16 bits of data are read from the controller. Each bit is a button's state on the controller, but its more convenient to append the bits altogether into a single bitfield and use that.

Lastly, I improved upon the blit code from last time. Now it will properly clip when it runs off the screen... that is until it goes completely off, and then it starts drawing random artifacts all over the place.... but nothings perfect =) Since I refactored the code from last time to play nicer with the registers I'd better post everything for it to make sense, instead of as snippets:

.macro var name r .ifdef __\name .unreq \name .endif \name .req \r .set __\name, 1 .endm .macro nop_delay count .rept \count nop .endr .endm .set VS_BASE, 0x2000B208 .set VS_MAG, 12 .set MB_BASE, 0x2000B880 .set MB_STATUS, 0x18 .set MB_WRITE, 0x20 .set GP_BASE, 0x20200000 .set GP_SEL0, 0 .set GP_SEL1, 4 .arm@ ============================================================================== mov sp, #0x8000 var base, r11 var fbi, r10 var fbp, r10 var req, r9 var res, r9 var px, r8 var py, r12@ Initiate output pins. ldr base, =GP_BASE mov req, #0x9 str req, [base, #GP_SEL1]@ Wait til the mailbox is not busy. ldr base, =MB_BASEbusy$: ldr res, [base, #MB_STATUS] tst res, #0x80000000 bne busy$@ Ask for framebuffer info (fbi). ldr fbi, =framebufinfo add req, fbi, #0x40000000 add req, #1 str req, [base, #MB_WRITE]listen$: ldr res, [base, #MB_STATUS] tst res, #0x40000000 bne listen$ ldr res, [base] cmp res, #1 bne listen$@ Wait for v-sync. mov px, #0 mov py, #0 ldr fbp, [fbi, #32]render$: ldr base, =VS_BASE mov req, #0x10000 str req, [base, #VS_MAG] ldr r0, =0x20600000 mov req, #0 str req, [r0]vsync$: ldr res, [base] tst res, #0x10000 beq vsync$@ Poll input. ldr base, =GP_BASE mov req, #0x800 str req, [base, #0x1c] @@ latch on nop_delay 12 str req, [base, #0x28] @@ latch off nop_delay 12 mov r0, #15 mov r1, #0nextbutton$: mov r1, r1, lsl #1 ldr res, [base, #0x34] @@ read bit tst res, #0x10 orreq r1, #1 mov req, #0x400 str req, [base, #0x1c] @@ clock on nop_delay 12 str req, [base, #0x28] @@ clock off nop_delay 12 subs r0, #1 bge nextbutton$ tst r1, #0b0000000100000000 @@ left subeq px, #1 tst r1, #0b0000001000000000 @@ right addeq px, #1 tst r1, #0b0000100000000000 @@ down addeq py, #1 tst r1, #0b0000010000000000 @@ up subeq py, #1 mov r0, #256 mov r1, #240 mov r2, fbp mov r3, px mov r4, py mov r5, #16 mov r6, #16 ldr r7, =spritesheet bl blit_clip b render$@ ==============================================================================@ Blit a spritesheet var dst, r0 var src, r1 var drofs, r2 var srofs, r3 var rowsiz, r4 var nrows, r5blit: push {r6-r8} add r6, srofs, rowsiz mul r6, nrows add r6, srcouter$: add r7, src, rowsizinner$: ldrb r8, [src] strb r8, [dst] add src, #1 add dst, #1 cmp src, r7 blt inner$ add dst, r2 add src, r3 cmp src, r6 blt outer$ pop {r6-r8} mov pc, lr@ ==============================================================================@ Blitting done with clipping var dw, r0 var dh, r1 var dst, r2 var sx, r3 var sy, r4 var sw, r5 var sh, r6 var src, r7blit_clip: var drofs, r8 var srofs, r9 var rowsiz, r10 var nrows, r11 push {r8-r12} mov drofs, #0 mov srofs, #0 mov rowsiz, sw mov nrows, sh cmp sx, #0 addgt drofs, sx addgt dst, sx sublt src, sx addlt rowsiz, sx add sx, sw subs sx, dw, sx addgt drofs, sx addlt rowsiz, sx cmp sy, #0 mullt r12, sy, sw sublt src, r12 addlt nrows, sy mulgt r12, sy, dw addgt dst, r12 add sy, sh subs sy, dh, sy addlt nrows, sy mov r0, dst mov r1, src mov r2, drofs mov r3, srofs mov r4, rowsiz mov r5, nrows pop {r8-r12} b blit@ ============================================================================== .poolspritesheet: .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .align 12framebufinfo: .int 640 .int 480 .int 256 .int 240 .int 0 .int 8 .int 0 .int 0 .int 0 .int 0OK thats all for now, time to go to bed smile.png Thanks for stopping by!
Segmented

Video memory on the pi

I suppose a quick intro is in order, seeing as this is my first post. The purpose of this blog shall be to log the development of a game I am making for my three younger sisters for Christmas. There is quite an age gap between me and my sisters, the eldest is 10, and the youngest is 6, to give an idea of my target audience. I'm hoping to make it a coop game so that none of them will be left out, but this is difficult from a design standpoint considering the range in their coordination.

I'm making it on the raspberry pi, which for those of you who don't know is a credit card sized onboard computer. Why? For one thing, it allows a direct connection to your TV. For another, I've been wanting an excuse to play with the one on my shelf smile.png. You can boot linux on these little guys, but I decided to go the route of pain instead and code the game as an OS using raw ARM assembly (I'm crazy, yes I know).

Things have been going surprisingly well so far, considering. I've meddled with x86 assembly before, but this is the first time trying out ARM assembly, so its a bit of a change-up in CPU architecture, it being RISC and all. I was fortunate enough to find this tutorial, which helped a lot.

Heres what I've come up with so far:
.set MB_BASE, 0x2000B880 .set MB_STATUS, 0x18 .set MB_WRITE, 0x20 .arm mov sp, #0x8000 ldr r0, =MB_BASE mov r1, #0x80000000@@ Wait for the go-ahead to ask for the framebufferloop$: ldr r3, [r0,#MB_STATUS] tst r3, r1 bne loop$@@ Store a request for info about the framebuffer mov r4, #0x40000000 ldr r5, =framebufinfo add r1, r5, r4 add r1, #1 str r1, [r0,#MB_WRITE]@@ Wait for a response about the framebufferloop2$: ldr r3, [r0,#MB_STATUS] tst r3, r4 bne loop2$@@ Check that the response is valid mov r1, #15 ldr r3, [r0] cmp r3, #1 bne loop2$ ldr r7, [r5,#32]@@ Wait until vertical retrace. This is when we do all our drawing, since it@@ will appear on the next draw, and there will be no flicker. Note this is@@ based off a snippet I found on the internet, as documentation on the subject@@ proved to be practically non-existant.render$: ldr r0, =0x2000B214 mov r1, #0x00010000 str r1, [r0] ldr r0, =0x20600000 mov r1, #0 str r1, [r0] ldr r0, =0x2000B208wait_vsync$: ldr r1, [r0] tst r1, #0x00010000 beq wait_vsync$@@ Now lets draw something!!! mov r0, r7 @@ dest ldr r1, =spritesheet @@ src mov r2, #0x00f0 @@ drofs mov r3, #0x0000 @@ srofs mov r4, #0x0010 @@ rowsiz mov r5, #0x0010 @@ nrows bl blit b render$@@ Blit a spritesheet@ r0: dest@ r1: src@ r2: drofs@ r3: srofs@ r4: rowsiz@ r5: nrowsblit: push {r6-r8} add r6, r3, r4 mul r6, r5 add r6, r1outer$: add r7, r1, r4inner$: ldrb r8, [r1] strb r8, [r0] add r1, #1 add r0, #1 cmp r1, r7 blt inner$ add r0, r2 add r1, r3 cmp r1, r6 blt outer$ pop {r6-r8} mov pc, lr .poolspritesheet: .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .byte 1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 .byte 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 .align 12framebufinfo: .int 640 .int 480 .int 256 .int 240 .int 0 .int 8 .int 0 .int 0 .int 0 .int 0I couldn't get FASMARM to work under OSX, so for now I'm stuck using gas to assemble, which isn't that different except for its inability to directly produce a raw image file (you have to use ld and objcopy).

I'd put a screenshot here of the result (as unexciting as it currently is) but I don't want to resort to taking a photo of my TV, so if anyone knows of a way to emulate the pi I would really love to know (for more than just screenshots actually).

Thats all for now, more to come smile.png Thanks for stopping by!
Sign in to follow this