6 ms·

SNES Development Part 1: Getting Started

willis936 5y ago
Holy smokes! What a list of resources. 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 5y ago
  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.
- john-doe 5y ago
  You might also enjoy this piece about the Nintendo Game Processor, and its software, the “Mario Factory.” https://lunduke.substack.com/p/nintendo-game-processor-the-lost https://lunduke.substack.com/p/nintendo-game-processor-the-l...
muterad_murilax 5y ago
Also: Part 2: https://blog.wesleyac.com/posts/snes-dev-2-background-graphics https://blog.wesleyac.com/posts/snes-dev-2-background-graphi... Part 3: https://blog.wesleyac.com/posts/snes-dev-3-input https://blog.wesleyac.com/posts/snes-dev-3-input Part 4: https://blog.wesleyac.com/posts/snes-dev-4-nmi-and-vblank https://blog.wesleyac.com/posts/snes-dev-4-nmi-and-vblank Part 5: https://blog.wesleyac.com/posts/snes-dev-5-dma https://blog.wesleyac.com/posts/snes-dev-5-dma Part 6: https://blog.wesleyac.com/posts/snes-dev-6-sprites https://blog.wesleyac.com/posts/snes-dev-6-sprites
DaiPlusPlus 5y ago
On a related note, the Retro Game Mechanics Explained YouTube channel has excellent videos about how SNES hardware works: https://www.youtube.com/c/RetroGameMechanicsExplained/videos https://www.youtube.com/c/RetroGameMechanicsExplained/videos
- matheusmoreira 5y ago
  I love this channel. My favorite video is the one about lag and blanking interrupts which is so widely applicable even today. https://youtu.be/Q8ph2OVqZeM https://youtu.be/Q8ph2OVqZeM
- coldpie 5y ago
  Agreed, and also want to mention Displaced Gamers https://www.youtube.com/c/DisplacedGamers https://www.youtube.com/c/DisplacedGamers
nyanpasu64 5y ago
Personally instead of Mesen-S, I'd use the fork at https://github.com/NovaSquirrel/Mesen-SX https://github.com/NovaSquirrel/Mesen-SX, which contains a fix for saving settings on Linux Mono 6.12 (https://github.com/NovaSquirrel/Mesen-SX/commit/c374ca8b9ed35aeca532ce24be20a30c5a4e4da6 https://github.com/NovaSquirrel/Mesen-SX/commit/c374ca8b9ed3...). 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 5y ago
  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”). [0] https://github.com/bazz1tv/snestracker https://github.com/bazz1tv/snestracker [1] https://www.twitch.tv/Bazz1tv https://www.twitch.tv/Bazz1tv
  - nyanpasu64 5y ago
    The README says "the latest version of SNES Tracker is available exclusively via Patreon a few weeks before it becomes available on github". In https://github.com/bazz1tv/snestracker/releases https://github.com/bazz1tv/snestracker/releases, v0.2.0 was released in 2020-09-29 and says "the next version, v0.2.1 is already released to Patreon!" In reality, v0.2.1 was released publicly months later on 2021-02-19, with a tasteless notice saying "Note: the next version, v0.2.2 and v0.2.3 is already released to Patreon! This includes a critical bugfix (app hanging)." The public Github repository you linked hasn't been updated in 11 months (v0.2.2 source and releases last updated in 2021-03-15), and v0.2.2 actually dates back to 2020-11-08 on Patreon. The Patreon (https://www.patreon.com/bazz1 https://www.patreon.com/bazz1) was last updated in 2021-03-14 with v0.2.4, yet continues to take money for the past 11 months of silence. I've heard that he's stopped supplying builds to Patreon subscribers, and only giving them to Twitch subscribers. This is my first time looking at his Twitch, and wow that's a lot of livestreaming uploads. I don't know if SNES Tracker is still being developed or not, and if Twitch subscribers receive newer builds of the tracker. In any case I'm definitely not subscribing. I tried cloning the repo to view the current publicly released state. It has over 100 MB of files previously in history but deleted in a more recent commit, polluting non-shallow clones. I couldn't get it to build easily, so I downloaded the prebuilt Windows v0.2.2. The user interface is bare-bones and written in SDL, though I didn't poke around very deeply. In any case I'll consider checking on his Twitch streams, and see if he can help me, though I prefer interacting with other people who don't behave in ethically dubious ways. I've already figured out how to make the S-DSP output sound. I'm currently working on learning S-SMP/SPC700 programming, writing/picking a hardware driver, (if I write my own driver) picking efficiently-implementable behaviors while remaining musically useful, or (if I pick an existing driver) learning the driver and build system. Eventually I want a characterization of the SNES's analog frequency/phase response (DAC impulse response plus analog filtering) so I can implement it in software. I feel eliminating unneeded audio latency, and implementing aliasing-free hardware-accurate resampling/filtering, are aspects that most emulators (even accurate ones like bsnes/higan) get wildly wrong, which I can improve with effort.
