[HN Gopher] SNES Development Part 1: Getting Started
___________________________________________________________________
SNES Development Part 1: Getting Started
Author : muterad_murilax
Score : 242 points
Date : 2022-02-11 09:06 UTC (13 hours ago)
(HTM) web link (blog.wesleyac.com)
(TXT) w3m dump (blog.wesleyac.com)
| DaiPlusPlus wrote:
| 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
| matheusmoreira wrote:
| 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
| coldpie wrote:
| Agreed, and also want to mention Displaced Gamers
| https://www.youtube.com/c/DisplacedGamers
| justanother wrote:
| 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.
| lscharen wrote:
| 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
| kevdev wrote:
| Is there a good website/subreddit/etc for the Apple IIGS dev
| community you'd recommend?
| majjam wrote:
| https://apple2.gs/communities.php
| k4shm0n3y wrote:
| Have a link to where the community resides?
| majjam wrote:
| https://apple2.gs/communities.php
| hnthrowaway0315 wrote:
| 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.
| nyanpasu64 wrote:
| Personally instead of Mesen-S, I'd use the fork at
| 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/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 wrote:
| 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
|
| [1] https://www.twitch.tv/Bazz1tv
| thehias wrote:
| also check out the bass asembler
|
| https://github.com/ARM9/bass
|
| and the snes dev kit
|
| https://github.com/alekmaul/pvsneslib
| giovannibajo1 wrote:
| 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.
| tom_ wrote:
| I've been very happy with 64tass for 6502 code:
| http://tass64.sourceforge.net/ - apparently supports 65816 as
| well.
| nyanpasu64 wrote:
| 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).
|
| 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.
| tadfisher wrote:
| Unfortunately the author passed away recently. If there is
| a community fork of bass that would make it easier.
| jsd1982 wrote:
| 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.
| a_t48 wrote:
| I didn't know there was a v2 of alttpo going on! I will have to
| give it a look, I wasn't a fan of v1 because of it being tied
| to an emulator.
| jsd1982 wrote:
| Yep, it's aimed mostly at console users though it works with
| emulator too, just without sprite sync. WIP on sprite sync
| for emulator to bring that back
| new_stranger wrote:
| 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 wrote:
| 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 wrote:
| Another fantastic resource (SDK + example codes):
| https://www.chibiakumas.com/6502/snes.php
|
| 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.
| McHankHenry wrote:
| Very cool hardware in that little machine.
| willis936 wrote:
| 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 wrote:
| 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 wrote:
| 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-l...
| muterad_murilax wrote:
| Also:
|
| 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
| cableshaft wrote:
| 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
|
| [2]: https://github.com/stacksmashing/gb-wordle
| ant6n wrote:
| 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?
| cableshaft wrote:
| I have a video for the sequel when I released it on Xbox 360,
| although that's not what I linked to at first. The first link
| is Newgrounds, an old flash animation/game website that I
| first released the original game on 17 years ago (oh man,
| it's really been that long?).
|
| https://youtu.be/Yqe0hS7AvOE
|
| I'm also currently working on a new version for desktop and
| hopefully eventually consoles that uses 3D models, larger
| maps, 8 team local support, map editor, hopefully either a
| campaign or challenge mode (eventually, maybe not on first
| release), and hoping to add support for up to 150-ish stream
| viewers to join various teams and play on one of the 8 teams
| (where they vote for moves kind of like in Twitch Plays
| Pokemon).
|
| Here's a year old video when I was just starting the project,
| I desperately need to make a newer video (hopefully this
| weekend finally):
|
| https://youtu.be/0IAx9fsBuus
|
| But I still would love to have a weekend project at some
| point of making a retro version.
| lostcolony wrote:
| 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)
| CoolGuySteve wrote:
| 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.
| cableshaft wrote:
| Thank you! I'll check it out.
|
| I wasn't actually asking for anything low-code, I'm fine with
| coding, just hoping I can mostly stick with a C/C++ style
| approach without having to dig too deep into understanding
| the memory and registers and other things on a hardware
| level.
|
| I've done some reading of materials on the hardware before
| (NES and GB mostly), and it's interesting, I just don't have
| the mental bandwidth at the moment to turn that casual
| understanding into usable code.
|
| Maybe eventually I can get to that point, but for now if I
| can get by with mostly my game logic and some function calls
| to various wrappers for the hardware functionality, the
| better.
___________________________________________________________________
(page generated 2022-02-11 23:01 UTC)