Search options (Page 18 of 39)

With a midi clock higher or lower, you change the Tempo of the playback from what it sounded like in FamiTracker. What I was trying to say was: the standard playback rate is equal to 150 BPM regardless of the NSF's internal tempo. The recommended FamiTracker setting is to set for 150 BPM and adjust the Speed for the desired Tempo. This way the NSF matches with the NMI calling frequency. Now FamiSlayer is not tied to the NMI so even if the NSF was written for a Tempo of 80 BPM, it will only sound like that internal Tempo with a sync pulse stream equal to a clock BPM of 150.
How this will effect you is if you are syncing to a PC or LSDJ they should be close to that 150 BPM and the NES will sound normal. But if the master is running at a much slower tempo, like 75 BPM, the NSF would play back slower (not Pitch shifted. just much slower). So a 1/4 note will be as long as a 1/2 note and Bars will be longer. The same would happen in reverse for like 300 BPM.
So when composing you will have to preview on the HW to get the sound you want at the much slower or faster Clock BPM you'r using. May be able to adjust the Speed setting in FamiTracker to raise the effective tempo within the NSF, for when it's played slower.

With the CD4021. The GamePad circuit: a open button has the pin pulled to 5v, pressing the button = GND. If you use a bare 4021 you could drive it's pins with TTL signals, but active low logic. If you mod a GamePad you need to disable the Pull-Up Rs or use Open Drain. Most uCs don't have Open Drain outputs so we can simulate with the Port direction trick. Also by using the Open Drain, you can still use the GamePad for manual input.
The NES reads the GamePad with a SPI like interface. To directly connect from the Nes to the uC you need to set it as a SPI slave. I think this should be doable but the extra expense of a 50 cent chip to buffer things seems OK also.
Code wise there really isn't much difference between Set/Clr the Port.Pin direction bit or the Port.Pin data bit.
Yogi

Well I was thinking that by watching the bytes sent out (if midi Thru is part of Arduinoboy code) a sync function would work with both the Arduinoboy in Master or Slave mode. Otherwise you will only output sync when the GB is slave, which may be fine also (?).

The basics of the timing:
Most NSFs are played within the NMI at a refresh of 60Hz. which works out to 3600 calls to the play frame address per Min.
This is the same as a Midi clock running at 150 BPM. The midi Clock messages occur at 24 ppqn, so at 150 BPM: 150 x 24 (ppqn) = 3600 tick bytes per Min. What I'm driving at is with a Clock running at 150 BPM your NSF should sound 'normal'. So there is no heavy math in the firmware, just detect the Midi Tick byte and pulse the trigger button.

The other issue is the connection to the CD4021 in the GamePad. The Buttons are active low logic; I.E. when 'Open' a 10K R pulls the pin high, Closed to GND. So to drive the 4021 pin we need to setup our uC for Open Drain: a 1 = Pin as Input, 0 = active GND. To press a button we Output a 0 and to release, idle the Pin as a Input (neither sourcing or sinking);
1. During Init, set output Pin latch data to 0 for each GamePad button we want.
2. Then switch Pin between Input and Output for triggering a button (output to trigger, input for release). Beware: with the PIC, there are issues with the Read-Modify-Write structure of the ports, but I don't think the AVRs suffer from this.

For Start/Continue/Stop just need to switch the 2nd Pin direction according to the received message; Start/Continue = button pressed, Stop = Button released. FamiSync handles this manually but its a easy change.

The Tick pulse width is still up in the air, but I am starting with 2-3mS. It really depends on the NES code; how responsive the code is reading the controller. Once I get all the hardware running together I'll have a better idea.

The ASM  for my 'F628 is like 400 words and uses about 5 ram bytes ATM. So I would guess the Arduino code would be similar.
Yogi

Hi mOOdawg
Don't know if you are aware of FamiSync by HeavyW8bit. it's a mod to VegaPlay by No-Carrier. Both versions allow you to load a NSF file into a NES prg rom that can be flashed to a cart (or used with a EMU or PowerPak).
http://www.heavyw8bit.com/famislayer.php
FamiSync adds control of the NSF frame playback as well as transport. The sync is triggered by input to a controller button. So by adjusting the rate of the pulse stream to the GamePad you can change the Tempo of the NSF.

The MCTRL is configurable so it should be able to do the Midi Clock to Trigger conversion (it may already be an option, I don't know).
Also uXe has a Arduino shield, FamiDi, that allows midi messages to trigger GamePad buttons much like the MCTRL. This also could be used.
http://chipmusic.org/forums/topic/12998 … interface/

If you are looking to use a NFS directly on the PowerPak you would have to mod the NSF mapper code to allow sync input I believe. And Pulsar may use a different technique, don't know the specifics they worked out (Pulsar has a refresh rate of 180Hz where as most NSFs are 60Hz)
yogi

From Farris in this thread http://chipmusic.org/forums/topic/12762 … rt/page/6/

yogi

  As with all systems, a hardware interface will require software to run it   Haven't seen any SNES softs for Midi/Sync, but there is a SNES tracker in the works (search the forum).
  The APU could be tricky for frame by frame playback. It's a sub processor that gets programmed by the main processor, then plays the song till a new song is loaded. To allow control over playback, the main CPU would have to interact with APU on a more intensive basis.
  Not saying that it can't be done, just that this is not how games handle it and there hasn't been much interest in the SNES for chiptunes Too many roadblocks, which is a shame. The good news is it seems like more people are looking closer at the SNES and tools are getting better.
yogi

I agree that it's unlikely that all your optos are bad.
For the 6n138 circuit, I refer to the MidiBox.org's reference design. Your Resistor values may very, but should be simular to these.
On the Midi side:
PIN 4 of the midi socket goes thru a 220R (Red, Red, Bro) to PIN 2 of the 6n138
PIN 5 of the Midi socket goes to PIN 3 of the 6n138
A 1n4148 is connected between PIN 2 & 3 of the 6n138; Cathode (bar) to PIN 2

On the TTL side of the 6n138:
PIN 5 to GND
PIN 6 to Rx in; with a 1.2K pull-up (Bro,Red, Red; don't confuse with 220R Red, Red, Bro)
PIN 7 thru a 5.6K to GND (Grn,Blu, Red)
PIN 8 to Vcc

You should not have a GND from the Midi cable connected to anything. The Arduino/6n138 and GB should have a common Vcc & GND.

When sending Midi notes, should see lower then +5 V on midi socket PIN 5 or 6n138 PIN 3; most DMMs aren't fast enough to detect the serial bit transitions; just a lower average voltage. Should be lower with higher Midi traffic. A logic probe or a scope should detect the clocking of bits. If no changes are detected, suspect your cables/socket/KB
IF you see incoming Midi bits and you don't see output transitions at 6n138 PIN 6: problem with opto. If you have the transitions on the TTL side @ PIN 6 but no response from the Arduino, suspect wrong wiring, Arduino pin or firmware.

This is all pretty basic, in most cases it 'just works' so in your case it's prob something simple that's been overlooked ( had this bite me a few times)
yogi

Yea it's always the little things
yogi