thehias 5y ago
also check out the bass asembler https://github.com/ARM9/bass https://github.com/ARM9/bass and the snes dev kit https://github.com/alekmaul/pvsneslib https://github.com/alekmaul/pvsneslib
- giovannibajo1 5y ago
  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.
  - nyanpasu64 5y ago
    Can bass be fixed to remove this design flaw? Is xkas/asar worse than bass? A lot of SMW-adjacent romhacking tools use xkas/asar which preceded bass (the author discussed at https://news.ycombinator.com/item?id=11720057 https://news.ycombinator.com/item?id=11720057). Some alternatives I've come across include macro packs for ca65 to make it assemble for instruction sets it doesn't understand natively, and I hear tass64 has macro packs too.
    - 5y ago
justanother 5y ago
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.
- kevdev 5y ago
  Is there a good website/subreddit/etc for the Apple IIGS dev community you’d recommend?
  - majjam 5y ago
    https://apple2.gs/communities.php https://apple2.gs/communities.php
    - MegaDeKay 5y ago
      "Last Update, 2014-08-18"
- k4shm0n3y 5y ago
  Have a link to where the community resides?
  - majjam 5y ago
    https://apple2.gs/communities.php https://apple2.gs/communities.php
- hnthrowaway0315 5y ago
  Just curious is there an affordable kit to build one's own Apple IIGS? Considering GS is more powerful than II, would love to have one instead of II.
- lscharen 5y ago
  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. It's available on github at https://github.com/lscharen/iigs-game-engine https://github.com/lscharen/iigs-game-engine
cableshaft 5y ago
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. [1]: https://www.newgrounds.com/portal/view/183428 https://www.newgrounds.com/portal/view/183428 [2]: https://github.com/stacksmashing/gb-wordle https://github.com/stacksmashing/gb-wordle
- lostcolony 5y ago
  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 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)
  - CoolGuySteve 5y ago
    Yes, out of all the old systems, I think the GBA is the easiest to program for. The design is more streamlined/modern overall so that you don't have to worry about things like bank switching and the GPU has a cleaner design than the SNES. The BIOS, graphics, and audio firmware fit nicely with the 32bit ARM architecture such that all you have to do is poke data into the right address (usually a #define'ed pointer in C) and it DMAs to the hardware. And unlike later consoles, there's no operating system or significant copy protection to deal with, you link in a crt0.s to put everything at the right address, load the rom into an emulator, and it will start displaying your game. When your ready, you pop a flashcart into your hardware and it will probably work too. It's all very nice.
jsd1982 5y ago
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 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 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 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 5y ago
  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!
  - jsd1982 5y ago
    Oh but there is shared game state! Most of SRAM data is synced for ALTTP and there's even a PvP feature so you can slash at each other with swords and use some of the items to damage each other. Of course you can enable/disable whatever bits of state to sync or not.
anta40 5y ago
Another fantastic resource (SDK + example codes): https://www.chibiakumas.com/6502/snes.php https://www.chibiakumas.com/6502/snes.php And also accompanied by a book: https://www.amazon.com/gp/product/B08W7DWZB3/ 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.
McHankHenry 5y ago
Very cool hardware in that little machine.
thar0x29a 5y ago
Awesome project. Cant wait to look around in it :)

