2A03 Puritans compilation album

The debut album from the new label Bit Puritans released today! This is a 17-track compilation album of NES music, and I'm proud to have been a part of it.

The NES cartridge version is now available, as of April 21, 2014. Video: https://www.youtube.com/watch?v=CYKenZOpTF0

http://bitpuritans.bandcamp.com/album/2a03-puritans


1. jrlepage - Introduction
2. bradsmith - dry up and tumble on
3. ipi - Garten
4. TQ-Jam - Milky Fields
5. Doxic - Pollution
6. commandycan - Sky Bus For Hire
7. HertzDevil - Extends Levant
8. Jangler - Tide/Grotto
9. TristEndo - Be water my friend
10. kfaraday - The Bloop
11. stinkbug - Dreamgate
12. gyms - Magmo's Magical Ingot
13. Moot Booxlé - Ouroboros
14. Fearofdark - An Earth made of Molten Rock
15. chipchop - the robot emptiness
16. Zan-zan-zawa-veia - Dove Dome
17. KungFuFurby - Null and Void

No emulators, no expansions. All recordings were made from a real 2A03.

Compilation ROM/NSF/NSFe available: http://rainwarrior.ca/projects/nes/2a03puritans.html
Source code available in: this thread

Awesome! I'm giving this a listen.

By the way, how do you record this?

I want to make my album(s) real 2a03 recordings, but I don't know the best way to go about doing it.

So far I have: PowerPak -> NES -> Audio of AV to Line-in on computer. Is that it? Would people not mind the hum?

To minimize hum, set the background color to $0D and disable rendering before you start the recording.

Interesting advice. If I'm someday in the mood to rebuild the PowerPak's NSF player I might try it.

I didn't record this one, jrlepage did, but it's probably a setup close to what you described.

Is that what Loopy did here? I'd wish I'd gotten the link when I could.

As for the album, HertzDevil devilers some great content as always!

All tracks except for 3, 15 and 17 were recorded using my Famicom and my TNS-HFC3 cart's built-in 1/8" jack. Tracks 3, 15 and 17 were recorded using my Power Pak and my NES's AV out signal (because of incompatibility with the TNS-HFC3 hardware).

I take it there is no plan for a cartridge release? Pretty good stuff, nice work guys!

Do you want to help build one? It'd basically need a hardware version of the NSF mapper, and I think we'd need ~2MB ~1MB of ROM. I'd be willing to code a menu and whatnot to show some graphics, but the idea of building the mapper hardware is daunting to me.

FamiTracker, for one, supported output to .nes last time I checked.

It does not export to NES if the track is bankswitched (which almost all of these are). If I didn't have to worry about bankswitching I could just do it with an oversized AxROM kinda mapper.

I'd love to.

I'm not really sure how the whole NSF mapper/player thing is setup though... Is this the best documentation we have on it?

Loopy's source has some mention of counters and such.

I'm having a hard time wrapping my head around how this whole thing works. It's sounding like it all depends on the nsf player you create that will play .nsf files. From what I gather there is no specific 'nsf mapper'. To some degree we'd be creating a nsf player that was most easily played on low cost hardware.

Perhaps branching off to another topic is in order. I'd be interested, and I think should be possible with some of the stuff I have right now. Just need to better understand the 'mapper' and what options we do and don't have without making a ton of work.

Oh, well there's really only a few things we actually require. The wiki page for NSF outlines the complete NSF mapper, but what we'd need for this project specifically:

1. 8 x 4k switchable banks from $8000-FFFF. The banks are addressed by 8 registers accessed at $5FF8-5FFF. It looks like we need to address 1MB worth of ROM (our combined NSF data is ~760k), so they'll need be 8-bit bank select registers. These registers could be moved if necessary, but it'd be easiest if they were at the standard address.

2. The NSF spec expects RAM at $6000-7FFF, though I'm not sure if it's needed for this project. I don't believe that Famitracker NSFs depend on that RAM, but there are tracks from PPMCK and IT2NSF that I need to investigate a little. I think it's likely this RAM isn't needed (will report back later).

2. CHR-RAM would probably be the easiest way to do the visual stuff for this, so we wouldn't need any additional hardware logic to swap tiles. You could take your pick w.r.t. mirroring (vertical, horizontal, whatever), it doesn't need to be dynamic.

