257

(54 replies, posted in Nintendo Consoles)

You know, I have been kicking around the whole issue of 'the cable'. Finding a source of NES cables is like impossible, so that leaves recycling old (new ?) controllers or extension cables.  I had noticed at INL's site he has CD4021 pulls from his USB mods so he may have cables also ( will have to ask him).

But then I was thinking of a internal mod with just a ribbon cable to the port 2 motherboard header. Downside is you can't move the interface to another NES and may interfere/disable a GamePad on port 2. For my case atm, I have a cable setup for prototyping but once it's done, I think I'll do a internal install. Would also cut down on extra gear, like in your case.

On a side note about the cable, you can't solder the wires in the (original) cable, so you have to use crimp connectors. They used a copper foil/nylon conductor, like a lot of headphone cables do. Don't know about  after market GamePads.
Just a thought
Yogi

258

(54 replies, posted in Nintendo Consoles)

As far as I can tell Pinout and Max operating Voltage range seems to be the major difference, but Functionally they are the same. And of course the 'HC165 is a newer chip and there is the general family differences between 74HC and CMOS.
  For these kinds of designs, if you are recycling a GamePad's cable, might as well recycle the chip also.
yogi

259

(54 replies, posted in Nintendo Consoles)

m00dawg wrote:

Well damn that all sounds nifty! There was user MidiBox project where the dude made a AY-3-8910 synth so that may exist as an option in the interim. But yeah if 5B is attainable that would be a much more integrated solution.

I got a MB AY almost done, waiting on parts for a CS (Too many projects!!!)

m00dawg wrote:

For now, though, just being able to sync the NES would be, in it of itself, quite fantastic, sound chips aside.

As an aside, really bummed to see RetroUSB doesn't carry much stuff now. E-mailed him to see if that's just temporary, but haven't heard back yet.

Yea, syncing the NES seemed like the highest priority for me atm.
About RetroUSB, BunnyBoy had stuff listed as "out of stock", but about 6 mos ago dropped them from the site ?!?! Bummed too.
yogi

260

(54 replies, posted in Nintendo Consoles)

m00dawg wrote:

