[NSF type files]
@>Well, you can do it both ways. Essentially what you're doing is searching
@>through the 6502 code to spot tell-tale writes to the sound registers, which
@>on the NES is $4000-$4013 and $4015. You can do this either in a hex
editor,
@>by disassembling the 6502 code from an NES ROM, or by tracing through the
code
@>in an emulator (like NESticle.)
On the PC-Engine, it's $0800-$0808 (mapped from segment $FF to the
$0000-$1FFF range by convention).
@>Almost all games play music by calling an initialization subroutine to
start a
@>tune, and then each VBlank, calling a play routine to update the sound
@>registers. Ripping music code involves finding the entry points for these
@>routines and extracting the relevant code to a file.
It will be the same for PC-Engine. The PSG player, I believe, is standard
on all games - or at least most of them. It is also built-in to the CDROM
system card, so PSG music on CDROM's should be pretty easy to find by the
use of a standard PSG registration call.
@>> @>Unfortunately, I don't know 6820 assembly or the
@>> @>PCE's memory map, so I can't start with this right now.
@>
@>> The PCE is more similar to the NES than you expect. 6280 assembler is
@>> essentially 6592 with a couple of extra instructions. The memory map may
@>> be different from NES, but the segmented model is basically the same -
it's
@>> just more regular (imagine not worrying about 200 mappers).
@>
@>That is both good and bad. NES games usually keep their music code in
memory
@>all the time, and the game code is switched in/out in a different bank. I'm
@>just speculating, but a TG game might have its music code spread over
several
@>banks.
No, not really. I did some (small) amount of research on this when I wrote
my emulator a few years ago (has it really been that long ?).
The music usually resides in its own segment by itself, which will always
get mapped to the same memory address range. This gives 8K of bytecode,
which can store several songs.
The sequence is like this:
1/ Call to PSG register routine includes segment number where music is stored.
2/ Each vsync thereafter, PSG player is invoked as part of vsync service
routine. It does the following:
a) map the music segment
b) determine whether timing of individual notes is complete, and if so,
update pointers (per voice) in RAM and service next PSG-code function (they
include goto's and sound-modification functions as well as note/duration
bytecodes).
c) hit the PSG registers appropriately
d) unmap the music segment and re-map whatever else was occupying that
memory range
>> Well certainly discussing file formats can't be all that harmful. Or even
>> techniques for finding PSG code.
>
>Well, I haven't boned up on the TG registers, but usually it involves finding
>in code the writes to the sound registers. Most "good" programmers just
write
>directly, but I have seen in my ripping travels "bad" programmers who use
>zero-page indirect addresssing to write to the sound regs, which is harder to
>trace. Anyway, somebody already has done what I've mentioned and ripped the
>music from Galaga '90 into a PCE ROM (which I've seen floating around). Now
>all we need is the same thing done to the other great games. :-)
I believe the PSG music processor was essentially a licensed piece of code
from Hudson, descended from a NES PSG player with some small modifications
so that this code didn't need to be rewritten time and again. Also, I
believe they had some rudimentary tools for MML by the time people were
developing for the PCE, so it would make sense to standardize on a common
PSG player.
That said, I'll bet somebody somewhere still tried to write their own PSG
player and language.
- Dave