Why no SNES homebrew scene?

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Stef
Posts: 251
Joined: Mon Jul 01, 2013 11:25 am

Re: Why no SNES homebrew scene?

Post by Stef » Thu Jul 05, 2018 5:37 am

Bregalad wrote: If they don't want to spend 3 weeks for "hello world", then they probably won't ever spend the time to make a full game for the system. I spent probably well over 3 weeeks when I wanted to do a "hello world" on NES back when I started this activity in 2002 at age 13 without any knownledge of the english language back then.
Because you were truly passionate and you deeply wanted to do it... but that is not the case of everyone.
If the first step seems to be too high then a lot of people will be discouraged even if they had motivations to do it. At the opposite if things seems to be really easy (you can get your first "hello world" working in a couple of hours) then you may gain attention to the system when you weren't in first place, and at the end you may eventually find interests in developing something bigger.

creaothceann
Posts: 210
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Why no SNES homebrew scene?

Post by creaothceann » Thu Jul 05, 2018 6:30 am

Stef wrote:When i said hardware abstraction, i speak about low level stuffs in general. In the end the library / API still need to fit the hardware design in some ways, but for instance it would be nice to not having to know that the OAM is split in 2 parts. At higher level i would say you won't even need to know you need to fill a OAM.
There's syntax vs. semantics. A higher-level language should be able to translate "a = b;" (or "a := b") to the necessary mnemonic, depending on the current register state and where these variables/values are located. But it shouldn't abstract the SNES-specific hardware features; that can indeed be handled by an API function call.

i.e. the language for the 65c816, a lower-level library for the SNES and a higher-level library for a game engine.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

User avatar
Punch
Posts: 345
Joined: Sat Feb 16, 2013 11:52 am

Re: Why no SNES homebrew scene?

Post by Punch » Thu Jul 05, 2018 9:59 am

Bregalad wrote:
Stef wrote: Starting immediately with very low level and assembly is just too much for a lot of people, we don't want to spent 3 weeks just to understand how to display a simple "hello world" string on the screen.
If they don't want to spend 3 weeks for "hello world", then they probably won't ever spend the time to make a full game for the system. I spent probably well over 3 weeeks when I wanted to do a "hello world" on NES back when I started this activity in 2002 at age 13 without any knownledge of the english language back then.
I'm sorry but you're just showing your prejudice against high level programming. The small-C ish compiler for the PC engine is responsible for all current (and excellent) homebrew available, which despite being completely ignored when posted some pages before it's a pretty strong real-life example of real programmers doing real games for real 16-bit systems. Same with other consoles with varying levels of processing power (even Batari Basic expanded the 2600 homebrew library quite well).
This is a block of text that can be added to posts you make. There is a 255 character limit.

DarkKobold
Posts: 8
Joined: Fri Sep 19, 2014 1:11 pm

Re: Why no SNES homebrew scene?

Post by DarkKobold » Thu Jul 05, 2018 2:41 pm

Punch wrote:
I'm sorry but you're just showing your prejudice against high level programming. The small-C ish compiler for the PC engine is responsible for all current (and excellent) homebrew available, which despite being completely ignored when posted some pages before it's a pretty strong real-life example of real programmers doing real games for real 16-bit systems. Same with other consoles with varying levels of processing power (even Batari Basic expanded the 2600 homebrew library quite well).

To me, it seems like a form of "gatekeeping." You are only allowed to program for SNES if you learn ASM, and really care to put in the hard work! Who wants more homebrew anyway?

I love the SNES, and I'd love to port my games. While C isn't the be-all end-all, and has it's own caveats, it's the easiest general way to put a game together. I feel like the general people here don't want more homebrew.

I may just port to Genesis, and it's horrid sound chip.

lidnariq
Posts: 8778
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Why no SNES homebrew scene?

Post by lidnariq » Thu Jul 05, 2018 3:08 pm

