coding help

i have 7 .nam files with corresponding .pal files i would like to code into a rom that would play in sequence along with my original .nsf's. The screens all use the same .chr file which is 4 pages long, and the nsf's only use 20a3 channels and no dpcm. It's Very similar idea to Alex Mauer and no-carrier's vegavox 2, but with static images instead of scrolling logos.

So my question is would anybody be able to sew this all together for me? I unfortunately have little to no experience with programing. all the, .chr, .pal, .nam, and .nsf are organized in a numerical sequence within a single folder to make it as easy as i could to code.

I've spent a lot of time trying to make the music and artwork good enough that someone would want to code this thing just to have their name on the credits, but im also prepared to exchange code for cash.

here's a preview of one of the tunes along with a music video i made which was really a biproduct of the artwork.
http://www.youtube.com/watch?v=SI5l8DRo0ec



Thank you all in advance for your time.

chaz,
chazbc24@gmail.com

Do you know what programs are used to create the .NSF files? Do they use bankswitching? Also if you write about other information, such as controlled by user or automatic advance or whatever. I may be able to help; if so, I do not need my name on the credits and I do not need any money for it either; only thing I would ask is that the source-codes for the program that puts all of it together will be in public domain.

I used famitracker, and I was definatly planning on making it public. The more people see it the better. Ill pm you the files.

I've been asked to put a "slideshow" template project in NESICIDE a few times in the past...looks like this could be a candidate for that.

I was planning on doing a slideshow builder as part of my graphics editor project. This would make a good test case. I can help you with this through PM.

the only thing the user controls is starting the second track after the title screen. the rest will be automatic advance.

I will try (perhaps others can also try, and we can see who ends up doing what!). One thing that may help is the source code for the Famitracker playback engine so that we may know how to properly call init and playback and detect when it has stopped, and to know what ROM and RAM is free for other use.

Do you have idea to select a mapper? If not, I could try to look in wiki to select one that has the ideal bankswitching which is most useful for this, while being otherwise simple.

EDIT: I have looked at mappers; perhaps SFROM is OK. I looked at the .NSF in hex editor and it seems OK (the ROM addresses not used by any of these NSF can be used for the rest of the program, including nametables); 16K CHR is then good enough. I would still need to know what RAM is used but I could test that in the emulator too; it can display the contents of RAM while playing NSF files (and even allow them to be edited). But there is still one more thing: To know when the song ends. Looking at the wiki for FamiTracker, it appears to lack a direct write command. If the FamiTracker playback engine is known well enough perhaps there is some way to detect. There is a halt command; will that do?

However, I have a question: Why some nametable files are larger than others (especially 2.nam)?

i will go through the songs today, finish them up, clean them up, and add halt commands at the end of each track (except track 1).


I have no idea why 2.nam is so much bigger than every other file, i sent an email to no-carrier, who designed the flash tool which i used to create the graphics.

Keep in mind that if he wants to do a cartridge run you shouldn't pick anything exotic.

Is SFROM OK for that? Is the cost OK? (If not, make another suggestion.)

I honestly don't know how SFROM differs from the much more common SLROM. Are you picking SFROM just because it allows for less CHR-ROM? You can use less CHR-ROM in any board, the wiki lists the smaller values for SFROM likely because Nintendo used ROMs of that size, but as a general rule the CHR column in that wiki page lists the maximum CHR size, you can always use less than what's specified there.

Still, I don't know why use the MMC1 while you could just use simpler discrete logic mappers. UNROM, one of the simplest and most common mappers would probably work just fine, you'd just have to update the CHR-RAM manually, instead of using CHR-ROM with bankswitching.

Yes I did pick SFROM because it allows for less CHR ROM and has 32K PRG banks (I was trying to find a discrete logic mapper doing these things but failed). UNROM uses 16K PRG banks, and I think 7.nsf is too large to fit in 16K. The required CHR is also 16K (the actual file is larger but has junk at the end), and only 8 banks are possible. I do not yet have 6.nsf so I don't know how large that one is; otherwise UOROM might work since it can store all the nametables and pattern tables in other banks, and use the first part of the last (fixed) bank for the part in 7.nsf which exceeds $C000, and then there is enough space for the program as well in the fixed bank. Although, UNROM with banked CHR ROM might work too (saving 16K of PRG ROM), if it can be used.

