nesdev.org

And if you're going to be manufacturing a game, why not just use a commodity ARM MCU instead of an uncommon GSU or SA-1?

Three reasons:

1) Authenticity. This may not be important to everybody, but some people (myself included) might value the fact that a game could, in principle, have been made during the commercial lifetime of the SNES. This, I think, is closely related to the reasons people code for the SNES in the first place - coding for SNES+GSU or SAS is philosophically a lot more like coding for SNES than coding for SNES+Cortex-M is. (Yes, this does provide an incentive to eliminate any practical differences between an FPGA GSU or SA-1 and a real one as far as possible.)

2) Hardware/interface design. I'm not an expert in this area, but... There were only a couple of full-fledged programmable coprocessors released for the SNES, so the work done cloning them could be reused by anybody who wanted to. In fact, it's not unlikely that an FPGA clone of the GSU, and maybe even the SA-1, could appear by the agency of an enthusiast independent of developer demand. By contrast, a "modern" embedded systems processor is a moving target, nobody is going to integrate one with the SNES just for the heck of it, and you'd be lucky to ever have two games using the same configuration.

3) Emulation support. The only ARM CPU with out-of-the-box support in emulators is the ST-0(0?)18, which is useless for anything other than quick-move shogi and not very good at that. If your game is a massive hit, emulator authors might be moved to support it, but it's an uphill battle, especially if your coprocessor is actually a somewhat modern chip...

The ST-018 could be a powerhouse for programming most of the SNES game logic in C. It just needs one very simple, very minor addition of a DMA channel to get data out of the chip quickly. You could probably write a decent video codec to pair with the MSU-1.

I've thought about adding in such a thing, but so far haven't acted on it.

I was under the impression that the chip was tied to an on-die program ROM. Being ARM, I wouldn't think it could interface with an 8-bit SNES ROM directly; other than the DMA interface you mention, would it simply be a matter of changing out the program ROM (the replacement presumably being larger)?

