I've developed quite a few SNES-related things for fun, mostly using Go and C++, with some 65816 ASM sprinkled in.
https://github.com/alttpo/alttpo - A Link To The Past Online. Lets multiple players see and interact with one another in the same game world and synchronize their progress through the game. Exclusive to a customized fork of the bsnes emulator which provides a scripting language and PPU-integrated drawing routines to render remote player sprites. In retrospect, I consider this a dead-end architecture; redesigned in o2 project (see below).
https://github.com/alttpo/o2 - Second version of alttpo (see above) but this time targeted at SNES hardware console support (via SD2SNES flash cart USB feature) and does not require a customized emulator nor a scripting language. Trade-off here is a loss of the visual aspect (cannot see remote player sprites) due to tight hardware limitations in the amount of VRAM and limited SNES CPU cycles available. Work is in progress to gain back the remote sprite rendering as an optional add-on via the bsnes-plus WASM module support (see below). This project includes a 65816 machine code emitter library (pure Go) with support for named labels of branch targets. There is also a bare-bones headless SNES emulator library (pure Go) included for unit tests to verify the generated 65816 ASM and ROM patching mechanism.
https://github.com/alttpo/bsnes-plus - A fork of bsnes-plus in development that invokes WebAssembly modules when certain general SNES events occur, e.g. `on_nmi`, `on_power`, `on_reset`, `on_frame_present`. WASM code has access to a draw-list API for drawing into the various PPU layers, e.g. extra sprites, text (with PCF font support), basic shapes. WASM code can also receive arbitrary binary messages from external applications, e.g. to update remote player positions or exchange custom sprite graphics.
Great idea, there are so many games that would actually be played with even a basic co-op support like this. It's okay it's just an overlay with no shared-game state, still really fun!
I'm more interested in SPC700 development for SNES music. Mesen-SX has a SPC debugger separate from the main debugger, but I'm not sure if it's more or less useful than bsnes-plus (I know the Mesen emulators have a far worse Linux UI when running under Mono, and I haven't tried running the Windows Mesen under Mono or real .NET yet). I don't know enough to judge if the disassembler is better or worse than bsnes-plus though.
A friend of mine from high school is working on a SNES tracker[0]. He’s deep into this space and could probably answer your questions if you catch him on stream[1]. He also authored many of the sections on the SNES development wiki linked by the article (under “bazz”).
If you decide you really enjoy 65816 development, just a gentle reminder: The Apple IIGS dev community would love to have you and we're seeing new hardware releases at a pace we haven't seen since the 1990s.
And if there are people specifically interested in console-style IIgs game development, I've picked up and significantly enhanced my old graphics engine that was used for the IIgs Super Mario Bros demo.
I really want to make a retro version of my turn based strategy game Proximity[1] (pretty simple game and I've mostly made a version in Pico-8 already, so it should be doable) for NES, GB, SNES, GBA, and/or something similar, but I'd like to do it with the smallest amount of time and effort necessary (because I really don't have a lot of time anymore).
It seems like the new GBDK might be the easiest, especially since I recently ran into the source code[2] for a Wordle clone someone made using it that I could reference, but is there perhaps an even easier way? Most of the low-code software kits assume you're moving sprites around on a screen and don't seem like a good fit for the project.
I can't speak to any of the low code approaches, but I do know it wouldn't be that hard for a GBA implementation once you learned the hardware (and the resources for learning it are pretty good). Each hexagon could be its own sprite (probably even with the text on them already, to make it super trivial), and then you can probably just DMA them into the appropriate place in memory during vblank. So then it's just the game state/logic. All of which is pretty straightforward in C, though there is tooling around other languages as well.
https://github.com/gbadev-org/awesome-gbadev has a buncha resources, though I can personally attest to Tonc as being everything you need for getting up and running (at least it was years ago when I used it, but the GBA hasn't changed since then; just the tooling and environment may have gotten better)
That link doesn't work well, just says it's not compatible with my device. There's a link that goes to some seo spam. Name not very googlable. Do u have a link to some screenshots/play video?
Get ready to scroll if you do. The first significant chunk of the document was around Nintendo's (in)famous licensing process and instructions. It wasn't surprising, but confirms a lot about what we hear regularly about Nintendo of the 80s and 90s being hard to work with because of licensing and the way they treat third-party developers.
It's awesome. Not many new materials dedicated for good old game console programming. BTW, the book also covers Nintendo, Gameboy, Sega, Atari (!!), etc.
I generally advise against using bass for home-brew development. Bass is not a very well thought out assembler. I've never used it for 65816, but for other architectures like MIPS has some serious design issues that cause invalid code to be silently accepted by default, which is normally a disaster when it gets to debugging.
For MIPS at least, one of the completely wrong design decision has been to map basic register indices to raw numbers. For instance, in bass, this is a valid instruction:
add 2, 4, 5
which means "add register 4 and 5 together and write the result in register 2". Normally, one would write that line with the register aliases:
add v0, a0, a1
The problem comes with the fact that MIPS has also a "addi" (add immediate instruction) that you would use like this:
addi v0, a0, 5
"add the immediate value 5 to a0 and store the result in v0". So I guess the problem is clear: what happens if you instead write:
add v0, a0, 5
There are two possible reasonable outcomes: either the assembler should reject the above line as invalid, or it should silently convert it to "addi" which is what GNU as does for instance. Instead, with bass, the above is a perfectly valid line which gets assembled to the same of "add v0, a0, a1", which basically silently generates wrong code.
I think bass was a quick hack that overgrew its intended goal. I suggest to use something more mature.
[+] [-] jsd1982|4 years ago|reply
https://github.com/alttpo/alttpo - A Link To The Past Online. Lets multiple players see and interact with one another in the same game world and synchronize their progress through the game. Exclusive to a customized fork of the bsnes emulator which provides a scripting language and PPU-integrated drawing routines to render remote player sprites. In retrospect, I consider this a dead-end architecture; redesigned in o2 project (see below).
https://github.com/alttpo/o2 - Second version of alttpo (see above) but this time targeted at SNES hardware console support (via SD2SNES flash cart USB feature) and does not require a customized emulator nor a scripting language. Trade-off here is a loss of the visual aspect (cannot see remote player sprites) due to tight hardware limitations in the amount of VRAM and limited SNES CPU cycles available. Work is in progress to gain back the remote sprite rendering as an optional add-on via the bsnes-plus WASM module support (see below). This project includes a 65816 machine code emitter library (pure Go) with support for named labels of branch targets. There is also a bare-bones headless SNES emulator library (pure Go) included for unit tests to verify the generated 65816 ASM and ROM patching mechanism.
https://github.com/alttpo/bsnes-plus - A fork of bsnes-plus in development that invokes WebAssembly modules when certain general SNES events occur, e.g. `on_nmi`, `on_power`, `on_reset`, `on_frame_present`. WASM code has access to a draw-list API for drawing into the various PPU layers, e.g. extra sprites, text (with PCF font support), basic shapes. WASM code can also receive arbitrary binary messages from external applications, e.g. to update remote player positions or exchange custom sprite graphics.
[+] [-] new_stranger|4 years ago|reply
[+] [-] a_t48|4 years ago|reply
[+] [-] muterad_murilax|4 years ago|reply
Part 2: https://blog.wesleyac.com/posts/snes-dev-2-background-graphi...
Part 3: https://blog.wesleyac.com/posts/snes-dev-3-input
Part 4: https://blog.wesleyac.com/posts/snes-dev-4-nmi-and-vblank
Part 5: https://blog.wesleyac.com/posts/snes-dev-5-dma
Part 6: https://blog.wesleyac.com/posts/snes-dev-6-sprites
[+] [-] nyanpasu64|4 years ago|reply
I'm more interested in SPC700 development for SNES music. Mesen-SX has a SPC debugger separate from the main debugger, but I'm not sure if it's more or less useful than bsnes-plus (I know the Mesen emulators have a far worse Linux UI when running under Mono, and I haven't tried running the Windows Mesen under Mono or real .NET yet). I don't know enough to judge if the disassembler is better or worse than bsnes-plus though.
[+] [-] teeray|4 years ago|reply
[0] https://github.com/bazz1tv/snestracker
[1] https://www.twitch.tv/Bazz1tv
[+] [-] DaiPlusPlus|4 years ago|reply
[+] [-] matheusmoreira|4 years ago|reply
https://youtu.be/Q8ph2OVqZeM
[+] [-] coldpie|4 years ago|reply
[+] [-] justanother|4 years ago|reply
[+] [-] lscharen|4 years ago|reply
It's available on github at https://github.com/lscharen/iigs-game-engine
[+] [-] hnthrowaway0315|4 years ago|reply
[+] [-] kevdev|4 years ago|reply
[+] [-] k4shm0n3y|4 years ago|reply
[+] [-] cableshaft|4 years ago|reply
It seems like the new GBDK might be the easiest, especially since I recently ran into the source code[2] for a Wordle clone someone made using it that I could reference, but is there perhaps an even easier way? Most of the low-code software kits assume you're moving sprites around on a screen and don't seem like a good fit for the project.
[1]: https://www.newgrounds.com/portal/view/183428
[2]: https://github.com/stacksmashing/gb-wordle
[+] [-] lostcolony|4 years ago|reply
https://github.com/gbadev-org/awesome-gbadev has a buncha resources, though I can personally attest to Tonc as being everything you need for getting up and running (at least it was years ago when I used it, but the GBA hasn't changed since then; just the tooling and environment may have gotten better)
[+] [-] ant6n|4 years ago|reply
[+] [-] willis936|4 years ago|reply
The official developer manual? I want to flip through that just to learn more about the system and the context for game development at the time.
[+] [-] eddieroger|4 years ago|reply
[+] [-] john-doe|4 years ago|reply
[+] [-] anta40|4 years ago|reply
And also accompanied by a book: https://www.amazon.com/gp/product/B08W7DWZB3/
It's awesome. Not many new materials dedicated for good old game console programming. BTW, the book also covers Nintendo, Gameboy, Sega, Atari (!!), etc.
[+] [-] thehias|4 years ago|reply
https://github.com/ARM9/bass
and the snes dev kit
https://github.com/alekmaul/pvsneslib
[+] [-] giovannibajo1|4 years ago|reply
For MIPS at least, one of the completely wrong design decision has been to map basic register indices to raw numbers. For instance, in bass, this is a valid instruction:
which means "add register 4 and 5 together and write the result in register 2". Normally, one would write that line with the register aliases: The problem comes with the fact that MIPS has also a "addi" (add immediate instruction) that you would use like this: "add the immediate value 5 to a0 and store the result in v0". So I guess the problem is clear: what happens if you instead write: There are two possible reasonable outcomes: either the assembler should reject the above line as invalid, or it should silently convert it to "addi" which is what GNU as does for instance. Instead, with bass, the above is a perfectly valid line which gets assembled to the same of "add v0, a0, a1", which basically silently generates wrong code.I think bass was a quick hack that overgrew its intended goal. I suggest to use something more mature.
[+] [-] thar0x29a|4 years ago|reply
[+] [-] McHankHenry|4 years ago|reply