Holy smokes! What a list of resources. 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 5y ago
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.
john-doe 5y ago
You might also enjoy this piece about the Nintendo Game Processor, and its software, the “Mario Factory.” https://lunduke.substack.com/p/nintendo-game-processor-the-lost https://lunduke.substack.com/p/nintendo-game-processor-the-l...

muterad_murilax 5y ago

Also: Part 2: https://blog.wesleyac.com/posts/snes-dev-2-background-graphics https://blog.wesleyac.com/posts/snes-dev-2-background-graphi... Part 3: https://blog.wesleyac.com/posts/snes-dev-3-input https://blog.wesleyac.com/posts/snes-dev-3-input Part 4: https://blog.wesleyac.com/posts/snes-dev-4-nmi-and-vblank https://blog.wesleyac.com/posts/snes-dev-4-nmi-and-vblank Part 5: https://blog.wesleyac.com/posts/snes-dev-5-dma https://blog.wesleyac.com/posts/snes-dev-5-dma Part 6: https://blog.wesleyac.com/posts/snes-dev-6-sprites https://blog.wesleyac.com/posts/snes-dev-6-sprites

DaiPlusPlus 5y ago

On a related note, the Retro Game Mechanics Explained YouTube channel has excellent videos about how SNES hardware works: https://www.youtube.com/c/RetroGameMechanicsExplained/videos https://www.youtube.com/c/RetroGameMechanicsExplained/videos

matheusmoreira 5y ago
I love this channel. My favorite video is the one about lag and blanking interrupts which is so widely applicable even today. https://youtu.be/Q8ph2OVqZeM https://youtu.be/Q8ph2OVqZeM
coldpie 5y ago
Agreed, and also want to mention Displaced Gamers https://www.youtube.com/c/DisplacedGamers https://www.youtube.com/c/DisplacedGamers

nyanpasu64 5y ago

Personally instead of Mesen-S, I'd use the fork at https://github.com/NovaSquirrel/Mesen-SX https://github.com/NovaSquirrel/Mesen-SX, which contains a fix for saving settings on Linux Mono 6.12 (https://github.com/NovaSquirrel/Mesen-SX/commit/c374ca8b9ed35aeca532ce24be20a30c5a4e4da6 https://github.com/NovaSquirrel/Mesen-SX/commit/c374ca8b9ed3...). 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 5y ago
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”). [0] https://github.com/bazz1tv/snestracker https://github.com/bazz1tv/snestracker [1] https://www.twitch.tv/Bazz1tv https://www.twitch.tv/Bazz1tv
- nyanpasu64 5y ago
  The README says "the latest version of SNES Tracker is available exclusively via Patreon a few weeks before it becomes available on github". In https://github.com/bazz1tv/snestracker/releases https://github.com/bazz1tv/snestracker/releases, v0.2.0 was released in 2020-09-29 and says "the next version, v0.2.1 is already released to Patreon!" In reality, v0.2.1 was released publicly months later on 2021-02-19, with a tasteless notice saying "Note: the next version, v0.2.2 and v0.2.3 is already released to Patreon! This includes a critical bugfix (app hanging)." The public Github repository you linked hasn't been updated in 11 months (v0.2.2 source and releases last updated in 2021-03-15), and v0.2.2 actually dates back to 2020-11-08 on Patreon. The Patreon (https://www.patreon.com/bazz1 https://www.patreon.com/bazz1) was last updated in 2021-03-14 with v0.2.4, yet continues to take money for the past 11 months of silence. I've heard that he's stopped supplying builds to Patreon subscribers, and only giving them to Twitch subscribers. This is my first time looking at his Twitch, and wow that's a lot of livestreaming uploads. I don't know if SNES Tracker is still being developed or not, and if Twitch subscribers receive newer builds of the tracker. In any case I'm definitely not subscribing. I tried cloning the repo to view the current publicly released state. It has over 100 MB of files previously in history but deleted in a more recent commit, polluting non-shallow clones. I couldn't get it to build easily, so I downloaded the prebuilt Windows v0.2.2. The user interface is bare-bones and written in SDL, though I didn't poke around very deeply. In any case I'll consider checking on his Twitch streams, and see if he can help me, though I prefer interacting with other people who don't behave in ethically dubious ways. I've already figured out how to make the S-DSP output sound. I'm currently working on learning S-SMP/SPC700 programming, writing/picking a hardware driver, (if I write my own driver) picking efficiently-implementable behaviors while remaining musically useful, or (if I pick an existing driver) learning the driver and build system. Eventually I want a characterization of the SNES's analog frequency/phase response (DAC impulse response plus analog filtering) so I can implement it in software. I feel eliminating unneeded audio latency, and implementing aliasing-free hardware-accurate resampling/filtering, are aspects that most emulators (even accurate ones like bsnes/higan) get wildly wrong, which I can improve with effort.

