Is there a reason why the Megadrive/Genesis gets more homebrew and or demos than the SNES/SFC?

[SNESPlayer]

No, seriously, it's something I've been pondering in my sleep as of recently. I've been recently reading an interview for a game called Earthion, made with SGDK https://www.timeextension.com/features/ ... -really-is

And it seems like the devs had a blast (heh) making this game, and are looking to make their next game on that system as well. I've also read about a new demo for a SoTN prototype running on the Genesis, as well as the recent news that Paprium was finally playable on emulators through the efforts of reverse engineering teams in Brazil and this has all led me wondering: Of the 16-bit consoles, why is the Genesis in particular getting the most attention here?

I say this because in other communities, you do see demos and homebrew for a lot of devices but usually, some tend to weight heavier than the others. What I mean with that is the amount of them, you'll see more homebrew for the NES than you would for the Master System, and conversely, you'd see far, far, far more homebrew on the GB/GBC than the GameGear. I usually chalk this up to the popularity of those systems, as well as emulators for the NES and GameBoy coming earlier than those for Sega consoles (could be wrong on this one though, about Nintendo emulators predating Sega ones)

But is a complete blowout for Sega's 16-bit console here. In spite of the fact that the SNES seemingly sold more than the other console by lifetime sales and has enough nostalgia and popularity boosting it, it doesn't get nearly as much homebrew in comparison. Is it a result of the MD/GS being easier to program for? I've read that documentation for the 68000 has been, historically, much better than that of the SNES's CPU for a long time and the relative straightforwardness of Sega's hardware also helps here (as opposed to the way the SNES components work in tandem), but I am not sure if those are the only factors at play here.

[aa-dav]

I'm really do not know why, but after learning about both architectures I admit: SMD is much simpler and easy to use.
LoROM/HiROM in SNES is much more harder to implement in C compiler than linear memory map in SMD.
SMD CPU ISA is 32-bit ISA, not 16-bit. 16-bit is about data address lines and internal CPU units. But ISA is 32-bit.
SNES CPU is truly 16-bit with the pain in the ass of the memory banks/page mappings.
Video modes are not that important for this topic, but also simplicity of SMD is the fact: there is only 1 really useful video mode in SMD which is used anywhere. SNES has bunch of videomodes with different capabilites, but with exclusion of mode 7 (exceptional thing!) they are redundant and unnecessary (eh, I will be damned for this sentence here ).
SMD has only 1 "16-bit video mode" with 2 back layers and sprites - all of this with the same color scheme - easy and simple. Just use and don't ask.
SNES is much more complicated in this question.

[creaothceann]

SNES has very few registers (unless you want to include the page zero area), which is supposedly harder on compiler writers. So on the SNES you have to know assembly. And the ISA is not orthogonal at all - all the registers have very specialized functions.

SNES audio is quite complicated. You have to basically learn how to program another smaller computer.

SNES CPU is truly 16-bit with the pain in the ass of the memory banks/page mappings.

There's also the issue that registers / memory accesses could be 8 or 16 bits wide.

SNES has bunch of videomodes with different capabilites, but with exclusion of mode 7 (exceptional thing!) they are redundant and unnecessary

Mode 0 is useful if you somehow need the layers. Offset-per-tile modes are nice for independent tile scrolling, like Tetris Attack. High-color modes are good for static screens, if you have the ROM space.

[NovaSquirrel]

I don't think there's very much passion or interest in making games for the SNES regardless of how easy or difficult it is. I don't see a lot of people engage with the console much past just trying out a few popular games, and I don't see romhackers really care about the console past just that it happens to be the platform the game they want to hack was made for. I feel like maybe part of this is because the SNES's graphics are good enough that games can look however they want and the console does not really have a particular aesthetic, so it's just whatever aesthetics each games' artists went for. I think people are drawn to the NES and Game Boy partially because what an "NES game" or "Game Boy game" looks like and sounds like is more specific and those limited aesthetics have become iconic. I also don't see many people working on 2D GBA games (but lots of 3D engine stuff), and it's the easiest and friendliest 2D console I've ever seen.

SNES audio is quite complicated. You have to basically learn how to program another smaller computer.

