Interest in "modern" SNES Development Hardware?

As kind of a response to this thread, saying:

Would some SNES Development Hardware revive it?
I am in the process of designing Hardware, which could evenually end up to be a "modern" version of the Super NES Emulator SE (even though I can only imagine how one would have developed anything with the SE).
It was supposed to be just a BIOS for the SNES, which would allow loading games from an SD Card, dump Cartridges and SaveRAM. But I thought I can carry this much further.
Anyone have thoughts on this? I would like to hear opinions on whether this is going to be useful or not.

That will be awesome, especially if it comes with a sprite/tile editor.

I would implement any feature thats within reach. For example i wanted to support partial SA-1 and SuperFX developement Features (if that is possible) by loading a program into the WorkRAM of a Cartridge, that should allow the processor to execute anything loaded in there. You could then write your program like that and test certain features (until there are SA-1 and SuperFX Implementations for an FPGA).
Another Feature is going to be Internet connectivity, but thats yet a far way until (though I have a ROM Downloader implemented ).
Currently I am putting the pieces together

This seems to be a statement implying unfamiliarity with actual ICEs. So what're your questions?

defparam is actually working on something similar, which he calls the 21FX-TL

More than likely. I'm sure there is interest, it's just currently a rock-and-a-hard-place situation with emulating 16-bit systems (includes things like the Amiga, and 8088/80286 machines too) where acquiring working real hardware is too hard (or too expensive), but software emulation is only a close-enough approximation. One of the the other computer emulation communities that I've been to runs into the same problem where the hardware can't be emulated in software with enough precision that developing anything against the software emulator is a bit of an exercise in frustration. We can't be sure that is what the original hardware works like because not enough real hardware is in the hands of people who can reverse engineer them.

What I'd like to see is a SNES-FPGA kit that has a switch between HDMI-pixel-perfect scale (up to 8K) and Accurate (puts out 240p, use with external capture or upscaler) and can use original carts and controllers. A complete kit would need to emulate all the known chips if it doesn't have the cartridge slot, which means it may require a larger FPGA.

As I've mentioned elsewhere, the biggest pain point in modern SNES development is the lack of a C compiler. bsnes is accurate enough to develop without emulator frustrations, using it you're fairly unlikely to hit any quirk on hw later on.

The wiki-page did explain a good amount of things, but I actually already figured out most of what was mentioned in it. I meant the Super NES Emulator SE in specific, as there is no information whatsoever to be found, other than a scarce overview of its hardware (no software was ever seen).


I would love to include such an option. But there are two problems as far as I can tell:
1) The used FPGA wont be capable of driving an HDMI Signal (at least I have not found any Information, I use an Altera Cyclone II). However I could drive a VGA Signal with it, which I would assume to be enough to get a nice picture. VGA should also be fairly present on TVs and Monitors and not die any time soon (at least I hope so).
2) The PPU does not have a digital Output for composed Pixels, so in order to capture the video signal, I either have to somehow sample the analog signals from PPU2, process (upscale or anything else), then Output the analog for VGA. Or I need an FPGA PPU implementation that could mimic the PPU behavior (which is obviosly the better solution, but would require work that is not really on my TODO list).
Or maybe I am missing out on some way to get to the Pixel data?


What about cc65? Shouldnt that be suited for SNES development, or 65816 in general?

I figured that too, which is why I ask if there is even a need for development Hardware other than the existing Flash Cartridges.

A year ago, I made a list of SNESdev hurdles, some with solutions.

cc65 is for 6502, not 65816. Code produced under the assumption that a 65816 can act like a 6502 expects the data bank register to equal the program bank register, and it uses a slow software stack through 8-bit accumulator and index registers. If your object code exceeds 32K, you have to string together the different banks as completely separate programs. And there's a feeling that it's not efficient enough to make the sort of detailed action games that people expect out of the Super NES. Finally, though macros exist to make SPC700 code with 65C02 mnemonics (thanks blargg), I haven't seen anyone hook up cc65 in that way. Would tcc-65816 work?

If you want to make a 16-bit game in C, here are the first of 68,000 things you could try:

1. Read through the first book of the Bible.
2. Listen to a rock album that shows a Tupperware Shape-O sorting toy on the cover. (Clue: Phil Collins sang on it.)
3. Take the Bible and the CD to your Hyundai dealer and ask about a sporty sports car.
4. Have Xzibit put a game console in your car so your passenger can...

In case you're confused: If use of C is a sticking point, start with the Sega Genesis rather than the Super NES. To get started, try spritesmind.net.


Besides, no compiler is going to draw several megabits of sprites, background tiles, and audio waves for you. And as dougeff pointed out, a 16-bit game is going to need to look at least as good as Super Mario World.

I have mistakenly assumed ca65 compatibility would also apply to cc65.
However I have seen WDCTools is available for free, that would at least supply you with an additional IDE.
Other than that, it seems that tcc-65816 is the only open source solution available?

WDC's cannot be used for commercial development, it's Windows-only, and does not support the SNES directly. The tcc port is so buggy it cannot be called a compiler.

1) You can drive HDMI directly with a FPGA, the catch is that most FPGA dev boards use a separate chip to do HDMI,VGA and Composite video thus incur latency and timing issues with the PPU. Thanks NTSC.

2) From a development perspective you'd have to emulate the PPU1 and PPU2 as it exists in hardware, and then drive a pixel doubler and HDMI output where the S-ENC/S-MIX is normally. If you are developing something to target 10 year old computer monitors and televisions, yes VGA might be fine, but that is not the direction anything is going. If you buy a 4K monitor, there is only DisplayPort, HDMI2.0/MHL or USB-C (which includes power for MHL, and HDMI 2.0 or DisplayPort alternate modes.) 4K monitors can still do VGA resolution at 640x480, but that invokes the monitor's scaler, which adds latency in pretty much every case. 4K televisions are worse in this regard as they've been deleting S-Video, VGA and YPbPr component connections, and "smartTV" add additional latency that previous models previous overlays didn't have. The video scaler's in TV's assume you're connecting something like a VHS deck where you can simply stretch the video and it doesn't make the video any worse than it was originally, and the latency is irrelevant. When you connect a video game to a TV, unless it explicitly has a game mode for that input, it typically gets stretched in ways that makes the pixels smeared.

Like I get it, on one side people would prefer an accurate pixel-perfect emulation, which requires emulating the PPU in a way that multiplies the pixels at the last stage possible. On the other hand doing so would require more complex FPGA's. See the difference between the RetroAVS(Xilnix Spartan 6) vs. Analogue Nt mini(Altera Cyclone V), where the former is $150 and the latter is $450. I'd assume a devkit system would be more like the latter with all the options.

That said the main issue with developing things for 16-bit systems is that they are not things you can just develop on a software emulator and then expect to work on real hardware or re-engineered hardware. It's not enough to go "it works", it has to "work on every version." So it's very likely any development solution ends up being two FPGA's, one that emulates the base system, and one that emulates the cartridge and any additional coprocessors, because the co-processors are not always used (and if the option to use the SA1 were always available, it's likely that it would be used, but that then limits it to people who have a cartridge with it.) If someone wants to release their homebrew SNES game, right now you have no guarantee that it works on anything but the emulator it was developed against. So it's very likely that a fully functional devkit ends up costing $1000, which puts it out of price range for just about everyone.

I'd like to see such a thing, even if it's expensive, but I think at some point it has to be evaluated for practicality. Would it be cheaper to have 4 cheaper FGPA's than one expensive FPGA? Who knows until someone tries.

In case people haven't seen it
http://pgate1.at-ninja.jp/SNES_on_FPGA/rpt_DE2-115.htm
The SFC FPGA here, 28,417 / 114,480 Logic elements for the entire SFC. Of which 13476 Logic cells are for the APU alone(11400 DSP, 1707 SPC.) 11853 For the rest of the CPU/PPU (1790 DMA, 2160 MPU, 7060 PPU1, 392 PPU2)
I've seen at least two FPGA projects online that have done HDMI with the FPGA alone, but because they require high speed transmitters, they can't just use cheap FPGA's and high resolution.

For me, the lack of compiler is the least of my worries. I'll use ASM (ca65).

My main concerns are...
-no specific GUI tool for working with SNES graphics
-music (SPC programming)
-I had to read multiple, very large technical documents just to print "Hello World" on the screen.

But, at least we have 2 decent SNES emulators with debugging tools (thanks guys)

Oh, and I still need to buy a flash cart. RetroUSB is out of SNES PowerPaks, and Krikzz doesn't take PayPal... so I'm not sure what I'm going to do there (I don't like paying for online things with credit cards).

Yeah if these worries could be tackled I feel like SNES homebrew scene could take off kind of like the NES one. A Snes Screen Tool and a SNES Nerdy Nights to help people get started would be great. I haven't looked into SPC programming so much yet but there at least seems to be some kind of MML for Super Mario World and lots of info about Nintendo's N-SPC engine. An open source version of N-SPC would be nice too.


I never had the Powerpak but it seems to me to be just very expensive and yet inferior to most other modern SNES flashcarts. It costs almost as much as the SD2SNES and yet it's worse than the Super Everdrive in every way. I have the SD2SNES and it's almost flawless and fully open source, but the Super Everdrive seems to be a solid and inexpensive alternative. There's a list of official resellers for Krikzz' products here (Krikzz makes and sells the SD2SNES too).

That and last time I checked (today), PayPal offered a Debit MasterCard. That might help with dealers that have integrated a payment processor other than PayPal.

But both the EverDrive and the SD2SNES are backordered at the North American dealer.

I agree 100% with your ambitions to bring home brew hardware into this community. That is also my goal as well with 21FX-TL and EP. The fact that SD2SNES was open source helped me so much and I want to keep creating new hardware and help out others. With that spirit all the hardware I make I will release it open source because I want HW developers like you and others to take the technology and keep adding on. The cart I'm making has 1MB PSRAM and an FTDI USB controller so the capabilities of internet connectivity and dynamic ROM loading should be possible. However I understand these things take time and have to be iterative and a community effort. Right now my goal is to reduce the BOM cost while reporting back info on any proof of concepts I create with this hardware. I would like to get it into developers hands at a reasonable price/assembly. I'm a bit weary about things like HDMI and feature creep as it adds too much cost and complexity in early platform designs. However as time goes on and testing goes well I think the more advance features will come. Starting simple is key.

@Kismet:
I have done some more research and it turns out I would need a better, more expensive FPGA to drive a DVI or HDMI signal. The Cyclone II does not have the required TMDS Interface, and LVDS seems to be not suited to drive TMDS. And if the FPGA had the TMDS Interface, it would allow only for a 640x480 due to speed issues.
In addition to that, in order to get "the most responsive picture" I would need to rewrite the PPU for the FPGA for direct access to the pixel information, which I did not really intend to do.

I dont think this applies, because in my situation using any more amount of the same FPGA wouldnt really help the missing TMDS Interface to pop up. So Isee no point in testing this (though I would love to be disproven by some crazy EE-Tricks ).


This is true. I am currently just asking for what the hardware is supposed to do for someone using it, so I know what I could add to (or remove from) the project. The current goal remains to get ROMs loading from an SD Card and dumping a Cartridge's contents, all built into the console.

Yeah, if you're a normal, sane person trying to develop a new game from scratch within the accepted limits of the Super NES. It won't let you get away with basic screwups like writing to VRAM during active display or using 60 KB of sample data with a 240 ms echo buffer, and even fancy tricks like Air Strike Patrol's mid-scanline scroll and brightness changes or blargg's echo buffer streaming technique will work fine.