That would be pretty cool (even though I don't personally care about C).

In any case, the ST-018 was a bit of a red herring anyway; the question was about a widely-available MCU, which I'm not sure a 21 MHz ARMv3 qualifies as. If the chip you're using in the cartridges is backward-compatible with the one the emulators think you're using, well and good, but now you've got a potentially massive performance difference between emulation and real hardware, with emulation giving you what would have been possible back in the day and real hardware giving you the "cheat" of a high-performance 21st-century substitute.

IMO a tweaked ST-018 is closer to the category of the GSU/SA-1 than that of the Cortex-M in the context of my previous post. I only mentioned it because it was an ARM chip, which was careless of me...

tepples wrote: If "Python dependencies" are bad, are GCC/clang dependencies better?

I think no matter which route you go, a portion of users won't want to switch from their preferred language. Personally, I'd go with Python...as long as it doesn't require some obscure library...(complaint/rant removed).

What prior knowledge should a Super NES-specific tutorial assume?

Honestly, a good tutorial should either...
A. Explain everything. Everything!

Or..
B. Automate all the boring stuff with a vast library of pre-written functions for loading the PPU, updating sprites, etc...much how Shiru did for the NES.

I don't expect any one person to do all that (tepples).

dougeff wrote:

tepples wrote:If "Python dependencies" are bad, are GCC/clang dependencies better?

I think no matter which route you go, a portion of users won't want to switch from their preferred language. Personally, I'd go with Python...as long as it doesn't require some obscure library...(complaint/rant removed).

The only non-stock library I rely on is Pillow (Python Imaging Library), and that's common enough to be in PyPI (pip install Pillow), Debian and Ubuntu (sudo apt-get install python3-pil), and Fedora (sudo yum install python3-pillow). Do these instructions still work?

tepples wrote:

Pokun wrote:A graphic tool for converting bmp/png files (Tepples made one but it has Python dependencies) to the SNES formats

If "Python dependencies" are bad, are GCC/clang dependencies better?

No you would ideally have to minimize dependecies for a tutorial/devkit like this IMHO. I'd include source and binaries for the most common OS:es. They will become obsolete one day but that's unavoidable. Otherwise we would still be using pcx2snes or whatnot and never have this problem.

Kismet wrote:

tepples wrote:

Teach SPC700 programming and how to upload an SPC700 program. There seems to be at least two alternatives for assemblers: Tasm and bass, both using an SPC700 table-file. But bass changes the mnemonics from the official ones, I'm not sure that's a good idea for a tutorial.

The third is to use ca65 with a macro set that implements SPC700, which blargg made. There are versions that use Sony's official "please don't sue us" mnemonics as well as the standard 65C02 mnemonics.

What prior knowledge should a Super NES-specific tutorial assume? Programming? Assembly on another architecture? 6502 family? 65816 in particular? Graphics programming? Programming for another tiled VDC?

I think with the SNES Assembly is "too hard" without a manual that actually includes both the 65816 and the S-CPU specific instructions, and how the PPU actually works.

The one thing I liked about the "family basic" manual for the famicom was that it did a fairly good job of demonstrating how sprites and display priorities worked on the hardware, from within the confines of the hardware, even if the language was clunky. Some simple program with commented source code, and the compiler that creates it, is needs to exist to demonstrate all the features of the SNES.

Oh yeah I forgot about SPC700 macro set for ca65. I didn't realize he included Sony's mnemonics as well (could they really sue anyone for using a bunch of stupid abbrivations though?).

I imagine an ideal tutorial could assume zero programming knowledge but still be used by anyone who is interested in learning SNES programming no matter how much prior programming experience they have. It would have to be structured in a way that it's possible to skip any section that the reader is already familar about (the sections have to have headlines that makes it clear what they teach), and following sections can not assume the reader has read all prior sections. Of course this kind of tutorial would require lots of work and skill of the writer, so it's up to the writer how much prior knowledge to assume depending on how much time and energy he/she is ready to spend on a project like this.

Since 65816 requires quite a bit more work than 6502 it might be easier to lean more against a tutorial for NES programmers that wants to learn SNES. Either way there is no avoiding technical manuals for 65816 or SNES hardware, so eventually the tutorial will have to refer more to these documents, and assume more and more that the reader is capable of learning from these as the chapters advances. There's always a period, especially in the beginning of something totally new, where the reader just have to memorize and accept a lot of new things that's too early to get into explaining yet. I think the problem is about balancing how much you expect from most readers to be able to handle, and how much you need to push them in the right direction.

As Kismet said, full working example programs with commented source code and the ways to assemble it is necessary. As they say "the hardest part is to get started" so even a minimal working SNES program (like changing the screen to a single colour) is a huge step for a newbie that have no clue of how SNES games work. The example programs needs to be logically structured and easy to follow however. Can't throw in a bunch of pecuilar macros or smart solutions with little explanations or stuff like that. There's nothing wrong with teaching good programming habits and useful tricks though, as long as they are properly explained.

I'm still a newbie programmer myself, and I don't know what kind of programming should be taught in a tutorial like this, but I can tell when a tutorial isn't explaining what it's doing properly.
Sorry for ranting.

tepples wrote:

WheelInventor wrote:Python tools can be converted to nondependent executables with py2exe:
http://www.py2exe.org/index.cgi/Tutorial

How well do py2exe and executables produced with py2exe work under GNU/Linux? The laptop into which I am typing this post does not and has never run a Microsoft Windows operating system, though it does have Wine installed. Besides, if I have four or five Python tools, will each of them bloat by 5 MB when the whole interpreter and its support libraries are added?

These kinds of tools is how pygame and such work, since you can't get end users to install python.

tepples wrote: Or what did you mean by "self-contained"?

There are two pieces. The hardware side, and the software side. If you want a devkit to be of any use, anyone needs to be able to use it without procuring extra bits of hardware (see the Emulator SE, or the Net Yaroze for PS1 development) that are different from the retail hardware. Fundamentally developing for the SNES without a SNES (like a FPGA-SNES or at least a hardware clone) is the blind leading the blind. On the software side, there are emulators, however there are no software emulators that will 100% emulate everything, accurately, on every system, and every operating system. This is why I don't like ARM platforms being promoted for emulators because it's hard enough to get people with a powerful PC to play a game like it was intended, good luck even getting half the accuracy out of a weak ARM part.

With the advant of always-on internet updates that PS3/PS4/Wii/3DS/Xbox360/XB1 devices have been caught in a deathspiral of "blink and you miss it" code rot. If you throw your device in the closet for 20 years, will those update servers be up? Doubtful. So there is something about cartridge-based systems that don't have internet access, that makes them more of viable hobby/homebrew platform.

tepples wrote: They still depend on the operating system. Or is each developer of tools expected to buy a Mac on which to run Xcode with which to make and test Mac binaries, as well as a Windows license for that Mac on which to run MinGW or Visual Studio with which to make and test Windows binaries?
...
Then a lot of software products are "fundamentally broken" because the developer isn't willing to buy a sufficiently recent Mac every four years on which to continue to build updated binaries.

You can cross-compile to operating systems supported by the compiler. Both GCC and Clang can do this. Clang can pretty much compile anything to any platform for which it has a target. The problem today is typically C++ compilers generate rotten code because the developer decided to not use C bindings.

Here's a thought experiment. Make Clang compile to SNES 65c816 . There's a LLVM backend for Z80, so why not.

Pokun wrote: I'm still a newbie programmer myself, and I don't know what kind of programming should be taught in a tutorial like this, but I can tell when a tutorial isn't explaining what it's doing properly.

BASIC today is probably not very fun, but if you want to get people to learn assembler, they need to know how the hardware works. For example, the game "Human Resource Machine" http://tomorrowcorporation.com/humanresourcemachine is teaching you assembler (more or less) in a very blunt way, through trial-and-error. As one more example https://usborne.com/browse-books/featur ... ing-books/ , scroll down the the 1980's books. The "Machine code for beginners" one actually explains how Assembly works in the 6502 and Z80. At least two of these books the public library had and I took them out every chance I had back then.

But getting people (with short attention spans) to read an entire book without being able to do something -now- is the problem with teaching people code. It's far more efficient to show a program and explain it, line by line, let the user compile it themselves (eg http://nehe.gamedev.net/ for OpenGL) and then each successive program builds on the previous one. What is the initial state when the machine is powered on, do you need to initialize variables, or will some garbage collection run? A production SNES doesn't have a keyboard, so the vast majority of programming tutorials that involve input aren't usable, so you need one that specifically addresses how to initialize the controller for input. How do you program the SPC, can do you need to know MIDI, should a MIDI tutorial exist or can something be applied to it? etc. Is a tracker format more appropriate for music? How do you store a bitmap, how do you get something into video memory, how do you display strings, there's no built in font, so what kind of font fits in the memory. One thing that 8-bit microcomputer users had was that there was always a system font in ROM. The NES and SNES do not have this. You can't just dump an error text message to the screen, you need to halt and send a memory dump to a computer to examine it, or try to replicate it on a software emulator on the PC.

What I think prevents people from getting into the SNES is largely because nothing really transfer to it.

Kismet wrote:Here's a thought experiment. Make Clang compile to SNES 65c816 . There's a LLVM backend for Z80, so why not.

Clang compiles C or C++ to an "Intermediate Representation" that assumes a (relative) abundance of 32-bit-or-more registers. LLVM then has to figure out how to convert that into useful native code on machines that aren't shaped like that.

This is why the PIC16 backend isn't part of the LLVM distribution anymore: it's a Harvard architecture where code and data pointers are different sizes, there's only one real register and it's 8 bits wide; that's about as differently shaped from ARM/386 as practical. I'd expect any 8-bitter to have the same problems, although most won't be as severe as PIC. The 65816 might be in a better place, since it's 16-bit and Von Neumann.

Just because LLVM can emit functioning code for an architecture doesn't mean it's necessarily good code.

Kismet wrote:

tepples wrote:Or is each developer of tools expected to buy a Mac on which to run Xcode with which to make and test Mac binaries, as well as a Windows license for that Mac on which to run MinGW or Visual Studio with which to make and test Windows binaries?

You can cross-compile to operating systems supported by the compiler. Both GCC and Clang can do this.

And test the produced executables on what?

Kismet wrote:A production SNES doesn't have a keyboard, so the vast majority of programming tutorials that involve input aren't usable, so you need one that specifically addresses how to initialize the controller for input.
[...]
How do you store a bitmap, how do you get something into video memory, how do you display strings, there's no built in font, so what kind of font fits in the memory.

I started to address both of those in spadtest: it has the beginning of text display routines as well as controller reading routines.

Kismet wrote:

Pokun wrote: I'm still a newbie programmer myself, and I don't know what kind of programming should be taught in a tutorial like this, but I can tell when a tutorial isn't explaining what it's doing properly.

BASIC today is probably not very fun, but if you want to get people to learn assembler, they need to know how the hardware works. For example, the game "Human Resource Machine" http://tomorrowcorporation.com/humanresourcemachine is teaching you assembler (more or less) in a very blunt way, through trial-and-error. As one more example https://usborne.com/browse-books/featur ... ing-books/ , scroll down the the 1980's books. The "Machine code for beginners" one actually explains how Assembly works in the 6502 and Z80. At least two of these books the public library had and I took them out every chance I had back then.

But getting people (with short attention spans) to read an entire book without being able to do something -now- is the problem with teaching people code. It's far more efficient to show a program and explain it, line by line, let the user compile it themselves (eg http://nehe.gamedev.net/ for OpenGL) and then each successive program builds on the previous one. What is the initial state when the machine is powered on, do you need to initialize variables, or will some garbage collection run? A production SNES doesn't have a keyboard, so the vast majority of programming tutorials that involve input aren't usable, so you need one that specifically addresses how to initialize the controller for input. How do you program the SPC, can do you need to know MIDI, should a MIDI tutorial exist or can something be applied to it? etc. Is a tracker format more appropriate for music? How do you store a bitmap, how do you get something into video memory, how do you display strings, there's no built in font, so what kind of font fits in the memory. One thing that 8-bit microcomputer users had was that there was always a system font in ROM. The NES and SNES do not have this. You can't just dump an error text message to the screen, you need to halt and send a memory dump to a computer to examine it, or try to replicate it on a software emulator on the PC.

What I think prevents people from getting into the SNES is largely because nothing really transfer to it.

Thank you, I mean I'm still too much of a newbie programmer to give adequate advice on what programming techniques to teach in a tutorial like this. I already "know" Family BASIC, 6502, 65C02, 65816 and Z80 and can make simple games for at least the NES (using 6502). I don't know so much "gaming programming" which I think is something a tutorial like this might want to teach. Nerdy Nights teaches the basics of state machines which helps a lot when learning how to structure a game.

Yes you'd need practical examples in a tutorial like this, especially since most people do this in their free time, there's only so much you can teach through pure theory. For NES and SNES the font is part of the ROM in the cartridge, I'd just provide a free 2bbp ASCII/JIS font (ripped from Super Mario Bros or something) with the tutorial and teach how to upload it to VRAM and print strings and RAM values on screen.

Something the Nerdy Nights doesn't teach is how to make simple menus. For me it was a lot harder to figure out than I imagined, and it's a common element in many programs/games.

tepples wrote:

Kismet wrote:

tepples wrote:Or is each developer of tools expected to buy a Mac on which to run Xcode with which to make and test Mac binaries, as well as a Windows license for that Mac on which to run MinGW or Visual Studio with which to make and test Windows binaries?

You can cross-compile to operating systems supported by the compiler. Both GCC and Clang can do this.

And test the produced executables on what?

I'd just send it to a friend with a Macintosh. For Windows and Linux you need to have to have at least a Linux system and try the Windows build in Wine.

> I was under the impression that the chip was tied to an on-die program ROM.

Not a problem for an emulator nor a new flash cart that supported it.

> IMO a tweaked ST-018 is closer to the category of the GSU/SA-1 than that of the Cortex-M in the context of my previous post.

Perhaps, but the ST018 gets you a usable C compiler unlike the others.

> This is why I don't like ARM platforms being promoted for emulators because it's hard enough to get people with a powerful PC to play a game like it was intended, good luck even getting half the accuracy out of a weak ARM part.

I keep waiting for ARM to catch up on performance. We keep inching closer, but it's taking so maddeningly long.

It's not even about the top-end ARM core being fast enough (which it still isn't quite there yet), we need all the little dev boards (RPi, etc) to be fast enough. Those things aren't even close -- they can barely run minimal Linux desktops.