Same situation on the Genesis (and it's worse, because the z80 is very different from the 68000, and you have to care about the 68k and z80 interacting with the same bus), though I don't think people often write audio drivers anyway. With Terrific Audio Driver we have a very good option nowadays that you can just drop into a game.

[TmEE]

SNES audio is quite complicated. You have to basically learn how to program another smaller computer.

Sound on MD is also similarly learning another computer, there is that Z80 there for doing sound and you'll need it to play samples. Sometimes even several, and there are examples of pitch control too and you need to write some really good assembly if you want anything fun. But difference from SNES is that both 68K and Z80 can freely access each other's address space, no little keyhole interface with communication protocol overhead. Z80 in MD can, for example, read any data from ROM and only cost is slightly lower performance of 68K due to stolen bus cycles to access *anything* in the ROM without help from 68K. If you want to help the SPC700 side get more than 64KB of stuff, you need to involve main CPU relatively actively into the process. I do think SPC is simpler, simply because of the sample aspect although 64KB is a big limit for them. Getting good results with the YM chips is not so easy and good results need a lot of fiddling the knobs so to speak, and the FM chips have a lot more of them than sample things do. But similarly, I don't actually see much SNES in the chiptune world either, in which I still participate in some capacity since I was a teenager. YM chips seem to have risen a lot in popularity but NES and GB are still higher I think. Things like Furnace seem to be helping all the other things to sort of catch up

---

I only know SNES by spec (big thanks to nocash's excellent documentation !), but I have not tried to develop for it so I don't know all the things you could do. I got spoiled by 68K quite early on and while I would be able to master 65816 and SNES itself, it would be an exercise in relative masochism and I'm not really into that lol. I know making a game I would like to make is going to be a much greater challenge on SNES than on MD, the 8/16bitness with all its joys is really limiting compared to 32bit freedom from 68K. The "ISA" matters as was put earlier. While I personally write in assembly, I know a lot of people who only will not want to or be able to, and just do things in full C and few souls even C++ and only because of GCC doing ok enough code for the CPU. I am aware there are C compilers in 65x world too but it seems that use of them will put significant limits on what kind of game you can get due to the mentioned difficulty of producing code for the architecture. The previously mentioned SGDK is making things relatively easy, I am not sure there is anything quite featured on the SNES to let someone ease into the entire thing without having to really get into the nitty gritty at first. Maybe later on you need to actually learn the hardware to get better performance.

If I am ever going to write something for SNES it is probably something for testing some hardware feature, for science reasons lol. Nowdays I am looking really into the hardware and slowly documenting some really low level details and having to rely on someone else's effort may not get me deep enough. The context is along the lines of enhanched implementations of the original hardware such as better quality video and sound outputs but still using the original parts rather than full on FPGA recreations. There will be FPGAs but they're not running the show, only providing support for whatever extra features are necessary, such as a HDMI output so many people crave for a variety of reasons. But I start with my favorite hardware which is MD, and only because of the games. The things SNES does best aren't my kind of games although it does have a bunch of good games and I will definitely want to play them the best way possible and fortunately a base SNES isn't quite as terrible as a stock MD is lol (but there are numerous shortcomings that can be fixed with some effort).

[NovaSquirrel]

I do think that people who might have been interested might get scared away from trying when everyone tells them about how it's so hard so as not to be worth it, rather than offering to point them towards help and resources.

[TmEE]

There's a lot of help on this forum at least. Every question gets an answer sooner or late, there are a lot of technical people where who know what they are talking about and also a lot of enthusiasts of many are devs too, and it is one of the reasons I am around here. There's always new things to learn, be it hardware or software side.

Your efforts should help more people to ease into the whole thing (I cerall open source aspect), the progress on the things you have been doing are very nice and I always like any new thing I get to see but I am not actively following any social media etc. to know if there have been any trying to do something with these things or anything else. Perhaps social media presence is important and showing all the new SNES things (from developer perspective) will help to gather that missing interest or push some NES fan over since once you know 6502, it isn't so hard to go toward the 65816 and especially when there are bits to make use of. A lot of stuff seems to happen outside forums nowdays.

[TakuikaNinja]

The opinion I have (which I've posted in the SNESdev Discord server before) is that a typical homebrew dev would look at the SNES/SFC and assume the console is not worth targeting for the following reasons:

• Non-existent or poor tooling
• Perceived (or misinformed) hardware limitations
• Actual hardware limitations
• Overwhelmingly large feature set (i.e. why I tend to describe it as "bloated")
• Perceived audience size (correlates with profit incentive)

The debugging tools in Mesen-S/Mesen2 are great but they don't (and aren't meant to) address the lack of good tooling.

It always comes back to this: "No users, no tooling. No tooling, no users."

I don't see a lot of people engage with the console much past just trying out a few popular games, and I don't see romhackers really care about the console past just that it happens to be the platform the game they want to hack was made for.

This is also the current state of the FDS. Ask me how I know...

[NovaSquirrel]

I guess one factor is that on top of tools, documentation, guides, etc. existing, people have to find out about them somehow. When Mesen-S came out it was this revolutionary thing for me that finally made SNES dev worth it, but in spaces I was in that weren't connected to this one, people were very slow to start using it. The SNESdev WIki is great and makes a lot of things clearer than they were on https://wiki.superfamicom.org/ but I think a lot of people still end up being pointed to the latter, by people or by search engines. I feel like when people keep bringing up the SPC700 as a gotcha that probably hints at people not realizing we have good audio drivers already, and more in development.

I don't understand what kind of tooling people really expect to see. We have an amazing debugger, a really good audio driver (and a good tracker, and a tool to combine the two), tools to convert graphics, level editors, a metasprite editor, and tools for setting up tilemaps. WDC provides a C compiler that I have seen at least one person use on a SNES project, which I would hope would be higher quality than tcc816.

There's libSFX which makes ca65 more approachable, and there's tools for various aspects of SNES dev like the mode 7 previewer or VRAM planner (and these things are very easy and fast to make.)

But I don't think people really know about most of these tools and resources. Maybe awareness is something that can be improved on? Or putting them in some sort of package together? Some things are kind of clunky but you do at least have options available. You can definitely make a game with what we've got and I don't think it's a terrible experience.

[TakuikaNinja]

I agree with user awareness being something which can be improved. If an "outsider" (in terms of SNESdev) like myself was oblivious to the tooling mentioned here, then I can't imagine how unaware other devs are of them.

You have a good point about toolchain consolidation. I think any platform can become approachable if devs can be pointed to a "monolithic" toolchain which handles most things (bare minimum: code compilation/assembly, asset conversion, boilerplate) out of the box. SGDK uses GCC + custom libgcc along with a resource compiler (rescomp). The PCE/TG16 scene built HuC on top of PCEAS (CC65 support is apparently subpar for this platform) and is continuing to improve it. It seems that libSFX is the most consolidated SNES setup so far, since it uses a makefile depending on CC65 and a selection of external asset converters. There's plenty of potential here.

[Oziphantom]

the general points form the multitude of forum posts, threads etc are
SNES is harder to develop for
- more capable hardware leads to higher expectations
- people can't slum it in C easily
- higher fidelity audio that doesn't use a method people are convinced sounds better, has a "nostalgic sound" and have a cult following of people dedicated to. With dedicated "grand masters" to latch on to. It just sounds like a worse PS1.
- higher fidelity art assets take longer and more skill to develop
- huge array of large game franchises that defined their genre and are still active today and hence people expect said genre to behave in a 2025 way
- SNES teams got really good at it and have some very advanced tech that takes years to learn.
- MD games didn't really change much, the Hardware is very "what you see if what you get" on day 1.
Sega has a reality distortion field around it
- Sega fans have not had a console since 2001
- Sega fans have not had a console people cared about since '94
- This makes them hungry for anything, even collision you can fall through the ground on with ripped assets and AI slop to be heralded as "better than anything the snes can do" and massive hype.
SNES has a huge translation and hacking scene and has for the last 25+ years
- The popular games all have extensive tools and tutorials on how to mod them and there whole communities dedicated to playing and supporting said mods. Why make a game from scratch when you can start with an existing game and engine and asset pack?
- There are still untranslated games to be translated and introduced to the west, giving people a sense of finding new hidden gems in the existing game library. The SNES has over twice the number of games as the MD.
Conversely the MD has a poor library of games from older gameplay styles that have not held up and have basically died out.
- Making a new game is a better idea as you don't want to try and fix the old games, you just start from scratch to avoid the dated limits.
- Their IPs are all dead so you don't have to fight them for brand recognition, and making a new IP will be welcomed and not really compared to anything else.
- "modern retro" games don't try and mimic the MD gameplay styles making people who want that style a captive audience.
The MD has a poster child success story
- Tanglewood got a lot of publicity and kicked the whole thing off.
- SNES games get released and nobody really notices.

[creaothceann]

At least the new SNES DOOM has got a bit of coverage by DF, though that's by the original developer('s team), and it still looks kinda bad compared to other platforms...

[stan423321]

I have discovered both MD and SNES games way past their prime, and I think that claims boiling down to "classic MD games suck comparatively" or "MD hardware doesn't take time to flesh out" are overstated, though there is a grain of truth to both of them. I would counter that more MD fans care about the hardware itself a bit while more SNES fans specifically care about the classic games.

The C compilers working alright on 68k are a huge deal. Even before they got good, there has been a nice connection to home computers. 68k and the cousins were used in Amigas, Ataris, and Apple Macintoshes, for example. The x86-s that were also popular are a bit different, but closer to 68k than 65c816, especially so after segmented addressing was phased out and SIMD registers phased in (no, I'm serious about that one, they're like 68k data registers with address registers given superpowers). Arguably, mostly everything made later was more similar to 68k than 65c816, the rest of 6502 family, and as I understand it 6800 family, all of the latter relying on external zero page instead of loads of registers.

The 65c816 is mostly known for two uses, SNES and Apple IIgs. Learning material specific to 65c816 is fairly minimal. You're more likely to find guides about use of the base 6502, at which point you may go fuller retro and code for e.g. an NES or C64.

But full assembly MD premium homebrew wasn't that much of a thing, anyway - there were a few titles, but not a lot. The recent-ish waves of titles for MD are mostly coded in C (maybe ++).

I hear there are C compilers for 65c816, but I wouldn't expect too much from them. 68k architecture is very well mapped to "standard" C with arrays of structures and whatnot. 65c816 can handle these better than a base 6502, but it's not designed for it.

The APU situation is not that much of a deal. People don't write custom drivers for everything on MD and wouldn't need to do that on a SNES.

The SNES PPU is a little intimidating in comparison to MD VDP, with its galore of modes, bitplaney formats and lack of a square pixel option. But it's not as intimidating as the CPU.

It would be interesting to see if unlicensed SNES cartridge manufacturing was considered more problematic than on MD or NES due to CIC presence and SA-1 games checking if it works.

[NovaSquirrel]

To improve tool awareness, I added a bunch of missing tools to https://snes.nesdev.org/wiki/Tools - though it made me realize that just listing out tools without further direction probably isn't helpful, so I tried to add some recommendations about what people are actually using. Maybe I should try and put some work into packaging the tools I've made that are more build process related so they're easier for other people to pick up and use, like my ld65 config file generator. Or maybe it would make more sense to drop them into a theoretical all-in-one toolset.

And yeah relating to doing romhacking instead, I saw someone point out that if they make a Super Mario World hack, they have a big thriving community they can share it with that's eager to play their game and that's used to beating hard platformer levels, but if it were a homebrew game instead you lose access to that community. There's a really big boost to discoverability and people caring about your game that you get from making a romhack.

[aa-dav]

SMD has tricks to compete with Mode 7 in SNES.
"The Adventures of Batman and Robin" game uses interesting trick to imitate pseudo-3D-environment - hardware shifting of scanlines.
It's basically demo-scene like thing. Game itself is not that good.
Another interesting example - "Red Zone" game. It's demo-scene itself with the next start screen:

Lol, they stated this in the start screen!
Game features full-screen video and interesting 3D-rendering technique in the "indoor gameplay" (there are two gameplay modes - outdoor and indoor).
If it was SNES game we could say 'ah, it uses mode 7'. But this is not the case.