thehias 5y ago

also check out the bass asembler https://github.com/ARM9/bass https://github.com/ARM9/bass and the snes dev kit https://github.com/alekmaul/pvsneslib https://github.com/alekmaul/pvsneslib

giovannibajo1 5y ago
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.
- nyanpasu64 5y ago
  Can bass be fixed to remove this design flaw? Is xkas/asar worse than bass? A lot of SMW-adjacent romhacking tools use xkas/asar which preceded bass (the author discussed at https://news.ycombinator.com/item?id=11720057 https://news.ycombinator.com/item?id=11720057). Some alternatives I've come across include macro packs for ca65 to make it assemble for instruction sets it doesn't understand natively, and I hear tass64 has macro packs too.
  - 5y ago

justanother 5y ago

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.

kevdev 5y ago
Is there a good website/subreddit/etc for the Apple IIGS dev community you’d recommend?
- majjam 5y ago
  https://apple2.gs/communities.php https://apple2.gs/communities.php
  - MegaDeKay 5y ago
    "Last Update, 2014-08-18"
k4shm0n3y 5y ago
Have a link to where the community resides?
- majjam 5y ago
  https://apple2.gs/communities.php https://apple2.gs/communities.php
hnthrowaway0315 5y ago
Just curious is there an affordable kit to build one's own Apple IIGS? Considering GS is more powerful than II, would love to have one instead of II.
lscharen 5y ago
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. It's available on github at https://github.com/lscharen/iigs-game-engine https://github.com/lscharen/iigs-game-engine

cableshaft 5y ago

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. [1]: https://www.newgrounds.com/portal/view/183428 https://www.newgrounds.com/portal/view/183428 [2]: https://github.com/stacksmashing/gb-wordle https://github.com/stacksmashing/gb-wordle

lostcolony 5y ago
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 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)
- CoolGuySteve 5y ago
  Yes, out of all the old systems, I think the GBA is the easiest to program for. The design is more streamlined/modern overall so that you don't have to worry about things like bank switching and the GPU has a cleaner design than the SNES. The BIOS, graphics, and audio firmware fit nicely with the 32bit ARM architecture such that all you have to do is poke data into the right address (usually a #define'ed pointer in C) and it DMAs to the hardware. And unlike later consoles, there's no operating system or significant copy protection to deal with, you link in a crt0.s to put everything at the right address, load the rom into an emulator, and it will start displaying your game. When your ready, you pop a flashcart into your hardware and it will probably work too. It's all very nice.

jsd1982 5y ago

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 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 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 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 5y ago
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!
- jsd1982 5y ago
  Oh but there is shared game state! Most of SRAM data is synced for ALTTP and there's even a PvP feature so you can slash at each other with swords and use some of the items to damage each other. Of course you can enable/disable whatever bits of state to sync or not.

anta40 5y ago

Another fantastic resource (SDK + example codes): https://www.chibiakumas.com/6502/snes.php https://www.chibiakumas.com/6502/snes.php And also accompanied by a book: https://www.amazon.com/gp/product/B08W7DWZB3/ 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.

McHankHenry 5y ago

Very cool hardware in that little machine.

thar0x29a 5y ago

Awesome project. Cant wait to look around in it :)