You mentioned hacks. The cartridge I mentioned isn't a hack, it's just dedicated equipment.
Which brings me back to my original point: if you don't like the idea of multiple expansions, just don't use them or ask for them (i.e. don't specifically ask for them not to be implemented). You have a right to your opinion, and that's fine, but please respect that of those of us who would like such a feature to be implemented some time in the future. Thank you.
That's what I mean when I say "shits on the real system architecture.".
Expansion chips shouldn't be supported at all then, because they are basically hacks of the "real system archetecture." You could hook up anything to that extra pin and get audio from it, in theory.
That's what I mean when I say "shits on the real system architecture.".
Expansion chips shouldn't be supported at all then, because they are basically hacks of the "real system archetecture." You could hook up anything to that extra pin and get audio from it, in theory.
Well, I bet NES purists already think expansions are excessive, and that 2A03 alone should be more than enough. And after listening to some compositions out there online, I'd say they have a point (sometimes).
You could hook up anything to that extra pin and get audio from it, in theory.
Yeah, that's the output side, but how you can manage the input?. You can hook up a Foodmixer and get audio from that pin, but how you can send commands to the Foodmixer?.
If someone can explain me how to send information to VRC6/VRC7/NAMCO106, etc, at the same time on the same cartridge, using the standard BUS of the 2A03, I will start thinking that it is not a hack.
Btw, I can't find the link to that Japanese cartridge with more than 1 soundchip, I'm interested.
That's what I mean when I say "shits on the real system architecture.".
Expansion chips shouldn't be supported at all then, because they are basically hacks of the "real system archetecture." You could hook up anything to that extra pin and get audio from it, in theory.
Time to intervene here...
That Japanese multi-expansion cartridge is dedicated equipment indeed, but still remains a hack because the circuit board for that cartridge runs an extra microcontroller & is wired in such a way as to take advantage of all the possible output paths for each expansion; if it weren't for that custom-programmed microcontroller, you'd see the console's actual limitations of not being able to run all expansions without conflicting with each other.
It's true that you can take any output pin of any device & use it as audio output (provided that it produces a high enough current,) but the same can't be said for any & every input pin because you'd then have to figure out how the intelligence is organized before being sent to that input. And to manipulate it, you'd definitely need to make your own elaborate system to generate/convert the intelligence from one form to another (& that's when you get into hacking).
As for the tracker's support of all sound chips in one module, I don't mind having this feature as long as doing so will at least force the tracker to disable NSF export (namely because NSF & NES ROM data shouldn't support all expansion chips at the same time, in keeping with the original hardware's limits).
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
That's easy; all you need to do is put a low-pass filter (with a ridiculously huge resistor) on the blade's motor input & feed that to a class AB transistor amplifier. All you'd get is a steady sine wave tone for each different speed setting on your "mixing" board. :P
Anyways, I remember that the multi-expansion cartridge links were posted up here somewhere. I can't find them, though.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
That's easy; all you need to do is put a low-pass filter (with a ridiculously huge resistor) on the blade's motor input & feed that to a class AB transistor amplifier. All you'd get is a steady sine wave tone for each different speed setting on your "mixing" board. :P
OMFG!!! That idea is so geeky but so correct physically, that it gives me chills. xD
As for the tracker's support of all sound chips in one module, I don't mind having this feature as long as doing so will at least force the tracker to disable NSF export (namely because NSF & NES ROM data shouldn't support all expansion chips at the same time, in keeping with the original hardware's limits).
I disagree. NSF support should be enabled since the NSF format supports multiple simultaneous expansions. We're writing NSFs here, not programming NES ROMs... And anybody who actually is making music for the purpose of using it in homebrew NES software probably already knows better than to use several sound chips...
Imo, If, no matter the hacked equipment you use, it's possible on the real hardware successfully, then we got ourselves a keeper. I'll bet using all chips at once on the real stuff is easier than overclocking an NES/FC as well.
That Japanese flash cartridge is rare, so if you're going to go that way with using physical hardware & can't find the cartridge, you'd have to create your own flash cart from scratch (including programming the microcontroller to allow all expansions to work without interferance) or you'd have to hack a PowerPak (again, using a microcontroller that you program yourself).
To use all chips at once on real hardware would require you to understand how all the audio data from all of the expansions are transfered from the cartridge to the CPU & back before outputting the resulting audio signal to the RCA jack; you'd then have to use this information to program a microcontroller in such a way that you can create a new path between certain expansion signals & the CPU (because some expansion chips use the same communication lines to send info to the CPU).
Over-clocking, on the other hand, is MUCH easier because it's really a matter of working with the CPU & PPU's internal & crystal oscillators.
This said, if emulator & NSF player programmers decide to NOT go for 100% accuracy, then multi-expansion NSFs could be good to have (but I doubt this will ever happen).
jrlepage wrote:
I disagree. NSF support should be enabled since the NSF format supports multiple simultaneous expansions. We're writing NSFs here, not programming NES ROMs... And anybody who actually is making music for the purpose of using it in homebrew NES software probably already knows better than to use several sound chips...
Yes; but because the NSF spec supports it, it doesn't mean that it's supposed to. The NSF spec is based off of Marat Fayzullin's iNES spec (& we all know how drastically flawed it is when compared to the UNIF file spec,) namely because the iNES spec dosen't adhere to hardware specifications as well as it should. To further compound the problem, there aren't many people who have knowledge of the hardware or the software aspects of the NES, nor does every chiptune composer readily have the know-how to hack (or access to any hacked) hardware. But once again, I guess it's good to have the feature available to have for those of us with the technical skills.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
I disagree. NSF support should be enabled since the NSF format supports multiple simultaneous expansions. We're writing NSFs here, not programming NES ROMs... And anybody who actually is making music for the purpose of using it in homebrew NES software probably already knows better than to use several sound chips...
Yes; but because the NSF spec supports it, it doesn't mean that it's supposed to. The NSF spec is based off of Marat Fayzullin's iNES spec (& we all know how drastically flawed it is when compared to the UNIF file spec,) namely because the iNES spec don't adhere to hardware specifications as well as it should.
Quite frankly I'm not all that much into the more technical stuff; I don't understand much of it and I'm not interested in it either. What I am interested in however is writing music. I have chosen the NSF format because I like it. One of the reasons I like it is because of its vast choice of expansions. I like to use more than one of those, and the NSF format allows it. I don't really care whether it should or not, that isn't my debate; but the fact of the matter is that it does. All I'm saying is, if the NSF format supports it, then the "the NES can't do it" argument is moot, because the format we're writing for can do it, and there's no denying that. And if the NSF format can do it, when why shouldn't any piece of software whose purpose is to export to it?
Now if jsr decides that this should not be implemented (and I think I recall him saying otherwise somewhere on this forum), then I'll respect his decision. But I'd still like it to be implemented, which is why I requested it. So there.
) 
