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 . 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 Thanks for stopping by!