A custom discrete logic mapper would work too, as follows: Have 256K PRG ROM (bank size 32K) and 16K CHR ROM (bank size 4K or 8K, either one works). When writing anywhere into $8000-$CFFF, use bits 0 to 3 to select a PRG ROM bank, and bits 4 and 5 to select a CHR ROM bank (in a bit similar way to UNROM). However, iNES, UNIF, and NES 2.0 do not support custom mappers; only DotFami does, and no emulators support DotFami (especially since the document is not complete, how can you have a specification to emulate?). In addition, I don't know how difficult it is to build your own mapper board, or if they even want to do that, etc.

But let's chazbc24 to decide too (his private message to me does say he wants to build cartridges). (Of course, anyone else who knows answers to what I have written, should also please reply to tell me if I did anything wrong.)

EDIT: I looked at wiki again, maybe mapper 240 might work? It is similar to the custom mapper I described above, except that the PRG bank and CHR bank bits are switched around. I do not know the name of mapper 240; the article does not say what it is.

zzo38: Look up GNROM. 32 KiB PRG banks, 8 KiB CHR banks, watch for bus conflicts. Or Color Dreams, which is the same except nibble swapped. Or BNROM: 32 KiB PRG banks with CHR RAM.

I made an AOROM Famitracker music project, and it is open source.

http://rainwarrior.ca/music/moon8romsrc.zip

I chose AOROM because it made it very easy to produce actual cartridges (just a single common 74161 as a mapper).

GNROM does not have enough banks; we need seven PRG banks, GNROM only has four. BNROM has the same problem. Mapper 240 (with less than the maximum PRG ROM and CHR ROM amounts) seems exactly what is needed, but how easy is it to make a cartridge with it? They wanted to make a cartridge.

To rainwarrior: OK, I looked at AOROM, which also seems it could work.

AOROM vs BNROM hardware is similarly easy to build. The ReproPak directly supports a BNROM with 8 banks (same as AOROM but you solder the tabs for mirroring instead of 1 screen), and you could relatively easily mod it to support 16 (two bent pins, one wire).

I think many emulators may support oversize BNROM, though I'm unsure.

Most emulators (and the PowerPak) do accept oversized BNROM programs (with up to 16 PRG-ROM banks), and carts are very easy to make/modify. GNROM carts can easily be modified to support more PRG, but I'm not sure emulators support that.


It may not be so easy because its register is mapped at $4020-5FFF (if it was $8000-$FFFF it would be super easy).

rainwarrior's suggestion of using AxROM is good, because those mappers are really simple.

True, rewiring a Deadly Towers donor might not be the best option here. But the obvious oversize extension of BNROM to sixteen banks works on PowerPak, and eight banks work on the ReproPak when you configure it for BNROM. Follow the AOROM instructions in the manual but set the mirroring to VERT or HORZ instead of ONE.

O, yes, you are correct; forgot that it is mapped at $4020-5FFF. Yes, $8000-$FFFF is better and AOROM is sufficient. I will use AOROM (unless chazbc24 objects). Now I will just need 6.nsf and it should be OK.

Unless the picture needs to scroll, the nametable mirroring shouldn't matter; even something strange like CIRAM A10 to CHR A6 (the adjacent pin, on both 60-pins and 72-pins) should work as far as I can tell (I may be wrong; I don't know it perfectly).

I recommend using the FTM sources and the .BIN export in Famitracker. That way you can use the famitracker driver source directly and modify it if needed.

I wrote a simple guide for this here: http://famitracker.com/forum/posts.php?id=3681

The open source project I posted earlier does the same thing, except it makes some minor modifications to the famitracker driver source.

Thanks. However: I do not even have Famitracker on my computer. My plan was to do something like this:

• Load .NSF memory directly into same address.
• RST points to equivalent code in all banks.
• Pattern table and nametable is stored in "scrambled" order in top ROM.
• Thirty-two bytes of palette is stored after that.
• Bank number of next song is also stored in each bank.
• The reset would tell it to select bank 0, wait for PPU, set up stack and so on.
• Disable PPU.
• Select address $0000 in PPU memory.
• Load pattern table and name tables.
• Select address $3F00 in PPU memory
• Load palettes.
• Set up PPU registers and enable rendering.
• Initialize registers according to NSF specification.
• Set A and X registers to zero (maybe it is already).
• Call NSF init routine.
• Enable IRQ.
• IRQ calls play routine (these NSFs seem to use the APU IRQ playback rate).
• In bank zero, check if START button is pushed. In other banks, check for music is finished by reading a RAM flag or something like that.
• If it is, select next bank and then next instruction will be the one to disable PPU.
• The pattern table/name table is 5K in total, and then 32 bytes for palette, and the rest of the program code then should not take up more than 1K or 2K, so it would expect that if .NSF file can be as large as 23K (counted starting from CPU memory $8000).

A question: What to do after the last song/slide is shown?

Discuss here on the forum about making the cartridge; while I would know how to design the circuit, I don't know what ways you want to use the build the cartridge and those other things (as well as such things as: number of pins, CIC (if 72-pins), where to get parts, which parts you are using, etc)

I made the program which will combine the music and graphics into the single file. It expects address $0211 to contain $01 while the music is playing and $00 when it finished playing (I used the VirtuaNES cheat finder to determine that this is true with the .NSF files I was asked to include).

Download: http://zzo38computer.org/nes_program/nsfslideshow.zip (all source codes and Windows binaries is included, although it should compile on other computers too)

http://www.retrousb.com/product_info.ph ... ucts_id=42

would i be able to use this for the repos?

As far as I can tell, the specifications are met, so probably it works. However, I have no experience with such things so I may be wrong.

I've used the ReproPak to make 60 or so AOROM repros so far. It works pretty well. (There are other simple mappers supported, see the manual.)

It supports a limited set of mappers; I think zzo38 used AOROM, so that'll be fine. The manual will tell you what chips you need. For AOROM you want a 74HC161 (or 74LS161) latch for bankswitching, a 27C020/27C010 eprom for your PRG data, a 6264/62256 for CHR RAM, a CIClone chip, and three small capacitors.

You'll also need a bunch of tools (soldering iron, solder, eprom programmer, wire cutters, pliers). Probably you want a plastic case to put the game in, too. RetroUSB also sells those.

fuck it. its a lot cheaper for me to just buy a bunch of ironswords and desolder the chips.

And that's the whole problem in a nutshell.

Fabio will never forgive you.

what eproms should i buy specifically?

27C020 holds 256kb of data
27C010 holds 128kb of data

Make sure the one you choose is big enough.

there is no specific one i need for the chr as opposed to the pgm?

You need RAM for your CHR chip. See what I wrote above, or read the ReproPak manual's AxROM section.

http://www.mediafire.com/?r8ivqgqw144k5a5

does this mean i only need to desolder and replace the pgm chip of the AOROM board?

This is kind of confusing. What is the "Ducktails" ROM for? If that's "Duck Tales" by Capcom, it's not an AOROM game.

You can't just desolder the chip from an AOROM game and replace it with a 27C020/27C010; you will need to bend some pins out and reroute them, because NES boards mostly use a nonstandard pin configuration for their ROMs.

Oh, I see, it's your music ROM? I hope the graphics are supposed to look like that.

Anyhow, the ROM pinout is here: http://wiki.nesdev.com/w/index.php/Mask_ROM_pinout

I tried your ROM in an emulator. The title screen looks okay, but everything else looks corrupted, but maybe that's what you wanted? There's some weird sounds at the beginning of the third track, but I'll presume that's intentional as well.

I've decided to stick with the method of re-using old boards. I figured out that i don't need to replace the chr ram only the prg rom... so i pretty much ruined the first 10 boards i worked on. tee hee hee.