If you're not a normal, sane person who respects the accepted limits of the Super NES, you can run into edge cases that bsnes doesn't handle properly. For instance, my ongoing attempt to port a shmup from a much more advanced platform set in motion a chain of events that resulted in bsnes acquiring mid-scanline BGMODE change capability as of higan v095, but it still doesn't emulate the glitched area properly; I need to test on real hardware to see the specks that show through the sprites used to mask the garbage. And the only reason I didn't run into trouble with mid-screen OBSEL changes is that I'm doing them mid-scanline; bsnes doesn't quite handle the timing correctly during HBlank (you shouldn't be changing OBJ base addresses during HBlank anyway, and why would you want to change sprite sizes? Even so). My largely useless DMA direct colour demo is another example of the timing in bsnes being slightly funky - oddly enough it works better in v072 (since I added the DMA/PPU alignment check) than in the latest versions, but in all cases the picture is displayed one scanline late. (It's still pretty cool that it works at all; no other emulator even displays the picture.) Finally, I seem to recall having trouble with turning off forced blank during HBlank; bsnes has/had slightly more forgiving timing than real hardware, so it was easier to get a glitch-free picture with the goofy H/V counter polling loop I was using (don't do this unless you have no choice; an IRQ is generally better, as is HDMA if you can spare a channel).

In every single one of those cases, I would refuse to speculate on the behaviour of a SNES Jr. without specifically testing on one. Apparently they're a fair bit different internally. Even the ASP brightness change trick doesn't work properly...

There's also the fact that it can be very difficult to get low latency with any PC-based emulator, so tuning the controls and designing the challenges in an action game could benefit from access to real hardware. (On the flip side, tuning the game in an emulator might be a way to more accurately target the bulk of your likely audience...)


Not if you want to load an outsize ROM. Super Everdrive only has 7 MB of flash memory. And doesn't the PowerPak load faster?

I thought about making a tutorial, but the question is what PPU configuration should be recommended? I used to think this was a good arrangement:

$0000 sprites
$2000 BG1 map
$2800 BG2 map
$3000 BG3 map
$3800 BG4 map
$4000 4bpp tile patterns
$7000 2bpp tile patterns

...but that doesn't allow for Mode-7, because Mode-7 takes up the first 32kB so this might be a better arrangement:

$0000 Mode-7
$4000 sprites
$6000 4bpp tile patterns (for ground)
$7000 2bpp tile patterns (for HUD)
$7800 BG1 map (for ground)
$7C00 BG3 map (for HUD)

For a newbie tutorial there is no need to go into Mode 7 right away, a general VRAM setup is enough. You teach how to change each VRAM base address so people can set them in a way that is most suitable for their projects, and you can go into Mode 7 in a later chapter.

Currently bazz' tutorial seems to be the best one. But he uses WLA while people here seems to prefer ca65 (including me), and he has lots of confusing WLA-specefic macros not very suitable for a newbie tutorial. It would be best to write it so that the user can easilly change the assembler to one he prefers. Also there are a ton of overcomplicated variations of the init code, and none of them seems to follow the recommendations of the official dev docs.



Oh yeah I forgot Super Everdrive uses flash which is slow, what a bummer (Famicom Everdrive is a solid product so I'm kind of assuming Super Everdrive is good too). How much memory do the Super Powerpak have?
The SD2SNES is only a bit more expensive and offers a ton of more features though (RTC, Satellaview, Cx4, MSU-1 and other cool stuff). I don't know if it loads faster than the Powerpak, but it does load about instantly (it uses 16 MB PSRAM) despite using SD, and it has USB for transfering the ROM directly from the PC.

The PowerPak can reportedly load the chipless Star Ocean hack, which is 12 MB. I can't find a reference indicating how much memory it has, but since it doesn't support any bankswitching chips and there are unlikely to ever be any bare ROMs larger than 12 MB, I suppose the answer is "enough".

Oh that much? I didn't know. Then it beats the Super Everdrive at least in that area, although Super Everdrive is still big enough for all comercial ROMs. While the SD2SNES has 16 MB for ROMs, it supposedly only currently supports 12 MB, "as there are no larger known memory maps". Hopefully though in the future it will support S-DD1 so the Star Ocean hack will become obsolete for SD2SNES users.

SD2SNES loading speed seems to be ~9MB/s.
https://sd2snes.de/blog/status

Another thing I don't like about the Powerpak is that it only supports CF cards which are getting harder to come by here, and are also quite expensive.

> In every single one of those cases, I would refuse to speculate on the behaviour of a SNES Jr. without specifically testing on one. Apparently they're a fair bit different internally. Even the ASP brightness change trick doesn't work properly...

As I've said before, I can't prove it, but my guess is higan is closer to a real SNES than the SNES Jr is.

They really made radical changes to the PPU's mid-scanline behavior. Which turns out to be fine since only ASP actually does anything with it.

People seem unwilling to group the SNES Jr into the clone category simply because it's official hardware, yet they don't seem to have that hangup with the official NES Classic device.

I don't know where people fall on the Genesis 3, but I would count that as a clone device as well.

Yeah what I'm thinking of was based on the original post of a complete devkit, not just a flash cart. If the plan is just for a debug-able devcart all you really need is a way to dump the RAM so you can compare it with Higan/BSNES.



The Cyclone II is 90nm, so it would probably not be feasible to put too much logic on it since it would require a more expensive version to produce.

When I was doing some research on the feasibility of a SNES-FPGA, apparently the FPGA (Cyclone V, which is a 28nm chip) used by the Analogue Mini NT, is just "capable" enough for 1080p with the entire NES logic on the FPGA. A very old post by kevtris says he used about 17500 gates on a 25K Cyclone III so based on the numbers by a previous SNES FPGA project , it looks like maybe 30,000 gates would be needed for the SNES before considering cartridge and video interface. However I don't know what exactly went into the Mini NT since nobody has one (that I'm aware of.) So I am pulling the numbers from guesses. Let's assume at some point a Cyclone VI comes out in 14nm, that would allow roughly 4x as many gates in the same die area, so might actually be cheaper then to produce a FPGA SNES then. Digikey's price for a single 5CEBA4F17C8N (Cyclone V E with 49,000 logic elements) is around $50. The next FPGA up 5CEBA7F23C8N is $160 with 149500 logic elements. I think every project trying to do a SNES FPGA is using a EP4CE115 Cyclone IV E FPGA Evaluation board (DE2-115) which is $595, has 114480 LE, and the chip alone is $315. And this board only has VGA and Analog audio output.

So right now, a complete "devkit" might be a bit on the ridiculous side, but just barely. Once you add in the other chips that could be emulated like the SA1 or the Cx4, that is large additional chunks of logic that will just sit idle in a base unit that a regular SNES would not have. I suppose one needs to ask the question of what, if any, additional chips do people actually intend to use. If you're just making a dev "cart" then you only need to enable one of those, the one the developer wishes to use, which would bring the logic units down, but also require the cart FPGA to be reprogrammed for each chip. Also... if the chip exists in both the cart and the base unit, how does the base unit know to turn off it's own chip?



Feature creep suggestions is how you decide which features are actually useful, and which features are wishful thinking. I think the entire thing needs to be considered as two separate but related projects.

The cartridge-side, which would be something more like a "lock-on" cart that can intercept, dump, or pass-thru the cartridge, dump the reachable system memory from the system bus, maybe replicate expansion chips if that is viable.

The console-side which would have have a way to pause-and-dump/edit the memory either back to a flash cart or to something else like USB or a SD-card. I'm not sure off-hand if that can specifically be done from a cart, but if it can be done without a FPGA-SNES that makes it that much more valuable. If the entire SNES has to be emulated, you may as well go the entire Analogue NT mini route and create both an analog path and a digital path, but you can cross the road when you get there.

Right now nobody has published code to a PPU for the SNES. Like to me, I only care about pixel-perfect scaling that bypasses the monitor scaler. I don't care for scanlines or xBRZ or any of that, and IMO it shouldn't exist in a devkit because that adds an extra thing that games need to be tested with. Someone who tests the game against scanline mode might find that it doesn't in fact it does not even remotely look that way on a real SNES even on a CRT (which is one of the things pointed out with the higan emulator, is that frequently there are things not emulated due to the timing hacks needed to make the minimum requirements a Pentium 133 (DOS ZSNES circa 1999,) not a 3Ghz i7.) I'm pretty sure all the ARM-based emulators are throwing away a lot timing information because they are substantially weaker parts than desktop systems but still more powerful than where we started when SNES emulators began. I'm pretty sure Nintendo is aware of this as well, and what we get on the Virtual Console is "close enough that QA testers didn't notice"

Like as far as what is useful, I think developers are more interested in being able to pause the CPU/PPU and then peek/poke the ram in a debugger and compare it to what happens in BSNES.

The Emulator SE (from pictures I've seen) shows three FPGA's on them which appear to be connected to the respective CPU, PPU and SPC memory buses. At least that's what it looks like. So my best guess is that the SCSI connection gives the developer a live look at the memory, and the midi output over midi (I'm assuming the red connector is a S/PDIF) is to monitor the music to see if it's playing the right notes and samples. Re-implementing all that mess probably isn't necessary and could probably be streamed over USB in some way. But more to the point, just being able to pause the SNES and dump the memory to the card would probably do the same thing. I assume the SCSI connection also allowed the SNES to do "step-into", but that could probably be done differently since a computer in 1990 would have been way to slow to have emulated the entire SNES in software, so they'd want to use the real hardware to do that.

Anyhow on the software end of things, I'm sure more software would come out if there are known good flash carts that have predictable characteristics. RAM and Flash memory do not have the same speed as Mask ROM, which is another unknown variable. So what might be fast on a software emulator becomes sluggish on a real SNES with a flash cart due to using the SRAM as workspace. It might even be reasonable to make one of the more accurate emulators be able to connect to a devkit over USB or ethernet or something.

But I'm not suggesting putting the cart before the horse, if something can't be done today, it can likely be done when the devkit parts are cheaper to obtain. I'm under no impression that the SNES would suddenly become a popular development platform, so highend features aren't likely needed when the software emulators can do most of that.

So buy an SD-to-CF adapter? I say this without having tried one. I should also point out that I asked bunnyboy many years ago about why he went with CF over SD (SD at the time was around/available). I don't remember the exact quote, but his explanation was that CF was a lot easier to interface with (either in the FPGA code or circuit-wise, I don't know) than SD.

@koitsu:
I can approve of the SD Card Interface not being too easy, I have a 1000 line state machine just to read the first sector of an SD Card (this includes calculating the CRC and initializing the SD Card).

Is there an up-to-date list of the differences? Also to clarify, are you referring to 1CHIP consoles using S-CPUN and S-APU? There are also units using S-CPU, S-PPU1, and S-PPU2 in conjunction with the S-APU. Newer PAL consoles are also 1CHIP without them being jr., and I think I recall there are jr's that use the old 3-chip setup.

> Is there an up-to-date list of the differences?

I haven't kept one, no.

What I know of is that the PPU mid-scanline effects are very different. For instance, adjusting the brightness register seems to only barely affect the brightness for some reason.

The weird glitchiness with the SMP timers in a certain edge case are also absent.

I don't know if these issues affect the 1CHIP consoles, but my guess is that they do. All of my testing has been on 1/1/1 and early 2/1/3 systems with separate chips for each component.

I've never heard of a Jr that wasn't a 1CHIP.

My usb keyboard has 1ms latency. The OS overhead can be expected to be less than half a ms. Does it really matter when a frame is 16.666ms? It's slower than a SNES controller, but in any visible way?

