chipmusic.org is an online community in respect and relation to chip music, art and its parallels.
You are not logged in. Please login or register.
ChipMusic.org / Forums / Nintendo Consoles / PC->NES Transfer Tool + FaMI - Family MIDI - [Wiki Updated]
Now if only it was plain microcontroller code instead of Arduino it'd be less expensive.
http://www.moderndevice.com/products/rbbb-kit
RBBB's are $12.50, man.
Yea you can always jsut make your own pcb and use a dirt cheap atmel. Thats as plain as you can get,
arfink wrote:Now if only it was plain microcontroller code instead of Arduino it'd be less expensive.
http://www.moderndevice.com/products/rbbb-kit
RBBB's are $12.50, man.
Ohhhh, nice stuff! Welp, the Munchausen may have to ship with one of these, since it's so awesome. 
Well, 25 kbps is slower than the 57.6 kbps can easily do in software on the NES, but the big advantage is that you get buffering, critical for music players and such. Is this interface synchronous, where the Arduino is clocked by the controller strobe rather than requiring cycle-timed NES code when reading? You can PM me if my questions are cluttering up your thread, BTW.
THIS IS IT.
How well does this thing receive MIDI messages? I heard MIDINES has trouble receiving really fast changes...
Well, 25 kbps is slower than the 57.6 kbps can easily do in software on the NES, but the big advantage is that you get buffering, critical for music players and such. Is this interface synchronous, where the Arduino is clocked by the controller strobe rather than requiring cycle-timed NES code when reading?
The transfer rate was much faster but at some point in development I had a couple of glitchy tiles so I added a delay subroutine with about 30 NOPs out of frustration. I'll reduce/remove the routine when I get home and take another capture.
But yeah you don't have to poll the controller port (no cycle timed code!) - the arduino responds to an STA $4016 by putting the next byte in the buffer out on the line and a LDA $4017 will clock out the next bit. It took a lot of wrestling with the atmega interrupts to get this to happen! There is a 128 byte buffer for the serial messages from what I understand - the serial is actually setup as 57600 to the UART but it seems that the NES has always pulled the messages out fast enough that it never has overflowed.
How well does this thing receive MIDI messages? I heard MIDINES has trouble receiving really fast changes...
Extremely well - I ran my guitar pro stuff through it with a bunch of chords across 3 instruments without any delay (played out as consistently tight arpeggios) - this was with the PPU disabled so I'll have to stress test it again with the new visualization stuff. I've never used a MIDINES but I'd love to see how they compare side by side. Here is an early video of testing for you.
Last edited by Batsly Adams (Jul 30, 2010 3:43 pm)
What do you think about the machine receiving a full MIDI instrument dump on each sequencer step, for each channel?
Yes, I am extreme
What do you think about the machine receiving a full MIDI instrument dump on each sequencer step, for each channel?
Yes, I am extreme
Uh, that'd make alot of MIDI stuff choke, just saying.
akira^8GB wrote:What do you think about the machine receiving a full MIDI instrument dump on each sequencer step, for each channel?
Yes, I am extremeUh, that'd make alot of MIDI stuff choke, just saying.
And this is why I have not bought any MIDI device like this yet, like the MSSIAH.
When you use a tracker in one of these machines you can change "instruments" on each sequencer step, on each channel, whereas with MIDI this is a fucking pain in the ass.
I wonder if the whizzes here can come up with a solution to this.
Maybe one can dump to a part of memory instrument definitions, so all you have to do is dump them to the device on startup of your tune or something (using sysex?), and then you use program change commands (one command, once) to change instruments.
Batsly? Don?
Being limited to one single sound definition on each channel at once makes this very very limited.
Last edited by akira^8GB (Jul 30, 2010 5:47 pm)
I really think the key is having tracker tables run ON the cart. You then just have midi only controll patch changing and midi notes and light cc. All the really heavy refresh rate synced sound design would be done on the art IN the rom directly. Less cycles for viz but I think it would be better for sound design nerds..
What do you think about the machine receiving a full MIDI instrument dump on each sequencer step, for each channel?
Yes, I am extreme
With midines you can do this jsut once to set the basic instrument, then jsut need to send it again when it updates. It sucks if you want envelope based tables but works fine for set it and forget style instruments.
I really think the key is having tracker tables run ON the cart. You then just have midi only controll patch changing and midi notes and light cc.
That's kind of similar to what I said xD
If you can make instrument definitions, say, with an editor on the computer, then save it and UPLOAD this to the cart, and you can upload, I dunno, 128 instrument definitions, you can change them on the fly using program change and adopt tracker-like functionality without wasting cycles with unnecessary MIDI data being sent.
herr_prof wrote:I really think the key is having tracker tables run ON the cart. You then just have midi only controll patch changing and midi notes and light cc.
That's kind of similar to what I said xD
If you can make instrument definitions, say, with an editor on the computer, then save it and UPLOAD this to the cart, and you can upload, I dunno, 128 instrument definitions, you can change them on the fly using program change and adopt tracker-like functionality without wasting cycles with unnecessary MIDI data being sent.
This, to me, doesn't seem like it'd be too big of a deal. Now, I'm not the programmer, so I'm not certain, but this kind of thing would already have to take place for stuff like NSF playback anyways, so setting up some presets and then having a way to quickly trigger them seems like it'd be perfectly doable.
Hey guys - made some major progress today.
I've sped up the transfer rate considerably (>100Kbps) by optimizing the arduino code / unrolling the NES controller loop.
I'm hoping that people will develop stuff for this. You really only need to be able to program something that can write to the serial port which can be done really easily with something like processing. Everything works on 2 byte messages formatted as ([command] [value])- I've put up a list of the ones I'm using so far.
PC->NES Transfer Tool Opcode List
For instance - some pseudo code for writing a message to the screen.
String message = "Hello world!"
// Set the VRAM address to the top left of the name table (0x2000)
Serialport.write(0x01, 0x20); // 0x01 -> Set PPU MSB
Serialport.write(0x02, 0x00); // 0x02 -> Set PPU LSB
for(int i=0; i < message.length; i++)
{
Serialport.write(0x04, message[i]); // 0x04 -> Write tile to screen with blip - increment to next position
}That's it - the program gives you full access to the PPU/APU (sort of like an API) so you can pretty much do whatever you want with it. Should be handy for VJ applications - back to working on FaMI!