snes homebrew project

[neen]

glider pro on the snes.

it started in 2016 when i emailed john calhoun, author of a series of macintosh games being released from 1988 to 1994. i asked him to post the source code online, and i had no idea why.

the original glider (1.0?) i have never seen, it may just be a myth. glider 2.02 has pascal source code somewhere. i might be able to find it on a hard drive. glider 3.14 too. all these early versions are 15-screen long arcade style games. single screen, no scrolling.

glider 4.0 was also written in pascal, in 1990-91 but this time had 16 colors and a level editor.

glider pro was written in C in 1994. even larger worlds, a much better editor (bettitor?), 256 colors, and was one of the first video games i played. i posted some houses online in the summer of 2003 or 2004 to a yahoo group. this was basically the end of online glider community, as far as i'm aware.

a few days ago i started looking at the C source of PRO with the intent of... well, something, i guess. snes homebrew is something i had been thinking about for a few months, after getting deeper into snes architecture and programming after romhacking super metroid for about 3 years.

so, here are some highlights of failed attempts to display a static background on the screen, which took about 2 or 3 days (yes, seriously, like 8 hours a day). i am not sure i really need toe C source at this point (or ever) but maybe once i get to the point of making an actual engine it will be useful.

[neen]

and finally it came together today. this is actual snes emulator output, and finally, on a real console. here's the github repo https://github.com/n-neen/glider , you can open it in a snes emu and be amazed at the nonmoving background. you'll probably see some garbage sprites if your emulator is accurate enough.

next up is to learn how to apply the skills we have with doing DMA to load sprites into OAM. well, first clear OAM to initialize it, because we have not yet done that.

[RT-55J]

aw yeah this looks nice

[neen]

the only real progress has been structural. i have implemented a state machine. after boot and some init, we drop into a state handler loop.

state 0 is the splash screen. we load graphics, tilemap, and palettes, then wait $80 frames. increase state to 1.

state 1 is the newgame preparation. right now this just loads a static background and some sprite graphics get uploaded to vram. also load new palettes. this is where the level data will be loaded and anything else for preparing to play the game. then increase game state to 2


state 2 is where gameplay will occur. currently this is a loop where we wait for nmi over and over.

oh yeah, non-maskable interrupt handler has been implemented. this is where sprites will be updated when that occurs. also we will read the controller port here. anything else that needs to happen while the electron gun is not drawing to the screen will happen now, too. set up dma, whatever.

Code Select Expand

main: {
        .stateinit: {
            lda #$0000
            sta !gamestate
        }
       
        .statehandle: {
            inc !maincounter                ;main switch case jump table loop
            lda !gamestate                  ;usually, state handler will
            asl                             ;return after running once, like newgame
            tax                             ;or itself has a loop, like playgame
            jsr (statetable,x)
           
            jmp .statehandle
        }
}


statetable:             ;program modes, game states, etc
    dw #splash          ;0
    dw #newgame         ;1
    dw #playgame        ;2
    dw #gameover        ;3

this is the core of the state machine. the rest is in https://github.com/n-neen/glider/blob/main/bank80.asm

this is the splash screen, with a palette i was playing around with. currently we just proceed from this to the static room background test from earlier. i need to figure out how to read the controller next (happens during nmi).

[RT-55J]

ooh that's a very nice title screen

[neen]

made a debug state handler and enabled debug mode. you can use the dpad to scroll the tilemap around, and you can press y, b, and x to change the background. i hope someday to display a sprite on the screen, but that day is not today

[neen]

the first iteration of the controller response code is pretty naively written as a gigantic switch case with cmp instructions. yuriks gave me a tip on how to rewrite it so we will have the ability to press multiple buttons at once! more details to follow

[neen]

controller reading is fine now, gotta use the bit instruction, not cmp, and check each button in some order.

initially, backgrounds were on layer 1. today, i moved them to layer 2. the idea is to use layer 1 for a mostly transparent tilemap where objects like furniture exist. this means we want to define a type of object for modifying part of the layer 1 tilemap to place objects around the room.