nesdev.org

byuu wrote:So now I have no idea when the best time to buy a system is :/

Buy used right after the next gen gets in stores

byuu wrote: 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.

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.

byuu wrote: 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 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.

byuu wrote: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.

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.

byuu wrote: 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.

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.

elseyf wrote:it seems emulators are enough to debug developed SNES 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.

elseyf wrote:There is rather a need for Software Tools to get easier into developement of SNES games and software.

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.

Pokun wrote: 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.

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.

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

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

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

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

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

tepples wrote:

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

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

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

tepples wrote:

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

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

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

tepples wrote:

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

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

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

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

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

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

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

Kismet wrote:If you want someone to use a devkit, it has to be self-contained.

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"?

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

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?

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.

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