Edit: none of the NSFs require the RAM at $6000-7FFF so that part of the spec can be dropped.

Also, is it possible to initialize the top bank register to $FF on reset? I'm not sure if it's feasible to stick a reset stub into every bank of the NSFs.

Not sure how I missed the dedicated wiki... I was looking over kevtris' doc on the format after my post. While I'd probably need to make a few modifications to my current setup now is ideal timing to lay this out since I'm making other changes to my v1 board right now as well.


Not much issue allowing for this. Only adaptation needed is splitting PRG A12 for 4KB banks. However moving the banks would be helpful.


I understand these register locations were chosen to not conflict with WRAM and existing sound chip's registers. But this sucks up too much i/o to stay low cost since it'd require PRG A0-3 as inputs. PRG A0 might be okay, but A1, A2, and A3 are too costly. since we already require A12-A14 for decoding I'd suggest something like registers $8000, $9000, $A000 etc. Basically just line up the reg with the bank it controls. Could use $5000, $6000, $7000 as well possibly for other functions, or leave as options to de-conflict for other sound extension registers if desired in the future.


Agreed. Nice and easy, no changes needed. 8KB CHR-RAM and fix H/V/one-screen mirroring all requires no I/O from the mapper, so that sounds like the best route for this.


It's no problem to initialize any/all of the banks to the last bank at power on. Reset is a little more tricky/costly since you'd need another i/o to sense reset and possibly some discrete components. If it helps, since there isn't WRAM, fixing the last 4-8KB of ROM to $6000-7FFF would be pretty easy. So you'd only need a JMP $6000-7FFF stub in each bank that was ever placed at $F000-FFFF. You wouldn't need the stub in every bank, just the banks that might be there if the user hit reset.

Yeah, a bank register addressed at each 4k page would be fine.

Yeah, if the high bank is initialized at powerup that should be enough. I'm sure I could manage a stub in every bank that's mapped there. The problem I was concerned about was having to put a stub in all the banks.

There's probably no need to map anything to $6000. It might be a convenient place for some player code, but since $8000-BFFF is available to swap some code in anyway, it's not necessary.

Hello. I am one of the composers from the soundtrack.

With a couple of exceptions, the majority of the tracks were made in Famitracker. The exceptions are TQ-Jam's (which is done with MML) and my song, which was made with Schism Tracker and then converted to .nsf file via mukunda's it2nsf.

The documentation for it2nsf states that the memory mapping to $E000-FFFF must not be changed outside of its music routine. That's the DPCM data access. $A000-CFFF is not used in it2nsf.