DarkKobold wrote:I feel like the general people here don't want more homebrew.
I know I've said nothing else here, but I'd really be happy to see more SNES homebrew. (And yes, I wouldn't care what language it was written in!) I just don't have the correct kinds of skills to help with it.

We do have a few grumpy people, unfortunately.

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Why no SNES homebrew scene?

Post by psycopathicteen » Thu Jul 05, 2018 7:12 pm

In C compilers, is it common to pad 8-bit variables to 16-bit words? Otherwise it would have to do all kinds of stuff with XBA and REP/SEP if you're adding or subtracting an 8-bit value from a 16-bit value.

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Why no SNES homebrew scene?

Post by rainwarrior » Thu Jul 05, 2018 8:04 pm

psycopathicteen wrote:In C compilers, is it common to pad 8-bit variables to 16-bit words? Otherwise it would have to do all kinds of stuff with XBA and REP/SEP if you're adding or subtracting an 8-bit value from a 16-bit value.
C structs are often padded, usually just to align to the size of the type of the next variable in the struct. The compiler is allowed to do this if needed for alignment or optimization. It's also common to have #pragma pack directives to disable it, where you need a specific memory layout.

Alignment is the biggest issue necessitating this for the most part. On many modern platforms unaligned access might be a large performance problem, or even cause a crashing fault. It can also help with calculating the stride offsets for an array of structures if it's a power of two.

Similarly, the result of malloc() is usually always aligned to 16-bytes or some other size so that it can be safely used with any primitive types the platform requires alignment for. There are compiler-specific extensions to add alignment requirements to types/structs as well. (C++11 finally created a standard "align" keyword.)

If you're asking if CC65 does it, no I don't think it does (there's not even a #pragma pack), but it also has no aligned types since it only generates 8-bit code, so it doesn't really have any need for it either. Manually padding a struct for power-of-two stride might help a little though.

User avatar
koitsu
Posts: 4215
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Why no SNES homebrew scene?

Post by koitsu » Thu Jul 05, 2018 9:14 pm

rainwarrior wrote:Similarly, the result of malloc() is usually always aligned to 16-bytes or some other size so that it can be safely used with any primitive types the platform requires alignment for. (There are compiler-specific extensions to add alignment requirements to types/structs as well.)
And if it's not implied or apparent to readers: this details of how this is accomplished (re: dynamic memory allocation) is complicated, compounded with mass variances between implementations (GNU libc vs. uClibc vs. musl vs. FreeBSD 9.x and earlier libc (uses its own implementation) vs. FreeBSD 10.x later libc (uses jemalloc). Functions like aligned_alloc() (and non-standard MALLOCX_ALIGN() and MALLOCX_*_ALIGN() for jemalloc) can guarantee alignment on some other boundary of your choice.

Off-topic but semi-relevant: what's often unknown to general programmers is that many malloc implementations actually allocate more than what you ask for (ex. malloc(32) will probably allocate 4096 bytes internally, but may pick something larger or smaller depending on all sorts of logic and heuristics), since the malloc implementation itself manages pages into different categories/sizings to greatly minimise memory fragmentation. I believe several implementations also care deeply about cache line size. For jemalloc, the implementation is actually described in the IMPLEMENTATION NOTES section of the man page I linked, ditto with older FreeBSD's libc.

As for compilers (not libc/malloc!) deciding what to pad: depends on compiler. This is especially a problem for structs (it's one of the most commonly-discussed topics). rainwarrior covered that most of its controlled with #pragma, varying per compiler. Usually you'll find someone using something like __attribute__((aligned(XXX),packed)). Wikipedia has an article on the general matter of data structure alignment complexities with lots of C details. Eric Raymond also has a very detailed page on the matter.

Today's C compilers are often focused on portability (which was not a focus of C when originally created in the 70s, but within 4-5 years became a serious focal point that remains today), so there's that trade off too.

It sounds to me like folks complaining about lack of C compiler essentially are saying "assembly is fine but it takes a long time to write + is more tedious to deal with than something like C". And that's very true! Reading between the lines, to me that means an intermediary PL that is 65xxx-series friendly (re: limited registers, etc.), but not as tie-consuming as assembly, would benefit the masses. What's funny about that is in the 70s and early 80s, there were some PLs invented with that sort of thing in mind (given the design of CPUs and systems during that era)... all of which by today have (generally) fallen out of favour in exchange for more commonplace PLs... C being one such PL. :-)

There really isn't something that fills the gap between C and assembly, and definitely even more so when taking the limits of the 65xxx architecture into consideration. As such, the best two things we have right now are: a) cc65, which has had some games written in it (with assembly being required for important bits), and is 6502-centric (read: does not benefit from additional 65816 instructions, addressing modes, and register sizes), and b) Toshi Morita's lcc816, which in its current form won't emit 65816 assembly that's compatible with any present-day 65816 cross assembler.

If I could magically wave my arms and make something happen, it would be to fix/improve 65816 support for cc65 and ca65 (the assembler, which does not cater well to 65816 in its present form (I've discussed this before)), and tell people "if you know C, use this, but you are expected to also know 65816". If said magic happened, I think Stef would probably put in the time/effort to do the dev env/lib/framework to make development easier for folks. But I'm not a magic wizard. IMO, the effort to make TM's lcc816 work with some present-day 65816 cross assemblers (ex. WLA-DX, etc.) would probably take less effort, *unless* the person doing the work is more familiar with compiler internals and compiler theory.

And none of this even begins to touch base on graphical or audio tools. That's a whole other world of hurt that, much like assemblers, had better support back in the snesdev heyday of the early 90s. I could talk about that for hours but it's way off topic. I do remember one thing, though: in the early 90s, there were lots of people who got interested in snesdev, did little doo-dads, then disappeared into the void once the subject of SPC700/audio/music came up. I think the SNES happens to be an incredibly complicated console, probably overly so, but in a lot of ways I still think it feels way, *way* easier to program/work on than the NES. I guess because I started with the SNES and later did NES stuff makes me a bit biased towards the 16-bit console.

Stef
Posts: 251
Joined: Mon Jul 01, 2013 11:25 am

Re: Why no SNES homebrew scene?

Post by Stef » Fri Jul 06, 2018 5:02 am

koitsu wrote: It sounds to me like folks complaining about lack of C compiler essentially are saying "assembly is fine but it takes a long time to write + is more tedious to deal with than something like C". And that's very true!
Of course, definitely this. I still think that for some people it would be even better to avoid using assembly at all if possible...
Reading between the lines, to me that means an intermediary PL that is 65xxx-series friendly (re: limited registers, etc.), but not as tie-consuming as assembly, would benefit the masses. What's funny about that is in the 70s and early 80s, there were some PLs invented with that sort of thing in mind (given the design of CPUs and systems during that era)... all of which by today have (generally) fallen out of favour in exchange for more commonplace PLs... C being one such PL. :-)

There really isn't something that fills the gap between C and assembly, and definitely even more so when taking the limits of the 65xxx architecture into consideration. As such, the best two things we have right now are: a) cc65, which has had some games written in it (with assembly being required for important bits), and is 6502-centric (read: does not benefit from additional 65816 instructions, addressing modes, and register sizes), and b) Toshi Morita's lcc816, which in its current form won't emit 65816 assembly that's compatible with any present-day 65816 cross assembler.
I don't think we really need to create a new intermediate PL, i think it would be better to improve the current available C compilers, standing with C language is definitely preferable as many people already know it and it offers easier portability (at least for some parts of the code).
If I could magically wave my arms and make something happen, it would be to fix/improve 65816 support for cc65 and ca65 (the assembler, which does not cater well to 65816 in its present form (I've discussed this before)), and tell people "if you know C, use this, but you are expected to also know 65816". If said magic happened, I think Stef would probably put in the time/effort to do the dev env/lib/framework to make development easier for folks. But I'm not a magic wizard. IMO, the effort to make TM's lcc816 work with some present-day 65816 cross assemblers (ex. WLA-DX, etc.) would probably take less effort, *unless* the person doing the work is more familiar with compiler internals and compiler theory.
To be honest i don't know well these compilers but from what you told here, it sounds that trying to improve LCC816 to make it generate compatible assembly listing would be easier. But i don't really get it, i guess LCC816 is already producing valid binary code right ? what is the problem with it ? it don't allow to mix assembly code with C code ?
And none of this even begins to touch base on graphical or audio tools. That's a whole other world of hurt that, much like assemblers, had better support back in the snesdev heyday of the early 90s. I could talk about that for hours but it's way off topic. I do remember one thing, though: in the early 90s, there were lots of people who got interested in snesdev, did little doo-dads, then disappeared into the void once the subject of SPC700/audio/music came up.
...
Yeah but that is something that will come next, first a "usable" C compiler, then a good library with good tools :p
That is just story of developing existing tools / libraries... from what i saw on this forum today things get better, we have sound driver good enough to be usable in game condition. Just need to include them in a SDK with a C API so they become easier to use :)

tepples
Posts: 21750
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Why no SNES homebrew scene?

Post by tepples » Fri Jul 06, 2018 6:14 am

Stef wrote:To be honest i don't know well these compilers but from what you told here, it sounds that trying to improve LCC816 to make it generate compatible assembly listing would be easier. But i don't really get it, i guess LCC816 is already producing valid binary code right ? what is the problem with it ? it don't allow to mix assembly code with C code ?
Syntax for directives and expressions varies from one assembler to another. It's not nearly as big as the difference between Intel syntax and GNU assembler's AT&T syntax in i386, between Sony and MOS syntax in SPC700, or between Intel and Zilog syntax in 8080/Z80, but it does mean you can't assemble the same source code file in (say) ASM6 and ca65. My solution when building Action 53 was to write preprocessors to turn a subset of NESASM or x816 syntax into something that ca65 could handle.

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Why no SNES homebrew scene?

Post by psycopathicteen » Fri Jul 06, 2018 8:13 am

I think you can make an assembler with new instructions to make it more orthogonal, such as:

ldx long

but that will have to assemble to:

sta shadow_reg
lda long
tax
lda shadow_reg

which can slow it down quite a bit, it would have to use a bunch of variations depending on which regs are available.

if A is available:
lda long
tax

if A is unavailable, but Y is:
tay
lda long
tax
tya

If directly before or after a "sta mem"

sta mem
lda long
tax
lda mem

Just too many variations.

User avatar
koitsu
Posts: 4215
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Why no SNES homebrew scene?

Post by koitsu » Fri Jul 06, 2018 2:13 pm

Stef wrote: To be honest i don't know well these compilers but from what you told here, it sounds that trying to improve LCC816 to make it generate compatible assembly listing would be easier. But i don't really get it, i guess LCC816 is already producing valid binary code right ? what is the problem with it ? it don't allow to mix assembly code with C code ?
Toshi's lcc816 outputs assembly, not binary. Its assembly is intended for use with ORCA/M, the Apple IIGS assembler -- which obviously nobody here is using. :-) I still have both my IIGS and ORCA/M (incl. manuals in PDF format); it's a top-grade assembler, so understanding what all the mnemonics and control directives do is very much possible. There are also several bits that apparently output not-very-great code, which were rectified somehow but I believe Toshi lost the macros that improved it. Please refer to the 6502.org thread I linked in a previous post for some details that he himself provides. Toshi's also still around/active -- you can find him on LinkedIn or talk to him on the 6502.org forum -- and is a super friendly guy who did actual commercial SNES games (specifically the Zombies Ate My Neighbours SNES port).

Oziphantom
Posts: 774
Joined: Tue Feb 07, 2017 2:03 am

Re: Why no SNES homebrew scene?

Post by Oziphantom » Sat Jul 07, 2018 2:51 am

what actually is the "difficult" part about the SNES?

The DMA stuff could just be wrapped in a macro, or you make macro that presets the 8 channels to do a thing, then get them to fire each DMA channel off as they want to do Thing X.

How modular is ORCA, it is probably fairly easy to get a 65816 simulator and then enough Apple //gs file system rom mocked enough to give it what it expects and then run the ORCA assembler at ghz speed on a pc without having to go through a whole //gs emulator? That and its probably not that hard to translate the assem output. But having the 65816 simulator would be nice for other debugging tasks such as linking it in with BDD6502 ;)

calima
Posts: 1016
Joined: Tue Oct 06, 2015 10:16 am

Re: Why no SNES homebrew scene?

Post by calima » Sat Jul 07, 2018 3:52 am

For me, the banking is the greatest PITA.

User avatar
dougeff
Posts: 2614
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Why no SNES homebrew scene?

Post by dougeff » Sat Jul 07, 2018 5:56 am

All this time spent discussing SNES compilers, could have been spent working on a support library. :P
nesdoug.com -- blog/tutorial on programming for the NES

Post Reply