nesdev.org

No chances for VRC7. Tempo - maybe, however I don't consider it as important feature for a simple demo/game sound engine, and I'm lazy to figure out it's exact behaviour in FamiTracker.

Don't really get how it could help. Usually there is no real need to have register update before VRAM magic (on NTSC NES at least), because the VRAM magic could only take relatively short time, jitter not going to be noticeable. The problem is when you have VRAM update in main 'thread', not in NMI h...

'Globtop' is an IC package, just like DIP or any other, but cheaper (no need to form, pins, etc plus less holes and soldering points on the board). It has disadvantages, of course - lower mechanical reliablity (bending the board could disconnect chip from the board), and lack of ability to replace s...

An NMI handler doesn't have to be in a separate file. It can be right below the subroutine that prepares the data that the NMI handler copies to VRAM. They can be next to each other in source code even if they have to be in separate banks because of how ca65 segments work. Thanks, I know how assemb...

if inside every loop you have a different code for PPU updates, how's that any different from having all of that as separate NMI handlers? It's practically the same amount of code, it's just ordered differently. That's it, code located in other place. Drawback is that it makes code more difficult t...

In your example there is just GameLoop, but actual game could have many loops (one for menu, other for game, other for pause, other for a cutscene). I think that this is where things turns to be more complex with VRAM update code in NMI, with switchable handlers or general update system you need mor...

It basically describes that I've meant under words 'a general VRAM update system'. Is there actual games that uses this method?

I don't think that putting all the code that access to VRAM to NMI affects to project design just 'a little bit'. I mean, let's say you have a game of few screens. For one screen you need to update part of nametable when user press keys; for other you need to animate part of nametable; for other you...

- NMI handler, all the code that updates VRAM should be there, and after it sound update routine called. If it is a game, it could need many different pieces of code that updates VRAM depending from situation, that could make a lot of headache to organize and debug (compared to previous case). I do...

There is a set of problems related to sound update routine calling in a more complex project than a simple demo. I still can't find nice NES-specific solutions to these, so maybe someone can give me some ideas or input how it was solved in existing games. Main problem is that you need to call sound ...

I've updated the archive without changing version number, but the update is important. First, sound effects converter was broken (altough it wasn't noticeable in the demo). Second, text exporter plugin was recompiled to work with FamiTracker 0.3.6, which was released recently. Third, short demo 'son...

There are two other animation NES demos, ones which marked 001 and 002.

There are few places in FamiTone code you can change to make it faster, but for most part it will increase player code size (unroll some loops, replace some calls with copies of code). setInstrument routine is indeed is the first candidate for optimization.

It is actually easy to make a direct export plugin for FamiTone (quick and dirty way: constuct a text file in memory or temp file, then use existing converter code on it). It wasn't done yet just because I'm lazy, and there are things in the converter that could be improved.

Is 'better' was the only word in my post? Yes, if you want to release something for really wide and not very techy auditory, you'd better to use zip to avoid questions 'what is 7zip' etc. Don't see any major problem for other cases, 7zip is around here since 1999, and now it is supported widely enou...