@byuu
Thanks. Also I recall that on the 1CHIP some (but not all) games that use mid-screen mode changes cause sync glitches where the mode change occurs.
I'm guessing(!) that the APU was simply fixed but the rest of the phenomena probably just stem from changes in the analog world where the levels are off, maybe caused by a different manufacturing process for the die.

Oh, and $2100 is a strange beast either way. Still haven't quite figured out the DMA/HDMA weirdness that seems to surround it. Didn't verify against 1/1/1 and 1CHIP yet though.

USB keyboards are usually low speed (1.5Mbit/s) devices, which operate on a 100Hz timebase—unlike high speed (12Mbit/s)'s 1kHz timebase. Are you sure about that latency figure?

I haven't measured, going by the reported specs.

YYCHR supports 3bpp and 4bpp SNES graphics. I think it's windows only tho.

My NES and Super NES project templates include a converter written in Python that converts an indexed PNG to 2bpp, 3bpp, or 4bpp tiles. This lets you use any paint program you want as a tile editor, so long as it supports indexed color (such as GIMP or Graphics Gale, not Pyxel Edit).



So use PNG as your master format, and have your makefile (or other build tool) run the converter whenever the PNG file changes. The one drawback of this workflow is that it's more useful for original software rather than hacks of someone else's proprietary ROM.

But then you might actually want something Super NES-specific, such as ability to remove duplicate tiles from a screen or convert a single image that uses multiple palettes. I haven't yet provided that.

What do you mean? Unless I'm mistaken, the S-CPU doesn't respond to wait states. All the timing is on-die. If the memory is too slow, you get errors, not slowdown.


It's not just input latency, though that's not always as good as you'd expect. It's the whole chain from input to display.

I once played F-Zero in emulation extensively when I was away from home and didn't have a TV, and when I came back for the holidays I booted up the real thing and immediately drove into a wall due to learned latency compensation. This caused me to swear off playing F-Zero in emulation. I've noted distracting jump precision issues in Super Mario World and pilot-induced oscillation in Super Mario Kart, for the same reason. And I just tried F-Zero again, and yep - pilot-induced oscillation. The controls feel horribly stiff and muddy.

