Are High SNES Homebrew Expectations Justified?

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.

Are High SNES Homebrew Expectations Justified?

Yes if selling, no if not selling
11
44%
Yes for both selling and not selling
2
8%
Depends
6
24%
No
3
12%
I don't know
1
4%
I don't care
2
8%
 
Total votes: 25

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

Re: Are High SNES Homebrew Expectations Justified?

Post by Oziphantom » Fri Nov 13, 2020 8:45 am

CA65 is pretty good, vs 64tass its auto allocation in banks can be nice, if that is something you like. But its other features are lighter weight vs tass64 more powerful features and N pass, but you do have manual bank layout.

64Tass does have some nice 65816 features, such as stack relative "structs". If more people use and it Soci get some time back, Covid19 has sadly impacted him heavily. I will then be able to push harder for "auto collapsing REP/SEP" which would be solid bars of gold for macros.

but CA65 is perfectly serviceable and won't cause you to spend hours tracking a bug to find that for some reason the assembler got the wrong bank number like WLA-DX has done.

User avatar
Nikku4211
Posts: 383
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: Are High SNES Homebrew Expectations Justified?

Post by Nikku4211 » Fri Nov 13, 2020 9:33 am

Oziphantom wrote:
Fri Nov 13, 2020 8:45 am
CA65 is pretty good, vs 64tass its auto allocation in banks can be nice, if that is something you like. But its other features are lighter weight vs tass64 more powerful features and N pass, but you do have manual bank layout.

64Tass does have some nice 65816 features, such as stack relative "structs". If more people use and it Soci get some time back, Covid19 has sadly impacted him heavily. I will then be able to push harder for "auto collapsing REP/SEP" which would be solid bars of gold for macros.

but CA65 is perfectly serviceable and won't cause you to spend hours tracking a bug to find that for some reason the assembler got the wrong bank number like WLA-DX has done.
It helps that Mesen-S' debugger can use CA65 symbols and labels. It can't do that for WLA or 64Tass.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

Pokun
Posts: 1760
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Are High SNES Homebrew Expectations Justified?

Post by Pokun » Fri Nov 13, 2020 9:56 am

A powerful modern/classic 65xx assembler like 64tass should support HuC6280 and SPC-700. WLA-DX should support R800. The only assembler I know for R800 is tniasm, which although great is closed source and probably quite limited.

CA65 is nice, but I'm told it has problems with direct page addressing, as it's coded with the assumption that the direct/zero page is always page 0. Its HuC6280 support has similar problems since zero page is at $2000 there. I've used it for SNES in the past, but even if I use the config file examples out there (those by Blargg and Tepples) I get overdump errors in the Cart Profile of No$sns (one of the features missing in bsnes-plus and Mesen-S):

Code: Select all

Overdump (contains mirrored data)
Overdump (file is at least 50% empty)
These errors doesn't happen for me when I wrote the code in WLA-DX and 64tass. I'm not sure who's at fault here (probably me though).


Oziphantom wrote:
Fri Nov 13, 2020 7:08 am
WLA-DX is a horrible assembler for 65XX ( best in class for Z80 ). It will send you insane. The problem is the linker can't modify the code. This works fine for Z80 which it was designed for, but on 65816 it can cause you lots of random bugs.

LDA #someLabel

now if someLabel is in the DP, you want the DP version of LDA but its in another bank you want the long version. Problem is this then changes the number of bytes the instruction needs to use and the linker can't do it. So it will just put ABS. Which may or may not be what you want. Leading you to write code along the lines of

Code: Select all

