Hello,
I am completely new to NES development. I have just started to read a bit about it and still contemplating the idea to dive further.
One question that is puzzling me right now is about figuring out what could be the easiest workflow for modding existing ROMs or making new ones from scratch, then testing on the console itself.
Some years ago I played a bit with libnds and my workflow was like this:
several iterations of "code -> compile -> emu" and then testing the ROM on the nds with a flashcart once I was happy enough with the emulated result.
Would it be the same with NES development? Can I remain in the emu domain for testing basic thing and then use something like an Everdrive N8 to test my ROMs?
Apologies if this question is too trivial or obvious, any help or examples on existing workflows would be very useful for me to understand the process!
Thanks!
If you don't plan to use a custom mapper or other extra hardware, you can completely develop a game using existing modern emulators only. If you will consider certain NES limitations and quirks (documented everywhere, like VBlank time, DPCM/controller bug, and so on), good chances that your code will run on the actual hardware exactly as it runs on modern emulators. Note that old emulators were less precise and allowed some things that won't work on the hardware to run.
Testing on the hardware is certainly av good thing to make sure that everything works correctly, and should be done time to time if you have an opportunity, but if you don't have one, it is not a showstopper. Also, testing using Flash cartridges isn't a perfect way, because they could change system state. Like, a cart menu initialize PPU, leaving a bug in your PPU init code unnoticed.
I have set up a key combination in my text editor that runs a makefile that converts graphics to tiles, assembles and links the program, and starts the emulator. All I need to do is press Ctrl+R and wait a couple seconds, and FCEUX pops up. It's not the most accurate emulator, but it runs at full speed even on an Atom netbook.
Emulators should be accurate enough for game logic and even for basic graphics logic, but particularly timing-sensitive things like scroll splits and worst cases of VRAM updating should be tested on hardware. I'd recommend running your program on a flash cart at least once a day if you can; that'll also make sure your graphics look good on a TV and that your game's control doesn't rely on things that are easier on a keyboard than on an NES controller. To work around the problem of flash cart menus covering up init code bugs, you could use known-good, tested-on-hardware init code like that found in
my NROM project template.
Thanks both for the answers, very helpful!
One last thing, out of curiosity, if I would want to actually turn the bit of code into a "proper" cartridge, and knowing that flashcart based ROM testing comes with the strings attached you are describing, is there a hardware method that would be more reliable and faithful to test the code?
Paul at infiniteneslives.com sells single-game flash carts, the same kind that you'll probably use to make your finished product. Near the end, once your game is in late beta, try your release candidate builds on those. Make sure to test power cycles and resets, as there are several different micro-alignments between CPU and PPU timing that could screw things up.
Thanks for the link!
For the nds I was using emacs under Debian and also had some pseudo automation to quickly test my code with the emu.
Now I moved to FreeBSD but I see that Nestopia seems to be fully supported and I see that there is a port for cc65. I doubt there are many utilities running or compiling on FreeBSD though. The length of the list on the NesDev wiki is a bit daunting for a newcomer, any recommendation for an assembler, or is cc65 enough to get started?
lowgman wrote:
The length of the list on the NesDev wiki is a bit daunting for a newcomer, any recommendation for an assembler, or is cc65 enough to get started?
Um um... I know a good assembler... tokumaru told me about asm6 on
page 3 of the thread I've been asking questions and sometimes recieving answers about NES development (remember asking questions is mostly good.).
ASM6 is quite a good assembler! ... in
my our opinion.
And look see I used um twice... it's a real word scrabble dictionary.added.addition2.