It's real, and it's substantial. There's even an article about it on byuu's site. (Although near the end he seems to be claiming something about latency perception that I know isn't true, because I've messed with software synthesizers and I know what the difference between a 5 ms ASIO buffer and a 20 ms ASIO buffer feels like (even for a single keypress - so no, it's not just jitter I'm sensing). Also, I can feel the latency in Mario Golf on a real N64 on a CRT. Just because you can't repeat an action faster than a certain timeframe doesn't mean you can't perceive gaps smaller than that timeframe, or target a particular instant more precisely for a single action. Now, if he just means that the difference between 100 ms and 83 ms is immaterial, there may be a case for that...)

It kinda makes me worry about the public perception of classic NES and SNES games when I realize that most people playing them nowadays are using either emulators or HDTVs (and I'm sure the NES Mini is framebuffer-based, which adds a frame of latency before the TV even gets involved). I bet if you actually asked some of these people, they'd say Super Mario Bros. 3 has issues with control tightness, and put it down to the ancient technology of the NES rather than the modern technology that's actually the source of the problem...

Correct, the CPU has no concept of the memory state, it just reads the data on the bus at a specific rate. If the memory isn't fast enough, you just get undefined values, which can cause glitches, or crashes, but not slowdown. Also, modern SRAM/NOR Flash are considerably faster than the specced access times of the S/NES MaskROM's (for example, a Micron M29F160 has an access speed of 55ns), so it's a complete non-issue for the most part, unless you're dealing with really old obsolete parts or some really slow voltage translation buffers.



Don't the old-school Mario games have a ~4 frame input delay anyway? I would never describe Mario controls as "tight".

93143 yeah that's why I don't like emulators when playing for fun, being it Virtual Console, NES Classic Edition or free ones for PCs. Playing on emulators for development purposes are great though.


Depends on how you define clone. I think most people think a clone is when outside people try to mimic the hardware of another. No matter how much they change it's still not a clone in that case.
But yeah Nintendo almost always release an inferior version of their systems full with ridiculousness. The Famicom got the New Famicom that removes the microphone and the NES got the toploader missing a bunch of things, then we have the SFC Jr and late N64 without the EXP port, late Gamecube without the analogue output port (and removed the unused exp port), the backlit GBA SP AGS-101 (ok that one was actually better then the original SP I guess) and finaly the worst of all, the Wii without Gamecube backwards compatibility. The NES is also often jokely called the most accurate Famiclone.



Good point about the SD-to-CF-adapter, didn't knew about those.
The explanation I always heard about using CF is that it will allow much faster loading since the Famicom/SFC CPU has to do the job. But then the Everdrives came out using SD and booted games at least as fast as the Powerpaks did (except the ones that use flash).
Another flaw of the Super Powerpak is that the vertical bar on the screen is supposedly more pronounced on it due to noise.

I believe SMB uses bit shifting to calculate current speed, so ...acceleration + bit shift = zero for the first few frames. Deceleration is also a bit sluggish.

Modern games would use floating point speed and position, thus immediate response to input.

No.

Maybe the original SMB did something with acceleration that had that result when walking or running, but jump timing? No way. I believe SMW has a 1-frame delay on jumps, and the NES games were certainly not more sluggish than that.


This may be a terminology issue. I always found SMB3's controls to be extremely responsive and immediate on real hardware; I never felt like I was fighting the controls like I did with SMB. But if you think "tight" means no inertia or something, then I agree it isn't like that.

I don't remember where it was, but someone developed another kind of AI to play SMB, and found that they had latency issues when reading off the analog output over the emulated input they developed against. Claiming that there is no latency, or not perceptible latency in a television is just marketing. There is always latency, and it always depends on how a circuit is routed.

On a 1970's, early 80's TV (whom the RF converter was for) I in fact played the NES on, there is no perceived latency because this is what both the Famicom/Super Famicom and NES/SNES were designed against. RCA composite inputs didn't start appearing on televisions as standard until the 90's (N64, PS1.) By that time 3D comb filters were what started adding latency.

Any scanline delays inside the console are not perceptible until you try playing the exact same unit on a LCD monitor and discover that anywhere from 1 to 6 frames being buffered through the various stages used to decode, scale and stretch. When you go back to the CRT it's like "wow is that LCD ever rubbish." Right now you're better off with a "gaming" monitor than an expensive TV, due to the propensity for manufacturers to make "smartTV"'s and all the extra latency added by having that junk in it. People buy smartTV's to watch Netflix, not much else.

At any rate, we will never see a return to CRT screens, so we may as well not chase that optimization.

I couldn't find any mention in Google about a N64 edition without the bottom exp port. You sure it exists?

The Pikachu Edition doesnt have the EXP Port

> It's real, and it's substantial. There's even an article about it on byuu's site. (Although near the end he seems to be claiming something about latency perception that I know isn't true...)

Everyone misinterprets that point.

I've experienced the latency effect myself. I was playing Ninja Gaiden Trilogy on my real SNES + Sony PVM. I had every move timed to avoid taking any damage until stage 6-1. But I got tired of one loss to Jaquio restarting the entire level, so I switched to emulation to save state between each 6-N stage. And my timing was entirely off. I was getting hit constantly. Took a while to adapt to the new timings for everything. But I did, and I was right back to not getting hit at all until 6-1.

My point was more in line with people claiming they can totally tell the difference between lossless CD-quality audio and 24-bit 192KHz audio. Everyone wants to imagine themselves as some kind of god with superhuman abilities.

The thing with Ninja Gaiden is that I relearned how to play it and was back to not noticing it at all. It didn't make the game much harder.

I put a latency value for input polling into v101, and one thing you can do is raise it as high as you want. The difficulty of games doesn't start to go up until you reach around 80-100ms from the default of 5ms. (note that this is *added* latency to the rest of the chain.)

So the takeaway from that section of the article was: don't let perfection be the enemy of good. Shaving off 16ms of latency isn't going to turn your average game into a perfect world record-setting game.

It might be important if you're beating Tetris: Grand Master, or doing a no-hit Touhou game run. But for 99.999% of gamers, it's not the end of the world and proof you should go spend $1500+ buying old game systems, flash carts, CRT monitors, etc.

> Now, if he just means that the difference between 100 ms and 83 ms is immaterial, there may be a case for that

It's the same thing. 16ms is 16ms.

> and finaly the worst of all, the Wii without Gamecube backwards compatibility

Don't forget the Wii Mini without component output (composite only) and without internet connectivity.

You would really think consoles would become better in time as costs fell, not worse. Of course, now they're starting to (New 3DS, PS4 Pro, Scorpio). So now I have no idea when the best time to buy a system is :/

I didn't forget about the RVL-201 Wii Mini, I just lumped it together with the RVL-101, and it's just so ridicilous that I didn't even wanted to mention it. I forgot about the GBA Micro though, it had lots of stuff removed including disabling most of the GBz80 I think. I don't know if DS had any though? The DSi is closer to a sequel console rather than a new model (same goes for New 3DS). The closest thing for 3DS would probably be the 2DS so far, but it's released more as a budget alternative for children.

Buy used right after the next gen gets in stores

Pretty much everyone else misses the point of audio sampling >96khz, which is for mixing/mastering, not consumer playback. People keep trying to correlate "human hearing" frequencies with sampling rates which is two completely different things. Human hearing is X, therefor the sampling rate must be 2*X (Nyquist–Shannon sampling theorem.) But if you are mixing two sounds of different sampling rates, you need at least a higher sampling rate for mixing. This comes into play mostly in the domain of music since various instruments natural frequencies will not be recorded and mixed correctly, and computer generated music (eg FM synths, Trackers) which literately can generate frequencies that result in distortion if sampled too low. A blind test will always show that people who claim >96khz is better are full of it when they listen to the same thing at 44.1khz (CD) and can't tell the difference. 44.1khz was selected because of it's mathematical appropriateness, not because it happened to agree with the commonly held "humans can only hear up to 20,000hz" accepted knowledge. What most people perceive as better quality is really less noise from the DAC that is really only noticed at high volume.




I always buy consoles after the second "smaller" model comes out, despite those often losing features, the smaller model is less likely to die due to cooling improvements which allows for the smaller model in the first place. Though Microsoft gets a lot of frowny faces for the Xbox360. I waited until that was completely redesigned, and STILL the hard drive died. Everyone who bought a model before it, either had the unit RROD, or scratch the hell out of most of their discs. The 3DS, Wii and WiiU I have are both launch+a few months models. The DS I have is the Lite model which simply has brighter screens. The GBA I have is the first clamshell backlit model. Of these only the DS Lite is broken. The original SNES on the other hand, I had kept in it's original packaging when I moved, and when I took it out, dead. Storage kills games consoles.

IMO if consoles were to be designed better, the first thing I'd suggest is removing all the moving parts from the base unit, and use off-the-shelf SSD's instead of storage soldered to the motherboard or mechanical drives. But from a preservation point of view, I'd rather games were installed to removable storage unit that can be backed up by the user (like the 3DS, or Wii to WiiU) to new media for the same device over completely preventing backups at all. We're entering a stage of video games where thousands of games are just going to be lost because those who bought the games have no way of backing up the storage device and restoring it to the same or a replacement console. So 20 years after the console is released, there will be no replacement units. When I phoned Nintendo about that non-working SNES about a decade ago? They said try eBay. I since acquired another (slightly older (lower serial number,) broken) one that I'm going to attempt to fix before seeking out a working model.

But this is primarily why I want to see a FPGA SNES. The amount of working SNES models out there, and devices that have good scalers is quickly dropping. People who have broken SNES systems tend to throw them away because that's what you do with broken electronics today (Android smartphones have a lifespan of 18 months.) The Virtual Console (3DS, Wii, Wii U, NES Mini) is "good enough" for some popular games, but there's only 51 out of 780 or so games available on it, and few game companies want to remaster their old titles for new systems, especially the bad ones.

If some SNES devkit grade gear can be designed and created, is having something (eg like the Family Basic on the Famicom) for people to learn how the SNES actually works. That is usually enough to push people who are just casually interested to wanting to do more. If a "SNES-like" system came standard with the MSU-1 for example, that opens up an entirely new thing that people can do that also can work with original systems (with SD2SNES.) But let's not jump the gun here, I get excited when I see projects like this, but am fully aware that many such projects just never pan out because it's one person's spare time, not their job.

Ah, I see what you're saying.

Yes, you can get used to it, and it mostly makes up for it in a lot of cases. Super Mario Bros. 3 feels heavier in Nestopia, particularly windowed, but it doesn't seem to affect the difficulty much.

Still, I think the permanent impact of the lag depends on the game. Some of the older Touhou games, for instance, have 2-3 extra frames of lag on a modern machine without vpatch, and there are players that think using vpatch is cheating because it's about equivalent to going down one difficulty level. EoSD reportedly has two frames of lag, and when I tried vpatch it was a revelation.

Also, I used to be really quite good at F-Zero. I once came in second on Death Wind I with the Golden Fox on Master level, and third was regularly achievable if not quite routine. I was nowhere near as good in emulation, and I've never gotten back to that level of play.

The lag in Mario Golf on a real system is slightly annoying due to how the swing is controlled. I've tried it in Project64, and... NOPE.

I've never played Punch-Out!!, but apparently barring luck, Mike Tyson is literally impossible to beat for a person with normal reflexes playing on a normal HDTV.

I still think it's a shame so many people are probably growing up thinking that this is just how classic video games were.

That's right, stick to emulation. More old consoles and CRT monitors for me!

Seriously though, emulation is good enough for most people that casually play games and don't notice little things. I prefer to play on original consoles with analog CRTs rather than emulation. But it's expensive and not as easy these days. For the average person a cheap machine like the Raspberry Pi 3 could emulate most of the older games they are interested in playing well enough for them. It's a lot cheaper and can be hooked up to most displays.

If you don't have an analog CRT or maybe a Framemeister upscaler you may be better off with emulation as well since HDTVs suck for analog signals.

Though the talk got pretty much offtopic to whether or not the lag is perceivable or not, I guess from the answers before, it seems emulators are enough to debug developed SNES software.
There is rather a need for Software Tools to get easier into developement of SNES games and software.

I don't know if that's true.

It's probably okay if you don't get too crazy with PPU exploits and such (like I have), and if you have real hardware to do final verification on. I would absolutely trust bsnes to catch basically any possible mistake in my code, and it should properly handle any graphical technique that has precedent in the library (along with some that don't). But I would never publicly release a game that had never been run on real hardware, ideally on a devcart to eliminate register contamination from a flashcart/copier OS. No emulator is a perfect substitute for that.

Maybe I'm being too paranoid...

@93143
I considered in your reply that you already did get started to develop something, so for you the issue was the missing accuracy in the current emulators (though you really try some crazy things ). But there were several other posts that bassically said, that getting started with SNES development is hard due to missing software.

I will probably just integrate some easy way to upload software to the SNES with my hardware, but I guess I will ditch the advanced development stuff (though I guess I will finish my 65816 emulator for SNES that I started some time ago).

Edit: worded poorly, changed to 65816 emulator

Emulators are great for quick testing, I always test my programs on my flashcarts from time to time to make sure that they work on real hardware, there are often different results from emulators. And yeah in the end I would like to test on a devcart/repro-cart to make sure everything works from a cold boot.
I'd like to try the INL SNES cart, but it seems Paul only has North American SNES shells which won't fit in niether my Super Famicom nor my PAL SNES without an adapter. Krikzz used to sell the universal SNES cart shells that he uses for the SNES flashcarts, but they are the type with the two extra edge connectors on the sides so they aren't compatible with INL carts AFAIK.


Yes mainly: A graphic tool for converting bmp/png files (Tepples made one but it has Python dependencies) to the SNES formats, free music engine (if it doesn't already exist), Nerdy Nights-like newbie tutorial.

A Nerdy Nights-like tutorial should probably do the following:
- Teaching the overal structure and program flow of a basic SNES program, without complicating anything.
- Use the official names for registers. No need to invent new things.
- Be written so that it's easy to adapt into a different assembler (preferably use a general 65816 assembler with a common syntax like ca65).
- Teach how to initialize all registers like recommended by the official dev docs without complicating things.
- Possibly teach some 65816 programming along the way like Nerdy Nights does for 6502 (or at least make it easier for NES developers to immigrate to SNES).
- Teach how to make a simple game like Pong.
- 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.
- Eventually get into more advanced stuff.

For graphics conversion I use SnesGFX, it does output a map file for backgrounds and palettes, it does its job very well.
For music I know that SNESGSS exists (though I havent used it before). There are (apparently) no tutorials for SNES, but I think if you do the Nerdy Nights for NES, getting started with SNES is not hard, as there are plenty of resources on SNES Hardware (see fullsnes and superfamicomwiki). But you are right, in order to get started from ground up, it would be better to have a tutorial speciffically meant for the SNES.

I'm using SnesGFX too but it tends to make the output file much bigger than my png. Also it randomly inserts garbage into the file or otherwise formats it wrongly. That never happens to Nes Screen Tool. I think SnesGFX is more for ripping images than converting png to SNES CHR.

SNESGSS, looks like a tracker. Better than nothing I guess.

Yeah I'm currently learning from Fullsnes, Yoshi doc (thanks Koitsu), various tutorials at superfamicom.org, Tepples' example program (thanks) and the dev docs. Already knowing the NES hardware good enough makes things quite easy once you get used to all the new registers. But a good newbie tutorial in the lines of Nerdy Nights would make it easier for more people to get into SNES development.

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


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?

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

No. If you want someone to use a devkit, it has to be self-contained. If the tools are cross platform, you need to literately include a shell script or batch file that fetches dependencies. Those tend to rot quickly over time. At least "C" tools can be compiled into a binary and not need to depend on a C runtime, but because of the license quagmire of using free tools, that is often not the case. eg Linux tools the steps are typically " ./configure then ./make install" and it will complain about dependencies. If you use a package manager like Yum on linux or pkg on FreeBSD it will find compatible binaries for your platform, assuming your platform is still in a supported version. On Windows you are never given the opportunity to compile anything, but unlike Linux, most software products come with the dependencies (even if they're years out of date, they are the dependencies that work with that software.) Windows is not immune from dependency rot (known as dll hell) either.

So the best case scenario is you include the source and go "here, I made a thing, it was built against X, Y and Z dependencies which at the time it last worked could be found at (website), here's a make file to compile those things from source and work with my thing." I see this all the time. A software product is fundamentally broken if you can not provide a binary package (be it due to license issues, or laziness) that works out of the box with no further dependencies.



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.

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?


You can't depend on the support libraries for running binaries designed for Windows being installed on every computer, especially computers that did not ship with Windows. So by one plausible definition of "self-contained", each developer of tools would need to sell a Raspberry Pi 3 with a self-contained set of tools preinstalled, with one cable going out of the Pi and into a suitably modded Super NES Control Deck, so that the environment is "self-contained". Or what did you mean by "self-contained"?


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.

Well, the discussion seems to have moved on again, but I'd just like to belatedly point out that bsnes isn't nearly as good for the SA-1 as it is for the SNES itself; apparently the timing requirements are a bit too insane for a modern CPU, and certain behaviours are still not perfectly understood. This may also be true for the Super FX; there have been significant recent accuracy improvements, and I got the impression it wasn't the end of the road.

Working with either of those chips would ideally involve a hardware solution, and I have no idea how difficult it would be to get an FPGA to behave enough like an original chip to offer a valid testing environment. On the other hand, if you're going to manufacture the game with an onboard FPGA rather than destroying a bunch of copies of Yoshi's Island or Super Mario RPG, you'll probably want to check your code on the FPGA...

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...

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).



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).

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?

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.



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.

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



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.



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.



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.

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.

And test the produced executables on what?


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

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.


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.

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?


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.


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.

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 so too.

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. :/

Not to nitpick, but in 16bit mode, the 65816 accumulator is referred to as 'C', which has a low byte A and high byte B. See ASM with C in it (TCD, TCS). Also XBA (swap high and low byte).

But since XBA is the only opcode that uses B, it's not useful for much else but as the high byte of the accumulator in 16-bit mode.


You make them (I think).


At least you can assume that people that buy expensive Mac computers are either only interested in using them for websurfing on Starbucks, or are prepared to compile open source programs themselves.


Ah come on, someone are going to wine about it if they find a bug. Can't believe this is really that big of a problem.


Agreed! Smartphones are not good for much else but backgammon or solitair. Can't play action games without the feedback you get from real buttons. It's not as much fun either.

Last time I checked, make friend failed on my machine, complaining that there's no rule to make target friend. Where do I find a working Makefile for this?

It is baffling how frequently these (ARM-based emulators) show up, and use pirated games in the marketing (note screenshots of games that you can not legally buy for the unit alone):
https://www.indiegogo.com/projects/retr ... yer-cool#/
https://retropie.org.uk/

Both of these things use RetroArch which in turn use things like BSNES, SNES9X, ScummVM and MAME which they circumvent the licenses of the emulators by not including the emulators themselves with the hardware, which is why they don't mention the emulators by name in the marketing either, though you can see them in screenshots.

So the question is, why is this 60$ device any better than the RetroN 5 or the RetroFreak which can play your legal carts (with the same emulator cores no less)?

¯\_(ツ)_/¯

The chip used by RetroFreak and RetroN is the Rockchip 3066 which you can buy a devboard for $58 http://www.marsboard.com/marsboard_rk3066_feature.html

The Pi3 is $40 https://www.adafruit.com/product/3055

I can't imagine the experience of the RetroPie/RetroEngine being even usable when the base performance of the Pi3 is so poor relative to a desktop PC, and the emulators are just being compiled, not optimized for the specific multi-core ARM platforms.

Pi3: 478 on Geekbench single thread, that puts its somewhere between the Apple A5 (iPhone 4S) and the iPhone 5 or about the same speed as a Samsung Galaxy Note or S3 Neo. A Intel Atom N455 (think Chromebook) is slightly faster than that. So basically the worst performing Intel CPU in 2010. And yet here we are again with people throwing money at a project that at best gives you a poorer experience than the desktop computer, and at worst, a completely unusable experience.

For reference the ARM part Nintendo used for the mini is a AllWinner R16 (A33) , which has a geekbench score of 309. Something tells me that Nintendo Devs just wanted something cheap so they can port the NES VC emulator to it (likely written in C.) The R16 and the RPi2 use the same ARM Cortex-A7 (ARMv7-A), the RPi3 uses ARM Cortex-A53 (ARMv8-A). For comparison, the 3DS uses an ARM11(ARMv6) like the original Raspberry Pi. Now consider that the SNES emulator on the new 3DS requires the quad-core version of the otherwise identical chip. Did they bury a SNES core in that CPU, or is the emulation not as good as the PPC Wii/WiiU version?

The cheap ARM stuff is barking loudly up the wrong tree. I imagine that only the 8-bit computers even produce 60fps on these devices (and indeed all the videos I see on RPi3's seem to show that 16-bit and 32-bit emulators don't run at 60fps.) They are not going to be 100% accurate, and I don't think they hit 99.0% "good enough" for most games even if the emulators they are using are 99.0% "good enough" on a high-end desktop.

It's not like Nintendo or Sega are ever going to support one of these devices, though at least Sega has released their own emulators for various platforms for Sonic games, thus you can move the ROMS from those into it. I don't ever expect Nintendo to do the same with Mario titles.

I don't have any of these cheap arm-based console emulators, as I would much rather support a FPGA project that can play the original cartridges (or authentic releases on alternate media) then encourage yet more piracy with devices that don't even have a cartridge reader for the device they are emulating.

A devkit needs to address the elephant in the room and say the device is a devkit and have the features of a devkit.

If only it was as simple as man friend but alas, no such manual page exists. Nor is there one for man woman... *sigh* adulting sucks.





Retropie is purely a software release, they're not selling hardware, nor are they circumventing any licensing (the entire project is hosted on Github). It's basically just taking RetroArch to the next level, where RA combines all of the different emulators together into a unified interface, this packages that along with everything else you would need to set up a dedicated emubox on a Raspberry Pi.

The RE Sigma, on the other hand... yeah that's basically just a Retron without the cartridge ports.

Wouldn't that be more like 700,000 or 800,000 instructions per second anyway? 300,000 would be like 9-12 cycles per instruction.

Not sure what byuu is taking about. The NES at 1.79mhz is like 450k average cycles a second (assuming 4 cycle average, but it's probably lower than that. Closer to 550k instructions per second). And the z80 reg pairs aren't functionality identical to an "accumulator" reg (matter of fact, a huge majority of operations have to be done through Z80's A reg).

Nitpicking aside, neither 65xx nor Z80 is well equipped for efficient compilation of C code.

There are examples of really efficient FORTH implementations for 65xx... I've been thinking a bit if one could make a more easily digestable high level language on top of FORTH that would suit the SNES. Some (optional) type checking and syntactic sugar for flow control and structs (with associated functions/methods) could result in something pretty neat I think.

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

I do.

> Not to nitpick, but in 16bit mode, the 65816 accumulator is referred to as 'C'

I know, and don't care.

> See ASM with C in it (TCD, TCS). Also XBA (swap high and low byte).

See lda #$1234, tax, pha, etc.

> Both of these things use RetroArch which in turn use things like BSNES, SNES9X, ScummVM and MAME which they circumvent the licenses of the emulators by not including the emulators themselves with the hardware, which is why they don't mention the emulators by name in the marketing either, though you can see them in screenshots.

There's no stopping that, unfortunately. All we can do is implore people not to buy such products.

> So the question is, why is this 60$ device any better than the RetroN 5 or the RetroFreak which can play your legal carts (with the same emulator cores no less)?

The RetroN 5 uses Snes9X without a proper license (there can't exist one: I'm a developer and the code I contributed was non-commercial only.)

In Hyperkin's defense, I believe they're moving to do the right thing. They purchased a license to higan from me, and asked about other cores to license.

> Not sure what byuu is taking about.

It was a quick ballpark number. I keep forgetting where I'm posting, sorry.

Okay guys, here you go:

NTSC CPU oscillar rate: 315/88*6 million = 21477272hz
Standard cycle = ~8 clocks (6, 8, or 12. 8 is the most common.)
Standard opcode = ~4 clocks (2 for NOP, INC; 4-5 for LDA $1234; 6-8 for LDA [$00],Y)
21477272/32=671,164.75 instructions per second, on average

Now keep in mind how many times you have to do two or more instructions for something that most processors can do in one: clc; adc instead of add. asl; asl; asl; asl instead of shl 4. pha; txa; clc; adc #$10; tax; pla instead of add x,#$10.

Point being: the CPU is less than 1 MIPS. Sacrificing most of that to trying to run C on a processor that vehemently opposes such a language is a fool's errand. There are many SNES games that bog down and choke even with well-optimized assembler.

If you want to write a Wheel of Fortune clone, go right ahead. If you want to write a Gradius or Rendering Ranger clone, good luck. If you want the AI in Der Langrisser to take 25 seconds instead of 5 seconds, then go for it.

...

Believe me, I'm with you guys. I want more SNES homebrew. But I'm telling you why we don't have it, and why the Genesis does. You can argue semantics with me, but you can't argue the reality of Pier Solar vs Pac Man.

That isn't a stealth jab at me for making something simple like Concentration Room back when I wasn't that experienced with large projects, was it? (well...)

DRW's forthcoming NES game City Trouble (product page; video) is written mostly in C. Or is that likewise VCS-ish?

In any case, with 16-bit A, X, Y, D, and S, and S-relative addressing modes for the group 1 instructions (dd,S and (dd,S),Y), the 65816 is at least less bad for C than the 6502 is.

Everybody says Konami has well-optimized assembly, but I know for a fact that it's not true. Konami's code just looks optimized because of their use of the direct page, but a lot of time is actually wasted moving stuff to and from the direct page that it actually ends up slower than if they just used absolute addressing.

Case in point, their collision subroutine looks optimized because both of the character's coordinates are placed in the direct page when it is being jumped to, but the routine that jumps to the collision routine has to copy the data into the direct page first before jumping to the collision routine.

Well, the difference between stating 300k and 670k is pretty big. I mean, it's as if someone where to come in here and state the SNES base clock speed 1.34mhz instead of 2.68mhz for lo-rom. For someone who has a reputation around the net about being obsessed with accuracy (which is a good thing), it's odd to see you throw out inaccurate numbers/claims like that.

I'm not championing C for these systems either, but I think the assessment of 2600 is a bit of an exaggeration. C for the 68k is sooo much of a better fit. But some of the big problems with C on the 65x isn't so much the smaller details (CLC needed with ADC, etc), but how none of the C compilers can optimize data structures or access to data structures in a way that optimal for the 65x arch. When it comes to speed, it's a pretty narrow window in how data is accessed on the 65x in relation to speed and layout. I'm sure the SNES has it's own issues compounded by the memory layout that adds to this ( long addressing via indirection might seem convenient, but local access with a better memory banking system is more efficient).

I would personally never want to use C on the SNES. I think you'd be fighting with it more, way more than with the NES and TG16 in C. So I'm not disagreeing with you, but having worked with C compilers and C generated code for the 65x, I just disagree with details of why.


What!? Who says this? Like many Japanese companies; great game design, mediocre code efficiency (speed) at best.

For what it's worth, overall I agree with byuu's stance on this (i.e. I've never seen C as a practical language on the 6502/65c02/65816 given how the designs and limitations of the architecture). I also agree that the 68K almost certainly is a substantially better CPU for C (or x86/x64 for that matter). All the additional registers, instructions, and addressing modes/features make it a better choice.

Switching consoles for just this paragraph: I think there are some C-based NES games which are pretty cool, but yes, you aren't going to find anything like, say, Gradius 2 in C on the NES -- or if you do, all the key/critical innards are done in native 6502. C has just too much "overhead" on the 65xxx architecture.

I don't write C compilers or look at their innards, but the limiting factors with the CPU architecture have nothing to do with the SNES's memory models (mode 20/21/25), although you probably would want mode 21/25 for a linear memory map, though the trade off is that MMIO register accesses take longer (you either use 24-bit addressing or you're going to be doing phb ... plb a lot), and the lda #$2100, tcd trick probably isn't going to help you either (I imagine C compilers on the 65816 make heavy use of DP).

I feel like a broken record saying this, but for the 65816, there are actually two C compilers that I know of: Toshi Morita's lcc816 and ORCA/C for the Apple IIGS. I can't remember if cc65 can be used either, but I do know ca65 has some very annoying design quirks/issues with 65816 that make it painful (I can't find the link on the forum, but we've discussed it before). lcc816 outputs code intended for ORCA/M (Apple IIGS), because Toshi did a lot on the IIGS (he's a guy I met back in 1993 and spent an afternoon/evening around). If you want to talk about "C compiler design for 65816" (since this thread is about the SNES, hence 65816), then Toshi might be a worthwhile person to ask, especially given his background (read, don't skim -- you will find several compilers he's worked on). (Injected note: I feel lucky that I still have my ORCA/M data around, as the Syndicomm website seems to be completely MIA at this point. That Opus ][ product is probably the best bet for getting your hands on it). If I remember correctly, and this is key, the ORCA/C manual actually goes over some of the internals of *how* it was designed/works.

I used ORCA/C on the IIGS for small/worthless projects (back when I was trying to learn C) and because it was the compiler used as part of the Apple IIGS's UNIX OS called GNO/ME. You'll find that most Apple IIGS projects involved ORCA/M (assembler), simply because, yes, that's right, the 65816 doesn't cater well to C in general. There were a couple games made for the IIGS in ORCA/C, but they were things like Tetris clones and (sorry for downplaying the complexities) "simple" games. For anything highly complicated and needed every cycle, assembly was the go-to. There were LOTS of great games on the IIGS in assembly. I can't speak for others, but I mainly did everything in ORCA/M (65816) (using Applesoft BASIC or ORCA/Pascal to generate data sets for me, although I did write a CDA in ORCA/Pascal). On the SNES, most of my efforts were done using a PC and cross-assembler, with nothing more than edit.com (QBasic in editor mode); any graphics/layout data I did was all hand-done using .dcb statements.

Did you notice a common theme in my above paragraphs? If not, here you go: the projects done using ORCA/C and similar were done on a system and environment -- the Apple IIGS, usually within GS/OS -- where tools were available (and those which weren't, you made yourself), all the way down to graphics editors (DreamGrafix) and audio tools (Soundsmith), and with tools that integrated with assembly very very well (this is critical/key!). Debugging was possible through a multitude of ways (GSBug, and classic printf-style debugging if you were using something in the ORCA shell environment), etc... Basically none of this is available on the SNES because it's a video game console, not a home computer. (Injected note: the guys who made DreamGrafix -- Jason Andersen and Steven Chiang -- were both co-founders of Tiburon Entertainment (now known as EA/Tiburon) and did all the Madden SNES titles. Jason worked way too much stuff (almost all in 65816), and Steven's now the executive VP at Warner Bros. Games).

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.

Breaking out of this excuse model is possible. One such example, though for the NES, is forum user JoeGtake2's game Mystic Searches (see The New 8-bit Heroes). He had game development experience prior, but no 6502 or NES knowledge. He set his mind to it, and he's doing it. In C? Nope, in assembly.

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.

> Well, the difference between stating 300k and 670k is pretty big.

And as I explained, 65xx often requires several instructions to do what another processor can in one.

So you can't compare 670K instructions on a 65816 to 670K instructions on a 68000, let alone on an ARM CPU.

I didn't really cover that nuance in my first post, but I thought I did a good job explaining that with my second post.

> it's odd to see you throw out inaccurate numbers/claims like that.

Look at the sheer volume of posts I make. 6000 on my own board, 6000 tweets, 1200 here, all the posts on Reddit/HN/etc ... some of my posts are of lower quality than others :/

> I think the assessment of 2600 is a bit of an exaggeration

It's really not. The only reason things look better is because of the graphical and audio capabilities being superior.

I guess we're just going to have to agree to disagree. But I have a ton of experience trying to wring out every last drop of performance on the SNES through -hard- code. Proportional font rendering, huffman/LZSS decompression, etc.

I also have experience with compilers and the requirements of transforming C code into 65816 assembler. It's not pretty.

> I would personally never want to use C on the SNES. I think you'd be fighting with it more, way more than with the NES and TG16 in C

It would be much more complex to try and take advantage of the P/M status flags efficiently. But it should still be possible to generate better code than with the 6502. But not by a whole lot.

What would've helped a lot was if we had sax,say,sxy (swap registers.) That would've made arithmetic on X/Y a lot less painful than it ends up being in practice.

My second major change would be to turn WDM into a one-cycle penalty prefix to invert the P/M flag of the next instruction. After that, I'd leave P/M clear outside of leaf functions, and use the prefix for when 8-bit was mandatory (which is not all that often. Mostly for I/O accesses or extreme memory contention.)

It still wouldn't be great for C, but that'd make things a lot easier for an intermediate language between C and assembler.

> I feel like a broken record saying this, but for the 65816, there are actually two C compilers that I know of

LordTech also got pretty far with one.

There's no surprise that they exist: the 65816 is Turning complete. It could handle C++17 or Haskell if you wanted. The issue is entirely performance. The translation has so much more overhead because there is only one accumulator.

I love the 65xx, but I don't pretend it's something it's not.

> So, all that said: the lack of C compiler really isn't what's keeping people from doing SNES homebrew.

I believe it's a large part of why there are so many commercial-quality games for the Mega Drive out of China. Fengshen Yingjiechuan alone (stolen music aside) is right up there with Bahamut Lagoon and Der Langrisser in terms of how much fun it is. And of course, Pier Solar.

But yeah, if we made "game dev kits", I think we'd see a lot more homebrew.

Imagine if instead of having closed source, Windows only, ROM hacking tools for specific games like Lunar Magic for Super Mario World ... we instead had engines like ViRGE or modern PC-based RPG Makers for the SNES.

You'd just use bytecode engines, tilemap editors, modify BMP graphics files, drop in music files to transform (hell, use the MSU1 if you want), have all the sound effects pre-loaded and ready to play for you, etc.

You'd need a strong community around each engine. One for JRPGs, one for Zelda 1-like games, etc.

Of course, by setting the bar so low, you'd get flooded with a bunch of shit-quality games, too. See Lunar Magic and Super Mario World for example. But there'd be some great games put out, too.

> it's that "writing stuff on the SNES is hard"

Honestly, having to code in assembler aside, it's not that bad unless you get super fancy.

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.

In that regard, I'd much rather work with the SNES and just not use all the fancy stuff the Genesis lacked anyway.

The audio ... in complete agreement there. Audio is a massive pain in the ass on the SNES.

I feel like most of the instruction set of the 65816 was wasted on 24-bit addressing. If they just kept the 16-bit address bus of the 6502, they could've had a much more powerful instruction set.

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.

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.

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:


Macro:

The code is readable, and I had no issues maintainig the readability throughout (almost) all of my code (it does need some cleanup ).
Or I am totally missing the point of what a C compiler is supposed to make easier when developing homebrew for old systems...

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

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.

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.

@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").

> 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.

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?

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.

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 ).


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.

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.


AKA "tracing holes" from the Pachi Com rant.


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.

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.

Another tool option that I made recently: https://github.com/fo-fo/snes-tile-tool ... le-tool.py (warning: Python )

@ koitsu
I agree with what you're saying.
I want to emphasize that many would like to make a SNES game but assembler is scary.

For PNG / PCX / SNES conversions I get the impression that everyone uses their own tool :p

I'll probably start using Tepple's python script eventually. I'll have to do a ton of reorganizing first, so that I don't accidentally draw over other stuff.

On the other hand, I don't know if there is any alternative to drawing out tile maps in hex. Can anybody tell what this is supposed to be?

Not without context. Also, whoever hand-coded that decided to stop complying with a consistent syntax near the end (they stopped zero-padding their zero values, e.g. 0 instead of $0000). The alignment can help. If it's a map/screen layout, maximising the screen + sitting back from it a little ways might give me an idea of what it's supposed to be. A logo? A town with a road through it? Hard to tell.

For tile maps it might not always be so bad to do hole tracing, especially if you can make an engine that's using metatiles to bring the tile map file size down. But for sprites and background graphics? No way! I don't think my right brain even understands the concept of hexadecimal numbers.


Hahaha that's stupid... eh hey!

Alright alright I'm going to go and install that stupid serpent one day... I have a new computer so it should probably work this time.


But how do you go and create the pcx files in the first place? No respectable image editor seems to be willing to even touch that format with a pair of pliers anymore.

That's because High school and College programs that involve programming use Java (and have been since 1998.) Looking at the local University's webpage they only mention Java and Python. Java has no Assembly code to look at, and neither does Python.

When you program something in C, the C compiler may produce Assembly code that you can look at, but unless you suddenly switch from C to assembly at that point, any changes you make at the assembly level are going to be erased when you next compile the C program. Likewise if you fail to initialize variables in C, you will never get two executions of the program to produce the same results.

As far as difficulty, it's only as difficult as you make it. If you load up a file in a hex-editor and transcribe the instructions to bytes itself, yes it's going to be hard.

I think it's more that you didn't present it as a standalone executable. My response to python is "eww"; why use python when you can use java - a self contained jar file, or wrap the jar file in an exe (windows for the win!).

For example, Tilemolester was distributed as a jar package and was quite successful. That same app in python probably wouldn't have gone anywhere. People who don't code in python, just have an aversion to it. Doesn't matter if it's logical or not. What matters is that it exists. If you want to create tools for yourself, no problem. But if you really want others to use your tools, you probably shouldn't "put your wallet in someone else's pocket".. so to speak. I remember people releasing tools in PHP, for rom hacking, and no one would touch them.

Just curious, but why do programmers pick python over java? My university just switched the two CS level I and level II pre-major classes (known as the elimination courses; weed out people trying for CS major) over from Java to Python - everyone (faculty and students) have collectively rolled their eyes. Java is now introduced as the third class in, in the pre-major line.

Photoshop, Gimp, and a bunch of top tier open source graphic editors support it. Not sure what you mean.

viewtopic.php?f=21&t=15165&start=15

It's this title screen. $08f0 and $08f1 are stars, $0000 is empty space, everything else is the girl.

Python? Bah. Matlab is where it's at.

Yeah, I'm one of those guys who uses his own tools. They're spectacularly application-specific, too; I have to write a new tool almost every time I do a new thing.

Sad world. I guess that's better than my high school though; there isn't even a programming class. Assembly was the first (and only) thing I know. I still imagine it's easier to get into assembly after learning a higher level language than to have no programing experience, or do you still have to start from scratch?

Every language has it's strengths and weaknesses, but for a university, it's a question of finding professors who actually know the language versus whatever is "hip" at the time. In 1998, that Java course I took, I ran circles around the professor, and I had never touched Java once before (only BASIC,) simply reading the Java manual was faster than waiting for the class to catch up.

I won't even get into why it's better to learn C than Java, but suffice it to say people need to learn the languages that they intend to develop software for, not the other way around. If you apply for a job at a game development company with nothing but "Java and Python" they will probably accept your application for linux server administration, but not game programming. If you have C and C++ in there, then you may get to use your java or python experience to write build tools.

From Capcom's job page for software engineer:


Here's a similar one from EA


So C++, C#, LUA. No Java and no python for games at least. The most jobs seen for Python are for web or database administration. Java, mostly logistics firms, database administration and engineering.

I would both agree and disagree with this assessment (re: "easier to get into assembly after learning a higher level language"). I can only speak for myself (where I started with Applesoft BASIC for a few months, then 65c02/machine language, then 65816, then x86 and Pascal, then C and Perl):

If you learn assembly first, you have a better understanding of how the actual CPU works at (almost) its lowest layer. (I am not going to sperglord, but I say "almost" because present-day x86/x64 CPUs have microcode, and then there's also the actual hardware layer. PLEASE DO NOT FOCUS ON THIS). However, when moving to a higher-level language, you find yourself asking questions like "I wonder how they implemented that in assembly", pondering how many cycles are potentially wasted, etc.

However, the other way around: if you learn a higher-level language first (ex. Ruby, Python, Go, whatever the current hipster trend garbage is), you have literally no understanding of how the CPU works. All you're given is a bunch of functions/methods/whatever that "do things" and "magic stuff happens!" What's going on deep under the hood (at the CPU level) is completely different. An example I use is mentioning whatever function "finds the first occurrence of character 'x' within a string". Good C programmers will know strchr() and what it actually is doing (iterating over the memory byte by byte, doing a comparison and incrementing a counter, then returning that counter value if the comparison is true, otherwise return NULL), but higher-level language programmers often have no clue. If you try to explain to them that the CPU is doing this, they look almost dumbfounded, like this kind of "What? Nah, surely it's not that arcane/cryptic" expression. Another good one is types (character vs. string vs. signed integer vs. unsigned integer vs. boolean), and a more evil one is data structures. Many think the CPU at the lowest level comprehends all of this, like somehow the CPU "truly understands" these different types of data: most CPUs don't (the IBM S/360 might be an exception -- a damn CPU that has instructions that handle UTF-8!). Data is data -- the CPU doesn't care. The delineation is how the assembly code is written to comprehend said numbers/types/structures. All of this is "black magic voodoo" to people, especially "web programmers".

We assembly guys look at shit like JavaScript and go "my god, I can't even imagine how many CPU cycles are wasted on all this abstraction and nonsense". Good C folks tend to be able to make pretty good guesses at what's going on at the layer underneath, but programmers exclusively using other PLs (again, especially "web people")? Objects? Fucking hilarious.

In other words: Assembly language is a human-readable encoding of machine language, which is the lowest user-serviceable level.


Even C++ polymorphism is somewhat predictable because of how every relevant compiler implements virtual dispatch through a "vtable". Polymorphism in assembly language programs ends up looking similar.

@koitsu I think I kind of get it; you will have a harder or easier time based on what language you're using. I was surprised some people would have an even harder time than if they didn't know anything, but it makes sense to me. People would have to unlearn stuff that they would assume is actually interacting with the CPU, but is really just abstraction. I wouldn't even be surprised if some people weren't even aware of what abstraction in this context is, as if the CPU can somehow read "printf("Hello World");". I really don't know much about high level programming languages (I don't plan on making this my job, as I now understand that programming 30 years ago is not what it is now; I will keep low level programming as a hobby though) but I imagine that many of them would fall apart if you were doing something that they weren't "intended" to do. I thought I heard that BASIC is like this, and is why it isn't used anywhere outside of a high school programming course, if it is even taught anymore.

> For PNG / PCX / SNES conversions I get the impression that everyone uses their own tool :p

Yeah, it takes like two minutes to write a PNG <-> SNES tiledata conversion tool.

I tried to make a tool (named mosaic) that let you program a delcarative syntax for transforming tiledata, and the syntax files would allow conversion in both directions. It was flexible enough to support almost any zany tile data layout in memory.

It turned out to be harder to remember how the syntax worked than to just hand-make the conversion tools on demand whenever I need them.

For graphics to be referenced in code, I forgo ASCII/hex representations and just output a binary file with a corresponding .inc file that defines a label and a size viable and then includes the binary file.

I'm not following your logic here. If a person goes "I'd like this game to run on the SNES", takes a look at the system, and stops due to the lack of a C compiler, how is it not due to lacking the compiler?

Do you mean to imply that the compiler is just an excuse, and they would give up due to other reasons if it existed? The Genesis scene is proof against that.


I've replied to this before, and byuu did as well. It's not true, barring compiler bugs.

I'm glad my high school taught me C++, it's one of the most useful languages to learn I think. You are forced to learn more about how computers work and it also has a common syntax used by many other languages, besides being very useful on its own. It's always easier to learn a new language the more programming you know before it (this goes for anything, it was much easier for me to learn Chinese because I already knew Swedish, English and Japanese which minimized the number of times I was shocked due to encountering a totally new kind of grammatical construction and the like), but learning a higher level language simply as a stepping stone in order to learn a lower level language and never use the higher level one again is a waste of time in my opinion. Sure you learn programming logic but you also waste a lot of time to learn a bunch of language-specefic things that you don't have any need of. In that case it would be better to just learn everything from the lower level language directly.

On the other hand, breaking down real applications (of anything) into abstract, "dumbed-down" components is a valid way of learning. For example in martial arts you first learn to use abstract movement schemes (kata and similar exercises) that, although not always directly realistic, contains ideal angles and muscle tension at ideal timing. At the same time they build up muscles, speed, breathing techniques and motor skills. When the body have stored this information correctly in muscle memory (after lots of repetitions and corrections), it is then easy to adapt a single one of these abstract component into many kinds of techniques (that needs to be practiced on its own as well though) that they form the basis of.

Back to programming, I don't know if high level programming can be used as a form of kata, or if low level programming is better suited for that. But I think it's best to focus on languages that you are interested in learning and that may be useful on their own.

BTW my C++ class was full of morons that had no will to learn anything. I'm probably the only one that learned to program C++ from it, not mentioning passing the course.



Huh? You are right, I have no idea why I got the impression that it wasn't supported before.

C++ is a language for people who enjoy the art of programming for the sake of it.

It's no surprise at all that people who want to do the bare minimum and get paid the most for their work hate it.

It's the violin of the programming world. Most people are happy to play guitar tabs (Java), and few people can make a violin sound nice. And it really doesn't help that C++'s default standard library is entirely out of tune, and the bow string it comes with is made out of barbed wire.

The key to turning C++ into a diamond is ignoring both the haters and the so-called "experts."

I think web browsers are the big holdout for PCX support.

As a format, it doesn't really offer much advantage these days. If you just want raw data easy to work with TGA is probably easiest, followed by BMP, which is almost as easy and more common. If you want small data, you'd probably prefer PNG or sometimes GIF (now that its patent has expired).

PCX was popular during a time where we needed reasonably good compression that was still easy to implement and performed well with very modest resources (i.e. RLE). BMP technically had an RLE compression option (TGA too), but this extension wasn't widely supported. PCX was the one where RLE was its standard compression method.

These days, though, there are lots of good image loader libraries that handle PCX and a bunch of other formats. It should be easy enough to work with PCX for old processes, but if you're working on a new process for something it would seem like a bit of an "archaic" choice for format?

There is a specific reason why web browsers support what they do. If only one web browser supports something (eg APNG, MNG), and nobody else does, the feature gets dropped.

Originally web browsers only supported JPG and GIF. The former was lossy and everything looked like garbage at 640x480 anyway. GIF was lossless, and could be animated, but was limited to 256 colors. There was no happy medium of lossless, non-animated, not patent-encumbered, true-color images. So PNG support eventually wound up in web browsers, but because MSIE didn't support the transparancy, nobody supported the transparency for a really long time.

Then comes google with it's microsoft-like attitude. WebP for everyone. What does WebP do? Nothing that JPG or PNG couldn't do, and by default it's more like JPEG. Go ahead and try to find libwebpdecoder by itself. Unlike PNG and GIF, it is threaded, and unlike JPG it can do lossless and some gif-like animation.

So what do you all think newbies are going to try and do with it? Yes, they will try to render animations to webp and use those as sprites in their HTML5 games. Bad idea. Unlike MNG, which was closer to a container for "muiltiple images" perfectly suitable for sprites, webp is just webm scaled back. So if you want to loop the same 2 seconds of video, that's exactly what you'll get. I've seen this kind of thing before back in some early 2D SNES-like RPG maker software, and also later with adventure game studio. The result is not good, and brings beefy desktops to a crawl because everything is being done in software on the CPU.

In the context of the SNES, at best you can get away with RLE without a performance impairment. If you want to get fancy you can do some lz compression of text and some kinds of bitmaps, but it comes with more loading time penalties.

Audio is an even worse monster. The SNES's APU is it's own separate cpu. So you're kinda at the whim of what the SPC700 can support, so when someone goes "gee I want to play that mp3/aac/flac/wav file" you can't just upload it and play it. The web browser's do not have any standard audio file or music file support. In the RPG Maker community, the latest MV version creates HTML5 games, but if you want to make a version that works on everything, you need to export the audio twice, once as mp3 and once as aac. You know what users of that software have a problem doing? Making sounds smaller so that the browser doesn't take 20 seconds to download, decompress and store in memory.

So yeah, web browsers are a holdout, but they are also the most sloppy things to code anything for. Look at it this way.
A web browser takes 1GB of ram, supports 95% of the stuff people want to do, but does all of it rather poorly. The web browser is trying to be the new "OS" layer.
ASM ->C libraries (dozens of them) -> C++ libraries/frameworks -> GUI ->DOM ->Javascript. To do one thing, you have to go through no less than 6 abstraction layers, and that doesn't include the OS and drivers. If someone is hellbent on using JQuery, or other javascript frameworks, that is yet more overhead.

If it feels like computers keep getting faster but software keeps getting slower, that is in fact what is happening. Throw cloud computing on top for yet another entire machine fabric's worth of abstraction.

Some of the abstraction of the "web platform" exists for two reasons. One is to make convenience reasonably safe, as the other option requires users to download, elevate, install, and launch the program from the native menu. The other is to reach users of Windows, macOS, X11/Linux, iOS, Android, and possibly even game consoles without having to remake the thing five or more times using five or more platforms' C libraries and recurring payments for developer certificates for many of these platforms. Unlike web development, which has free and inexpensive domain-validated certificates, code signing certificates recognized by popular operating systems are at least organization-validated. This means there's no counterpart to Let's Encrypt for code signing.

Yes, I absolutely didn't mean to imply that web browsers should have PCX. I just meant that I think they're the most visible place where they are conspicuously not supported.

I don't remember where I got the impression that Gimp and Photshop couldn't do PCX out of the box (it was probably about a year ago I last touched SNES development). But yeah PNG is probably the image format of choice nowdays.

PCX2Snes actually works now! I also found nconvert that can be included in the compiling tool chain to convert PNG to PCX (my favourite image editor iDraw only does PNG and BMP). A bit clunky tool chain but it works until I'm ready for the dreaded Python.


We where all new to programming but I think many people in my class had gotten the impression that programming involved some kind of graphical interface with pointing and clicking, and that games were easy to make. When they realized the harsh reality they just lost all their will to learn. This is a common attitude in Swedish schools. The Swedish school system is going down the drain, and the authorities just pretends that we are the best in the world and that there is no problem... Bah!


This is probably exactly why RPG Maker MV uses HTML5 and JavaScript. They ditched the RTP too (a run time package that you needed to install in order to play RPG Maker games earlier). I guess they assume people have faster computers with more harddisk space nowdays.

Well at least i can speak about my own experience.
I did lot of assembly back in time (mainly x86 but i touched also many other CPU) as i was really obsessed by performance. But with time i realized than assembly was a real pain to maintain and doing everything in assembly is just a *huge* waste of time compared to higher level language (as C). In almost case only 5% of the code is really performance critical so only that part need to be wrote in assembly if required.
So when i started to get interests in Megadrive programming, I immediately considered to code in C and i searched for a good C compiler for the Sega Megadrive. I started with SDCC which was terribly broken and bad... then i realized GCC was existing for m68K target so i compiled an old version of GCC which delivered "good enough" compiled code so i could use it for real development. And honestly without that GCC compiler i would have *never* attempted to do anything serious on that system...
I understand that with 8 bits systems you can eventually consider full assembly, because the system is so limited and C compilers are so bad you can't get anywhere, also project size is more limited so it's less problematic. But on a 16 bits system you should be able to stay with C for 90% of the code and only use assembly on critical parts...
I tried to code for the SNES but the fact there is no good C compiler was a terrible penalty for me, still i tried to use PVSnesLib and it was not that bad... but the SNES complex hardware and the poor performance and the compiled code ruined my motivations :p

Another point is that the language is nothing without a SDK, for me C is also good to provide a friendly and comprehensive API compared to ASM.

PNG is unfortunately a rather complicated format to implement. Specifically due to the use of the deflate algorithm, and the not-very-useful Adam7 deinterlacing. Paeth is weird but not that difficult.

I think it'd be very easy to write a format that's only a little more complicated than PCX, and results in files only a little larger than PNG. But of course there's no point since no one would use it (hi, BPS!)

Still, I'm always disappointed at complexity creep in file formats, protocols, etc. Now they're talking about using full-on video codecs to encode images on the web (eg WebP). FFS.

If a compiler can optimize code for 16 registers, couldn't it also optimize code for just one?

Yeah, it could, but it's a whole different league of difficult.

As a simplistic metaphor, consider the Tower of Hanoi puzzle. With a single "register", by which we mean "only one disc at a time", it takes 2ⁿ-1 moves to move a n-tall stack from one pile to another. But with n registers, it becomes trivial.

I think I have an idea of how the optimizations would be done.

As Byuu proposed, you could eventually try to write a customized/simplified compiler (using a syntax similar to C for convenience) specifically for the 65816 CPU. The optimizations psycopathicteen is speaking about are well known in compiler lands, you can probably use GCC to produce intermediate code and only do the last part to translate the GCC intermediate code to 65816 assembly (which is still a huge task).
https://en.wikipedia.org/wiki/Intermedi ... esentation
http://www.montefiore.ulg.ac.be/~geurts ... tecode.pdf

Are the optimizations already implemented?

Yeah, a big part of them and the most complexes ones. The only part remaining is the intermediate code to target assembly code translation, which also need optimizations in the process (as register allocation..) but it's much more simpler that handling a complete compiler from scratch
Here you have a nice tutorial about compiler design :
https://www.tutorialspoint.com/compiler ... /index.htm
You can see how far is the intermediate code generation in the process, it's why it's interesting to only consider that last step of intermediate code to target code translation if possible.

So is this last step what is still needed?

Yes, and it's far from trivial.

Most people on the internet do.

Which people? "Most people say [x]" is way too vague to be meaningful, and "everybody says [x]" is just outright bullshit.

Websites like Sega16 and Atariage.

Hello!

Some time ago I decided I wanted to learn Super Nintendo development. I managed to write 12 small programs, for example one for changing the background color, and another one for moving a sprite. I learned a lot from repeatedly reading documentation found on the web. I tested my programs on an emulator ('higan' if I remember correctly). I wanted to test them on real hardware, so I obtained a back-up device outfitted with a floppy drive emulator. Unfortunately about half of my programs did not work on real hardware. I obtained an official development kit hoping it would help me debug, but its power supply is broken and I've been too lazy to get that fixed. And even then, I'd have to get an ancient computer with Japanse software to interface with the unit, so I have all but given up on the dream of debugging my code on real hardware.

Anyway, here's the code, the documentation I wrote as I was developing and learning how the Super Nintendo works, and the slides for a presentation I once gave on the topic.

https://github.com/michielvoo/SNES
https://github.com/michielvoo/SNES/wiki
http://michielvoo.github.io/SNES/introduction

The code is for the WLA assembler, and I've added some library code for init, registers and some constants, just to make the example code more readable. I was about to write a sprite tool but then I lost interest ¯\_(ツ)_/¯

I still think the Super Nintendo is an awesome console, but not because of its system design; the games I played on it when I was young were my main inspiration.

Good luck with any endeavours in this space, I think you guys are amazing!

Maybe these products didn't exist when you were doing your dev work, but it's a little surprising you didn't consider the SD2SNES, SNES PowerPak, Super EverDrive -- especially considering how much pain you must have gone through to try and get an official devkit + hardware.

Thanks for putting your stuff online!

For me the SNES represents an interesting dichotomy.

With regards to NES and my nominal C64/128 development the SNES is relatively as so

NES : stuck is a desert with a small canteen and a walking stick
C64 : travelling through the dessert with a well stocked camel caravan and a compass.
C128 : travelling through the dessert with a well stocked camel caravan, a compass, a large water reserve and a motorbike to scout with.
SNES : living it up in *****s at the Hanging Gardens of Babylon eating grapes and drinking wine with a fan-boy to keep you cool.

we are all suffers of the 6502, the 65816 is a lovely CPU that fixes most of the issues, makes coding less painful, 2.5~3.5 mhz and 16 bits easy... Hardware Mul and Div to make up for the CPUs lack of operations, happy sigh. It has stack relative commands which helps with C. The ability to move the ZP and Stack allow for making micro threaded entity systems.
Then large number of sprites, 4 moveable planes, windows, colour, palettes, dedicated VRAM, dedicated Sound chip with its own RAM. DMA channels out of our ears... HDMA... 8 button joypad... and then we can drown in ROM...

So why do we waste our time with the NES and C64/128 when we can just live it up on the SNES and make the same game we make now but in half the time?

That leads to the other half of the tale...
Because if we did launch the straight C64/NES game on the SNES we would be laughed at. The SNES has all the toys and the disconcerting customer will demand them all. Just in the way a C64 game these days has to do all the tricks or go home, a SNES game will have to be top of the line... a top of the line SNES game is 5 people and 2 years of work.To which if I'm going to put in that work I might as well use game maker, get it done in 1 year and sell if somewhere I have a hope of making money ( a hope, not a reality ) like Steam. Because there aren't really any publishers for the SNES, you even still call the NES "homebrew", ( do you have NES publishers? )
Lets make a SNES game, is it a platformer, is it as good a SMW? DKC? ok no lets make a shooter, R-type3 Daruis good? JRPGs the SNES was king of those, is Chrono Trigger good, Terranigma, FF6 good? the bar is very high.

However this is 2017 and we have lots of new toys to get the development time down... only the SNES doesn't seem to... I first go into SNES dev on my P133 when Y0shi's doc was the only doc, and it seems if I wanted to do dev now my best bet would be to fire up the P133 and use the tools I had back then, as they won't run on my modern machine and there doesn't seem to be much to replace them...

I don't think fixing the lack of C compiler is going to really move the needle. Sure they modern people can say... oh man asm... but I want C.... but then if you give them C it will be... wait palettes you mean I can't just draw a png in photoshop, I have to work out tiles, I can only play 8 notes and not an mp3... the game maker crowd will never really push through the hard work of doing SNES dev, C or not. For me, C would be good enough on the SNES for doing presentation and general flow, but I would imagine I would need to kill the C runtime and drop into a pure ASM game core. It would save some time but not a lot of time. For me the rest of the tools,docs,turn key solutions would help a lot more. Porting the MACROSS assembler to 65816 might make a gentle halfway house though.

I don't think having C is the only push for getting more MD games, the fact it shares its core with the Amiga and ST means all their tools can be ported and the MD was more popular in the Euro zone where the demo coders are. They will just bash out a MD game for the fun it and to do something different for a change. Nintendo dominates in the US which doesn't really have a demo scene or programming mindset when it comes to computers. Also the MD has a lower standards.

For me the first step would be getting the tools and getting c# libs up to snuff, so people can make content, and build custom game tools quickly.
Then get some off the shelf solutions for things. The Audio tracker + playback code, standard joypad reading code, basic sprite bolting animation and movement system, something like http://codebase64.org/doku.php?id=base:start maybe port exominizer and make custom versions for it to depack to VRAM etc

Can those debug though?

Or to summarize that long post more concisely:

A 1- or 2-man hobbyist team can complete an NES game as visually impressive as a commercial game from the pre-MMC era (NROM, CNROM, FDS, early UNROM, thinking 1983-1986) in a reasonable time. Not all NES games are as visually impressive as, say, Battletoads or Bucky O'Hare. There's still plenty of room for a 512 kbit production, such as the NESdev Compo, and an option to upgrade to a cartridge release once you hit 1987-1989 levels of complexity.

But even the Super NES's launch titles, such as Super Mario World, are more visually impressive than Battletoads and Bucky. Matching those production values needs a bigger team. With more people on your team comes more pressure to pay them, and once they want money up front, a retraux production on a modern platform is the path of least resistance.

So anyway, about tools that you would have run on a Pentium 133 in MS-DOS or Windows 95: Which tools would you have used to assemble 65816 code, assemble SPC700 code, make tile graphics, make art, make BRR samples, make music sequences, and debug your program? Are there specific deficiencies in the debugging-oriented Super NES emulator bsnes-plus?

I've been chipping away at my dev setup/framework, libSFX, for some time now. It started life to handle S-CPU boilerplate for my S-APU tinkering (and to get me out of the tools ghetto that this thread is mostly about), but now it's possibly a good starting point for anyone that wants to get started with some SNES coding.

The SNES makes it a lot easier to do things, as a consequence we must do a lot more things. Is the TL;DR

X816 was the assembler I settled on. There is a RAW2SNES,GIF2SNES I think there was a PCX version as well, I eventually got hold of a leaked IFF2SNES which was used by some game devs.
Audio was very very primitive, I think a tool called SNESSOR was a tool for ripping bbr samples from games, and then you would use MIDI2MSS with the wavs of those samples and the actual brr samples. So you make the Midi on the PC using the wavs, then it packed it into some format and there was player code for it. Very very primitive from memory.
There was also a WAV2BRR but my music skills were never good enough so I just made things silent.

There was TileLayerP and a couple of others. I eventually made a Charset editor and Map editor as a SNES program. Then I would save the data to the SRAM, switch to windows and rename the srm file, then save the other. I then had a tool to strip and remove the excess from them. It was easier to use the SNES emulator to draw GUIS and the like than try and write windows code again to emulate all the drawing modes and pallets.65816 its faster to write than MFC Again coming from the C64 were all the char editors, screen editors, music makers, map makers etc were programs on it, it was just how I was use to things. There was another one that let you view ZSNES savestates, so you could run your code, then savestate it, the look at it in the tool to see all the other stuff you can't see on the screen to work out where you went wrong etc.

For debuggers there was the ZSNES one, which makes GDB look good. However as I came from C64 dev where the are no debuggers on the actual hardware ( although the fancy expensive assemblers had 6502 emulators so you could step your code, I didn't have a fancy one ), I just black box debugged as before.

I'm not saying the tools of yore are awesome, just seems to be more off them. Back then there was a small demoscene, since then most SNES work has been ROM translations, with some hacks. So the tools have grown up and around that purpose, so debuggers, translation tools, table editors, patch formats etc are well covered in the tool department, but the "to make something new" department is somewhat barren.

Now the Assemblers and Debuggers are miles better. I wouldn't use X816 any more, we have 64tass Then you have geigers and the new bsnes debuggers. There was a dev who told a tale of a game they worked on, and for months they just could not find what was corrupting a single pallet entry, so before they shipped they just made some code to patch it back at the end of vblank. With the modern tools I found it in 20mins for them. These debuggers, like FCEUX, take a more lets work out how this code works rather than, lets debug the code I just wrote work flow, well at least to me.

libSFX looks like an awesome start, nice work Optiroc.
However when it comes to more complex games, code is not really the battle, layout, balance, design start to take over.

Some of these tools exist:

• Assembler: I use ca65. x816 is hardcoded to LoROM (mode $20) anyway.
• Graphics conversion: I made a tool that can convert an indexed PNG, GIF, or BMP to 2-, 4-, or 8-bit planar or 8-bit packed formats, which I included with my Super NES project template. It currently doesn't do anything related to palettes or maps though. Though I made a tool to convert a PNG title screen to tile and map data, converting an arbitrary PNG is a bit of a harder problem with 1+8x15 colors than with 1+4x3 because it's harder to handmake the palette and specify it on the command line.
• Audio: We have an audio engine called SNESGSS. I also write my own WAV to BRR tool, which I included with my Super NES project template.

Is this in any way similar to a background graphics editor I made for NES?

I actually cleaned up and published the tool I've been using for graphics conversion recently: SuperFamiconv

It overcomes the shortcomings you mention and handles both indexed and RGB(A) images as input for either palette, tile and map generation. You can also feed (and output) palette data as JSON for easy tinkering or piping from some other format (like Photoshop ACT).

I've been pondering how to support the priority bit in generated maps. Without adding support for the monstrous (layered) TIFF or PSD formats as input the best way is probably to feed the tool an extra image with such metadata.

Would it be a useful starting place to make a converter that starts with Tiled's tmx files?

Oh, of course, I should absolutely add support for a Tiled workflow!

Command line converters are ok for a title screen or a small patch here and there, but when you start to get deep into development they really start to bite you.
As you add features you need to fix the order of things, or when you add things, have the maps and animations all update as well. When you modify an image and it adds a char here, the automatic conversion tools just happily rearranges everything. Then you have to go and edit your map blocks to match the new order, then you have edit all the anim data to match the new order. This turns add 1 tile into 4 days of boring slog. And that is on single layer, single map, 256 chars. I shudder to think what a 2 layer, 1024 char map would take.
If I have animating chars then I need to make sure they stay in a solid block, so I can just DMA in a slab of RAM. If I'm doing a rol/ror parallax effect then I can't have the tool mirror those 1 or 2 chars, and I need to make sure they stay in a fixed position. If I'm doing a palette cycle effect then I need to make sure that the colours are assigned to fixed locations on a fixed palette, and although I have other pixels that are the same colour, they then need to be assigned to a different entry. If I'm using the Char < X = solid, X < Char < Y = fall through, and Y < Char is no collide collision then I need to be able to have strict order control, be able to insert a char and have maps/blocks auto updated. If I have meta characters, like slope start, slope end etc then again.
The SNES way around this it to burn the ROM and RAM on a separate collision map, but then that is Y.A.T you need to make/update/maintain/document

Using an external tool to make the graphics is fine, there is no need to rebuild DP V or PS into the tool again, but it then needs to let me make a char into a file, import and convert it, then add it into the char set, map where I choose and set the params on it. The "old Skool way" is to put bounding boxes on your "sprites", and then you can encode data into said box. I.e colour 1 is used to denote Collision box, so you have two colour 1s in the top row and two on the left side. Then colour 2 might be anchor point. Colour 3 is 1+2 on the same pixel. Colour 4 might be used for another anchor point, say you are making a game like Alien 3, and you have N guns, you want the artist to be able to mark where the gun should be held, as each gun has its own sprites that have their anchor point. If you need more complex data, say you use AND masks for collision to achieve a more complex result, making the image Half-Bright, and then you paint the areas with the darker half. This then gives you a 6th plane for the AND mask, which you strip off and use the first 5 to generate the sprite data.
To avoid the PSD, TIFF mess I would recommend IFF, it is the battle warn, battle tested, won every victory, and still fighting file format. It's very light weight, very easy to parse and very flexible. Any "true" IFF tool will only edit the parts that it knows about and leave the rest of the file in tact. So if you have an ILBM chunk, and then you put your tile metadata into say a TLMD chunk, when a person opens the IFF file and edits the "image" the tool will save out the IFF file and keep the TLMD chunk intact.