| Level 0 | Level 1 | Level 2 | Level 3 | Level 4 |
| Level 5 | Level 6 | Level 7 | Level 8 | Level 9 |
| Level 10 | Level 11 | Level 12 | Level 13 | Level 14 |
| Level 15 | Level 16 | Level 17 | Level 18 | Level 19 |
LEVEL 16 Tokuma Shoten - Clox - Famimaga Disk Vol. 4 FDS
Now is the time to take the next step in FDS NSF ripping. We are going to use the same method to extract an NSF from the disk as we had in level 15, even though you could rip the NSF from an emulator dump. We are dealing with a one sided disk that contains all of the data of the game, including the sound driver. Before we get started, let's examine how interrupts are handled in a FDS game. Interrupts are still pointed to in the same way, with the exception that they are dealt with indirectly. FDS Interrupts, as far as I know are always located at the same address. Here they are as follows.
While you're at it, open a debugger and set a NMI execute or PC same breakpoint for the address $E18B, in the game Clox - Famimaga Disk Vol. 4. Here is the code that you'll get.
$E18B:2C 00 01 BIT $0100 = #$C0 $E18E:10 08 BPL $E198 $E190:50 03 BVC $E195 $E192:6C FA DF JMP ($DFFA) = $D8A8 $E195:6C F8 DF JMP ($DFF8) = $0000 $E198:50 03 BVC $E19D $E19A:6C F6 DF JMP ($DFF6) = $0000
More than likely the code will jump to $D8A8, in fact it does when I stepped the code. This NMI routine will lead you to the play code entry point somewhere. You could have easily also backtracked the stack in order to find the play address as well.
Now it's time to get started in the ripping process. As we had done in level 15, we will use FDS Explorer to examine the disk and to extract the file(s) that contain the sound driver. Here is the list of files to browse.
| File # | ID | File Name | Address | Size | Type |
|---|---|---|---|---|---|
This time we don't have a file that is named sound, so it's not going to be so easy of a job this time, still not too bad though. Like level 15, this game has a Boot ID of 15, so examine all of the files with an ID 15 or less that are labled as PRG. If you had done any debugging prior to opening up this file in FDS Explorer and I suggest that you always do this, you would know that most if not all of the sound driver is located in the $7xxx range. You can also examine the disassembly of each file in FDS Explorer. Look at the list and determine which file has the $7xxx range included. File #1, ID #0, LOGODATA, starting at $7020, size 11488 is the file that we are looking for. Extract this file as a bin into your NSF project folder.
First thing, before we slap a header on the file is that we will padd the beginning of the bank, get used to it, you may have to padd banks in other rips. This file's address starts at $7020, what we want to do is for this file to start at $7000, so you need to insert 20h at the beginning of the file. When you're done, if the first byte of the unmodified file still lands on address $7020, then you done the job right. There are other rips that you may have to padd the file at the beginning or end. The reason why you may have to do this is because an NSF is like a ROM file, it uses banks and not files like an FDS disk does. You may want to know what padding is, well padding is a bunch of bytes to fill in space that you won't be using and to fill up the rest of the bank. Commonly, 00 or FF is used for bank padding. 00 is often used in FDS games when it's an area that will be modified by a PRG RAM file that is loaded from the disk. I might mention that the FDS since it uses RAM instead of ROM for it's program, this means that the code and data can be self-modifying, anything in the $6000 - $DFFF range can be changed at anytime.
Slap a NSF header on your file, if you had done some debugging you would deduce that your load/init/play addresses would be the following, $7000/$7447/$747B, in addition to the init address, you have a bootstrap at $7400, $E0 is used to switch the tune. However, you can't use any of these addresses because you want to conform to the NSF spec and to make the NSF compatible to as many players as possible. Especially the load address has to be $8000 and/or greater. All the main address calls have to be equal to or higher than $8000, in the range of $8000 - $FFFF. We can do this by using the bankswitching bytes in the header and writing some simple code in the init.
As I had listed in level 12, Optimization, I will list again the bankswitch bytes and what they correspond to, with only one difference for FDS NSFs. We will use the registers as though we were optimizing, it's a trick.
76h and 77h can be used for both addresses, normal bankswitching and FDS bankswitching. What are going to do now is determine what banks are being used in this NSF. The following are used - $7000, $8000, $9000 currently before optimization. The three banks are also in order starting with the $7000 bank. We set the load address at $8000, and then we set the bankswitch bytes in the header as follows: 01,02,00,00,00,00,00,00. This allows you to load below $8000, with minimal bank shuffling in the ripping process.
Now it is time to write the init code, you must find some space and I suggest that you do so higher up in the $8000 bank or somewhere in the $9000 bank. Here is how I suggest that you design your init code for this game, since you must also load the FDS $7000 bank into memory. Before we go any farther, a little about the bankswitching registers for FDS NSF, keep in mind that the bankswitching registers are a little different than normal NSF bankswitching registers, although you may still use the normal mode if you do not need to load anything below $8000.
Now that you see all of the bankswitching registers, only the FDS registers will be used and not for bankswitching but for loading in banks that are below $8000 in this level. Now I will show you some basic code that I will use for this game.
PHA LDA #$00 STA $5FF7 ; load first bank in the file to $7000 JSR $7400 PLA TAX LDA $tune_index,X STA $E0 JSR $7447 RTS
One more thing before we end this level. This is one method of loading banks below $8000, there are other methods depending on the game that you rip. You will notice that this game does not have FDS expansion sound, but the FDS byte is set in the header. The FDS header byte setting serves a two-fold purpose, one of them is obvious and the other is to use FDS bankswitching. So a rip may have the FDS set in the header but not have any expansion sound, chances are that this tune loads banks below $8000 and/or is in fact bankswitching. It is possible that a game has expansion sound, loads below $8000 and is also bankswitching, so be aware of this fact.