LDA.B MyVar
STA.W MyOtherVar
LDA.L LongVar
STA.W Register
It also has a lot of issues getting the :Bank of labels, to the point you just start hardcoding them.
I don't see the problem. When something doesn't assemble as you want you can manually adjust it using the .b, .w and .l prefixes like you did there (and it's even possible to do it on the argument: "LDA MyVar.B"). I guess there might be some strange situation where this doesn't work though, I haven't used WLA-DX so much yet.

I did find one strange bug with parenthesis and bank labels though. The following works fine:

Code: Select all

  LDA #<(label+1)     ;load low byte of the expression: label+1
But doing the same thing with the bank operator doesn't:

Code: Select all

  LDA #:(label+1)     ;load bank byte of the expression: label+1
The last one gives "STACK_CALCULATE: Syntax error. Invalid use of modulo." error. So it interprets the # as a modulo operator instead of an immediate operator. In this case it works fine by just removing the parenthesis, but I guess it could cause trouble if you do more complicated mathematical expressions and need the parenthesis.
But throwing weird errors in strange situations or getting the wrong bank number is not a good thing.
I guess WLA-DX is fine for SPC-700 though as there aren't that much competition anyway.
Edit: WLA-DX is reported to output the wrong machine code for SPC700, so it's probably not very good for this either.


Oziphantom wrote:
Fri Nov 13, 2020 7:08 am
64tass docs are top of the line, and while the docs on cdef may seem brief it really is that simple. Basically from the manual

Code: Select all

.enc "ascii"	;define an ascii encoding
.cdef " ~", 32  ;identity for printable
which basically this says for each character in the range starting with " " ( ascii code 32) to ascii letter ~ (126), map start from 32. thus " " = 32, "!" = 33, "'"' = 34 ... "}" = 175 "~" = 176
Since the text file ( remember to assemble with the -a option) is in ascii mode that will magically convert the whole printable set. If you want to do new lines etc you would then expand it to be

Code: Select all

.enc "ascii"	;define an ascii encoding
.cdef " ~", 32  ;identity for printable
.edef "\n", 13  ;one byte control codes 
OK so "identity for printable" means "define and ASCII encoding with all printable characters so it can be used with strings".
Now it actually works (I don't remember what I did differently before though). Previously I couldn't get small letters work, only big ones. Now all letters works.

Maybe I think I begin to understand things, slowly. The "-a" option is what encoding the whole source is in and the .enc directive is for how strings in the source will be assembled. I don't get what "none" and "screen" means though and why I need to set encoding to "none" after each set of strings. Does .enc affect anything else than .text strings?
Right now all my strings are surrounded by .enc "ascii" and .enc "none" statements:

Code: Select all

  .enc "ascii"
  .text "Gamen Över"
  .enc "none"
  


Now there is just how to do a dummy long jump to bank $80 so that the SNES high-speed mode benefits kicks in.

Code: Select all

NMI:               ;in bank $00
  jml fast
fast:              ;in bank $80
  ...
How would I make this label "fast" have the bank byte $80? In WLA-DX it's as easy as sticking in ".base $80" before the label, but I see no such option in 64tass.




Edit: Answering my own question, after trying out various things this appears to work:

Code: Select all

NMI:
  jml fast+$800000 ;long jump to bank $80
fast:
  ...
This assembles to 5C xx 80 80 (long jump to $8080xx) instead of 5C xx 80 00 (long jump to $0080xx).
Too simple! No need for a .base directive.
Last edited by Pokun on Thu Nov 19, 2020 4:02 am, edited 1 time in total.

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

Re: Are High SNES Homebrew Expectations Justified?

Post by Oziphantom » Fri Nov 13, 2020 11:25 pm

Nikku4211 wrote:
Fri Nov 13, 2020 9:33 am
Oziphantom wrote:
Fri Nov 13, 2020 8:45 am
CA65 is pretty good, vs 64tass its auto allocation in banks can be nice, if that is something you like. But its other features are lighter weight vs tass64 more powerful features and N pass, but you do have manual bank layout.

64Tass does have some nice 65816 features, such as stack relative "structs". If more people use and it Soci get some time back, Covid19 has sadly impacted him heavily. I will then be able to push harder for "auto collapsing REP/SEP" which would be solid bars of gold for macros.

but CA65 is perfectly serviceable and won't cause you to spend hours tracking a bug to find that for some reason the assembler got the wrong bank number like WLA-DX has done.
It helps that Mesen-S' debugger can use CA65 symbols and labels. It can't do that for WLA or 64Tass.
That is a nice feature, I've not looked at it yet, but I would think converting 64tass labels to something it will load is not that hard. In that TASS gives you a list of label = address. I use VBS of all things to convert them to VICE/ VICEPDB / ACME format. I think there was some rudimentary WLA-DX label support but WLA-DX labels are for all intents useless as it only exports what the Linker sees you have to EXPORT label for every label you want to appear in the file.

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

Re: Are High SNES Homebrew Expectations Justified?

Post by Oziphantom » Sat Nov 14, 2020 12:47 am

Pokun wrote:
Fri Nov 13, 2020 9:56 am
A powerful modern/classic 65xx assembler like 64tass should support HuC6280 and SPC-700. WLA-DX should support R800. The only assembler I know for R800 is tniasm, which although great is closed source and probably quite limited.

CA65 is nice, but I'm told it has problems with direct page addressing, as it's coded with the assumption that the direct/zero page is always page 0. Its HuC6280 support has similar problems since zero page is at $2000 there. I've used it for SNES in the past, but even if I use the config file examples out there (those by Blargg and Tepples) I get overdump errors in the Cart Profile of No$sns (one of the features missing in bsnes-plus and Mesen-S):

Code: Select all

Overdump (contains mirrored data)
Overdump (file is at least 50% empty)
These errors doesn't happen for me when I wrote the code in WLA-DX and 64tass. I'm not sure who's at fault here (probably me though).
I did ask about HuC6280 but 64tass lives and dies on the fact 6502 opcodes are 3 letters it really is hardcoded all the way through. And Huc6280 has 4 letter ones. If there was enough interest, adding 3 letters versions and then using macros to transparently convert 4 letter names to 3 letters would be a workable solution.
SPC-700 again 4 letters and a different parser, perhaps a 65816 style mnemonics with 4->3 via macros could be achieved with demand.
Pokun wrote:
Fri Nov 13, 2020 9:56 am
Oziphantom wrote:
Fri Nov 13, 2020 7:08 am
WLA-DX is a horrible assembler for 65XX ( best in class for Z80 ). It will send you insane. The problem is the linker can't modify the code. This works fine for Z80 which it was designed for, but on 65816 it can cause you lots of random bugs.

LDA #someLabel

now if someLabel is in the DP, you want the DP version of LDA but its in another bank you want the long version. Problem is this then changes the number of bytes the instruction needs to use and the linker can't do it. So it will just put ABS. Which may or may not be what you want. Leading you to write code along the lines of

Code: Select all

LDA.B MyVar
STA.W MyOtherVar
LDA.L LongVar
STA.W Register
It also has a lot of issues getting the :Bank of labels, to the point you just start hardcoding them.
I don't see the problem. When something doesn't assemble as you want you can manually adjust it using the .b, .w and .l prefixes like you did there (and it's even possible to do it on the argument: "LDA MyVar.B"). I guess there might be some strange situation where this doesn't work though, I haven't used WLA-DX so much yet.
Well the problem is it does assemble, because the linker just throws in the bytes as the assembler told it to. So sometimes it errors, sometimes it just puts in the wrong address mode silently. Oh and the listing don't have any addresses in them because they are made by the assembler and the assembler doesn't know where things are, which makes it lots of fun to track them down.

Pokun wrote:
Fri Nov 13, 2020 9:56 am
I did find one strange bug with parenthesis and bank labels though. The following works fine:

Code: Select all

  LDA #<(label+1)     ;load low byte of the expression: label+1
But doing the same thing with the bank operator doesn't:

Code: Select all

  LDA #:(label+1)     ;load bank byte of the expression: label+1
The last one gives "STACK_CALCULATE: Syntax error. Invalid use of modulo." error. So it interprets the # as a modulo operator instead of an immediate operator. In this case it works fine by just removing the parenthesis, but I guess it could cause trouble if you do more complicated mathematical expressions and need the parenthesis.
But throwing weird errors in strange situations or getting the wrong bank number is not a good thing.
I guess WLA-DX is fine for SPC-700 though as there aren't that much competition anyway.
Yeah lots of issues for example have you checked to make sure it does it in the right order. is it
(:Label)+1 or :(Label+1) if you don't have the parentheses? Don't trust it ;) I was able to get a few issues fixed, not sure it he has pushed out a newer release with them yet, but if you can build them might be worth building latest code.
Pokun wrote:
Fri Nov 13, 2020 9:56 am
Oziphantom wrote:
Fri Nov 13, 2020 7:08 am
64tass docs are top of the line, and while the docs on cdef may seem brief it really is that simple. Basically from the manual

Code: Select all

.enc "ascii"	;define an ascii encoding
.cdef " ~", 32  ;identity for printable
which basically this says for each character in the range starting with " " ( ascii code 32) to ascii letter ~ (126), map start from 32. thus " " = 32, "!" = 33, "'"' = 34 ... "}" = 175 "~" = 176
Since the text file ( remember to assemble with the -a option) is in ascii mode that will magically convert the whole printable set. If you want to do new lines etc you would then expand it to be

Code: Select all

.enc "ascii"	;define an ascii encoding
.cdef " ~", 32  ;identity for printable
.edef "\n", 13  ;one byte control codes 
OK so "identity for printable" means "define and ASCII encoding with all printable characters so it can be used with strings".
Now it actually works (I don't remember what I did differently before though). Previously I couldn't get small letters work, only big ones. Now all letters works.

Maybe I think I begin to understand things, slowly. The "-a" option is what encoding the whole source is in and the .enc directive is for how strings in the source will be assembled. I don't get what "none" and "screen" means though and why I need to set encoding to "none" after each set of strings. Does .enc affect anything else than .text strings?
Right now all my strings are surrounded by .enc "ascii" and .enc "none" statements:

Code: Select all

  .enc "ascii"
  .text "Gamen Över"
  .enc "none"
  
64Tass is really Turbo Macro Pro, yes that TMP which is an expansion of Turbo Assembler which actually runs on a Commodore 64. So TA -> TMP -> TMPx -> 64tass. So this assembler has a long long history and thus the default mode of it is to take files in PETSCII encoding. -a is the option which allowed us to use ASCII for input files. It really should be the default and you toggle to enable PETSCII but well its been so long that it would cause things to break, but having -a be option and do nothing and then another -p or something to re enable PETSCII mode would be the way but eh its been 20 years already.
The commodore 64 has 2 encodings, PETSCII which is "none" as the default file encoding is PETSCII. And Screen which is the charset in ROMs layout order.
A in PETSCII is 65 but is 1 in Screen.
So if you want to "print" a string you want PETSCII codes. If you want to poke screen memory you need Screen codes.
poke 1024,64 will give you a horizontal line character. See Appendix A and B of the Commodore 64 Programmers Reference Guide for a complete list.

The encoding will affect ALL strings for example if you do

Code: Select all

.enc "screen"
lda #"a"
you will get LDA #1
or if you do

Code: Select all

.enc "none"
.byte 5,"this is white",19,145,28,"this is red and below"
it will encode the text as PETSCII
also for operations

Code: Select all

TextStrings .block 
    _strings = ["health","lives","score","level"] ; strings I want
    _lengths := []
    _offsets := []
    .for s in range(len(_strings))
    _lengths ..= [len(_strings[s])] ; get the length of each string
    _offsets ..= [TextData + int(... + _lengths)] ; compound if from the first string
    .next
    
    length .byte (_lengths)-1 ; length of string -1 so you can just LDX TextStrings.length,y
    lo .byte <(_offsets)         ; lo byte to start of string
    hi .byte >(_offsets)         ; hi byte to start of string
    TextData 
    .for s in TextStrings._strings
    	.text s[::-1]  ; store each string backwards so you can dey/bpl to copy it
    .next	    
.bend    
if you are in "none" you get

Code: Select all

3094	>6102	05 04 04 04			    length .byte (_lengths)-1
3095	>6106	14 19 1e 23			    lo .byte <(_offsets)
3096	>610a	61 61 61 61			    hi .byte >(_offsets)
3097	.610e					    TextData
3098						    .for s in TextStrings._strings
3099	>610e	48 54 4c 41 45 48		    	.text s[::-1]
3099	>6114	53 45 56 49 4c			    	.text s[::-1]
3099	>6119	45 52 4f 43 53			    	.text s[::-1]
3099	>611e	4c 45 56 45 4c			    	.text s[::-1]
but if you are in "screen" you get

Code: Select all

3094	>6102	05 04 04 04			    length .byte (_lengths)-1
3095	>6106	14 19 1e 23			    lo .byte <(_offsets)
3096	>610a	61 61 61 61			    hi .byte >(_offsets)
3097	.610e					    TextData
3098						    .for s in TextStrings._strings
3099	>610e	08 14 0c 01 05 08		    	.text s[::-1]
3099	>6114	13 05 16 09 0c			    	.text s[::-1]
3099	>6119	05 12 0f 03 13			    	.text s[::-1]
3099	>611e	0c 05 16 05 0c			    	.text s[::-1]
for a SNES project I would just
.enc ASCII
; cdefs here

and then never change it again. Unless you have some other text you want to encode. For example your 2bit plane 3 HUD graphics will probably have some custom chars and be off different encoding for large text font so you will want to toggle as you need. Restoring to "none" is not doing anything for you and can just be removed.
but say you have a heart character for the your HUD Zelda style you might want to do

Code: Select all

.edef "{fullHeart}", 128
.edef "{halfHeart}", 64
then latter for Hud text you can define

Code: Select all

HUDText
.text "Health{fullHeart}{fullHeart}{fullHeart}{fullHeart}{fullHeart} Lives:00" 
and then latter when you to drop to a half heart
lda #"{halfHeart}"
sta health,y
Pokun wrote:
Fri Nov 13, 2020 9:56 am
Now there is just how to do a dummy long jump to bank $80 so that the SNES high-speed mode benefits kicks in.

Code: Select all

NMI:               ;in bank $00
  jml fast
fast:              ;in bank $80
  ...
How would I make this label "fast" have the bank byte $80? In WLA-DX it's as easy as sticking in ".base $80" before the label, but I see no such option in 64tass.

Edit: Answering my own question, after trying out various things this appears to work:

Code: Select all

NMI:
  jml fast+$800000 ;long jump to bank $80
fast:
  ...
This assembles to 5C xx 80 80 (long jump to $8080xx) instead of 5C xx 80 00 (long jump to $0080xx).
Too simple! No need for a .base directive.
Multiple ways to do this.
as you discovered adding $80000 works, but not really the right way.
the proper way would be

Code: Select all

NMI
	jml _fast
.logical $808000
_fast
	...
.here
This way all code will be treated and encoded as if it is in bank 80. Maybe something else will jump to a label and this way all labels here after will be in bank $80 as seen by the assembler.
However ; for a snes project the linear map of the ROM doesn't always match the memory map. LoROM for example so I would expect you have a "map" header where you do something along the lines of

Code: Select all

.logical $808000
.dsection BANK00
.here
; maybe put vectors here?
.align $8000 ; fill up empty bank space 
.logical $818000
.dsection BANK01
.here
....
If the earlier code thinks it is in $008000 vs $808000 that is fine as the vectors will be taking a <>NMI which is only 16 bits, and if the assembler puts the INIT code where it thinks it is 808000 not 008000 it doesn't matter.

For SPC-700 one could also use BASS made by the emulator programmer formally known as byuu https://www.romhacking.net/utilities/794/ it is table based which is great and expandable, but then how does one explain the intricacies of the addressing mode to it. But if is probably serviceable for SPC-700 code.

Pokun
Posts: 1760
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Are High SNES Homebrew Expectations Justified?

Post by Pokun » Sun Nov 15, 2020 4:57 am

Oziphantom wrote:
Sat Nov 14, 2020 12:47 am
I did ask about HuC6280 but 64tass lives and dies on the fact 6502 opcodes are 3 letters it really is hardcoded all the way through. And Huc6280 has 4 letter ones. If there was enough interest, adding 3 letters versions and then using macros to transparently convert 4 letter names to 3 letters would be a workable solution.
SPC-700 again 4 letters and a different parser, perhaps a 65816 style mnemonics with 4->3 via macros could be achieved with demand.
That is really too bad. I guess NESASM/PCEAS is the best assembler for HuC6280. The one from the latest HuC fork, which has many weird bugs and quirks fixed, isn't as bad as its reputation is around here.

Well the problem is it does assemble, because the linker just throws in the bytes as the assembler told it to. So sometimes it errors, sometimes it just puts in the wrong address mode silently. Oh and the listing don't have any addresses in them because they are made by the assembler and the assembler doesn't know where things are, which makes it lots of fun to track them down.
Sounds painful. You have convinced me that WLA-DX probably isn't very good for 65xx.

Yeah lots of issues for example have you checked to make sure it does it in the right order. is it
(:Label)+1 or :(Label+1) if you don't have the parentheses? Don't trust it ;) I was able to get a few issues fixed, not sure it he has pushed out a newer release with them yet, but if you can build them might be worth building latest code.
No I haven't checked. Actually in this example, the +1 doesn't even affect the bank byte so I don't really know if it works like you expect. I can't build it so I used the v9.7b Windows binaries from here.
The WLA-DX site has official builds of the latest release, but they throw missing dll errors for me so they must have been built incorrectly. This is a very common problem, and leads people to download dlls from shady sites. I personally prefer to include static libraries instead of having to mess with the curse of the dll.

64Tass is really Turbo Macro Pro, yes that TMP which is an expansion of Turbo Assembler which actually runs on a Commodore 64. So TA -> TMP -> TMPx -> 64tass. So this assembler has a long long history and thus the default mode of it is to take files in PETSCII encoding. -a is the option which allowed us to use ASCII for input files. It really should be the default and you toggle to enable PETSCII but well its been so long that it would cause things to break, but having -a be option and do nothing and then another -p or something to re enable PETSCII mode would be the way but eh its been 20 years already.
The commodore 64 has 2 encodings, PETSCII which is "none" as the default file encoding is PETSCII. And Screen which is the charset in ROMs layout order.
A in PETSCII is 65 but is 1 in Screen.
So if you want to "print" a string you want PETSCII codes. If you want to poke screen memory you need Screen codes.
poke 1024,64 will give you a horizontal line character. See Appendix A and B of the Commodore 64 Programmers Reference Guide for a complete list.
...
for a SNES project I would just
.enc ASCII
; cdefs here

and then never change it again. Unless you have some other text you want to encode.
Huh I thought C64's character ROM would be PETSCII. OK so neither "screen" nor "none" are needed at all. I'll just switch between my own defined encodings when required. I wish the 64tass manual would explain things like this a bit better.

Multiple ways to do this.
as you discovered adding $80000 works, but not really the right way.
the proper way would be
...
I actually do have memory map header where I define RAM and ROM sections, but I will create a new thread and continue this discussion there, or this thread will derail into a 64tass help thread.
Thank you for the explanations! As it looks now, I'm probably going to continue to use 64tass for SNES development.


For SPC-700 one could also use BASS made by the emulator programmer formally known as byuu https://www.romhacking.net/utilities/794/ it is table based which is great and expandable, but then how does one explain the intricacies of the addressing mode to it. But if is probably serviceable for SPC-700 code.
Yeah I have actually used BASS in the past for SNES homebrew (65816 only though) and there are tons of examples for this assembler on Github by Peter Lemon for all kinds of systems it supports. But while it's simple and great in many ways, the non-standard syntax is really bugging me and makes porting code more painfull. Besides the official SPC700 table file for BASS is inventing a new syntax for SPC700 messing things up even further.

The fact that 64tass is traditional assembler (considering its history) with a traditional syntax, while still being a modern and maintained assembler, and having both the simplicity of ASM6 and the powerful macros and functions of CA65, is what attracted me to it in the first place. That and the fact that it seems to be regularly used for the SuperCPU, making it suitable for SNES development. Plus it's multipass like ASM6, which means it should be, in some ways, more versatile than a 2-pass assembler such as CA65.

There is also TASM (as in Telemark Assembler not Borland's Turbo Assembler also called TASM) also table-driven and with the SPC-700 table "tasm07.tab" by Gau (and revised by ekid) it looks like it should be able to assemble SPC700 code, with official syntax and well enough to make a sound engine.
Edit: Ekid's table seems to contain errors. Membler has another SPC700 table here.


Edit: Let's continue the 64tass usage discussion here.

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

Re: Are High SNES Homebrew Expectations Justified?

Post by DarkKobold » Mon Nov 23, 2020 5:42 pm

I have to say, I've now made multiple homebrews for the TG-16, one for the Sega Genesis, and have an in-progress one for the GameBoy. Each one of those communities are incredibly supportive, helpful, and greatly inspirational towards getting new people coding for their systems. There are multiple tutorials to get you started on each system, and lots of hand holding to get you on your feet.

On the other hand, I see an insane amount of dismissive gatekeeping from the SNES community. The amount of condescension that occurs in this community is staggering. I'm sure there are plenty of good, helpful people in this community, but they get overshadowed by crap like this:
And actually... why does it even matter if there is a lot of homebrew for the SNES? Why does the quantity matter? Everyone should think about that one for a while; don't reply, just think deeply about it.
This is the worst example, but I've encountered it frequently.

User avatar
Nikku4211
Posts: 383
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: Are High SNES Homebrew Expectations Justified?

Post by Nikku4211 » Mon Nov 23, 2020 7:00 pm

DarkKobold wrote:
Mon Nov 23, 2020 5:42 pm
I have to say, I've now made multiple homebrews for the TG-16, one for the Sega Genesis, and have an in-progress one for the GameBoy. Each one of those communities are incredibly supportive, helpful, and greatly inspirational towards getting new people coding for their systems. There are multiple tutorials to get you started on each system, and lots of hand holding to get you on your feet.

On the other hand, I see an insane amount of dismissive gatekeeping from the SNES community. The amount of condescension that occurs in this community is staggering. I'm sure there are plenty of good, helpful people in this community, but they get overshadowed by crap like this:
And actually... why does it even matter if there is a lot of homebrew for the SNES? Why does the quantity matter? Everyone should think about that one for a while; don't reply, just think deeply about it.
This is the worst example, but I've encountered it frequently.
Yeah, I don't understand why it's the SNES homebrew community that's the pretentious r/gatekeepers.

Is it because of the console's high expectations? The Mega Drive would have high expectations as well, but I guess its graphics aren't that colourful when you have only 512 colours to choose from instead of 32,768, and its sound is more geared towards something like EDM or some other genre that relies on distinctly synthesised instruments, whereas the SNES' sampling is expected to lead to more realistic music(only by comparison). Also, the Mega Drive never had (hardware) mode 7, so nobody expects most games on it to have rotation and scaling of any kind.

Maybe it's because its CPU is apparently more 'C-friendly'(I don't know the details), making it easier to start making games for it. The SNES technically has PVSNESLib for C, though I've never used it, so I don't know about the nuances other than the fact that it uses TCC-816.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

User avatar
Señor Ventura
Posts: 177
Joined: Sat Aug 20, 2016 3:58 am

Re: Are High SNES Homebrew Expectations Justified?

Post by Señor Ventura » Tue Nov 24, 2020 8:53 am

DarkKobold wrote:
Mon Nov 23, 2020 5:42 pm
On the other hand, I see an insane amount of dismissive gatekeeping from the SNES community. The amount of condescension that occurs in this community is staggering. I'm sure there are plenty of good, helpful people in this community, but they get overshadowed by crap like this:
I don't know what is wrong with that.

But maybe you have to keep in mind that snes is a great machine, with excellent ratings and, in spite of that, its scene does not move as much as any other scene of the other machines.

It's frustrating, and people expres it this way ... not condescendence, but whish.

User avatar
Nikku4211
Posts: 383
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: Are High SNES Homebrew Expectations Justified?

Post by Nikku4211 » Tue Nov 24, 2020 9:16 am

Señor Ventura wrote:
Tue Nov 24, 2020 8:53 am
I don't know what is wrong with that.

But maybe you have to keep in mind that snes is a great machine, with excellent ratings and, in spite of that, its scene does not move as much as any other scene of the other machines.

It's frustrating, and people expres it this way ... not condescendence, but whish.
There's a difference between being frustrated with the state of the scene, and just gatekeeping.

Gatekeeping is when you are elitist enough to actually attempt to control who has or does not have access to a community. You can see a lot of examples of this in the r/gatekeeping subreddit.

For instance, I wish the SNES homebrew scene would be more active myself, but that's exactly why I'll try not to be hostile towards newbies, because we need as many new people in the community as we can get. The people who are condescending towards newbies already give the SNES homebrew community a bad name, but that's one factor that results in the scene being small and inactive in the first place.

I don't want to demotivate newbies who want to try the SNES. I'm frankly curious what newbies can do and discover with the SNES.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

Pokun
Posts: 1760
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Are High SNES Homebrew Expectations Justified?

Post by Pokun » Tue Nov 24, 2020 9:53 am

Nikku4211 wrote:
Mon Nov 23, 2020 7:00 pm
Maybe it's because its CPU is apparently more 'C-friendly'(I don't know the details), making it easier to start making games for it. The SNES technically has PVSNESLib for C, though I've never used it, so I don't know about the nuances other than the fact that it uses TCC-816.
Yeah maybe, there seems to be a lot more C users in the MD homebrew community, while in the NES and SNES homebrew communities there is more assembly elitism. On the other hand the Game Boy and PC Engine homebrew communities are quite heavy on C as well, and those systems are not any more C-friendly than NES or SNES are.

User avatar
Nikku4211
Posts: 383
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: Are High SNES Homebrew Expectations Justified?

Post by Nikku4211 » Tue Nov 24, 2020 10:00 am

Pokun wrote:
Tue Nov 24, 2020 9:53 am
Yeah maybe, there seems to be a lot more C users in the MD homebrew community, while in the NES and SNES homebrew communities there is more assembly elitism. On the other hand the Game Boy and PC Engine homebrew communities are quite heavy on C as well, and those systems are not any more C-friendly than NES or SNES are.
Yeah, that's pretty strange. But then again, not that much people would have nostalgia for the TurboGrafx-16, so maybe they wouldn't have that much of a head start on assembly? However, the Game Boy would've been nostalgic to way more people than the TurboGrafx-16.

One thing the NES, SNES, and TG-16 all share is having a 6502-based CPU, so maybe the Game Boy is big on C more because people who have done 6502 assembly can't apply their pre-existing 6502 ASM knowledge to the Game Boy at all.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

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

Re: Are High SNES Homebrew Expectations Justified?

Post by psycopathicteen » Tue Nov 24, 2020 10:54 am

I never thought nesdev has much gatekeeping. Smwcentral and nearly every website hosted by "acmlm" on the other hand :roll: .

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

Re: Are High SNES Homebrew Expectations Justified?

Post by Oziphantom » Tue Nov 24, 2020 11:54 pm

Nikku4211 wrote:
Tue Nov 24, 2020 10:00 am
Pokun wrote:
Tue Nov 24, 2020 9:53 am
Yeah maybe, there seems to be a lot more C users in the MD homebrew community, while in the NES and SNES homebrew communities there is more assembly elitism. On the other hand the Game Boy and PC Engine homebrew communities are quite heavy on C as well, and those systems are not any more C-friendly than NES or SNES are.
Yeah, that's pretty strange. But then again, not that much people would have nostalgia for the TurboGrafx-16, so maybe they wouldn't have that much of a head start on assembly? However, the Game Boy would've been nostalgic to way more people than the TurboGrafx-16.

One thing the NES, SNES, and TG-16 all share is having a 6502-based CPU, so maybe the Game Boy is big on C more because people who have done 6502 assembly can't apply their pre-existing 6502 ASM knowledge to the Game Boy at all.
Having 7.6mhz helps get over C being crap. Having a MMU also helps. T register also gives you an easy out pass for how C is designed.
Having 2K of RAM really hinders.
That being said I'm fairly sure LazyCow's Wolfling game is mostly C. Just people who make NES and SNES games seem to be here to "push the limits". And with C you hit them fast.
TG-16 WOW A GAME SWEET, NES eh I have a huge pile of good stuff, I'm fine thanks.
Gameboy seems to have this odd middle ground where it has a pile of good games, but also generally seen as simple enough that making a new C game doesn't seem "bad" but a lot of people have a deep love for it, possibly retrospectively thanks to the "music scene" around it. However also nobody ( well okay maybe Tepples ) actually likes to write Z80 code. It's horrible and as bad as C is on it, its preferred ;)