I don't know what the other ones use for memory mapping, but as long as you don't accidentally switch the banks used for DPCM (I'd think that would be the only place not to touch the bank switches), I think you should be good.

I do have ideas about how a mapper can be made for .NSF, it especially simplify if it is only NTSC, and has no expansion audio, etc



Depending on what the $Fxxx bank is used for in the .NSF files you are using, the vector ROM might be unnecessary.

I believe this would be sufficient to implement a 2A03 only NSF player cartridge (tell me if I missed anything). The code for the player which is always present belongs in the fixed PRG ROM starting at $4800. (For example, the reset, interrupts, and code to clear the RAM) Sixteen bytes of the stack are reserved for the NSF player program, so the PLAY routine and current file number and so on can be stored there (you can also use CIRAM if you need additional RAM).

The simple mapper currently under consideration has 8 x 8-bit 4k bank registers, addressed at the standard NSF $5FF8-F, but also mirrored across all of $5000-5FFF. The high bank register should power on as $FF. This is more than sufficient for the 2A03 Puritans project.

However, I think zzo38's suggestion of a mapper override for the vector table is good, but only if paired with a fixed player code bank placed at $6000-7FFF (or other suitable location). In general RAM at $6000-7FFF is not necessary for homebrew NSFs (the popular NSF engines do not use it), but an always-available player location coupled with an automatic vector table would make it very easy to just drop an NSF in.

If you don't have a fixed bank available, though, there's really no point to overriding the vector table, because there's no sensible place to point the vectors at, unless you start modifying the NSF banks, at which point it's a non-issue to manually put the vector table in there.

Translated into software-ese:
$4800-$4FFF: Fixed PRG ROM for player.

It was perfectly clear, tepples.

This is now a real NES cartridge!

http://bitpuritans.bandcamp.com/album/2a03-puritans
Video: https://www.youtube.com/watch?v=CYKenZOpTF0

I did the programming and infiniteneslives built the hardware. In the future I plan to release a guide with some example source code on how to use the mapper we created.

I can't seem to order the carts, it takes me to a "please wait" screen and sits there.

I'm not the administrator, so I can't really help you with that, but that sounds like a problem with paypal to me.

I just wanted to know if I was the only one with the problem.

Anyone interested in source code, please see: this thread

Also, compilation ROM/NSF/NSFe files are available here: http://rainwarrior.ca/projects/nes/2a03puritans.html

Sorry for bumping the thread, but I wanted to say that I placed my order and got my cassette yesterday. Apparently I was #5, woo. Regardless, this has some amazing tunes given it's just the 2A03, I guess the DPCM allows for near-infinite 'instruments'. Extends Levant is probably the most impressive 2A03 song ever composed, and it would be the second longest NES song to my knowledge, the longest being (Samurai) Zombie Nation's stage select/continue theme, though I shouldn't count it since it's just the same beat repeated with different notes.

This cassette made me wonder, would it be possible to make a music cassette with a "music video" of sorts? Such as a bunch of cutscenes ala Ninja Gaiden and some sprites running around? Or that would be quite an achievement to make?

Actually, KungFuFurby's track on 2A03 puritans (Null and Void) is longer than Extends Levant.

Ballblazer has procedural music that will go on "forever", though you'll feel like you've heard it all after a few minutes. Solar Jetman has some really long tracks, though they're somewhat minimal compositions. I think the Jurassic Park tracks are probably really long, but I'd have to check again. In NES games it's generally not worthwhile to spend so much data on music... Extends Levant is 61k in size, only a few of the biggest NES game soundtracks are even 32k in size. There's a big difference between having an essentially unlimited budget, and having to make 10 tracks fit into 20k of data, so it's not really fair to compare against real game soundtracks anyway.

It's possible to do animations, yes. It just requires the time and effort of an artist and programmer.

I haven't listened to the game that far, I only made it around track 10-11 before I had to leave. I was close to finishing it, that I know.

And I figured that a "music video" game would be quite challenging, requiring a very good artist with a creative mind, which is allegedly on the complete opposite side of the spectrum of programmers. Ironically enough, said artists could probably do something like that for a "fake-bit" game, if only because they don't have to deal with assembly language and having strict limitations.

Well, what you're describing is done by the demoscene quite regularly. (e.g. high hopes by aspekt. BotB Winter Chip IV NES Flyer by miau/ui) Though, NES demos are kind of a minority. There's a lot more for C64, for example. There's lots of people doing unrestricted but retro-gaming inspired animation too. (e.g. Gamer - Turbo. Free Wilco by Bowz)

Anyhow, these things are totally doable. The hard part is finding the manpower and the will to complete the task.

There are more C64 demos because the demoscene was mostly a continental Europe thing, and during the NES's commercial era, continental Europe preferred open platforms such as the Commodore 64 and ZX Spectrum. The resident PlayStation fanboy on Slashdot claims that computer gaming remained popular in Europe because computer games were far cheaper to obtain, which is important for adoption in an area with undervalued currency such as eastern Europe at the time.

So anyway, one problem with making a rhythm game is that the best known design patterns for such a game are patented in nesdev.com's home country until around the end of this decade. And if Konami v. Roxor is any indication, the patent holders are unwilling to license their so-called "valuable intellectual property" to the so-called "riff-raff".

Hmm, I guess you're right, but what I was talking about would be like the Player video Rainwarrior posted, not necessarily a demo like the C64 stuff. Seeing cutscenes like Ninja Gaiden's and Vice: Project Doom (and how that game started BEFORE you got to the title screen) makes me yearn for something like a music video, with creative use of the NES' quirks and limitations. If you will, the Daicon IV of NES demos.

But it's just a suggestion, thanks for reading.