Interest in "modern" SNES Development Hardware?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: Interest in "modern" SNES Development Hardware?

Post by TmEE »

byuu wrote:The Genesis has a simpler VDP, but holy -fuck- is the interface to it a gigantic pain in the ass. It's like a Rube Goldberg machine to write to the VDP. All the address bits are randomly shuffled because you're going through three layers of legacy abstractions and backwards compatibility to access the thing. Lots of latched state where you have to do successive interleaved writes to even -send- second-layer commands to the chip. I still don't have a clue how the internal FIFO stuff even works for it.
Only the top two address bits are in another position, it isn't that bad. But all would be lot nicer if there wasn't SMS compatibility, flat address in one command word half and instruction bits in another would have been really convenient (and 32bit write takes care of the two parts for you, and is faster anyway, you aren't supposed to think of the command word as two halves you do separately). SNES equivalent is the horizontal coord for sprites I suppose.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Interest in "modern" SNES Development Hardware?

Post by calima »

koitsu wrote:So, all that said: the lack of C compiler really isn't what's keeping people from doing SNES homebrew. There's a term for this that I can't recall right now, but it's one of those "convenient excuses" that people use rather than actually putting in the time/effort to do what their heart is set on. The elephant in the room isn't the lack of C compiler, it's that "writing stuff on the SNES is hard". "What are all the registers? OMG", "I don't understand assembly language, it's nothing like Ruby/Python/Node/blah blah", that kind of thing. Consoles, much like arcades, are a completely different world. The potential gamedevs that might be considering the SNES probably come from backgrounds that are PC-centric, using a plethora of tools and languages and frameworks to accomplish their goal. You throw them into an environment that offers none of that and they're like a fish out of water. Why do you think there's such a humongous influx of indie games on Steam/etc. that have "16-bit-like graphics" but are PC (possibly Mac/Linux) titles?

THAT is why people aren't doing more SNES homebrew.
...
So, really, the reality is that people want "a convenient way to make stuff", and like arcades, there is nothing convenient about classic video game consoles when compared to present-day stuff for the PC (in contrast/comparison). The "lack of C compiler for SNES dev" is really not the crux of the matter.
We'll just have to disagree on that. The Genesis would have 1/100 the homebrew it has without a C compiler. Writing for the SNES would not be hard in C comparing to Gen or GBA, it would be about the same difficulty.

I had very little trouble adjusting to the NES, Genesis and GBA, coming from the PC world. Script kiddies and Unitybabbies will always exist, but some of them will graduate to real programmers eventually.
User avatar
elseyf
Posts: 72
Joined: Sat Dec 01, 2012 4:10 am

Re: Interest in "modern" SNES Development Hardware?

Post by elseyf »

I go with what koitsu said. I can not really agree on the missing C compiler being the main reason for lacking homebrew (or interest in programming for the system). Though it would certainly help getting started without knowing asm, I would say an assembler with a good set of basic macros would actually just do the job as well for creating a game. As far as I can judge, the C compiler would just allow code to be more readable for the developer, but as it was said before, you would sacrifice a good amount of performance. Using a set of macros which aim at implementing code structures to do basic things you should be able to get at least the same readablity, and you could tweak every macro to your need, implement your own and use assembler when needed.
When creating homebrew for an old system, you have to learn how the inner guts of the system are working and thus it's inevitable to learn asm if you want something more complex and efficient to run on the system. So going with what you have at hand (an assembler with macro support) is the best way to program anything.
As an examle, here is the code I use for reading the controller to navigate through a menu (using bass as the assembler):
Actual code:

Code: Select all

key_check_up:
	ctrl_check({UP_KEY},push,jsr UP_KEY_ACTION,key_check_down)
key_check_down:
	ctrl_check({DOWN_KEY},push,jsr DOWN_KEY_ACTION,key_check_accept)
key_check_accept:
	ctrl_check(accept,push,jsr ACCEPT_ACTION,key_check_cancel)
key_check_cancel:
	ctrl_check(cancel,push,jsr CANCEL_ACTION,rts_menu_navigation)
Macro:

Code: Select all

macro ctrl_check(button,btn_state,button_action_instruction,jmp_return_addr) {
variable push(1)
variable hold(0)
variable release(-1)
variable not_pressed(-2)

//Check if "jmp_return_addr" is -1 => if so, execute next instruction right after macro
	evaluate temp({jmp_return_addr})
	if ({temp} == -1) {
		define jmp_return_addr(next_button_post{#})
	}

	//check_0: exit if fail; used on _last_pad
	//check_1: exit if pass; used on _pad
	//bne: pressed; beq: not pressed
	if ({btn_state} == push) {
		define check_0(beq)//not pressed before	-> pass
		define check_1(beq)//not pressed now	-> fail
	}
	if ({btn_state} == hold) {
		define check_0(bne)//pressed before	-> pass
		define check_1(beq)//not pressed now	-> fail
	}
	if ({btn_state} == release) {
		define check_0(bne)//pressed before	-> pass
		define check_1(bne)//pressed now		-> fail
	}
	if ({btn_state} == not_pressed) {
		define check_0(beq)//not pressed before	-> pass
		define check_1(bne)//pressed now		-> fail
	}
	
	php
	rep #$30//A,X,Y 16-Bit
		lda _pad_last
		and {button}
		{check_0} goto_button_action_instruction{#}//was not pressed before
			jmp next_button{#}
		goto_button_action_instruction{#}:
			lda _pad
			and {button}
			{check_1} next_button{#}//button is pressed
				plp//restore state used outside Macro
				php//Tempsave State
					{button_action_instruction}
				plp
				jmp {jmp_return_addr}
		next_button{#}:
			plp
	next_button_post{#}:
}

macro ctrl_check(button,btn_state,button_action_instruction) {
	ctrl_check({button},{btn_state},{button_action_instruction},-1)
}
The code is readable, and I had no issues maintainig the readability throughout (almost) all of my code (it does need some cleanup :mrgreen: ).
Or I am totally missing the point of what a C compiler is supposed to make easier when developing homebrew for old systems...
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Interest in "modern" SNES Development Hardware?

Post by tepples »

One thing C is supposed to do better is make it so that when you fix a game logic problem on the Genesis version of a game, the same problem is fixed on the Super NES version as well, and vice versa. You wouldn't get nearly as many PS4/XbOne/PC cross-platform releases if porting game logic involved line-by-line translation by hand.
User avatar
elseyf
Posts: 72
Joined: Sat Dec 01, 2012 4:10 am

Re: Interest in "modern" SNES Development Hardware?

Post by elseyf »

tepples wrote:One thing C is supposed to do better is make it so that when you fix a game logic problem on the Genesis version of a game, the same problem is fixed on the Super NES version as well, and vice versa. You wouldn't get nearly as many PS4/XbOne/PC cross-platform releases if porting game logic involved line-by-line translation by hand.
I see, but this would just allow easy portability. Is missing portability the reason for lack of interest in SNES homebrew development? Is there any other reason than this that someone would want to develop anything only when the C compiler exists?
I can only see that you could manage local variables easier, but with 128kB of memory to store anything I would just go with putting all the stuff as globals (dismissing good-noodle programmer rules).
The reason given is valid (eg. pursuing commercial Release, you would want to reach as many Systems as possible with the least effort), but I want to know when using macros is just not enough anymore as opposed to using C
Kannagi
Posts: 100
Joined: Sun May 11, 2014 8:36 am
Location: France

Re: Interest in "modern" SNES Development Hardware?

Post by Kannagi »

You have an elitist vision.

Sorry but not many people in 2016 (and soon 2017) mastered the assembly, and even more make a complex game in assembly.
For that the SNES devellopement is very small.
If there existed a compiler C + a library, there will be more programmer.

This does not change anything for me, I development in assembler on all machines 8/16 bits.
For the assembler one does not use all the same (BASS / wla-dx / cc65), which does not help in my opinion the beginner, I thought to make a SNES library for wla-dx but those who use another assembler can not use it.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Interest in "modern" SNES Development Hardware?

Post by calima »

I believe there's several threads here already on the "why use C on these platforms" question. Tepples can probably link them for you, if the search gives too many.

tl;dr it is a huge waste of time to code everything in asm, even for people capable of doing so.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Interest in "modern" SNES Development Hardware?

Post by koitsu »

@Kannagi:

Respectfully, I disagree. The logic presented is the following: "people in 2016 don't know assembly, so if the PL used wasn't so arcane, e.g. C or something higher-level, then there would be more homebrew". Did I misunderstand?

What's never mentioned is this: you are choosing the system (SNES/SFC) on which to develop. It is not happenstance. It is a deliberate, conscious choice; you aren't forced to use it. That choice encompasses said limits and realities, ones which may not be known to the person who has chosen to try and write software on a system that is over 20 years old (released 1991).

Yet, when it comes to the actual development process, whinging begins: "There isn't a C compiler! There's no PNG or JPG file support! How am I supposed to do all these graphics? Oh my god, ASSEMBLY LANGUAGE? Are you kidding me?" -- speaking generally here, not of you. These may be thoughts or feelings of the same person who intentionally chose they wanted to work on 20-year-old system.

You can't have your cake and eat it too when it comes to this. And I believe it to be truth -- the proof lies in the large number of indie games on Steam etc. that try to achieve a "SNES-esque 16-bit look" (aesthetically) but aren't on the actual SNES. Did they consider the SNES to develop on? Probably not (instead people just want "the look" because it's the hip/trendy thing), but there are certainly those who did, and shied away from it. Therein lines the conundrum: you can't blame the lack of a C compiler for the 65816 or SNES when a person chooses the console to develop on consciously. Maybe this is a chicken-vs-egg problem.

And I'll again point out: even if you were to use C on the 65816 (or 6502/NES for that matter), to debug you STILL need to know assembly. There is no avoiding it; this fact cannot be ignored.

As for assembler syntax differences: yes, I get what you're saying, but as you get more and more familiar with the development process and 65816 in general (and MUST know the assembler you're using -- as I say, do not use an assembler that lacks clear/concise documentation!), most of what you're going to find online (for solving a problem/thing on the SNES) isn't assembler-relevant -- it's going to be 65816 that you can read and go "ah I see". If the code found uses #^label to fetch the bank byte of a label. while the assembler you use would need lda #.BANK(label), then I don't see this being a "large-scale" problem. The programmer should say "huh? That syntax is weird to me, better find the docs for that assembler and find out what that does, then find the equivalent here". It's only a large-scale problem if you're trying to migrate an entire existing project from, say, WLA-DX to ca65, or if someone has written "a framework" (oh god help us all) consisting of convenience routines. (I'll point out the latter sounds like a good idea on paper, but when it comes to implementation, often causes conundrums in cases relating to the PPU -- this is certainly the case on the NES anyway. We've seen forum posts from people who use existing libraries/code but get "odd behaviour" + ask about it, and the answer is "yeah, well, the function written doesn't take into consideration X/Y/Z of how the PPU works, it's kinda intended to be used for one specific thing, you can't use that for what you're doing, you gotta write the code yourself").
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Interest in "modern" SNES Development Hardware?

Post by Near »

> And I'll again point out: even if you were to use C on the 65816 (or 6502/NES for that matter), to debug you STILL need to know assembly

I mean, I get your sentiment, but I've never had to resort to looking at x86 assembler to debug a C/C++ application I was working on.

I mostly just use strategically placed print statements, which is possible with both my USART controller and the 21fx expansion port device.

> or if someone has written "a framework" (oh god help us all) consisting of convenience routines.

That's not just a nightmare for the SNES, but for all programming in general.

I became so tired of writing the same exact functions over and over, so I started putting them into a library that I eventually named nall.

A dozen years later, it's basically its own standard library, and every time I write even tiny amounts of code, it ends up dependent upon nall. It requires a small part of it, that requires another small part of it, and by the end it's pulling in 100KiB or more of header code.

This means I can't share the little 10KiB implementation of elliptic curve cryptography, or the 12KiB HTTP server, or the 8KiB PNG decoder. Because I wanted the convenience of passing around a nall::string or something inside of them, or I didn't want to fall back to memset, printf, and manually looping over each byte in a string to do some common operation std::string lacks entirely.

It's a blessing in that it's made C++ an enjoyable language to me. Most people hate C++, and rightly so. Its standard library is a flaming pile of horse shit. Insane flexibility for things you don't care about (like custom allocators), and no support for things you do (string split, word replace, binding member functions to a functor easily, etc. Let alone real shit like file format parsers, protocol support, etc.)

But it's also a curse in that there's absolutely no way I could ever go back to not using nall now. I'd sooner quit using C++ all together and move to D.

And it becomes downright evil whenver I want to improve a bad decision in nall: I have to go through and update every single project that relies on it. Which is only even possible because nobody but me uses it.

I've long thought about developing a complex macro library for bass. But I'm sure it'd have exactly the same problems.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Interest in "modern" SNES Development Hardware?

Post by psycopathicteen »

I don't understand how a programmer can't understand ASM. You should know what a byte is, and what a memory address is, what Boolean logic is, etc.

Instructions even have names that speak for themselves, like "LDA #constant" and programmers are like "What the fuck is that?". Then they see the explanation next to it, "Load Register A with constant" and they still don't get it. Then they see it saying "constant = A" and they STILL don't get it.

JMP? What they hell is that supposed to mean?
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Interest in "modern" SNES Development Hardware?

Post by Drew Sebastino »

I think the fact that even I know ASM (albeit, after loads of help) invalidates any argument that says it's too difficult to understand. :lol:
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Interest in "modern" SNES Development Hardware?

Post by Pokun »

You'd be surprised how many professional programmers I know that are absolutly afraid of anything assembly. When we are talking about assembly and I mention that I like 6502 they start to believe I'm some kind of programming genius, even though they are really much much more skilled than me (I don't do anything to break that illusion either :lol:).
koitsu wrote: Yet, when it comes to the actual development process, whinging begins: "There isn't a C compiler! There's no PNG or JPG file support! ..."
I'm imagining you guys drawing beautiful pixel art by simply punching in the bytes in a hex editor. No but seriously getting my drawings up on the screen is my biggest headache when it comes to SNES development so far, simply because I have found no reliable way to do it. All the tutorials uses ancient file formats with ancient programs that only works on ancient computers.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Interest in "modern" SNES Development Hardware?

Post by tepples »

Pokun wrote:You'd be surprised how many professional programmers I know that are absolutly afraid of anything assembly.
And you'd be surprised how many programmers on this forum are afraid of tools written in Python as if they were a snake. It's as if they have one level, and they're unwilling to accept anything lower (assembly) or higher (Python) than that.
I'm imagining you guys drawing beautiful pixel art by simply punching in the bytes in a hex editor.
AKA "tracing holes" from the Pachi Com rant.
No but seriously getting my drawings up on the screen is my biggest headache when it comes to SNES development so far, simply because I have found no reliable way to do it. All the tutorials uses ancient file formats with ancient programs that only works on ancient computers.
Here's a tutorial:
  1. Make your pixel art in GIMP.
  2. Image > Mode > Indexed
  3. Move the transparent map to the front using Colors > Colormap
  4. Export as PNG.
  5. ./pilbmp2nes.py --planes "0,1;2,3" something.png something.chr
  6. In one of your assembly language files, .incbin this file.
  7. DMA copy the file to VRAM.
  8. Draw an appropriate tilemap or fill OAM.
  9. Fill the palette.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Interest in "modern" SNES Development Hardware?

Post by Drew Sebastino »

PCX2SNES is the way I do it. It kind of sucks though. Straight uploading of tile data is the only useful thing. You can try and do the stuff where it automatically makes its own palette and tilemap for a background, but it can only handle one screen. What would have been useful is if you could give it the palettes that are being used in the image and possibly the tile data how you want it organized and the final picture, and it would create a tile map based on that. You would just add the palettes and the tile data by themselves later.

Oh yeah though, another BS thing about PCX2SNES is that it won't make a file smaller than 512 bytes; it will pad it with zeros. You can fix this with a hex editor, but you shouldn't have to.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Interest in "modern" SNES Development Hardware?

Post by thefox »

Another tool option that I made recently: https://github.com/fo-fo/snes-tile-tool ... le-tool.py (warning: Python :))
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Post Reply