That being said we now have NESMaker and I don't think the number of devs here has increased in any significant number.

User avatar
MottZilla
Posts: 2835
Joined: Wed Dec 06, 2006 8:18 pm

Re: Are High SNES Homebrew Expectations Justified?

Post by MottZilla » Wed Nov 25, 2020 1:41 am

I think a lot of the time people underestimate the other part of SNES (or insert any other system) homebrew. The part where you "make a game".

Designing and developing and actually completing any game is a big task. Developing a game or any program on a platform you aren't used to is going to introduce challenges for sure. In the end it's less about the platform and more about what you're going to make run on it. Planning, organization, time management, all sorts of other things are probably more important.

I've thought about making a SNES homebrew game before. The big platform related thing that bothered me was dealing with the SPC700. These days there are some ready made solutions to get sound and music going. The rest of it isn't too difficult or complicated unless you choose to do something that is. But it's still a lot of work.

In my opinion rather than developing a game for the SNES (on NES or whatever) if you have never done so before, you should first develop atleast a reasonable portion of the game on another platform you know that allows for faster/easier development. Throwing together the same basic sort of game you might see on the NES or SNES is going to be much faster if you can program in C or another language. And using a platform like the PC will make it much easier to work with graphical assets, sound effects, music.

Once you have an actual game I think it's easier to then deal with the part of "making it run on X platform". Of course you'll ideally want to keep in mind the general capabilities of your intended platform so you don't end up with issues related to something being impossible.

There is nothing wrong with developing a game using tools that make it easier. Having a game that works and you can play but it runs in Unity or GameMaker or whatever is better than having virtually no game but it shows some stuff on an older platform that had some really cool other games. So first worry about having a game designed and developed somewhat before worrying about making it run on the SNES. I think it's backwards to learn how to do something on the SNES and then make a game after that. Not that you can't do it that way, I just think the other way is more likely to succeed.

Post Reply