I suspect we'll be waiting a whole lot longer.

The shift from performance to energy efficiency has certainly hampered efforts to improve emulation accuracy.

> So there is something about cartridge-based systems that don't have internet access, that makes them more of viable hobby/homebrew platform.

To me, even if an emulator isn't 100% perfect, you can get 99.99% perfect. At some point you have to stop worrying about absolute perfection.

If you write your game for the NES or SNES, and don't go out of your way to abuse the hardware (looking at you, 94143 :P), it will always be playable forever.

If you wrote your game using MFC, Glide, EAX audio, DB15 gamepad, well ... yeah. You can emulate it, probably. But not anywhere near as well or as easily as the NES. And don't think Metro, Vulkan, XAudio2, XInput is going to be much different than the aforementioned example in 20 years.

Sure, if you need all that power, then you have no choice. But I'm guessing for the kind of games people here like, they don't.

> Make Clang compile to SNES 65c816

It's not that we can't make a C compiler for the SNES. It is Turing complete, after all.

The problem is that the 65xx is a miserable CPU to target via C. It only has one single accumulator.

80% of your performance will be lost to the compiler trying to cope with the CPU's design.

And on a 2MHz system that gets about 300,000 instructions per second, that's not really tenable. Unless you're okay with making an Atari 2600-level game on the NES/SNES.