On the PowerPak, switching ROMs requires a power-cycle (reset won't do it) but otherwise it's easy to do. That said, I would probably setup ROMs on the PP just like I would a flash cart - namely try to fit as many on a ROM as I could, keeping with song orders and things. An added benefit is emulation of extra sound chips (a shame those chips can't be had more easily hmm).

So I guess to answer your question, on the PP the workflow doesn't really have to change all that much compared to a flash cart.

OK

m00dawg wrote:

Having said all that, damn the stuff at Infinite Nes Lives is awesome! Dude even provides the Sunsoft 5B, although while I thought Famitracker implemented it, it looks like that hasn't been done yet. Still that's very cool!

Oh Yea, I've been eyeing the SunSoft cart for awhile, but kind of waiting till FamiTracker finally support's it ( I think most of the drivers and code are already in place). He's also been working on a Hardware NSF mapper cart (They used it for the 2A03 Puritans Album just released). not sure of all the details, but would allow loading of bank switching NSF. smile
yogi

261

(54 replies, posted in Nintendo Consoles)

m00dawg wrote:

We do live shows so I tend to be in favor of what requires less work. What I saw of VegaPlay was pretty well in line with what I would need I think. I'd probably do a mix of having sub-songs on an NSF and multiple NSFs.

Better might be kind of relative. My band-mate likes the idea of physically changing out cartridges to make it look neat during a live show smile Not sure how that relates to flash carts save for saying if all our music won't fit on one, we'd have to switch them out. In actuality, that's not a big deal - we'd just coordinate our breaks so we switch carts then.

Well, not having a PowerPak it's hard for me to judge how hard or easy switching from song to song is.
With my mod you could have 7 - 32K NSFs in one file, so less cart switching IF you use carts smile With a PP it's still button presses but if your band changes up your set, might be better to have NSFs separate (?)
Will add my changes back into FamiSlayer anyways at some point, choice is alway good smile

m00dawg wrote:

So I guess for me it doesn't matter much. Curious - what flash cart do you use? And, on that note, I noticed RetroUSB no longer carries plastic cases or their MMC board. I was kinda bummed out by that. Are these found elsewhere?

My gut feeling is the same as yours - that PowerPaks likely outnumber flash carts and other solutions. For us? We could easily do either, though.

A guy over @ NESDEV.com, INL, is producing Flash carts and a flashing system for 'Cart Edge' re-flashing ( so much better then pulling chips )
His Store:
http://www.infiniteneslives.com/products.php
He is also working on a molds for cart cases, may be this summer (?)
I have a couple of SXROM carts, with PR8 and Pulsar and just got a SNROM for this dev stuff.
yogi

262

(54 replies, posted in Nintendo Consoles)

m00dawg wrote:

Cool beans! I noticed the DropBox link is really just for the compo stuff you mentioned on NESdev? Guessing you're still working on the code and haven't released it yet? smile No rush if so, but when you do, I'd be happy to test it out!

In the interim, I may give FamiSlayer a go, but man not having to do any removing of headers and things is really tantalizing! So looking very much forward to seeing what you come up with, for both that as well as sync.

So let me ask for your opinion
Do you feel it is easier to manage individual NSF as separate .NES files on a PowerPak, or have a multi NSF .NES?
I was thinking that a multi cart would be useful for a Flash cart based musician, but there are prob way more with PowerPaks then Flash carts, so after I wrap up the current build I could update the basic FamiSlayer to simplify it.
yogi

263

(54 replies, posted in Nintendo Consoles)

m00dawg wrote:

Maybe it was pulsar? I dunno some NES program I ran into had trouble due to using an odd mapper. That said, your version of VegaPlay (http://forums.nesdev.com/viewtopic.php?f=6&t=11322) /does/ indeed work with PowerPak. I used your example .NES and I noticed some songs would cause the NES to freeze. I'm guessing it's because the NSF didn't actually have song data there or something?

I don't have a 6502/NES toolchain setup yet so that's next on my list, at which point I can do additional tests. But apart from the freezing issue, yeah it worked like a champ! I'm guessing any sync additions you plan on adding should work fine too, but of course if you add them, let me know and I can easily test them on my PowerPak.

Could be Pulsar, it uses SXROM which is an extremely rare mapper ( only used in one Famicom title)

Good to hear the mod does work on your HW smile Yea some of the NSFs I grabbed are 'weird'. I think they use a different tool chain/tracker and stomp on some of the ram I'm using. FamiTracker NSFs work fine so not too motivated to find a fix for every driver out there. VegaPlay has the same issues outlined in the release notes.

The tool chain is a breeze, the release package will have a copy of ASM6, the compiler. No install, just configure the user config file and run the .BAT
Yogi

264

(54 replies, posted in Nintendo Consoles)

Hummm. not sure, I don't have a PowerPak, just flash carts. But FamiSlayer should work (?)  PowerPak can run a NROM or a SNROM .NES? These are like the most common mapper.
For FamiSlayer and my mod file, there isn't any HW mods or such. The Sync converter just plugs in a controller port and it's just "pressing buttons"; it's all a software thang' on the NES.
Hope there isn't an issue with PowerPaks, can't imagine what the issue would be ?!?!
yogi

m00dawg wrote:

Well that should make things reasonably easy! I need to wrap my head around some of this theory more, but that makes the solution potentially pretty straightforward.

Yogi, I'm not too familiar with the Pic family apart from with the MidiBox stuff (where many of the details are covered up) so I don't know how helpful I can be smile But if you do get that design off the ground, I'd love to do what I can to help test it!

For me Arduino was just an easy path to entry and I think augmenting ArduinoBoy to send some pulses out to some unused pins is probably within the realm of possibility as has already been discussed. So I may play around with that just to see where that goes while you're working on your PIC solution.

Do keep me posted though! At this point, I'm more after a solution that would work over one that is simply one I built. The net goal is being able to use the NES again as soon as I can.

You Betcha! ATM: HW built, only have small changes to make with the PIC and NES code. Want the keep the HW comp with the basic FamiSlayer package as well as allow advanced control for the SNROM ver .

Pad 1 controls unchanged.
Midi control on Pad 2 ATM:
Pulse Start on Midi Clock Ticks
Press or Release A on Midi RTM Start/Continue or Stop (Sync accepted by NES code only with A pressed)
Pulse Left for Frame Re-start on Midi CC#
Pulse Right for Frame FastFWD on Midi CC#

So it's moving along, will keep you posted
Yogi

So to match an Ext Midi Clock:
Reset the "Engine Speed" in FT to:
(BPM x 24) / 60 = F in Hz  This will match the Ext Clock (@ 24 ppqn) and the NSF will sound the same as in FT. The Internal FT "Tempo" and "Speed" setting can also be used to fine tune the sync match smile
Yogi

Been doing some searches, found this http://famitracker.com/wiki/index.php?t … _and_tempo

FT Wiki wrote:

Another option is to use a user-defined clock speed, but then you have to modify the calculations above to determine which tempos are acceptable under which clock speeds. One drawback of this method, though, is that few NSF players support custom clock speeds, so NSF export is compromised.

This may overcome the limitations we've been discussing (?)
yogi

EDIT: Just did some basic tests in FT.
Under "Tracker" tab, "Engine Speed" set to "Custom"  to adjust the NSF playback speed.
This doesn't effect the preview in FT but changes the exported NSF's speed. So playing in Nestopia (@ 60Hz) it sounds slow or fast, but when using FamiSlayer and a Ext Clock should sound the same as in FT!
Just have to work out the freq of the Ext BPM to set the engine speed.

m00dawg wrote:

I am eyeing MCTRL actually, along with Pulsar. The reason I liked going the FamiSlayer route is I find FamiTracker a lot easier to work with than, say, LSDJ. The downside is I don't have sync when composing songs like I do using LSDJ, so composing is a bit non-linear when working with other synths.

Yea, composing on a native tracker is fun, but cross platform tools have a better workflow, imo. Full key board and such.
ATM only PR8 has been extended for sync control; I would love to see Pulsar with sync as well! ( Hey Neil? Hint Hint)

m00dawg wrote:

On that note, though, the idea of using a sort of BPM track to send to the NES seems workable. If that works, though, it seems like sending the MIDI clock through and having a bit of code on the uC could do the same affect but without having to toss that in every-time? I've had to do the sync track for our drum machine (which is really just a glorified click for us) and it's a bit annoying to setup over just having a clock.

A Midi Clock to Sync converter is the easiest user solution but requires some firmware development time. With just a 1:1, Clock to Sync24, conversion it may be useable for allot of tempo signatures; the down side is using FamiTracker to compose. A track will sound different during playback then when you compose it. But you may be able compensate with FamiTracker's settings.

m00dawg wrote:

So, since we're now including MCTRL in the discussion - how easy of a modification might that be (DIY or otherwise)? One of the reasons for going the Arduino route was really just to reduce the number of stuff we have, particularly during a live show. If one box can sync both the GB and NES, it would be really convenient. But otherwise, MCTRL is there, works, I could look at using Pulsar with it - so the only gap is the discussion on syncing with a MIDI clock using FamiSlayer or some other NSF player, based upon some of the previous discussions in this thread?

Not sure on single Arduino control option, don't know enough about the ArduinoBoy code. Lots of IFs
MCTRL should work with FamiSlayer but again you'r back to a timing track (which you would need with PR8 also). The plus is you have fine grain control to adjust (via the track) without disturbing the other tracks' tempo, but this is also an extra burden.

m00dawg wrote:

I guess long story short, it sounds like going from MIDI Clock to NES requires either some caveats / things to be mindful of, or uC support to make things function like they would with LSDJ or other MIDI clock-aware devices?

No perfect solution ATM. If I had the skills, the best would be a sync-able NSF driver. Guess that is possible, the FamiTracker source code is open, if someone has a mind to change it.
Yogi

DSC wrote:

Thank you,
Yep, SysEx is how it communicates.  That was one thing that was kinda of a drawback considering Arduino would have USB, but in the end multi OS platforms and features seem to be more desirable.

Cool, like'n that. Would streamline switching carts, but with the learn function it's easy enough. I'm ok with straight Midi on kit; USB to Midi interfaces are common and universal. In some way USB midi is kind of limiting, hard o find a sequencer that functions as a USB host.

 

DSC wrote:

Oh, and the order of buttons was 'Up' 'Down' 'Left' 'Right' 'Select' 'Start' 'B' and 'A'.  In my own setup I use a Cirklon to stay in perfect unison with my live setup.  This way I don't even use a DAW or computer in my live rig.

That looks awesome!

Looking through your site; Sega(?)   Hmmmm...will have to keep an eye on it smile
Yogi

Excellent! Quality product and worth the cost. Full understand the design choices; looks like it would stand up to the the demands of being on the road well.

So did I understand from the screen shots that it's configured via a SysEx message? That would work well with multiple cartridges and different control configurations, could embed the cart's configuration within the midi file.
yogi

Thanks DSC!! Great info.
I've been playing with sync ideas for a bit and had headed down the Beat Clock path but am re thinking it now. The sync code I've been working on so far is based on FamiSlayer but I'm a little up in the air as to the selection of triggers and controller standards in a midi setting.

I don't want to encroach on MCTRL, it looks to be a solid, well built device. But before I finish off the code i've been working on I got to ask you if you can share any info on the button assignments and functions. I guess it's flexible with MCTRL's 'learn',  to work with any button usage; but I'd like to use the same assignments chosen for PR8, rather then create yet another control scheme.
yogi

m00dawg wrote:

Aha ok. Mostly makes sense (re the BPM) but I think I'll have to try it out and see to really know how it will affect things in practice but now I see what you're referring to.

Major changes to the NSF's tempo will mostly affect how a triplet or vibrato will sound, they'll be slower or faster, like changing the speed on a turntable (without pitch shift).
One workaround idea could be a second clock that free runs at or about 150 pulse rate for the NES but also syncs, in a very broad way, to the Midi master clock. You would write your NES track with it's internal BPM close to the song's BPM so it's 'what you hear is what you get'. Playback is controlled by the secondary clock's BPM but syncs to the Master Midi Clock every ~2, 4 or 8 bars (?) then adjust the Second Clock (small shifts) as needed to get the best timing.
This could all be in the uC, just a timer routine that's adjusted/locked to the incoming Midi Clock.

m00dawg wrote:

If the input/output trick works on Arduino there probably isn't much worry to do any other shenanigans so I think I'll try that first since I have all the stuff I need to get it going I think and I can go from there. Since this would be for stage and studio, I'll want to built something that is hardy enough. On that note, it sounds like MCTRL is doing very similar things so I'm guessing it would be useful for controlling FamiSlayer if I wanted to buy over build?

MCTRL is based on a Highly Liquid Midi board and is programmable but I think it responds to Note On/Off messages and not sure if it does Midi Clock messages.
So in your user case; you would have to use one of the tracks in your DAW to send the Note message timing, a Click track smile This may be more flexible to handle the issues; just come up with a note pattern that sends 150 'note ticks'
each Min of your song regardless of it's tempo. Does this sound more flexible to you? Because as I'm writing, it kind of seems like a really good way to control the NES, hummm.

m00dawg wrote:

By the way, thanks again! I've been wanting to do this for years now and the detail and time taken to explain all this is much appreciated!

No problem, Been wanting this sort of setup also, since I first heard about MidiNES in '01 or 02. That didn't workout too well for me, but lately there are a lot of great projects that pull this all together. Lucky Us smile
Yogi