Splitting hairs, but it's actually called the N163. N106 is a misnomer by early Japanese Nintendo emulator authors. Explanation here.
Regarding RetroVisions, whenever one is born a Game Boy has to die. And that makes me smile. 
81 May 26, 2011 10:02 pm
Re: RetroVision - GB for the NES (Oh the possibilities...) (7 replies, posted in Nintendo Consoles)
82 May 26, 2011 2:15 pm
Topic: CHIP MAESTRO - NES CART MIDI SYNTH (11 replies, posted in Nintendo Consoles)
There is a Kickstarter page drumming up support for Chip Maestro that looks like it's already mostly completed according to his project page:
Hopefully he hasn't bitten off more than he can chew since he's 10x over his original monetary goal already.
Looks like pre-orders of $50 get a cart sent to them; $150 for a development cartridge.
83 May 26, 2011 1:29 pm
Re: RetroVision - GB for the NES (Oh the possibilities...) (7 replies, posted in Nintendo Consoles)
Damn. My post looks like one of your manuals, Neil. 
84 May 25, 2011 8:42 pm
Topic: IT2TIA (Atari 2600) (3 replies, posted in Atari)
For quite some time now, us at Battle of the Bits have been messing around with GreaseMonkey's IT2TIA tool -- http://pubacc.wilcox-tech.com/~greaser/stuff/it2tia/ . It's buggy, not documented, and limited, but it at least works. What sets IT2TIA aside from what is currently available is that you can make TIA music by tracking the IT format. It also almost tunes notes by timed warbles between frequencies.
Here's an example of something I did for a One Hour Battle. It has a few skips in Stella and it's not perfectly tuned, but it works. Heck it was done in an hour as well.
Now, GreaseMonkey's tool IT2TIA requires a few things.
1.) Python
2.) An IT tracker. (I use ModPlug.)
3.) An Atari 2600 emulator. (I use Stella.)
No assembler is required.
You must already have Python installed and save it2tia.py.txt to it2tia.py so it can be an "executable". If you are running Linux or Mac OSX w/ Darwin, I assume you know how to use chmod; and won't be referencing you lot much from here on out. You also need the "sunds.bin". This is the assembled binary program itself. IT2TIA just injects the sequencer data. In summary, basically you just need those two things: it2tia.py and sunds.bin
If you execute it2tia.py by itself, it generates an IT pack with all the TIA waveforms; even the ones removed from Paul Slocum's Music Kit. Your next step is to start composing your song in your IT tracker.
Keep in mind that the TIA only has 2 hardware sound channels. You can use the xtest.it example found in the directory if you choose. Yes, I know that the xtest.it has 3 channels (one being unused), but channels other than the first two are ignored.
Inside it2tia.py is the strange README. Pasted here:
# IT2TIA converter by Ben "GreaseMonkey" Russell, 2011 -- PUBLIC DOMAIN
# You will need the IT2TIA driver (sunds.bin).
#
# Some requirements:
# - Full channel volumes, tempo 150.
# - Mono, samples, compat Gxx off, old effects off, Amiga slides.
# - Bxx on last pattern played.
# - If it's not an effect, don't put it past the second channel.
# - Same goes for effects that affect pitch/volume/waveform.
#
# Notes:
# - YOU MUST EXPLICITLY USE Bxx TO LOOP BACK.
# - Cxx should only be C00 and NOT in any other form.
# - Txx WILL NOT WORK. TEMPO MUST BE 150.
# - Same for Pxy, Xxx, Yxy (no panning).
# - Same for Mxx, Nxy, Vxx (no multiplies, so no chvol/glbvol).
# - Same for Oxx, Zxx, SAx (no sample modification).
# - Same for S3x, S4x, S5x (triangle mod only - also S5x == panning).
# - Same for SBx (ruins linearity + this converter won't like you).
# - Some stuff has not been implemented yet. Check this script.
# - There are no voleffects other than "set volume" at this stage.
# - Each pattern MUST HAVE THE SAME SPEED INFO EACH TIME AROUND.
# - Don't use separators (+++) in your orderlist, it's STUPID and IT'LL BREAK.
# - PATTERNS WILL PLAY THE SAME WAY EACH TIME AROUND.
# If you want anything playing at a different speed or something,
# copy/paste into a new pattern.
# By the way, playback ordering pertains to the orderlist.
# - Don't put too much on the last tick of a pattern.
# This is a converter limitation. YOU WILL LEAK EXTRA TICKS INTO THE PATTERN.
# In fact, it's best not to put too much on ANY tick.
#
# Space specific notes:
# - Orders + (Patterns * 2) <= 256.
# - Patterns cannot change info more than 256 times.
# You may need smaller patterns.
# - Try not to use vibrato (Hxy) too much. (NOT IMPLEMENTED YET)
# - Avoid using Jxy ESPECIALLY. (NOT IMPLEMENTED YET)
# - Unused patterns will be ignoredIn summary it supposes that you are familiar with IT effects commands, it tells which ones are supported, and that tempo 150 is necessary,
One thing that this doesn't tell you is that the sequencer data is very bloated and you will soon run out of the Atari 2600's 4K ROM space very quickly if you create songs that are too complicated.
Once you've composed your song, the syntax for outputting to Atari 2600 format is: it2tia.py input.it output.bin. The input.it is the filename of your IT module. The output.bin is the Atari 2600 program that's ready to be run in an emulator or a Melody/Harmony cart. I wrote a batch file to do this for me:
@echo off
it2tia.py tiapack.it test.bin
You can either add a line for Stella to run your binary or create a shortcut of Stella in your directory to drag the binary file to to execute your song.
A couple things.. If it2tia gives you an error, to be honest, I told you it was buggy and even the code says to talk to GreaseMonkey about the issue. Try to keep things simple and follow the guidelines provided. If the track assembles properly without errors but it does not play audio properly, you have run out of ROM space. Again this is an issue with the code.
IT2TIA is a fun little program that I hope gets tested and bugfixed by issues spawned from this thread.
Cheers, GreaseMonkey!
85 May 25, 2011 3:14 am
Topic: RetroVision - GB for the NES (Oh the possibilities...) (7 replies, posted in Nintendo Consoles)
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?