I originally posted this at ChipMusic.org.
http://chipmusic.org/forums/topic/4281/ ... ibilities/
Basically the idea would be to allow the NES and Game Boy pseudo APUs to sing together.
I'll mirror the quotation here:
I'm no expert at the moment. I'm more of a dreamer with select knowledge. I talked with a few people in #NESdev to see if this would work and most responded positively or didn't shoot me down.
How many people have a RetroVision and a hacked Game Genie?
I guess the easiest way to start this off would be to program music using PPMCK and XPMCK since the xyntax is almost identical for the MML.
http://chipmusic.org/forums/topic/4281/ ... ibilities/
Basically the idea would be to allow the NES and Game Boy pseudo APUs to sing together.
I'll mirror the quotation here:
B00daW wrote:
Oh, Hi.
Well, it's not news that bunnyboy of RetroUSB fame has created the RetroVision (http://www.retrousb.com/product_info.ph … ucts_id=87) from his "because he can" department... Game Boy on the NES seems to be a neat idea for the NES fans who would just love to play a Game Boy game on the same system after playing a Nintendo game. However, don't we all just love chip music even more?
Let's stop bickering about which console has more sheer power or kick-ass, because we'll never reach an outcome of which sound chip sounds the best or which console has the greatest possibilities. ...Not.
The Nintendo Entertainment System wins again by one simple design choice of the RetroVision.
The RetroVision is basically Game Boy with a I/O (controller) wrapper intercepting from the NES to the GB and PPU (graphics) wrapper intercepting from the GB to the NES inside of an NES cart. The GB audio is also piped through the expansion port of the NES if you have done the expansion sound modification. If not, there is a 1/8" headphones audio jack on the side of the cartridge. The RetroVision wraps the NES I/O register $4016 to the GB controller register $FF00. Both registers are also R/W (or read/write). (The NES controller register can be written via binary strobe. -- http://wiki.nesdev.com/w/index.php/Cont … _registers. GB registers located here. -- http://fms.komkon.org/GameBoy/Tech/Software.html) What does this mean or why does this matter? Effectively the NES can stream data to the Game Boy. Let's use our imagination, shall we? Hrm...
Who would like the NES to control the Game Boy's audio? ...Now wouldn't we need NES code and hardware to store that code to control the GB while the Retrovision is also connected to the Nintendo?
Fortunately, it appears that bunnyboy at RetroUSB is working on a dongle cartridge for the NES. http://www.sealiecomputing.com/images/scoreboard.jpg (This cart in question currently takes score information from a game and uploads it to the Internet. Neat.) This means that a dongle cart can run host code in a specified area of RAM while the client cart connected to it is running its code as well. Remember the Game Genie?
Let's think about what we need for our NES+GB audio set up:
1.) 6502/2a0x host code on a NES dongle cartridge that contains a NES sound engine -- with its 2a0x instrument envelopes, sequencer and sample data -- also its accompanying GB instrument envelopes, sample and sequencer data; and a routine that streams GB sequencer data through the controller port to the GB after X cycles (depending on the code.)
2.) A Game Boy flash cartridge with Z80 code that contains a Game Boy sound engine and a routine that synchronizes with the NES, reads the GB instrument envelopes, sample and sequencer data from the NES controller port and plays the sequencer data after X cycles (depending on the code.)
Sounds complicated, but once it's coded and done, it's done. However there are just a couple minor snags to consider:
1.) Obviously the controller would be useless while GB music is playing, but could also effectively distort the GB sequencer data if you wanted it to for a few frames. The only way around this would be that the controller can only be used after the GB song data has been determined finished. Obviously looped GB audio accompaniment would make effectively using the controller impossible.
2.) There is a known hardware glitch on the NES that when DPCM (sample) data is being played that it corrupts reads to certain NES registers; one being the controller registers. (http://wiki.nesdev.com/w/index.php/APU_DMC -- See the bottom.) This is normally worked around for NES/Famicom software by reading the register 2 to 4 times before proceeding to make sure the right information is received. In this case the GB would have to read its controller register a few times before proceeding. My idea for this would be to either have no DPCM sample data on the NES end -- being quite the shame -- or streaming four duplicate nibbles (half bytes or 4 bits) of the GB sequencer information to the controller register from the NES. If the GB receives two equal nibbles, that it would wait the remaining cycles until the next nibble, and so on...
The main stress would be synchronization of the GB to the NES. Without it this wouldn't work. This means cycle timing on the GB end on its main loop timed to the NES code. Shouldn't be all that difficult. The second stress is that the sequencer data should not be played unless the GB instrument envelopes and sample data has already been streamed to the GB and written to RAM. Basically there would only be a short loading period. To summarize, first the GB would synchronize to the NES, the NES would wait X frames before streaming GB instrument envelopes and samples to the GB with a stop sequence at the end, once the GB has written them to RAM the NES waits X additional frames before streaming sequencer data to the GB, to which it begins to listen and stream the sequencer data in real time to its player routine. The goal being the NES is only writing and not checking on the GB to see if it has gotten what it needs. The NES would just make sure to send more than necessary while the GB continues to check that it's getting the right stuff.
So that about sums it up. If I was a better coder than a dreamer I'd do this myself.
Thoughts?
Well, it's not news that bunnyboy of RetroUSB fame has created the RetroVision (http://www.retrousb.com/product_info.ph … ucts_id=87) from his "because he can" department... Game Boy on the NES seems to be a neat idea for the NES fans who would just love to play a Game Boy game on the same system after playing a Nintendo game. However, don't we all just love chip music even more?
Let's stop bickering about which console has more sheer power or kick-ass, because we'll never reach an outcome of which sound chip sounds the best or which console has the greatest possibilities. ...Not.
The Nintendo Entertainment System wins again by one simple design choice of the RetroVision.
The RetroVision is basically Game Boy with a I/O (controller) wrapper intercepting from the NES to the GB and PPU (graphics) wrapper intercepting from the GB to the NES inside of an NES cart. The GB audio is also piped through the expansion port of the NES if you have done the expansion sound modification. If not, there is a 1/8" headphones audio jack on the side of the cartridge. The RetroVision wraps the NES I/O register $4016 to the GB controller register $FF00. Both registers are also R/W (or read/write). (The NES controller register can be written via binary strobe. -- http://wiki.nesdev.com/w/index.php/Cont … _registers. GB registers located here. -- http://fms.komkon.org/GameBoy/Tech/Software.html) What does this mean or why does this matter? Effectively the NES can stream data to the Game Boy. Let's use our imagination, shall we? Hrm...
Who would like the NES to control the Game Boy's audio? ...Now wouldn't we need NES code and hardware to store that code to control the GB while the Retrovision is also connected to the Nintendo?
Fortunately, it appears that bunnyboy at RetroUSB is working on a dongle cartridge for the NES. http://www.sealiecomputing.com/images/scoreboard.jpg (This cart in question currently takes score information from a game and uploads it to the Internet. Neat.) This means that a dongle cart can run host code in a specified area of RAM while the client cart connected to it is running its code as well. Remember the Game Genie?
Let's think about what we need for our NES+GB audio set up:
1.) 6502/2a0x host code on a NES dongle cartridge that contains a NES sound engine -- with its 2a0x instrument envelopes, sequencer and sample data -- also its accompanying GB instrument envelopes, sample and sequencer data; and a routine that streams GB sequencer data through the controller port to the GB after X cycles (depending on the code.)
2.) A Game Boy flash cartridge with Z80 code that contains a Game Boy sound engine and a routine that synchronizes with the NES, reads the GB instrument envelopes, sample and sequencer data from the NES controller port and plays the sequencer data after X cycles (depending on the code.)
Sounds complicated, but once it's coded and done, it's done. However there are just a couple minor snags to consider:
1.) Obviously the controller would be useless while GB music is playing, but could also effectively distort the GB sequencer data if you wanted it to for a few frames. The only way around this would be that the controller can only be used after the GB song data has been determined finished. Obviously looped GB audio accompaniment would make effectively using the controller impossible.
2.) There is a known hardware glitch on the NES that when DPCM (sample) data is being played that it corrupts reads to certain NES registers; one being the controller registers. (http://wiki.nesdev.com/w/index.php/APU_DMC -- See the bottom.) This is normally worked around for NES/Famicom software by reading the register 2 to 4 times before proceeding to make sure the right information is received. In this case the GB would have to read its controller register a few times before proceeding. My idea for this would be to either have no DPCM sample data on the NES end -- being quite the shame -- or streaming four duplicate nibbles (half bytes or 4 bits) of the GB sequencer information to the controller register from the NES. If the GB receives two equal nibbles, that it would wait the remaining cycles until the next nibble, and so on...
The main stress would be synchronization of the GB to the NES. Without it this wouldn't work. This means cycle timing on the GB end on its main loop timed to the NES code. Shouldn't be all that difficult. The second stress is that the sequencer data should not be played unless the GB instrument envelopes and sample data has already been streamed to the GB and written to RAM. Basically there would only be a short loading period. To summarize, first the GB would synchronize to the NES, the NES would wait X frames before streaming GB instrument envelopes and samples to the GB with a stop sequence at the end, once the GB has written them to RAM the NES waits X additional frames before streaming sequencer data to the GB, to which it begins to listen and stream the sequencer data in real time to its player routine. The goal being the NES is only writing and not checking on the GB to see if it has gotten what it needs. The NES would just make sure to send more than necessary while the GB continues to check that it's getting the right stuff.
So that about sums it up. If I was a better coder than a dreamer I'd do this myself.
Thoughts?
I'm no expert at the moment. I'm more of a dreamer with select knowledge. I talked with a few people in #NESdev to see if this would work and most responded positively or didn't shoot me down.
How many people have a RetroVision and a hacked Game Genie?
I guess the easiest way to start this off would be to program music using PPMCK and XPMCK since the xyntax is almost identical for the MML.
