Create accountLogin

Recent searches

No recent searches

Search options

Not available on dragonscave.space.
dragonscave.space is one of the many independent Mastodon servers you can use to participate in the fediverse.
A fun, happy little Mastodon/Glitch instance.

Administered by:

Server stats:

232
active users

dragonscave.space: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.0-alpha.4+glitch

Public

@x0 Wow, this is really well done. I don't think I'd have noticed if you hadn't said.

Public

@simon What, that it's only one pulse channel? Yeah it's completely nuts. I imagine even C64 composers, who had to deal with some of the most limitations and invented the most convoluted voice-interchange schemes, would envy this.

Public

@simon You could play this on a Tesla coil or perhaps a PC speaker, though the volume bits would be a huge pain and probably not work on even older PC speakers. Might work on a coil though.

Public

@x0 Do we have the source for it somewhere?

Public

@simon If you mean the NSF, yes it was submitted to Famicompo. If it was made in a tracker though I don't have the module for that.

Public

@x0 Yeah I guess it would be NSF, sorry for the ambiguity. I haven't played with this stuff in years and never knew how to actually make them.

@simon You effectively need a compiler. Programs that take music in their own format and stick it in an NSF ROM, along with a replay routine. Assuming the NSF doesn't do crazy things like modifying the base framerate or adding too many chips at once, you can load the ROM onto a cart and play it on real hardware.

·Public·TWBlue
0boosts·0favorites
Public

@simon Presumably the compiler compresses the absolute hell out of the music first, and maybe expands macros or does some kind of space optimization involving subroutines, but the ultimate result is a bunch of static ROM including music data for the driver and the driver code itself, compiled into 6502 instructions.

Public

@simon Thus, NSF players have to act almost like complete NES emulators, including the main CPU and its audioo part, timing circuits including VBlank interrupt, and the like. They can be sparse about the PPU though. When people rip NSFs from games, they primarily rip the game's own reply routine and data, stripping extra junk, and possibly tweak it to conform to some constraints of emulation.

Public

@simon This is the same for formats like GBS for the game boy, GSF/PSF/SSF, SID for the C64, among others. This contrasts with formats like VGM, GYM, AY and YM, which are made by running the replay routine in an emulator and logging every write it makes to the audio chip with timing information. TO play it back you need only emulate the audio chip, and simply send all the register writes that the program did.

Public

@x0 I had no idea. I just assumed there was some kind of external music format. Makes me even more impressed that people have taken the time to rip this stuff apart and keep it alive.

Public

@simon And the trackers and other compilers to make purely custom music for the NES at some point had to have internal routines coded in 6502 assembly. E.G. FamiTracker, PPMCK. This is no different from the way it was before, all games with music had a playback routine. It's just these routines were written in the 2000s and 2010s.

ExploreLive feeds
About