Z80 has AF, BC, DE, HL, AF', BC', DE', HL' that can be used as accumulators. 65xx has A.

I believe there exists a language between 65xx and C that will be much easier to code for and only sacrifice a tiny bit of performance. But I've yet to come up with it.

Pokun wrote:

tepples wrote:

Kismet wrote:You can cross-compile to operating systems supported by the compiler. Both GCC and Clang can do this.

And test the produced executables on what?

I'd just send it to a friend with a Macintosh.

Please help me overcome my disability: What's a "friend", and how does one find one? If you mean through the social network of NESdev itself, then the only Mac owners I know through #nesdev on EFnet (wyatt8740 and tpw_rules) use PowerPC Macs, which are too old to run binaries made for any Mac from the past ten years. Or can people assume that little supply of free labor to test Mac builds implies little demand for production use of Mac builds?

Pokun wrote:For Windows and Linux you need to have to have at least a Linux system and try the Windows build in Wine.

Making a "Windows" program that inadvertently depends on bugs in Wine is like making a "Super NES" program that inadvertently depends on bugs in Snes9x.

byuu wrote:I keep waiting for ARM to catch up on performance. We keep inching closer, but it's taking so maddeningly long.

I likewise keep waiting for mass market ARM devices capable of running emulators to catch up on input devices. Emulation of a twitchy gridiron football sim designed for buttons using only a touch screen for input will always be Madden-ing.

byuu wrote:And on a 2MHz system that gets about 300,000 instructions per second, that's not really tenable. Unless you're okay with making an Atari 2600-level game on the NES/SNES.

I don't think "Atari 2600-level" is really descriptive of all the NES/SNES homebrew that has already been made in C.

I believe there exists a language between 65xx and C that will be much easier to code for and only sacrifice a tiny bit of performance. But I've yet to come up with it.

I believe so too.

tepples wrote:If you mean through the social network of NESdev itself, then the only Mac owners I know through #nesdev on EFnet (wyatt8740 and tpw_rules) use PowerPC Macs, which are too old to run binaries made for any Mac from the past ten years. Or can people assume that little supply of free labor to test Mac builds implies little demand for production use of Mac builds?

Would mac mini a1103 from 2005/06 do? Just got one in, but need to go buy a hdmi adapter to set it up.
EDIT: Nevermind; G4. :/